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, 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.

Begrepet ble popularisert i 2001 gjennom Manifestet for smidig programvareutvikling, og disse verdiene og prinsippene ble avledet fra og underbygger mange forskjellige rammeverk for programvareutvikling, inkludert scrum og kanban.

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 og adaptiv programvareutvikling.

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 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.

Allerede siden 1991 har lignende endringer pågått i produksjonIacocca 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. og ledelse 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).

I 2005 skrev en gruppe ledet av Alistar Cockburn og Jim Highsmith et tillegg med prinsipper for prosjektledelse kalt PM Declaration of Interdependence (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) 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.

Manifestet for smidig programvareutvikling Verdier i smidige programvareutvikling Med bakgrunn i deres erfaring med å utvikle programvare og hjelpe andre med det proklamerte de 17 signatarene til manifestet at de verdsetter:

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:

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:

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

Oversikt høyre|miniatyr|200x200pk|Parprogrammering, en smidig utviklingsteknikk som brukes i ekstrem programmering.

Iterativ, inkrementell og evolusjonær 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. 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.

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. 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. Sammen med utbredt bruk av fjernarbeid under Covid-19-pandemien og endringer i verktøy har det blitt utført flere studier 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.

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. 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.

Kvalitetsfokus 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. 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.

Filosofi 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. 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.

Adaptiv kontra prediktiv Utviklingsmetoder eksisterer på et kontinuum fra tilpasningsdyktig til prediktiv. Appendix A, pages 165–194 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.