Det här är en liten serie på tre delar om hur det gick till när Aftonbladet 2011/2012 bytte alla sina system för att registrera, logga in och ta betalt av kunder online. Jag deltog som utvecklare i teamet som fick i uppdrag att ro projektet i land. I den här tredje och sista delen dissar vi Agile, leker NASA och genomför Dagen D.

Läs först del 1 och del 2.

Vad är mer Agile än Agile?

Vad gäller teamets arbetssätt under denna implementationsfasen i projektet gjorde vi tidigt ett intressant vägval. Vi var ganska väl intrimmade på agil utvecklingsmetodik, men vi kom fram till att projektet innebar ganska lite traditionell programmering av typen “skriv en applikation och lansera den”. Det mesta av koden var den nya fasaden och en massa script/kod för att batchknåda data i de gamla databaserna. Mycket av arbetet bestod av att utreda konsekvenser av att införa SPiD och komma fram till lösningar för att mildra eventuella negativa effekter. Vi visste i stora drag vilka områden som behövde åtgärdas och ungefär vad vi behövde göra, men i många fall skulle resultatet av en utredning eller åtgärd ge förutsättningarna för nästa.

Mot alla moderna utvecklingsprinciper satte vi först ett rimligt lanseringsdatum. Sedan skrev vi upp alla åtgärder vi kunde komma på – utan att tidsuppskatta dem – och grupperade dem på en tidsaxel, jämt distribuerade fram till lanseringsdatum. Vi visste helt enkelt att alla försök till en detaljerad tidsuppskattning skulle vara en lögn i ett så tidigt skede. Efterhand som projektet fortskred så kunde vi tidsuppskatta mer detaljerat det som vi hade framför oss. Detta måste ha varit otroligt läskigt för beställarna av projektet, eftersom vi bara kunde ge vaga svar på projektets framsteg. Det visar på vilket förtroende beställarna hade för teamet. När projektet var över kunde vi dock konstatera att vi bara behövde justera lanseringsdatum en gång från början av december 2011 till i slutet av januari 2012. Ganska bra kan man tycka, med tanke på projektets komplexitet. Det var dessutom ingen bra idé att lansera strax innan Jul/Nyår ifall något skulle går fel, då många skulle vara lediga.

Dagen D

Inför lanseringen av den nya plattformen hade vi sammanställt ett körschema för varje moment i lanseringen, d v s vem som skulle vad i vilken ordning. I största möjliga mån var varje åtgärd automatiserad i script som kördes igång vid lämplig tidpunkt. Många av åtgärderna var avslutande datatvättar av olika slag. Sedan följde bl a blockering av trafik, migrering av data, tester och omdirigering av trafik till nya plattformen. Några dagar innan lanseringen genomfördes en generalrepetition med alla inblandade i en för ändamålet bokad konferenslokal. Steg för steg gick vi igenom körschemat och utförde de manuella och automatiska punkterna i en kopia av den skarpa miljön. Hela tiden monitorerades systemen och de ansvariga för varje punkt ropade ut status på sina åtgärder. Nästan som en raketuppskjutning på NASA. När något inte fungerade som väntat noterades det så att det kunde fixas innan lansering.

Själva lanseringen startades kl 01.00 den 24/1-2012 och genomfördes enligt körschemat. En del av teamet körde migreringen, medan den andra delen var hemma och sov. Importen av användardata till den nya plattformen blev klar runt kl 05.30 på morgonen. Det var data för ca en halv miljon användarkonton som leverantören SPiD anpassade och lagrade i sina databaser. Runt kl 09.00 tog den andra delen av teamet över och nattens hjältar kunde åka hem till en välförtjänt vila. Under förmiddagen testades all funktionalitet internt av aftonbladare med hjälp av vitlistade användarkonton. Sedan kunde Aftonbladets tjänster, t ex aftonbladet.se och Vitklubb.se stegvis gå över till att logga in och genomföra köp via SPiD. Kl 15.00 Släpptes all trafik på till SPiD och lanseringen var slutförd.

De dagar som följde ägnades åt trimma in den nya plattformen. Lyckligtvis var det inga större problem som uppstod i kölvattnet av lanseringen. Det kunde vara detaljer som t ex justeringar av när cookies skulle bli inaktuella, vilket påverkar inloggningen; eller missvisande texter på försäljningssidor för prenumerationer. Äntligen kunde vi andas ut efter nästan ett års förberedelser.

