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
