Parprogrammering – den okända manualen

Vi vet idag att parprogrammering egentligen är fruktansvärt effektivt. Det finns skäl att tro att parprogrammering i kombination med TDD kan ta bort 90-97% av felen. [1] Dom här felen är irriterande, otroligt jobbiga att fixa i efterhand när ingen längre kommer ihåg hur det var tänkt, men framför allt kostar de mycket pengar. Plus en massa andra bra saker, som att fler ser mer kod och man inte blir så personberoende.

Så varför gör vi det inte mer? Ett skäl till det är att det är så förbannat svårt att trivas bra med (det finns andra skäl, som att chefer eller kunder tror att tangentbordet är den trånga sektorn och inte hur snabbt vi kan lösa problem, men det är en annan historia). Jag har haft några av mina roligast stunder som utvecklare när jag har parprogrammerat. För det är ju kul att jobba tillsammans på ett gemensamt problem och lösa det. Att dela den där svindlande känslan av att klarat av ett svårt problem. Wow! Men jag har också upplevt oerhört frustrerande stunder. När magen har morrat och andningen varit kort av irritation. När allt man har längtat efter är en kopp kaffe.

För vad det kan vara värt, här kommer några knep för att lyckas med parprogrammering som har fungerat för mig.

Ping-Pong-Kingen
Folk vet att man ska byta tangentbord ofta, men håller ändå tangentbordet hårt timmar i sträck. Det är oerhört lätt, jag gör det själv. Men det duger inte. Att sitta och titta på när någon programmerar i ett par timmar är tråkigt intill döden, trots att du försöker allt som du kan för att engagera dig.

Så jag ska ge er ett tips: Använd Ping-pongprogrammering. Det fungerar så här: Du skriver ett test som inte går igenom. Din partner får sedan skriva enkel kod som får testet att fungera. Sedan skriver hon ett test och då är det din tur att få testet grönt. Superenkelt! Och det fungerar. Inte nog med att tangentbordet byter ägare med några minuters mellanrum, dessutom blir båda parter mer engagerade. Det är nästan så att ett litet tävlingsmoment uppstår. “Ok, nu j-klar ska jag ge dig ett svårt test att klara av.” Och av en ren slump så kör ni perfekt, disciplinerad TDD, bara en sån sak.

Så starta idag! Bli Ping-Pong-Kingen på din arbetsplats.

Promiskuös parning
Nästa sak man kan läsa om parprogrammering är att man ska byta partner ofta. “Varannan dag typ?”, kanske många tänker. Många verkar idag sitta med samma partner dag ut och dag in. Allt känns tryggt och fint. Visst blir ni förbannade ibland och visst kan ingen annan er kod, men det känns ju så lugnt och skönt. Mmm…

Nej nej, det duger inte. Parprogrammering är inte bara en ständigt pågående granskning av kod, det ska också vara ett sätt att flytta runt personer så att alla lär sig stora delar av systemet. Det ligger i allas intresse. Större variation för deltagarna, mindre personberoende för cheferna. Och vad säger det om teamkänslan när ni har ett litet team i teamet?

Men jag kan ge ett litet tips: Använd promiskuös parning. Det låter lite knäppt på en arbetsplats, men det fungerar så här: Var och en i teamet har en uppgift, tagen från till exempel en sprintplan. När du ska lösa en uppgift tar du en uppgift som du kan ganska lite om. Du måste be om hjälp. Om istället någon ber dig att hjälpa till måste du tacka ja. Här kommer det viktiga: Ni får bara arbeta tillsammans i max 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.

Det sköna med detta är att ni aldrig hinner tröttna på varandra. Även om du får jobba med petimetriske Olof eller ständigt negativa Ulla så visst klarar du av några timmar? Och jag lovar, Ulla är inte så neggig som man kan tro, när man väl har lärt känna henne.

Så börja redan idag! Hur många partners kan du få till innan dagen är slut?

Fotnot: För fullständig promiskuös parning krävs också att ingen stannar vid samma uppgift genom hela utvecklingen och att varje uppgift ges till den minst kunnige inom området. Enligt forskning ger detta högre produktivitet. Läs mer i forskningsrapporten, om du är intresserad.

Moccamaster
Men hur ska vi komma ihåg att byta partner? Enkelt, i Sverige har vi en enorm fördel som de inte har i andra länder: Fika! Tiofikat och trefikat är perfekt tider för partnerbyten. Lägg till ett byte vid lunch och du har delat in dagen i fyra perioder. Dessutom får du lite paus för att rensa hjärnan mellan bytena. Rekommenderade ministorleken på en uppgift i Scrum är 1-2 timmar och det är ju perfekt! Det är ju exakt den tid ni får om ni delar in dagen i fyra delar. Och det passar också utmärkt för maxtiden 90 minuter.

Fikar ni inte längre på ert jobb? Så… modernt. Fundera gärna på att återinföra det. Kanske fanns det någon poäng med de där fikastunderna förutom att få i sig koffein? Kanske behöver din hjärna tänka på något annat? Kanske lära känna folk i projektet kan göra det lite roligare ändå? Kanske Ruben från det där andra projektet har haft samma problem med CruiseControl som vi? Och nej, jag menar inte betongsverigefika på 45 minuter. Femton sköna minuter av mys räcker för att vara högproduktiv igen när du väl kommer tillbaka.

Vad väntar du på? Gå iväg och brygg en hederlig gammal kanna åt teamet. Bli Moccamaster pronto.

Använd en P3
“Ok, det här låter väl schysst, men det fungerar ju inte. Människor vill känna att man avslutar saker. Om man nu har satt sig hos Karin och påbörjat någonting så vill man ju bli klar.” Ja, jag håller med, flow är viktigt. Problemet är bara att det då stör rytmen för alla andra som behöver byta partner. Och snart blir det heldagar tillsammans. Eller flera dagar. Nej, det duger inte. Vi vill att flera personer ser den där “smarta” koden som ni håller på med. Vad händer annars när ni drar på kärlekssemester tillsammans?

Men jag ska ge er ett tips: För varje session skapa en P3, en parprogrammeringsplan. “Äsch, mer planer, jag trodde inte man planerade i agila metoder?” Eh, jo, vi planerar bara väldigt lite väldigt ofta istället för allt på en gång i början. Men det är enkelt, en P3 är inget annat än de steg ni behöver ta för att klara av den uppgift ni har satt er för att göra. Skriv en lista av punkter, typiskt en handfull, det första ni gör tillsammans. Lämna lite utrymme emellan dem för saker som ni kommer på under arbetets gång. Låt den som är kartläsare (bisittaren) sköta planen. När ni byter tangentbord byter ni också blocket. Och här kommer det sköna: Även om allt går åt pepparn och ni bara hinner med några punkter på listan så kommer ni ändå känna att ni har klarat av någonting och kan utan emotionella störningar gå vidare till nästa partner. Ett par saker bortstreckade i alla fall. Inte illa så!

Så sätt igång: Bli P3-chef på en gång.

Referenser
[1] Joakim Sundén, Avega, föredrag på Developer Summit, Stockholm, 2008. Joakim hänvisar till Steve McConnells bok “Code Complete: A Practical Handbook of Software Construction som i sin tur hänvisar till Shull et al “What we have learned about fighting defects”, 2002