Bygga broar Skapa en stabil grund som förstagångscoach

Bygga broar Skapa en stabil grund som förstagångscoach Oscar Lundh, D02 (d02ol@efd.lth.se) Mats Wilson, D02 (d02mwi@efd.lth.se) 2005-02-22

Sammanfattning Att träda in i rollen som coach för första gången väcker många tankar och skapar viss osäkerhet. Det är inte ovanligt att det förekommer frågeställningar så som hur man fångar en grupps uppmärksamhet, undviker fatala misstag och skapar en god sammanhållning inom gruppen. En stabil grund ger framtida coacher en möjlighet att hantera problem med en ökad självsäkerhet och framförallt på ett bra tillvägagångssätt. Med vår erfarenhet som lagledare har vi reflekterat över de förberedande momenten som erbjuds i kursens inledande fas. Tanken med djupstudien är att erbjuda blivande coacher en vägvisare att ha med sig både under de inledande momenten och även under projektets gång. Djupstudien går genom moment för moment och beskriver dess roll i projektet, hur de användes, vad som saknades och hur de tillämpades praktiskt. Det är tydligt att alla moment inte är lika centrala och genom våra egna erfarenheter skildrar vi vilka delar som var betydande förettlyckatgenomförande av projektet.

Innehåll 1 Inledning 2 1.1 Tankar och funderingar....................... 2 2 Att förbereda sig 2 2.1 FIRO................................. 2 2.2 Tracking................................ 4 2.3 Konfigurationshantering....................... 4 2.4 XP-metodiken............................. 5 3 Iterationer och Planeringsmöten 6 3.1 Grunditerationen (Iteration 0)................... 6 3.2 Planeringsmöte1... 7 3.3 Iteration 1............................... 8 3.4 Planeringsmöte4... 8 3.5 Iteration 4............................... 9 4 Releaser 9 4.1 Första releasen............................ 10 4.2 Andrareleasen... 10 5 Problem och åtgärder 11 5.1 Återkommande konflikter...................... 12 5.2 Programmeringsrelaterade problem................. 12 6 Coachens reflektioner 13 1

1 Inledning Studien fokuserar på hurförstagångscoacher kan gå tillväga för att skapa en stabil grund till ett bra projekt. Vad man bör tänka på, hur man bör handla i vissa situationer och vilka hjälpmedel som finns för att underlätta coachandet. Studien behandlar till största delen coachning för grupper inom XP-metodiken men kan även till viss del användas av projektledare och coacher inom andra områden. Artikeln lyfter fram de olika frågeställningar och osäkerheter vi hade, men även de erfarenheter som erhölls både före och under projektets gång. Det sker ständiga reflektioner i texten och avslutningsvis visas våra allmänna reflektioner. Artikeln är även baserad på andra coachers erfarenheter. 1.1 Tankar och funderingar Texten bygger mestadels på våra erfarenheter och reflektioner till vårt eget coachande. Vad kunde vi ha gjort bättre och på vilket sätt? Hur tänkte vi innan projektet startade och hur det blev det i slutändan? Djupstudien kommer även ta upp lite av de erfarenheter som andra coacher erhållit under kursens gång. 2 Att förbereda sig Många känner sig väldigt nervösa och osäkra inför rollen som förstagångscoach medan andra är lugna, det enda man kan säga med säkerhet är att det finns en uppsjö medförväntningar inför arbetet som coach. Så var det naturligtvis i vårt fall också, ena stunden kände man sig osäker, för att strax därefter slappna av och bli lugn. Man funderade väldigt mycket och det var svårt att förstå hur man skulle vara som coach. Nyckelordet här är förberedelser. Genom att förbereda sig så kanmanhjälpa sig själv att bli en bra coach. I vårt fall fick vi hjälp att träda in i rollen som coach genom sju veckor av inledande moment som skulle hjälpa oss att bli bekväma i den nya ledarrollen. En av de viktigaste delarna var diskussionerna oss coacher emellan samt de erfarenheter vi erhöll från tidigare coacher tack vare djupstudierna. Nedan presenteras några av de inledande momenten vi fick presenterade för oss. 2.1 FIRO Will Schutz, en amerikansk psykolog, utvecklade en teori, vid namn FIRO 1 som beskriver de faser som människor genomgår vid bildandet av grupper. Han beskriver det med tre huvudfaser, tillhöra, rollsökning och öppenhet. Det sker ofta hopp mellan faserna exempelvis så kan öppenhetsfasen gå tillbaka till tillhörandefasen om nya individer kommer till gruppen. Det är som coach lätt att identifiera dessa faser, det är även bra att låta dessa faser utvecklas och inte 1 Fundamental Interpersonal Relationship Orientation 2

