Från traditionellt till agilt

Transkript

1 Från traditionellt till agilt En studie i hur en agil metod kan introduceras i ett företag Felix Hall, dt05fh0, Aron Lidé, dt05al1 2 mars 2010 Sammanfattning In this paper the authors discuss strategies of introducing agile methods in software development organisations. The paper focuses on difficulties regarding organisations structure and employees and the employees former experiences and education. It briefly mentions the pros and cons of a transition to an agile method and covers some real industry cases.

2

3 1 Inledning Inom industrin idag är traditionella utvecklingsmetodiker i stil med vattenfallsmodellen ett genomgående tema. De agila idéerna har börjat spridas och i vissa fall implementerats, men det finns fortfarande stor motsträvighet från de som länge använt andra metodiker [3]. Nya företag, ofta mindre sådana, kan ha lättare att introducera nya agila metoder, då de har mindre intern friktion. Det är också lättare att kommunicera med alla parter inom en mindre organisation. Ett företag som försöker övergå till agila metoder kan i slutändan ha implementerat en avskalad version av en agil metod som inte innehåller de relevanta delarna då de har svårt att överge de traditionella metoderna. De kallar sig ändå agila fast de inte tar del av de fördelar som agila metoder ger [5]. Företagsledningen kan ha uppfattningen att metoden ska införas i sin helhet på en gång, men det är både onödigt och olämpligt [4]. I denna studie undersöks hur ett företag kan införa en agil metod i organisationen. Under studiens gång har artikelförfattarna tagit del av intressanta artiklar och böcker om ämnet. De har även genomfört intervjuer med personer med erfarenhet inom området. Artikeln går först igenom varför en övergång till agila metoder skulle kunna vara bra, sedan hur man går till väga och vad för problem som kan tänkas uppstå, både strukturellt och på personnivå. Därefter behandlas huruvida de anställdas utbildning påverkar hur lättinförda de agila metoderna är. 2 Fördelar med en agil utvecklingsmetod Om det är så svårt att implementera en agil metod i stor skala, varför ska ett företag gå igenom all möda för att lyckas? Ska en välbeprövad metod som finslipats över flera år, exempelvis med hjälp av CMMI 1, överges till förmån för något nytt och okänt, som inte ens behöver vara bättre? Vi har ju levererat bra produkter tidigare, vad är det som säger att vi inte kan fortsätta göra det med samma metoder? Dessa är alla relevanta frågor vars svar borde vara kända för alla inom en organisation innan en övergång ens förs på tal. Det handlar för det första inte om att kasta bort all kunskap och erfarenhet man samlat på sig, utan att ta tillvara på denna och tranformera den till en mer agil metodik som sät- 1 CMMI är en modell för utveckling av hur väl ett företag tar tillvara på sina erfarenheter för att förbättra sina processer och bättre kunna värdera framtida utmaningar, 3

4 ter kunder, utvecklare, kommunikation, fungerande mjukvara och tidsenlig leverans - istället för dokument, kontrakt och management - i fokus [4]. En agil organisation och en lärande, dokumenterad organisation med informerat management är inte motpoler, utan kan och bör samexistera [10]. Även om agila metoder kan te sig nya och okända så är de långt ifrån detta. Idéerna har funnits länge och har applicerats på mjukvaruprojekt med goda resultat i flera decennier [6]. Att en organisation tidigare levererat goda resultat med hjälp av en traditionell utvecklingsmetod behöver inte betyda att det är optimala resultat som levererats. Vid nästa projekt kan kanske tidspressen vara högre, så att produkten inte hinner testas tillräckligt mycket före leverans. Kanske förväntar projektet sig att koden ska kunna återanvändas, med förändringar och förbättringar till nästa version. Detta kan innebära stora problem för en stel utvecklingsmetod med stor teknisk skuld till följd att helt uteblivna refaktoriseringar. Kort sagt finns det ingen anledning att inte alltid sträva mot perfektion. Agila metoder strävar efter mer kontakt med kunden. Med tillvägagångssättet att utveckla med fokus på funktioner får kunden snabbare ut mjukvara där vissa delar är helt färdiga istället för att hela projektet är färdigt till en viss del. Fungerande mjukvara är både bättre för mätning av hur långt projektet har kommit och för feedback [1], vilket leder till att missförstånd mellan kunden och utvecklarna upptäcks tidigare. 3 Genomförande av övergång 3.1 Företagets struktur Arkitekturen i en organisation ligger inte bara till grund för hur arbetet i organisationen utförs, utan den har även en inverkan på hur mjukvarusystemet i slutändan kommer att se ut. Melvin Conway skrev 1968 att Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. Detta är känt som Conways lag [7]. Vad som menas med detta är att i en organisation där olika delar av ett program utvecklas i olika delar av organisationen kommer den slutgiltliga programvaran, och samverkan mellan de olika delarna i denna, att återspegla samverkan och kommunikationen mellan de olika delarna i organisationen. 4

