Agil systemutveckling

För andra betydelser, se Agil (olika betydelser).

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.

Historik

Metoderna följer den filosofi och de principer som formulerades 2001 i Manifestet för agil systemutveckling 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, , till exempel inom traditionell produktion.

Grundtankar

En 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, Karlskrona Test, 42 points test, Agility measurement index.

Exempel på ett antal "lättrörliga metoder" inom IT:

• Feature Driven Development (FDD)
• Adaptive Software Development
• Dynamic Systems Development Method (DSDM)
• Scrum
• Extrem programmering (XP)
• Lean Software Development
• Crystal
• Nightly build

Mjukvarutvecklingens livscykel

SoftwareDevelopmentLifeCycle.
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).

De tolv Grundprinciperna

Agila metodens tolv grundprinciper är följande:

• Vår högsta prioritet är att tillfredsställa kunden genom tidig och kontinuerlig leverans av värdefull mjukvara.
• Välkomna förändrade krav, även sent under utvecklingen. Agila metoder utnyttjar förändring till kundens konkurrensfördel.
• Leverera fungerande programvara ofta med tidsskala från ett par veckor till ett par månader, med en förkärlek till den kortare tidsskalan.
• Affärsfolk och utvecklare måste arbeta tillsammans dagligen under hela projektet.
• Bygg upp projektet runt motiverade individer. Ge dem den miljö och det stöd de behöver och lita på dem för att få jobbet gjort.
• Den mest effektiva metoden för att förmedla information till och inom ett utvecklingsteam är konversation på plats mellan individerna (en: face-to-face).
• En fungerande programvara är det huvudsakliga måttet på framsteg.
• Agila processer främjar en hållbar utveckling. Sponsorer, utvecklare och användare ska kunna hålla en jämn utvecklingstakt på obestämd tid.
• Kontinuerlig uppmärksamhet på förstklassig teknik och god design ökar flexibiliteten.
• Enkelhet - konsten att maximera mängden arbete som inte görs - är grundläggande.
• Bäst arkitektur, krav och design framträder ur självorganiserande team.
• Med jämna mellanrum reflekterar teamet över hur det kan bli mer effektivt, och justerar och anpassar sitt beteende därefter.

Filosofi

Agile 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

• Agila programspråk
• Prototyp#Inom systemutveckling
• Testdriven utveckling
• Projektledare
• Projektledning

Externa länkar

• Agile Sweden
• The Agile Alliance