försöka förhindra dem allt för mycket och placera dem en fas tillbaka i tiden. Gruppen behöver genomgå detta för att bli starkare. Figur 1: FIRO-modellen, Källa: Ugil Konsult Första fasen, tillhöra. Personernabörjar känna av stämningen inom gruppen. De är osäkra på sin roll och vågar därför inte söka konflikter. Fasen uppkommer då gruppen sätts samman eller då nya individer kommer in i gruppen. Frågor som kan uppkomma kan vara, är jag accepterad? Vill jag vara med och får jag vara med? Fasen består av osäkerhet hos gruppmedlemmarna. Innan fasövergången såbörjar gruppen kommunicera och individerna är mer sammansvetsade men håller sig ändå undan till en viss del från konflikter, man kan se det som gemytlighetsfasen. Andra fasen, rollsökning. Vadsomär utmärkande är att gruppen börjar fördela ut roller, någon försöker skaffa en ledarroll eller försöker styra gruppen. Deltagarna börja ta konflikter och försöker påverka varandra. Även små uppror uppkommer. Vanliga frågor är, vem är ledaren? Hur stort inflytande har de? Vid allt för stora diskussioner kan det vara bra att som coach agera bollplank och försöka reda upp problemen. Coachen bör förklara att de tillsammans utgör ett team samt att coachen är den som har ledarrollen. Även i vårt fall upplevde vi denna fas och genom att vi observerade mer än angrep situationen erhöll vi en starkare grupp. Tyvärr minskade vår auktoritet lite men det var det väl värt. Tredje fasen, öppenhet. Innan sista fasen händer det oftast att deltagarna måste ta sig igenom en övergångsfas vid namn idyllfasen, vilket ofta uppkommer efter en stor konflikt. Resultat gör oftast att deltagarna känner sig befriade och de utvecklar en gruppidentitet. Sista fasen kan också kallas för samhörighetsfasen, då man har en relativt fungerande grupp. En grupp som kan hantera konflikter då de uppstår, öppet delge varandra idéer, känslor, åsikter och feedback. Vanliga frågor, hur stor öppenhet är tillåtet? Hur starka känslor kan jag visa? 3

2.2 Tracking Tracking används till största delen för att följa projektets utveckling. Ett verktyg som är bra att använda eftersom det kan öka motiveringen hos teamet samt användas av projektledningen som en översikt för att studera hur arbetet förhåller sig till den uppsatta planen. Det finns olika sätt att föra samman trackinginformation, samt att göra informationen visuell och lättöverskådlig. Det kan åstadkommas genom att skapa diagram eller liknande, exempelvis över vilka storys som är klara i ett XP-projekt. Det kan även vara bra att använda verktyg som gör det möjligt för utvecklarna att editera informationen vart efter de känner sig bekväma in i proceduren med tracking. Om resurserna tillåter kan en speciell tracker användas, en person vars huvudansvar är tracking, det går även bra att som coach ansvara för trackingen. Detta beror såklart på projektets storlek, i vårt fall ansvarade coachen för det arbetet. Figur 2: Förslag på visualisering av tracking information 2.3 Konfigurationshantering Att kunna följa utvecklingen av programmet och att dela med sig av sin källkod är en självklarhet när man arbetar i lag. XP-metodiken uppmuntrar och stödjer konfigurationshantering, dock kan det nämnas att det inte finns några krav på det. Att versionshanteringen i det här specifika projektet sköts med hjälp av CVS 2 är inget konstigt. Det är det klart vanligaste systemet när man utvecklar större projekt. Eftersom utvecklarna detta året har fått en grundlig genomgång av Eclipse var det ett naturligt steg att använda detta IDE 3 som ett gränssnitt mot CVS:en. 2 Concurrent Versions System - system för versionshantering 3 Integrated Develloping Enviroment 4

