Agil utvecklingsmetodik

Agile utvecklingsmetodik ( engelska  agil mjukvaruutveckling , agil utveckling ) är en allmän term för ett antal tillvägagångssätt och metoder baserade på värderingarna i Agile Software Development Manifesto och de 12 principer som ligger till grund för det [1] .

Agila metoder inkluderar i synnerhet extrem programmering , DSDM , Scrum , FDD , BDD och andra.

De flesta agila metoder syftar till att minimera risken genom att reducera utvecklingen till en serie korta cykler, kallade iterationer, som vanligtvis varar två till tre veckor. Varje iteration i sig ser ut som ett miniatyrprogramvaruprojekt och inkluderar alla uppgifter som krävs för att producera en minitillväxt i funktionalitet: planering, kravanalys , design , programmering , testning och dokumentation . Även om en enstaka iteration i allmänhet inte räcker för att släppa en ny version av en produkt, antas det att ett agilt mjukvaruprojekt är redo för release i slutet av varje iteration. I slutet av varje iteration omvärderar teamet utvecklingsprioriteringar.

Agila metoder betonar kommunikation ansikte mot ansikte. De flesta agila team finns på samma kontor, ibland kallade eng.  bullpen . Åtminstone inkluderar det också "kunder" ( engelsk  produktägare  - kunden eller dennes auktoriserade representant som bestämmer kraven för produkten; denna roll kan utföras av en projektledare, affärsanalytiker eller kund). På kontoret kan även inkludera testare, gränssnittsdesigners, tekniska skribenter och chefer.

Huvudmåttet för agila metoder är arbetsprodukten. Genom att prioritera kommunikation ansikte mot ansikte minskar agila metoder mängden skriftlig dokumentation jämfört med andra metoder. Detta har lett till kritik av dessa metoder som odisciplinerade.

Historik

Under 1990-talet utvecklades ett antal lätta mjukvaruutvecklingsmetoder som svar på de rådande tunga metoderna, som kritiker kallade överreglerade, planerade och mikrostyrda. Dessa inkluderar: Rapid Application Development (RAD) sedan 1991 [2] [3] ; enhetlig process och metod för att utveckla dynamiska system sedan 1994; Scrum, sedan 1995; Crystal Clear och Extreme Programming (XP), båda sedan 1996; och funktionsorienterad utveckling sedan 1997. Även om de alla har sitt ursprung före publiceringen av Agile Manifesto, kallas de nu gemensamt för agil mjukvaruutveckling.

I februari 2001 släpptes " Agil Software Development Manifesto " i Utah, USA . Det gav ett alternativ till dokumentdrivna "tungviktiga" programvaruutvecklingsmetoder som " vattenfallsmetoden ", som var den gyllene standarden för utveckling vid den tiden. Detta manifest godkändes och undertecknades av representanter för följande metoder: Extreme Programmering , Crystal Clear , DSDM , Funktionsdriven utveckling , Scrum , Adaptiv mjukvaruutveckling , Pragmatisk programmering . Agile utvecklingsmetodik användes av många företag redan innan manifestet antogs, men inträdet av Agile utveckling i massorna inträffade precis efter denna händelse.

Principer

Agile är en familj av utvecklingsprocesser, inte ett enda tillvägagångssätt inom mjukvaruutveckling, och definieras av Agile Manifesto [4] . Agile inkluderar inte praxis, utan definierar de värderingar och principer som vägleder team.

Agile Manifesto utvecklades och antogs 11-13 februari 2001 på The Lodge at Snowbird skidort i Utah-bergen. Agile Manifesto innehåller 4 huvudidéer och 12 principer. Det är anmärkningsvärt att Agile Manifesto inte innehåller praktiska råd.

Nyckelidéer:

• människor och interaktion är viktigare än processer och verktyg;
• en fungerande produkt är viktigare än heltäckande dokumentation;
• samarbete med kunden är viktigare än att komma överens om villkoren i kontraktet;
• förändringsberedskap är viktigare än att följa den ursprungliga planen.

Grundläggande principer för Agile Manifesto [6] :

• kundnöjdhet genom tidig och oavbruten leverans av värdefull programvara erkänns som högsta prioritet;
• ändrade krav är välkomna även i slutet av utvecklingen (detta kan öka konkurrenskraften för den resulterande produkten);
• frekvent leverans av fungerande mjukvara (varannan vecka eller varannan månad med en preferens för en kortare period);
• kommunikation mellan företagsrepresentanter och utvecklare bör vara dagligen under hela projektet;
• projekt bör byggas kring intresserade människor som bör ges rätt arbetsvillkor, stöd och förtroende;
• den mest effektiva metoden för att dela information i ett team är ett personligt möte;
• fungerande mjukvara är det bästa måttet på framsteg;
• sponsorer, utvecklare och användare måste kunna hålla ett konstant tempo i all oändlighet;
• konstant uppmärksamhet på teknisk excellens och bra design ökar flexibiliteten;
• enkelhet, liksom konsten att inte göra onödigt arbete, är mycket viktigt;
• de bästa kraven, arkitekturen och designlösningarna kommer från självorganiserande team;
• teamet funderar regelbundet på sätt att förbättra sin effektivitet och anpassar arbetsflödet därefter.

Kritik

