Projektretrospektiver och Extreme Programming

Coaching av programvaruteam, djupstudie:
Projektretrospektiver och Extreme Programming
Christofer Rydenfält
D-00, Lunds Tekniska Högskola
([email protected])
24 februari 2004
Sammanfattning
Denna studien ger en inblick i hur användning av projektretrospektiver på extremeprogramming projekt (XP) kan gå till. Först ges en bakgrund där syftet med projektretrospektiver tas upp sen beskrivs två försök med retrospektiva övningar som genomförts
på ett XP projekt. Syftet med studien är att med avseende på projektretrospektiver
peka ut skillnader mellan traditionell vattenfalls projektmetodik och XP. Samt att genom exempel, visa hur etablerade retrospektiva övningar kan anpassas till XP och att
ge inspiration till nya övningar som passar bättre in i XP-metodiken.
1
Inledning
Projektretrospektiver, att i efterhand se tillbaka på och objektivt granska ett projekt, är en
metod som använts inom traditionella projekt under en längre tid. Syftet med denna studien
är att utreda huruvida det går att tillämpa projektretrospektiv metodik på ett extremeprogramming (XP) projekt. För att lyckas med detta måste de retrospektionsövningar som
finns anpassas till eller ersättas med metoder som passar XP-metodiken. Till skillnad från
traditionella projekt där utvecklingen kan liknas vid ett vattenfall, bygger XP på mikroiterationer. I traditionella projekt är det inte tänkt att man skall återvända till en passerad fas.
Sist kommer projektretrospektiven, efter projektet avslutats. I XP är utvecklingen cyklisk,
varje mikroiteration har sina mål och innehåller små doser av faserna i ett traditionellt projekt (analys, design, implementation och test-fas) [5]. Detta för med sig att de retrospektiva
metoder som används på ett XP-projekt måste passa in i cykeln.
Vid traditionella projektretrospektiver avsätter man ett par dagar upp till en vecka efter
projektet då alla projektmedlemmar träffas och under ledning av en erfaren person, går
igenom retrospektiva övningar för att få insikt hur projektet fungerat. Syftet är att identifiera
vad som varit bra och dåligt, utreda hur man skall kunna förbättra dåliga saker och få tillfälle
att visa uppskattning och berömma bra saker. Det är omöjligt att i XP där en utvecklingscykel
är på sin höjd ett par veckor, tillämpa denna metodiken eftersom den skulle ta alldeles för
mycket av projekttiden i anspråk. I det projekt som studien utförts på är utvecklingscykeln
ännu kortare än i ett normalt XP projekt, 14 timmar allt som allt. Att lägga några dagar eller
ens ett par timmar på retrospektiva övningar under varje iteration i ett sådant projekt går
av naturliga skäl inte. Det skulle kännas omotiverat och löjligt. Detta särskilt med tanke på
att XP skall vara en lättviktsmetodik. Att tillämpa tung projekt metodik på mindre enklare
projekt får endast följden att projektmedlemmarna med all rätt ifrågasätter metodiken. Det
går helt enkelt inte att motivera metodiken.
Slutsatsen är att metodiken måste bantas, alternativa mindre resurskrävande övningar
måste utvecklas för att kunna använda retrospektiver på XP projekt. I denna studien kommer vi att dels prata om traditionella retrospektiver dels gå igenom 2 olika retrospektiva
1
uppföljningsmetoder som genomförts på ett XP projekt. Den första är “skapa en tidslinje”
vilket är en traditionell metod utvecklad av N. Kerth [1]. Den andra är en enkel form av
enkät undersökning som regelbundet genomförts med ett XP team. Syftet med båda två var
att få projektmedlemmarna att reflektera över arbetet.
2
Metod
2.1
Den traditionella projekt retrospektiven
En projektretrospektiv är inget som genomförs i en handvändning. I normala fall brukar det
sättas av mellan ett par dagar till en vecka i slutet av ett projekt för en projektretrospektiv.
Personen som leder retrospektiven börjar med förberedelser långt innan. Han/Hon måste
sätta sig in i projektet, lära sig förstå den organisation som berörs och samla in synpunkter
från projektmedlemmarna.
En traditionell projektretrospektiv (som den beskrivs av Kerth) är uppdelad i tre delar:
• Förberedelsefasen med syftena att projektmedlemmarna skall få förtroende för varandra, skapa ett bra diskussionsklimat samt att sätta upp regler för retrospektiven.
• “Det förflutna fasen” vilken går ut på att ge alla projektmedlemmar insikt i hur projektet
verkligen gått till. Oftast är detta första gången projektmedlemmarna ser helheten. Man
får perspektiv på projektet och samband som tidigare varit dolda visar sig.
• “Framtidsfasen” detta är förbättringsfasen. I framtidsfasen används vad som under tidigare faser lärts om projektet för att förbättra arbetsprocessen. Detta innebär att man
identifierar orsaker till att det gått bra och försöker få med dessa även i framtiden samt
att man försöker förändra processen på de punkter det gått dåligt.
Till de olika faserna hör en samling retrospektiva övningar. Allt från enklare övningar som
tar någon timme till sådana som tar en hel dag. I “Det förflutna fasen” ingår [1] till exempel
övningen, “skapa en tidslinje” vilken går ut på att identifiera för projektet avgörande händelser
och under “förberedelse fasen” ingår till exempel “definiera framgång” övningen vilken har
syftet att få medlemmarna att uppskatta det som gått bra istället för att bara fokusera på
problemen.
2.2
Projektretrospektiver och i XP
Om man skall kunna tillämpa retrospektiva övningar på XP projekt måste de anpassas. Det
förfaringssätt som beskrivits i korthet ovan är alldeles för tidskrävande. De flesta av de övningar som beskrivs av Kerth är i sig så pass omfattande att de ensamma tar mer tid än vad
som är acceptabelt i ett XP-projekt. I ett traditionellt XP-projekt där iterationscykeln är
på sin höjd några veckor går det inte att tillämpa metodik som är anpassad för projekt där
iterationcykeln är ett år.
Projektet som studien utfördes på hade en ännu kortare iterationscykel som såg ut som följer.
Tid
2 timmar
4 timmar
8 timmar
Aktivitet
Planeringsmöte.
Spiketid, dvs förberedelse inför implementation.
Implementationstid i form av en laboration.
De retrospektiva övningarna förlades till planeringsmötet först i iterationscykeln och avsåg
i första hand föregående iteration. Det gjordes två typer av övningar, dels en enkätundersökning som konstruerats speciellt för ändamålet dels en förenklad version av Kerths övning
“skapa en tidslinje”. Motivet till varför det gjordes en enkät undersökning istället för en traditionell retrospektiv övning är tidsåtgången.
2
2.2.1
Enkät undersökningen
Enkät undersökningen genomfördes på planeringsmötet efter varje långlaboration. Frågorna
som ställdes var dels av en allmän och motiverande karaktär t.ex: “Nämn och motivera minst
två saker som du tycker behöver förbättras från lab 1” till mer specifika fråger. De mer
specifika frågorna valdes ut av coachen och grundas i coachens uppfattning om vad som
behövde belysas från långlaborationen. Syftet med detta var att få projektmedlemmarna att
reflektera lite mer över problem som uppstått under laborationerna. På detta sätt skall de bli
mera medvetna om problemen och därmed kunna motverka dem lättare i framtiden. Exempel
på frågor är t.ex: “Var det något som du upplevde som en “flaskhals” under laboration 2?”.
Denna frågan ställdes med tanke på rad problem med beroenden som coachen noterade under
laboration 2. Syftet var att få projektmedlemmarna att se mer kritiskt på sitt arbete, att
tänka på konsekvenserna. (Se bilaga 1 och 2 för enkäter)
Efter varje enkät skickades det via epost ut en sammanställning av de viktigaste och mest
påpekade svaren till alla medlemmar i gruppen. På detta sätt skulle gruppmedlemmarna
kunna lära sig av varandras erfarenheter av arbetet.
2.2.2
“Skapa en Tidslinje”
Syftet med att skapa en tidslinje är enligt Kerth “att ge alla projektmedlemmarna en möjlighet att lägga sin personliga erfarenhet till projektets kollektiva historia”. Detta hjälper dem
sedan att förstå allt som hänt under projektet. De skall här igenom få en betydligt bättre
helhetsbild av projektet.
Övningen “skapa en Tidslinje” genomfördes under planeringsmöte 4 dvs efter iteration
3 och mitt i projektet. Vi valde att vänta så länge som möjligt med denna övningen för
att ge projektmedlemmarna lite mer att placera på tidslinjen. I Kerths övning “skapa en
Tidslinje” skall man först skapa tidslinjen, sen “gräva efter guld i tidslinjen” dvs identifiera
saker som varit bra samt att identifiera problem. Det senare valde jag att begränsa till en enkel
diskussion (se bilaga 3, Tillvägagångssätt punkt 5 och 6). Anledningen var återigen tidsbrist.
Kerths “skapa en Tidslinje” övning tar mellan 5 och 8 timmar i anspråk, i projektet som
studien utfördes på kunde endast en halvtimme avvaras på grund av de korta iterationerna.
På planeringsmötet försågs projektgruppen med en tidslinje där laborationer, möten och
spiketid var utsatt. På tidslinjen fästes ett par exempel som coachen tyckte var viktiga för att
demonstrera vad det gick ut på. Sen ombads projektmedlemmarna att följa instruktionerna i
bilaga 3. Coachen, jag var hela tiden delaktig och ledde övningen. Resultatet blev en tidslinje
med fokus på händelser under den senaste iterationen. Detta var på intet sätt avsiktligt
eller styrt men av någon anledning blev det så. Kanske för att projektmedlemmarna hade
bäst minne av denna eller för att det helt enkelt hände mer för projektet avgörande saker då.
Under iteration 2 och 3 arbetade gruppen i hög grad med att lösa återkommande problem från
tidigare iterationer. Dessa berodde bland annat på bristfällig testning och dålig kodkvalité.
Det tog ett par iterationer för gruppen att komma till insikt med dessa problem.
3
3
Resultat
3.1
Enkät undersökning
Enkät undersökningarna genomfördes under första delen av planeringsmötet. På det stora
hela var antalet svar och dess omfattning förvånandsvärt stort. Mycket bättre än väntat.
Tyvärr har det i dagsläget bara hunnits med två enkät undersökninger, efter första och
efter andra iterationen. Men trots detta kan man se skillnader mellan svaren de olika gångerna. Svaren på den andra undersökningen fick en betydligt matigare karaktär. Det kom in fler
svar på de specifika frågorna och projektmedlemmarna hade mer precisa åsikter. De verkade
säkrare på sig själv. Kanske berodde detta på att de vid detta laget blivit vana vid dels
XP-metodiken dels undersökningen. Det kan också bero på att de den andra gången visste
om att hela gruppen skulle få feedback på deras svar. Svaren skulle alltså komma dem själva
till nytta, inte försvinna in i en rapport som någon annan skrivit som de ändå aldrig skulle
bli intresserade av att läsa.
Nedan följer en sammanställning av de viktigaste synpunkterna från enkäterna.
• Laboration 1
Kommentar
Test first fungerade dåligt.
Parprogrammering upplevdes som om den fungerade bra.
Kommunikation inom gruppen var inte bra nog.
Kommunikation inom gruppen var bra.
Det refaktorerades alldeles för lite.
För få partner byten.
Det behövs någon form av briefing möte i början av laborationen
för att klargöra designen.
Miljön i Uranus var dålig.
4
Antal
2
9
3
4
4
2
4
2
• Laboration 2
Kommentar
Bättre på Eclipse.
Kommunikationen var dålig, man visste inte vilka konflikter man
riskerade att skapa.
Vissa story’s upplevdes som för stora i iteration 2.
Det gjordes för lite tester.
Det gjordes för lite refaktoring.
Kommunikationen var bättre än förra gången.
Ökad känsla av delat ansvar jämnfört med iteration 1.
Det testades bättre.
CVS-disciplinen blev bättre.
Oklara arbetsuppgifter/story’s.
Design borde klargjorts bättre innan.
Vill gå hem när det inte finns något att göra.
Svårt att hålla sig till story’n pga konflikter
Vissa story’s “blev aldrig” klara och senare förbisprungna av andra
story’s.
Parbyten borde ske oftare.
För mycket fulhack (snabba) lösningar som ställer till problem
senare.
Releasen stoppade upp och tog mer tid än väntat.
Överblicken är för dålig, vet inte vad de andra gör.
Parprogrammering bättre jämnfört med iteration 1.
Vi producerar för lite!
Kodkonventioner följs dåligt.
Antal
1
2
2
5
7
4
1
2
1
1
1
1
1
4
4.
1.
1
1
2
1
1
Tips från enkät:
– Kontrollera mera innan Commit så att det inte läggs upp icke fungerade kod
på CVS. Detta hänger samman med CVS-disciplin och -testning. Man kan bara
garantera att sådant som testas fortsätter fungera när man lägger upp det på
CVSen. Slutsats: All funktionalitet man vill ha måste ha tester.
– Klarare CVS rutiner.
– Kör ett par fast, byt ut den ena medlemmen.
Som kommentar till ovan presenterade resultat bör nämnas att kodkvaliten i projektet
som studien genomfördes på ökade markant. Betydande refaktoreringsarbete genomfördes
och projektmedlemmarna lade större vikt vid kodkvalitét än under de första iterationerna.
Det samma gällde testerna de ökade från 19 till 44 från iteration 2 till iteration 4. Nämnas
bör att testerna i början hade en betydligt mindre karaktär. Allt eftersom programmet blivit
mer komplext ökade också komplexiteten i testerna.
5
3.2
“Skapa en Tidslinje”
Det är svårt att i dagsläget tolka resultatet från övningen då det inte genomförts särskilt
många iterationer efter den ännu. Även om så skulle ha skett skulle det ha varit svårt att
tolka resultatet.
Det finns helt enkelt inga enkla svar på frågan om en sådan här övningar gör någon nytta.
Sådana saker måste utredas under en längre tids försök. I gruppen som försöket genomfördes
på var alla ganska överens om vad de olika problemen var. Det på grund av att gruppen var så
liten (10 personer) och att de hade kollektivt kodägande, alla hade tillgång till all kod. Detta
skiljer XP-projektet från ett vanligt projekt där olika grupper i gruppen oftast ansvarar för
olika delar och därmed har sämre insikt i varandras arbete.
Diskussionen i slutet av övningen blev inte så livlig som vi hoppades på. Kanske återigen på
grund av att deltagarna var mer insatta i varandras arbete än vad som är brukligt i vanliga
projekt. Under senare iterationer har projektmedlemmarna enligt mitt tycke blivit mer varse
om möjliga konflikter och beroenden mellan story’s. Om detta beror på de retrospektiva
övningarnas positiva effekt eller erfarenhet är svårt att säga men det är helt klart att de
retrospektiva övningarna inte skadat projektet.
6
Nedan följer en komplett uppräkning av entiteter från tidslinjen.
Tidpunkt
Första planeringsmötet
Händelse
Gruppen träffas för första gången.
Första spiketiden
Första laborationen
Automatiserade acceptanstester fungerar.
Andra planeringsmötet
Andra spiketiden
Refaktoring, minskning av antalklasser underlättar.
Andra laborationen
Varvlopp påbörjad.
Story 6 “gick åt helvete” då varvlopp påbörjats innan den var
färdig.
Release 1 fungerade ej på kundens Mac.
Tredje planeringsmötet
Review av datastrukturen, avgörande design diskussion.
Tredje spiketiden
Refaktoring av Datastrukturen.
ANT skript testat.
Coachen tvingar oss att göra bättre spike genom email.
Tredje laborationen
Varvlopp avklarat.
Lärt sig stänga evighetstester dvs undvika en eclipse krasch.
Byte till ny datastruktur.
Release 1b, kunden kunde för första gången köra systemet.
Testskriving ökar.
7
4
Slutsatser
Studiens resultat visar på att det går att använda retrospektiva övningar på XP-projekt. Övningarna måste dock anpassas till de kortare iterationscyklarna. Därför måste nya lättviktiga
metoder utvecklas. Detta försöktes i studien göras genom enkätundersökningen. För att få
prova på och anpassa en traditionell retrospektiv övning valdes även “skapa en tidslinje”[1] ut.
Alla projektgrupper har behov av att förbättra sitt arbete, vilket medför att de retrospektiva
metoderna alltid har en plats. Dock är enligt min mening XP med övningar som “Just Rules”
betydligt mer öppen för förändring under projektets gång. Man uppmuntras att ändra sådant
i metodiken som inte fungerar. Det är en av grundpelarna i metodiken. Traditionella tyngre
projekt metodiker är inte lika flexibla. Därför har projektretrospektiver ett ännu större värde
när dessa metodiker används. Det är kanske den enda chansen att identifiera fel i arbetssättet
eller gruppsammansättningen. När en tung metodik tillämpas blir det antagligen alldeles för
omständigt att ändra tillvägagångssättet under projektets gång. Projektretrospektiven ger
möjligheten att mellan två projekt identifiera problemen och anpassa metodiken.
Projekt retrospektiver i XP gör nytta på ett annat sätt än i traditionella projekt. De
tar mer karaktär av en påminnelse till projektmedlemmarna att vara uppmärksamma på
helheten, att visa uppskattning när något är bra och att de är ansvariga när något inte
fungerar.
När man använder en agile utvecklingsmetodik är det viktigt att behålla de agila traditionerna [6] i alla steg i utvecklingen. Detta är viktigt för att metodiken skall kunna behålla
sin trovärdighet. Retrospektiver i XP-projekt måste alltså anpassas till iterationens längd.
De får inte bidraga till att göra processen trögflytande. Min personliga uppfattning är att
projektretrospektiver av bantad karaktär har en plats i iterations cykeln även i XP-projekt
med korta iterationer till exempel det som studien utfördes på. De bidrar på ett organiserat
sätt till att projektmedlemmarna stannar upp och reflekterar över sitt eget arbete. Denna
typ av reflektion och granskning av det egna arbetet uppmuntras redan inom XP, i practices
som: “Refactoring”, “Simple design” och “Just Rules”. Dessa leder bland annat till refaktoring
av kod med dålig lukt samt till att regler som uppenbarigen inte fungerar, byts ut. De mikroretrospektiver som testats i studien skall bidraga till att dåliga lukter i koden samt problem
med projektmetodiken upptäcks ännu tidigare och undersöks på ett mer systematiskt sätt.
På så sätt kan de bidraga till effektivare arbete och högre kodkvalité.
5
Vidare utvecklings möjligheter
Det skulle vara intressant att prova retrospektiva metoder på ett större XP projekt där
iterationerna är så pass långa att man till varje iteration har råd att lägga några timmar
på att göra en iterationsretrospektiv. Då skulle det bli tid till att prova några fler olika
retrospektiva övningar. Det skulle också bli tid till att utveckla nya XP anpassade övningar.
En retrospektiv övning som enligt min mening skulle göra sig bra i ett lite större XP projekt
är “Definiera framgång” [1] vilken går ut på att få projektmedlemmarna att uppskatta det
som gått bra i projektet, oavsett hur lite det är. Denna övning skulle med fördel kunna
plockas fram efter en extra jobbig iteration för att få projektgruppen att komma tillbaka i
spåret inför nästa iteration. En annan övning av intresse kan vara “Session utan Managers”
[1]. Vilket i ett XP projekt skulle motsvaras av session utan coacher eller kunder. Precis som
ovan nämnda övning är detta inte en övning som skall användas regelbundet utan bara en
som tas i bruk om det finns misstankar om problem med kommunikationen mellan ledning
och utvecklare.
Jag har fått förslaget att lägga in en ämnesintroduktion, till projektretrospektiver i form
av en spike i början av projektet. Detta tycker jag låter som en utmärkt idé särskilt i projekt
av lite större karaktär än det som studien genomfördes på. Då skulle projektretrospektiverna
få en riktigt bra chans att komma arbetet till nytta eftersom projektmedlemmarna skulle
vara ordentligt insatta i ämnet och dess syfte.
8
Referenser
[1] Norman L Kerth. Project Retrorspectives
a handbook for team reviews. Dorset House Publishing 2001
[2] Marek Leszak, Dawayne E Perry, Dieter Stoll. Classifications and evaluation of defects
in a project retrospective. Journal of Systems and Software 2002.
[3] Jonathan Rasmusson. Introducing XP inte Greenfield projects, lessons learned IEEE
Software 2003.
[4] Jutta Eckstein. http://www.jeckstein.com Jutta Eckstein 2003.
[5] Kent Beck. Embracing Change with Extreme Programming Kent Beck 1999.
[6] Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
Mark Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern,
Brian Marick, Robert C. Martin, Steven Mellor, Ken Schwaber, Jeff Sutherland, Dave
Thomas. The Agile Manifesto Agile Alliance 2001.
9
Bilaga 1 - Enkät från planeringsmöte 2
• Nämn och motivera två eller flera saker som du tyckte var bra
med under långlaboration 1.
• Nämn och motivera två eller flera saker som du tycker borde
förbättras från långlaboration 1.
• Vad innebär XP-practicen “Simple design” för dig?
• Var det någon/några XP-practice som du tyckte saknades under långlaboration 1?
• Var det någon/några XP-practicar som du tyckte överdrevs under långlaboration 1, motivera varför?
10
bilaga 2 - Enkät från planeringsmöte 3
• Nämn och motivera två eller flera saker som du tyckte fungerade bättre under långlaboration 2 jämnfört med laboration 1.
• Nämn och motivera två eller flera saker som du tycker borde
förbättras från långlaboration 2.
• Var det något som du upplevde som en “flaskhals” under långlaboration 2? Förslag på åtgärder för att undvika denna i framtiden?
• Var det någon/några XP-practice som du tyckte saknades under långlaboration 2?
• Har du några reflektioner eller åsikter om arbetsformen och
grupparbetet som du tror skulle vara värdefulla att dela med
resten av gruppen?
11
bilaga 3 - Instruktioner till “skapa en Tidslinje”
A
Syftet
Att skapa en tidslinje ger alla projektmedlemmar möjlighet att lägga sina upplevelser till
projektets kollektiva historia.
Detta ökar förståelsen av allt som hänt under projektet. Vidare ger det projektmedlemmarna
träning i att granska projekt och i att identifiera “saker som man måste lära sig” för att bli
bättre. En tidslinje ökar kort och gått förståelsen av händelseflödet och dess konsekvenser.
B
Tillvägagångssätt
1. Gå ihop 3 eller 4.
2. Identifiera viktiga händelser, sådant som skall nämnas är alla story’s som någon i gruppen gjort. Annat som skall tas upp är sådant som ni tycker varit viktigt från de olika
momenten till exempel nya saker som ni gjort som underlättat arbetet eller problem ni
haft. Alla händelser som påverkat projektet bör tas upp.
3. Identifiera start(tex lab1 middag) och sluttid (slutet av lab 2) för händelserna och gör
ett händelsekort av en etikett med start sluttid samt namn (tex story 9 varvlopp).
Placera på tidslinjen.
4. Studera tidslinjen
5. Identifiera problem. Vad ledde till vad. Orsaksförlag? Hur skall man göra istället?
6. Vad har vi lärt oss av detta?
7. Om coachen är nöjd, ät kex.
Tackar för din medverkan i min djupstudie!
12