Mobbprogrammering är en teknik som kan lösa många problem. Det är också en teknik med många utmaningar. Rickard Sundin har samlat ihop sina erfarenheter, tankar och ger tips på vägen.
Mobbprogrammering kan kortfattat beskrivas som att hela teamet jobbar på samma sak, tillsammans, på samma dator. Det kan vara en effektiv teknik för att lösa utmanande problem där allas kompetenser nyttjas. Det hjälper teammedlemmar lära sig av varandra och att leverera den bästa möjliga kodkvalitét som är möjligt för teamet att frambringa. Det minskar också den negativa effekten om någon är frånvarande eller slutar, och är ett fantastiskt bra sätt att introducera nya medlemmar till teamet och kodbasen. Jag har varit med i tvärfunktionella team som med mobbprogrammering byggt funktioner som spänner över olika system, i olika språk, där alla i teamet har koll på och känner ägarskap för hela lösningen.
Det är också en teknik med många utmaningar. Här följer några insikter, tips och regler som hjälpt mig, och de team jag jobbat i, att få mobbprogrammeringen att fungera. Ditt team kommer behöva etablera sina egna regler, så ta inte det jag skriver här som absolut sanning, utan se det som inspiration.
Använd en timer och sluta när din tid är ute
Hitta ett rum med en stor skärm, låt någon i teamet ta plats vid tangentbordet och sätt en timer. Det kan fungera att någon startar en klocka vid sidan av, men jag rekommenderar att använda en timer avsedd för mobbprogrammering. Jag gillar Jason Crows MobTime, men det finns många andra. En bra timer låter dig ange namn på deltagarna, och visar förutom återstående tid namnet på den som ska ta över vid tangentbordet när tiden är ute. Hur lång tid som är lagom behöver teamet prova sig fram till, vi började med 7 minuter och anpassade oss därifrån.
Utvärdera och anpassa regelbundet
De första gångerna fungerade vår mobbprogrammering ofta ganska dåligt, och vi gick ifrån ineffektiva sessioner med en känsla av frustration över bortslösad tid. Ibland tappade medlemmarna fokus och var inte involverade i arbetet, och andra gånger ropade alla instruktioner i munnen på varandra till den stressad stackaren vid tangentbordet. För att få bättre kvalitet på våra sessioner, började vi ha korta (ca 5 minuter) retrospektiv i slutet av varje sittning, där vi pratade om hur vi tyckte att sessionen varit. Efter några sessioner, då vi samlat på oss information om allas upplevelser, höll vi ett lite längre retrospektiv fokuserat på mobbprogrammeringen. Tillsammans formulerade vi några regler som vi behövde hålla oss till, som sedan utmanades och justerades återkommande.
Det är inte personen vid tangentbordet som programmerar
Mobbprogrammering är en grupp människor som programmerar tillsammans, inte människor som turas om att programmera framför varandra. Tänk på personen vid tangentbordet som teamets röst-till-kod-gränssnitt. Genom att någon annan än den vid tangentbordet berättar vad nästa steg är, minskar risken för situationer där en person programmerar och resten tittar på.
Du är antingen med i mobben eller utanför mobben
Mobbprogrammering kräver fokuserade deltagare. Det vara frestande att börja göra andra saker när man inte sitter vid mobbens tangentbord. Du ska bara svara på det där mailet som dök upp, eller fixa något litet vid sidan av. Helt plötsligt har du tappat fokus på vad mobben håller på med, och de andra måste berätta för dig vad ni håller på med och vad som ska göras härnäst eftersom du inte hängt med riktigt.
Behöver du göra något vid sidan av, så gör det tydligt att du kliver ur mobben. Det behöver inte innebära att lämna rummet, men det kan av pedagogiska syften vara bra att sitta längst bort från skärmarna där mobben pågår. Om du sitter på kunskaper som mobben kan behöva kan mobben kan ställa frågor vid behov.
Välj en kapten
Ett engagerat team kan lätt börja prata i munnen på varandra när flera vill berätta för den som skriver vad som ska göras härnäst. För att undvika detta kan teamet utse en kapten, som leder arbetet och, efter att ha hört gruppens olika förslag, bestämmer vilken väg som ska tas. Kaptenen kan vara någon som har djupare kunskaper i det område mobben just nu befinner sig i, eller rotera varje gång tiden går ut. Min erfarenhet är att det i ett samspelt team inte behövs en uttalad kapten hela tiden, om man snabbt kan utse när en sådan situation uppstår.
Stressa inte när du skriver
För den som skriver kan det vara oerhört stressande att skriva kod framför ett helt team av smarta kollegor, och det är lätt att hjärnan låser sig även för en van programmerare. Genom att tänka på sig själv som röst-till-kod-gränssnitt kan det vara möjligt att slappna av och känna att det faktiskt är alla andra som behöver tänka ut hur det aktuella problemet ska lösas; du behöver bara skriva det som sägs. Säg till om du vill ha instruktionerna på en högre eller lägre nivå, där en högre nivå kan vara “skapa en konstruktor” och en lägre nivå kan vara “skriv ‘toString’ med stort S och utan mellanrum”.
Stressa inte när du inte skriver
De som inte skriver kan ibland känna frustration över kollegor som skriver med långsam pekfingervals och använder musen för att leta i menyer i programmet. Släpp det! Om någon eller några i teamet inte är lika snabba på att skriva, eller kan lika många kortkommandon, så tappa inte tålamodet. Jag strävar själv ständigt efter att effektivisera mitt tangentbordsanvändande med snabb och effektiv fingersättning, och effektiva kortkommandon, men det har tagit år av medveten träning att bli någorlunda bra på det. Ge gärna tips om förenklande kortkommandon, men kom ihåg att det inte är rimligt att lära sig allt samtidigt.
Påpeka inte småfel omedelbart
Om den som skriver gör ett stavfel eller liknande, så vänta några sekunder innan du påpekar det. Personen som skriver har förmodligen också själv sett felet, men vill skriva klart raden/funktionen först för att inte tappa flytet.
Samma dator eller byta dator?
Vid växling har jag oftast jobbat så att arbetet fortsätter på samma dator, och att man bara byter vem som skriver. Bytet går snabbt eftersom aktuella filer redan är tillgängliga och allt som behöver vara igång på datorn redan är igång. Men även i team där alla har samma operativsystem och samma utvecklingsmiljö så kan det skilja sig i vilka inställningar för tangentbordslayout, kortkommandon, mm, man är van vid, så vid varje växling kommer nästa person antingen att behöva ändra dessa inställningar.
Ett alternativ är att istället låta alla jobba på sin egen dator och när det är dags för byte kommitta koden precis som den är, pusha till en feature branch, koppla in nästa persons dator till bildskärmen, och checka ut samma branch på dennes dator. Själva växlingen tar lite längre tid, men fördelen blir att var och en kan ha precis de inställningar, konfigurationer och verktyg som den vill ha.
Om det ändå inte funkar
Är uppgiften lämplig för mobbprogrammering
Uppgifter som ligger i områden där teamet redan har etablerade best practises, dvs där alla redan har en gemensam bild av hur problemet ska lösas, kan lätt leda till att några bara sitter och inte gör något. Fokusera istället mobb-sessionerna på uppgifter som rör sig på ännu ej upptrampade stigar, och som kanske kräver kunskaper som inte alla redan besitter.
Vill utvecklarna mobbprogrammera?
För många utvecklare är det nästan en euforisk känsla att ta på sig hörlurarna, glida in i zonen och bara låta koden flöda genom fingrarna. Programmering i en mobb (eller i par) är en helt annan utmaning, då det är flera hjärnor som ska lösa problem tillsammans. Var medveten om att det för en del kan vara en dealbreaker att inte få programmera ensam med bara sin egen hjärna.
Är deltagarna trygga?
Mobbprogrammering är designat för att riva barriärerna inom teamet och skruva upp interaktionen till max. Saknas grundläggande psykologisk trygghet i teamet kommer inte mobbprogrammering att fungera bra förrän medlemmarna litar på varandra. Med rätt stöd och coachning är det en aktivitet som hjälper till att bygga ett sammansvetsat och välfungerande team.