EDA270 ex treme Coaching Djupstudie i ett studentprojekt

EDA270 ex treme Coaching Djupstudie i ett studentprojekt Maxim Machelak (cim04mm6@student.lth.se) E rik Iveroth (dt05ei7@student.lth.se) Lunds Tekniska Högskola 24 februari 2009 Sa m m a nfa t t n i ng Rapporten är en djupstudie i svårigheterna en coach kan stöta på och analyserar dessa utifrån e X treme Programming -principen. V i berör kommunikationsproblem, brister i parprogrammering, undermånig testdriven utveckling och utvecklarnas kunskaper i C VS. Rapporten är en djupstudie i kursen E D A270 - Coaching för programvaruutveckling och genomförs under långlabbarna i kursen E D A260 - Programvaruutveckling i grupp. 1

Innehåll 1 I nled ning 2 2 K o m m u nika t ion 3 3 B rist a n de k u nska p i a t t coach a 4 4 P a r-p rogr a m m ering och dela d ko d 5 5 Test d riven u t veck ling 6 6 C V S so m kon figu r a t ionsm e to d 6 7 Slu tsa tser och fr a m å t blicka r 8

1 Inledning Den här djupstudien behandlar svårigheterna coacher av et t X P-team kan stöta på och försöker samtidigt ge lösningar på dessa. X P-teamet som denna djupstudie rör är et t team på tio personer med varierande erfarenheter av tidigare projekt. Ingen i teamet har tidigare arbetat enligt X P-metoden, men de har under höstterminen läst första delen av den kurs projektet är en del av, vilket motsvarar ungerfär 120 studietimmar. Därmed har det vid projektets början kunnat förutsät tas at t teamet har åtminstone grundläggande kunskaper inom X P-teorin. Som studenter har de flesta relativit liten erfarenhet från större projekt, och saknar därmed inför projektets start mycket av den kunskap rörande intern kommunikation mellan fler personer, vilket har visat sig vara ett av de största problemen. Coacherna i teamet hade på samma sät t ingen tidigare erfarenhet av coachning av et t större team. Den här djupstudien försöker identifiera, förklara och ge förslag på lösningar, för att göra det lättare för framtida förstagångscoacher at t reda ut eventuella dysfunktioner i et t team. Coacherna har under projektets gång identiferat flera problem, såsom avsaknad av kommunikation, dålig eller felaktig kommunikation, problem at t ta till sig X P-metodikens arbetssät t såsom delat kodägande, testdriven utveckling och användandet av et t konfigurationsverktyg. Coacherna har även kommit med förslag på hur, när och varför något av ovannämda problem ska lösas, och vad som kan göras för att undivka att samma sak händer igen. A rtikelns innehåll bestämdes under första långlabben då vi upptäckte hur svårt det egentligen är att coacha. V i hade tidigare ingen erfarenhet av coaching och det var en av de starkaste anledningarna för oss att läsa kursen E D A270. A t t coacha en grupp studenter trodde vi skulle vara relativt trivialt, eftersom uppgifterna var definierade och tillvägagångssät t var beskrivet. Syftet med rapporten är at t försöka identifiera några av problemen som kan uppstå vid coaching och ge förslag på hur problemen kan tacklas. V i kommer identifiera och beskriva följande områden: Kommunikation, bristande kunskap i at t coacha, parprogrammering, testdriven utveckling och C VS som verktyg. A nalysen genomförs på en grupp studenter som läser kursen Programvaruutveckling i grupp (E D A260) av två äldre studenter som redan läst kursen och rapporten är en del av examinationen i Coaching av programvaruteam (E D A270). 2

