Agile Development

Agil utveckling är ett tillvägagångssätt för att bygga programvara som levererar arbete i korta iterationer, kontinuerligt införlivar feedback och anpassar planer allt eftersom förståelsen förbättras. Det formulerades i det agila manifestet från 2001, som angav fyra värdepreferenser: individer och interaktioner framför processer och verktyg, fungerande programvara framför omfattande dokumentation, kundsamarbete framför kontraktsförhandlingar och att reagera på förändringar framför att följa en plan.

Manifestets formuleringar citeras ofta felaktigt på ett sätt som är viktigt. Varje påstående uttrycker en preferens mellan två saker som båda har värde, inte ett förkastande av det andra. Dokumentet säger uttryckligen att även om det finns värde i punkterna till höger, värderas punkterna till vänster mer. Implementeringar som tolkar manifestet som att det förbjuder dokumentation, planering eller kontrakt har förkastat hälften av vad det säger och producerar vanligtvis den oordning som kritiker tillskriver själva tillvägagångssättet.

Den underliggande logiken handlar om osäkerhet. Sekventiell utveckling antar att krav kan specificeras korrekt i förväg, vilket gäller för väl förstådda problem och misslyckas för produkter vars värde beror på hur människor reagerar på dem. Iterativ leverans minskar kostnaden för att ha fel genom att förkorta intervallet mellan ett beslut och bevis om det, vilket är värdefullt i proportion till hur osäkert problemet är.

Det vanligaste misslyckandet i praktiken är att man anammar ceremonier utan principerna. Organisationer inför dagliga möten, iterationsgränser och uppskattningsmetoder samtidigt som de bibehåller fasta omfattningar, fasta deadlines, årlig planering och ingen mekanism för att agera på feedback. Resultatet är sekventiell utveckling som genomförs i tvåveckorssegment med ytterligare möten, vilket är långsammare än om någon av metoderna utförs korrekt och skapar en utbredd skepsis mot metodiken.

Kundsamarbetet är det som organisationer har svårast att hantera och hoppar över oftast. Att anpassa sig till feedback kräver att man faktiskt får feedback, vilket innebär att riktiga användare regelbundet interagerar med fungerande programvara. Team som arbetar utifrån en proxy, oavsett om det är en intern intressent eller en skriftlig specifikation, har iterationskadensen utan den input som ger den ett syfte, och de itererar med självförtroende i en riktning som ingen har validerat.

Skalning medför verkliga svårigheter som den ursprungliga formuleringen inte åtgärdade, eftersom manifestet skrevs med små samlokaliserade team i åtanke. Att koordinera många team kring en produkt kräver mekanismer för samordning, beroendehantering och arkitektonisk koherens, och de olika skalningsramverk som hanterar detta kritiseras ofta för att de återinför den processvikt som tillvägagångssättet var avsett att minska. Spänningen är verklig snarare än ett missförstånd.

Bedömningen bör fokusera på resultat snarare än på följsamhet. De relevanta frågorna är om tiden från idé till validerat lärande har förkortats, om teamet kan ändra riktning när bevisen motiverar det, om kvaliteten bibehålls snarare än att bytas bort under deadline, och om produkten är mätbart bättre för användarna. Team som utför varje föreskriven praxis samtidigt som de levererar årligen enligt en fast specifikation har anammat vokabulären utan att dra någon nytta av den.

Eftersom tillvägagångssättet är lika mycket beroende av organisatoriska förutsättningar som av teamets praktik, kräver implementeringen ofta förändringar i styrning, finansiering och planering som ligger utanför leveransteamet. I praktiken hanteras detta inom produktutveckling vid sidan av själva leveransprocessen, med återkopplingsslingan som stöds av användarundersökning, och organisationer som bygger upp kapaciteten internt etablerar den vanligtvis inom en produktavdelningen där planering och leveransansvar går hand i hand.