Agil utvikling

Smidig utvikling er en tilnærming til å bygge programvare som leverer arbeid i korte iterasjoner, kontinuerlig innlemmer tilbakemeldinger og tilpasser planer etter hvert som forståelsen forbedres. Dette ble formulert i Agile Manifestet i 2001, som anga fire verdipreferanser: individer og interaksjoner fremfor prosesser og verktøy, fungerende programvare fremfor omfattende dokumentasjon, kundesamarbeid fremfor kontraktsforhandlinger og respons på endringer fremfor å følge en plan.

Manifestets formuleringer blir ofte feilsitert på en måte som betyr noe. Hvert utsagn uttrykker en preferanse mellom to ting som begge har verdi, ikke en avvisning av det andre. Dokumentet sier eksplisitt at selv om det er verdi i elementene til høyre, verdsettes elementene til venstre mer. Implementeringer som leser manifestet som om det forbyr dokumentasjon, planlegging eller kontrakter, har forkastet halvparten av det det sier og produserer vanligvis den uordenen som kritikere tilskriver selve tilnærmingen.

Den underliggende begrunnelsen handler om usikkerhet. Sekvensiell utvikling forutsetter at krav kan spesifiseres nøyaktig på forhånd, noe som gjelder for godt forståtte problemer og mislykkes for produkter hvis verdi avhenger av hvordan folk reagerer på dem. Iterativ levering reduserer kostnadene ved å ta feil ved å forkorte intervallet mellom en beslutning og bevis om den, noe som er verdifullt i forhold til hvor usikkert problemet er.

Den vanligste feilen i praksis er å ta i bruk seremonier uten prinsippene. Organisasjoner innfører daglige møter, iterasjonsgrenser og estimeringspraksis samtidig som de beholder et fast omfang, faste tidsfrister, årlig planlegging og ingen mekanisme for å handle på tilbakemeldinger. Resultatet er sekvensiell utvikling som gjennomføres i toukers segmenter med ekstra møter, noe som er tregere enn noen av tilnærmingene gjort riktig, og det skaper en utbredt skepsis til metodikken.

Kundesamarbeidselementet er det organisasjoner synes er vanskeligst og hopper over oftest. Å tilpasse seg tilbakemeldinger krever faktisk innhenting av tilbakemeldinger, noe som betyr at ekte brukere regelmessig engasjerer seg i fungerende programvare. Team som opererer på en stedfortreder, enten det er en intern interessent eller en skriftlig spesifikasjon, har iterasjonskadensen uten innspillet som gir det formål, og de itererer selvsikkert i en retning ingen har validert.

Skalering introduserer reelle vanskeligheter som den opprinnelige formuleringen ikke tok for seg, siden manifestet ble skrevet med tanke på små, samlokaliserte team. Koordinering av mange team på ett produkt krever mekanismer for samordning, avhengighetshåndtering og arkitektonisk sammenheng, og de ulike skaleringsrammeverkene som adresserer dette blir ofte kritisert for å gjeninnføre prosessvekten som tilnærmingen var ment å redusere. Spenningen er reell snarere enn en manglende forståelse.

Vurdering bør fokusere på resultater snarere enn etterlevelse. De relevante spørsmålene er om tiden fra idé til validert læring har blitt kortere, om teamet kan endre retning når bevisene tilsier det, om kvaliteten opprettholdes i stedet for å bli byttet bort innenfor tidsfristen, og om produktet er målbart bedre for brukerne. Team som utfører alle foreskrevne fremgangsmåter samtidig som de leverer årlig i henhold til en fast spesifikasjon, har tatt i bruk vokabularet uten å oppleve noen av fordelene.

Fordi tilnærmingen avhenger like mye av organisatoriske forhold som av teamets praksis, krever implementering ofte endringer i styring, finansiering og planlegging som ligger utenfor leveranseteamet. I praksis håndteres dette innen produktutvikling ved siden av selve leveringsprosessen, med tilbakemeldingssløyfen støttet av brukerforskning, og organisasjoner som bygger opp kapasiteten internt, etablerer den vanligvis innenfor en produktavdeling der planlegging og leveringsansvar henger sammen.