Mjukvaruprocessen: översikt och repetition. XP: problemformulering. JUnit.

Innehåll Allmännt om utvecklingsprocesser från Bruegge kapitel 12 Separata OH-bilder Introduktion till eXtreme Programming (XP) Översikt och problem som man vill lösa Ett enhetstestning med hjälp av Junit Från Fowler med separat utdrag och OH-bilder OOMPA 2000 Föreläsning 12 Mjukvaruprocessen: översikt och repetition.XP: problemformulering.JUnit.

eXtreme Programming (XP), av Kent Beck Tillvägagångsätt (12 grundpelare) eXtreme Programming • Parprogrammering • två programmerare per maskin • Kollektivt ägande av koden • alla äger och kan ändra i koden • Kontinuerlig integration • integrera och bygg systemet flera gånger per dag • 40-timmarsvecka • jobba som regel inte mer än 40 timmar per vecka • Inkludera en "kund" i teamet • inkludera en "riktig användare" på full tid • Följ kodstandard • förenklar kommunikation • Planeringsspel • planera snabbt förutsättningarna för nä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åste lyckas innan utvecklingen går vidare. • Skriv testerna först! • Omstrukturera ("refactoring") • strukturera om ofta; ta bort onödig kod, förenkla osv

Grundproblemet: Risk • Tidsramar brister • Programvaran ej klar vid utsatt datum • Projekt avbryts • Efter massa fel så avbryts projekt • System blir sura • Efter några år blir det för dyrt att underhålla programvara även om den var lyckosam från början • Många defekter • Produktionsprogramvara använd inte pga för många defekter

...problemet • Fel problem löses • Programvaran löser inte det problem som man från början skulle läsa • Problemdomänen förändras • Efter ett tag ändras behoven så den existerande programvaran löser ett gammalt problem • Massa onödiga ”features” • Programvaran innehåller massa finesser som var roliga att progammera fast egentligen inte behövs • Utvecklare byts ut • Efter ett tag tröttnar programmerarna på projektet och slutar

XPs lösning på problemet: Risk • Tidsramar brister • XP använder korta cykler med täta releaser • Projekt avbryts • XP ber kunden att välja den minsta release som ger maximalt värde. Vilket medför att så lite som möjligt kan gå fel innan avstämning, samtidigt som man fokusera på det viktigaste • System blir sura • I XP skapas massor av tester som körs efter varje förändring. Detta gör att systemen ”hålls i form” • Många defekter • I XP skriver både utvecklare och kunder tester vilket reducerar sannolikheten för defekter

...XPs lösning på problemet • Fel problem löses • I XP deltar kunden som en viktig del i utvecklingsteamet. Specifikationer uppdateras kontinuerligt under utvecklingen • Problemdomänen förändras • XP förkortar releasecyklerna, så det är inte så många förändringar i utvecklingen av en release. Däremot är kunden välkommen att komma med nya krav kontrinuerligt (som vanligen tas upp under nästa cykel) • Massa onödiga ”features” • I XP fokuserar man på högprioriterade uppgifter • Utvecklare byts ut • I XP behandlas utvecklare som intelligenta och ansvarsfulla individer som får ta eget ansvar. Därmed minskar man risken för frustrerade programmerare. XP innehåller också element för övertagande av kod.

Arbetssättet vid kodning i XP, några huvuddrag • Par programmerar tillsammans • Utvecklingen drivs av tester • Man testar först kodar sedan • Alla tester måste fungera innan man är klar • Par gör inte bara enskilda delar körbara utan utvecklar och designar också (om) hela systemet • Integration följer hela tiden på utvecklingen av en viss del • Detta inkluderar också integrationstestning

Vi försöker kontrollera fyra variabler • Kostnad • Mer pengar löser vissa problem fast för mycket kan skapa nya problem • Tid • Mer tid gör att vi kan leverera mer. Men för mycket tid kan vara till skada. • Kvalitet • Genom att tumma på kvaliteten kan man göra vissa vinster på kort sikt. Men på längre sikt kostar det för mycket. • Omfattning • Mindre omfattning gör det möjligt att bättre kvalitet samt leverera tidigare och billigare

Kostnad för förändring • Man brukar säga att kostnaden för förändringar av ett system ökar exponentiellt över tiden • Med XP verkar det som om kostnaden för förändring planar ut • Detta därför att vi hela tiden testar (automatiskt), gör så lite som möjligt (inga onödiga finesser som gör systemt mer komplext), gör saker på bara ett ställe, integrerar kontinuerligt och alltid omstrukturerar • Vi blir dessutom på grund av detta vana att hela tiden förändra och modifiera designen

Fyra värden • Kommunikation • Utvecklare kommunicerar med varandra • Enkelhet • Vad är det enklaste som kan fungera? • Återkoppling (feedback) • Tester, stories, systemet välstrukturerat och självförklarande • Kurage • Fixa fel eller brister med stort kurage, dvs tveka inte

Grundläggande principer • Snabb återkoppling • Kort tid mellan aktion och feedback • Antag enkelhet • Behandla ett problem som om det kan lösas otrolig enkelhet • Inkrementell förändring • Lös problem som en serie av små förändringar • Anamma förändring • Bästa lösningen är att lösa det viktigaste först men ha maximalt med möjligheter till variationer kvar • Kvalitetsarbete • Alla vill göra ett så bra jobb som möjligt

Basala element • Kod • Till slut är det bara koden som räknas oavsett hur många diagram du ritat • Test • Vi vet inte om något fungera om vi inte testar det • Testerna gör att vi kan tänka på ett problem på ett lite annorlunda sätt • Lyssna • Lyssna på kunder, domänexperter osv • Design • För att få ett bra system måste vi (självklart) designa även i XP

Mjukvaruprocessen: översikt och repetition. XP: problemformulering. JUnit.