5 För att ändra på strukturen i programmet kan det därför vara nödvändigt att ändra strukturen i organisationen, vilket ofta i stora organisationer är ett stort steg som dessa sällan vågar ta. Detta gäller inte minst sagt för införande av en agil utvecklingsmetod. Som nämnt ovan är införandet av en agil metod i sin helhet på en gång inte att föredra, utan det bör göras i mindre steg. 3.2 Pilotprojekt Många företag som stått inför utmaningen att anamma en agil metod har valt att börja med ett pilotprojekt, där en för företaget icke-kritisk del av organisationen börjat arbeta efter den tänkta metodiken[6][8][11]. De anställda inom pilotprojektet, såväl som viktiga stödfunktioner och management, har fått utbildning och därefter börjat arbeta enligt det nya tankesättet. Det kan tas in externa resurser med erfarenthet av metodiken för att ge organisationen självförtroende och kunskap. Därefter övergår pilotprojektet till att bli mer och mer självständigt, för att till slut vara helt självgående. När projektet är över utvärderas resultaten, och företaget kan ta vara på sina erfarenheter och bestämma sig för om metodiken är något de vill bygga vidare på eller avveckla. 3.3 Praktik för praktik XP är uppbyggt på värderingar och principer som ligger till grund för de praktiker som används. Dessa praktiker är uppdelade i primary practices och corollary practices. De primära praktikerna behöver införas först eftersom de ligger till grund för att de efterföljande praktikerna ska kunna fungera över huvud taget och inte påverka utvecklingen negativt. Om man till exempel börjar distribuera programvara dagligen (en corollary practice) utan att man fått ner antalet defekter i mjukvaran med hjälp av testbaserad utveckling och kontinuerlig integrering (primary practices) kan det leda till katastrof [4]. Vilka av praktikerna som bör införas först beror på miljön i gruppen där de införs och på vad som gruppen uppfattas kunna dra mest nytta av. Om gruppen har problem med defekter i koden, se då till att införa testdriven utveckling i ett tidigt skede. För vissa team är vissa av praktikerna lättare än andra att införa, till exempel praktiken att sitta tillsammans för att göra det lättare att kommunicera. För ett team som är lokaliserat på flera orter är detta i princip omöjligt att åstadkomma medan det är förhållandevist enkelt för ett team som redan sitter i samma byggnad. En studie gjordes på företag i Stockholm som införde agila metoder [11]. 5

