Smidig programvareutvikling
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
[rediger | rediger kilde]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.
Manifestet for smidig programvareutvikling[17]
[rediger | rediger kilde]Verdier i smidige programvareutvikling
[rediger | rediger kilde]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.
Prinsipper for smidig programvareutvikling
[rediger | rediger kilde]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
Oversikt
[rediger | rediger kilde]
Iterativ, inkrementell og evolusjonær
[rediger | rediger kilde]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
[rediger | rediger kilde]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
[rediger | rediger kilde]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]
Kvalitetsfokus
[rediger | rediger kilde]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]
Filosofi
[rediger | rediger kilde]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
[rediger | rediger kilde]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]
| 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
[rediger | rediger kilde]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
[rediger | rediger kilde]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
[rediger | rediger kilde]
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:
| Rammeverk | Bidragsytere |
|---|---|
| Adaptiv programvareutvikling (adaptive software development, ASD) | Jim Highsmith, Sam Bayer |
| Smidig modellering (agile modeling, AM) | Scott Ambler, Robert Cecil Martin |
| Smidig enhetlig prosess (agile unified process, AUP) | Scott Ambler |
| Disiplinert smidig leveranse (disciplined agile delivery, DAD) | Scott Ambler |
| Dynamisk systemutviklingsmetode (dynamic systems development method, DSDM) | Jennifer Stapleton |
| Ekstrem programmering (extreme programming, XP) | Kent Beck, Robert Cecil Martin |
| Funksjonsdrevet utvikling (feature-driven development, FDD) | Jeff De Luca |
| Strømlinjeformet programvareutvikling (lean software development) | Mary Poppendieck, Tom Poppendieck |
| Strømlinjeformet oppstart (lean startup) | Eric Ries |
| Kanban | Taiichi Ohno |
| Rask applikasjonsutvikling (rapid application development, RAD) | James Martin |
| Scrum | Ken Schwaber, Jeff Sutherland |
| Scrumban | |
| Skalert smidig rammeverk (scaled agile framework, SAFe) | Scaled Agile, Inc. |
Smidig praksis
[rediger | rediger kilde]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]
| Praksis | Bidragsytere |
|---|---|
| Akseptansetest-drevet utvikling (ATDD) | |
| Smidig modellering | |
| Smidig testing | |
| Kø av funksjonaliteter (produktkø og sprintkø) | Ken Schwaber |
| Atferdsdrevet utvikling | Dan North, Liz Keogh |
| Kontinuerlig integrasjon | Grady Booch |
| Tverrfaglig lag | |
| Daglig stand-up / Daglig Scrum | James O Coplien |
| Domenedrevet design | Eric Evans |
| Iterativ og inkrementell utvikling | |
| Parprogrammering | Kent Beck |
| Planleggingspoker | James Grenning, Mike Cohn |
| Refaktorering | Martin Fowler |
| Retrospektiv | |
| Scrumhendelser (sprintplanlegging, sprintgjennomgang og retrospektiv) | |
| Spesifikasjon gjennom eksempel | |
| Historiedrevet modellering | Albert Zündorf |
| Testdrevet utvikling | Kent Beck |
| Tidsbokser | |
| Brukerhistorier | Alistair Cockburn |
| Måling av hastighet |
Smidig ledelse
[rediger | rediger kilde]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]
Bruk utenfor programvareutvikling
[rediger | rediger kilde]
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]
Se også
[rediger | rediger kilde]Referanser
[rediger | rediger kilde]- ^ Collier, Ken W. Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing. Pearson Education. ISBN 9780321669544. «What is a self-organizing team?»
- ^ Beck; Beedle; Bennekum; Cockburn. «Manifesto for Agile Software Development».
- ^ «What is Agile Software Development?». Agile Alliance. Besøkt 4. april 2015.
- ^ a b c Kent Beck. «Manifesto for Agile Software Development». Agile Alliance. Besøkt 14. juni 2010.
- ^ a b Larman, Craig. Agile and Iterative Development: A Manager's Guide. Addison-Wesley. s. 27. ISBN 978-0-13-111155-4.
- ^ «Evolutionary Project Management (Original page, external archive)». Gilb. Arkivert fra originalen 27. mars 2016. Besøkt 30. april 2017.
- ^ «Evolutionary Project Management (New page)». Gilb. Arkivert fra originalen 7. februar 2018. Besøkt 30. april 2017.
- ^ Edmonds. «A Process for the Development of Software for Nontechnical Users as an Adaptive System».
- ^ Gilb (1. april 1981). «Evolutionary development».
- ^ Martin, James. Rapid Application Development. Macmillan. ISBN 978-0-02-376775-3.
- ^ Kerr, James M.; Hunter, Richard. Inside RAD: How to Build a Fully Functional System in 90 Days or Less. McGraw-Hill. s. 3. ISBN 978-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.
- ^ Sanchez, Luis (November 2010). «A Review of Agile Manufacturing Systems». International Journal of Production Research (39(16):3561-3600).
- ^ Anderson, David. «Declaration of Interdependence». Arkivert fra originalen 27. januar 2018. Besøkt 4. oktober 2018.
- ^ McDonald, Kent (1. november 2016). «How You Can Help Agile Alliance Help You». Agile Alliance Blog. Besøkt 4. juli 2017.
- ^ «Manifestet for smidig programvareutvikling». agilemanifesto.org. Besøkt 10. oktober 2022.
- ^ «Examining the Agile Manifesto». Ambysoft Inc. Besøkt 6. april 2011.
- ^ a b Kent Beck. «Principles behind the Agile Manifesto». Agile Alliance. Arkivert fra originalen 14. juni 2010. Besøkt 6. juni 2010.
- ^ Moran, A. Agile Risk Management. Springer Verlag. ISBN 978-3319050072.
- ^ Preuss, Deborah Hartmann. «Study: Co-Located Teams vs. the Cubicle Farm». Besøkt 23. oktober 2018.
- ^ Cockburn, Alistair. «Agile Software Development: The Cooperative Game» (2nd utg.). Addison-Wesley Professional. Besøkt 23. oktober 2018.
- ^ «Management Transformed | Research». CMI (på engelsk). Besøkt 10. oktober 2022.
- ^ Jain, Parita (August 2018). «The Impact of Agile Software Development Process on the Quality of Software Product». IEEE.
- ^ Cockburn, Alistair. «Information radiator».
- ^ Ambler, Scott (12. april 2002). Agile Modeling: Effective Practices for EXtreme Programming and the Unified Process. John Wiley & Sons. ISBN 978-0-471-20282-0.
- ^ Vasiliauskas, Vidas. «Developing agile project task and team management practices». Eylean. Arkivert fra originalen 15. september 2014. Besøkt 15. september 2014.
- ^ Jeffries, Ron; Anderson, Ann; Hendrickson, Chet (2001). Extreme Programming installed. Addison-Weslsy. ISBN 978-0201-70842-4.
- ^ 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. ISBN 978-1-908552-49-5.
- ^ Larman, Craig. Agile and Iterative Development: A Manager's Guide. Addison-Wesley. s. 27. ISBN 978-0-13-111155-4.
- ^ Boehm, B.; R. Turner. Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN 978-0-321-18612-6. Appendix A, pages 165–194
- ^ Larman, Craig. «Chapter 11: Practice Tips». Agile and Iterative Development: A Manager's Guide. s. 253. ISBN 9780131111554. Besøkt 14. oktober 2013.
- ^ Sliger, Michele; Broderick, Stacia. The Software Project Manager's Bridge to Agility. Addison-Wesley. s. 46. ISBN 978-0-321-50275-9.
- ^ Boehm, B.; R. Turner. Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN 978-0-321-18612-6.
- ^ «Paul Downey's view at Twitter».
- ^ Rakitin. «Manifesto Elicits Cynicism: Reader's letter to the editor by Steven R. Rakitin».
- ^ a b Scott Ambler. «Agile/Lean Documentation: Strategies for Agile Software Development».
- ^ Scott Ambler. «Just Barely Good Enough Models and Documents: An Agile Best Practice». Arkivert fra originalen 8. oktober 2014. Besøkt 10. oktober 2022.
- ^ «Guide to Agile Practices». the Agile Alliance. Arkivert fra originalen 9. februar 2014.
- ^ Moran, Alan (2015). Managing Agile: Strategy, Implementation, Organisation and People. Springer. ISBN 978-3-319-16262-1.
- ^ «The Procurement Call for Agile, What does it mean?».
- ^ USAID. "ADS Chapter 201 Program Cycle Operational Policy" Arkivert 23. oktober 2019 hos Wayback Machine. Arkivert 23 oktober 2019 hos Wayback Machine. Retrieved 19 April 2017
- ^ Richet, Jean-Loup (2013). Agile Innovation. Cases and Applied Research, n°31. ESSEC-ISIS. ISBN 978-2-36456-091-8
- ^ Smith, Preston G. Flexible Product Development. Jossey-Bass. s. 25. ISBN 978-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. ISBN 978-1-4939-0535-5.
- ^ Moran, Alan. Managing Agile: Strategy, Implementation, Organisation and People. Springer Verlag. ISBN 978-3-319-16262-1.
- ^ "Agile programming – for your family".