Den agila verktygslådan. Spelutvecklaren Dice måste arbeta agilt. Ivar Jacobson om vår största utmaning. Ger insikt i tid

Transkript

1 Ett magasin från Combitech AB Ger insikt i tid Tema: Den agila verktygslådan Nr 2 juni 2009 Den agila verktygslådan Spelutvecklaren Dice måste arbeta agilt Ivar Jacobson om vår största utmaning

2 Tema: Den agila verktygslådan Nr 2 juni 2009 redaktionen Ansvarig utgivare Marie Bredberg Ett magasin från Combitech AB Ger insikt i tid redaktionsråd Göran Carlzon, Erichs Communications Göran Ekberg Lena Eklöf Magnus Skoog redaktör Karin Rydman, Linköping karin.rydman@combitech.se nätvariant av OnTime Den agila verktygslådan Spelutvecklaren Dice måste arbeta agilt Ivar Jacobson om vår största utmaning OnTime ska ge insikt i tid OnTime är en branschtidning som tar upp olika aspekter och nyheter inom området utveckling av realtidssystem. OnTime ska ge möjlighet att ställa olika perspektiv mot varandra, och samtidigt visa helheten i teknik- och samhällsutveckling. COmBITECH linköping Box Linköping (Besöksadress: Universitetsvägen 14) Jönköping Box Jönköping (Besöksadress: Änkhusgatan 9) Växjö Ljungadalsgatan Växjö övriga orter: Arboga, Borlänge, Enköping, Göteborg, Helsingborg, Hässleholm, Karlstad, Kristianstad, Malmö, Norrköping, Norrtälje, Sundbyberg, Trollhättan, Västerås, Älvsjö, Örebro och Östersund. Ledare 3 Temaintroduktion 4 Motorola Hitta balansen i Scrum-arbetet 7 Dice Agila metoder skapar ett oslagbart engagemang 8 Agilt är melodin för Westermo 11 Scrum ger Hercules nytt liv 12 Saab Security Säker utveckling med agila metoder 14 ContextVision Agil utveckling med kvalitet 16 Ivar Jacobson Vi är i desperat behov av en teori för mjukvaruutveckling 17 E-post info@combitech.se Hemsida PrODuKTIOn Erichs Communications AB, Linköping Grafisk design Capo Marknadskommunikation AB Tryck LTAB Combitech är ett obundet konsultföretag som med hög kompetens och kontinuitet skapar stor kundnytta genom att tillhandahålla värdefulla och innovativa lösningar som kombinerar teknik, miljö och säkerhet. Kunderna finns inom branscherna försvar, flyg, telekom och säkerhet samt myndigheter med ansvar för skydd av flöden i samhället. Närheten till våra kunder är viktig. Därför finns Combitech på ett 20-tal orter i Sverige och Europa. Vi är runt 800 medarbetare och ingår i Saab-koncernen - ett av världens ledande högteknologiska företag med huvudsaklig verksamhet inom försvar, flyg och rymd.

3 ledare Bli inte lurad låt dig inspireras! när vi ifrågasätter en sanning som var självklar igår, ersätter den med en ny idag, för att sedan åter bepröva den i morgon. Då har vi ett processflöde som säkerställer ständiga förbättringar Som 16-årig sommarjobbare träffade jag en erfaren produktionschef som kunde verksamheten på sina fem fingrar. Kontorsdörren stod alltid på glänt och han hörde rytmen från maskinerna. Kadom, Kadom, Kadom Han kunde snabbt och kraftfullt rusa ut för att åtgärda problemen när rytmen i produktionen förändrades. Jag var djupt imponerad för här var produktiviteten hög och verksamheten lönsam. Eller, var den verkligen det? Idag är större delen av verksamheten nerlagd och de stora glansdagarna är förbi. Produktionen gick bra, men det räckte inte för att klara omvärldens allt hårdare krav. Hur är det med verksamheten du själv sitter i? Svarar du nu att den går bra, så har ni redan påbörjat er avveckling. Svarar du att den kan bli bättre, så finns det fortfarande hopp. Har ni fått alla på företaget att kontinuerligt fråga sig om det inte går att arbeta smartare? Då är det dags för era konkurrenter att bli oroliga. Det här numret handlar om Agila metoder med flera korta iterationer som engagerar personalen där även arbetssätt och processer förbättras. Låt dig inspireras och bli inte lurad av maskinernas trygga gång. Kadom, Kadom Kadom marino mirkovic Konsultenhetschef Västerås

4 TEmAInTrODuKTIOn Agila metoder Text: Erik narby / magnus Skoog Att utveckla mjukvara är svårt. Sedan mjukvaruutvecklingens begynnelse har utvecklare, projektledare och företag bittert fått erfara detta faktum. mjukvaruutvecklingsprojekt blir ofta försenade, kostnaderna skenar och många projekt lyckas inte leverera det kunden vill ha. lika länge som detta har varit ett faktum har man försökt att komma till rätta med problemet. under ÅrEnS lopp har en lång än till tunga processer och verktyg. rad av verktyg, programmeringsspråk Så vad innebär egentligen agil utveckling? För att förstå det krävs en liten och metoder presenterats som den avgörande lösningen. Värda att nämna tillbakablick. är bland andra FORTRAN, strukturerad programmering, objektorienterad Vattenfallsmodellen programmering, RUP och UML. Alla Vattenfallsmetodiken togs inledningsvis dessa har bidragit till att förändra hur vi fram under slutet av 60-talet för mjukvaruutveckling inom aerospaceindustrin. utvecklar mjukvara idag men ingen av dem har visat sig vara Lösningen med Att jobba enligt en vattenfallsmodell kan göras mer eller mindre strikt. stort L. I detta nummer av OnTime reflekterar Ivar Jacobson kring dessa frågor Tanken är att man har hela kravbilden på ett träffsäkert sätt. Senast i raden av klar för sig innan man går vidare. Enligt metoder är de agila metoderna som är de klassiska projektstyrningsmodellerna den hetaste trenden inom system- och ska alla artefakter göras i en sekvens. Det mjukvaruutveckling just nu. betyder att inför viktiga beslutspunkter Agila metoder är en reaktion på så finns allt material färdigt. Ändringshantering behövs i princip inte. Detta klassiska arbetssätt inom system och mjukvaruutveckling. Att jobba agilt är synsätt fungerar sällan i stora projekt. att vara mer lättrörlig. Man försöker höja Orsakerna till det är flera: gruppens effektivitet och frigöra kreativiteten. Man ser till människan snarare som är kostnadsdrivande kommer fram Kraven är svåra att fånga. Många krav Krav Beslutspunkt Design Beslutspunkt Implementation Beslutspunkt Test Vattenfallsmetodiken togs fram under 1960-talet. senare. Det betyder att man analyserar endast en del av kravmängden. Ändringshantering har visat sig behövas. Krav, tidsramar och andra förutsättningar förändras oftast under projektet. Detta betyder ofta att många av de krav som man från början ämnade ha med stryks under projektets gång samtidigt som nya kommer till. Det är sällan lämpligt att implementera och testa allt på en gång, s.k. big bang. Detta angreppssätt innebär att fel ofta upptäcks sent vilket leder till att den totala utvecklingstiden ofta blir längre än om man jobbar i små steg. Ett annat skäl att undvika big bang har med komplexiteten att göra. Det är svårt att överblicka allt på en gång. Faktum är att det är under utvecklingen av produkten (eller prototypen) som man faktiskt lär sig att formulera de rätta kraven. Detta betyder att systemutveckling i själva verket är en lång läroprocess. Nu skulle man kunna tro att vattenfallsmodellen är under utdöende. Men så är icke fallet. I flertalet projekt så finns den med, åtminstone med som dåligt exempel. Vattenfallsmetoden har fungerat i en värld som inte är så föränderlig menar t ex Fredrik Löving i artikeln om DICE. Redan under de tidiga mjukvaruprojekten på 60 och 70-talet insåg man att något var fel. Så länge projektens krav kunde styras inifrån projekten och projektgrupperna var små så fungerade 4 OnTime nr 2/09 Agila metoder