6 Teamet var ett underhållningsteam som tog hand om buggar för en del av programvaran och de införde praktiker efter varandra med månadslånga mellanrum. De införde praktiker som passade dem bra i deras situation och ändrade en del för att få dem att passa bättre. En del praktiker tycktes vara bra, men dyra och svåra att införa, medan en del inte passade dem. Till exempel kunde de inte få så mycket användning av Planning Game eftersom deras utveckling styrdes av defekter som uppkom och som behövdes fixas och därför kunde de inte planera sin utveckling särskilt lätt [12]. 3.4 Team uppdelade på funktioner Ett företag som inför agila metoder kan hamna med flera små team som utvecklar sina delar agilt, men som i slutändan är beroende av varandra och som kommer att hindra varandra från att forsätta utvecklingen av programmet smidigt. Det är svårt att undkomma detta, men det går. Agil utveckling fungerar bäst med tvärfunktionella team där ett team eller en liten grupp av team har förmågan och befogenheten att leverera användbara funktioner till kunden oberoende av andra team [7]. Därför bör teamen så ofta som möjligt vara organiserade utefter funktioner, och så oberoende som möjligt av varandra. Med team uppdelade på detta sättet kommer färre team att påverkas när någon ändring i en funktion i programmet görs. Endast det team vars funktion rörs av ändringen kommer att påverkas istället för flera team som har hand om olika delar av funktionen [7]. Det är förstås inte alltid möjligt att utforma team som står för en hel funktion själva. Till exempel finns problemet mellan hårdvara och mjukvara där hårdvaruutvecklingen ofta har längre cykler. En förändring som påverkar hårdvaran kommer således att ta längre tid att åtgärda, och därför bör hårdvaran ha mer detaljplanering. Man kommer inte ifrån produktplanering och roadmaps, säger Per Runeson. Man bör inte slänga alla sina planer bara för att man kör agilt [10]. 3.5 Agil samverkan inom organisation Eftersom agila metoder inte alltid är lönsamma i alla delar av en organisation, eller i alla fall olika mycket i olika delar, bör man prioritera att införa agila metoder i delar där kravförändringar är troliga och där designen är oklar [1]. Tankesättet embrace change [4] kommer till användning mer när det finns större risk för förändringar. Det är också viktigt att tänka på att agila metoder och traditionella me- 6

7 toder har helt olika utvecklingsfaser och kan därför ha svårt att samarbeta. För ett team som utvecklar traditionellt är det viktigt med strikta gränssnitt mellan sig självt och andra delar då dessa har tagits fram under lång tid i planeringsfasen och en förändring i dem orsakar stora problem. Samtidigt är det viktigt för ett agilt team att utifrån kundens feedback kunna ändra i sin design och sina gränssnitt [1]. Om traditionella och agila metoder ska kunna användas samtidigt så bör de delarna de används i vara självständiga och påverka varandra så lite som möjligt. 3.6 Slutsatser om övergång Agila metoder verkar fungera bäst i förändringsbenägna delar som till så stor del som möjligt är oberoende av varandra och som kan leverera funktioner. Vilken övergångsstrategi som passar bäst beror hur organisationen ser ut och är svårt att svara på. Det måste till en anpassning, det finns inte ett sätt som passar alla, och förstår man vad som ligger bakom de agila metoderna så kan man få ut det viktiga ur det, säger Per Runesson [10]. 4 Anställdas inställning För mjukvaruutveckling är frågor angående de anställda ännu viktigare än de strukturella aspekterna i företaget. För att de agila metoderna ska kunna fungera på ett bra sätt är det väsentligt att de anställda är motiverade till att anamma förändringarna som följer med dem. Två vanliga missuppfattningar [2] när det kommer till att införa förändringar är: Förändringar kommer att bli accepterade bara för att de är bra idéer När en ny idé är introducerad behövs inget mer Hur pass accepterade förändringar blir i en grupp beror förstås på förändringen i sig och på individerna i gruppen i fråga. Det finns människor som är väldigt öppna för nya idéer, de som är väldigt konservativa och många nivåer däremellan. Det kan krävas en hel del ansträngningar och tid för att få med sig alla. Man bör inte direkt avfärda de åsikter om förändringen som de som är emot den har, utan lyssna på dem för att kunna angripa motståndet. Man behöver dock inte lägga alltför mycket energi på att försöka omvända de som gör mest motstånd, det är bättre att hjälpa dem som är villiga att införa förändringen [2]. 7

