Lättrörlig utveckling i Helsingborg 18/5 2004

Varför lyckas vi inte bättre?

Det finns mängder med fantastisk teknik som vi kan utveckla programvara med. Massor. Det finns inga gränser för vad vi kan göra. Men vi känner samtidigt att kraven ökar på att man skall hänga med på allt fler plattformar, verktyg och "teknologier" (underbart begrepp för allt från kapsylöppnare till rymdskyttlar). Vi hinner alltmer sällan bli riktigt bekanta med våra verktygs alla möjligheter innan ett nytt teknikskifte kräver vår uppmärksamhet. Ändå skall vi samtidigt hinna utveckla rätt produkt till rätt pris.

Hur kul är det att vara kund, då? Som kund/beställare krävs det att vi skall ha "beställarkompetens", vilket ofta blir att agera arg konsument och slug avtalsjurist om vartannat. Vi skall minsann fixa fram valuta för företagets pengar. Men samtidigt skall vi göra tillräckligt bra förarbete för att kunna begära fast pris på vår kravspecifikation. Och priset måste vi pressa. Helst skall utvecklarna inte ha "gott mått", det kostar pengar. Man vill ha "högt tryck i projekten".

Vi har sökt lösningar i omfattande dokument- och verktygs-drivna utvecklingsprocesser där vi säkerhetsställer att vi vet vad vi ger oss in på, helst innan vi fått erfarenheter "den hårda vägen", eller kanske egentligen fått känsla för och kläm på vad vi egentligen skulle bygga.

För utvecklarna innebär det att allt mer tid går åt för att lära sig verktyg som istället för programvara producerar papper med tveksamt värde, åtminstone efter projektslutet. Få projekt har råd att hålla en "komplett" up-to-date detaljdokumentation.

För beställare, kund (eller produktchef om det gäller produktutveckling) innebär det att vi skall ta beslut och prioritera om vad som skall göras för "våra" pengar efter att ha tagit del av digra, ofta metertjocka, luntor med underlag.

Alla kan inte åka till månen

Men "tunga" utvecklingsprocesser fungerar ju inte av egen kraft! Det har dom aldrig gjort. Väl fungerande projekt bygger på att alla lever sig in i och får en klar bild av vad vi försöker åstadkomma.

Kennedy kunde sina vision-statements! De flesta projekt-kickoff's ter sig bleka i jämförelse. Man satte dock inte människor på månen tack vare dokumentdriven utveckling. Utan med starkt fokus i hela landet från presidenten och neråt. Det var också yttre hot i form av kapplöpning med Ryssland. Det var dramatik. Hela världen följde mån-programmets misslyckanden och framgångar.

Vi har alltför länge försökt efterlikna de formella processerna i miltär- och rymd-industrins mest framgångsrika utvecklingsprojekt, men glömt bort att våra mål, behov och förutsättningar sannolikt är annorlunda.

För några år sedan fick Erik Lundh chansen att vara med och tänka till på hur team från olika företag med olika utvecklingstradition skulle kunna jobba tillsammans under samma tak, grannar med högskolan. Man kunde dock gissa att närmast religiösa strider kunde komma att utkämpas om vems formella utvecklingsprocess som var bäst.

Lättviktiga processer?

XP är en så kallad lättviktsprocess. På svenska låter det som om den väger lätt, men på engelska tänker man direkt på motpolen till de tungviktsmetoder som förlamat många utvecklingsorganisationer. Fram till 2001 var "light-weight processes" gängse samlingsnamn på XP och ett antal likasinnade processer.

Agile

Men lättviktsprocesser började inte med XP. Det fanns redan ett antal etablerade, dock med mindre genomslagskraft än XP kom att ha: DSDM , SCRUM, FDD etc.

Agile Development, lättrörlig utveckling är nu ett samlingsnamn på ett antal metoder som bygger på samma grundidé men med lite olika fokus

En översikt över olika agile-metoder och dess utövare finner du i boken Agile Software Development Ecosystems.

Däremot är Agile ingen egen metod. Det är ett samlingsbegrepp. Vi körde alltså agile-projekt redan år 2000, med agile-metoden eXtreme Programming som utvecklingsprocess. Jag vet att några på Ericsson började pröva XP redan 1999.

Design då?

Så här kan livet te sig för ett team som börjar med lättrörlig utveckling:

Teamet har valt att arbeta enligt den lättrörliga metoden eXtreme Programming (XP). Man börjar projektet med ett planeringsmöte. En eller flera "kunder", dvs folk med kund eller beställar-perspektiv sitter på ena sidan bordet. Utvecklare på den andra sidan. Alla ingår dock i samma team. Kunderna skriver funktioner och egenskaper styckvis på kort som sorteras efter prioritet. Utvecklarna tidsuppskattar korten en första gång. Kunderna tar sig en funderar och eventuellt prioriterar om för att få med det viktigaste vägt mot tidsåtgång. Utvecklarna åtar sig vid varje planeringsmöte bara så mycket som ryms i normal arbetstid under två veckor. Men teamet, både kunder och utvecklare, anstränger sig för att hitta det som är värdefullast att få fram just nu. I andra steget bryter utvecklarna ner kund-korten i utvecklaruppgifter på nya kort. Man uppdaterar sina tidsuppskattningar med den nya detaljnivån och uppdaterar tidsuppskattningarna på kundkorten. Kunden får sedan åter avgöra vad som är viktigast att få fram till nästa leverans om två veckor.