5 Programmeringsspråk Formella metoder Utvecklingsmetoder Maskinkod Assembler 1950 Fortran COBOL 1960 BASIC SIMULA 1970 PASCAL Strukturerad Programmering talet Vattenfall talet Smalltalk C 1980 ADA 1990 C++ Objektorientering 80-talet Spiralutveckling Inkrementell/Iterativ utveckling (1984) Prototyping Parallell utveckling (~1980) JAVA UML (1994) 2000.NET C# RUP (1998) Agila metoder: J2EE Scrum (1995) *ref [3] FDD (1997) *ref [4] XP (1999) *ref [5] LEAN (2003) *ref [6] 2010 Under årens lopp har en lång rad av verktyg, programmeringsspråk och metoder presenterats som den avgörande lösningen. det hjälpligt.. Men ganska snart kom det nya tankesätt Dessa modeller har också en del problem: När blir man färdig? Ofta behövs det fler inkrement än man först tänkte. Hur hanterar man fel som har upptäckts i föregående inkrement? Risken är att man springer vidare och att felen först rättas senare (om de inte glöms bort helt). Det finns ju en viss overhead för varje gång man löper hela linan ut. Så hur långt ska man gå med dokumentation och test i varje inkrement? mot en Agilare Värld? Agila metoder är ett samlingsnamn för en hel familj av metoder. Flertalet av dessa är inte nya utan har använts sedan länge. De har alla inspirerats av spiralmodellen. Gemensamt för dessa är dock de grundläg- Inkrementplanering Feedback Test Spiralmodeller Krav Implementation Spiralmodellen reducerar riskerna genom utveckling i små steg. Design Av flera skäl är projekten mycket mer komplexa idag. T ex så ställer kunderna högre krav, produkterna innehåller mycket mer programvara och kravbilden är föränderlig. Att jobba inkrementellt innebär att man utvecklar systemet i små steg Inkrement. Dessa inkrement kan ses som små vattenfall. Genom att utveckla i små steg så kan man reducera några av de risker som finns inbyggda i vattenfallsmodellen. Framförallt så slipper man big bang effekten. Då systemet tas fram i små steg så innebär det att man kör hela cykeln från krav till test. Man kan då hitta problem tidigare och med hjälp av denna feedback planera och genomföra resten av projekten bättre. En iterativ modell har stora likheter med en inkrementell, men här har man ofta kortare tidshorisont för planeringen. Man gör i stället ständiga förbättringar. OnTime nr 2/09 Agila metoder 5

6 Erik narby (till vänster) är civilingenjör i datateknik och systemutvecklingskonsult på Combitech. Han har arbetat som mjukvaruutvecklare och projektledare inom fordons- och telekomindustrin. Han är även kursledare inom programmering och mjukvaruutvecklingsmetodik. magnus Skoog (till höger)har 17 års erfarenhet som systemutvecklare och mjukvaruutvecklare inom bl a försvar och telekomindustri. I de senaste projekten har han infört modellbaserade arbetssätt. Han jobbar också som mentor och kursledare. gande principer som finns specificerade i Det Agila Manifestet [1]: Individer och samspel framför metoder, processer och verktyg. Körbar mjukvara framför omfattande dokumentation. Kundsamarbete framför kontraktsförhandlingar. Anpassning till förändring framför att följa en statisk plan. Det som är nytt är egentligen hur dessa metoder har kombinerats samman till större metodikpaket som sedan har marknadsförts som enskilda enheter. Scrum och XP är två exempel på sådana metodikpaket. Motivationen bakom att vilja gå över till ett mer agilt arbetssätt skiljer sig åt mellan olika företag och projekt. På Westermo, som utvecklar industriella datakommunikationssystem, hade man t ex problem med att kravspecifikationer ändrade sig under utvecklingens gång. De metoder man har valt skiljer sig också åt. En vanlig metod inom flertalet av de agila metodikpaketen är att ständigt arbeta med att utvärdera och förbättra sina processer. Detta leder med tiden till att företag som säger sig använda samma metodik kan arbeta på helt olika sätt. Precis som vid alla förändringar bär införandet av ett agilt arbetssätt också med sig stora utmaningar. Det gäller dels att utbilda de utvecklare som ska arbeta enligt metodiken men även att få övriga delar av organisationen att acceptera de förändringar i deras arbete som de nya metoderna medför. En stor omställning är ofta det sätt på vilket kunder och beställare förväntas involvera sig i projektet under dess gång. Inte sällan hör man att det är svårt att få kunder att delta så aktivt som man skulle kunna önska. Ofta finns även redan befintliga processer som man måste anpassa sig till. Som Torbjörn Lundquist på ContextVision säger: Bara för att man använder Scrum eller någon annan agil metodik så kan man inte strunta i de krav som företaget har utan de måste tillmötesgås oavsett vilken metod man använder. Sammantaget leder detta till att de företag som har anammat agila metoder arbetar på ganska olika sätt. På grund av skillnader mellan branscher, företag, projekt och personer anpassas metoderna till den situation de ska användas i. Detta är i sig inget dåligt, men kan verka förvirrande då man studerar hur olika företag har anammat en viss metodik. Ivar Jacobson skriver om detta i sin artikel Varje gång vi byter jobb måste vi lära oss en ny metod innan vi kan sätta igång med den egentliga arbetsuppgiften. Den agila verktygslådan ger oss stora möjligheter att skräddarsy arbetssätten. Detta gör det extra viktigt att man är tydlig med vad man menar med agilt, dvs. vilka verktyg man valt att använda. Jobba agilt? De agila metoderna har tillfört många sunda idéer som har förändrat vårt sätt att jobba i projekt. Vilket arbetssätt man ska välja är tyvärr inte helt enkelt att säga. Möjligheterna till val är stora och som projektansvarig/metodansvarig är det svårt att välja arbetssätt och det krävs ett stort engagemang i projekten. Men det är ju utmaningen som gör vårt jobb kul. o Referenser [1] [2] [3] Scrum [4] FDD [5] XP: Kent Beck: Extreme Programming Explained [6] LEAN Software Development: Mary and Tom Poppendieck 6 OnTime nr 2/09 Agila metoder

7 Hitta balansen i Scrum-arbetet Text: Kent Olofsson Att slaviskt arbeta enligt Scrum bara för att det ska vara så är kanske inte den bästa utgångspunkten. Då är det bättre att använda Scrum som en startpunkt för att sedan hitta sitt eget agila förhållningssätt menar Henrik Gidmark på Motorola. Om man lyssnar till de riktigt frälsta bland Scrum-anhängarna så hör man ofta att det ska användas fullt ut. Nu är det inte alla som är övertygade om att det är den enda vägen att gå. En som har lite andra idéer är Henrik Gidmark, testchef på Motorola. Man ska akta sig för att lyssna för mycket på de fanatiska Scrum-anhängarna. Det finns sunda principer i Scrum som man kan plocka in även om man inte vill köra det fullskaligt. Man bör också tänka efter innan man lägger alla mjukvaruaktiviteter i backloggen, säger han. Själv arbetar han med Motorolas Set-top boxar för TV. Hårdvaruutvecklingen sker där efter andra metoder, men på mjukvarusidan arbetar man enligt Scrum-metoden. Efter ett drygt års erfarenhet av Scrum på Motorola så börjar de nu lära sig ett och annat. Svårtestat Just testsidan visade sig vara svår att få att fungera med en mer militant Scrumsyn. Var tredje vecka är en sprint klar och teamet ska i praktiken ha en liten release klar att visa upp för kunden. Denna release ska förstås ha testats, men i en komplex produkt så blir det omöjligt att hinna med alla tester under dessa tre veckor där utvecklingen pågår under tiden. Om produkten är väldigt komplex kan en alltför ambitiös plan, till exempel att ha kod som är färdig för release, medföra enorma krav på regressionstester inom ett sprint. Ett råd som Henrik Gidmark vill dela med sig av är därför att fundera över vilka kvalitetskrav som ska ställas på leveranser ut från en sprint. På Motorola har man också lagt de kontinuerliga regressionstesterna utanför de funktionsproducerande teamen för att få en sammanhållande testning. En annan viktigt del i hur Motorola arbetar med Scrum är automatisering. Det är oerhört viktigt att arbeta med automatiserade tester och det gör vi också, men inte ens det räcker till för att vi ska kunna släppa testad mjukvara var tredje vecka. Om vi satte det som högsta prioritet kanske vi skulle kunna lösa det inom överskådlig tid, men det skulle då kräva så stora investeringar i automatiseringslösningar och testorganisation att det är tveksamt om det skulle löna sig i längden, säger Henrik Gidmark. Äpplen och päron När Scrum infördes på Motorola blev det nästan en religion och helt plötsligt skulle allt lösas med den metodiken. Efter hand har en mer balanserad syn infunnit sig och Henrik Gidmark har några råd till dem som vill hitta rätt balans i sitt Scrum-arbete. Undvik att jobba med en för omfattande backlog där flera olika projekt, verktygsutveckling, supportärenden med mera blandas och ska prioriteras vid varje sprint. Det finns en stor risk för att kontinuiteten offras och dessutom gör det produktägarens roll väldigt svår när denna ska prioritera mellan äpplen och päron, säger han. Motorola har i god agil anda tagit steg för steg i förbättringsprocessen och idag ser till exempel backlog-arbetet annorlunda ut än för ett år sedan. Från början hade vi en stor backlog. Nu har vi tre separata, vilket ger ett större lugn och en bättre översikt, säger Henrik Gidmark. Gladare med Scrum För att det finns klara fördelar med att använda Scrum så länge man gör det på rätt sätt är det ingen tvekan om. Scrum har gett oss en fantastisk arbetsglädje, ett större deltagande från medarbetarna och mycket större transparens så att alla vet vad som händer, säger Henrik Gidmark. Ska man se på vad som inte får plockas bort så har Henrik Gidmark en speciell favoritdel i det agila arbetet. Ska jag plocka ut en enskild i del i Scrum som jag tycker är allra viktigast så får det bli att ha täta retrospektiv där vi tittar tillbaks på vad vi åstadkommit och ser vad vi behöver jobba med under den nästföljande treveckorsperioden. Det är också något som medarbetarna brukar gilla för då har de en chans att göra sin röst hörd och påverka arbetet, säger han. För den som funderar på att införa Scrum är det viktigt att inse att det kanske inte bara är att läsa igenom det agila manifestet och dra igång. Det gäller att förstå hur arbetssättet fungerar i den egna organisationen och ett bra sätt att se hur det kan fungera är att prata med andra som redan har gjort resan. Se till att få en nyanserad bild av Scrum och prata med både de frälsta och skeptikerna. Det allra bästa är om du kan få besöka ett företag med liknande verksamhet som redan jobbar med Scrum. Man ska då prata med personer på olika nivåer inom företaget för de kan ha lite olika syn på nyttan med Scrum, säger Henrik Gidmark. o OnTime nr 2/09 Agila metoder 7