2 K om munika tion P roble m a t i ken Det mest framträdande och tydliga problemet som vi redan från början fick tackla var hur kommunikation inom teamet fungerade. Att ett sådant problem uppstår är inte alls märkvärdigt. En av faktorerna till det var förmodligen att ingen i gruppen kände någon annan i gruppen. De var alla främlingar för varandra, vilket förvånande oss coacher, som är äldre studenter och redan läst kursen. Det ta gjorde at t lite extra tid fick läggas på teambuilding, men det är bara bra eftersom sådant lönar sig. Y t terliggare en faktor som påverkar kommunikationen var at t samtliga medlemmar i teamet var unga studenter utan tidigare erfarenheter av liknande arbete i grupp. ex treme Programming, X P-metoden, lägger stor vikt på att teamet ska kommunicera fritt och alla utvecklarna ska vara medvetna om vad som händer i den delade koden och vad de andra utvecklarna arbetar med. Förfat tarna observerade at t utvecklarna till en början hade svårt at t själva ta initiativ till at t kommunicera med varandra för att berätta nuvarande status på vad de arbetade med. Det ledde till att flera utvecklare i gruppen saknade överblick på hur systemet såg ut Vad säger X P? X P värdesätter kommunkation inom ett team högt, och är en av nycklarna till et t framgångsrikt projekt. Det också viktigt at t utvecklarna har en god kommunkation med kunden för att kunna leverera en så god produkt som möjligt. H a ntering av p roble m e t Som coacher ansåg vi kommunikationen som grunden för en bra stämning inom gruppen, och även som vägen till ett lyckat projekt. V i började tidigt med att låta medlemmarna lära känna varandra, lära varandras namn och varandras styrkor, det ta för at t underlät ta första långlabben. På långlabben uppmanade vi utvecklarna at t verbalt kommunicera med varandra, speciellt inom et t par. Kommunikationen mellan drivern och navigatorn kändes redan från början naturlig, men för att få paren att kommunicera sinsemellan krävdes det lite speciella taktiker. Möten planerades in. K lockan 10.00 och 15.00 planerade vi in fikapaus, där teamet och coacherna lugnt sat t ner och diskuterade hur projektet gick frammåt, problem som uppståt t och vad som behövde göras. Även mindre pauser togs under utvecklingens gång där två eller flera team samtalade. Why is it hard to learn extreme Programming? [2] tar upp problemet, och anser att det inte går att förutsätta att alla utvecklarna är födda med starka kommunikation- och sociala egenskaper. Det är coachernas uppgift at t lära ut dessa, minst lika mycket som det är at t lära ut de teoretiska och praktiska delarna kring X P-metodiken. Som coach lär man sig mycket av att coacha, men något av det viktigaste, enligt How to E ectively Coach [5] är at t coachen själv lär sig kommunicera bättre och bättre ju mer erfarenhet han får. Detta kan vara lika viktigt för ett projekt som at t utvecklarna lär sig god kommunikation. 3

3 B rist ande kunskap i a t t coacha P roble m a t i ken A t t coacha en grupp studenter verkade inte vara någon större ansträngning, men det visade sig redan under iteration 1 att det var fel uppfattat. Teorin har under hösten bearbetats och studerats. A rtiklar har lästs och diskussioner har alla coachpar deltagit i för at t reda ut svårigheter och begrepp inom coachingpraktiken. Trots denna ansträngning i teorin blev coachingarbetet under iteration 1 lite svårare än väntat. Det blev en något fumlig struktur på vårt arbete under långlabben och teamet kände förmodligen av det ta, vilket kanske ledde till en osäkerhet inom teamet. Men när iterationen väl kommit igång och utvecklarna tilldelats story så flöt arbetet på bättre. V i coacher hade underskattat hur mycket arbete som borde lagts ner inför iterationen och var inte så förberedda som vi borde ha varit. Vad säger X P? X P beskriver en coach som någon som guidar och fungerar som en mentor för ett team. Han bör vara respekterad inom teamet, genom att föregå med gott exempel. Den bästa egenskap en coach kan ha är erfarenhet. Ibland lär coachen ut direkt, ibland lär han ut genom at t själv göra. Han ger tips på hur man kan förbät tra arbetet, och kan fungera som en länk mellan utvecklarna och övre cheferna. H a ntering av p roble m e t Det tycks finnas en oändlig mängd av tekniker och tips till hur en coach bäst agerar. Att coacha är en egenskap som är svår att bemästrar till fullo och inte något som alla kan lära sig. Men teorin bakom coaching verkar vara oberoende av vem som är målguppen; det är samma tekniker och tillvägagångssätt som bör användas för att coacha en grupp utvecklare som att coacha en chef eller V D. A rtikeln The executive as coach [3] nämner olika tips och inställningar som en bra coach bör använda för att vägleda en V D till att arbeta bättre, men det som beskrivs där hade likväl kunnat fungera för en grupp studenter som utvecklar ett javaprogram. Det visar alltså att det är sättet som coachen agerar och beter sig som är det väsentliga, inte vilka som blir coachade. Generellt försökte vi arbete på så sätt att vi lät utvecklarna driva arbetet frammåt själva. V i poängterade på långlabbarna de olika X P metoderna och var relativt restriktiva till att vägleda dem i hur de skall koda och hur de behövde koda för att få klart en story. Det svåra med coachingen är hur man skall lägga upp sit t framträdande. Hur mycket kan man hjälpa utvecklarna? När skall coachen träda in? Hur vägleder man utvecklarna rät t? Richard Hackman och Ruth Wageman analyserar i sin artikel A theory of team coaching hur en coach skall agera och framför allt när en coach skall agera. Enligt dem är det av stor vikt att coacha under rätt tidpunkt. Det verkar finns tre naturliga tidpunkter i utvecklingens cykel; start, mittten och slutet. Det är under dessa tre tider som coachen har störst möjlighet at t påverka; i början ger coachen motivation, under mitten ger coachen konsultation i arbetet och i slutet bör coachen arbeta för att lära teamet nya kunskaper [6]. 4