Slutsatser

Det var ett tag sedan lanseringen nu i skrivande stund (augusti 2012) och uppföljning gör sig bäst strax efter man genomfört något. Det finns dock några saker som slår mig även så här efter lång tid:

• Leta förutsättningslöst efter lösningar. Ibland ligger bästa lösningen närmare än du tror. I en annan mer prestigeladdad organisation än Aftonbladet hade det varit svårt att acceptera att ett systerföretag inom koncernen tagit fram en bättre lösning än vi. Känns skönt att vi kommit förbi “Not invented here” som annars är vanligt inom mjukvaruutveckling.
• Underskatta inte betydelsen av samarbete. Jag vill göra gällande att vår leverantörs vilja att samarbeta är en stor del av framgången med införandet av nya plattformen. Det hjälpte förstås att vi samarbetade inom en koncern, men det brukar inte vara någon garanti i andra organisationer. Vi etablerade också tidigt en enda kanal (Skype) för kommunikation där vi blandade högt och lågt. Alla lyssnade på den konversationen och det var en låg tröskel för att ställa frågor, vilket gjorde att hinder kunde undanröjas hyfsat snabbt. Jag kan inte föreställa mig att vi skulle haft ett lika bra samarbete med en amerikansk SaaS-tjänst.
• Körschema och generalrepetition var en förutsättning för framgång. Martin Börlin hade framgångsrikt genomfört en lansering med ett körschema och en generalrepetition här på AB. Jag tycker att det var smart att lära oss av det receptet. Att simulera en skarp situation gör att man skärper sig. Om något går fel under genrepet är det lätt att föreställa sig hur kul det skulle vara i skarpt läge sedan. Därför tror jag att det är viktigt att försöka skapa känsla av skarpt läge så att man inte tar genrepet med en klackspark.
• Underhållet är nu att få Release Notes i mailen. Ett vanligt problem för utvecklare är att ju mer man utvecklar, desto mer måste har man att underhålla. Till slut kan man inte utveckla mer eftersom all tid går till underhåll. Det kändes otroligt skönt att kunna lämna vidareutvecklingen av plattformen till leverantören och underhållet av integrationen mot plattformen till en serviceorganisation. Vi har därmed kunnat ta oss an nya projekt som fått vänta p g a resursbrist.
• Äntligen kan vi lägga ned betalutvecklingsteamet. Egentligen inget konstigt eftersom vi nu har en extern leverantör av betalplattform. Det är dock inte alltid självklart för utvecklingsteam att jobba för att de inte ska behövas längre. Det borde vara det, tycker jag.
• Hur kunde vi börja projektet utan att ha tidskuppskattat det? Jag är fortfarande imponerad av hur lite vi uppskattade från början hur lång tid saker skulle ta. Mycket styrdes dock av leverantörens tidsplan. Så här i efterhand tycker jag att vi gjorde rätt. Vi hade kunnat bryta ned allting i atomer och ägna otroligt lång tid till att estimera tidsåtgång för allting, men det hade troligtvis varit slöseri med tid och gett oss en falsk känsla av kontroll. Mycket att det vi hade framför oss när vi startade var av undersökande natur. Det enda som var konkret utveckling var integrationslagret mellan tjänsterna och SPiD.

Särskilt omnämnande

Slutligen vill jag bara sjunga lite om de som ofta är osjungna när det lanseras nya produkter – utvecklarteamet. Tack för att jag fick vara med och jobba med er:
Adam Miller (Utvecklare, AB)
Erik Fried (Utvecklare, AB)
Hans-Göran Persson (Projektledare, AB)
Mats Strandberg (Utvecklare, Crisp)
Mikael Thorsson (Utvecklare, Cygni)
Ulf Liedberg (Utvecklare, Netlight)
Joakim Wånggren (Utvecklare, Netlight/Schibsted)
Thomas Andersson (Utvecklare, Netlight)
Peter Lindgren (Utvecklare, Netlight)

Det här var den sista delen i en serie av tre. Tack för att du följde mig ända hit.

Eventuella synpunkter tas gärna emot på Twitter @ocklund