2203$ ) UHOlVQLQJ. Varför fungerar XP Några motiveringar till varje regel efter Beck. Innehåll. Planeringsspelet

HTML
DOWNLOAD

Storlek: px

Starta visningen från sidan:

Download "2203$ ) UHOlVQLQJ. Varför fungerar XP Några motiveringar till varje regel efter Beck. Innehåll. Planeringsspelet"

Roger Sandström
för 8 år sedan
Visningar:

1 XP: varför fungerar det? Något om tentan. Innehåll 2203$ ) UHOlVQLQJ Introduktion till extreme Programming (XP) Varför fungerar XP? Något om tentan Vad ska man läsa och hur ser den ut? Varför fungerar XP Några motiveringar till varje regel efter Beck Han säger i princip att alla regler behövs tillsammans för att det hela verkligen skall fungera Dock fungerar regler som testa först, enkel design, refactoring och kontinuerlig integration även utan att resten av reglerna används eller hela XP genomförs previous next previous next 3 extreme Programming extreme Programming (XP), hur var det nu Tillvägagångsätt (12 grundpelare) 3ODQHULQJVVSHO SODQHUD VQDEEW I UXWVlWWQLQJDUQD I U QlVWD UHOHDVH SULRULWHUD WHNQLNNUDY 6Pn UHOHDVHU VOlSS Q\D YHUVLRQHU RIWD 0HWDIRU KLWWD HQ HQNHO RFK EUD PHWDIRU (QNHO GHVLJQ J U GHVLJQHQ Vn HQNHO VRP P MOLJW 7HVWD WHVWD NRGHQ NRQWLQXHUOLJW 0nVWH O\FNDV LQQDQ XWYHFNOLQJHQ JnU YLGDUH 6NULY WHVWHUQD I UVW 2PVWUXNWXUHUD UHIDFWRULQJ VWUXNWXUHUD RP RIWD WD ERUW RQ GLJ NRG I UHQNOD RVY 3DUSURJUDPPHULQJ WYn SURJUDPPHUDUH SHU PDVNLQ.ROOHNWLYW ljdqgh DY NRGHQ DOOD ljhu RFK NDQ lqgud L NRGHQ.RQWLQXHUOLJ LQWHJUDWLRQ LQWHJUHUD RFK E\JJ V\VWHPHW IOHUD JnQJHU SHU GDJ WLPPDUVYHFND MREED VRP UHJHO LQWH PHU lq WLPPDU SHU YHFND,QNOXGHUD HQ NXQG L WHDPHW LQNOXGHUD HQ ULNWLJ DQYlQGDUH Sn IXOO WLG ) OM NRGVWDQGDUG I UHQNODU NRPPXQLNDWLRQ Planeringsspelet Man kan väl inte starta utvecklingen med bara en vag plan? Det är väl sedan inte möjligt att kontinuerligt uppdatera planen? Kunderna uppdaterar själva Baserat på uppskattningar av programmerarna Planera tillräckligt så kunden får en ide om vad som är möjligt Korta releaser så att eventuella fel snabbt uppdagas Kunden finns med och kan kontinuerligt uppdatera previous next 2 previous next 4 Björn Eiderbäck Björn Eiderbäck

2 Täta releaser Antaganden: Man kan inte rimligen producera efter några få månader. Man kan inte rimligen göra releaser i cykler på bara några få dagar Planeringsspelet hjälper dig att fokuser på det mest väsentliga Man integrerar kontinuerligt, så paketeringskostnaden blir minimal Testningen reducerar defekterna så att långa testsekvenser inte behöver genomlöpas Du kan göra en enkel design, tillräcklig för aktuell release men kanks inte för alltid Enkel design Du kan väl inte ha tillräcklig design för dagens kod? Du målar in dig i ett hörn, utan möjlighet att fortsätta Du är van att strukturera om koden Så förändringar är inget som gör dig orolig Du har en bra metafor så framtida förändringar följer en ide Du programmerar med en partner, som hjälper dig att göra en enkel och motiverbar design previous next 5 previous next 7 Metaforer Man kan väl inte börja utveckla med bara en metafor? Det finns väl inte tillräckligt med detaljer och vad händer om man har fel? Du snabbt får feedback från riktig kod och tester Kunden gillar att prata om systemet med metaforen Du kontinuerligt refactors så att du modifierar dina kunskaper om metaforen och vad den betyder i praktiken Testning Man kan väl inte skriva alla tester som behövs? Det tar väl för lång tid. Programmerare skriver inte tester! Designen är så enkel den kan bli Du programmerar med en partner, så om du själv inte kommer på en test så kan kanske din partner Du känner tillfredställelelse då du ser att alla tester fungerar Kunden känner tillförlit till systemet då han/hon ser att alla tester fungerar previous next 6 previous next 8 Björn Eiderbäck Björn Eiderbäck