Att coacherna är väl insatta i versionshantering och konfigurationshantering i allmänhet är väldigt viktigt. När projektet väl startat ska ingen onödig tid behöva gååt till att förstå ochförsöka få igång verktygen. Speciellt inte när det är så lätt att undvika. Det finns en uppsjö material och guider till Eclipse och CVS och vi såg det som en själklarhet att man läser in sig på det. Till sist vill vi betona vikten av att sätta sig dagen innan första iterationen och verkligen se till att allt fungerar som det ska. Får inte coacherna igång programmet ska man inte förvänta sig att utvecklarna heller får det. 2.4 XP-metodiken Hur realiserar man XP-metodikenidetegnateamet?Detsomär svårt med rollen som coach är just vägningen mellan produkten och den metodik som används. Oftast går detta hand i hand, det vill säga, med en fungerande metodik får man bra produktkvalité. Kursen riktar sig först och främst mot XPmetodiken, något som kan vara svårt att förmedla då utvecklarnagärna lättar på metodiken för att hinna fortare fram i produktionen. Det delmoment som vi hade svårast att nå ut till utvecklarna med var test-first. De hade tendensen att vara ögontjänare, då vi coacher tittade på så fungerade det utmärkt men då vi inte tittade användes metoden inte lika effektivt. Orsaken till detta kan vara det ansvar utvecklarna kände mot kunden, de ville hinna med alla de storys kunden hade tilldelat oss. Vi insåg detta och tog upp en diskussion med gruppen nästkommande planeringsmöte. Här följer några delmoment i XP-metodiken ur vår synvinkel i projektet. Test-first Genom att använda sig av testdriven utveckling har man alltid en fungerande kod. Tyvärr var det svårt att få utvecklarna att inse metodens syfte. Som coach är det viktigt att vara vaken på ensådan inställning och leda gruppen på rätt håll, antingen genom att ta ett stående möte och diskutera problemet omedelbart eller ta upp en diskussion på nästa planeringsmöte. Det är viktigt att hela gruppen följer metodiken, annars fallerar hela metodikens syfte och det är lätt att hela projektet drar ut på tiden eller misslyckas. Parprogrammering Arbeteipar,där den ena är förare och den andra passagerare ger ett aktivt utvecklande och genom byten mellan de olika paren sprider man kunskapen i teamet. Byten mellan förare och passagerare skall gärna ske naturligt till exempel då föraren är trött eller sitter fast, där passageraren kan komma in med nytt blod och nya infallsvinklar. Detta gäller även vid parbyten, byten kan även ske inom vissa tidsintervall eller då enstoryär klar. Utvecklarna hade en mycket positiv inställning till detta. Som coach är det viktigt att se till att byten sker frekvent och försöka sträva efter att få gruppenattbytasjälvmant. Refaktorisering Att koden hela tiden håller en hög standard är viktigt. Det kan åstadkommas medenkodsomär enkel, ej duplicerad, inga metoder eller klasser som är för långa, självförklarande variabler samt metoder och så vidare.enbrametod för att erhålla detta är att tidigt ta upp momentet med gruppen och tilldela vissa deltagare speciell utlagd tid för de större modifikationerna. Refaktorisering 5

bör även ske i mindre omfattning till exempel vid iterationerna då en mindre refaktorisering kan underlätta påbörjandet av en ny story. Tänk på atthålla en god kommunikation i gruppen för att undvika problem i form av mergekonflikter. Collective Code Ownership IXPäger alla koden, ansvaret ligger på samtligas axlar. Som coach behöver man vara uppmärksam så att det inte uppstår situationer där utvecklare inte vågar ändra i koden. Genom frekventa samtal med gruppen där man ställer frågor om hur deltagarna upplever det samt om de vågar ta ansvar för koden. Genom att föra en öppen dialog kan man minska på rädslan vid ändringar och skapande av koden. I vår grupp hade vi ett fåtal sådana problem, något som åtgärdades genom diskussioner på planeringsmötena. Då man sitter och diskuterar i grupp kan det ibland svårt att som ensam person uttrycka sina åsikter, då kanman som coach ge förslag på individuella samtal. Kund på plats Oftast i större XP-projekt har man en kund som finns på plats hela tiden. I detta projektet hade kunden begränsade möjligheter till besök. Enklaste sättet vid en sådan situation är att samla ihop samtliga frågor som kan tänkas dyka upp och vänta tills kunden kommer på besök. Ett annat alternativ som fungerade bra var mail, de frågor som kan ställas genom skrift skickade vi coacher vidare till kunden. Samtliga teammedlemmar tyckte att det fungerade bra med dessa begränsade metoder. 3 Iterationer och Planeringsmöten Hur ser då iterationer och planeringsmöten ut? Hur förbereder man sig inför dessa moment? Dessa frågor kommer att besvaras till en viss del nedan genom ett urval av de möten och iterationer vi hade i vårt projekt. Urvalet är gjort genom att studera de första momenten hur det såg ut en bit in i projektet och dess slutskede. 3.1 Grunditerationen (Iteration 0) Hur skall man skapa den bästa möjliga grund inför kommande iterationer? Det är naturligtvis omöjligt att ge ett exakt svar på detta, det beror mycket på projektet i sin helhet. Det är viktigt att skapa ett programskelett som är anpassat efter projektets storlek och antalet deltagare. En iteration som är lättförståelig med en kod som styr utvecklingen av projektet åt rätt håll är det man bör eftersträva som coach. Vår tolkning av lagom mycket kod bestod av en design där alla parprogrammerare hade var sin del att arbeta med inför kommande iteration, en design som var enkel att visa och förklara för oss coacher. Genom att använda en självförklarande kod som är anpassad efter deltagarnas tidigare erfarenheter kan de snabbt sätta sig in i arbetet. Om grunditerationen blir för komplex, kan det vara svårt för utvecklarna att sätta sig in i koden och 6

