Agil systemutveckling

Agil systemutveckling är ett samlingsnamn för ett antal programutvecklingsmetodiker som kan användas vid programvaruutveckling, även kallade lättrörliga metoder. Metoderna följer i stort sett samma värderingar, principer och synsätt. Jämfört med tidigare vattenfallsmodeller representerar de mer flexibla sätt att arbeta. Agile är engelska och betyder smidig, vig, lättrörlig.

Grundtankarna bakom agile bygger på att göra kunden/användaren nöjd med det som utvecklas genom ett mycket nära samarbete under hela utvecklingstiden med täta och regelbundna möten mellan utvecklare och beställare/mottagare. Arbetet bedrivs inkrementellt och iterativt vilket innebär att regelbundna mindre leveranser sker och att saker löpande utvärderas och kan ändras för att möta nya krav och önskemål. Det agila synsättet anser att det oftare är människor och kommunikation än verktyg och formella dokument som löser problem under utvecklingsarbetet.

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 projekt utvecklar agilt (Nokia Test, Karlskrona Test, Agility measurement index).

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

• 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.
Author Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J.

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 stycken grundprinciper är följande:

• Vår högsta prioritet är att tillfredsställa kunden genom tidig och kontinuerlig leverans av värdefull mjukvara.
• Förändrande krav är välkomna, även sent i utvecklingen. Agila processen skördar förändring till kundens konkurrenskraftighet.
• 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ämjer 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å teknisk kvalitet och god design ökar flexibiliteten.
• Enkelhet - konsten att maximera mängden arbete som inte görs - är viktigt.
• De bästa arkitekturer, krav och design framträder ur självorganiserande team.
• Teamet ser över med jämna mellanrum hur man ska blir mer effektiva, sedan finjusteras det och man 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. Inom vattenfallsmodellen anses hög kvalitet betyda att programvaran följer specifikationerna, medan den agila uppfattningen är att hög kvalitet betyder att organisationen följer processerna. I vattenfallsmodellen anses det vara de enskilda programmerarnas problem att skriva specifikationsenlig och felfri källkod, och kvaliteten verifieras i efterhand genom en längre testningssekvens. Inom agile sätter 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.

Externa länkar

• Agile Sweden
• The Agile Alliance