XP: varför fungerar det?Något om tentan.
Innehåll
Introduktion till eXtreme Programming (XP)
Varför fungerar XP?
Något om tentan
Vad ska man läsa och hur ser den ut?
OOMPA 2000
Föreläsning 13
eXtreme Programming
eXtreme Programming
•eXtreme Programming (XP), hur var det nu
•Tillvägagångsätt (12 grundpelare)
• Planeringsspel
planera snabbt förutsättningarna förnästa release; prioritera, teknikkrav
• Små releaser
släpp nya versioner ofta
• Metafor
hitta en enkel och bra metafor
• Enkel design
gör designen så enkel som möjligt
• Testa
testa koden kontinuerligt. Måstelyckas innan utvecklingen går vidare.
Skriv testerna först!
• Omstrukturera ("refactoring")
strukturera om ofta; ta bort onödigkod, förenkla osv
• Parprogrammering
två programmerare per maskin
• Kollektivt ägande av koden
alla äger och kan ändra i koden
• Kontinuerlig integration
integrera och bygg systemet fleragånger per dag
• 40-timmarsvecka
jobba som regel inte mer än 40timmar per vecka
• Inkludera en "kund" i teamet
inkludera en "riktig användare" påfull tid
• Följ kodstandard
förenklar kommunikation
Varför fungerar XP
Varför fungerar XP
•Några motiveringar till varje regel efter Beck
•Han säger i princip att alla regler behövs tillsammansför att det hela verkligen skall fungera
–Dock fungerar ”regler” som testa först, enkel design,refactoring och kontinuerlig integration även utan att resten avreglerna används eller hela XP genomförs
Planeringsspelet
•Man kan väl inte starta utvecklingen med bara en vagplan? Det är väl sedan inte möjligt att kontinuerligtuppdatera planen?
•Om inte
–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
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
•Om inte
–Planeringsspelet hjälper dig att fokuser på det mest väsentliga
–Man integrerar kontinuerligt, så paketeringskostnaden blirminimal
–Testningen reducerar defekterna så att långa testsekvenser intebehöver genomlöpas
–Du kan göra en enkel design, tillräcklig för aktuell release menkanks inte för alltid
Metaforer
•Man kan väl inte börja utveckla med bara en metafor?
•Det finns väl inte tillräckligt med detaljer och vadhänder om man har fel?
•Om inte
–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 dinakunskaper om metaforen och vad den betyder i praktiken
Enkel design
•Du kan väl inte ha tillräcklig design för dagens kod? Dumålar in dig i ett hörn, utan möjlighet att fortsätta
•Om inte
–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 enenkel och motiverbar design
Testning
•Man kan väl inte skriva alla tester som behövs? Det tarväl för lång tid. ”Programmerare skriver inte tester!”
•Om inte
–Designen är så enkel den kan bli
–Du programmerar med en partner, så om du själv inte kommerpå 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 allatester fungerar
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 kontrolleraoch troligen förstörs väl hela systemt?
•Om inte
–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
Parprogrammering
•Du kan väl inte skriva all kod i par? Det går väl förlångsamt? Vad händer om folk inte passar ihop?
•Om inte
–Kodstandard används
–Alla är utvilade
–Paren skriver testerna ihop, så att dom kan ”förena”förståelsen innan dom tacklar den huvusakligaimplementationen
–Paren har en metafor
–Paren jobbar med en enkel design, så båda är med på vad somhänder
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
•Om inte
–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ågotminskar
–Du parprogrammerar, så att man minskar risken för attförstöra koden
–Du följer kodstandard
Kontinuerlig integration
•Du kan väl inte integrera efter bara ett par timmar?Integration tar väl för lång tid?
•Om inte
–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
40-timmarsvecka
•Man hinner väl inte göra tillräckligt på 40 timmar?
•Om inte
–Planeringspelet ger dig det som är av mest värde att jobba med
–Kombinationen av planeringsspelet och testning reducerarfrekvensen av hemska överaskningar
–Alla ”regler” tillsammans gör att du kan gå fort fram
Kund på plats
•Det kan väl inte var mest effektivt att ha en riktig kundpå plats på full tid?
•Om inte
–Dom kan ge värde åt projektet genom att skriva funktionstest
–Dom kontinuerligt kan hjälpa till att göra prioriteringar
Kodstandard
•Du kan väl inte be teamet att följa en viss standard?Programmerare är ju individualister och gör helst somdom brukar göra.
•Om inte
–Hela XP hjälper dem att vara med i ett vinnande lag
Seminarium 6
•På seminarium 6: första timme så presenterar deltagarnaen 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
Vad är en eXtreme Hour
•Under en eXtreme Hour går man igenom hela XP-processen mycket snabbt, dvs på en timme
•Av nödvändighet så är den applikation somimplementeras av mer artificiell natur och man brukarnormalt jobba med papper och penna
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, 52-55
eller (ej båda gångerna)
lö 28/10 kl 14-19 i V21-22, 32-34
•Tentamen kommer bli lite mindre omfattande äntidigare
–Tentan bör klaras av på max tre timmar men avschematekniska 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å