Författare Joakim Holm (Terrier Software)
Blogg: jockeholm.wordpress.com
I takt med att agila (lättrörliga) arbetssätt börjar få fäste inom systemutvecklarskrået växer också nyfikenheten på parprogrammering, en av de mest missförstådda och svåranvända agila teknikerna.
Parprogrammering innebär i korthet att två personer sitter bredvid varandra vid samma dator och arbetar tillsammans på samma programmeringsuppgift. En session med parprogrammering kan liknas vid en rallyetapp. Den som för tillfället har tangentbordet kallas ‘förare' och den som sitter bredvid kallas ‘kartläsare'.
Litteraturen om parprogrammering beskriver många saker som vi kan känna igen från dagis; att vara snälla mot varandra, inte ta saker av varandra, tvätta oss varje dag etcetera. Det är bra saker, men många behöver mer handfasta tips för att lyckas.
Färre fel och bättre helhetssyn
Vi vet idag att parprogrammering är bra på många plan. Det finns forskningsrön som tyder på att team som använder parprogrammering i kombination med testdriven utveckling (TDD) kan undvika över 90 % av de fel som annars brukar uppstå.
Fel som upptäcks under produktionsarbetet kan utan vidare ta ett par tre dagar att rätta till. Det kan handla om administration, felanalys, rättning, följdfel, testning, dokumentation och leverans. Detta kostar naturligtvis stora pengar och kloka organisationer gör allt för att undvika det. En annan stor fördel med parprogrammering möjliggör för fler personer att se stora delar av systemet. På så sätt upplever deltagarna en större variation och en större helhetssyn i sitt arbete medan uppdragsgivarna inte blir lika personberoende. En typisk vinna-vinna-situation, alltså. Det finns även andra fördelar med parprogrammering (se slutet av artikeln)
Ovanligt med parprogrammering i Sverige
Parprogrammering är trots dessa uppenbara fördelar ovanligt i Sverige år 2008. Varför? Mycket beror tyvärr på ren okunskap hos chefer och beställare. Om man får vara lite elak, verkar det nästan finnas en tro på att det är tangentborden som är den trånga sektorn inom systemutveckling. Att om vi maximerar användningen av tangentborden blir vi en effektiv utvecklingsavdelning - hur fort vi kan lösa problem eller hur mycket onödigt arbete vi kan ta bort verkar däremot spela mindre roll. Lite märkligt, kan man tycka.
Tvåsamheten har många utmaningar
En annan orsak finns hos systemutvecklarna själva. Att visa någon annan hur man utför sitt arbete kan i början kännas ungefär som att stänga in sig i en provhytt med någon som man knappt känner och ta av sig alla kläder. Samtidigt har många utvecklare negativa erfarenheter av att arbeta nära en del kollegor, som tyvärr kan vara prestigefulla och håna svaghet och okunskap. Det här kan vara symptom på dålig laganda, och i de fallen är det en fråga för ledningen att ta tag i. Dessutom är parprogrammering svårt att lyckas med och därmed även svårt att trivas med. Jag har upplevt många frustrerande stunder när jag suttit som ett åskmoln och bara längtat efter en kopp kaffe. Här följer några av mina bästa knep för att lyckas med parprogrammering.
Korta ner intervallen
Det vanligaste felet som jag ser är personer som håller tangentbordet för länge, det vill säga längre än 5-10 minuter. Så kort ska nämligen ett pass som förare vara. Det är oerhört lätt hänt, jag råkar fortfarande göra det själv ibland. Men det duger inte. Att sitta och titta på när någon programmerar i en timme är tråkigt intill döden, trots att du försöker göra allt för att engagera dig.
Testa lite pingpong
Pingpong-programmering 2 är en bra teknik för att komma ihåg att byta förare. Det fungerar så här:
1. Du skriver ett exempel på önskvärt beteende som systemet inte stödjer i form av ett test.
2. Växla förare. Din partner ska nu skriva enkel kod som får exemplet att fungera.
3. Partnern ser till att koden är enkel och läsbar, du verifierar.
4. Byt roller och börja om. Nu är det din partners tur att skriva ett test och din tur att få att fungera.
Pingpong-programmering är mycket enkelt och det fungerar faktiskt! Inte nog med att tangentbordet naturligt byter ägare med några minuters mellanrum, dessutom blir båda parter mer engagerade för snart är det din tur att skriva igen.
Byt partner lite oftare
Ett annat vanligt fel som många gör, är att de behåller paren alldeles för länge. Många verkar tro att man ska sitta med samma partner under flera dagar i sträck. Det kan möjligen kännas tryggt att hitta någon som man trivs med, men det vanligaste är att man irriterar sig på varandra. I längden blir det faktiskt kontraproduktivt då parprogrammering också ska vara ett sätt att flytta runt personer så att alla i laget lär sig flera delar av systemet. Och vad händer egentligen med lagandan när ni har ett litet team i teamet?
Promiskuös parning
En teknik för att bryta upp dessa "kärlekspar", som jag kallar dem, är att använda Promiskuös parning 3. Det kan låta lite märkligt på en arbetsplats, men det fungerar så här:
1. Du väljer själv din nästa uppgift från den plan som ni har för iterationen. Välj gärna en uppgift inom ett systemområde som du kan ganska lite om.
2. För att lösa uppgiften måste du be någon om hjälp. Och vice versa, om någon ber dig att hjälpa till måste du tacka ja.
3. Ett par får bara arbeta tillsammans i maximalt 90 minuter. Sedan måste ni byta partner.
På en dag kan du alltså ha tre-fyra partners, vilket kanske känns spännande bara det. På detta sätt kan ni sprida kunskaper i teamet maximalt och styra undan de värsta situationerna.
Partnerbyte i fikarasten
Men hur ska vi komma ihåg att bryta upp? I Sverige har vi en enorm fördel jämfört med andra länder: Fika! Tiofikat och trefikat är perfekta tider för att byta partner. Lägg till ett byte vid lunch och du har delat in dagen i fyra, bra perioder. Eftersom en lagom storlek på en uppgift är 1-2 timmar och promiskuös parning tillåter 90-minuterssessioner så fungerar det utmärkt. Ännu bättre är om ni då och då kan fika tillsammans hela laget. Varför inte bli lagets "Moccamaster" genom att brygga en kanna åt gänget ibland? Många företag har tyvärr glömt av traditionen att ta en paus tillsammans då och då.
Femton sköna minuter av projektmys räcker för att vara högproduktiv igen när du kommer tillbaka. Ett problem med korta sessioner är att många känner att de inte får chansen att avsluta det de påbörjat. Flytet är viktigt, förvisso, men teamflytet är ännu viktigare. Problemet är att om ni förlänger sessionerna stör ni rytmen för de andra i laget som vill och behöver byta partner. Och flera personer än ni behöver se den där smarta koden som ni håller på med. Det kommer fler heldagar tillsammans.
Parprogrammeringsplan, P3, för varje session
Vad du kan göra för att alltid skapa en känsla av avslut, är att arbeta med en parprogrammeringsplan, en "P3", för varje session. Jobbar du lättrörligt redan idag vet du att det handlar om att detaljplanera i rätt tid, det vill säga precis när det behövs. En P3 kan beskrivas som den mest detaljerade formen av plan. Den är mycket enkel, det vill säga inget annat än de deluppgifter som ni behöver utföra för att klara av den uppgift ni åtagit er. Börja arbetet med att skriva en lista av punkter, vanligen en handfull. Lämna lite utrymme mellan dem för saker som ni kommer på under arbetets gång. Låt den som är kartläsare sköta planen. När ni flyttar tangentbordet byter ni också blocket. Poängen med det är att även om ni stött på problem och bara hunnit med några punkter på listan kommer ni ändå känna att ni har klarat av någonting. Ni kan utan problem gå vidare till nästa session. Ett par saker är bortstreckade i alla fall - inte illa!
Roligare arbetsliv med parprogrammering
Jag skulle vilja påstå att TDD och parprogrammering har förändrat mitt arbetsliv till det bättre. Förut kände jag ofta en gnagande oro för att jag skulle göra bort mig; införa någon svår bugg eller inte klara av ett problem. Jag tror att fler än jag är bekanta med denna dagliga oro. Nuförtiden är jag helt lugn, och har tvärtom haft några av mina roligaste stunder som utvecklare när jag har parprogrammerat. För det är en fantastisk känsla att tillsammans lösa ett knepigt problem; att dela den där svindlande känslan när det fungerar med någon. Wow!
..................................................................
Fördelar med parprogrammering
..................................................................