kan till och med skrämma utvecklare till en viss del, om ribban på kodenär allt för hög. Bättre att utvecklarnas erfarenheter får växa med koden. Tänk på att Iteration 0 skapas som grund för hela projektet. Några viktiga punkter vid grunditerationen är följande: Alla skall vara aktiva Skapa en design som ger samtliga parprogrammerare arbete, dela upp paren så att de inte arbetar på samma ställe i koden. Självförklarande kod Koden bör vara enkel att förstå, då personer oftast har olika utgångspunkter i sina kunskaper. Det skall vara en kod som är strukturerad och lätt att sätta sig in i. Enkel design Genom enkel design underlättar ni inte bara för utvecklarna utan även för er själva, eftersom det blir enklare att förklara dess uppbyggnad. Anpassad efter projektet Man bör ha i åtanke att anpassa iterationen efter projektets storlek, antal deltagare och dess kunskaper. 3.2 Planeringsmöte 1 Första mötet med gruppen, teammedlemmarna är lika osäkra som oss coacher och alla undrar hur de närmsta veckor kommer se ut. Vi coacher hade i ett tidigt skede redan bestämt oss för hur vi skulle hantera det första planeringsmötet. Tanken var att inte sitta med ett manus och läsa innantill. Istället hade vi en mycket enkel punktlista med det viktigaste som vi behövde ta upp under mötet. Förhoppningen var att vi skulle försöka skapa en öppen diskussion med gruppen och diskutera deras frågeställningar och hur de kände inför XP-kursen. Detta fungerade väldigt bra och vi tror att det bidrog till en avslappnad och öppen stämning i gruppen. Motsatsen till denna tekniken hade varit att vi hade haft en föreläsning för dem i 2 timmar och sedan avslutat mötet. Det finns främst ett par saker som vi vill belysa från första planeringsmötet, som fungerade riktigt bra. Dels öppnade vi mötet med en simpel namnlek. Detta gjorde att alla från de första minuterna kunde namnet på alla deltagare. Naturligtvis underlättar detta inte bara för oss coacher, utan även för deltagarna som får lättare att starta diskussioner med sina programmeringspartners. För det andra delade vi upp grupperna i två lika stora delar till planninggame. Tanken var att vi kunde sparka igång avslappande diskussioner om vi inte var så stora grupper. Det tycks fungerat över förväntan. Vi vill dock påpeka att vi hade väldigt tur och fick en öppen och social grupp, så viharintebehövt kämpa för att få en gemenskap, den var där redan från första mötet. Vi avslutade planeringsmötet med en lek kallad Röd och Svart. Utan att gå in på detaljer och regler kan det nämnas att det är ett spel som eftersträvar att visa hur samarbete mellan deltagarna bidrar till ett bättre slutresultat än om man jobbar egoistiskt. Dock får vi vara realistiska och även om spelet inte bidrog till en upplysning av sällan skådat slag, så bidrogdetmedsäkerhet till ett avslappnat klimat. 7

