Smidig programvareutvikling

Iterative og inkrementelle metoder for programvareutvikling kan spores tilbake til 1957, og på begynnelsen 1970-tallet kom evolusjonær prosjektledelse^[6][7] og adaptiv programvareutvikling.^[8][9]

På 1990-tallet var det en rekke lettvektige metoder for programvareutviklings som ble utviklet som en reaksjon på de rådende tungvektige metodene (ofte referert til kollektivt som fossefallmodellen) som kritikerne beskrev som altfor regulert, planlagt og detaljstyrt. Lettvektige metoder inkluderte:

• Rask applikasjonsutvikling (rapid application development, RAD) fra 1991^[10][11]
• Enhetlig prosess (unified process, UP) fra 1994
• Dynamisk systemutviklingsmetode (dynamic system development method, DSDM) fra 1994
• Scrum fra 1995
• Crystal Clear og ekstrem programmering (XP) fra 1996
• Funksjonsdrevet utvikling (feature-driven development, FDD) fra 1997

Selv om disse alle oppsto før utgivelsen av Agile Manifesto er de regnet som smidige utviklingsmetoder.^[5]

Allerede siden 1991 har lignende endringer pågått i produksjon^[12][13] og ledelse^[14] avledet fra strømlinjeformet (lean) produksjon.

I 2001 møttes 17 programvareutviklere på feriestedet Snowbird i Utah for å diskutere lettvektige utviklingsmetoder. Disse var Kent Beck (ekstrem programmering), Ward Cunningham (ekstrem programmering), Dave Thomas (PragProg, Ruby), Jeff Sutherland (scrum), Ken Schwaber (scrum), Jim Highsmith (adaptiv programvareutvikling), Alistair Cockburn (Crystal), Robert C. Martin (SOLID), Mike Beedle (scrum), Arie van Bennekum, Martin Fowler (OOAD og UML), James Grenning, Andrew Hunt (PragProg, Ruby), Ron Jeffries (ekstrem programmering), Jon Kern, Brian Marick (Ruby, TDD) og Steve Mellor (OOA). Sammen publiserte de Manifestet for smidig programvareutvikling (engelsk tittel: Manifesto for Agile Software Development).^[4]

I 2005 skrev en gruppe ledet av Alistar Cockburn og Jim Highsmith et tillegg med prinsipper for prosjektledelse kalt PM Declaration of Interdependence^[15] (direkte oversatt: Erklæringen om gjensidig avhengighet i prosjektledelse) for å veilede prosjektledelse innen programvare i henhold til smidig utviklingsmetodikk.

I 2009 skrev en gruppe som jobbet med Robert Martin en utvidelse av prinsippene for programvareutvikling kalt Software Craftsmanship Manifesto for å veilede smidig programvareutvikling med tanke på profesjonell utøvelse og mestring.

I 2011 opprettet Agile Alliance kompendiet Guide to Agile Practices (omdøpt til Agile Glossary i 2016)^[16] som er åpent og under stadig utvikling, og inneholder definisjoner av smidig metodikk, krav og bestanddeler, sammen med tolkninger og retningslinjer basert på erfaring fra utøvere av smidige metoder.

Med bakgrunn i deres erfaring med å utvikle programvare og hjelpe andre med det proklamerte de 17 signatarene til manifestet at de verdsetter:^[4]

• Individer og interaksjoner fremfor prosesser og verktøy
• Fungerende programvare fremfor omfattende dokumentasjon
• Samarbeid med kunder fremfor kontraktsforhandlinger
• Respondere på endringer fremfor å følge en plan

Det skal sies at selv om begge sider har verdi, og at elementene på høyre side bør vurderes, valgte forfatterne av manifestet å vippe vekten mot elementene på venstre side som fokus for hvordan folk bør angripe arbeidet sitt.

Scott Ambler utdypet:^[18]