8 Agila metoder skapar ett oslagbart engagemang Text: Göran Carlzon För oss har det varit jätteeffektivt att arbeta agilt, konstaterar Fredrik Löving, som är projektledare på spelutvecklaren Dice. Fredrik och hans utvecklingsteam har lång erfarenhet av utveckling i Scrum och kan idag inte tänka sig att arbeta på något annat sätt. Vi jobbar just nu med ett alldeles nytt spel. Det är så hemligt att jag inte ens kan berätta vad det handlar om, berättar Fredrik Löving. Men jag kan förklara exakt hur vi arbetar och varför det är så viktigt för oss att arbeta agilt. Ett nyckelbegrepp inom Dice är Fun Factor. Om någon del av spelet inte är spännande eller roligt för spelarna har det inte något berättigande. Med succéer som Battlefield och Mirror s Edge bakom sig är förväntningarna stora på den internationellt välrenommérade studion i Stockholm. Det är lätt att säga i förväg att något kommer att bli kul, men en annan sak att prova, känna och klämma när det väl är framme. Då kanske det inte alls känns lika roligt längre. Om man i det läget har lagt ner tre års utveckling så kan det vara ganska tufft att få kasta allt i papperskorgen. Därför jobbar vi istället med tvåveckors iterationer, vilket innebär att vi i värsta fall inte skulle behöva slänga mer än två veckors jobb. Vattenfallsmetoden har fungerat i en värld som inte är så föränderlig, fortsätter Fredrik Löving. En stol förändras inte så mycket från skiss till slutprodukt. Om vi på Dice skulle arbeta så skulle planerna inte höra ihop med verkligheten. Inom spelvärlden händer så mycket och så snabbt att något som är nytt och hett blir gammalt och tråkigt på kort tid. Att utveckla ett nytt spel kan ta mellan två och fyra år. I var och en av alla faserna (se separat faktaruta) används Scrum. I praktiken går det till så här: Planning Poker spelet där alla vinner Dice börjar med att sätta upp en så kallad Product Backlog. Det är helt enkelt en todo-lista som börjar med vad som är mest värdefullt för kunden och slutar med det som är minst viktigt. Sedan genomför Dice något de kallar för Planning Poker. De samlar 4-5 personer, till exempel en kodare, en animatör och en projektledare och läser upp alla todo-punkter. Några punkter väljs ut och poängsätts i förhållande till hur komplexa de är relativt varandra. Sedan fortsätter gruppen med att relatera alla todo-punkter tills hela Backlogen är poängsatt utifrån sin komplexitet. När hela listan är estimerad börjar arbetet på riktigt. Fredrik Löving berättar: - Vi jobbar i tvåveckorscykler. Det är något vi har provat ut noggrant. En vecka per iteration är för lite, då tycker jag att det läggs för mycket tid på att planera. Vi har även provat att ha fyraveckorscykler, men vi gick över till två veckor, för då kan vi testa tillräckligt ofta utan att ha för mycket administration. Måndag vecka 1: På planeringsmötet som inleder varje iteration bryts varje todo ner i detalj för första gången. Teamet benar ut exakt vad som ska göras och sätter sedan timmar på det. - Det är viktigt att säga att det är teamet som committar. Det är inte jag som projektledare som säger vad som ska göras. För mig är det en otrolig skillnad. Och en stor fördel. Det är inte någon som står och skriker vad vi måste hinna, som det ofta kan vara i mer traditionella metoder, utan teamet lovar att de ska ha färdigt en viss del från todolistan till nästa gång. Teammedlemmarna avgör alltså själva vad de kan klara på en iteration. Det är projektledarens ansvar att se till att inget eller ingen stör. - Ibland kan det vara externa faktorer som utövar påtryckningar, exempelvis kunden. Men då måste jag säga nej. De måste vänta tills iterationen är klar. Arbetssättet är väldigt flexibelt när det gäller vad vi ska göra, men när vi väl bestämt oss för en iteration får inget komma emellan innan den är klar. Det skulle skapa osäkerhet och störa rytmen. Under tiden - Varje dag har vi ett Daily Scrum-möte på 15 minuter. Alltid samma tid varje morgon. Det är ett stående möte där vi går laget runt. Alla ska svara på tre frågor: vad gjorde jag igår, vad ska jag göra idag och viktigast: är det något som hindrar mig? Alla ska veta om någon annans arbete hänger på dig, eller vad du behöver av andra för att själv komma vidare. Fredag vecka 2 - Efter två veckor har vi Iteration Review. Det låter mer formellt än vad det är. Det kan vara att vi samlas runt någons dator. Alla får visa upp vad de har gjort och alla kommer med feedback. Utifrån synpunkterna kan vi göra urval och dra lärdomar. Det är också här vi presenterar 8 OnTime nr 2/09 Agila metoder

9 Dice spelutveckling är uppdelad i fem faser. Allt inleds med en konceptfas, där den grundläggande idén presenteras, men utan att gå närmare in på detaljer, en vision. I nästa fas, Design and Planning tar man fram en plan på hur man kommer att leverera produkten. Här är det också viktigt att man benar ut mer exakt vad produkten är. Därefter inleds First Production, där en liten, men helt spelbar del av spelet byggs. Här granskas om konceptet är genomförbart och vilken teknik som ska användas. Här kollas också spelets Fun Factor är det kul? Värt att satsa på? Om det blir grönt ljus följer sedan produktionsfasen, där ett större team samlas och alla tänkbara frågetecken rätas ut. Det handlar helt enkelt om att iterera och göra färdigt. - Sedan skulle många säga att de var klara, hävdar Fredrik Löving. Men då går vi över i Polish-fasen. Eftersom vi vill ses som en ledande studio i världen så fortsätter vi ytterligare en nivå innan vi släpper spelet. för kunden de framsteg vi har gjort. I en så kallad Sprint Retrospective går teamet igenom vad som kan förbättras och vad som var bra. - Vi lyfter fram det positiva, poängterar Fredrik Löving. Det är viktigt att det här blir en rolig stund. Vi ska få känna stolthet över vad vi har gjort. Efter genomförd review och retrospective är det dags för en ny Planning Session på måndagen. Skapar ett otroligt engagemang Antalet poäng som klaras av i varje iteration går snabbt upp i början. Alla lär sig hur mycket de kan ta på sig, processerna blir bättre och man arbetar allt effektivare tillsammans. Risken för att någon teammedlem ska ta på sig för lite uppgifter, för att sedan sova bort halva tiden, är däremot liten, enligt Fredrik Löving. Alla vet vad du har gjort och kommer att göra. Om du varje morgon säger samma sak så blir det ganska uppenbart om du inte tar din del. Dessutom är risken liten att hamna där. Den här metoden skapar ett otroligt engagemang. Man vill varje morgon kunna säga att man avslutat något. Det är lite prestige i det. Metoden att arbeta agilt är faktiskt som starkast när det är tufft, med tight deadline. Folk jobbar längre och sitter kvar på kvällarna om det krävs. Finns det då inte en stor risk att teammedlemmarna istället bränner ut sig själva? Projekten är otroligt långa, konstaterar Fredrik Löving. Det är nödvändigt att det fungerar hela vägen. Det du gjort klockan tre på natten blir dessutom inte lika bra. Därför är det min roll som projektledare att se till att teammedlemmarna inte hamnar i en sådan situation. lätt att beräkna tiden för hela projektet Det blir efter ett tag en väldigt tydlig trend hur många poäng teamet presterar per iteration, därför blir det också lätt att beräkna tidsåtgången för hela projektet. - Vi levererar exempelvis 14 stories på totalt 37 poäng under en normal interation. Det är ett grundvärde. Sedan summerar vi hela vår Product Backlog. Frå n spelet Mirror s Edge utvecklat av svenska DICE. Det är viktigt att varje Iteration Review innebär ett avslut, enligt Fredrik Löving. - Vi ska ha en potentiellt skeppbar produkt i slutet av varje iteration. Inget fulhackande är tillåtet. Det funkar lokalt på min dator är inte godtagbart. I princip ska vi se det som en slutleverans var fjortonde dag. Säg att vi då får poäng. Genom att dela med 37 får vi fram hur många iterationer vi behöver för att genomföra projektet som det ser ut just då. Eftersom varje iteration är två veckor vet vi också hur lång tid det tar. Detta är något som konstant måste uppdateras då det frekvent läggs till och tas bort saker från backlogen. - Om vi har en begränsad tid kapar vi helt enkelt listan nerifrån, eftersom OnTime nr 2/09 Agila metoder 9

