|
Agil systemutveckling
Agil systemutveckling är ett samlingsnamn för ett antal systemutvecklingsmetoder som kan användas vid programvaruutveckling i IT och även inom organisationsteori, också kallade lättrörliga metoder eller iterativa metoder. HistorikMetoderna följer den filosofi och de principer som formulerades 2001 i Manifestet för agil systemutveckling [1] av en grupp programmerare. De hade reagerat på fallerade IT-utvecklingsprojekt som är fastlåsta vid orealistiska projektplaner och lider av allt för byråkratiserande dokumentation istället för uppvisande av resultat. Dessa innebär vidare allt för detaljerade kravspecifikationer och omfattande kontraktskrivande istället för fungerande kommunikation mellan kund och leverantör. Jämfört med traditionella systemutvecklingsmetoder såsom vattenfallsmodellen representerar de mer flexibla sätt att arbeta. Agile är engelska och betyder smidig, vig, lättrörlig, jämför agility. På senare tid används ett agilt synsätt även utanför IT-sfären,[2] [3] [4] [5], till exempel inom traditionell produktion.[6] GrundtankarEn grundtanke i agila metoder är att arbetet bedrivs inkrementellt och iterativt, vilket innebär att fungerande delleveranser av funktionalitet sker regelbundet enligt ett schema och att planer och metoder löpande utvärderas och förbättras. Ändamålsenlig och användarcentrerad utveckling eftersträvas genom ett nära samarbete under hela utvecklingstiden med täta och regelbundna möten mellan utvecklare och beställare/mottagare. Man formulerar tidigt mål och visioner, istället för att arbeta mot hårda och detaljerade tekniska krav. Den detaljerade kravspecifikationen blir ett slutresultat av utvecklingsprojektet istället för ett ingångsvärde. Det agila synsättet anser att det främst är människor och kommunikation som kan lösa problem under utvecklingsarbetet, snarare än verktyg och formella dokument. En annan central grundtanke är att minimera risken för att en stor del av ett system befinner sig i ett halvfärdigt läge och inte kan leverera nytta. Ett agilt arbetssätt gör det möjligt för beslutsfattare att få ett bättre underlag inför beslut om att tillföra ytterligare resurser till ett projekt. Det finns självutvärderingar för att avgöra om ett arbetsprojekt fungerar enligt ett agilt tillvägagångssätt: Nokia Test[7], Karlskrona Test[8], 42 points test[9], Agility measurement index[10]. Exempel på ett antal "lättrörliga metoder" inom IT:
Mjukvarutvecklingens livscykel Författare: P. Abrahamsson, O. Salo, J. Ronkainen och J. Warsta. De agila metoderna är fokuserade på olika aspekter av mjukvaruutvecklingens livscykel. Vissa fokuserar på metoder (Extrem programmering, pragmatisk programmering, agila modeller), medan andra fokuserar på att hantera mjukvaruprojekt (Scrum). Ändå finns det metoder som ger full täckning över hela livscykeln (DSDM, RUP), medan de flesta av dem är lämpliga från kravspecifikationsfasen (till exempel FDD). Det finns alltså en tydlig skillnad mellan de olika lättrörliga metoderna för programvaruutveckling i detta avseende. DSDM och RUP behöver inte kompletterande metoder för att stödja utvecklingen av programvaran, de andra gör det i varierande grad. DSDM kan användas av vem som helst (även om bara DSDM-medlemmar kan erbjuda DSDM produkter eller tjänster). RUP är alltså en kommersiellt säljande utvecklingsmiljö (Abrahamsson, Salo, Ronkainen & Warsta, 2002)[11][12]. De tolv GrundprincipernaAgila metodens tolv grundprinciper[13] är följande:
FilosofiAgile jämförs ofta med den rådande vattenfallsmodellen. Skillnader i uppfattningen av grundläggande filosofiska begrepp gör dock att dessa inte är förenliga med varandra. Det grundläggande problemet är att vattenfallsmodellen har utvecklats från Taylorismen och från tillverkning av fysiska varor med signifikant marginalkostnad, medan programvara är immateriell och kan dupliceras utan marginalkostnad. Vattenfallsmodellen är uttryckligen positivistisk. Man anser bl.a. att framtiden är förutsägbar: projekt slår fel på grund av bristande planering, vilket innebär att man i framtiden borde planera ännu noggrannare. Att världen skulle vara oförutsägbar kommer inte på fråga. Inom agile gör man däremot tydlig skillnad mellan förutsägbarhet och kausalitet (förhållandet mellan orsak och verkan). Kausala förhållanden kan nämligen ligga dolda tills man samlat tillräckligt mycket förståelse. Det är t.ex. stört när omöjligt att förutspå hur börsen reagerar på en kvartalsrapport, men relativt enkelt att i efterskott, med facit på hand, analysera orsak och verkan bakom aktiekursens rörelser (exempelvis "företaget nådde inte upp till investerarnas förväntningar och aktiekursen sjönk med 10%"). Inom agile anser man därför att programvaruutveckling som verksamhetsdomän inte är tillräckligt förutsägbar för att det ska löna sig att skapa och följa långtidsplaner. Resurser bör i stället reserveras för att snabbt kunna reagera på oväntade händelser, och beslut ska inte tas i förtid om det ännu finns möjlighet att samla mer information. Också uppfattningen om kvalitet är olika. I vattenfallsmodellen anses det vara de enskilda programmerarnas uppgift att säkerställa specifikationsenlig och felfri källkod, och kvaliteten verifieras i efterhand genom en längre testningssekvens. Inom agile lägger man i stället stor vikt vid systemtänkande: processerna ska vara smidiga och styra hela organisationens arbete så att det är lätt att göra rätt och svårt att göra fel. Då är chansen stor att resultatet blir bra. Se även
Källor
Externa länkar |