8 4.1 Förändra nedifrån och uppifrån Det är inte att föredra att ledningen ovanifrån helt plötsligt meddelar att en ny utvecklingsmetod ska användas. Folk står inte emot förändringar lika mycket som de står emot att bli förändrade [2], detta betyder att det är lättare för folk att hantera förändringar när de själva kan påverka hur de går till. När de anställda inte har någonting att säga till om är risken för motstånd större och det kan vara svårt att få dem motiverade. Förändringar underifrån är bättre för de anställdas motivation, men de tar längre tid. Dessutom är det ledningen som har en bättre uppfattning om strukturen i organisationen. Den bästa lösningen är ett samarbete mellan de två, en förändring både ovanifrån och underifrån, för att kunna se på förändringen från bägge synvinklarna. Detta tillvägagångssätt användes när IBM startade Agile@IBM, användandet av agila team i sin mjukvaruutveckling, och det var en av anledningarna till att det fungerade så bra [7]. 4.2 Sammanhållning och effektiva team I agila team gäller det att se till att personerna i gruppen är sammansvetsade och att de arbetar bra ihop. Will Schutz beskrev i sin FIRO-modell (Fundamental Interpersonal Relations Orientation) de olika faserna i en grupps liv, och det tar ett tag för en grupp att uppnå den sista fasen där de samarbetar mest effektivt. Agila metoder införs ofta som ett pilotprojekt först, och en alltför vanlig reaktion till ett lyckat sådant är att befordra managern och splittra upp teamet [1]. Uppsplittring av team kan också tänkas hända efter att den feature som ett visst team har arbetat på är helt färdig. Detta rekommenderas inte. Om teamet fungerar bra ihop bör det hellre tilldelas en ny uppgift som grupp för att behålla effektiviteten. 5 Utbildningens roll 5.1 Frågeställning Artikelförfattarna ställde sig frågan om grundutbildningen spelar stor roll när det gäller att befästa metodiker i arbetslivet. Utgångspunkten är studier vid Lunds tekniska högskola och civilingenjörer i datateknik (i fortsättningen kallat D ), där flera kurser behandlar agila metoder. Studenterna på D har frekventa kontakter med studenter vid andra utbildningar, exempelvis den i industriell ekonomi (i fortsättningen kallat I ) med inriktning mot mjukvaruutveckling. Studenter från I hamnar ofta snabbt i ledande positioner vid företag, ofta utan att först innehaft lägre positioner som kräver mer teknisk 8

9 kunskap och erfarenhet. Problematiken författarna tänker sig är att kurser på I fokuserar mycket på ledarskap och att kurserna som specialiseringen på mjukvarusystem består av handlar mycket om att behärska den faktiska programmeringen. Nackdelen med detta kan tänkas vara att den viktiga dimension som utveckling i större team tillför behandlas ytterst lite, och att detta gör att I-studenterna senare får svårt att sätta sig in i de problem som härstammar från just detta. 5.2 Tillvägagångssätt För att utreda den faktiska situationen inledde artikelförfattarna med att kontakta personer med insikt i I-programmets faktiska uppbyggnad. Den första kontakten var Nina Reistad, programledare för industriell ekonomi. Vid intervjun med henne framkom att det nyligen (februari 2010) fastslagits en ny utbildningsplan för en specialisering på I, kallad programvaruintensiva system. Denna hade tagits fram i samråd med flera professorer, och då Nina själv inte var insatt i vad agila metodiker innebär så hänvisade hon till dessa professorer och andra vid hennes institution som var inriktade på management av mjukvaruutvecklingsprojekt. En av de nämnda professorerna som suttit med vid specialiseringsutformandet var Per Runeson vid datavetenskap på LTH, och han blev nästa kontakt. Frågeställningen var ifall det funnits någon tanke på agila perspektiv när specialiseringen utformades. 5.3 Resultat Svaret från Per Runeson var att det inte funnits något specifikt fokus på det, men att I:arna i sin utbildning behandlar många begrepp som inte står i konflikt med agila tankesätt, exempelvis Lean production 2. Det framkom också att kursen Coaching för programvaruteam (EDA270) funnits i åtanke under utformningen, men att denna fick slopas eftersom den inte uppfyllde programledningens krav på att samtliga kurser skulle ge 7,5 högskolepoäng (coachingkursen ger 9 hp) [10]. Specialiseringen programvaruintensiva system består av följande kurser (Tack till Rune Kullberg): Avancerad telekommunikation (Okänd kurskod) Konfigurationshantering (EDAN10) 2 Lean production är en metodik framtagen inom bilindustrin, med Toyota som främsta förespråkare. Metoden handlar om att ständigt förbättra företagets processer genom konstant feedback från varje del av organisationen [7] 9

