Agil projektmetodik Varför och vad är det?bme.lth.se/.../Projektmetodik_Agilt_2017.pdfBoris Magnusson CS, LTH 2016-02-08 Om det inte är Agilt - vad är det då? • Trögröligt

Agil projektmetodikVarför och vad är det?

Boris MagnussonDatavetenskap

LTH

2017-02-06

Boris Magnusson CS, 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 !

3. Do the job twice4. Testing, planned controlled monitored5. Involve the customer


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 metodagile – lättrörlig, vig

• “The agile manifesto”:

viktigt ännu viktigare

arbetsprocesser och verktyg individer och interaktion

dokumentation fungerande programvara

kontrakt med kunden samarbete med kunden

följa en plan 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. PlaneringPlaneringsspelet Regelbundna releaser Hållbart tempo Kund i teamet

2. UtvecklingTest-driven utveckling (TDD) Parprogrammering Kollektivt ägande Kontinuerlig integration

3. Kodning och DesignEnkel design Refaktorisering Kodningsstandard Gemensam vokabulär

4. DessutomGemensamt 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

• 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?

Kunder 1) Skriver ”user stories” (enkla användningsfall)

3) Prioriterar stories

Utvecklare2) Estimerar ”tid”

för varje story ”Story”


Regelbundna releaserRelease 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 nersenaste integrerade versionen)

• Varför?

- Kunden kan tidigt börja använda nya funktioner

- Programmerarna får snabb feedback

- Nya krav kan påverka vidareutvecklingen

- Lätt att göra omprioriteringar


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)

• När testprogrammen fungerar är man färdig!

Skriv ett nytt testfall

Koda

Kör testfallen


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 DesignCode 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 ändringarmed huvudversionen?

- Så snart ett nytt testfall fungerar!

- Flera gånger varje dag!

- Kräver smidiga konfigurationshanterings-verktyg


Delteknikerna förstärker varandra

• Vi vågar refaktorisera för vi har:

- Organiserade tester, jobbar ihop, enkelhet, integrerar ofta…


Feedback i XP

Faser i traditionella Utvecklingsmodeller

Tid

Vatt

enfa

ll

Allt Kra

v

Des

ign

Impl

Test

Und

erhå

ll

Leverans

Iter

ativ

tD

elar

Kra

v

Des

ign

Impl

Test

Kra

v

Des

ign

Impl

Test

Kra

v

Des

ign

Impl

Test

Kra

v

Des

ign

Impl

Test

Lev 1

Lev 2

Lev 3

Lev 4

Und

erhå

ll

Faser i Agil utveckling

XP

Tid

Nollte iteration

Stories

Krav

Design

Impl

Test

Krav

Design

Impl

Test

Krav

Design

Impl

Test

Krav

Design

Impl

Test

Krav

Design

Impl

Test

Krav

Design

Impl

Test

Krav

Design

Impl

Test

Krav

Design

Impl

Test

Krav

Design

Impl

Test

Krav

Design

Impl

Test

Funktion

Impl

Des

ign

Kra

vTe

st

Lev 1

Lev 2

Lev 3

Lev 4


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

VMUtbValideringUtv2Utv1


Iterationer

• Vi delar upp vägen till nästa (första) release i ett antal steg, iterationer.

• Precis som releaser bestäms iterationer av tid- punkter, t ex 2-3 veckor, snarare än innehåll.

R1

I1 I2 I3

R2R2R2

R2


Release-Iteration-Story-Task

I1 I2 I3

S1 S5S4S2 S3

T1

T2

T3

7 2 5 4 2 Summa = 16

R1

R2R2R2

R2Kunden

Kunden

Utvecklare

Utvecklare


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 TrenchesErfarenheter från det Svenska PUST-projektet

Documents

Agil projektmetodik Varför och vad är det?bme.lth.se/.../Projektmetodik_Agilt_2017.pdfBoris Magnusson CS, LTH 2016-02-08 Om det inte är Agilt - vad är det då? • Trögröligt