En av de återkommande kritikpunkterna: det agila tillvägagångssättet försummar ofta skapandet av en plan ("roadmap") för produktutveckling, såväl som kravhantering , i den process som en sådan "karta" bildas av. Ett flexibelt förhållningssätt till kravhantering innebär inte långtgående planer (i själva verket existerar kravhantering helt enkelt inte i denna metodik), utan innebär kundens förmåga att plötsligt och oväntat ställa nya krav i slutet av varje iteration, ofta motsäger arkitekturen hos en redan skapad och levererad produkt. Detta leder ibland till katastrofala "hands on work" med massiv refaktorering och omarbetning vid nästan varje nästa iteration.

Dessutom tror man att arbete i agilt motiverar utvecklare att lösa alla inkommande uppgifter på det enklaste och snabbaste möjliga sättet, samtidigt som de ofta inte uppmärksammar kodens korrekthet när det gäller kraven på den underliggande plattformen (den "fungerar och allt”) utan att ta hänsyn till att koden kan sluta fungera om den ändras ytterligare. Detta resulterar i minskad produktkvalitet och en ansamling av defekter (se " tekniska skulder ").

Metoder

Det finns metoder som följer de värderingar och principer som anges i Agile Manifesto, några av dem är:

• Agile Modeling  är en uppsättning koncept, principer och tekniker (praxis) som gör att du snabbt och enkelt kan utföra modellering och dokumentation i mjukvaruutvecklingsprojekt. Innehåller inte detaljerade designinstruktioner, innehåller inte beskrivningar av hur man bygger UML-diagram. Huvudmål: effektiv modellering och dokumentation; men omfattar inte programmering och testning, omfattar inte projektledning, driftsättning och underhåll av systemet. Det inkluderar dock kontroll av modellen med kod [7] .
• The Agile Unified Process (AUP) är en förenklad version av IBM Rational Unified Process ( RUP ) utvecklad av Scott Ambler som beskriver en enkel och begriplig approximation (modell) för att bygga programvara för affärsapplikationer.
• Agile Data Method  är en grupp iterativa mjukvaruutvecklingsmetoder där krav och lösningar uppnås genom samarbete mellan olika tvärfunktionella team.
• DSDM bygger på konceptet Rapid Application Development (RAD). Det är ett iterativt och inkrementellt tillvägagångssätt som betonar fortsatt användar-/konsumentsengagemang i processen.
• Essential Unified Process (EssUP).
• Extrem programmering ( Extreme programmering , XP) . 
• Funktionsdriven utveckling (FDD) - funktionsorienterad utveckling. Konceptet med en  systemfunktion eller egenskap som används i FDD är ganska nära konceptet med ett användningsfall som används i RUP, den betydande skillnaden är en ytterligare begränsning: "varje funktion måste tillåta implementering inom högst två veckor." Det vill säga, om ett användningsfall är tillräckligt litet kan det betraktas som en funktion. Om den är stor måste den delas upp i flera relativt oberoende funktioner.
• Getting Real  är en iterativ, icke-funktionell specifikationsmetod som används för webbapplikationer. I denna metod utvecklas först programmets gränssnitt och sedan dess funktionella del.
• OpenUP  är en iterativ-inkrementell mjukvaruutvecklingsmetod. Den är placerad som en lätt och flexibel version av RUP . OpenUP delar in projektets livscykel i fyra faser: start, förfining, konstruktion och överlämning. Projektets livscykel ger intressenter och gruppmedlemmar referenspunkter och beslutsfattande under hela projektet. Detta gör att du effektivt kan kontrollera situationen och fatta snabba beslut om acceptansen av resultaten. Projektplanen definierar livscykeln och slutresultatet är den slutliga ansökan.
• Scrum upprättar regler för att hantera utvecklingsprocessen och låter dig använda befintliga kodningsmetoder genom att justera krav eller göra taktiska förändringar. Att använda denna metod gör det möjligt att identifiera och eliminera avvikelser från det önskade resultatet i tidigare skeden av mjukvaruproduktutvecklingen.
• Lean mjukvaruutveckling ( engelska  lean software development ) använder tillvägagångssätt från konceptet lean manufacturing .

Anteckningar

1. ↑ Vad är agil mjukvaruutveckling? . Agile Alliance. - "Agil mjukvaruutveckling är ett paraplybegrepp för en uppsättning ramverk och praxis baserade på de värderingar och principer som uttrycks i Manifestet för agil mjukvaruutveckling och de 12 principerna bakom det." Hämtad 29 juni 2019. Arkiverad från originalet 31 juli 2018. (obestämd)
2. ↑ Martin, James. Snabb applikationsutveckling . - Macmillan, 1991. - ISBN 978-0-02-376775-3 .
3. ↑ Kerr, James M.; Hunter, Richard. Inside RAD: Hur man bygger ett fullt fungerande system på 90 dagar eller mindre . - McGraw-Hil, 1993. - ISBN 978-0-07-034223-1 .
4. ↑ Agile Manifesto Arkiverad 23 februari 2011 på Wayback Machine 
5. ^ De grundläggande principerna för det agila manifestet . agilemanifesto.org. Datum för åtkomst: 8 december 2016. Arkiverad från originalet 25 december 2014. (obestämd)
6. ↑ Agile modellering . Behandlingsdatum: 25 december 2011. Arkiverad från originalet 31 december 2008. (obestämd)

Litteratur

• Mike Cohn. Scrum: Agile Mjukvaruutveckling = Att lyckas med Agile: Mjukvaruutveckling med 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. Snabb mjukvaruutveckling. Principer, exempel, praktik = Agil mjukvaruutveckling. principer, mönster och praxis. - Williams, 2004. - 752 sid. — ISBN 0-13-597444-5 .
• James A. Highsmith. Agila ekosystem för mjukvaruutveckling . - Addison-Wesley Professional, 2002. - ISBN 978-0-201-76043-9 .