May 2009

Jag skrev tidigare om några av problemen med mjukvaruutveckling och lovade att jag skulle berätta om scrum – den “lättrörliga” utvecklingsprocess som vi jobbar enligt. I det här inlägget tänker jag försöka skriva en liten introduktion till scrum. Jag har också tänkt att fortsättningsvis skriva inlägg om scrum och de för och nackdelar som jag upplevt under ett och ett halvt år med scrum.

Scrum är uppbyggt kring begreppet sprint. En sprint är en period på två till fyra veckor som upprepas om och om igen. Varje iteration innehåller utveckling, tillbakablickar och förbättring. Tanken är att man efter varje period får en verklighetskoll på att man gör rätt saker, det kunderna vill ha och har möjlighet att reagera på om man gör fel snabbt. Hela tiden försöker man också förbättra hur man utvecklar mjukvara genom att ha former för att fånga upp sådant som fungerar dåligt.

På pappret är scrum utöver sprinten tre roller, tre artifakter och fyra olika sorters möten. Vi börjar med rollerna:

teamet

Sju personer plus minus två som utför själva utvecklingen. Teamet skall vara “korsfunktionellt” och innehålla all kompetens som behövs för utvecklingen: t.ex. testare, kodare och grafiker.

Teamet jobbar tillsammans med produkten och det är viktigt att uppnå en känsla av gemensamt ansvar för utvecklingen. Man får aldrig säga – det går dåligt för att han eller hon är så dålig. Att någon saknar kompetens är ett gemensamt problem som måste lösas genom kunskapsspridning och utbildning.

scrum master

En person som är ansvarig för att hjälpa teamet att vara så produktivt som möjligt. Det kan handla om att undanröja olika typer av hinder och störningar på arbetsplatsen allt från tekniska problem till chefen som kommer och stör med frågor i tid och otid. Scrum mastern är också ansvarig för att teamet förstår scrum och att processen fungerar. Kan vara en i teamet, men det finns både för och nackdelar med det.

produktägare

Den person som är ansvarig för att rätt delar av produkten utvecklas i rätt ordning och omfattning (mer om det strax). Skall ha koll på kundnytta, affärsnytta, företagets strategi och baserat på det prioritera.

Artefakterna då. Lite skum term men i princip handlar det om vilka dokument och saker man faktiskt producerar. Tre stycken:

product backlog

Produktägaren ordnar all funktionalitet som skall in i produkten i ganska övergripande “backlog items” i en lång lista. Varje item skall vara ett tvärsnitt genom applikationen som utvecklas och handla om en slutanvändarfunktion – en bra form är userstories.

Listan är sorterad på en prioritetspoäng på varje item, inga item får ha samma prioritet. De saker som är överst skall vara mer detaljerade och kortare än de lägre prioriterade items:en i listan. Syftet är att lägga tid på att utreda detaljer så nära själva utvecklingen som möjligt.

sprint backlog

I början av varje sprint plockar teamet åt sig så mycket arbete från toppen av produktbackloggen som de tror att de tillsammans kommer klara av att få färdigt under sprinten. De backlog items de plockat åt sig placeras i en prioritetssorterad lista där saker inte får tas bort eller läggas till under sprinten.

Under sprinten jobbar sedan teamet tillsammans med att färdigställa varje item. Ett item skall aldrig vara reserverat för en utvecklare i teamet – “pinpointat”. Tanken är att undvika flaskhalsar när någon blir sjuk eller inte är tillgänglig.

produkten

Det viktigaste så klart. Produkten man utvecklar. Kodbasen och det man “bygger” produkten av skall vara i sådant skick att man kan göra en ny version till kund i slutet av varje sprint.

Och så mötena. Alla möten är “timeboxade” vilket innebär att de har en fast längd, om mötet drar ut på tiden så skall man ändå avbryta det efter timeboxen och lära sig till nästa gång att man pratade för mycket detaljer eller inte såg till att mötet flöt på bra. De tre mötena är:

sprintplaneringsmöte

Första dagen på sprinten, teamet och produktägaren. Mötet har två delar, först går teamet och produktägaren igenom de högst prioriterade sakerna i produktbackloggen, teamet ställer frågor om saker de behöver veta för att upskatta hur lång tid varje backlogitem tar att implementera.

Den andra delen av mötet går ut på att teamet delar upp varje backlog item i mindre och mer tekniskt orienterade delar: tasks. När teamet uppskattat tiden det tar att uföra ett item så har produktägaren möjlighet att “scopa” om det – dela upp det i mindre delar och prioritera ned vissa. Produktägaren får däremot inte kräva att teamet gör ett item snabbare genom att tumma på kodkvalité och liknande.