10 Från spelet Battlefield Bad Company utvecklat av svenska DICE. Product Backlog är ordnad så att det viktigaste står överst. Då får produktägaren titta på det som inte kommer med och avgöra om det är OK. Annars får vi flytta om på listan eller utöka tiden. Det blir väldigt tydligt vad som kan göras eller inte. Tar bort orolighet hos slutkunden Därför är det också mycket viktigt att listan är uppdaterad. Hela tiden händer något som gör att saker byter plats, eller någon ny todo-punkt tillkommer. Det påverkar egentligen inte teamet eftersom det hela tiden avverkar listan uppifrån, utifrån hur den ser ut på måndagsmorgonen vid en ny iteration. Däremot är det nödvändigt med en tät dialog med produktägaren, så att teamet vid varje iteration tar itu med det som är viktigast. - Det är en fördel på det sättet att man får bort en hel del av oroligheten hos slutkunden. Han/hon vet hela tiden hur långt projektet har hunnit, vad som är klart och kan påverka prioriteringen i listan. Kunderna visar lätt lite motstånd mot den här metoden i början, men sedan ser de att det ger dem bättre kontroll. Våga leka med processen Med, så småningom, nöjda kunder och engagerade team är det lätt att tro att det bara är att införa agil utvecklingsmetodik rakt av, men det kan ta ett tag att hitta rätt. - Sedan vi började har vi säkert ändrat i planeringsförfarandet 5-10 gånger, sammanfattar Fredrik Löving. Det är viktigt att inte se Scrum som en regelbok, utan som en guide. För att få ut maximal effektivitet ur Scrum måste man öva och öva. Våga leka er fram! Det är som ett fotbollslag. Du kan sätta ihop hur många stjärnor som helst, det kommer ändå inte att funka perfekt förrän ni har spelat ihop er. Men till slut får ni ett oerhört samspelat lag och det är där vi befinner oss just nu i vårt hemliga spelprojekt. o Fredrik Lövings tre agiltips: * Prova er fram! Även om Scrum kan vara oerhört effektivt redan från början, så blir det bara effektivare ju mer ni provar er fram. I början av projektet bestämde vi oss för att vi aldrig fick göra på samma sätt två gånger i rad. Det tvingar fram nya sätt att tänka. Även om det i vissa fall bara handlade om hur vi genomförde morgonmötena. Funkar det bättre, fortsätt. Funkar det sämre, gå tillbaka eller prova något annat. * Flytta folk! Man ska sitta nära dem man har täta kontakter med i iterationen. * Introducera inte agila arbetssätt som en helt ny process. Så fort man säger något om att byta arbetsprocess blir folk skrämda. Alla är i grunden rädda för förändringar, det gäller både utvecklare och chefer. Börja istället bottom up, med ett dagligt möte. Om det funkar bra kan ni gå vidare med att planera ihop och prova att leverera på två veckor. Inför Scrum bit för bit. 10 OnTime nr 2/09 Agila metoder

11 Agilt är melodin för Westermo Text: Kent Olofsson Westermo har utvecklat mjukvara enligt agila metoder i över ett år nu, vilket har gett utvecklarna blodad tand. Westermo levererar industriella datakommunikationsprodukter och merparten är egenutvecklade system. Fram tills för ungefär ett år sedan var det traditionella utvecklingsmetoder som gällde. Det kunde dock ibland bli litet ofokuserat när det kom nya krav från höger och vänster, och det var svårt för utvecklarna att veta vad som hade högsta prioritet. Så ett av målen som Westermo ville uppnå när man beslutade att börja arbeta agilt i mjukvaruutvecklingen var att få mer fokus i utvecklingsprocessen. Hittills har det agila arbetssättet helt klart motsvarat förväntningarna och även lett till effektivare utveckling. För oss har det här varit ett mycket bra sätt att hålla fokus i teamet. Ser man på produktiviteten så är det alltid svårt att sätta en siffra på den, men jag är helt övertygad om att den har ökat ordentligt och den kommer att öka ännu mer ju mer vi lär oss om att arbeta agilt, säger Raimo Haukilahti projektledare för mjukvara på Westermo. Påverkar hela organisationen Att arbeta agilt innebär att utvecklarna måste tänka lite annorlunda i form av dagliga möten och sprintar i stället för enstaka jätteleveranser. Det här är också något som påverkar den övriga organisationen, och att hantera det har varit den största utmaningen. Det gäller att även få med alla runt omkring på vad det innebär att vi jobbar agilt och iterativt. Det är inte bara utvecklarna som måste ändra sitt arbetssätt utan resten av organisationen måste också förstå att det exempelvis kommer en release var tredje vecka istället för var tredje månad. Så det kan till exempel innebära att en säljare kan behöva komma med synpunkter på en ny produkt långt innan den är färdig för leverans, vilket är litet ovant, säger Raimo Haukilahti. De allra flesta blev dock snabbt övertygade om fördelarna med agil utveckling, och särskilt att kontinuerligt kunna se hur produkten ser ut och fungerar för tillfället var något som alla från kund till företagsledning uppskattade. Just stödet från ledningen är viktigt när man ska börja jobba agilt. Det är inte säkert att vinsterna kommer direkt utan det kan behövas en del tålamod medan medarbetarna lär sig att fullt ut utnyttja de fördelar som agil utveckling ger. Vi har redan från början fått ett mycket bra stöd från ledningen som hela tiden trott på den här metoden. Det har betytt mycket för oss som arbetar agilt eftersom vi då har känt att alla dragit åt samma håll och haft samma mål, säger Raimo Haukilahti. Utveckling med kvalitet Det sägs ibland att agila metoder leder till att man kanske slarvar litet med kvaliteten bara för att bli färdig snabbt. Raimo Haukilahti menar att det snarast är motsatsen som gäller. De ger minst lika bra och förmodligen bättre kvalitet än andra metoder. Det finns många anledningar till det, men en är att det går snabbare att åtgärda buggar, säger Raimo Haukilahti. Som exempel på det nämner han att i och med att sprintarna bara tar tre veckor så är en ny bugg aldrig mer än tre veckor gammal. Utvecklarna har därför den delen av koden i färskt minne och kan snabbt utreda vad som gått fel. Med en mer traditionell utvecklingsmetod kan man istället råka ut för att en Raimo Haukilahti, projektledare för mjukvara på Wesermo. bugg kanske inte upptäcks på tre månader. Den kan exempelvis orsakats av en konsult som inte längre är involverad i projektet och det tar lång tid att sätta in någon annan i vad konsulten gjort, och åtgärda buggen. Agila metoder kan ge stora fördelar, men de kanske inte passar inom precis alla verksamheter. Vi har pratat om att det kanske inte fungerar så bra att köra agilt i supporten där kunderna vill ha stöd direkt, men det går säkert att plocka ut delar av det agila arbetssättet för att effektivisera även sådant som support, säger Raimo Haukilahti. På det hela taget är Raimo Haukilahti mycket nöjd med hur det har fungerat att arbeta agilt och han vill definitivt fortsätta med det här arbetssättet. Det vi gjort hittills med agila metoder har gett oss blodad tand och vi är mycket intresserade av att lära oss mer för att kunna utnyttja det agila arbetssättet ännu mer effektivt. o OnTime nr 2/09 Agila metoder 11

