Affärsnytta i fokus för sammankopplade system sid 7 ... - Contoso.se

metoder&modeller
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!
jOAKIM HOlM | tERRIER SOFtWARE | BlOgg: jOCKEHOlM.WORDPRESS.COM
Referenser:
1 Steve McConnell ”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
2 Dave Hover: redsquirrel.com/blog/archives/00000170.html
3 Arlo Belshee: mitchlacey.com/docs/XR4PromiscuousPairingandBeginnersMind.pdf
22 Informators tidning om utveckling och kunskap. Nummer fem. Hösten 2008.