• Verktøy og prosesser er viktige, men det er viktigere å ha kompetente mennesker som jobber sammen effektivt.
• God dokumentasjon er nyttig for å hjelpe folk til å forstå hvordan programvaren er bygget og hvordan man bruker den, men hovedpunktet i utviklingen er å lage programvare, ikke dokumentasjon.
• En kontrakt er viktig, men er ingen erstatning for å jobbe tett med kundene for å finne ut hva de trenger.
• En prosjektplan er viktig, men den må ikke være for rigid til å imøtekomme endringer i teknologi eller miljø, interessenters prioriteringer og folks forståelse av problemet og løsningen.

Manifestet for smidig programvareutvikling bygger på 12 prinsipper:^[19]

1. Kundetilfredshet ved tidlig og kontinuerlig levering av verdifull programvare.
2. Ønske velkommen endrede krav, selv sent i utviklingen.
3. Levere fungerende programvare ofte (uker istedenfor måneder)
4. Tett, daglig samarbeid mellom forretningsfolk og utviklere
5. Prosjekter er bygget rundt motiverte personer, som bør stoles på
6. Ansikt-til-ansikt-samtaler er den beste formen for kommunikasjon (samlokalisering)
7. Fungerende programvare er det primære målet for fremgang
8. Bærekraftig utvikling, være i stand til å opprettholde et konstant tempo
9. Kontinuerlig fokus på teknisk dyktighet og godt design
10. Enkelhet, altså kunsten å maksimere mengden arbeid som ikke er gjort, er viktig
11. De best arkitekturkrav og design kommer fra selvorganiserende team
12. Laget reflekterer regelmessig over hvordan de kan bli mer effektive, og justerer deretter

De fleste smidige utviklingsmetoder bryter produktutviklingsarbeidet ned i små trinn som minimerer mengden planlegging og design på forhånd. Iterasjoner eller sprinter er korte tidsrammer (tidsbokser) som vanligvis varer fra 1-4 uker. Hver iterasjon innebærer at et tverrfaglig lag arbeider i alle funksjoner: planlegging, analyse, design, koding, enhetstesting og akseptansetesting. På slutten av iterasjonen vises et fungerende produkt til interessentene. Dette minimerer den totale risikoen og gjør at produktet raskt kan tilpasses endringer.^[20] En iterasjon kan ikke legge til nok funksjonalitet for å garantere en markedsutgivelse, men målet er å ha en tilgjengelig utgivelse (som har minimalt med programlus) på slutten av hver iterasjon. Gjennom inkrementell utvikling har produkter plass til å "mislykkes ofte og tidlig" gjennom hver iterativ fase i stedet for drastisk på en endelig utgivelsesdato. Flere iterasjoner kan være nødvendig for å utgi et produkt eller nye funksjoner. Fungerende programvare er det primære målet for fremgang.^[19]

En viktig fordel med smidig utvikling er kortere tid til markedet og reduksjon av risiko. Stegvise forbedringer frigis vanligvis til markedet, hvilket reduserer tids- og kostnadsrisikoen ved å konstruere et produkt som ikke oppfyller brukerkrav.

Det 6. prinsippet i manifestet for smidig programvareutvikling sier at "Den mest effektive måten å formidle informasjon inn til og innad i et utviklingsteam, er å snakke ansikt til ansikt." Manifestet, som riktignok ble skrevet i 2001 da videomøter ikke var utbredt, påpeker at dette gjelder kommunikasjon av informasjon, ikke nødvendigvis hvorvidt laget skal være samlokalisert.

Prinsippet om samlokalisering er at medarbeidere på samme lag bør være på samme sted for å etablere en identitet som et lag og for å forbedre kommunikasjonen.^[21] Dette legger opp til kommuniasjon ansikt til ansikt, ideelt foran en tavle, hvilket reduserer tiden som det vanligvis tar når spørsmål og svar formidles via telefon, chat, wiki eller e-post.^[22] Sammen med utbredt bruk av fjernarbeid under Covid-19-pandemien og endringer i verktøy har det blitt utført flere studier^[23] rundt samlokalisering og distribuert arbeid som viser at samlokalisering blir stadig mindre relevant.