12 Scrum ger Hercules nytt liv Text: Kent Olofsson Genom att använda Scrum i utvecklingen av ett nytt system lyckades Saab Aerosystems arbeta både snabbare och billigare fick transportplanet Hercules känna luft under vingarna för första gången, och mer än 50 år senare är den gamla trotjänaren långt ifrån pensionsmässig. Faktum är att FMV och försvarsmakten nu moderniserar Sveriges Hercules-plan så att de ska bli ännu effektivare och därmed kunna användas i säkert ett par decennier till. En del i den moderniseringen är att utveckla ett nytt Mission Support System (MSS) som bland annat inkluderar ruttplanering. Här får Hercules hjälp av en av de modernaste utvecklingsmetoderna som finns. Snabbt och billigt Saab Aerosystems, som fick uppdraget att utveckla MSS, valde nämligen att använda Scrum för att bygga det nya systemet. Att Scrum skulle användas var ingen självklarhet från början, men med en pressad tidplan och begränsad ekonomi verkade det som att Scrum skulle kunna vara rätt metod för det här projektet. Något som också visade sig stämma. Jag uppskattar att utvecklingen blev 50 procent snabbare och 50 procent billigare med Scrum än om vi hade använt oss av mer traditionella metoder, säger Per Rosby, projektledare på Saab Aerosystems. Med traditionella metoder hade man först lagt en hel del tid på att skapa ett designdokument och först när det var färdigt hade själva kodandet tagit vid. Designdokumentet hade sedan kanske inte varit ristat i sten, men inte långt ifrån. Om något inte fungerat riktigt hade det förmodligen tagit lång tid att upptäcka och lång tid att åtgärda. Med Scrum blir tidsperspektiven mycket kortare. Här arbetar man i sprintar som varar ungefär en månad. Så varje månad gjordes en sorts informell leverans där både teamet och slutanvändaren fick se vad man kommit fram till hittills. Kunden fick därmed möjlighet att komma med feedback varje månad istället för att behöva vänta till slutleveransen för att se om systemet motsvarade kraven. Det gjorde att kunden blev väldigt nöjd med Scrum som metod. Även utvecklarna uppskattade fördelarna även om inte alla var så förtjusta till att börja med. Visst fanns det de som tyckte det var onödigt att gå på möten varje dag och menade att det mest handlade om ett kontrollbehov från arbetsgivarens sida. Men idag skulle nog inte någon av de som var inblandade vilja arbeta på något annat sätt eftersom fördelarna var så stora för alla i teamet, säger Per Rosby. Chefen blir coach Även för projektledarna innebär Scrum ett annat arbetssätt och det gäller då speciellt den som traditionellt skulle fungera som teknisk projektledare. I det här projektet var det Patrik Hilding som nu istället fick titulera sig Scrum master. Istället för att vara en chef, som projektledaren ofta är, så blir en Scrummaster mer av en coach som ser till att teamet får de förutsättningar som behövs för att göra sitt arbete på ett så bra sätt som möjligt, säger han. På ett sätt innebär det att projektledaren får släppa lite på kontrollen eftersom Scrum bygger mycket på att varje medlem i teamet tar ansvar för sina egna uppgifter utan att projektledaren står där med pekpinnen hela tiden. Å andra sidan ger det också projektledaren bättre kontroll eftersom han vid morgonmötet varje dag får den senaste informationen om hur det går för var och en i projektet. Det här var något som Per Rosby uppskattade mycket. Hans roll i projektet blev närmast som produktägare vilket i mångt och mycket liknar en traditionell projektledarroll med övergripande ansvar för ekonomi och kundkontakter. Traditionellt finns det en risk att delar av ett projekt kan hamna på efterkälken utan att projektledaren märker det eftersom den som ligger efter kanske inte berättar det för någon förrän krisen är ett faktum. I Scrum måste varje person redogöra för vad han gjorde igår, vad han ska göra idag och om det finns några hinder i arbetet. Om någon inte riktigt hänger med märks det snabbt. Den stora utmaningen när det gäller att införa Scrum är därför att få medlemmarna i teamet att tänka Scrum. Det är väldigt lätt att införa Scrum, men det är inte lika lätt att genomföra det. Det svåra är att man måste förändra sitt sätt att tänka på när det gäller utveckling, både som ledare och team, och våga utmana traditionell utvecklingsteknik. Det är inte så enkelt för alla, säger Patrik Hilding. Per Rosby är inne på samma linje. Vissa var vana vid att jobba i sitt hörn vecka efter vecka och då blev det ju en stor omställning att varje dag redovisa vad man gjort. Det krävs att alla involverar sig mer i arbetet och tar mer ansvar än i traditionell utveckling, men får man alla att acceptera det blir arbetet både snabbare och roligare, säger han. Nu var projektet inte helt och hållet ett Scrum-projekt. Kunden hade krav på att det skulle finnas en formell process enligt RUP i grunden, och det fanns vissa standarder som skulle uppfyllas och milstolpar som skulle uppnås. Att passa ihop detta med Scrum var dock inget större problem. 12 OnTime nr 2/09 Agila metoder

13 Här ses Hercules i utländsk tjänst, men även i Sverige har planet ett aktivt liv. Inte minst sedan det moderniserats med ett nytt MSS, Mission Support System, som exempelvis inkluderar ruttplanering. Systemet har utvecklats av Saab Aerosystems. Det var inte särskilt svårt att få Scrum att fungera tillsammans med mer traditionella metoder som RUP. Vi gjorde en sprint-planering som överensstämde med de milstolpar som fanns i den formella processen och det fungerade alldeles utmärkt, säger Patrik Hilding. Så man behöver inte vara Scrumfundamentalist för att arbeta med Scrum utan det går alldeles utmärkt att kombinera Scrum med mer traditionella metoder. Framgångsrecept Att komma igång med Scrum är med andra ord inte så svårt. Arbetsgången är ganska enkel och man behöver inte skicka iväg hela utvecklingsavdelningen på kurs i ett par månader för att kunna arbeta med Scrum. Det finns dock några saker man ska tänka på för att lyckas. De stora framgångsfaktorerna i Scrum är kommunikation, samarbete och bra kontroll på vad som händer. Får man till det så kommer man att kunna jobba mycket effektivt med Scrum, säger Patrik Hilding. Ett annat bra råd är att inte ta i för mycket på en gång. Jag tror inte man ska börja i för stor skala och starta med ett jätteprojekt direkt utan ta ett projekt som passar ett team för 8-10 personer. Om det fungerar bra kan man sedan starta fler team och då kan deltagarna i det första teamet fungera som mentorer i de nya teamen, säger Per Rosby. Att se till att alla är överens om vad planen är och vilket mål man egentligen jobbar emot är också mycket viktigt för att projektet ska gå som på räls. En viktig sak är att definiera vad klart betyder så att alla har samma uppfattning om när en uppgift kan anses vara klar, säger Patrik Hilding. I början kan det också finnas en viss oro för det nya bland utvecklarna och då är det upp till ledarna att föregå med gott exempel och övertyga alla om att det här är rätt väg att gå. Som Scrum master och projektledare måste man vara lite av en eldsjäl och visa att man själv brinner för det här och visa på vilka stora fördelar det faktiskt finns med den här metoden, säger Per Rosby. Det man ska akta sig för är att beskriva Scrum som en sorts silverkula som ska lösa alla upptänkliga problem. Om det inte finns en solid grund att stå på i form av bland annat en stabil arkitektur och klara mål så hjälper ingen utvecklingsmetod i världen. Det blir som att ställa en verktygslåda bredvid en trasig bil och hoppas att den ska laga sig själv. Det fungerar förstås inte och Scrum kan heller inte göra arbetet åt dig utan bara hjälpa dig göra det bättre och effektivare, säger Patrik Hilding. o OnTime nr 2/09 Agila metoder 13

