Agile udviklingsmetodik

Agile udviklingsmetodologi ( engelsk  agile software development , agile development ) er en generel betegnelse for en række tilgange og praksis baseret på værdierne i Agile Software Development Manifesto og de 12 principper, der ligger til grund for det [1] .

Agile metoder omfatter især ekstrem programmering , DSDM , Scrum , FDD , BDD og andre.

De fleste agile metoder sigter mod at minimere risikoen ved at reducere udviklingen til en række korte cyklusser, kaldet iterationer, der typisk varer to til tre uger. Hver iteration i sig selv ligner et miniaturesoftwareprojekt og inkluderer alle de opgaver, der er nødvendige for at producere en minivækst i funktionalitet: planlægning, kravanalyse , design , programmering , test og dokumentation . Selvom en enkelt iteration generelt ikke er tilstrækkelig til at frigive en ny version af et produkt, antages det, at et agilt softwareprojekt er klar til udgivelse ved slutningen af ​​hver iteration. I slutningen af ​​hver iteration revurderer teamet udviklingsprioriteterne.

Agile metoder lægger vægt på ansigt-til-ansigt kommunikation. De fleste agile teams er placeret på samme kontor, nogle gange omtalt som eng.  bullpen . Som minimum inkluderer det også "kunder" ( engelsk  produktejer  - kunden eller dennes autoriserede repræsentant, der bestemmer kravene til produktet; denne rolle kan udføres af en projektleder, forretningsanalytiker eller klient). Kontoret kan også omfatte testere, grænsefladedesignere, tekniske skribenter og ledere.

Det vigtigste mål for agile metoder er arbejdsproduktet. Ved at prioritere ansigt-til-ansigt kommunikation reducerer agile metoder mængden af ​​skriftlig dokumentation sammenlignet med andre metoder. Dette har ført til kritik af disse metoder som udisciplinerede.

Historie

I løbet af 1990'erne udviklede en række lette softwareudviklingsmetoder sig som reaktion på de fremherskende tunge metoder, som kritikere kaldte overregulerede, planlagte og mikrostyrede. Disse omfatter: Rapid Application Development (RAD) siden 1991 [2] [3] ; samlet proces og metode til udvikling af dynamiske systemer siden 1994; Scrum, siden 1995; Crystal Clear og Extreme Programming (XP), begge siden 1996; og funktionsorienteret udvikling siden 1997. Selvom de alle opstod før offentliggørelsen af ​​Agile Manifesto, omtales de nu samlet som agil softwareudvikling.

I februar 2001 blev " Agil Software Development Manifesto " udgivet i Utah, USA . Det gav et alternativ til dokumentdrevet "tungvægts" softwareudviklingspraksis såsom " vandfaldsmetoden ", som var den gyldne standard for udvikling på det tidspunkt. Dette manifest blev godkendt og underskrevet af repræsentanter for følgende metoder: Ekstrem programmering , Crystal Clear , DSDM , Funktionsdrevet udvikling , Scrum , Adaptiv softwareudvikling , Pragmatisk programmering . Agile udviklingsmetodologi blev brugt af mange virksomheder, selv før vedtagelsen af ​​manifestet, dog skete den agile udviklings indtog i masserne netop efter denne begivenhed.

Principper

Agile er en familie af udviklingsprocesser, ikke en enkelt tilgang til softwareudvikling, og er defineret af Agile Manifesto [4] . Agile inkluderer ikke praksis, men definerer de værdier og principper, der guider teams.

Agile Manifesto blev udviklet og vedtaget 11.-13. februar 2001 på The Lodge at Snowbird skisportssted i Utah-bjergene. Agile Manifesto indeholder 4 hovedideer og 12 principper. Det er bemærkelsesværdigt, at Agile Manifesto ikke indeholder praktiske råd.

Nøgle ideer:

• mennesker og interaktion er vigtigere end processer og værktøjer;
• et fungerende produkt er vigtigere end omfattende dokumentation;
• samarbejde med kunden er vigtigere end at blive enige om vilkårene i kontrakten;
• forandringsparathed er vigtigere end at følge den oprindelige plan.

Grundlæggende principper for Agile Manifesto [6] :

• kundetilfredshed gennem tidlig og uafbrudt levering af værdifuld software anerkendes som højeste prioritet;
• ændrede krav er velkomne selv i slutningen af ​​udviklingen (dette kan øge konkurrenceevnen for det resulterende produkt);
• hyppig levering af fungerende software (hvert par uger eller et par måneder med en præference for en kortere periode);
• kommunikation mellem virksomhedsrepræsentanter og udviklere bør være dagligt gennem hele projektet;
• projekter bør bygges op omkring interesserede mennesker, som skal have de rette arbejdsforhold, støtte og tillid;
• den mest effektive metode til at dele information i et team er et personligt møde;
• fungerende software er det bedste mål for fremskridt;
• sponsorer, udviklere og brugere skal være i stand til at opretholde et konstant tempo i det uendelige;
• konstant opmærksomhed på teknisk ekspertise og godt design øger fleksibiliteten;
• enkelhed, ligesom kunsten ikke at udføre unødvendigt arbejde, er meget vigtig;
• de bedste krav, arkitektur og designløsninger kommer fra selvorganiserende teams;
• teamet tænker regelmæssigt på måder at forbedre effektiviteten på og tilpasser arbejdsgangen i overensstemmelse hermed.

Kritik

Et af de tilbagevendende kritikpunkter: Den agile tilgang negligerer ofte oprettelsen af ​​en plan ("roadmap") for produktudvikling samt kravstyring , i den proces, hvormed et sådant "kort" dannes. En fleksibel tilgang til kravstyring indebærer ikke vidtrækkende planer (faktisk eksisterer kravstyring simpelthen ikke i denne metodologi), men indebærer kundens evne til pludselig og uventet at stille nye krav i slutningen af ​​hver iteration, ofte i modstrid med arkitekturen af ​​et allerede skabt og leveret produkt. Dette fører nogle gange til katastrofalt "hands on work" med massiv refactoring og rework ved næsten hver næste iteration.