3.3 Iteration 1 Det är nu projektet börjar på riktigt ochdå man som coach får använda sig av förberedelserna praktiskt. Man kan se Iteration 1 som ett stadie då utvecklarna försöker känna av läget hos varandra, fasen tillhöra enligt FIRO-modellen. Eftersom iterationen varade i åtta timmar så kunde man se förändringarna inom fasen, stämningen lättades upp vart efter och gruppen började svetsas samman. För att få ensåbraiteration som möjligt så behövs noggranna förberedelser, exempelvis genom att ha ett schema över dagens inplanerade moment. Utvecklarna är mycket uppmärksamma på coachen vilket ger en utmärkt möjlighet att praktisera de modeller man vill ha in i projektet, i vårt fall var det XP-metodiken. Man kan redan i detta stadie se utvecklarnas ansvar jämtemot kunden, en stor produktkänsla, de vill komma sålångt med koden som möjligt. Det är viktigt att man som coach ser till att metodiken efterföljs så att det inte bara blir en kamp mot storys. En viktig sak som man kan ha i åtanke är att försöka få utvecklarna att kommunicera mellan varandra. Några viktiga punkter att ta med sig till iterationen är följande: Planering Kommunikation Lyssna Ställ frågor Motivera gruppen Tracking Metodiken Detaljerad plan över iterationens olika moment. Mellan samtliga inblandade, ett förslag är att coacherna går bort en stund, då överlämnas ansvaret till utvecklarna och de måste kommunicera mellan varandra. Var aktiv och lyssna på deltagarna och reflektera. Försök ställa intelligenta frågor till exempel fråga hur lång tid en story kommer att ta och varför, eller hur det känns osv. Det är viktigt att ge beröm för att sporra deltagarna, man kan även använda sig av belöningar. Även genom visualisering av tracking informationen så kanmanöka motivationen. Genom att hela tiden ha en öppen dialog med gruppen och diskutera hur det går och hur lång tid de uppskattar att vissa storys kommer att ta så håller sig trackern uppdaterad. Detta är ett viktigt arbete både för gruppen och för projektledarna så attman kan visa upp resultatet. Glöm ej att använda metodiken. I vårt fall XP-metodiken, användarna skall använda sig av moment som test first, parprogrammering, reglerad arbetsdag osv. 3.4 Planeringsmöte 4 Halvvägs in i projektet. De tidigare planeringsmötena har fungerat på ungefär samma sätt och detta mötet är inget större undantag. Vi vill passa påattnämna att inför varje planeringsmöte träffas båda coacherna och diskuterar mötet, det vill säga vad som skall tas upp och vilka XP-fokuseringar som är aktuella. Eftersom iterationerna har flutit på relativt bra och vi ligger långt fram om man ser på implementerade stories, så tog vi beslutet att vi under de kommande iterationerna ska lägga majoriteten av tiden på attfåettså stabilt program som möjligt. Tyngdpunkten las därför på refaktorisering, källkodsdokumentering och buggfixning. Eftersom vi hela tiden har jobbat för att få en självständig grupp och därmed avsiktligt minska vår inflytande över gruppen, la vi fram ompriori- 8

teringarna som ett förslag till gruppen. Detta diskuterades sedan igenom under en dryg halvtimme innan vi hade detaljer på hurmånga timmar som skulle läggas på vad. Som en sammanfattning av debatten kan det nämnas att vi kom fram till att 50 procent av tiden skulle läggas på nya stories och resterande halvan på attgöra programmet säkrare och mer pålitligt. Denna veckan hade vi en trevlig fika stund under iteration 3. Det var uppskattat av alla och de flesta tyckte att det gav en behövlig paus på eftermiddagen. Med detta i åtanke erbjöd sig en gruppmedlem att frivilligt ta med sig fika. Att ta med fika jämställs med en 2 timmars spike. Som coach balanserar man hela tiden mellan att hålla sig i bakgrunden och stå framme vid rodret. Trots att man konstant jobbar för att gruppen skall bli självständig och ta initiativ på egetbevåg så måste man komma ihåg att coachen fungerar även som en chef, det gäller att behålla en viss auktoritet under projektets gång så attmankanryckainochstyrauppsakeromdetskulle behövas. Redan under förra iterationen har vi märkt av att gruppen har blivit väldigt självständig och klarar alla problem själva med hjälp av diskussioner, teammedlemmarna sinsemellan. Detta naturligtvis något man hela tiden eftersträvar, men med det nya ansvaret har vi sett hur XP-praxisen har tynat bort med tiden eftersom vi inte längre står över axeln och tjatar om hur viktigt det är. I ärlighetens namn kan det nämnas att Test First var den första praxisen som sållades bort av gruppen. Som coacher vill vi inte ge order, det är att hoppa tillbaka ett par steg. Istället valde vi att ta upp problemet med Test First medgruppenochdiskuterahurvi kunde bli bättre på det.nuär det att vänta till Iteration 4 för att se resultatet. 3.5 Iteration 4 De största skillnaderna mellan tidigare iterationer var gruppens utveckling och programmets komplexitet, vårt team hade utvecklas mot fasen öppenhet i FIROmodellen. De var väl sammansvettsade men hade börjat känna sig lite frustrerade över antalet storys, något som förändrades vid nästkommande planeringsmöte då de började se slutet på projektet. Gruppen förde bra samtal och de använde XP-metodiken mer naturligt, som coach innebar detta mindre coachande och mer tracking. Gruppen hade utvecklats ihop med produkten och de kände sig stolta över att vara med i teamet och vad de åstadkommit med. Då de var en aningen frusterade, försökte vi vara lite extra uppmärksama mot gruppen och vi försökte uppmuntra gruppen genom fika och beröm. Iterationen påminde mycket om tidigare iterationer, vilket gör det möjligt att följa samma viktiga punkter som tidigare angetts. 4 Releaser Precis som iterationerna så förändrades releaserna ju längre in i projektet man kom, deltagarna började ta mer och mer ansvar och rollen som coach minskade i samband med detta. Tanken är att coacha utvecklarna så att de tar mer och mer 9