10 Programvaruutveckling för stora system (ETS032) Simulering (ETS061) Kravhantering (ETS170) Programvarutestning (ETS200) Flervariabel reglering (FRTN10) Marknadsstyrda system (FRTN20) Projekt i elektro- och informationsteknik (Okänd kurskod) Teknologistrategier (Okänd kurskod) Som synes ligger fokus på tekniken i sig, och inte på samarbete inom team. Det finns ett klart undantag från denna bild, nämligen Programvaruutveckling för stora system. Denna kurs kräver oerhört mycket samarbete och simulerar en vattenfallsmodell på ett relativt verklighetstroget sätt för att vara i undervisningsmiljö. Dock är detta så långt ifrån agilt man kan komma. Även konfigurationshantering behandlar problem som uppstår till följd av parallell utveckling. I denna kurs tas software configuration management 3 för agila team upp [9]. Det är artikelförfattarnas åsikt att ansvaret för samordnandet av införandet av en agil modell lämpligast bör ligga hos någon med erfarenhet från samarbete i team. Ledarroller i företag tillsätts ofta ur mängden anställda på lägre positioner, och man kan anta att dessa lättare kan se fördelarna och kraven vid en övergång. Det är positivt att den nya specialiseringen för I i viss mån berör begrepp relevanta för agila metoder, men det hade varit bra om dessa fått ett än mer explicit fokus. 5.4 Kvarstående frågeställningar Artikelförfattarna frågar sig om det inte hade varit lämpligt att, då utvecklingen inom industrin går mot mer agila metoder, på ett tidigt stadie explicit tydliggöra skillnaderna mellan en agil och en traditionell metod då en ny programvaruinriktad specialisering för framtida managers utvecklas. Det är författarnas förhoppning att dessa insikter når de studerande innan de kommer ut i industrin. 3 Tekniken att samordna parallell utveckling och se till rätt funktionalitet finns med i en produkt. Se kursbeskrivning [9] 10

11 6 Resulterande metodik Det viktiga vid en övergång till en agil metod verkar inte vara att till punkt och pricka följa någon given metodik, utan snarare att ta idéer från agila metoder och göra dem till sina egna. Risken då uppmärksamheten kring SCRUM 4 eller andra metodiker blir stor är att företag bestämmer sig för att det är dags att införa en metodik och tar in någon konsult för att få det överstökat. Det finns ju tyvärr rätt många konsulter som slår med stora reklamtrumman men inte har någon nyansering i det, säger Per Runeson [10]. Men det som övergången ska ge är en anpassning, inte en total revolution över en natt. Inom stora företag som använder traditionella utvecklingsmetoder är Stage-Gate 5 ett sätt för beställaren att ge feedback till utvecklarorganisationen. Utefter projektets lopp sätts ett antal milestones upp. När vattenfallsmodellen används kan milstenarna vara krav färdigställda, arkitektur färdigställd och så vidare. Om organisationen är van vid detta upplägg kan det vara lämpligt att låta slutresultatet ska vara en sådan metodik med agila inslag, där varje milestone innebär en synkronisering mellan de olika teamen och en kontrollpunkt för hur mycket av funktionaliteten som finns på plats. En sådan modell är fullt möjlig, och därtill lämplig [8]. 7 Slutsatser När ett företag står inför de stora utmaningar som en metodförändring innebär finns det mycket att tänka på. Det är svårt att ge en generell metod som passar alla, men det verkar som att följande punkter bör tas i beaktande Informera - se till att alla förstår var förändringen innebär och vilka fördelar det ger. Nedifrån och uppifrån - en effektiv förändring kommer inte bara från management eller bara från de anställda, utan är ett samarbete mellan de båda. Ta till vara på gammal kunskap - ett ny metod innebär inte att allt man gjort innan är fel. Utvärdera gamla praktiker och anpassa vid behov. Utvärdera erfarenheter - undersök om de anställda har tidigare erfarenhet av den tänkta metoden - akademiska eller yrkesmässiga. Ta tillvara på värdefull information och feedback. 4 En agil utvecklingsmetod, 5 Registrerat varumärke, 11