14 Säker utveckling med agila metoder Text: Kent Olofsson Även komplexa system som säkerhetssystem för flygindustrin kan utvecklas med agila metoder, menar man på Saab Security. Att agila metoder som Scrum kan fungera bra för små projekt i mindre organisationer råder det knappast någon större tvekan om, men hur fungerar det när projekten och organisationerna blir större och mer komplexa? En som har haft tillfälle att fundera mycket på det är Jan Seger, ansvarig för Quality Assurance för Products and Systems på Saab Security. Saab Security bygger säkerhetssystem för flygindustrin, men har också system för att skydda exempelvis kraftverk, fängelser och hamnar. Det blir ofta komplexa lösningar som man kanske inte förknippar med agila system i första hand, men Jan Seger menar att det går alldeles utmärkt att utnyttja agila metoder även här. Rent generellt ger den agila utvecklingen en enorm styrka och det frigör ett stort engagemang i de lokala utvecklingsteamen. Så på den lokala nivån är agil utveckling överlägsen i alla lägen, säger han. Därmed inte sagt att agila metoder löser alla problem och passar för alla i alla lägen. Frågan många ställer är när det passar att använda agila metoder och vilka delar av projektet som kan köras agilt, men Jan Seger menar att det är fel ände att börja i. Kompetensen är nyckeln Frågan är snarare för vem agil utveckling passar bäst. För att lyckas med agila metoder gäller det att ha medarbetare som har den kompetens som behövs i projektet. I många fall innebär det att man måste få utvecklare som har arbetat enligt vattenfallsmodellen i många år att tänka om och börja arbeta agilt istället. Det brukar emellertid inte vara något större problem. Att ta ett gäng erfarna utvecklare som tidigare arbetat med vattenfallsmetoden och få dem att arbeta ännu effektivare med agila metoder fungerar säkert väldigt bra. Om man däremot tar ett gäng rookies som aldrig gått igenom alla stegen förr så är det inte helt klart vilken metod som kommer att fungera bäst för dem, säger Jan Seger. Den stora utmaningen lär istället bli att få med resten av organisationen på det agila arbetssättet Det kan vara svårt för exempelvis sälj- och IT-avdelningen att se att de skulle behöva ändra sitt arbetssätt bara för att utvecklarna vill jobba på ett annat sätt. Det är dock en förutsättning för att det ska gå att utnyttja agila metoder fullt ut, menar Jan Seger. Jobbar man med agil utveckling så krävs det snabba beslut även i andra delar av organisationen så där är väldigt viktigt att ledning, säljare med flera, förstår att utvecklingen kommer att ske på ett annat sätt nu och att de också måste anpassa sig till det, säger han. Ett exempel på det kan vara att det ställs nya krav på supporten från ITavdelningen. En typisk fråga kan vara IT-miljön där olika problem kan dyka upp hela tiden som gör att vi tappar ett visst antal timmar varje dag. Företagets centrala ITavdelning sitter inte med på utvecklingsteamets möten och den lokala IT-chefen kanske inte har möjlighet att själv lösa problemet, och om det inte fungerar sätter det käppar i hjulet för hela utvecklingsarbetet, säger Jan Seger. Jobbar man enligt en traditionell vattenfallsmodell där det kanske är ett år kvar till leverans är det väl ingen total katastrof om utvecklingsservrarna åker jo-jo av någon outgrundlig anledning i en vecka. Om det däremot är en vecka kvar av en sprint så kommer IT-avdelningen att drabbas av en svärm bålgetingar i form av extremt irriterade utvecklare. Därför är det viktigt att från början skapa förståelse för verksamheten. Vattenfall har sin roll På säljsidan kan det innebära att det designdokument som de tidigare lutat sig emot för att sälja in en ny produkt kan ändras under arbetets gång. Det är därför viktigt att sälj- och utvecklingsavdelningen är överens om vad som är ok att förändra och vad som måste finnas med för att inte säljarna ska börja sälja något som i slutänden inte kommer att finnas med eller fungera på ett helt annat sätt. Det kan också bli problem om man slänger ut vattenfallsmodellen och missar att en del dokumentation fortfarande måste tas fram, t.ex. dokumentation där produkten definieras på ett sätt som säljarna kan använda i sitt arbete. Och så måste förstås ledningen vara med på noterna. De måste stå bakom kursändringen och förstå att de inte kan räkna med att det ska bli guld och gröna skogar så fort man bytt metod. Vi gör det här för att öka produktiviteten, få bättre kvalitet, sänka kostnaderna, korta ledtiderna och få nöjdare medarbetare vilket alla företagsledningar säkert uppskattar. Men det kommer inte att ske från dag ett så man måste ha tålamod från ledningens sida och inse att det till att börja med kan kosta lite mer, säger Jan Seger. Sedan kan det vara bra att ha kvar delar av vattenfallstänket även när man använder agila metoder för själva utvecklingen. Vattenfall kan innehålla mycket av agil utveckling. Det går att hitta ett gränssnitt som gör det möjligt för enskilda utvecklingsteam att jobba agilt i 14 OnTime nr 2/09 Agila metoder

15 ett vattenfallsprojekt, säger Jan Seger. Det gäller bara att lägga det på rätt nivå. Att behålla en del av dokumentationskraven som finns i vattenfallsmodellen kan vara till stor nytta, men att jobba delvis agilt och delvis traditionellt i själva utvecklingen är däremot inte att rekommendera. Jag har sett exempel på där det körts vattenfall och agilt på rätt låg nivå och det fungerade inte alls utan då fick vi det sämsta av två världar istället för det bästa, säger Jan Seger. Produktägarens roll Ett problem med att arbeta agilt kan vara att produktägaren, Product Owner, har problem att hitta sin roll. Det är han eller hon som ska vara länken mellan kunden och utvecklingsteamet och i komplexa projekt kan det vara enormt svårt för en person att klara den roll som produkt- och systemledning traditionellt har. I komplexa projekt finns det ingen stålman som har tillräcklig kunskap för att samtidigt kunna förstå kundens krav fullt ut, se vilka lösningar som företaget tjänar mest pengar på och dessutom är tillräckligt implementationsnära för att inse hur svårt det blir att bygga, säger Jan Seger. En bra produktägare lyssnar inte bara till det kunden vill utan ser också till att kunden förstår vilka konsekvenser det får om deras önskningar ska tillgodoses. Om en ny funktion ska läggas så kanske en annan måste tas bort om inte tids- och kostnadsramarna ska spräckas. Konkurrensfördel för Sverige På det hela taget finns det stora fördelar med att arbeta agilt. Produktiviteten höjs, kostnaderna sänks och utvecklarna blir nöjdare med sin arbetssituation. Jan Seger vill också slutligen peka på att agila metoder kan ge oss i Sverige konkurrensfördelar. Agila metoder passar väldigt bra för oss här i Norden där vi till stor del har delegerat beslutsfattandet och medarbetarna är vana att ta eget ansvar och egna initiativ. Jag har jobbat med utveckling i Kina och Indien och där är det mycket mer hierarkiskt vilket gör det svårare att lyckas med agil utveckling där och det kan ge oss en fördel jag tycker vi ska utnyttja, säger han. o OnTime nr 2/09 Agila metoder 15

