Agil projektmetodik Varför och vad är det? Boris Magnusson Datavetenskap LTH 2016-02-08
Lite större projekt Sträcker sig över tid Involverar många deltagare som behöver arbeta parallellt Planeras - delas upp, säkerställa att delarna passar när det skall sättas ihop Både när det gäller tidsplaner och funktion
Agilt - vad betyder det? Agile (eng.) = lättrörlig, vig Projektmodell: - Anpassning när målen blir bättre kända, - eller ändrar sig. - Minska onödig byråkrati - Iterativt, i mindre steg - Förbättrar när det inte blir bra.
Om det inte är Agilt - vad är det då? Trögröligt! - Uppstyrd process för hela projekt - Utföres i faser som var och en måste vara färdig innan nästa påbörjas. - Tydligt dokumenterade steg - Så man vet vad man gör - och inte gör något fel som måste göras om
Exempel: Tunnel genom Hallandsåsen Tågtunnel - inte första gången i världshistorien Vad behövs: - Borras två hål, läggas räls, elinstallationer, anslutningar, en ny station. Stort men välkänt. Upphandling: så noggrann spec: - Detaljer, krav, tider för leverans, 1997. Kraftbyggarna vann upphandlingen (billigaste budet) - Byggt mycket tunnlar till vattenkraft i Norrland. - Borrat i urberg - nu en grusås skall också gå.
Så mycket för den planeringen! (Tunneln blev 18 år försenad)
Kraftbyggarna gick i konkurs Man kan missa något viktigt Viktigt att: - Först prova i mindre skala - Prototyper - Vara beredd att backa och göra om
Tyvärr är det inte bättre i programvaruprojekt Många stora satsningar har havererat helt: - Nordea - 5 Miljarder - SEB - 753Miljoner -> 2 Miljarder - Försäkringskassan - 400Miljoner - Polisen/PUST - 300Miljoner - Gemensam Vård Data (GVD) - 1,6Miljarder (NPÖ) - Försvaret Prio - 2,4 Miljarder - GB: EHR (Journalsystem) - 12 Miljarder Pund (!) Alla med Trögrörligt projektupplägg.
Varför går det så illa? Verksamhetskritiska system - programvara - Måste passa användarnas behov väldigt väl. Hur specificerar man ett sådant: - 1) Frågar chefen? Vad skall personalen göra - 2) Frågar användarna? Vad behöver ni - 3) Observerar användarna! Se vad dom gör Men - ett nytt system ändrar ofta behovet - 4) Utveckla tillsammans med användare - Ändra, lägga till, Agilt!
Inte alltid så - strikt planering ända möjligheten ibland Kommunikation mellan apparater - Utvecklade parallellt av olika grupper/företag - Måste fungera ihop Mobiltelefon - Basstation (många tillverkare av båda) Mycket tydliga specifikationer. Analyserade, Simulerade, Prototyper Referens-implementationer att verifiera mot Certifiering av speciella organisationer
Elektronik - programvara? Min bild :-) Prototyping HW+SW Iterativt: - Bygga Testa Börja med något litet, få att fungera, bygg vidare Mycket som är likt
Utveckling av programvara - hur gör man? Två tydliga strategier: - Vattenfall - trögrörlig modell - Agilt - lättrörlig modell Går tillbaka till ämnets barndom, 1970!
En tidig publikation: Managing the Development of Large Software Systems, Dr. Winstone W. Royce, IEEE, 1970 Skisserade hur han såg på utvecklingsmetodik. Vattenfallsmodellen Upphov till strikta metoder: Varje pil är ett dokument
Men så enkelt är det inte menade han Feedback!
Hela bilden som Royce såg det: Agilt!
Vad är XP? En metod för hur man utvecklar programvara - i grupp - i nära samspel med kunden - med täta releaser - med hög kodkvalitet - som skall kunna förändras och leva under lång tid
XP en agil metod agile lättrörlig, vig The agile manifesto : viktigt arbetsprocesser och verktyg dokumentation kontrakt med kunden följa en plan ännu viktigare individer och interaktion fungerande programvara samarbete med kunden kunna hantera ändringar i planen
Varifrån kommer XP? Smalltalk-traditionen: 1972, 1980,... - dynamiskt OO språk och integrerad programmeringsmiljö - everything is an object - programmeringsstil: explorativ, prototypande,... Kent Beck & Ward Cunningham pionjärer inom OO design - CRC-cards 1989 (Class, Responsibility, Collaboration) - Patterns 1987
XP:s Deltekniker (Practices) 1. Planering Planeringsspelet Regelbundna releaser Hållbart tempo Kund i teamet 2. Utveckling Test-driven utveckling (TDD) Parprogrammering Kollektivt ägande Kontinuerlig integration 3. Kodning och Design Enkel design Refaktorisering Kodningsstandard Gemensam vokabulär 4. Dessutom Gemensamt utvecklingsrum Nollte iterationen Spikes
1. Planering i XP Börja med en enkel plan Planera om efter hand Rimlig nivå: Jfr köra bil till Italien Få med det användarna prioriterar högst tidigt
Planeringsspelet Kunder 1) Skriver user stories (enkla användningsfall) 3) Prioriterar stories Story Utvecklare 2) Estimerar tid för varje story Relativ estimering Hur svår är denna story jämfört med andra? Hur mycket hann vi sist? Så mycket hinner vi nog nästa iteration också. Yesterday s weather Prioritering vad är viktigast just nu?
Regelbundna releaser Release Regularly / Small releases Vad innebär det? - Releaser till kund skall göras ofta, och med små inkrement. - Den första releasen begränsas i storlek så mycket som möjligt så att normalfallet är att vi har en releasad produkt När? - Typiskt efter varje iteration - Ibland kontinuerligt (kunden har alltid möjlighet att ladda ner
2. Utveckling i XP Hög kvalité - identifiera fel så tidigt som möjligt Snabb feedback till: - utvecklarna - andra i teamet - användarna/kunden
Testning Testning är centralt i XP Enhetstester (unit tests) för varje klass/modul - Ett testfall skrivs innan motsvarande kod (Test-Driven Development) - Testfallen automatiseras (regressionstest) (vi kan enkelt köra om alla testfall efter en ändring) Acceptanstester för varje story - Även acceptanstestfallen automatiseras
Test-Driven Development Testfallet skrivs innan koden! - Fungerar som specifikationer vad skall koden göra? - Skrivs i mycket små iterationer: testa...koda...testa...koda... - Körs automatiserat alla testfall körs efter en ändring (så ser man att man inte förstört något som fungerade tidigare) Skriv ett nytt testfall Koda Kör testfallen När testprogrammen fungerar är man färdig!
Acceptanstester Kunden tänker ut testfall för stories: - Vad skulle övertyga mig om att denna story är implementerad? - Programmerare hjälper kunden att implementera testfallen Testfallen mäter hur projektet framskrider Först när användaren har tillgång till en story har den värde.
3. Kodning och Design i XP Komma igång så fort som möjligt! Skapa ett skal Nollte iteration - något att integrera mot. Jfr: - Hallandsåstunneln - Strömförsörjning
Enkel Design Code and Design Simply / Simple Design Vad innebär det? - Ren tydlig kod, goda namn - Ingen duplicerad kod - Ingen onödig komplexitet (all komplexitet skall vara motiverad av dagens behov testfallen) - Enkel design innebär att programmet är lätt att förstå och ändra Ibland kräver det mer jobb att få det enkelt!
Enkel design växer fram Designen växer fram för att passa de testfall som finns idag - I motsats till Big upfront design (när man designar för morgondagens behov) Varför? - Vi vet inte om en big upfront design verkligen kommer att passa förrän vi har implementerat kraven - Vi vet inte om en big upfront design verkligen kommer att behövas kanske alla delar av designen inte kommer att utnyttjas, kanske ändrar projektet riktning - Vi är inte rädda för att ändra kod och design när vi behöver det En komplicerad design blir bättre om man gör den i många små steg, med feedback från testfallen i varje steg.
Parprogrammering (Pair Programming) Två personer vid en maskin! - Driver & Partner. Växlar ofta. Paren kan växla flera gånger per dag Parprogrammering innebär automatisk kodgranskning
4. Refaktorisering (Refactoring) Omstrukturering av koden utan att ändra beteendet Exempel: - Rename Method (byt namn på en metod och alla anrop till den) - Extract Method (bryt ut ett stycke kod till en egen metod) - Move Method (flytta en metod från en klass till en annan) Varför - Åstadkomma och upprätthålla Enkel Design Hur? - med verktyg (Eclipse, Smalltalk refactoring browser,...) - för hand (jobbigt)
När gör man refaktorisering? För att förstå koden bättre - när man läser den inför att göra en ändring För att lättare kunna införa en ändring När koden börjat lukta illa - och man inte längre har Enkel Design Hela tiden, i små steg - omfattande refaktorisering har man sällan tid med
Kontinuerlig Integration (Continuous Integration) När skall man integrera sina ändringar med huvudversionen? - Så snart ett nytt testfall fungerar! - Flera gånger varje dag! - Kräver smidiga konfigurationshanteringsverktyg
Delteknikerna förstärker varandra Vi vågar refaktorisera för vi har: - Organiserade tester, jobbar ihop, enkelhet, integrerar ofta
Feedback i XP
Traditionella Utvecklingsmodeller Vattenfall Allt Iterativt Delar Tid
Agil utvecklingsmodell Nollte iteration Stories XP Tid
Release-plan När ett OS (VM etc) startar måste datorsystemen vara användbara. - Deadline! Det är kunden och deras prioriteringar som bestämmer vilken funktion som skall vara med. R1 R2 R3 R4 R5 Utv1 Utv2 Test Utb VM
Iterationer Vi delar upp vägen till nästa (första) release i ett antal steg, iterationer. Precis som releaser bestäms iterationer av tidpunkter, t ex 2-3 veckor, snarare än innehåll. R1 R2 R2 R2 R2 I1 I2 I3
Release-Iteration-Story-Task Kunden Utvecklare S1 S2 S3 S4 I1 S5 I2 R1 I3 Kunden Utvecklare T1 T2 T3 7 2 5 4 2 Summa = 16 R2 R2 R2 R2
XP-metoden Högiterativ agil metod De traditionella faserna (kravanalys, design, impl, test) vävs samman Körbar produkt så tidigt som möjligt. Vidareutveckling är normalfallet. Fokus på test och test-driven utveckling Muntlig kommunikation hellre än skriftlig Små inkrement feedback i varje steg Konkreta deltekniker
Vad göra om det blir problem? Traditionellt: systemet blir inte klart i tid - Stoppa in mer folk? - Projektet blir ännu mer fördröjt (de gamla måste först lära upp de nya och får inget gjort i början). XP: systemet får inte med alla funktioner - De väsentligaste funktionerna är med - Mer folk? - kan gå med parprogrammering
Målet med XP Utveckla vad användaren vill ha Mycket hög kodkvalitet Kod som kan ändras i takt med förändrade krav Lycka till med projekten!
För den som vill läsa mer Chromatic: Extreme programming pocket guide, O'Reilly, 2003. ISBN: 0-596-00485-0. Extremt kompakt introduktion James Shore & Shane Warden: The Art of Agile Development, O'Reilly, 2008. ISBN: 0-596-52767-5. Fylligare beskrivning Henrik Kniberg Lean from the Trenches Erfarenheter från det Svenska PUST-projektet