12 Ge tillräcklig auktoritet - en agil metod införs inte av chefer, den växer från alla nivåer. Ett team kan inte utveckla verkligt agilt om de inte har de befogenheter som krävs, exempelvis tillåtelse att begära ändringar i intilliggande moduler. Omstrukturera - agila team fungerar bäst om de är tvärfunktionella. En organisations tidigare struktur kan vara ett hinder när man söker en ny metodik. 8 Framtiden för agila metoder inom större organisationer I takt med att de empiriska studierna av agila utvecklingsmetoder i företag blir fler och erfarenheterna större så minskar barriärerna för större företag att våga ta steget mot en mer agil modell. Det är tur, med tanke på den explosionsartade utveckling inom mjukvaruindustrin vi sett sedan sin födelse och säkerligen kommer fortsätta se framöver samt de stora krav på flexibilitet och kundanpassning som denna kommer att kräva. Tack till Professor Per Runeson vid institutionen för datavetenskap vid Lunds tekniska högskola för intervju. Universitetslektor Martin Höst vid institutionen för datavetenskap vid Lunds tekniska högskola för intervju. Universitetslektor Rune Kullberg, ansvarig för samordning av programplanering vid LTH, för hjälp med information kring Industriell ekonomis nya masterspecialisering. Universitetslektor Nina Reistad, programledare för industriell ekonomi vid LTH, för hjälp med information kring Industriell ekonomis nya masterspecialisering. 12

13 Referenser [1] Boehm, B. Turner, R., Management Challenges to Implementing Agile Processes in Traditional Development Organizations. IEEE Software, [2] Manns, M. L. Rising, L., Fearless Change: Patterns for Introducing New Ideas. Addison-Wesley, [3] Baker, S. W., Formalizing agility: an agile organization s journey toward CMMI accreditation. Agile Conference, Denver, Colorado, USA ss Agile Alliance, [4] Beck, K., Andres, C., Extreme Programming Explained: Embrace Change (2nd Edition). Addison-Wesley Professional, [5] Benefield, G., Rolling out Agile in a Large Enterprise. Proceedings of the 41st Hawaii International Conference on System Sciences, Waikoloa, Big Island, Hawaii, ss , [6] Dybå, T. Dingsøyr, T., What Do We Know about Agile Software Development?. IEEE Software, [7] Poppendieck, M. Poppendieck, T., Leading Lean Software Development. Addison-Wesley, [8] Karlström, D. Runeson, P., Integrating agile software development into stage-gate managed product development. Emperical Software Engineering, Springer Science + Business Media, Inc., [9] Kursbeskrivning och kurslitteratursförteckning för kursen EDA240 - Konfigurationshantering, Institutionen för Datavetenskap, Lunds tekniska högskola, [10] Runeson, P. En intevju utförd med Per Runeson, professor vid instituionen för datavetenskap vid Lunds tekniska högskola. Felix Hall och Aron Lidé, [11] Svensson, H. Höst, M. Views from an Organization on How Agile Development Affects Its Collaboration with a Software Development Team. Lecture Notes in Computer Science, Springer Berlin / Heidelberg, [12] Höst, M. En intevju utförd med Martin Höst, universitetslektor vid instituionen för datavetenskap vid Lunds tekniska högskola. Felix Hall och Aron Lidé,