Utveckling på Bonnier Broadcasting

Bonnier Broadcasting, som har en av Sveriges mest intressanta utvecklingsavdelningar jobbar vi dagligen med utveckling. Vi utvecklar avancerade applikationer, system och verktyg för videoströmmar både med och utan reklam på olika plattformar och miljöer. TV4 Play, C More, köket.se och fotbollskanalen.se är några av våra starka varumärken som alla utvecklas och underhålls här.

Nog för att produkterna är viktiga men viktigast är kanske ändå den personliga utvecklingen. Inte bara sin egen personliga utveckling utan även medarbetares och kollegors utveckling. Om personalen utvecklas, är stimulerad och har kul blir också produkterna det.

Men hur görs då detta?

Det kan ju låta ganska ambitiöst. Men med rätt inställning, rätt förutsättningar och uppbackning av kollegor och arbetsgivare är det möjligt.
Vi premieras att möta nya utmaningar och får dagligen jobba med stimulerande problemlösning. Vi ligger långt framme med till exempel lean- och mob-programmering. Mob-programmering är ett utmärkt sätt att enkelt våga pröva något nytt och att snabbt vara produktiv även om språk och miljöer inte är de man behärskar bäst eller kanske rent av inte kan alls. Genom att lösa problem tillsammans blir den individuella utvecklingen en del av gruppens utveckling. Där man nu förhoppningsvis har skapat både förståelse av både sig själv och gruppen, samt programspråk, ramverk och produkten man jobbat på.

Vi försöker bygga våra system i små moduler – mikrotjänster. Detta förenklar skalning och hjälper oss att undvika hårt kopplade system. Komplexiteten i tjänsten minskar och blir mer lättarbetad eftersom varje tjänst försöker lösa ett specifikt problem. Det är helt enkelt lättare att jobba med mindre kod och ett begränsat scope. Enkelhet ger snabbhet och snabbhet ger stimulans. Självklart får det ju inte bli för enkelt så att man slentrianmässigt bara slänger ihop nåt utan att tänka på vad man gör, men det är sällan programutveckling blir “för enkelt”. Lägg till faktorn miljoner användare, gärna med personaliserat data och datatunga videoströmmar så får du se. Enkelhet gör också att man kan ta sig tid att lägga till enhetstester och hinna med refaktorering.

Till våra tjänster och system försöker vi använda oss av moderna språk som Go, Elixir och Swift. Även om vi också använder Ruby, Java, C# och självklart JavaScript, HTML och CSS. D.v.s. vi väljer språk och ramverk efter problemet vi ska lösa, inte för att det är förutbestämt. Detta hjälper oss se för- och nackdelar med olika språk och ramverk.

Samma anda gäller när det gäller molntjänster, även om vår primära tjänsteleverantör är AWS/Heroku för plattform, Travis CI för byggen och GitHub för koden. Dessa miljöer gör det enkelt att arbeta ifrån olika platser eller att snabbt kunna pröva något vilket också främjar utvecklingen av både produkterna och utvecklarna själva.

En annan faktor som bidrar till utvecklingen är att vi håller meetups och låter anställda åka till intressanta konferenser, som bland annat dotGo i Paris och Full Stack Fest i Barcelona. För de som vill ges möjligheten att presentera bolaget och våra produkter på olika arbetsmarknadsdagar och mässor.

Vi har ju också sedvanliga medarbetarsamtal och undersökningar med fokus på retrospektiv. Vi arbetar också med feedback för att förstärka det som är positivt och utveckla det som kan bli bättre. Både personlig och teknisk återkoppling är viktigt för att lärdomar ska förankras och se till att alla är på rätt spår. Det är viktigt att alla får vara med och att allas åsikter beaktas. Därför tycker vi att team med en bred mångfald är att föredra, speciellt när man som vi utvecklar tjänster som används av många olika användare.

Tillsammans får vi en stimulerande och utvecklande miljö där vi levererar produkter som vi kan vara stolta över.

Om du som jag tycker att detta verkar spännande och vill vara med och utveckla och utvecklas, kolla in våra lediga tjänster på http://bonnierbroadcasting.com/jobba-pa-bonnier-broadcasting/.

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)

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.

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.

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.

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

Taks

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.