Uansett hvilken smidge utviklingsmetode som følges bør hvert lag inkludere en kunderepresentant (i scrum kalles denne produkteier). Denne representerer interessentene og handler på deres vegne, og forpliktelse seg til å være tilgjengelig for utviklerne å svare på spørsmål gjennom hele iterasjonen. På slutten av hver iterasjon inspiseres fremgangen av prosjektinteressentene og kunderepresentanten, og re-evaluerer prioriteringer med sikte på å optimalisere avkastning og sikre tilpasning til kundens behov og selskapets mål. Betydningen av tilfredshet hos interessentene, tilsynegjort gjennom hyppig samhandling og gjennomgang på slutten av hver fase, er årsaken til at tilnærmingen ofte betegnes som en kundesentrert metodikk.^[24]

I smidig programvareutvikling har man ofte en stor fysisk skjerm eller en table med notatlapper plassert nær utviklingslaget som forbipasserende kan se, og som gir en oppdatert oppsummering av produktutviklingsstatusen.^[25][26] Noen lag bruker et slags trafikklys for å vise hvilket steg teamet er på i produktutviklingen.

En vanlig egenskap i smidig programvareutvikling er daglige ståmøter (kjent som daglig scrum i scrum-rammeverket). I en kort økt (for eksempel 15 minutter) deler gruppemedlemmene fremgangen mot sine mål og blir enige om tilpasninger. For å holde seg til tidsbegrensningen på møtet bruker lagene ofte enkle, kjente spørsmål (som for eksempel hva de gjorde forrige dag, hva de tar sikte på å fullføre denne dagen, og om det er noen hindringer eller risiko for fremgang), og utsetter detaljerte diskusjoner og problemløsning til etter ståmøtet.^[27]

Spesifikke verktøy og teknikker, for eksempel kontinuerlig integrasjon, automatisert enhetstesting, parprogrammering, testdrevet utvikling, designmønstre, atferdsdrevet utvikling, domenedrevet design, koderefaktorering og andre teknikker brukes ofte for å forbedre kvaliteten og forbedre utviklingens smidighet.^[28] Dette baserer seg på at man designer og leverer kvalitet fra starten og at man skal kunne demonstrere programvare for kunden når som helst, eller i det minste på slutten av hver iterasjon.^[29]

Sammenlignet med tradisjonell programvareutvikling, retter smidig programvareutvikling seg hovedsakelig mot komplekse systemer og produktutvikling med dynamiske, ikke-deterministiske og ikke-lineære egenskaper. Nøyaktige estimater, stabile planer og spådommer er ofte vanskelig å komme med i tidlige stadier, og tilliten til dem er sannsynligvis lav. Utøvere av smidig metodikk ønsker å redusere trossprang som trengs før man kan se bevis på verdi.^[30] Krav og design anses som å være stadig under utvikling. Detaljerte spesifikasjoner på forhånd vil trolig føre til mye bortkastet arbeid som kan være vanskelig å forsvare økonomisk. Disse argumentene og bransjeerfaring har bidratt til å gjøre at smidig utvikling lener seg i favør av adaptiv, iterativ og evolusjonær utvikling.^[31]

Utviklingsmetoder eksisterer på et kontinuum fra tilpasningsdyktig til prediktiv.^[32] Smidige utviklingsmetoder ligger på den tilpasningsdyktige siden av dette kontinuumet. En nøkkel i adaptive utviklingsmetoder er en såkalt <i id="mwAQY">rolling wave</i>-tilnærming til tidsplanlegging som identifiserer milepæler, men også gir fleksibilitet med tanke på hvordan man skal nå dem, samt gjør det mulig for milepælene selv å endre seg.^[33]

