Innen programvareutvikling er smidig utvikling (engelsk: agile development) en form for prosjektarbeid hvor oppdagelse av krav og forbedring av løsninger gjøres gjennom samarbeid i selvorganiserende og tverrfaglige lag hvor kunden eller sluttbrukeren er med,[1] adaptiv planlegging, evolusjonær utvikling, tidlig levering, kontinuerlig forbedring, og fleksibel respons på endringer i krav, kapasitet og forståelse av problemene som skal løses.[2][3]
Begrepet ble popularisert i 2001 gjennom Manifestet for smidig programvareutvikling,[4] og disse verdiene og prinsippene ble avledet fra og underbygger mange forskjellige rammeverk for programvareutvikling, inkludert scrum og kanban.[5]
Det finnes mye anekdotiske bevis for at smidige metoder og verdier forbedrer effektiviteten hos programmerere, lag og organisasjoner, men empiriske bevis er blandede og vanskelig å finne.
Historie
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:
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.
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.
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.
Prinsipper for smidig programvareutvikling
Manifestet for smidig programvareutvikling bygger på 12 prinsipper:[19]
Kundetilfredshet ved tidlig og kontinuerlig levering av verdifull programvare.
Ønske velkommen endrede krav, selv sent i utviklingen.
Levere fungerende programvare ofte (uker istedenfor måneder)
Tett, daglig samarbeid mellom forretningsfolk og utviklere
Prosjekter er bygget rundt motiverte personer, som bør stoles på
Ansikt-til-ansikt-samtaler er den beste formen for kommunikasjon (samlokalisering)
Fungerende programvare er det primære målet for fremgang
Bærekraftig utvikling, være i stand til å opprettholde et konstant tempo
Kontinuerlig fokus på teknisk dyktighet og godt design
Enkelhet, altså kunsten å maksimere mengden arbeid som ikke er gjort, er viktig
De best arkitekturkrav og design kommer fra selvorganiserende team
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.
Kommunikasjon: Effektivt og ansikt til ansikt
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.
Hyppige tilbakemeldinger og rask tilpasning
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]
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]
Adaptiv kontra prediktiv
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]
Naturlige habitat for ulike utviklingsmetoder
Verdidrevne metoder
Plandrevne metoder
Formelle metoder
Lav kritikalitet
Høy kritikalitet
Ekstrem kritikalitet
Seniorutviklere
Juniorutviklere(?)
Seniorutviklere
Kravene endres ofte
Kravene endres ikke ofte
Begrensede krav, begrensede funksjoner, se Wirths lov
Lite antall utviklere
Stort antall utviklere
Krav som kan modelleres
Kultur som reagerer på endring
Kultur som krever orden
Ekstrem kvalitet
Smidig kontra fossefall
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.
Kode kontra dokumentasjon
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.
Metoder for smidige programvareutvikling
Livssyklusstøtte fra ulike rammeverkSmidig enhetlig prosess (<i>agile unified process</i>, AUP) er basert på enhetlig prosess (en rammeverk for iterativ og inkrementell programvareutvikling)
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]
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]
^Collier, Ken W. Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing. Pearson Education. ISBN9780321669544. «What is a self-organizing team?»
^Beck; Beedle; Bennekum; Cockburn. «Manifesto for Agile Software Development».
^Kerr, James M.; Hunter, Richard. Inside RAD: How to Build a Fully Functional System in 90 Days or Less. McGraw-Hill. s. 3. ISBN978-0-07-034223-1.
^Iacocca Institute (1991). "21st Century Manufacturing Enterprise Strategy: An Industry Led View". Iacocca Institute, Lehigh University, Bethlehem, PA.
^Presley, A., J. Mills and D. Liles (1995). "Agile Aerospace Manufacturing". Nepcon East 1995, Boston.
^Ambler, Scott (12. april 2002). Agile Modeling: Effective Practices for EXtreme Programming and the Unified Process. John Wiley & Sons. ISBN978-0-471-20282-0.
^Lisa Crispin; Janet Gregory. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley.
^Mitchell, Ian. Agile Development in Practice. Tamare House. s. 11. ISBN978-1-908552-49-5.
^Larman, Craig. Agile and Iterative Development: A Manager's Guide. Addison-Wesley. s. 27. ISBN978-0-13-111155-4.
^Boehm, B.; R. Turner. Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN978-0-321-18612-6. Appendix A, pages 165–194
^Smith, Preston G. Flexible Product Development. Jossey-Bass. s. 25. ISBN978-0-7879-9584-3.
^Newton Lee. "Getting on the Billboard Charts: Music Production as Agile Software Development," Digital Da Vinci: Computers in Music. Springer Science+Business Media. ISBN978-1-4939-0535-5.