ansvar själva. Till en början skapades releaserna för hand men övergick sakta mot automatisering. Vad utgör då en bra release? 4.1 Första releasen Lugnet före stormen är en mening som säger en hel del om vår första release. Dagen började lugnt och självförtroendet stod på toppinför överlämnandet av den första version av produkten. Ju längre dagen gick och ju närmare release vi kom desto mer förändrades situationen hos deltagarna, de började att känna sig mer och mer stressade. En metod att minska stress under en release är att använda en checklista över vad som skall göras. Att försöka automatisera releasen fungerar utmärkt vid en stressad deadline, något som realiserades till nästkommande release. Bestäm gärna en tid då allt skall vara klart inför byggandet av releasen och håll på den, det vill säga försök att inte slänga in ny funktionalitet om ni inte är riktigt säkra på att ni kommer klara deadlinen. En bra release utgörs inte bara av en nöjd kund utan även ett team som har gott mod och inte är skrämda inför kommande releaser. Några viktiga punkter att ta med sig till releasen är: Stress Det är lätt att göra misstag såförsök minska påstressen. Checklista Genom att använda en lista så kannisehurlångt ni har kommit i releasen, sen minskar man risken för att glömma något viktigt. Automatisering Börja tänk på automatisering, minskar på stressen. Deadlines Uppmuntra Håll på deadlinen, bestäm en tid då releasen skall byggas. Glöm ej att berömma deltagarna speciellt efter en lyckad release, ta en paus och fira, gå ochfikaellernågonting. 4.2 Andra releasen En automatiserad release kommer att förenkla den andra releasen avsevärt, här ingick det i vårt fall en release av teknisk dokumentation, manual, källkod och program. Själva releasen i sig påminner om en vanlig release, men eftersom arbetsbördan är större så ökar även stressen hos teamet ju närmare deadlinen närmar sig. Vid det här läget har gruppen genomgått några av de faser enligt FIRO och de är väl sammansvetsade, något som även kommer påverka coachningen. Man får mer frekvent ta på sig hatten som tracker än som coach. Även om gruppen fungerar bra så kan situationen bli ganska förvirrande hos utvecklarna då klockan tickar på ochdetär dags för release. Det är viktigt att som coach kontrollera checklistan och informera gruppen om de utsatta tiderna, ett förslag är att tydligt visa tiderna på entavla. Eftersom iterationen i sig inte skiljer sig allt för mycket från de andra så kommer vi här ge några få råd inför releasen. 10