Det är inte lätt att coacha och det är ännu svårare att vara en bra coach. En god coach är en speciell person skriver David Rohland [5]. Det är en ära och et t viktigt uppdrag som tilldelats dig som coach, men Rohland påpekar även att du gör det inte bara för teamet - utan även för dig själv. Den största fördelen med att coacha är att Du lär dig så mycket av det, Du utvecklas av det! Och vi kan inte annat än att hålla med - det kan vi med erfarenhet säga från våra iterationer. V i författare känner att vi har blivit mycket mer bekväma i coachandet efter et t antal iterationer. 4 Par-program mering och delad kod P roble m a t i ken Par-programmeringen kändes redan från början naturlig; teamet arbetade direkt från start två och två vid varje dator. Men en av de viktigaste praktikerna för delad kod - parbyte - utfördes inte som vi hade hoppats på. Paren kände att det störde deras arbete att byta, och efter första iterationen hade det gjorts i snitt två byten under åtta timmar, vilket var helt för lite. Detta betydde att teamets medlemmar hade dålig överblick över programmets struktur, och var de andra låg i tiden. Många var förvirrade över vilka storys som var implementerade, och vilka som inte var det. Driver och navigator bytte lite oftare, men det visade sig att den starkare programmeraren satt oftare vid datorn än den svagare. Teamet hade dock inga problem att jobba i formen av två och två, vilket enligt andra undersökningar kan vara besvärligt för vissa grupper. K amran Sharifabdi och C laudia G rot har i likhet med oss analyserat en grupp utvecklare som använder sig av e X treme Programming [1]. I deras fall handlar det om erfarna norska utvecklare som har mångårig erfarenhet i programmering, men likväl uppstår där problem inom teamet när de försöker parprogrammera. Vad säger X P? X P uppmanar utvecklarna att programmera i par. Personen som sitter vid klaviaturet - drivern - tänker i detalj på det som kodas just nu, medan personen vid sidan av - navigatorn - har en överblick över programmet som helhet och ser till att drivern är på väg åt rätt håll med sin kod. Det är viktigt att det finns god kommunikation mellan medlemmarna. X P lägger inte vikt på parbyten, men i vårt projekt var det ta en viktig ingerdiens i det dagliga arbetet. H a ntering av p roble m e t Coacherna började med at t ta upp problemet på planeringsmötet, och försökte förklara varför det var viktigt med parbyten. När teamet väl så var övertygat att det var viktigt, så sattes planen i verket. Mål sattes upp - Parbyten ska ske minst varje timme, ett par ska inte sitta med ett problem längre än en timme, driver och navigator ska byta minst var femtonde minut. Resulutatet blev till en början blandat, men när coacherna började lägga sig i parbytenea och positivt uppmana teamet at t byta plats började det till slut fungera. Kommunkationen blev inom teamet bättre, de hade bättre koll på koden och fick en godare överblick över var de befann sig. Par som kände sig stressade genom att ha kört fast i ett problem 5

mådde bättre då de kunde gå över till något annat. totalt sett har medvetna parbyten ofta gjort teamet starkare och bät tre på at t kommunicera. 5 Test driven u t veckling P roble m a t i ken Teamet började direkt vid första iterationen med T D D, men bara efter ett par timmar visade det sig att de flesta gett upp metodiken. Teamet kände sig stressat att fullfölja storysen, och för att hinna klart dem skrevs koden först, och testerna efteråt - det var i alla fall deras egna ursäkter. Men vi tror snarare att det är ren lathet som är största argumentet till att inte skriva tester först. Det tycks inte vara något ovanligt fenomen, även erfarna utvecklare har samma problem beskriver Sharifabdj och G rot i sin artikel om det norska telekomföretagets utvecklare [1]. Intressant är at t deras project managerblev nödgad at t tvinga utvecklarna redovisa sina tester och visa sit t intresse för testerna för at t utvecklarna skulle bli bättre på att skriva dem. V i tacklade problemet på samma sätt med vår grupp och det gav genast resultat i antal tester men även i det ansvar studenterna tog för testerna. Vad säger X P? X P säger att teamet ska anamma tesdriven utveckling. Genom att skriva ett test, se att det fallerar, för att sedan implementera metoden och till sist se att testet går igenom är hur T D D ska praktiseras. Tester ger självförtroende och ger kodaren möjlighet att prova nya saker, utan att oroa sig över att han bryter gammal kod, eftersom han har testerna som säkerhet. H a ntering av p roble m e t G enom at t ta upp problemet och samtidigt delge en teammedlem T D D som spike fick teamet upp ögonen för metoden. E tt litet seminarium hölls i början av långlabb 2 där teamet och coacherna diskuterade T D D och dess fördelar. Teamet började koda väl enligt T D D, men ju längre tid som gick ju mindre brukade de metoden. Då tog teamet än en gång upp fördelarna med T D D för att verkligen övertyga teamet om att det var viktigt. V i som coacher passade ständigt upp teamet, och genom verktyget E C L Emma kunde vi visa vilka delar av koden som inte var testad. Ö verlag var tesutsträckningen nära 100%, vilket var väldigt bra. 6 C V S som konfigura tionsmetod P roble m a t i ken Teamet valde redan i början av projektet at t använda sig av C VS som konfigurationsverktyg. Det visade sig at t de flesta använt verktyget sen tidigare, och därmed antog vi som coacher lite dumt at t det inte skulle uppstå några problem med användningen av C VS. V i kunde inte haft mer fel. För även om teamet visste hur det fungerade tekniskt, så hade de ingen direkt kunskap om varför de använde C VS, och vilka bakomvarande ideer som låg bakom valet 6