16 Agil utveckling med kvalitet Text: Kent Olofsson Att Scrum och andra agila metoder ökar produktiviteten genom att själva kodandet går snabbare lär väl ingen ha undgått som läst det här numret av OnTime, men hur blir det med kvaliteten? Från en del håll hörs kritik om att agila metoder snarast är ett sätt för att slippa dokumentera och att kunna ta en del genvägar i utvecklingsarbetet. Slutsatsen skulle då bli att agila metoder och hög kvalitet inte direkt skulle gå hand i hand. Ett företag där det absolut inte går att slarva med kvaliteten är Context- Vision som utvecklar bildbehandlingssystem för medicinska tillämpningar. För att utveckla dessa system använder ContextVision agila metoder och utvecklingschefen Torbjörn Lundquist ser inga problem med det. Det finns ingen motsägelse i att använda agila metoder och att hålla hög kvalitet utan det är bara en fråga om att använda de agila metoderna på rätt sätt, säger han. Agil på rätt sätt Han är dock medveten om att problemet kan uppstå, men då handlar det om att de som använder de agila metoderna inte arbetar med dem på rätt sätt. Agil har blivit ett modeord och kan ibland bli synonymt med vi dokumenterar inte utan vi kodar istället. Det är ett missbruk av de agila metoderna. I det agila manifestet sägs att körbar kod värdesätts högre än dokumentation, men det innebär ju inte att dokumentation är oviktigt, säger Torbjörn Lundquist. Tanken med Scrum och liknande metoder var att komma bort från vattenfallstänket där man först lägger mycket tid och energi på att skapa stora designdokument som sedan ska följas slaviskt. Om det uppstår ett problem upptäcks det normalt inte förrän långt inne i processen och det tar lång tid och blir mycket dyrt att åtgärda. Kombinera agilt och traditionellt Med agila metoder ser man under arbetets gång vad som fungerar och inte och kan enkelt genomföra ändringar. Det betyder dock inte att man ska slänga allt som hör till traditionell utveckling överbord. Bara för att man använder Scrum eller någon annan agil metod så kan man inte strunta i de krav som företaget har utan de måste tillmötesgås oavsett vilken metod man använder, säger Torbjörn Lundquist. Ett exempel på hur det kan fungera i praktiken är att anpassa Definition of Done, det vill säga villkor som måste uppfyllas innan man kan säga att man är klar med något, så att det följer de krav som kan finnas. Ett bra sätt att tillmötesgå regulatoriska krav och processkrav är att lägga in dessa i Definition of Done, säger Torbjörn Lundquist. Det kan handla om sådant som att designspecifikationen måste vara godkänd eller att man måste kunna visa upp ett fungerande testfall innan man kan gå vidare. På det hela taget går det nästan alltid att kombinera agila metoder och höga krav på kvalitetssäkring. De enda fall där det inte är lämpligt att använda agila metoder är i processer som är väldigt dokumentdrivna och som från början är anpassade för vattenfallsmetoden. Även här går det dock ofta att jobba agilt i implementationen. Det bästa är förstås att ha en inkrementell specifikation från början, men det går att översätta kraven från det stora designdokumentet till något som ska uppnås under olika sprintar om man använder Scrum, säger Torbjörn Lundquist. På det hela taget passar agila metoder i de flesta utvecklingsprojekt och fördelarna är uppenbara, tycker Torbjörn Lundquist. Man får högre produktivitet, bättre kvalitet, nöjdare medarbetare och högre lönsamhet, säger han. o Torbjörn Lundquist, utvecklingschef på ContextVision. 16 OnTime nr 2/09 Agila metoder

17 Vi är i desperat behov av en teori för mjukvaruutveckling Text: Ivar Jacobson Vår största utmaning: vi är en modebransch Vår syn på hur mjukvara ska utvecklas tycks ändras dramatiskt vartannat till vart tredje år, oftare än modets nycker. Företag över hela världen skrotar sina stora dyra investeringar i processer och verktyg på ett vårdslöst sätt och praktiskt taget innan de ens har hunnit pröva dem. Istället för att lära sig av sina erfarenheter tar de tanklöst något i bruk som de tror är helt nytt. I verkligheten har dock mycket litet förändrats. Precis som i modevärlden är det mycket väsen för praktiskt taget ingenting. Det kan gå an när det gäller något så trivialt som kläder, men med tanke på storleken på våra investeringar i mjukvara är det slösaktigt, dyrt och absurt. Vi är alla dödströtta på alla modenycker som vi drabbas av. Den senaste trenden är att vara agil (exemplifierat av Scrum). Den agila rörelsen framhåller att människan kommer i främsta rummet vid utveckling av mjukvara. Detta är egentligen inte något nytt temat dyker upp i stort sett varje decennium när naiva chefer försöker mekanisera och göra handelsvara av vad som i grunden är en övning i kreativ problemlösning. Det är viktigt att vi inte tappar taget om hur vi till exempel arbetar i grupp, hur vi samarbetar, hur vi dokumenterar vad vi gör och hur vi planerar vårt arbete på dag-, vecko- och månadsbasis. Men under arbetet med att åter sätta fokus på dessa saker går mycket förlorat eller döljs av nya namn på gamla företeelser, vilket skapar en illusion av något helt nytt. Resultatet blir en massa bortkastat arbete när gamla sanningar upptäcks på nytt, dolda av vad som tycks vara ett helt nytt yttre. Yngre och mindre erfarna medarbetare predikar nya trender och följer nya guruer, uppbackade av medias hajp i den ständiga jakten på nyheter. Chefer som har tappat kontakten med det egentliga utvecklingsarbetet hamnar i en hopplös sits. Står de emot det senaste modet, brännmärker de sig själva som utan kontakt med verkligheten. Pilotprojekt genomdrivs för att få fram bevis för den nya metodens fördelar, men motiverade utvecklare kan få allt att fungera i liten skala. Följden blir att den nya metoden tar över efter den gamla och allt som fungerade med den gamla metoden kastas ut tillsammans med de delar som inte gjorde det. Alltför sent upptäcks att även den nya metoden har delar som inte fungerar tillsammans med de delar som gör det. Problemets grundorsak bottnar i ett djupt missförstånd om vad mjukvaruutveckling egentligen är. Forskare har försökt angripa problemet med nya teorier som formalism för att bevisa programmens riktighet, eller formella språk som aldrig har prövats utanför den akademiska världen. Branschen har ägnat åratal åt att standardisera uppsvällda metamodeller som är mer eller mindre omöjliga att förstå sig på. Vi lär oss mjukvaruutveckling enbart genom exempel, inte genom teori först och exempel sedan. Universitet och tekniska högskolor lär ut ett visst sätt att arbeta, såsom XP eller Scrum. När vi senare möter utmaningarna i den verkliga världen har vi inga solida kunskaper att stå på. Därför hakar vi lätt på nya trender utan möjlighet att behålla våra gamla kunskaper och erfarenheter. I den verkliga världen, på jobbet, baseras alla projekt på en speciell metod som vi måste lära oss först och behärska innan vi kan börja arbeta. Varje gång vi byter jobb måste vi lära oss en ny metod innan vi kan sätta igång med den egentliga arbetsuppgiften. Detta är inte effektivt. Vi lär oss inte av våra erfarenheter eftersom vi hela tiden börjar om från början. OnTime nr 2/09 Agila metoder 17

18 Vi måste sluta att följa de senaste trenderna och söka enkla svar som bara leder till nya besvikelser. Men hur? Det är ett problem som jag har tänkt mycket på under det senaste decenniet och självfallet har jag en konkret idé om hur vi kan komma vidare. Ta itu med utmaningen: utveckla en grundläggande teori som beskriver vad mjukvaruutveckling egentligen är Som jag ser det ligger teorin rakt framför oss vi behöver bara ta tag i den. Låt oss börja med alla dessa metoder, processer och practices och försöka hitta sanningen bakom mjukvaruutveckling. Lösningen ser ut ungefär så här: 1. Hitta kärnan alla metoders heliga moder. Alla metoder har ganska mycket gemensamt. När allt kommer omkring används allihop för att utveckla mjukvara, och det finns vissa saker som vi alltid måste göra när vi utvecklar mjukvara. Vi skriver till exempel alltid kod, vi testar den alltid (på ett eller annat sätt), vi tänker alltid på kraven (dokumenterade eller odokumenterade), vi har alltid en backlog (uttrycklig eller underförstådd), och vi har alltid en plan på papper eller i våra huvuden. Vi vill hitta mjukvaruutvecklingens bakomliggande DNA, för att låna en utsliten liknelse. Vi vill hitta mjukvaruutvecklingens egentliga kärna eller rot som inte kan förenklas ytterligare. Genom att studera ett femtiotal metoder, inklusive XP och Scrum, har vi identifierat en kärna med ett tjugotal saker som vi alltid gör eller producerar. Ytligt sett kan det tyckas finnas stora skillnader mellan de studerade metoderna och hur vi arbetar med dem. Man kan exempelvis specificera krav utgående från features eller use cases. Alla metoderna har dock en gemensam grund som vi fångar i våra kärnelement. 2. Förstå grunden för metoderna eller processerna. En viktig insikt är att alla metoder består av en soppa av olika practices, oavsett om dessa är uttryckligt specificerade eller inte. RUP omfattar till exempel flera integrerade practices, medan Scrum i princip bara omfattar en. Scrum handlar om projektledning, så för enkelhets skull kallar vi denna practice för Scrum. Både RUP och Scrum omfattar dessutom en rad viktiga mönster, såsom Scrums agila arbetsmönster. För enkelhets skull lämnar vi dock diskussionen av dessa mönster till en annan dag. 3. Beskriv varje intressant metod utgående från kärnan. Med kärnan på plats kan alla metoder beskrivas på ett enhetligt sätt som specialiseringar eller utvidgningar av kärnan. Vi kan tillvarata underförstådda practices från alla brett använda och beprövade metoder eller processer, såsom arkitektur, Scrum, komponenter, iterationer osv. Vissa practices kommer att överlappa, t.ex. iterationer från RUP och Scrum. Vissa practices kommer att komplettera varandra, t.ex. use cases och Scrum. Kärnan undanröjer de kosmetiska skillnaderna mellan metoderna, såsom att samma sak heter olika saker i olika metoder. RUP talar till exempel om iterationer när Scrum talar om sprint, men i själva verket avser båda i stort sett samma sak. Genom att göra detta kan vi tydligt se de verkliga skillnaderna mellan olika metoder. I dag har omkring 15 sådana practices utvecklats med hjälp av kärnan. Eftersom kärnan är agnostisk i fråga om specifika practices, kan vi enkelt ta reda på vad som utgör den faktiska skillnaden mellan olika practices, inte bara på ytan utan på djupet. Detta minskar det religiösa inslag som omger alla metoder. Utbildningen blir alltmer logisk, eftersom den fokuserar på enskilda idéer istället för på den speciella blandning av idéer som utgör grunden för varje metod, process eller metodik. Jag är övertygad om att studenterna kommer att älska det. Det skulle vara perfekt om våra tekniska högskolor och universitet kunde utbilda studenterna i mjukvaruutvecklingens grunder, följt av att lära dem en uppsättning bra practices utgående från dessa grunder. Det finns även ett stort behov av relevant forskning här. Glöm inte Kurt Lewins ord: det finns inget så praktiskt som en god teori. En god teori gör det lätt att lära och utveckla sig utan att hemfalla åt religiösa överdrifter. Något som verkligen skulle vara bra. Vad innebär detta för branschen? De flesta stora företag har sin egen hemmasnickrade metod eller process som vanligtvis är en blandning av idéer från hela världen plus några företagsspecifika egna idéer. Vanligtvis beskrivs sådana processer i en tjock bok eller på en webbplats, och stora pengar har investerats i att dokumentera dem. Ibland utbildas människor i processerna, ibland hänvisas de bara till dem. I verkligheten ignoreras processerna ofta och bara de delar som faktiskt utgör en del av organisationens muntliga tradition används. Detta förklaras genom en återupptäckt naturlag: människor läser inte processböcker. Då och då dyker nya idéer upp (just nu vill alla vara agila), och de gamla processerna faller i onåd och deras böcker samlar damm på hyllorna. Det kan förekomma flera processer i de stora företagen. De stora systemintegratörerna kan ha tio till tjugo olika sådana processer. Ofta är de ganska likartade, men likheterna döljs bakom alla kosmetiska skillnader. Just nu använder företag över hela världen vår kärna för att skörda sina egna bästa practices och skapa företagsövergripande practicebibliotek. För första gången kan nu medarbetare i olika delar av ett företag lära sig av varandra. Vidare kan företag införa practices som används av andra företag utan att slänga ut sina egna om dessa visar sig fungera bra. Skulle ditt företag införa metodiken med practices skulle du inte behöva förkasta ditt nuvarande sätt att arbeta bara för att något nytt och sexigt 18 OnTime nr 2/09 Agila metoder