Automatisering Stress Checklista Deadlines Uppmuntra Automatisera releasen, exempelvis genom ANT eller något annat byggnadsverktyg, detta kommer skapa extra tid som gruppen kan utnyttja. Precis som i första releasen så är det viktigt att undvika allt för mycket stress, kommunicera och använd de hjälpmedel som finns. Använda ett schema över iterationen som ni kan bocka av och se hur långt ni har kommit, minskar risken för att glömma något viktigt. Använd gärna en stor och tydlig tavla med de utsatta tiderna och momenten. Håll på deadlinen, bestäm en tid då releasen skall byggas. Glöm ej att berömma deltagarna speciellt efter en lyckad release, ta en paus och fira, gå ochfikaellernågonting. 5 Problem och åtgärder Gruppen går från xp-metodiken för att hinna med fler stories. Till exempel, Test First tillämpas inte längre Attallaiteametköper xp-metodiken rakt av är att begära för mycket. Speciellt folk med viss programmeringsvana tycks ha svårt följa den. Naturligtvis för att man som programmerare redan har ett invant mönster som fungerar bra. För att förhindra detta har vi betonat på varje planeringsmöte att i det är xp-metodiken som är det viktiga i kursen, inte hur många stories man implementerar. Naturligtvis är det svårt att sälja in argumentet när det inte fungerar påsåvis i arbetslivet. Så omdetkrävs har du rätt att (och bör) kräva av utvecklarna under iterationerna att de inte får börja arbeta på enstoryomde inte kan visa upp att de har gjort ett antal testfall först. Vissa teammedlemmar har svårt för att våga göra sig hörda Det här är ett problem som kanske är det svåraste att åtgärda. Att coacherna redan från första dagen arbetar för att skapa en gemensamhet i gruppen är bara ett steg i rätt riktning. Ibland kan det även krävas en puff i rätt riktning. Vi löste problemet genom att varje gång någon hade en fråga till oss coacher så samlade vi hela gruppen och förklarade att vi det var dags för ett designmöte, varvid personen fick förklara sin fråga för gruppen. De utvecklare som kunde svara på frågan hjälpte sedan till att lösa problemet. Detta var ett synnerligen effektivt sätt att tvinga alla i gruppen att diskutera med varandra. Motivationen tycks sakta dala bort under projektets gång Detta är inget stort problem, utan rätt vanligt och naturligt. Hur som helst, för att ändå göra det bästa av situationen försökte vi väcka tävlingsinstinkten i våran grupp. Vi klargjorde att det var en självklarhet att vi skulle vinna loppet runt sjön-sjön sista veckan. Emellanåt jämförde vi hur det gick med de andra lagen. Ett exempel som är värt att nämnas är att vi var väldigt dåliga på att skriva test de första iterationerna. Efter att ha visat att vi hade minst antal test av alla grupper, så kunde man snart hitta femton, tjugo nya test i CVSen. Naturligtvis får man hålla den här tävlingsuppmuntran på en lagom nivå, vi vill inte att varken vår grupp, eller någon annan ska bli stressade eller göra undermålig kod. 11

5.1 Återkommande konflikter Återkommande konflikter är något som tar onödigt mycket tid.här gäller det för en coach att vara uppmärksam, är det till exempel två utvecklare som inte kan jobba tillsammans ska det inte upptäckas efter tredje gången eller fjärde gången, utan helst redan vid första konflikten. Ett sätt att hantera vanligt förekommande konflikter är att se varningstecken och handla utifrån det. Det är ingen idé att testa fyra gånger för att se om två utvecklare som brukar hamna i luven på varandra har lärt sig att jobba tillsammans. Det tar alldeles för mycket tid från projektet och energi från gruppen. 5.2 Programmeringsrelaterade problem Att gå igenom alla programmeringsrelaterade problem som har dykt upp under iterationernas gång skulle ta allt för mycket tid och plats för att gå igenomhär. Det är dock ett par problem som vi vill belysa som kan bespara gruppen mycket tid om de går att undvika. Det första är den så kallade hjälpklassen. Genom att jämföra med andra grupper och från tiden vi själva var utvecklare så minns man avsaknad av hjälpklassen var en av de direkta anledningarna till att källkoden i slutet såg riktigt taskig ut. En hjälpklass är alltså en statisk klass, som kan påbörjas vid implementering av grunditerationen, där man lägger alla metoder som förekommer i flera klasser och kanske i både klienten och servern. Exempel på metoder som är bra att ha i en hjälpklass är en metod som räknar ut totaltiden mellan två tidpunkter. Hur som helst, hjälpklassen är ett utmärkt verktyg för att hålla borta duplicerad kod och påminner utvecklarna om vikten att tänka på det. Det är värt att nämna den obligatoriska övergången till nätverksstöd. I vårt specifika fall hade vi tur som fick två stycken utvecklare som redan var väl insatta i nätverksprogrammering. För att förbereda övriga gruppen lät vi en av våra nätverkskunniga utvecklare hålla en presentation på 10minuterframmepå tavlan under ett planeringsmöte. Tiden som det tog för utvecklaren att förbereda presentationen räknades av från dennes spiketid. Tanken är att hela gruppen skall känna till hur en nätverkslösning ser ut och vad som behövs göras innan arbete påbörjas. Och precis som i arbetslivet tar man vara på den expertis som finnes, tanken är alltså attnågon av våra näteverksutvecklare hela tiden skall ha ett finger med i spelet vid utvecklingen av dessa nya funktioner. I övrigt, som redan nämnts under Iteration 0 så var vi mycket noga med att se till att det fanns så många klasser att varje programmeringspar kunde jobba på en egen del. Tack vare detta kunde vi undvika väldigt många merge-konflikter i det tidiga programmeringsskedet. Om man pratar med övriga coacher så är merge-konflikter något som har tagit väldigt mycket tid. Så vi betonar igen; se alltid till att ha många små klasser som utför sin specifika uppgift. Under ett planeringsmöte höll en av utvecklarna ett mycket givande föredrag om Bad Smells. Att friska upp minnet för alla utvecklare genom ett kort föredrag på 5 minuter gav faktiskt mycket mer än man kunde hoppas på. Till och med vi coacher fick en liten aha -upplevlse. Det viktigaste som togs upp i föredraget var hur man döper metoder och klasser. Hur viktigt det är att undvika långa 12