daily scrum

En gång varje dag under sprinten har man ett femtonminutersmöte där varje person i teamet besvarar frågorna “vad har du gjort sedan senaste mötet“, “vad kommer du göra tills imorgon” och “vad har förhindrat dig från att vara optimalt produktiv“.

Det är bara scrum master och teamet som får prata på detta möte men andra är välkomna att vara med och lyssna. Om några i teamet behöver diskutera något ytterligare bestämmer man en mötestid på detta möte.

sprint review

I slutet av varje sprint skall en handgriplig demo genomföras där varje funktion som är klar skall visas på en dator för alla de som kan vara intresserade. Kunder och chefer får vara med på detta möte, teamet, scrum mastern och produktägaren skall vara med. Bara sådana backlog item som är helt klara får demonstreras här, ett item som saknar någon del räknas inte som klart och måste vara med i en till sprint för att vara klart.

sprint retrospect

På det här mötet så går scrum mastern och teamet igenom vad som varit dåligt och bra under sprinten, vilka beslut man tagit, vilka störningar man haft och vad man skall förbättra nästa sprint. En bra grej eftersom saker som går dåligt ofta kan vara jobbiga att ta upp – det blir lättare att ta upp känsliga problem i ett konkret forum än att bara resa sig upp en dag och säga dem rakt ut.

Många utvecklingsprocesser försöker vara detaljerade och innehålla en kokbokslösning på alla aspekter av hur man bedriver mjukvaruprojekt. Scrum lämnar istället ganska många dörrar öppna och man måste i princip alltid anpassa processen efter de speciella krav som finns i varje företag. Nästa scruminlägg tänker jag ägna åt att berätta lite detaljer om scrumimplementationen på min arbetsplats.

Inom mjukvaruutveckling så finns ett jätteproblem: en extremt liten del av alla projekt lyckas. Oftast blir mjukvaran en kund beställt klar men väldigt sällan i tid – mjukvaruutveckling är extremt komplicerat och det är i princip omöjligt att förutsäga hur lång tid delar av ett program tar att skriva i förväg. Ett annat problem är att mjukvaran blir klar men faktiskt inte är vad kunden förväntat sig – eftersom mjukvara är så pass komplext är det svårt att få kommunikationen att fungera. En tredje variant är att mjukvaran blir klar i tid men att utvecklingsföretaget gör en stor förlust eftersom så mycket mer resurser gått åt till projektet än man förväntat sig.

Det mest bisarra är att man under hela mjukvaruindustrins existens inte verkar hittat något sätt att komma runt detta. Man kanske saltar sin tidsuppskattning på något sätt för att ta höjd för att man gissat fel, (säg t.ex. att man alltid multiplicerar hur lång tid det tar med 2).

Ett annat problem är att när man håller på med ett stort mjukvaruprojekt så kanske inte det en kund ville ha från början är samma sak som de vill ha ett år senare när det är klart. Ändå gör man först en förstudie och försöker mycket detaljerat dokumentera exakt vad man vill ha – vad man kallar för kravspecifikation. Denna dokumentation skall man sedan kunna använda som “bevis” för att beställningen är färdig. Utöver att världen är föränderlig är det mycket svårt att lyckas fånga varenda detalj man vill ha på papper. Det är möjligt att uppfylla en kravspec exakt men ändå ha skrivit ett system som är helt oanvändbart – ett något raljerande exempel: “det stod att man skulle kunna skicka mail, inte att det skulle gå utan att trycka på tio knappar och sedan snurra ett varv med händerna över huvudet”.

En kravspec kan också göra att man får en situation där kund och utvecklare är som motparter istället för att som det egentligen är de faktiskt har ett gemensamt mål som allt blir bäst om de hjälps åt att nå (en situation jag upplevt själv).

När kunden lagt två månader på att skriva ett jättedokument om exakt vad de vill ha finns en risk att man som utvecklare stänger in sig med dokumentet och kodar på för glatta livet. Ett år senare släpper man sin produkt och det visar sig att man feltolkat hälften av kraven totalt. “Att man skall kunna skicka mail” betyder ju inte att alla skall det, det är ju självklart! “Det kan ju inte ta en halvtimme att visa sitt banksaldo” – “Det stod inget om hur lång tid det fick ta”.

På min arbetsplats (Databyrån) har vi sedan ett och ett halvt år tillbaka (tror jag) arbetat enligt ett “lättrörligt” eller “agilt” arbetssätt som kallas Scrum. Jag är en av initiativtagarna men att vi arbetar på detta sätt är ganska väl förankrat i hela företaget. I framtiden tänker jag skriva och berätta mer om Scrum och hur det löser de problem jag nu beskrivit och fler.