Mennesker har jobbet sammen om problemer så lenge vi har eksistert. Arkeologer har funnet tydelige bevis på at Homo Erectus var dyktige til å samarbeide allerede for nesten 2 millioner år siden.
Dette har vi vært dyktige på helt fram til IT-alderen og programmereren oppstod. Mutters alene har programmereren programmert sine programmer i ensomhet, helt fram til ganske nylig.
For kort tid siden ble nemlig samarbeid gjenoppdaget blant programmerere, og går som en slags farsott gjennom utviklingsmiljøene under det fiffige navnet “Mobbing”, eller “Mob programming”.
Programmererens ensomhet
Samarbeid er vanskelig for en programmerer. Over mange år i ensomhet har hver enkelt programmerer utviklet en helt egen, unik måte å programmere på. En måte å jobbe på som vi aldri har delt med noen.
Det eneste vi stolt viser fram er ferdig kode. Når den siste indent er på plass, når alle metodenavnene gir mening og vi er helt sikre på at koden tåler dagens lys, først da pusher vi til versjonskontroll og ber en kollega ta kodegjennomgang. Etterpå sitter vi med en følelse av at dette kunne nok noen, en eller annen plass, ha gjort bedre. Det frister å refaktorere litt.
Nå bør alle utviklere kunne fullstack
Programmerere hater når noen kommer snikende på dem bakfra og titter over skulderen mens de jobber. De føler seg blottlagt. Naken. Som om det finnes en åpen dør inn til de innerste hemmeligheter og noen står og stirrer inn, leter etter suboptimale metodikker.
Samarbeid blant programmerere er kontroversielt.
Samarbeid med kjøreregler
Mob-programmering ble første gang omtalt i 2003 som en metodikk innen Ekstrem-programmering, og en utvidelse av par-programmering. Alle programmerere har hørt om par-programmering, men få har gjort det mer enn en håndfull ganger.
Mob-programmererens far, Moses Hohman, beskriver at han nærmest snublet over denne måten å jobbe på da teamet hans prøvde å omstille seg til å jobbe mer smidig i starten av 2000-tallet. Han beskriver mob-programmering slik:
«Hele teamet, jobber samtidig, på det samme problemet, på den samme datamaskinen»
For vanlige folk høres dette ut som helt vanlig samarbeid, og det er jo det. Vi snakker her om et helt team, på 3 til 5 utviklere som sitter rundt et bord og ser på samme skjerm. En av dem sitter ved tastaturet, og resten diskuterer hva han skal skrive. Et mareritt, tenker noen. Hvordan kan dette være effektivt? tenker andre. Men det er lurt. Og det er effektivt. Jeg skal forklare straks.
Og, ja, for en stakkars introvert programmerer høres dette ut som et mareritt. Ikke bare en, men hele teamet skal se ham over skulderen og se på mens han koder. Det er åpenbart at vi trenger en regel.
«Regel 1: Alle må sitte ved tastaturet etter tur»
Sånn. Da er det i det minste like ille for alle. Det vanligste er at hver enkelt sitter ved tastaturet en fastsatt tid, gjerne 10 minutter, før det rulleres til nestemann.
Det er smertefullt i starten, men det går over. Noen i teamet har merkelige måter å jobbe på. Kanskje skriver han bare tullenavn på metodene sine
«public List asdfasdf()»
Fordi han, jo, ikke vet nøyaktig hva metoden kommer til å gjøre, han har jo ikke skrevet den ferdig ennå, så da vil han ha et mye bedre grunnlag til å gi metoden korrekt navn senere. Resten av teamet klarer ikke å forholde seg til dette, så det slutter han med. Snart har teamet lært av hverandre, og funnet lure måter å kode på som funker for hele teamet. Det er ikke lenger skummelt at de andre ser på mens du koder.
Regel 1 er faktisk den eneste regelen. Mange har forsøkt å lage flere regler og definere flere roller for deltakerne fordi de synes en regel er for lite, men det er stort sett bare bortkastet. Bortkastet fordi den store styrken til mob-programmering er at etter en stund sitter alle deltakerne med den samme kunnskapen om koden, den samme innsikten i problemet, og den samme visjonen om hvor de skal. Teamet har blitt en superorganisme.
Det gir ikke mening å samarbeide
En annen av grunnene til at det er vanskelig å samarbeide blant programmerere, er argumentet om at det umulig kan være effektivt. Hvis 4 personer skal sitte ved ett tastatur, vil det jo åpenbart ta 4 ganger så lang tid å skrive ferdig koden!
Koding er tross alt en øvelse i å trykke ned taster i rett rekkefølge så fort som mulig. Det framstår i hvert fall slik for produkteieren. Kanskje for prosjektlederen også. Sannheten er at det meste av jobben er tenking og problemløsing. Arkitektur og modellering. Kvalitet og ytelse. Bruksopplevelse og universell utforming. 4 hjerner tenker bedre enn 1, og i hvert fall 4 hjerner som har samme mentale modell for prosjektet.
TUT!
Mitt team er et nysgjerrig team, som gjerne prøver ny teknologi og metodikk. Vi lager TUT, en progressiv web-applikasjon for SpareBank 1 Finans, for trygt salg av bruktbil mellom privatpersoner.
Da vi skulle implementere en ny, stor, feature i prosjektet ville vi samtidig introdusere ny teknologi som en del av løsningen. Ny teknologi som ingen kunne fra før, men som Sjur hadde lest om.
Vi bestemte oss for å implementere det ved å bruke mob-programmering i håp om at det skulle hjelpe oss med å få en felles forståelse for hvordan den nye teknologien og featuren virket. Vi er heldige som har en produkteier som har tillit til oss, og lar oss prøve.
Vi gir hverandre hjemmelekse å lese oss opp på teknologien. Neste dag møtes vi for å gjennomgå problemstillingen og skissere opp arkitektur. Noen timer senere har vi en god forståelse av hvor vi skal, og hvordan det skal løses.
Teamet skisserer hvordan et forhåndsgodkjent finansieringsbevis skal løses
Vi setter oss ned foran det ensomme tastaturet og begynner å mobbe. Vi skreller av hverandres uvaner, vi lærer hverandre smarte måter å kode på. Vi tar tiden. Det var ikke så skummelt å sitte ved tastaturet; diskusjonen går ivrig på flankene og jeg blir nærmest diktert hva jeg skal skrive. Skal vi skrive enhetstesten først? Så klart vi skriver enhetstesten først! La oss gjøre det riktig.
Tempoet er høyt. En av teammedlemmene har en smart måte å angripe problemet på. Han har klekket ut en plan, men kanskje ikke tenkt den helt igjennom. Mens han forklarer planen tenker en annen, og når førstemann begynner å gå tom for plan, har nestemann en ide om hvordan den skal tas videre.
Joakim startet eget selskap:
- Det beste er friheten
Det går slag i slag, tastaturet gløder og vi kommer på at vi har glemt å ta pauser! Vi tar pause sammen. Henter kaffe. Ler av noe. Ingen sitter på facebook. I løpet av pausen har noen fått en ide. Vi kjører på.
Vi fortsetter slik i flere dager. Etter endt arbeidsdag er vi slitne, men ikke utmattet. Den typen sliten du er etter en god trening; sliten men oppstemt. Problemstillingen er komplisert og omfattende, men sammen har vi kontroll.
Når featuren til slutt er implementer og teknologien tatt i bruk, sitter hele teamet igjen med full oversikt over koden og hvorfor den ser ut slik den gjør. Kodegjennomgang fikk vi gratis. Hvis det kreves endringer på koden senere er vi alle like godt rustet til å gjøre endringen, og til å forstå hvordan koden må endres og hvilke følger det får. Hvis produkteieren har spørsmål om hvordan arkitekturen ser ut inne i den featuren der, kan hvem som helst av oss svare. Influensa? Noen har jogget seg av og brukket nesen? Ikke en risiko så lenge minst en av oss er på jobb.
Student-mobbing
I Kantega har vi tradisjon for å stille bachelor- og master-oppgaver til studentene ved dataingeniørlinja ved NTNU. Denne gangen skal studentene lage et verktøy for Statens Vegvesen.
Et verktøy som gir dataforvalterne ved Vegvesenet oversikt over innrapporterte mangler og feil på veger og ting langs vegnettet, og som gir de mulighet til å planlegge og iverksette utbedring. Det er en utfordrende oppgave i et komplisert domene.
Studentene skal, som en del av oppgaven, gjennomføre hele prosjektet i mob. Vi har stuet dem inn på biblioteket, og der sitter de foran en diger skjerm og koder på ett tastatur. Iveren er stor, og det er spesielt morsomt å høre på dem når de forteller om erfaringer de gjør seg. Vi har sprint-demo hver 14. dag, og det er tydelig at her er det 3 studenter med full oversikt og som løfter hverandre. For oss er det lett å veilede superorganismen på biblioteket.