Derudover menes det, at arbejde i agile motiverer udviklere til at løse alle indkommende opgaver på den enkleste og hurtigst mulige måde, mens de ofte ikke er opmærksomme på kodens korrekthed i forhold til kravene til den underliggende platform (den "værker og alt” tilgang), uden at tage højde for, at koden kan holde op med at fungere, hvis den ændres yderligere. Dette resulterer i nedsat produktkvalitet og en ophobning af defekter (se " teknisk gæld ").

Metoder

Der er metoder, der overholder de værdier og principper, der er angivet i Agile Manifesto, nogle af dem er:

• Agile Modeling  er et sæt af koncepter, principper og teknikker (praksis), der giver dig mulighed for hurtigt og nemt at udføre modellering og dokumentation i softwareudviklingsprojekter. Indeholder ikke detaljerede designanvisninger, indeholder ikke beskrivelser af, hvordan man bygger UML-diagrammer. Hovedmål: effektiv modellering og dokumentation; men dækker ikke programmering og test, omfatter ikke projektledelse, implementering og vedligeholdelse af systemet. Det omfatter dog kontrol af modellen med kode [7] .
• The Agile Unified Process (AUP) er en forenklet version af IBM Rational Unified Process ( RUP ) udviklet af Scott Ambler, der beskriver en enkel og forståelig tilnærmelse (model) til at bygge software til forretningsapplikationer.
• Agile Data Method  er en gruppe af iterative softwareudviklingsmetoder, hvor krav og løsninger opnås gennem samarbejde mellem forskellige tværfunktionelle teams.
• DSDM er baseret på konceptet Rapid Application Development (RAD). Det er en iterativ og inkrementel tilgang, der lægger vægt på fortsat bruger-/forbrugerinddragelse i processen.
• Essential Unified Process (EssUP).
• Ekstrem programmering ( Ekstrem programmering , XP) . 
• Funktionsdrevet udvikling (FDD) - funktionsorienteret udvikling. Konceptet med en systemfunktion eller  -egenskab , der bruges i FDD , er ret tæt på konceptet med en brugssag, der bruges i RUP, den væsentlige forskel er en yderligere begrænsning: "hver funktion skal tillade implementering i højst to uger." Det vil sige, at hvis en use case er lille nok, kan den betragtes som en funktion. Hvis den er stor, så skal den opdeles i flere relativt uafhængige funktioner.
• Getting Real  er en iterativ, ikke-funktionel specifikationstilgang, der bruges til webapplikationer. I denne metode udvikles først programmets grænseflade og derefter dens funktionelle del.
• OpenUP  er en iterativ-inkrementel softwareudviklingsmetode. Den er placeret som en let og fleksibel version af RUP . OpenUP opdeler projektets livscyklus i fire faser: start, forfining, konstruktion og overdragelse. Projektets livscyklus giver interessenter og teammedlemmer referencepunkter og beslutningstagning gennem hele projektet. Dette giver dig mulighed for effektivt at kontrollere situationen og træffe rettidige beslutninger om accept af resultaterne. Projektplanen definerer livscyklussen, og slutresultatet er den endelige ansøgning.
• Scrum etablerer regler for styring af udviklingsprocessen og giver dig mulighed for at bruge eksisterende kodningspraksis ved at justere krav eller foretage taktiske ændringer. Ved at bruge denne metode er det muligt at identificere og eliminere afvigelser fra det ønskede resultat på tidligere stadier af softwareproduktudvikling.
• Lean softwareudvikling ( engelsk  lean software development ) bruger tilgange fra begrebet lean manufacturing .

Noter

1. ↑ Hvad er agil softwareudvikling? . Agile Alliance. - "Agil softwareudvikling er en paraplybetegnelse for et sæt rammer og praksis baseret på de værdier og principper, der er udtrykt i Manifestet for Agile Softwareudvikling og de 12 principper bag det." Hentet 29. juni 2019. Arkiveret fra originalen 31. juli 2018. (ubestemt)
2. ↑ Martin, James. Hurtig applikationsudvikling . - Macmillan, 1991. - ISBN 978-0-02-376775-3 .
3. ↑ Kerr, James M.; Jæger, Richard. Inside RAD: Sådan bygger du et fuldt funktionelt system på 90 dage eller mindre . - McGraw-Hil, 1993. - ISBN 978-0-07-034223-1 .
4. ↑ Agile Manifesto Arkiveret 23. februar 2011 på Wayback Machine 
5. ↑ De grundlæggende principper for det agile manifest . agilemanifesto.org. Dato for adgang: 8. december 2016. Arkiveret fra originalen 25. december 2014. (ubestemt)
6. ↑ Agile modellering . Behandlingsdato: 25. december 2011. Arkiveret fra originalen 31. december 2008. (ubestemt)

Litteratur

• Mike Cohn. Scrum: Agile Software Development = Succesed with Agile: Software Development Using Scrum (Addison-Wesley Signature Series). - M. : "Williams" , 2011. - S. 576. - ISBN 978-5-8459-1731-7 .
• Robert S. Martin, James W. Newkirk, Robert S. Koss. Hurtig softwareudvikling. Principper, eksempler, praksis = Agile softwareudvikling. principper, mønstre og praksisser. - Williams, 2004. - 752 s. — ISBN 0-13-597444-5 .
• James A. Highsmith. Agile softwareudviklingsøkosystemer . - Addison-Wesley Professional, 2002. - ISBN 978-0-201-76043-9 .