metoder och stora klasser. Hur man undviker duplicerad kod. Det vill säga alla de viktigaste enklaste sätten att hålla källkoden ren och snygg. Utöver det har vi kontinuerligt varje vecka satt två utvecklarepå att refaktorisera hela koden. Eftersom åtta spike-timmar försvinner på det så blir det inte lika mycket spikning på veckans stories,men nu i efterhand kan vi med säkerhet konstatera att det var en vinnande strategi. 6 Coachens reflektioner Planering är det bästa förberedelsearbetet en coach kan göra. Genom att skapa en bra kunskapsgrund innan projektets start minskar man den stress och nervositet som kan uppkomma hos coachen. Låt utvecklarna få färdas genom de olika faserna som gruppen upplever, det kommer att stärka dem. Vissa delmoment i metodiken är svårare att förmedla än andra, som test-first. Åtgärder mot detta är kommunikation, exempelvis genom att tidigt föra en öppen diskussion och beskriva de förutsättningar som finns förettlyckatgenomförande av projektet. Om kommunikation inte fungerar som åtgärd vid eventuella avvikelser eller andra problem exempelvis försenade ankomster och så vidare, kan det även vara bra att införa milda straff. I vårt fall fungerade det mycket bra med införande av extra spikes och rapporter, ingen av våra utvecklare ville få extraarbete. I övrigt fungerade XP-metodiken mycket bra inom gruppen. Använd checklistor och trackingverktyg, de kommer underlätta ert planeringsarbete samt förenkla arbetet under iterationerna och möten, samtliga delaktiga kan på detsättet erhålla information om vart ni befinner er i planeringen. Ordet kommunikation dyker frekvent upp i denna rapport, oavsett om det är planeringsmöte eller iteration, ordet har stor vikt. Som coach är det viktigt att lyssna på deltagarna och ge intelligent feedback, försök få igång diskussioner vid behov. Försök hålla humöret uppe hos gruppen, nöjd grupp är lika med nöjd coach och slutligen glad kund. Det behöver inte vara så märkvärdigt utan det kan räcka med en fika eller verbalt beröm. Det är värt att påpeka att coachen finns till för gruppen och inte tvärt om. Coachens arbetsuppgift är att skapa en självständig grupp som klarar att att samarbeta och ta initiativ både på individnivå och tillsammans med hela gruppen. Med detta i åtanke bör man komma ihåg att coachen bör avsiktligt backa undan och ta allt mindre plats allt eftersom projektet fortskrider. I verkliga arbetslivet finns coachen bara på platsibörjan av projektet för att få igång arbetet snabbt och relativt smärtfritt. Slutligen kan vi säga att det var en mycket uppskattad upplevelse att få agera coach. Vi har med denna djupstudie skildrat några av de egna frågeställningarna samt beskrivit de erfarenheter som erhölls. Vi hoppas att denna studie kan hjälpa framtida coacher i deras förberedelsearbete. 13

Referenser [1] Ugil konsult, FIRO http://www.ugil.se/kurser/teori firo.html [2] CoachIsMe: Ledarskap i ett nötskal och några råd om bra coaching. Av Magnus Starseth. [3] Managing XP: Manager, Tracker, and Coach. By William Wake. Utdrag ur boken Extreme Programming Explored, Addison-Wesley, 2002. [4] Principles in Refactoring. Utdrag ur boken Refactoring av Martin Fowler. Addison-Wesley, 1999. [5] Test-Driven Development Patterns. Utdrag ur boken Test-Driven Development, Kent Beck, Addison-Wesley, 2002. [6] Software Configuration Management Practices for extreme Programmin Teams. By Ulf Asklund, Lars Bendix, Torbjörn Ekman. In proceedings of the 11th Nordic Workshop on Programming and Software Development Tools and Techniques - NWPER 2004, Turku, Finland, August 17-19, 2004. [7] Teaching Extreme Programming to Large Groups of Students. By Hedin, Bendix, Magnusson. Journal of Systems and Software, 74(2):133-146 Elsevier, January 2005. [8] Iteration Planning Meeting, etc. Utdrag ur boken Planning Extreme Programming, av Kent Beck och Martin Fowler. Addison-Wesley, 2001. 14