av et t konfigurationsverktyg. V id flera tillfällen uppdagades röd kod i repositoryt, och flera gånger gick inte testerna igenom. T ill en början använde de arbetande paren sig sällan av check-in / check-out, vilket kanske inte medförde mergeproblem som man hade kunnat tro, utan det spädde istället på problemet med dålig kommunikation, och inblandade blev förvirrade kring vilka delar var implementerade eller inte. Vad säger X P? X P tar knappt upp användningen av konfigurationsmetod, utan nämns endast som hastigast. Men faktumet är at t några av de viktigaste praktikerna inom X P kräver just ett sådant verktyg för att fungera på ett vettigt sätt. Kontinuerlig integration skulle vara i princip omöjligt utan et t bra verktyg som teamet använder sig av. H a ntering av p roble m e t Coacherna sat te upp tydliga mål, en uppdatering minst var 10:e minut, en checkin minst var 15:e minut. Det visade sig att detta var svårt, inte på grund av Eclipse och C VS, utan därför att teamet int lyckades arbeta enligt en av X Ps metodiker - Code and design simply. Utvecklarna tyckte om att hoppa över hela problemet direkt, och genom at t försöka sig på at t implementera hela storys eller tasks på en gång kunde de sitta i timtal utan att göra en commit. Det vi som coacher försökte lyfta fram var hur viktigt det var att arbeta enkelt och stega sig fram, och därmed också kunna utnyttja T D D fullt ut. 7

7 Slu tsa tser och framåtblickar Att ha god teori i bagaget är viktigt, men kunskap att coacha genom empiri är av ännu större vikt. En coach måste utvecklas genom coachingen och ta lärdom av de misstag hon gör. Hantering och lösning av de problem som uppstår kan underlättas genom att tillsammans med andra coacher prata om det och genom planering. Det är genomgående samma misstag eller problem som uppstår vid nästan all typ av coaching - flera av de problem vi stötte på var precis sådana som även andra coacher berättade att de stötte på. Det som skilljer en situation från en annan är coachernas erfarenheter, som varierar. E n erfaren coach har tidigare varit med om problemet och vet således hur man når en lösning och reder ut problemet medan en oerfaren behöver upfinna hjulet på nyt t - det räcker inte enbart med at t kunna teorin. V idare visar flera undersökningar och intervjuer att coaching får ett allt större utrymme hos företag och att företagen själva inser värdet i at t utbilda och använda coacher. Men till yrket kommer ansvar och kvalité. Det är en svår konst att bemästra coaching och fel coaching kan ge förödande e ekter för företaget. Det skall även poängteras att yrket är relativt nytt och har ännu inte blivit så pass legitimt alla företag ser det som något positivt eller användbart [4]. 8

R eferenser [1] K. Sharifabdi, C. G rot Team Development and Pair P rogramming: tasks and challenges of the X P coach. Agile A lliance, 2002. [2] J. Pelrine, R. Uhtes, C. Noack. Why is it hard to learn extreme Programming? - Philosophical and psychological aspects of learning a new methodology. 2000 [3] J. Waldroop och T. Butler. T he Executive as Coach. Harvard Business Review, 1 November 1996. [4] D. Coutu och C. K au man. What can coaches do for you? Harvard Business Review, 1 januari 2009. [5] David G. Rohlander. How to E ectively Coach Journal of Management in Engineering, Vol. 15, No. 2, March / April 1999 pp. 16-17. [6] J. R. Hackman och R. Wageman. A theory of team coaching. Academy of Management Review, Vol. 30, No. 2, pp. 269-287, 2005. [7] chromatic Extreme P rogramming Pocket G uide. O Reilly 2005. 9