Tilpasningsdyktige metoder fokuserer på å tilpasse seg raskt ettersom realitetene endrer seg. Når behovene til et prosjekt endres vil et adaptivt lag som arbeider med dette prosjektet også endre seg. Et adaptivt team har problemer med å beskrive nøyaktig hva som vil skje i fremtiden. Jo lenger unna en dato er, jo mer vag vil en adaptiv metode være for å si hva som vil skje på denne datoen. Et adaptivt lag kan ikke rapportere nøyaktig hvilke oppgaver de skal gjøre den neste uken, men bare hvilke funksjoner de planlegger for neste måned. Når du blir spurt om en utgivelse seks måneder fra nå av kan et adaptivt lag kun oppgi formålet for utgivelsen eller forklaring om forventet verdi kontra kostnad.

Prediktive metoder derimot fokuserer på å analysere og planlegge fremtiden i detalj og imøtekomme kjente risikoer. I ekstremer tilfeller kan et prediktivt lag rapportere nøyaktig hvilke funksjoner og oppgaver som er planlagt for hele utviklingsprosessen. Prediktive metoder er avhengige av en effektiv analyse i tidlig fase, og dersom denne går veldig galt kan prosjektet ha problemer med å endre retning. Prediktive lag innstiller ofte en endringskomité for å sikre at de bare vurderer de mest verdifulle endringene.

Risikoanalyse kan brukes til å velge mellom adaptive (smidige eller verdidrevne) og prediktive (plandrevne) metoder.^[34] Barry Boehm og Richard Turner har foreslått at hver side av kontinuumet har sine egne naturlig habitat, som følger:^[35]

En av forskjellene mellom metoder for smidig programvareutvikling og fossfallsmetoder er tilnærmingen til kvalitet og testing. I fossfallmodellen beveger arbeidet seg gjennom en livssyklus for programvareutvikling, hvor en fase slutter før den kan begynne. Derav er testfasen adskilt fra og følger etter en byggefase. I smidig programvareutvikling er utføres imidlertid testing i samme iterasjon som programmeringen. En annen måte å se på det er: "Smidig: Finn på ting underveis. Fossefall: Finn på noe før du starter, lev med konsekvensene."^[36]

Fordi testing gjøres i hver iterasjon (hvor man utvikler et lite stykke programvare) kan brukerne ofte bruke den nye programvaren og validere verdien. Etter at brukerne vet den virkelige verdien av den oppdaterte programvaren kan de ta bedre beslutninger om programvarens fremtid. Ved å ha et verditilbakeblikk og nye planleggingsøkt i hver iterasjon (i scrum har man vanligvis iterasjoner på bare 2 uker) kan laget kontinuerlig tilpasse sine planer for å maksimere verdien det leverer. Dette følger et mønster som ligner på planlegge, gjennomføre, evaluere, korrigere -syklusen (i gjennomgang og retrospektiv), og eventuelle endringer man blir enige om blir agert på.

Denne iterative tilnærmingen støtter opp om et produkt i stedet for et prosjekt som tankesett. Det gir større fleksibilitet i utviklingsprosessen, mens i prosjekter hvor kravene definerte og låste helt fra begynnelsen vil det være vanskelig å endre dem senere. Iterativ produktutvikling gjør at programvaren kan utvikle seg som svar på endringer i forretningsmiljø eller markedskrav.

I et brev til IEEE Computer skrev Steven Rakitin at smidig programvareutvikling var "enda et forsøk på å undergrave programvareutvikling som disiplin" og oversatte "programvare som virker fremfor omfattende dokumentasjon" til at "vi ønsker å bruke all vår tid koding. Husk at ekte programmerere ikke skriver dokumentasjon."^[37]

Denne anekdoten har blitt bestridet av talsmenn for smidig programvareutvikling som istedet sier at utviklere skal skrive dokumentasjon hvis det er den beste måten å oppnå de relevante målene på, men at det ofte er bedre måter å oppnå disse målene på enn å skrive statisk dokumentasjon.^[38] Scott Ambler sier at dokumentasjonen skal være "bare knapt god nok",^[39] og at for mye eller omfattende dokumentasjon vanligvis fører til bortkastet arbeid, og at utviklere sjelden stoler på detaljert dokumentasjon fordi den vanligvis ikke er synkronisert med koden,^[38] selv om for lite dokumentasjon også kan føre til problemer for vedlikehold, kommunikasjon, læring og kunnskapsdeling. Noen av utfordringene med utdatert dokumentasjon kan løses ved bruk av dokumentasjonsgeneratorer.