19 3. Eftersom människor inte läser processböcker måste alla practices dessutom vara lätta att ta till sig. Våra practices beskrivs på en uppsättning kort som bara fokuserar på det väsentliga. 4. Slutligen behöver vi practices som kan komma till liv och som kan exekveras. Dessa practices måste vara mer än bara beskrivningar. börjar bli populärt. Istället skulle du förbättra ditt nuvarande sätt att arbeta med en practice i taget. Du skulle börja titta på ditt nuvarande sätt att arbeta såsom bestående av en uppsättning practices. Sedan skulle du leta efter problemområden och komplettera ditt nuvarande sätt att arbeta genom att eliminera de av dina practices som inte fungerar och ersätta dem med practices som du tror kommer att undanröja svagheterna. Detta kan göras när du väl har förstått kärnan och dess användning. I en stor organisation med många olika sätt att arbeta kan du använda detta angreppssätt för att successivt förbättra varje sätt att arbeta utan att tvinga alla att använda samma metod eller process. Detta angreppssätt gör det lättare att införa nya practices utan att behöva ändra övriga practices inom organisationen. Tänk dig att du redan skulle ha introducerat kärnan och beskrivit dina practices för ett par år sedan. Då skulle du lätt kunna införa Scrum genom att byta ut ditt befintliga practice för projektledning mot Scrum utan att behöva göra några större förändringar av övriga practices. I framtiden kommer Scrum högst sannolikt att ersättas av en ny practice, och du kommer att kunna göra detsamma utan problem. några avslutande ord Vår förståelse av mjukvaruutveckling saknar en grundläggande teori. Följden blir att vi fortsätter uppfinna gamla practices på nytt men med något annorlunda ord, så att de verkliga innovationerna döljs och det blir svårare att använda de bra delarna av det nya samtidigt som vi gör oss av med de dåliga delarna av det gamla. Teorin kommer att hjälpa oss att väsentligt förbättra utbildningen relaterad till mjukvaruutveckling. Den kommer att hjälpa oss att vara mindre naiva i fråga om hur vi reagerar på nya idéer som dyker upp omkring oss. Slutligen kommer den också att hjälpa oss att införa nya idéer snabbare än vi kan i dag. I sina centrala delar vilar teorin på practices. Det finns dock bra och dåliga practices. Konceptet med practices har funnits i omkring femtio år, men dessa practices har varit löst definierade. Vi behöver ett koncept som är mer precist. 1. Våra practices måste vara avsedda för utvecklarna, inte som vi beskrev processen historiskt för processingenjörerna. 2. Vi måste kunna hålla practices åtskilda så att vi kan kombinera dem för att på så sätt skapa vårt eget sätt att arbeta (vår process). De som verkligen kommer att tjäna på denna teori är mjukvarubranschen, vilket redan har visat sig i flera företag. Vi kan lättare utbilda våra medarbetare, få dem att arbeta för fullt, förbättra vårt sätt att arbeta med våra produkter, reengineera (ett starkare uttryck än refaktorisera) våra produkter systematiskt och fortlöpande förbättra vårt sätt att arbeta. Resultatet blir bättre mjukvara, väsentligt snabbare och till dramatiskt sänkta kostnader. o Dr. Ivar Jacobson är en av upphovsmännen bakom komponenter och komponentarkitekturen, use cases, aspektorienterad mjukvaruutveckling, Unified Modelling Language och Rational Unified Process. Den senaste tiden har hans arbete varit inriktat på practice-baserad mjukvaruutveckling som nu tas i bruk över hela världen. OnTime nr 2/09 Agila metoder 19

20 Avsändare: Combitech AB Box 15042, Linköping B Porto betalt Seminarier om agila metoder Combitech kommer att erbjuda seminarier om agila metoder på tre orter i Sverige: Stockholm 22 september Västerås 23 september Göteborg 24 september På samtliga orter kommer Ivar Jacobson, grundaren av RUP, tillsammans med regionala föredragshållare ta oss med på en resa genom den agila världen. Alla har erfarenhet inom området och kan dela med sig av dessa. Det kommer att finnas möjlighet att få egna funderingar besvarade via paneldebatten som avslutar dagen. ny KurS Introduktion till agil utveckling COMBITECH TRAINING INSTITUTE introducerar en kurs där du kan prova det du lärt dig redan efter den första dagen. Kursen är en introduktion för projektledare och projektmedlemmar i Scrum och agil utvecklingsmetodik. Syftet är att utvecklingsarbetet ska bli enklare, snabbare och effektivare. Vi går igenom filosofierna bakom Lean, hur Scrum bäst kan utnyttjas och hur man skapar testbar kod av hög kvalitet från början med TDD testdriven utveckling. Kursen avslutas med ett uppföljningsmöte tillsammans med mentor. Kursen hålls under två heldagar, men vi låter det gå en tid mellan dag ett och två, så att du får möjlighet att öva på uppgifter och utveckla ditt tänkande mellan tillfällena. Efter genomgången kurs kommer du att ha grundläggande kunskaper om agila metoder som direkt kan användas i det dagliga arbetet. nästa nummer multicore superdator åt alla? De traditionella processorarkitekturerna närmar sig sin maximala kapacitet. Lösningen är att använda flera parallella kärnor och det kommer inom en snar framtid datorer med kanske hundratals kärnor. Dagens program är inte anpassade för detta. De utnyttjar alltså inte de nya möjligheterna och värre än så: i de framtida systemen så kommer de befintliga programmen faktiskt att gå långsammare. Detta kommer att driva på utvecklingen av programspråk och operativsystem. Det positiva är att superdatorns snabbhet blir tillgänglig för betydligt fler applikationer. Det kommer t ex att vara möjligt att simulera ett helt flygplan på en vanlig skrivbordsdator. Å andra sidan kan hackare få tillgång till enorm kapacitet för att knäcka koder. läs mer om detta i nästa nummer av OnTime. läs mer på