Mobbeprogrammering - 5 utviklere på én datamaskin?!

Eksperimenter for å forbedre prosessene våre er en del av det daglige arbeidet vårt. Så når jeg hører om noe som kan hjelpe oss med å bli bedre, vil jeg undersøke det. I begynnelsen av 2019 ble jeg med på Domain Driven Design Europe-konferansen. I pausene snakket jeg mye med andre deltakere, for det meste utviklere.

I mange av disse samtalene kom workshopen Mob-programmering fra konferansen året før opp. Utviklerne var veldig, veldig begeistret for mob-programmering: flere utviklere som jobber i samme rom på en enkelt PC. De forklarte hvor mye de hadde lært og vokst som team som et resultat av disse øktene. Det var et tydelig signal til meg om at jeg måtte lære mer om dette. Etter det bestemte jeg meg for at vi skulle eksperimentere med det.

En viktig del av et eksperiment er hypotesen. Uten den vet du ikke om eksperimentet var vellykket. Min teori var at mob-programmering ville hjelpe oss med å dele kunnskap mellom utviklere og samtidig bygge ren kode.

Jeg planla og forberedte vår første mobbeprogrammeringsøkt, noe som ikke var så vanskelig:

• Få en datamaskin koblet til en storskjerm

• Plasser et bord foran skjermen.

• Legg til fem sitteplasser ved bordet.

• Sett litt snacks og utstyr på bordet.

Og der satt vi, fem utviklere i et rom med bare én datamaskin:

Hva skjedde under vår første mob-programmeringsøkt?

Wesley setter seg ved tastaturet (vi bruker PC-en hans) og blir automatisk tildelt rollen som driver. Sjåføren er en intelligent inndataenhet: Han kan skrive, men har ikke lov til å ta beslutninger. De andre utviklerne får rollen som navigatør. Det er de som diskuterer hva som skal skje, og forteller sjåføren hva han eller hun skal gjøre.

Sjåføren er en intelligent inndataenhet: Han kan skrive, men har ikke lov til å ta beslutninger

Vi begynner å jobbe med en enkel oppvarmingshistorie der vi må fjerne noe utdatert innhold i bunnteksten på nettstedet.

Navigatørene ber Wesley om å starte Docker. Vi ser umiddelbart en feilmelding. Wesley forklarer at dette skjer av og til, men at det alltid løses med et par nye forsøk. Vi prøver ikke på nytt, men navigatørene forklarer hvilke innstillinger som må endres. Fra nå av starter Docker alltid uten feil;

Wesley skriver på en lapp hva han har lært om Docker. Han setter denne lappen på det store arket som heter Learnings.

Jeg skriver på en lapp at det at Docker ikke startet, holdt oss tilbake. Jeg gir den til Waste Snake, et stort ark med en slange tegnet på. På dette arket setter du lapper som beskriver alt som hindrer gjengen i å programmere:

Etter 12 minutter lyder en summer. Alle må skifte til høyre. Sjåføren blir navigatør, og en av navigatørene blir sjåfør. Det er litt tungvint, og det tar litt tid å komme i gang igjen. Men vi blir mye flinkere til det etter et par bytter.

Vi avslutter historien og begynner å jobbe med den neste: Yii2-visning forårsaker falske kommentarer i HTML, noe som fører til ugyldiggjøring av HTML. En interessant historie. Den har allerede blitt plukket opp to ganger av forskjellige utviklere, men begge har kjørt seg fast. Alle bidrar med historien. Til slutt løser vi problemet på en måte som alle er veldig fornøyde med.

Etter to timer avsluttes økten.

Hva lærte vi av vår første mob-programmeringsøkt?

Vi har et retrospektivt møte for å diskutere hva som gikk bra og hva vi kan forbedre. Det viktigste vi kan ta med oss er at vi fikset historien bedre/ grundigere i én iterasjon enn om én person hadde jobbet med den alene.

Vi fikset historien bedre/ grundigere i én iterasjon enn om én person hadde jobbet med den alene.

Alle føler seg energiske under retrospektivet. Vi likte alle eksperimentet. Det blir tydelig at mob-programmering faktisk hjelper oss med å dele kunnskap samtidig som vi bygger ren kode.

De fleste lærdommene var ganske åpenbare, som når en snarvei var ukjent for driveren, eller konfigurering av verktøy for å hjelpe deg mer effektivt. Det ble tydelig hvor lett det er å sløse bort tid i utviklingsprosessen ved å bruke omgåelser hvis et system oppfører seg uventet. Dette bekrefter behovet for å ta i bruk forbedringskataen.

Andre erfaringer var mer subtile. For eksempel å finne måter å dele opp et vanskelig problem i mindre problemer. Eller forslagene om hvordan man virkelig kan jobbe testdrevet ved først å lage en mislykket test i stedet for bare å legge til en test i etterkant.

Eksperimentet lyktes! Neste økt er umiddelbart planlagt

Noe av det som var vanskeligst å få til, var kommunikasjonen mellom navigatørene og sjåføren. Du ønsker ikke å stave alt, spesielt ikke for de mer erfarne utviklerne. Men du vil heller ikke at en yngre utvikler skal føle at han eller hun blir kastet ut på dypt vann. Over tid lærer mobben hvordan de skal henvende seg til de enkelte driverne på riktig måte.

Programmering av fjernstyrt mob

I Nederland er vi for øyeblikket i en lockdown. Kontoret vårt er stengt, og alle jobber eksternt. Dette gjør det umulig å gjennomføre mob-programmering som beskrevet ovenfor, fordi vi ikke kan være i samme rom.

Vi ønsket likevel å gjennomføre mob-programmeringsøkter. Gjennom prøving og feiling kom vi frem til følgende for en utmerket ekstern mob-programmeringsøkt:

• Alle har webkamera, og alle slår det på under en økt.

• Vi bruker Whereby som vertskap for møtene våre, fordi man kan dele skjermen og likevel se hverandres kamerastrømmer.

• Sjåføren logger seg på en dedikert datamaskin via en eksternt skrivebord-tilkobling (vi opprettet en mob-brukerkonto på det interne nettverket for dette).

• Vi opprettet en egen mob-brukerkonto for Git. Dette gjør det veldig enkelt å bytte roller.

Hvordan kan jeg eksperimentere med dette i mitt eget arbeidsmiljø?

Av alle artiklene, bloggene og e-bøkene jeg har lest om mob-programmering, kan jeg på det sterkeste anbefale å lese disse to:

• The Mob Programming Guidebook (nylig omdøpt til Ensemble Programming Guidebook) av Maaret Pyhäjärvi.

• Mob Programming - A Whole Team Approach av Woody Zuill.

Etter det er det bare å velge en dato med teamet ditt og prøve det ut. God fornøyelse!