Kunskapsspridning inom ett XP team

Transkript

1 Kunskapsspridning inom ett XP team Simon Lindberg & Firas Dib {ada10sli, En djupstudie i hur kunskaper sprider sig inom ett parprogrammerande utvecklingsteam. Nyckelord: kunskapspridning, bussfaktor, homogen grupp, parprogrammering, alla i samma rum, XP Abstrakt Denna studie innehåller våra tankar och observationer från vår tid som coacher för ett utvecklingsteam, då vi har studerat och utvärderat utvecklarnas kunskaper och dess spridning. I rapporten diskuterar vi hur de XP praktiker som parprogrammering, alla i samma rum, planeringsmöten och spikes påverkar kunskapsspridning inom gruppen och hur man utnyttjar dem bäst. 1

2 Introduktion Det har skrivits flertalet gånger om XP och dess fördelar för kodkvalité, tillfredsställelse och effektivitet [4,5,6]. I den här studien vill vi fokusera på hur kunskap sprids inom ett XP team och hur XP praktiker så som parprogrammering, alla i samma rum, planeringsmöten och spikes påverkar kunskapsspridningen i teamet. Denna djupstudie kommer att fokusera på hur kunskap sprider sig inom ett XP team. Eftersom XP fokuserar på Collective Code Owndership, dvs. att alla får ändra överallt, är det mycket fördelaktigt om man har en homogen grupp som arbetar tillsammans eftersom det indirekt ökar produktiviteten. Med en homogen grupp menar vi att gruppmedlemmarna har en jämnlik kunskapsnivå gällande systemet/projektet ifråga och en perfekt homogen grupp har exakt samma kunskaper och erfarenheter av systemet. Ett team som är perfekt homogent hade i praktiken varit omöjligt eftersom kodbasen ändras kontinuerligt av flera personer samtidigt. Därför introducerar vi ett sätta att mäta hur pass homogen en grupp är; bussfaktorn [2]. Bussfaktorn är ett mått på hur många programmerare som kan bli överkörda av en buss innan projektet inte längre går att genomföra eller stakar upp sig kraftigt. I ett perfekt homogent utvecklingsteam hade bussfaktorn varit lika stor som antalet medlemmar, dvs. att alla hade varit tvungna att bli överkörda för att projektet skulle dö ut. I ett team där kunskapen inte är homogent fördelad är bussfaktorn 1, vilket innebär att en specifik del av projektet förlitar sig fullständigt på en persons specifika kunskap. Målet med denna djupstudie är att se hur klassiska XP praktiker påverkar gruppens bussfaktor, och att vidare se vilka som fungerar bäst samt hur dem bör utövas. Även om vi i studien har ett fokus på bussfaktorn har vi använt oss av en mycket bred definition av kunskap. Vi benämner både vetskap om systemet och snabbkommandon i Eclipse som kunskap, lika så hantering av mergekonflikter och reguljära uttryck. Upplägg Totalt har vi arbetat med teamet under sex iterationer där varje iteration innefattade en långlabb och ett planeringsmöte. Under långlabbarna satt utvecklarna i samma sal och implementerade de stories som hade estimerats och prioriterats fram under det föregående planeringsmötet. Mellan varje långlabb delades det även ut spikes som utvecklarna gjorde hemma antingen ensamma eller i par. Efter varje långlabb lät vi alla i teamet fylla i en feedback enkät (se ett exempel i Appendix A) som varierade gradvis från vecka till vecka. Enkäten ändrades så att relevanta frågor och diskussionsämnen som kommit upp under dagen kunde läggas till och testas. 2

3 Många frågor i feedback enkäten är frågor där dem väljer en siffra som motsvarar den kunskap dem besitter. Frågorna är rankade 0 5 där vi översatt poängen till följande: 0. Ingen kunskap inom området alls. 5. Är en expert inom området. Kunskapsenkäten (se Appendix B) fylldes i under första och sista iteration för att på så sett ge oss ett bredare perspektiv över hur mycket det faktiskt lärt sig. Förutom att planera på planeringsmötena delade vi dessutom ut spikes till utvecklarna. Vi har provat olika metoder för hur spiksen bör genomföras och redovisas för att se vilken metod som verkar fungera bäst när det gäller att lära sig så mycket som möjligt och förmedla denna informationen till gruppen. Genomförande Förutom de återkommande feedback enkäterna delade vi ut en kunskapsenkät. Denna lät vi utvecklarna fylla i under första iterationen och senare under en av de sista iterationerna för att se hur utvecklarnas kunskapsnivå hade förändrats. Den delen av enkäten som vi fokuserat på mest är Kryssa i vad du känner dig säker på och vi har sammanställt resultat i tabellen nedan. Man ser tydligt att teamet i helhet ökat sina kunskaper. I denna delen av uppsatsen kommer vi att diskutera diverse situationer som har bidragit till denna ökning. Utvecklare Kunskapspoäng innan Kunskapspoäng efter Dev Dev Dev3 3 7 Dev Dev Dev Dev Dev Dev Dev Tabell 1. Sammanställning av antalet i kryssade rutor från Kryssa i vad du känner dig säker på Scenario 1: Spike för ANT script Upplägg Under första långlabben arbetade gruppen flitigt och tillslut saknades nya stories att implementera Vi valde då att dela ut en extra story till det par som inte hade något och göra vilket då handlade om just ANT skriptför att förenkla release processen. Paret lyckades skriva början till ett script som byggde 3

4 projektet och för att snabbt sprida kunskapen inom gruppen valde vi att dela ut en spike till nästa vecka. Spiken bestod av att läsa på om ANToch skriva ett script som bygger ett hello world projekt. Resultat I tabellen nedan finns den data vi samlat ihop genom enkätsvaren. Utvecklare Kunskapsnivå innan spike Kunskapsnivå efter spike Nedlagd tid Dev :30:00 Dev :30:00 Dev :10:00 Dev :30:00 Dev :45:00 Dev :15:00 Dev :30:00 Dev :00:00 Dev :30:00 Dev :20:00 Genomsnitt :36:00 Tabell 2. Resultat för scenario 1. Beskriver hur gruppen svarade på frågan Hur väl kan du ANT skript? samt Hur lång tid la du ner på ANT spiken? Diskussion Det var bara ett fåtal personer enligt vår data som tog sig tid att läsa på om ANToch framförallt DEV8 som även var den personen som skrev skriptet under första iteration. Många ökade sin kunskap smått men var fortfarande inte tillräckligt pålästa för att kunna arbeta med ANT. Detta återspeglas i hur lång tid varje person la ner på att lära sig ANT, där DEV8sticker ut extra mycket. Anledningen till detta var att DEV8 var ena halvan av paret som lyckades skriva det första skriptet, och upptäckte under spiken en bugg och spenderade tid på att lösa den. Trots att genomsnittet i gruppen fördubblats efter spiken var det inte mer än 4 personer i gruppen som svarade 3 eller högre, och t.o.m någon som fortfarande inte visste vad det var för något eller vars kunskapsnivå var helt oförändrad. Kunskapen för hur man skulle köra skriptet spreds sig efter hand till ett par andra inom gruppen, men under långlabbarna fick DEV8förklara en del till de andra som var mindre pålästa. Skulle en ändring för att hantera nya krav implementeras hade gruppen vänt sig till den personen som skrev det från första början för att endast denne har tillräckligt djup insikt. Detta tyder på att bussfaktorn var låg inom gruppen. Denna form av utdelning resulterade i att ingen riktigt kände sig träffad att ta tag i problemet, vilket har återspeglat några av Lencionis dysfunktioner [1]: Lack of commitment Avoidance of accountability 4

5 Slutsats I grund och botten är det tack vara en ensam gruppmedlem som ANT skriptetblev gjort och ett par andra medlemmar lärde sig använda det. Hade det inte varit för DEV8hade skriptet eventuellt aldrig blivit skrivet, alternativt hade någon annan varit tvungen att ta tag i det. Oavsett hade bussfaktorn inte ökat och fortsatt vara låg. Detta hade givetvis inte resulterat i att projektet hade varit tvunget att läggas ner men det hade varit en olägenhet som eventuellt hade resulterat i felaktiga releaser, att teamet hamnat bakom schemat eller en irriterad kund. Scenario 2: Strukturerade spikes Upplägg Veckan efter scenario 1 tog vi på oss att ge mer strukturerad instruktioner till spikesen, i kontrast mot den första. Vi erbjöd totalt 4 olika spikes, där ibland söka efter bad smells i kodbasen och göra en impact analysis. Utvecklarna valde själva fritt vilken de ville utföra. En del valde att samarbeta i par, andra delade upp uppgifterna mellan varandra eller gjorde det individuellt för att få bättre perspektiv. Vid nästa långlabb bad vi varje par redovisa för gruppen vad de kommit fram till och uppmanade till diskussion. På feedbeck enkäten frågade vi hur mycket de hade haft varandras spikes i åtanke. Resultat I tabellen nedan finns den data vi samlat ihop genom enkätsvaren. Utvecklare Spike 1 Spike 2 Differans Dev1 0:30:00 3:00:00 2:30:00 Dev2 0:30:00 2:15:00 1:45:00 Dev3 0:10:00 4:00:00 3:50:00 Dev4 0:30:00 0:10:00 0:20:00 Dev6 0:15:00 1:30:00 1:15:00 Dev8 2:00:00 1:00:00 1:00:00 Dev9 0:30:00 0:45:00 0:15:00 Dev10 0:20:00 0:20:00 0:00:00 Genomsnitt 0:36:00 1:37:30 1:01:30 Tabell 3. Visar nedlagd tid på olika spikes samt tidskillnaden. Två utvecklare är inte med då deras spike var att baka kakor. 5

6 Utvecklare Påverkan (0 10) Dev1 3 Dev2 1 Dev3 5 Dev4 5 Dev5 6 Dev6 3 Dev7 6 Dev8 7 Dev9 4 Dev10 4 Tabell 4. Utvecklarnas svar på Under dagen, hur mycket har du tänkt på de sakerna vi gick igenom under morgonmötet? Diskussion I snitt lade gruppmedlemmarna ner drygt en timme mer på den strukturerade spiken än ANT spiken, men redovisningen som grupperna gjorde var korta och innehållslösa. Resultatet var mycket varierat och om än inte dåligt tycker vi att det hade kunnat gå bättre. Även om många påstår sig ha tänkt på det som togs upp så löstes inte många av de problem och punkterna stod på tavlan under hela dagen. Ingen såg till att det gjordes vilket medförde att det mer eller mindre glömdes bort. Slutsats Vi märkte tydliga förbättringar efter att vi strukturerade upp utdelningen av spikesen, men anser fortfarande att en bättre redovisning av dem krävs för att få ut kunskapen i gruppen. Scenario 3: Refaktoreringsspike Upplägg Teamet började inse att kodkomplexiteten var för stor och att mindre individuella ingrepp skulle ta alldeles för lång tid att genomföra. Under planeringsmötet diskuterade vi därför problem med koden som skulle behövas refaktoriseras. Som spike delade vi ut att alla utvecklarna skulle se över systemet efter nyttiga refaktoriseringar, med de punkter som vi diskuterade fram under mötet i åtanke. Under morgonen på den följande iterationen gick vi igenom alla utvecklarnas refaktoriseringsförslag, diskuterade dem och skrev upp dem på tavlan. Under dagen noterade utvecklarna de refaktoriseringar de påbörjat och fullföljt. Resultat Teamet presenterade många och bra refaktoriseringar som kändes aktuella. Diskussion kring refaktoriseringsförslagen hölls också innan de skrevs ner på tavlan. 6

7 Utvecklare Påverkan (0 10) Dev1 6 Dev2 7 Dev3 6 Dev4 8 Dev5 4 Dev6 7 Dev7 7 Dev8 5 Dev9 7 Dev10 8 Tabell 5. Visar hur stor påverkan diskussionen kring spikes haft på varje utvecklare Diskussion Denna spike gav bättre resultat, vilket syntes både i vår feedback och i koden som de refaktoriserade. Utvecklarna ansåg att spiken var mycket aktuell vilket resulterade att de var mer angelägna i att ta tag i problemet. Dysfunktionerna vi såg i tidigare spikes märktes inte av den här gången vilket vi tror beror på att, utöver faktumet att spiken kändes relevant, vi krävde en mindre presentation från varje utvecklare och uppmanade till diskussion. Scenario 4: Utlopp för frustrationer Upplägg Bland JUnit testerna hade argumenten till assertequals(expected, actual)skrivits i fel ordning på flertalet ställen. Detta ledde till frustrationer inom teamet och specifikt hos ett par som felsökte testerna som slutligen gav utlopp för sina frustrationer. Föraren i paret berättade väldigt barskt för gruppen hur inkonsekventa de var. Resten av gruppen höll med, erkände att de gjort fel och i flera fall inte visste att det var någon specifik ordning för parametrarna. I vårt feedback formulär den dagen frågade vi om vilken som var den korrekta ordningen på argumenten i assertequals. Resultat Alla utom en utvecklare svarade rätt på frågan om ordningen och problemet har inte upprepats sen dess och alla tester följer konventionen. Diskussion och Slutsats Trots att detta utlopp resulterade i en positiv förändring inom gruppen anser vi inte att detta är ett optimalt sätt att förmedla informationen inom gruppen. Däremot ser vi det som något positivt att gruppen inte har 7

8 någon rädsla för att ta tag i en konflikt och lösa den, men optimalt hade denna information spritt sig tidigare (exempelvis genom parprogrammering) och detta scenario aldrig inträffat. Scenario 5: Utvecklare i samma rum med datorhaveri Upplägg Under första labben uppmuntrade vi utvecklingsparen till att sitta vid datorerna närmst varandra, vilket de gjorde. Detta visade sig mycket bra eftersom det blev lätt att vända sig om och fråga ett annat par om hjälp. Efter ett par labbar började ett antal datorer krångla vilket innebar att några par fick flytta på sig och avståndet mellan utvecklingsparen växte. I början av projektet var det max en halv meter mellan paren, i slutet var det uppemot tre meter. Resultat Antalet diskussioner som hölls gemensamt inom teamet minskade och de öppna frågor som utvecklarna ställde till rummet fick mindre respons. Diskussion och Slutsats Att en sådan enkel omorganisation skulle påverka gruppens samverkan var förvånande för både oss och teamet självt. När problemet upptäcktes uppmuntrade vi teamet till att vara mer uppmärksamma på öppna frågor och liknande. Detta hjälpte till viss del, men det fick oss att inse hur stor effekt små förändringar kan ha på teamets kommunikativa egenskaper. Diskussion Vi har märkt att kunskapen sprider sig på många olika sätt inom teamet. Under planeringsmötena, när utvecklarna diskuterar systemet och dess framtid, delar de med sig av sin bild av systemet och deras åsikter om det är något som borde åtgärdas i det. Vi märkte även att planeringsmötena var ett bra tillfälle att låta utvecklarna diskutera vad som borde göras som spike under veckan. Spikes har varit väldigt användbara för att snabbt få in specifik och nyttig kunskap i teamet för att sen låta utvecklarna sprida den vidare, men det tog några iterationer för oss att lyckas använda spike tiden bra. Vi märkte att spikes behöver vara välstrukturerade och, framför allt, relevanta för att utvecklarna ska ta till sig dem. Vi införde även korta redovisningar av spikesen vilket underlättare spridandet av kunskapen inom gruppen. Parprogrammeringen har varit väldigt intressant att följa hos utvecklarna eftersom man tydligt ser hur information och kunskap sprids mellan utvecklarna. Kortkommandon inom Eclipse och hur man använder SVN har varit två saker som var extra aktuella mellan paren. Självklart diskuterades även mer givande ämnen som design och specifika implementationsfrågor. 8

9 Vi påstår att en av de anledningarna som gör parprogrammeringen så kraftfullt på att sprida kunskap och öppna upp till diskussioner är det faktum att man sitter nära varandra. Detta såg vi tydligt i scenario 5 då teamet var tvungna att flytta sig längre ifrån varandra och att det efteråt krävde en ansträngning för att fortsatt upprätthålla kommunikationen. Från scenariot som vi upplevde kan man dra paralleller till hur små, enkla störningar och dysfunktioner påverkar teamets kommunikationsförmåga negativt. Det är därför viktigt att det är bra sammanhållning inom teamet för att ha fortsatt god kommunikation, undvika dysfunktioner och i slutändan sprida kunskap. Scenario 5 ger oss även tillfälle att påvisa hur teamet utnyttjade de olika praktikerna; parprogrammering och alla i samma rum. Parprogrammering används kontinuerligt, flytande i implementering, debugging, design och testning. Medan det faktum att man har hela sitt team i rummet utnyttjas endast när man fastnar, behöver hjälp eller inte förstår. Utvecklarnas tankar Under de sista delarna av projektet diskuterade vi med utvecklarna om vilka aspekter som de tyckte var hjälpsammast för inlärningen under projektet. De punkter vi diskuterade var: alla i samma rum, spikes, parprogrammering och planeringsmöte Alla i samma rum Det faktum att alla sitter i samma rum gör att det är lätt att ta upp diskussioner, vilket teamet har noterat och utnyttjat mycket. Men eftersom man har sin parprogrammeringspartner brevid sig att diskutera med blir det att de frågor man tar upp med någon är av större karaktär, tex. att man inte förstår någon någon nyligen implementerad del av systemet. Teamet uppmärksammade även att det är lätt att snappa upp något från en annan diskussion som man kan inflika i, vilket de tyckte var bra i sammanhanget. I början av projektet försökte vi sitta så nära varandra som möjligt, men allt eftersom datorer havererade spreds utvecklarna ut mer och mer. Alla utvecklarna var överens om att detta påverkade hur angelägna de var för att diskutera med andra par i rummet. Det bör noteras att avståndet endast gick från under 1 meter till 2 3 meter. En god idé kan vara att alla använder sig av en chattklient som man kan använda för kommunikation, även om man sitter i samma rum. Två fördelar lyftes fram: 1. Historik över diskussioner, lösningar och besluts som tagit. 2. Det underlättar för någon att inflika i diskussioner som man inte varit aktiv i från början. Spikes Vi diskuterade hur de hanterade de första 3 spikesen (scenario 1, 2, 3) och varför resultaten varierade så kraftigt. Anledningen de kom fram till och som vi tidigare diskuterat, en avsaknad av engagemang och 9

10 spiksen inte känns relevanta för teamet. Det var först under iteration 3 som de stötte på problem med kodbasen och då blev en spike om refaktorisering plötsligt relevant. Planeringsmöte Angående planeringsmötet tyckte utvecklarna att det var mer hjälpsamt för att snacka ihop sig om systemet, än att lära sig specifika saker om det. Dock skulle vi vilja argumentera att snacka ihop sig om något är att förmedla och dela med sig av sina kunskap om det ämnet. Vilket skulle göra planeringsmötena till en väldigt viktig del av teamets totala kunskapsspridning. Parprogrammering Alla utvecklare var i samtycke om att parprogrammeringen var det som hjälpt dem mest och det attribut som de värderade högst. De uppskattade framför allt den snabba feedbacken och att det uppmuntrar till diskussion eftersom man ser direkt vad ens partner försöker förklara. Med parprogrammeringen diskuterar så väl stora som små ämnen, både implementationsspcifika diskussioner och snabbkommandon i Eclipse. Självkritik Poängskalan vi använt på våra enkätfrågor öppnar upp till subjektiv bedömning vilket betyder att resultaten måste tas med en nypa salt då exempelvis en 3:a för en person kanske inte motsvarar samma kunskapsnivå hos en annan person. Detta hade eventuellt kunnat begränsas lite genom att ge en klarare definition för vad varje siffra ungefär motsvarade kunskapsmässigt, men hade aldrig blivit helt perfekt. Bussfaktor är en intressant mätstock men inte alltid en perfekt sådan. Låt oss demonstrera med ett exempel: Ett team med 9 utvecklare som delar samma kunskap där 1 person är den ende som kan en kritisk komponent i systemet och ett annat team på 10 utvecklare där alla utvecklare härjar fritt och ingen delar någon kunskap. Bussfaktorn för båda dessa team är 1, även om första teamet troligen arbetar betydligt effektivare och bussfaktorn är, med all sannolikhet, lättare att höja. Framtida arbete I mån om tid hade vi velat studera hur helt fria spikes hade fungerat för teamet. Förslagsvis hade vi kunnat diskutera fram ett antal potentiella spikes under planeringsmötena, sedan får utvecklarna själva välja vilken spike de vill utföra. Vid nästa iteration får de presentera vad de kommit fram till under sin spike tid. Alternativt hade spikes kunnat vara helt fria för utvecklarna, med den enda hållhaken att man måste presentera sina fynd i början på nästa iteration. Båda dessa alternativen garanterar att utvecklarna kommer att utföra något som de känner är relevant och givande. En annan idé, som uppmärksammades av teamet, är att se effekterna av en interna chattklient som används i konjunktion med att sitta i samma rum för att se om det öppnar upp för fler kanalar för kunskapen att spridas. 10

11 Slutsats Sammanfattningsvis kan vi konstatera att ett samarbetsvilligt team ökar möjligheterna för att kunskapen skall spridas effektivt. Att teamet har god atmosfär och saknar dysfunktioner gynnar deras diskussioner och ökar dess engagemang. Öppen diskussion är mycket viktigt och bör uppmuntras under både långlabbar och planeringsmöten. Det faktum att man sitter i samma rum är klar fördel för teamet, men är i sig självt inte nog för att få igång en bra diskussionsatmosfär. Man måste arbeta för att hålla atmosfären på en bra standard, men det kan räcka med att endast uppmärksamma kvalitén på den. Det är ytterst viktigt att de spikes som görs är relevanta och aktuella enligt utvecklarna. Annars blir de inte gjorda ordentligt alternativt så rinner det bara ut i sanden. Det krävs också att dem är välstrukturerade och redovisas för hela gruppen på ett bra sätt. Det som fungerade bäst för oss var att ha en genomgång och skriva upp lämpliga punkter på tavlan. Parprogrammering har visat sig har stort inflytande i hur kunskapen sprids från person till person. Det är därför extra viktigt att få in en god rutin på parbyten så att inte informationen koncentreras på ett och samma ställe. 11

12 Källor 1. The Five Dysfunctions of a Team, Patrick Lencioni, Bus factor. Wikipedia: The Free Encyclopedia. Web. 10 Dec Chromatic Extreme Programming Pocket Guide. O reilly media. 4. A. Cockburn, L.Williams The Costs and Benefits of Pair Programming. Online at: 5. C. McDowell, L. Werner, H. E. Bullock, J. Fernald The Impact of Pair Programming on Student Performance, Perception and Persistence. Online at: 6. C. McDowell, L.Werner, H. Bullock, J.Fernald The Effects of Pair Programming on Performance in an Introductory Programming Course. Online at: 12

13 Appendix A 13

14 Appendix B 14