Ulike metoder for smidige programvareutvikling støtter et bredt spekter av livssyklusen for programvareutvikling. Noen metoder fokuserer på praksis (for eksempel ekstrem programmering, pragmatisk programmering, smidig modellering), mens noen fokuserer på å håndtere arbeidsflyten (for eksempel scrum, kanban). Noen understøtter aktiviteter for kravspesifikasjon og -utvikling (for eksempel funksjonsdrevet utvikling), mens noen forsøker å dekke hele livssyklusen til utviklingen (for eksempel dynamisk systemutviklingsmetode og rasjonell enhetlig prosess).

Notable rammeverk for smidig programvareutvikling inkluderer:

Smidig programvareutvikling støttes av en rekke konkrete praksiser, som dekker områder som krav, design, modellering, koding, testing, planlegging, risikostyring, prosess, kvalitet, et cetera. Noen notable praksiser som underbygger smidig programvareutvikling inkluderer:^[40]

Smidig ledelse betegner en iterativ, inkrementell metode for å administrere design og konstruksjon innen ingeniørfag, informasjonsteknologi og andre forretningsområder hvor man ønsker å utvikle nye produkter eller tjenester på en fleksibel og interaktiv måte basert på prinsippene i Manifestet for smidig programvareutvikling.^[41]

Smidig metrikk kan brukes for å identifisere svake punkter og måle ytelsen til et lag. Smidighet i forsyningskjeden kan hjelpe med å takle usikkerhet og variabilitet i tilbud og etterspørsel, og kan øke og redusere kapasiteten raskt slik at den kan tilpasse seg et raskt skiftende kundebehov. Strategisk smidighet en organisasjons evne til å endre sin handlingsplan etterhvert som miljøet utvikler seg, og baserer seg på å gjenkjenne eksterne endringer tidlig nok og å tildele nok ressurser for å tilpasse seg disse skiftende miljøene.^[42]

Smidig ledelse har vært brukt i næringsliv og offentlig sektor, for eksempel av Det amerikanske byrået for internasjonal utvikling (USAID).^[43]

Ifølge Jean-Loup Richet, forsker ved den franske handelshøyskolen ESSEC, kan en smidig tilnærming også brukes effektivt for andre fagfelt enn programvareprodukter og for prosjektledelse generelt, særlig innen innovasjon og usikkerhet. Ifølge han kan dette resultere i et produkt eller prosjekt som tilfredsstiller dagens kundebehov og leveres med minimale kostnader, minimalt med bortkastet arbeid og tid, og på en slik måte at bedrifter kan oppnå gevinst på bunnlinjen tidligere sammenlignet med tradisjonelle tilnærminger.^[44]

Smidig utviklingsmetoder har blitt mye brukt til utvikling av programvare,^[45] men teknikkene kan også tilpasses for utvikling av andre produkter, som for eksempel datamaskiner, medisinsk utstyr, mat, klær og musikk.^[46] Smidige utviklingsmetoder har også blitt brukt i til drift (altså ikke-utvikling) av IT-infrastruktur -utrullinger og -migreringer. Noen av de bredere prinsippene for smidig programvareutvikling har også blitt brukt i generell ledelse^[47] (for eksempel strategi, styring, risiko, finans) under begrep som forretningssmidighet (business agility) eller smidig administrasjon (agile business management).

Smidig programvareutvikling kan også brukes innen andre områder av livet, som for eksempel oppdragelse av barn. Suksess ved i barns utvikling kan væe basert på grunnleggende styringsprinsipper som kommunikasjon, tilpasning og bevissthet. I en TED Talk delte Bruce Feiler hvordan han brukte grunnleggende smidige prinsipper for å håndtere husholdningen og oppdra barna.^[48]

• Tverrfaglige lag
• Scrum
• Kanban