Under varje tvåveckors-period lär sig både kunder och utvecklare mer om det man håller på att bygga. Det kan bero på att man släpper ut den förra periodens produkt till en grupp testpiloter. Det kan bero på att man är ute och talar med de som möter konsumenten. Därför har perspektivet ofta förfinats efter två veckor. Man börjar också varje planeringsmöte (utom det första om det är en helt ny produkt) med att titta på leveransen av de två gångna veckorna. Man installerar gärna produkten från scratch , demonstrerar och kör acceptanstester. Först därefter, med ett färskt intryck av produkten, sätter man sig och jobbar fram vilka funktioner som är viktigast att få med de kommande två veckorna.

Planeringsmöte i lättrörligt pilotprojekt hos ABB

Själva utvecklingen sker så här:

Varje dag inleds med 5 min standup-möte kl 9.00 Alla står upp för att det inte skall dra ut på tiden. Man kollar av vad alla gjort sedan igår och tänker göra idag.

Alla utvecklare jobbar i par. En individ börjar med att plocka en utvecklaruppgift, ett löst kort. Man plockar alltid uppgifter i prioritetsordning utan hänsyn till egen kompetens eller svårighetsgrad. Sedan ber man en kollega jobba som parhäst enbart för denna uppgift. Pararbete är obligatoriskt för allt som blir skarp kod och går till leverans. En liknelse är kirurgen som gör en kritisk operation, då står det alltid en annan kirurg bredvid, följer varje snitt noga, ger råd och kan gripa in.

Paret börjar med att plocka ut produktens senaste integrerade kodbas från versionskontrollen och bekantar sig med problemet genom att skriva några testfall. Testfallen skrivs i det språk man utvecklar med, inte i specialverktyg som kräver inlärning. Därefter jobbar paret sig fram till en lösning på det problem som man formulerat som testfall. Kanske inser man efter ett tag att man inte förstått hela problemet och justerar eller lägger till fler testfall. När alla testfall är uppfyllda "städar man köket efter sig", dvs man gör en refactoring. Ibland blir det bättre om man gör testfall, kod och refactoring flera gånger fortlöpande. Vissa snitsiga kockar har t o m diskat klart grytorna när maten skall serveras.

När alla testfall kör och man städat efter sig skall koden integreras. Då kör man först fler testfall och acceptanstest. Därefter plockar man ner senaste kodbas, andra par har troligen hunnit slutföra och integrera några utvecklar-kort sedan paret började. Blir det för svårt att leverera in koden, dvs integrera i den gemensamma kodbasen, överväger paret att kasta bort koden och börja från början. Ibland vinner man mycket tid på det. Ingen kod är helig, det är tankar och insikter bakom som är värdet.

Vissa team integrerar, ett par i taget, med en fysisk stafettpinne, kanske en tung gammal manual, eller går bort till en speciell integrationsmaskin. Andra team har teknikstöd i form av verktyg för automatisk kontinuerlig integration, ex populära CruiseControl, ett gratisverktyg som finns för både Java och .NET. De flesta verktyg bevakar en gren i versionskontrollen. Denna gren skall man bara checka in i när man blivit klar med integration. Verktyget startar ett bygge för varje integrerad incheckning, bygger sedan installationskit, installerar i en nollställd testmiljö, och kör stora sviter automatiska acceptanstester. När allt är på plats kan teamet veta att man alltid har ett installationskit för produkten klart med alla de funktioner som passerat alla tester och byggen. Det kan finnas mer funktioner uppströms i systemet, men det som passerat så långt att det kommit ur sista testen är mycket säkrare att demonstrera för utomstående.

Teamet undviker övertid, för att i längden orka jobba intensivt och entusiastiskt på ordinarie arbetstid. Regeln "40 hour week" tillämpar vi i praktiken så att man inte jobbar övertid mer än någon enstaka gång. Vi jobbar aldrig över två veckor i följd.

Leverans varannan vecka

Varje tvåveckorsperiod avsluta med ett nytt planeringsmöte där man börjar med att titta på produkten som den ser ut efter de två senaste veckornas utveckling. Enbart funktioner som passerat alla tester ingår. Man installerar om möjligt från scratch, kör acceptanstester och demonstrerar de nya funktionerna. Först därefter, när alla har ett färskt intryck av dagsläget, börjar man plocka fram de kund-kort som är vikigast att få införda de kommande två veckorna. Förloppet är detsamma som vid planeringsmötet två veckor tidigare.

Varannan vecka får man en reality-check i form av en release. Utvecklarna kan inte skjuta på releasen, kunder kan inte inbilla sig att mer skall magiskt komma in än vad man faktiskt kan få in på 14 dagar. Marknadsfolk och projektsäljare är utmärkta i kundrollen. Utvecklarna retar ofta sig på att säljarna lovar för mycket.

Är säljaren med som kund kan man inte blunda för vad som krävs för att erbjuda en viss funktion. Man måste själv vara med och prioritera fram rätt. Till utvecklarnas förvåning älskar de flesta på säljsidan att vara med som kunder. Man får mer känsla för vad som är möjligt att erbjuda sina kunder och kan fortlöpande prioritera fram funktioner från färska marknadssignaler.

Men det blir väldigt synligt om någon medlem, kund eller utvecklare, prioriterar annat och uteblir från den gemensamma, viktiga, release-och-planerings-dagen varannan vecka.

Andra projekt kan lita på att vi har en ny integrerad produktversion att släppa, exakt på dagen, var 14:e dag. Man kan lita på dessa releasedatum var 14:e dag, de är huggna i sten, det kallas ibland time-boxing. Projektledare i större projekt älskar delprojekt som tillämpar strikt time-boxing!