Lärdomar av mobbprogrammering (första veckorna)

 Fas 0: Förvirring

Högst upp på teamets att-göra-lista, vid arbetsstart efter julledigheterna, var att utmana oss själva och utforska nya arbetsmetoder. Agila arbetssätt, testdriven utveckling och kontinuerlig leverans har vi jobbat med och optimerat i flera år nu, finjusteringar är fortfarande nödvändiga, men vi kände behov att ta nästa steg vidare. En reflektion var att den sociala aspekten ofta prioriteras lägre än teknik inom teamet. Verktyg som parprogrammering, demo, kodgranskning och pull requests underlättar samarbetet men resultatet var ändå starka personberoenden till tjänster och uppgifter.

Mobb-teamens starka fördel är kunskapsväxling bland team-medlemmarna. Ensamma vargar infogar sig i ledet och blir inte i lika stor utsträckning som innan öar av kunskap i organisationen. En av riskerna är att mobbprogrammering kan vara påfrestande för många – t.ex. genom att vistas i ett så socialt sammanhang under lång tid kan leda till att mer introverta personer tappar energi. Vår rekommendation är att sätta av tid varje dag för reflektioner och förbättringar av arbetsprocessen för att undvika konflikter.

För att komma igång och undanröja vissa farhågor var det viktigt att avsätta tid för att diskutera saker som:

  • Vilka utvecklingsmiljöer och språk ska vi använda
  • Undvika bakterier på tangentbordet
  • Nu hinner jag inte göra vad jag ska göra
  • Alla rum är upptagna var ska vi vara
  • Har jag ett eget arbetsbord att gå till?

Fas 1: Insikt (Workshop med Woody Zuill)

Med lite flyt fick vi bokat en heldagsworkshop med Woody Zuill. Med praktiska och teoretiska övningar var gruppen snabbt mentalt redo för att starta på riktigt.

En lärdom från denna fas är att det viktigaste är att komma igång. Metod och process går att justera i efterhand. Teamet måste jobba fram arbetsprocessen själv och det är extra viktigt att alla kommunicerar på ett hjälpsamt sätt.

 

Fas 2: Installationsfasen

Återigen hade vi turen på vår sida och det fanns en möjlighet att ockuperad en yta väl ägnad för teamets behov. Bord, stolar, whiteboards, TV och soffor fanns på plats, annan hårdvara fick vi installera själv.

  • Möblera om till kommandocentral-stil
  • Stor TV-skärm av god kvalitet! (LG)
  • Dedikerad dator för teamet (Mac Mini)
  • Nätverksrouter – wi-fi
  • Trådlös mus och tangentbord (Apple)
  • Apple TV till skärmdelning
  • Konton (tvåfaktorsautentisering med YubiKey)
IMG_0415

Vi är i gång!

I denna fas fick mobben anpassas till varandras konstigheter. Vi ägnade tid åt att hitta bra gemensamma lösningar för dator- och tangentbords-inställningar. Känslan är att vi kom igång med kodande direkt och efter 5 dagar hade vi så pass mycket på plats att extern dator inte alls var nödvändig i kodningen.

image

Fas 4: Flytfas

Så tidigt som första dagen sjönk tröskeln tillräckligt för att alla skulle våga byta tjänster, språk och IDE. Två dagar senare hade mobben skrivit kod i Elixir, Go, Ruby och Python samt bytt mellan ett flertal IDE-er. En extra rolig och oväntat positiv följdeffekt var positiv respons från nyfikna kollegor. Flera team har kopierat upplägget och just nu känns det inte som ett reellt alternativ att gå tillbaks till gamla mönster.

Vi tror mobben har stärkt samarbetet över teamgränserna samt underlättat hopp mellan teamen både på kort och lång sikt.

Här har vi t.ex. besök av Elixir-skaparen José Valim som mobbar med oss en förmiddag.

IMG_0437

Fas 5: Vad nu

Nya bloggposter kommer att berätta vad vi gör i framtiden!

Kontinuerlig leverans på rätt sätt

Vi på TV4 har arbetat med kontinuerlig leverans de senaste fem åren som tidigare är beskrivit i ett flertal bloggposter. Dagligen gör vi flera kodändringar i produktion, hur kan vi det utan att störa för användare och affär? Under lister vi några bäst praxis principer vi försöker att leva efter for att kontinuerlig leverans ska fungerar för alla.

  • Teamen har fullt ansvar för tjänsten föra under och efter leverans
  • All kod måste ständigt kunna levereras till produktion
  • Vi väljer små leveranser ofta över stora leveranser mera sällan 
  • Beroende av tredjepartsverifieringar måste lösas så att det inte stör den kontinuerliga leveransen
  • Vi utvecklar enbart mot produktionsdata och produktionsapier.
  • Stagingmiljön är till envar tid uppdaterad med data från produktion och har så lik konfiguration som produktions miljön det går.
  • Vi använder brytare och miljövariabler för att ändra beteende på kod
  • Vi gör inga manuella steg i leveranserna
  • Alla deployer skall snabbt kunna rullas tillbaks som läget var innan – även miljövariabler
  • Kod ska ha tester och testarna ska köras innan leverans
  • Teknisk övervakning av tjänsterna måste finnas på plats för att analysera hur en ny leverans beter sig
  • Larm måste finnas på plats om något råkar bli fel i leveransen
  • Omedelbart efter leveransen måste man själv testa av önskad funktionalitet  i production
  • Vi utvecklar så att om fel uppstår så försämras inte användarupplevelsen
  • Innan deploy måste teamen värdera riskerna mot hur stabilt systemet är och värdet av leveransen vid givet tillfället
  • Sök och ge information till och av berörda partar innan, under och efter en ändringar genomförts

Vårstäda!

När våren kommer och solen skinner blir man sugen på att rensa och göra fint. Under veckan gick jag genom web-teamets pärm för utförde tasks, stories och features (2012 och 2013).

Tasks är oförutsedda uppgifter som dyker upp under veckan och inte ingår i det vanliga planerade arbetet. Vi använder gula post-its för ”kom-ihåg” lapper som går snabbt att åtgärda. Röda är buggar som genast måste åtgärdas. I normala fall estimerar vi inte hur lång tid en task men större tasks blir egna userstories.

Taks

På indexkort skriver vi userstories – flera userstories kan utgöra en feature och flera features kan utgöra en epic.

Taks

DSC_0423

Av vikt och storlek på pappershögarna finns det hundratals userstories och ungefärligen samma antal tasks.

Teamregler / Manifest

Vi rekommenderar att varje team utarbetar och underhåller några enkla riktlinjer som både nya och rutinerade team-medlemmar har nytta av.

Vi har arbetat fram flera versioner av regeldokumentet. Senaste uppdaterade varianten hittar ni under.

En señor(a) developer

Tar ansvar från kaktus till tequila
Deployar ofta till produktion
Håller mötesdisciplinen
Jobbar tillsammans
Hugger in där det behövs, från databas till pixel

“*Grav deg inn i snøen om nødvendig.”

http://fleecelabs.se/ manifest “11 saker vi lärt oss är kritiska för att lyckas med utvecklingsprojekt” är och har varit till stor inspiration och har nu hedersplatsen fastklistrat bredvid teamets regler.