3 Refaktoring Man kan väl inte strukturera om systemet hela tiden? Det tar väl för lång tid och är för svårt att kontrollera och troligen förstörs väl hela systemt? Du är van vid kollektivt ägande av kod Så att ändra där det behövs är inget du ser som ett problem Du följer en kodstandard Du programmerar i par Du har en enkel design Du har tester Du integrerar hela tiden Så man vet snabbt om någon del är i konflikt med någon annan Du är utvilad Kollektivt ägande av kod Alla kan väl inte tillåtas att ändra vadsomhelst överallt? Folk kommer väl förstöra till höger och vänster Du kan integrerar ofta, så att risken för konflikter minskar Du skriver och kör tester, så att risken för att förstöra något minskar Du parprogrammerar, så att man minskar risken för att förstöra koden Du följer kodstandard previous next 9 previous next 11 Parprogrammering Du kan väl inte skriva all kod i par? Det går väl för långsamt? Vad händer om folk inte passar ihop? Kodstandard används Alla är utvilade Paren skriver testerna ihop, så att dom kan förena förståelsen innan dom tacklar den huvusakliga implementationen Paren har en metafor Paren jobbar med en enkel design, så båda är med på vad som händer Kontinuerlig integration Du kan väl inte integrera efter bara ett par timmar? Integration tar väl för lång tid? Du kan köra testerna kvickt Så att man vet att inget är trasigt Du programmerar i par Hälften så mycket att integrera Du omsrukturerar, så att det är många smådelar Minskar risken för konflikter previous next 10 previous next 12 Björn Eiderbäck Björn Eiderbäck

4 40-timmarsvecka Man hinner väl inte göra tillräckligt på 40 timmar? Planeringspelet ger dig det som är av mest värde att jobba med Kombinationen av planeringsspelet och testning reducerar frekvensen av hemska överaskningar Alla regler tillsammans gör att du kan gå fort fram Kodstandard Du kan väl inte be teamet att följa en viss standard? Programmerare är ju individualister och gör helst som dom brukar göra. Hela XP hjälper dem att vara med i ett vinnande lag previous next 13 previous next 15 Kund på plats Det kan väl inte var mest effektivt att ha en riktig kund på plats på full tid? Dom kan ge värde åt projektet genom att skriva funktionstest Dom kontinuerligt kan hjälpa till att göra prioriteringar Seminarium 6 På seminarium 6: första timme så presenterar deltagarna en läst artikel Väljs bland förslagen på Presenteras/diskuteras ca 10 minuter Troligen delar vi in grupperna efter vilka artiklar som lästs Andra timmen genomförs en extreme Hour previous next 14 previous next 16 Björn Eiderbäck Björn Eiderbäck

5 Vad är en extreme Hour Under en extreme Hour går man igenom hela XPprocessen mycket snabbt, dvs på en timme Av nödvändighet så är den applikation som implementeras av mer artificiell natur och man brukar normalt jobba med papper och penna previous next 17 Tentamen vad ska jag läsa och kunna? Stora delar av boken och artiklarna i kursbunten tenteras Du tenterar antingen ti 24/10 kl 8-13 i F12-15, 45, eller (ej båda gångerna) lö 28/10 kl i V21-22, Tentamen kommer bli lite mindre omfattande än tidigare Tentan bör klaras av på max tre timmar men av schematekniska skäl så får du ändå fem timmar på dig Extentor finns på följande sida För fler detaljer se läsanvisningarna på previous next 18 Björn Eiderbäck

Relevanta dokument

Design och utveckling. 2203$ ) UHOlVQLQJ

Design och utveckling. 2203$ ) UHOlVQLQJ 2203$ ) UHOlVQLQJ Utvecklingsprocessen en översikt. Lite om kravspecifikationer. CRC-kort. XP som exempel på lättviktigare process. Få utvecklare Många utvecklare Design och utveckling Vilken typ av projekt