Flexibilná metodika vývoja (z angličtiny - Agile software development)- manifest, ktorý definuje spôsob myslenia a obsahuje základné hodnoty a princípy, na ktorých sú založené viaceré prístupy (rámce, z angličtiny). rámec- framework, štruktúra) k vývoju softvéru (hoci v poslednej dobe existuje tendencia a pokusy aplikovať flexibilnú metodiku vývoja aj v iných oblastiach činnosti, nielen v informačných technológiách), čo znamená interaktívny vývoj, periodické (dynamické) poskytovanie (aktualizovanie) požiadaviek od Zákazníka a ich implementácia prostredníctvom samoorganizujúcich sa pracovných skupín vytvorených z odborníkov rôznych profilov (vývojári, testeri, implementátori a pod.). Tento preklad Agile ako „flexibilná metodika vývoja“ nie je úplne správny, pretože... Agile sa zvyčajne nenazýva metodológia, ale prístupy založené na tomto manifeste sú metodiky, no z pohľadu agilnosti sa nazývajú frameworky. V súčasnosti existuje veľa rámcov (metodológií), ktorých prístupy sú založené na flexibilnej metodike vývoja, napríklad: Scrum, Extreme programming, FDD, DSDM atď.
Definícia z pohľadu BPM CBoK [z angl. - Sprievodca spoločným súborom vedomostí pre riadenie podnikových procesov]. Agilný- Jedna z iteratívnych metodológií vývoja softvéru krok za krokom, na rozdiel od tradičnej lineárnej „vodopádovej“ metodológie. Agilná metodika vývoja definuje systém návrhových, vývojových a testovacích metód počas celého životného cyklu softvéru. Agilné metódy vývoja (napríklad SCRUM) sú založené na rýchlej reakcii na zmeny pomocou adaptívneho plánovania, kolaboratívneho vývoja požiadaviek, zefektívnenia samoorganizujúcich sa medzifunkčných vývojových tímov a postupného vývoja softvéru s jasným časový rámec. Tento prístup sa používa v mnohých moderných komerčných projektoch vývoja softvéru.
Základom flexibilnej metodiky vývoja je liberálno demokratický prístup k riadeniu a organizácii práce tímov, ktorých členovia sú zameraní na vývoj špecifického softvéru.
Vzhľadom na to, že vývoj softvéru pomocou flexibilnej metodológie definuje sériu krátkych cyklov (iterácií) v trvaní 2-3 týždňov, riziká sú minimalizované, pretože Na konci každej iterácie Zákazník akceptuje výsledky a vydá nové alebo opravné požiadavky, t.j. riadi vývoj a môže ho bezprostredne ovplyvňovať. Každá iterácia zahŕňa fázy plánovania, analýzy požiadaviek, návrhu, vývoja, testovania a dokumentácie. Jedna iterácia zvyčajne nestačí na vydanie plnohodnotného softvérového produktu, ale na konci každej fázy vývoja by sa mal objaviť „hmatateľný“ produkt alebo časť funkčnosti, ktorú je možné prezerať, testovať a prijímať dodatočné alebo opravné opatrenia. . Na základe vykonanej práce tím po každej etape zosumarizuje výsledky a zozbiera nové požiadavky, na základe ktorých urobí úpravy plánu vývoja softvéru.
Jednou z hlavných myšlienok Agile je interakcia tvárou v tvár v rámci tímu a so zákazníkom, čo umožňuje rýchle rozhodnutia a minimalizuje riziká vývoja softvéru, takže tím je umiestnený na jednom mieste, z geografického hľadiska. z pohľadu. V tíme je navyše aj zástupca zákazníka (eng. product owner - splnomocnený zástupca zákazníka alebo samotný zákazník, ktorý prezentuje požiadavky na produkt; túto rolu plní projektový manažér zákazníka alebo obchodný analytik).
História agilného manifestu
Manifest Agile Software Development Manifest bol vydaný a prijatý vo februári 2001 (UTA, The Lodge at Snowbird) skupinou odborníkov. Tento manifest definuje 4 základné hodnoty a 12 princípov pre metodiky, ktoré sú na ňom založené, a tiež poskytuje alternatívnu víziu prístupu k vývoju softvéru na rozdiel od veľkých a známych metód a metodík, ale sám o sebe nie je metodikou. Agile sa zvyčajne porovnáva predovšetkým s „vodopádovou metódou“, pretože V čase vydania manifestu to bola „vodopádová metóda“, ktorá bola hlavnou pri plánovaní vývoja softvéru. Na vývoji a vydaní Agile Manifesto sa podieľali zástupcovia nasledujúcich metodík:
- Adaptívny vývoj softvéru (ASD)
- Krištáľovo čistý
- Dynamická metóda vývoja systémov (DSDM)
- extrémne programovanie (XP)
- Vývoj riadený funkciami (FDD)
- Pragmatické programovanie
- Scrum
V skutočnosti tieto agilné vývojové metodológie existovali ešte pred vydaním manifestu. Samotné vydanie manifestu dalo nový impulz vývoju flexibilných metodík, položilo základy, možno povedať konštituovanie flexibilného prístupu k vývoju softvéru.
Manifest agilného vývoja softvéru:
Hlavnou metrikou agilných metód je pracovný produkt. Uprednostňovaním priamej komunikácie agilné metódy znižujú množstvo písomnej dokumentácie v porovnaní s inými metódami.
To viedlo ku kritike týchto metód ako nedisciplinovaných.
Neustále objavujeme lepšie techniky vývoja softvéru tým, že to robíme sami a pomáhame ostatným robiť to isté. Vďaka odvedenej práci sme si mohli uvedomiť, že:
- Ľudia a interakcie sú dôležitejšie ako procesy a nástroje
- Funkčný produkt je dôležitejší ako komplexná dokumentácia
- Spolupráca so zákazníkom je dôležitejšia ako dohodnutie podmienok zmluvy
- Ochota zmeniť sa je dôležitejšia ako držať sa pôvodného plánu
To znamená, že bez popierania dôležitosti toho, čo je vpravo, si stále viac vážime to, čo je vľavo.
Autori manifestu:
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland Dave Thomas
Základné princípy Agile Manifesto:
Dodržiavame tieto zásady:
- Našou najvyššou prioritou je spokojnosť zákazníka prostredníctvom pravidelnej a včasnej dodávky hodnotného softvéru.
- Zmeny požiadaviek sú vítané, dokonca aj neskoro vo vývoji. Agilné procesy umožňujú využiť zmeny na poskytnutie konkurenčnej výhody zákazníkovi.
- Pracovný produkt by sa mal vydávať tak často, ako je to možné, v rozmedzí od niekoľkých týždňov do niekoľkých mesiacov.
- Vývojári a obchodní zástupcovia musia počas projektu denne spolupracovať.
- Na projekte by mali pracovať motivovaní odborníci. Aby ste svoju prácu zvládli, vytvorte podmienky, poskytnite im podporu a úplne im dôverujte.
- Priama komunikácia je najpraktickejší a najefektívnejší spôsob výmeny informácií ako so samotným tímom, tak aj v rámci tímu.
- Pracovný produkt je hlavným ukazovateľom pokroku.
- Investori, vývojári a používatelia by mali byť schopní udržiavať konštantný rytmus na neurčito. Agile pomáha vytvoriť takýto proces trvalo udržateľného rozvoja.
- Neustála pozornosť venovaná technickej dokonalosti a kvalite dizajnu zvyšuje flexibilitu projektu.
- Jednoduchosť – umenie minimalizovať zbytočnú prácu – je nevyhnutná.
- Najlepšie požiadavky, architektonické a technické riešenia pochádzajú od samoorganizujúcich sa tímov.
- Tím musí systematicky analyzovať možné spôsoby zvýšenia efektivity a prispôsobiť tomu svoj pracovný štýl.
Kritika Agile
Agile nepopisuje procesy riadenia požiadaviek dobre, môžeme povedať, že takýto koncept jednoducho neexistuje, pretože Agilná metodika vývoja nezahŕňa dlhodobé plánovanie (plánovanie sa vykonáva krátkodobo), v dôsledku čoho sa vynechá krok vytvorenia plánu vývoja produktu alebo inými slovami, plán produktu. Pretože plánovanie je krátkodobé (pre ďalšiu iteráciu vývoja) a zákazník na konci každej iterácie produkt akceptuje a stanovuje nové požiadavky, samotný produkt sa môže meniť vo svojich koreňoch a nové stanovené požiadavky často odporujú štruktúru a architektúru produktu už dodávaného zákazníkom. Vo všeobecnosti, ak zákazník úplne nerozumie tomu, čo chce na konci vidieť (konečný produkt), a pochopenie príde počas vývoja (to sa stáva v 90% prípadov), proces vývoja sa zmení na formalizovanú a legalizovanú byrokraciu. , t.j. produkt sa donekonečna zušľachťuje, kým sa neminú peniaze alebo kým zákazník neprejde na iný produkt. Spravodlivo treba poznamenať, že zákazník vie, do čoho ide, a sám sa rozhodne, či zaplatí za vývoj produktu alebo nie, vývojový tím jednoducho spĺňa požiadavky zákazníka. V skutočnosti to však v práci vedie k chaosu, zmeškaným termínom a náhlym prácam, čo vedie k novým požiadavkám, ktoré menia produkt k horšiemu. Navyše kvalita vyvinutého produktu klesá, pretože Agile definuje prístup k vývoju, ktorý sa zameriava na rýchle hasenie požiarov, čo najjednoduchším a najrýchlejším spôsobom. Kód je napísaný bez toho, aby spĺňal požiadavky platformy, na ktorej je produkt vyvinutý, objavuje sa veľa riešení a defektov, pričom takýto návrh nie je príliš stabilný ani bezpečný a rozhorčenie zákazníkov z častých porúch v softvéri rastie. Výsledkom je, že podnik utrpí straty a zníži sa kvalita plánovania.
Niektorí odborníci spájajú Agile skôr s prístupom vylepšovania existujúceho produktu ako s vývojom nového. Existuje veľa zástancov flexibilnej metodiky rozvoja, ale aj odporcov. Ten druhý dokonca svojho času vydal Anti Agile Manifesto. Nižšie na informačné účely uvádzame obsah dvoch najpopulárnejších manifestov, ktoré sú v rozpore s hlavným agilným manifestom:
Anti-agilný manifest (treba podotknúť, že tento anti-agilný manifest v skutočnosti neprotirečí Agile samotnému, ale skôr jednému z rámcov založených na princípoch Agile – Scrum, keďže manifest používa termíny z tohto konkrétneho rámca):
Prešli sme mnohými konzultantmi a strávili nespočetné množstvo hodín na agilných stretnutiach a stretnutiach. Na základe tejto skúsenosti sme si uvedomili, že Agile je len ústretová služba, pretože:
- eposy sú len projekty
- príbehy používateľov sú jednoduché prípady použitia
- šprinty sú len práca
- stand-upy sú len stretnutia
- iterácie sú len verzie
- nevybavené položky sú len zoznamom úloh
- tímová rýchlosť (velocity) sú len výsledky
- a tieto úlohy sú skutočné, len úlohy
Takže zatiaľ čo výrazy vľavo sú navrhnuté ako inovatívne a meniace hru, sú to jednoducho vágne pojmy výrazov vpravo.
Typy agilných vývojových metodík
Na základe hodnôt a princípov definovaných v Agile Manifeste boli vytvorené nasledujúce flexibilné metodológie rozvoja:
- Agilné modelovanie (AM)- tento prístup v podstate definuje postupy modelovania (vrátane kontroly modelu pomocou kódu) a dokumentáciu v rámci vývoja softvéru. Postupy na navrhovanie a vytváranie diagramov v UML sú popísané v menšom rozsahu. Nie sú ovplyvnené ani oblasti vývoja, testovania, projektového manažmentu, nasadenia a údržby.
- Agilný jednotný proces (AUP)- jednotná verzia metodiky RUP (IBM Rational Unified Process), ktorú vytvoril Scott Ambler. AUP definuje model na vytváranie softvéru v rámci podnikových aplikácií.
- Agilná dátová metóda (ADM)- súbor iteratívnych agilných techník vývoja softvéru, ktoré kladú dôraz na vývoj požiadaviek a riešení prostredníctvom spolupráce rôznych medzifunkčných tímov.
- Dynamická metóda vývoja systémov (DSDM)- iteratívny a inkrementálny prístup založený na koncepte rýchleho vývoja aplikácií (RAD), ktorý sa zameriava na maximálne zapojenie koncového používateľa do vývoja softvérového produktu.
- Základný jednotný proces (EssUP)- prístup vyvinutý Ivarom Jacobsonom obsahuje metódy iteratívneho vývoja softvéru s dôrazom na architektúru produktu a zavedené tímové postupy (v podstate prevzaté z RUP, CMMI a Agile Development). Myšlienkou je, že používate iba tie postupy a metódy, ktoré sú použiteľné v konkrétnej situácii. Na základe zvolených metód a praktík sa určí cieľový proces. Na rozdiel od RUP, kde sú všetky postupy a metódy vzájomne prepojené, v tomto prípade existuje flexibilita a možnosť presne izolovať potrebné prvky (metódy a postupy) z celého dostupného objemu.
- Extrémne programovanie (XP)- myšlienkou extrémneho programovania je využiť existujúce osvedčené postupy v oblasti vývoja softvéru a pozdvihnúť ich na novú (extrémnu) úroveň. Napríklad na rozdiel od bežnej praxe, keď jeden programátor postupne kontroluje napísaný kód svojho kolegu, pri extrémnom programovaní sa táto kontrola vykonáva paralelne, čo zvyšuje rýchlosť uvoľnenia produktu, ale aj riziká.
- Vývoj riadený funkciami (FDD)- hlavným obmedzením, ktoré je uložené v rámci tohto prístupu, je „každá funkcia by mala byť implementovaná najneskôr do dvoch týždňov“. Tie. Ak skutočne dokážete vyvinúť funkciu v jednom sedení, potom je to dobré, inak by sa táto funkcia mala rozdeliť na niekoľko a implementovať postupne.
- Getting Real (GR)- v rámci tohto prístupu sú vylúčené postupy špecifikácie funkcií používané pre webové aplikácie. Vývoj začína opačným smerom, najskôr sa vyvinie rozhranie a dizajn a až potom samotná funkcionalita.
- OpenUP (OUP)- tento prístup definuje iteratívno-inkrementálnu metódu vývoja softvéru. Vyvinuté na základe RUP. V rámci tejto metódy je definovaný životný cyklus vývoja (fáza spustenia, fáza objasňovania, fáza vývoja a prenosu k zákazníkovi). Vďaka určitému rozfázovaniu a kontrolným bodom sa zvyšuje efektivita kontroly a sledovania priebehu projektu a v dôsledku toho aj včasné rozhodovanie o projekte.
- štíhly vývoj softvéru- tento prístup vychádza z koncepcie štíhleho manažmentu výrobného podniku (štíhla výroba, štíhla výroba).
- Scrum- jeden z najbežnejších prístupov k flexibilnému vývoju softvéru, definuje pravidlá riadenia procesu vývoja s využitím existujúcich vývojových praktík. Dôraz je kladený na zapojenie zákazníka do procesu (možnosť zmeniť alebo objasniť požiadavky na vytváraný produkt po každej fáze), čo umožňuje včas identifikovať odchýlky a vykonať potrebné zmeny.
Agilná metodológia je pojem, ktorý v dnešnej dobe nosí každý, no čo sa za tým skrýva? Je to všeliek na riadenie projektov alebo je to náhrada zastaraných metód? Dá sa to uplatniť aj niekde inde ako v IT? Odpovede na tieto otázky sú v tomto článku.
Čo je Agile
Agilný(anglicky: „agile, quick-witted“) - filozofia, súbor flexibilných prístupov k vývoju softvéru, ktorý sa začal používať na riadenie projektov. Agilné prístupy znamenajú, že produkt vzniká ako výsledok iterácií, zákazník vyvíja požiadavky postupne a zmeny požiadaviek sú vítané aj v neskorých štádiách vývoja. Plnenie požiadaviek zákazníkov zabezpečujú pracovné skupiny zložené zo špecialistov v rôznych oblastiach. Kľúčové myšlienky a princípy Agile sú zakotvené v Agile Manifeste.
„Agile“ je súbor všeobecných princípov, ktoré sú spoločné pre množstvo nových metód vývoja a projektového manažmentu, ako je SCRUM, extrémne programovanie, Kanban a množstvo ďalších, na rozdiel od tradičného byrokratického a často nespĺňajúceho prístup k moderným požiadavkám. . Ale okrem toho je to aj marketingový výraz, zastrešujúca značka pre synergiu propagácie agilných metodík.
Chcel by som zdôrazniť, že Agile nie je metodika, ale všeobecné princípy. Napriek tomu, že v manifeste sa uvádza, že Agile je metodika vývoja softvéru, flexibilné metódy možno aplikovať na širšiu škálu úloh a jej princípy sa využívajú všade tam, kde je vysoká neistota konečného výsledku, rozhodujúce je načasovanie a cena vývoja.
Agilné metódy sa považujú za účinné pri organizácii práce malých skupín (ktoré robia homogénnu tvorivú prácu).
Stiahnite si a použite:
11. Najlepšie požiadavky, architektonické a technické riešenia pochádzajú od samoorganizujúcich sa tímov. Toto je názor autorov a signatárov manifestu, preto v rámci všetkých flexibilných metód je vývoj požiadaviek a riešení delegovaný na tímovú úroveň. Dosiahnutie efektívnej sebaorganizácie umožňuje prítomnosť spoločného záujmu a dohody o cieľoch a synergiu pri spoločnom dosahovaní týchto cieľov.
12. Analýza a prispôsobovanie sa meniacim sa podmienkam, neustále hľadanie spôsobov, ako zlepšiť efektivitu práce. Ide o rovnakú flexibilitu, ktorá je uvedená v názve prístupu a o ktorú by sa mali snažiť všetci vývojári v rámci konceptu agilnej metodiky.
Agilný SCRUM
SCRUM (čítaj ako „scrum“) je ragbyový termín používaný na pomenovanie najštruktúrovanejšej agilnej vývojovej metodológie, ktorá je v súčasnosti k dispozícii. V športe ide o tímovú a vysokointenzívnu akciu na dosiahnutie výsledku – príjem lopty na následný útok, ktorý trvá krátko. Na túto fázu hry sa pre jej vysokú chorobnosť využívajú tí najlepší a najpripravenejší hráči tímu a ak takýchto hráčov z nejakého dôvodu (napr. z dôvodu odstránenia alebo zranenia) nie je dostatok, prichádza na rad scrum. nevykonané.
V Rusku je metodika čoraz rozšírenejšia. Scrum je založený na takzvaných sprintoch – pevne fixovaných a krátkodobých iteráciách práce, počas ktorých je potrebné vyvinúť a poskytnúť koncovému užívateľovi fungujúci produkt s novými schopnosťami oproti predchádzajúcemu sprintu. Trvanie sprintu je prísne fixné a určuje flexibilitu a predvídateľnosť vývojového procesu, čím kratší je sprint, tým vyššia je flexibilita a predvídateľnosť, ale zvyšujú sa relatívne náklady na každú iteráciu a čas strávený plánovaním a konaním stretnutí s; zákazníka av rámci tímu tiež zvyšuje.
Veľmi dôležitým prvkom tejto flexibilnej metodiky je produktový backlog - zoznam technických a obchodných požiadaviek na finálnu verziu produktu, štruktúrovaný podľa stupňa dôležitosti, z ktorého sa preberajú úlohy pre každý nasledujúci sprint projekt je realizovaný a parametre sú vyjasnené.
Nová funkcionalita produktu, ktorý sa vyvíja pre ďalší sprint, je určená vo fáze plánovania, po ktorej sa vytvorí Sprint Backlog, ktorý sa počas celého trvania nemení.
Metodológia tiež zabezpečuje štruktúru rolí v projekte:
- Scrum-master – sprostredkovateľ medzi zákazníkom a tímom;
- Product Owner – zástupca zákazníka, ktorého úlohou je vytvárať a uprednostňovať Product Backlog a prijímať priebežné výsledky sprintov;
- Tím je projektový tím, v ktorom nie sú samostatné roly, ide o samoorganizujúci sa systém medzifunkčne motivovaných odborníkov.
Prečo finančníci potrebujú Agile?
Kľúčové výhody metodiky projektového manažmentu Agilw pre finančníkov:
- možnosť úspory peňazí pri zdĺhavom vypracovávaní projektovej dokumentácie;
- vysoká úroveň kontroly nad rozpočtom (
V modernom manažmente sa „flexibilný“ model riadenia zvažuje v troch rôznych kontextoch, ktoré (každý svojím spôsobom) definujú, čo je Agile.
Tri zväzky významu Agile
V prvom, užšom slova zmysle sa tento termín začal používať v oblasti vývoja softvéru na začiatku 2000-tych rokov, keď sa v americkom štáte Utah v horskom stredisku zišli odborníci z odvetvia, aby diskutovali o metódach a postupoch vytvárania softvérových produktov, ktoré boli žiadané konečným spotrebiteľom. Výsledkom tohto stretnutia bol Agile Manifesto pre vývoj softvérových produktov s 12 princípmi, ktoré sa primárne týkali úzkeho rozsahu aktivít autorov, ale potenciálne by sa dali rozšíriť aj na niektoré ďalšie obchodné projekty.
V druhom, širšom význame tohto pojmu sú agilné princípy aplikované na vedenie takmer akéhokoľvek podnikania a používajú sa ako komponenty napríklad v koncepte „štíhleho startupu“ (Lean Startup). V tomto zmysle sa agilný model chápe ako postup podľa flexibilnej metodiky vývoja projektu, ktorá sa riadi charakteristickou schémou v niekoľkých krokoch.
- Práca na projekte prebieha v iteráciách – krátkych cykloch (šprintoch). (V prípade vývoja softvéru sa dĺžka trvania týchto cyklov pohybuje od 1 týždňa do 1 mesiaca).
- Na konci každého cyklu sa uvoľní produkt, ktorý je už možné použiť v podnikaní. V prípade softvéru môže byť takýmto produktom aplikácia alebo len jej časť, ale aj „surový“ softvér možno a treba vyskúšať v akcii.
- Produkt testuje zákazník alebo používatelia, ktorí majú neustálu spätnú väzbu s vývojármi. Počas celého projektu (všetky iterácie) sa uplatňuje klientsky orientovaný prístup.
- Akékoľvek pripomienky sú rýchlo zahrnuté do revízie a vítame zmeny, ktoré nám umožňujú okamžite opraviť vývoj produktu, pretože nám to umožňuje vyhnúť sa hromadeniu globálnych systémových chýb.
V treťom, ešte širšom zmysle, Agile je súčasťou modelu riadenia používaného v továrňach Toyota a dnes je jedným zo základných komponentov riadenia takmer každej úspešnej výroby. Základy Agile v tomto kontexte sú podobné základom chápania technológie v iných kontextoch.
Rýchlu spätnú väzbu pri nastavovaní finálneho formátu výroby v továrňach Toyota poskytol každý pracovník, ktorý sa mohol stať iniciátorom zastavenia dopravníka a autorom úprav na doladenie výrobného cyklu. V celovýrobnom meradle môže agilná transformácia znamenať prestavbu výrobných činností ako celku, ak sa produkt stane výsledkom živej reakcie na aktuálne potreby zákazníkov. Ak teda továreň vyrábala plastové umývadlá a spätná väzba od klienta preukáže potrebu vedier, potom rýchle prispôsobenie s paralelnou úpravou odtieňov (tvar rukoväte, veľkosť, farba) bude presne v štýle agilného riadenia (ak budú dodržané iné zásady ).
Princípy agilného manažmentu
Agilný projektový manažment ako model riadenia podnikových procesov používajú tisíce tímov po celom svete a všade sú prítomné nasledujúce charakteristické črty tohto prístupu:
- Spotrebiteľ a miera jeho zapojenia do vytvárania výsledku sú rozhodujúce pre prispôsobenie produktu.
- Aby sa tímy mohli rozhodnúť, musia byť vysoko efektívne a súdržné.
- Základom procesu sa stáva postupná a cyklická práca. Projekt je rozdelený na malé časti, ktoré sú ukončené do určitého dátumu pred dokončením projektu ako celku.
- Ťažiskom hodnotenia výkonnosti sú časté prezentácie prechodných stavov projektu.
- Vo svojej práci sa tím opiera o Paretov zákon, podľa ktorého 20% úsilia dáva 80% účinnosti, čo umožňuje nedoviesť každý jednotlivý cyklus k dokonalosti pred predstavením výsledku spotrebiteľovi. Produkt sa prirodzene zlepšuje s každou novou iteráciou.
- Očakáva sa, že pred prechodom na ďalšiu musí byť dokončená jedna etapa.
„Flexibilný“ prístup sa stal základom pre množstvo metodologických postupov, ktoré sa od seba líšia, ale zahŕňajú myšlienky Agile: Scrum, Kanban, Lean, Crystal atď. v spojení s Agile ako jednotný systém riadenia projektov pre vývoj softvéru.
Metóda Scrum demonštruje, ako možno v praxi aplikovať „agilný prístup“ v konkrétnych operáciách. Napríklad práca s požiadavkami projektu sa realizuje pomocou štyroch „artefaktov“:
- Produktový backlog zahŕňa generovanie zoznamu požiadaviek vytvorených pomocou jedinej šablóny (Príbeh používateľa) a zoradených podľa priority. Ak nie sú žiadne požiadavky, projekt končí.
- Backlog sprintu sú požiadavky najbližšieho sprintu (etapy), rozdelené na úlohy bez možnosti pridávať nové požiadavky počas sprintu. Na tabuli (tzv. Kanban) sú napísané predsavzatia do ďalšej etapy, ktoré berie tím s typom Agile management.
- Cieľ sprintu – celkový cieľ sprintu – návod na alternatívne rozhodnutia.
- Sprint Burndown Chart – „diagram vyhorenia“. Ukazuje, ako ďaleko tím počas etapy pokročil.
Formát agilného riadenia projektov nie je vhodný pre každého a nie vždy. Vládne štruktúry, ktorých činnosť je založená na nezmenenej legislatíve a sú konzervatívne vo svojich cieľoch a implementácii, takúto optimalizáciu nepotrebujú.
Typické chyby pri implementácii Agile a nevýhody prístupu
Ten istý faktor, ktorý sa v niektorých prípadoch považuje za silu prístupu, môže v iných viesť k problémom. Preto sa „flexibilita“ často stáva dôvodom rozmazania zaostrenia. Pri absencii metodického základu dochádza k strate smerníc a nahrádzaniu primárneho sekundárnym. Na predchádzanie takýmto „skresleniam“ používajú hotové metodiky alebo vlastný vývoj, ktorý prísnejšie reguluje obsah a postupnosť operácií počas realizácie projektu. V tomto prípade sú však možné chyby v agilnom riadení.
Medzi bežné chyby implementácie patria:
Napriek všetkým ťažkostiam pri implementácii flexibilného prístupu je vo všeobecnosti efektívnejší ako tradičná „pomalá“ výroba, pokiaľ ide o rýchle vytvorenie nového zákaznícky orientovaného produktu. Zatiaľ čo tradičná výroba uviazla v byrokratických prieťahoch, agilný prístup poskytuje prirodzený pohyb ihneď po spustení projektu.
Agile je flexibilný prístup k vývoju vrátane rôznych metodík (Scrum, Kanban, XP, Lean a iné). Veľa ľudí o tom vie. Ale sú tu desiatky drobností a všelijakých zaujímavostí, ktoré neležia na povrchu.
Pripravili sme sériu článkov ako pre začiatočníkov, ktorí ešte stále poznajú flexibilné metodiky, tak aj pre tých, ktorí sa s nimi už dlho kamarátia. Povieme si o základných pojmoch (v skratke) a nečakaných aplikáciách Agile a Scrumu v každodennom živote. Dnešný článok je ako úvodná prednáška: o tom, čo je Agile a s čím prichádza.
Veľký tresk projektov
Ak uvedieme paralelu so zrodom Vesmíru – túto rolu pridelíme Agile – tak Veľký tresk bude problémom číslo jedna, ktorý dohnal viac ako sto projektových manažérov k nervovému zrúteniu – zmene požiadaviek na produkty. To je presne dôvod nárekov, úzkostných výkrikov „Prečo potrebujem tento trest? a rednutie vlasov.
Procesy zvyčajne fungujú v rámci kaskádového modelu (alebo vodopádového modelu) - všetko sa deje v etapách a postupne. Jednoducho povedané: "Vidím cieľ - idem k cieľu." A ak sa v určitom momente zmenia požiadavky na produkt, konečný cieľ, niekedy to musíte prerobiť znova. Len čo dokonale vybrúsený plán narazí na realitu, okamžite sa rozpadne na prach. Ale namiesto toho, aby manažéri zahodili plán aj jeho prístup do koša, predstierajú, že plán funguje, a dokonca si na to najímajú špecialistov. V podstate platia ľuďom, aby im klamali.
Podľa tvorcu Scrumu Jeffa Sutherlanda to pripomína správanie sa politbyra Ústredného výboru CPSU koncom 80. rokov, ktoré údajne verilo správam, ktoré dostávalo v predvečer rozpadu Sovietskeho zväzu.
Agilné metódy sú navrhnuté tak, aby proti tomu bojovali vďaka svojej flexibilite. Môžeme povedať, že Agile je zmesou niekoľkých prístupov, navrhnutých tak, aby minimalizovali najrôznejšie riziká pomocou súboru princípov. Rovnaké princípy a 4 hlavné myšlienky sú zhromaždené v Agile Manifeste z roku 2001.
Agilný manifest
Ak zjednodušíme jazyk, aby sme „vykryštalizovali“ úvahy, ktoré vedú každého, kto pracuje v agile, dostaneme niečo takéto:
- Najdôležitejší sú ľudia, nie veci
- Dokumentácia (ktorú zatiaľ nikto nečíta) by nikomu nemala zasahovať do práce
- Radšej spolupracujte ako si znova prečítajte zmluvu
- Žiť, dýchať, meniť sa – čo najrýchlejšie
Ako fungujú procesy
Pozrime sa, ako môžete pracovať podľa Agile. Vezmime si ako príklad Scrum – dnes je to najpopulárnejšia flexibilná metodika. Jeff Sutherland, autor Scrumu, vynašiel túto techniku, aby prekonal nedostatky klasického projektového manažmentu.
1. Vyberte vlastníka produktu- je to človek, ktorý vidí, k akému cieľu smerujete a čo chcete nakoniec dosiahnuť.
2. Rozhodnite sa pre tím- od 3 do 10 ľudí so zručnosťami, ktoré vám umožnia dosiahnuť výsledky (t. j. funkčný produkt).
3. Vyberte Scrum Master- táto osoba monitoruje priebeh projektu a pomáha tímu riešiť ťažkosti.
4. Vytvorte produktový backlog- zhromaždiť na jednom mieste (najlepšie na agilnej doske) všetky požiadavky na produkt a uprednostniť. Produktový vlastník musí premyslieť a zozbierať všetky želania. Tím potom musí vyhodnotiť nevybavené veci, aby zistil, či sa to všetko dá urobiť a ako dlho to bude trvať.
Takto vyzerá agilná doska v Yandex - .
5. Naplánujte si šprinty- časové úseky (týždeň alebo dva), počas ktorých tím plní určitý súbor úloh. Šprinty budú pravidelné: napríklad 15-krát počas dvoch týždňov, kým sa nedosiahne hotový výrobok.
6. Držte denné stretnutia 15 minút (a ani minútu viac)- na programe sú tri otázky, na ktoré každý stručne odpovedá: čo som robil včera, čo budem robiť dnes a aké prekážky mi bránia „dostať sa do výšin“.
7. Robiť recenzie- na konci sprintu tím povie, čo sa im podarilo a predvedie pracovné časti produktu. Recenzie sa môže zúčastniť ktokoľvek: vlastník produktu, hlavný zákazník alebo dokonca potenciálni klienti.
8. Vykonajte retrospektívu- po každom šprinte agilný tím diskutuje o problémoch a hľadá riešenia. Mal by existovať plán zmeny, ktorý tím okamžite zavedie – pri ďalšom šprinte.
Viac informácií o tom, ako implementovať Scrum a zvýšiť efektivitu tímu, nájdete v tomto článku.
Scrum je viac ako metóda tímovej práce. Scrum zrýchľuje tempo všetkých ľudských snáh. Bez ohľadu na to, o aký projekt alebo problém ide, Scrum možno použiť v akomkoľvek úsilí o zvýšenie produktivity a dosiahnutie lepších výsledkov.
Spoznajte Agile zrakom
Agilné metódy sa dajú ľahko identifikovať podľa kľúčových charakteristík, ako sú „signálne príznaky“.
- Minimalizácia rizika je hlavným cieľom každého agilného prístupu.
- Iteračný vývoj – práca v krátkych cykloch.
- Najdôležitejší sú ľudia a komunikácia.
Ak sa na Agile pozriete z oboch strán rieky – zákazníka aj tímu – tento prístup dáva zmysel pre každého.
- Zákazník potrebuje dostať aspoň minimálne funkčný produkt včas (nezáleží na tom, či sa bavíme o softvéri alebo iných procesoch a javoch), zmeniť podmienky bez toho, aby mu zostala diera na koblihu vo vrecku - to už je otázka rizikového poistenia.
- Tým profituje z komunikácie so zákazníkom a kolegami (takže bez tohto: „Zle ste ma pochopili – všetko rýchlo prerobte. A áno, toto je potrebné včera!“), transparentnosť procesov, ktorá znižuje šance na prekvapenia a rýchle riešenie problémov. No veľa ľudí chápe, kam ide čas a kde sa práca zasekáva. Je to maličkosť (nie naozaj), ale je to milé.
Navyše sa kvalitatívne zlepšuje komunikácia v rámci tímu. Všetci sa sústreďujú na spoločnú myšlienku, nie sú medzi sebou žiadne tajomstvá, každý skladá sľub (spoločenské povinnosti – kde bez nich). Čerešničkou na torte je možnosť pracovať pohodlným tempom, aj keď rýchlym (aspoň rýchlejším ako zvyčajne).
Agile prináša poriadok z chaosu. Uskutočnil sa výskum: ukázalo sa, že projekty, kde sa pracovalo v rámci flexibilného prístupu, boli 3-krát úspešnejšie ako tie, kde boli procesy postavené v štandardnej paradigme. A zdá sa to celkom logické: zákazník dostane to, čo chce, a to s minimálnym vynaložením času a zdrojov.
Komu by sa to nepáčilo?
Od svojho vzniku tvorí koncept Scrum základ pre návrh nových softvérových produktov pre technologické odvetvia. Avšak po získaní uznania a úspechu v Silicon Valley medzi projektovými manažérmi pre tvorbu softvéru a nového hardvéru zostáva Scrum vo všeobecnej obchodnej praxi málo známou metodikou.
To je na dnes všetko. Nabudúce si povieme niečo o Scrum of Scrums a o tom, ako fungujú flexibilné metodológie v ruskej realite. Neprepínajte.
P.S.Chcete každý týždeň dostávať užitočné tipy z najzaujímavejších kníh o obchode a marketingu, dozvedieť sa o nových produktoch a získať zľavy? Prihlásiť sa ku odberu noviniek. Prvé písmeno obsahuje darček.
- Preklad
„Akékoľvek podnikanie vždy trvá dlhšie, ako sa očakáva, aj keď berieme do úvahy Hofstadterov zákon.“
- Hofstadterov zákon
Najsledovanejšie video na YouTube na tému agile. 744 625 zobrazení v čase uverejnenia tohto článku. Jednoduchý štýl prezentácie, obrázky a iba 15 minút – to najlepšie, čo som videl. TED si dáva prestávku.
Roly
Toto je Pat vlastník produktu. Nepozná technické detaily, ale má víziu veľkého obrazu, vie Prečo vyrábame produkt, aké problémy vyrieši a pre koho.
Toto záujemcov. Budú používať produkt, podporovať ho alebo sa inak podieľať na vývoji.
Toto príbehy používateľov. Vyjadrujú želania záujemcov. Napríklad „v rezervačnom systéme leteckej spoločnosti by mal mať používateľ možnosť vyhľadávať podľa letu.“
Zainteresované strany majú veľa nápadov a Pat pomáha premieňať nápady na príbehy používateľov.
Toto vývojový tím. Tí, ktorí budú stavať pracovný systém.
Šírka pásma
Keďže príkaz používa flexibilná metodika rozvoja, všetky tieto príbehy až do veľkého vydania nehromadia, práve naopak, vydávajú ich okamžite a čo najčastejšie. Zvyčajne vydávajú 4 až 6 používateľských príbehov týždenne. Je to ich priepustnosť. Meranie je veľmi jednoduché - počet užívateľských príbehov za 7 dní.
Aby sa tento rytmus udržal a neuviazli v manuálnom regresnom testovaní, tím na tom tvrdo pracuje automatické testovanie a nepretržitá integrácia. Preto musíte písať autotesty pre každú funkciu a väčšina kódu má vstavané autotesty.
Problém je, že záujemcov je veľa a ich požiadavky sa nedajú uspokojiť 4-6 príbehmi za týždeň.
Zakaždým, keď implementujeme príbeh používateľa, prídu s niekoľkými ďalšími nápadmi, ktoré vedú k ešte väčšiemu počtu požiadaviek.
Čo sa stane, ak urobíme všetko, o čo nás žiadajú? Budeme preťažení.
Povedzme, že tím sa tento týždeň zaviaže vytvoriť 10 nových príbehov. Ak je vstup 10 a výstup 4-6, tím bude preťažený. Bude sa ponáhľať, prepínať medzi úlohami, stráca motiváciu a v dôsledku toho klesá produktivita a kvalita. Toto je zjavne stratová stratégia.
Scrum a XP v tomto prípade používajú metódu „včerajšieho počasia“. Tím hovorí: "V poslednom čase robíme 4-6 funkcií týždenne, akých 4-6 funkcií budeme robiť budúci týždeň?"
Úlohou produktového vlastníka je múdro vybrať, ktoré príbehy používateľov budú implementované tento týždeň.
Kanban odporúča obmedziť sa na niekoľko úloh – WIP limit. Povedzme, že tím sa rozhodne, že 5 je prijateľný počet používateľských príbehov, na ktorých môžu pracovať súčasne bez preťaženia, bez preskakovania z jedného na druhý.
Oba tieto prístupy fungujú dobre a obidva vytvárajú frontu úloh, ktorá sa v Scrume nazýva Backlog alebo prioritný zoznam úloh.
Tento rad je tiež potrebné spravovať, ak zainteresované strany požadujú 10 príbehov za týždeň a tím implementuje 4 až 6 príbehov, tento rad sa bude zväčšovať a zväčšovať. A čoskoro bude váš Backlog naplánovaný na šesť mesiacov vopred. To znamená, že jeden príbeh bude čakať na vydanie 6 mesiacov.
Existuje len jeden spôsob, ako udržať zoznam úloh pod kontrolou – slovo „nie“
Toto je najdôležitejšie slovo pre produktového vlastníka. Musí to cvičiť každý deň pred zrkadlom.
Povedať „áno“ je jednoduché. Ale dôležitejšia úloha je rozhodnúť, čo nerobiť a niesť za to zodpovednosť. Produktový vlastník tiež určuje postupnosť toho, čo robíme teraz a čo neskôr. Ide o komplexnú prácu a mala by sa vykonávať spoločne s vývojovým tímom a aspoň jednou zainteresovanou stranou.
Aby bolo možné správne určiť priority, produktový vlastník musí pochopiť hodnotu každého príbehu a jeho rozsah.
Robiť rozhodnutia
Niektoré príbehy sú absolútne nevyhnutné a niektoré sú len bonusové funkcie. Vývoj niektorých príbehov zaberie pár hodín, iných niekoľko mesiacov.Aký je vzťah medzi veľkosťou príbehu a hodnotou? V žiadnom prípade. Viac neznamená lepšie. Hodnota a zložitosť úlohy je to, čo pomáha Patovi určiť priority.
Ako produktový vlastník určuje hodnotu a rozsah príbehu? V žiadnom prípade. Je to hádanie. A je lepšie, aby sa ho zúčastnili všetci. Pat neustále komunikuje so zainteresovanými stranami, aby poznal hodnotu každého príbehu, komunikuje s vývojovým tímom, aby poznal rozsah práce, ale všetko sú to len hrubé odhady, žiadne presné čísla. Na začiatku vždy budú chyby a to je normálne. Komunikácia je oveľa cennejšia ako ultra presné čísla.
Zakaždým, keď vývojári vydajú niečo nové, dozvieme sa viac informácií a môžeme sa lepšie orientovať.
Samotné stanovenie priorít nestačí. Ak chcete príbehy zverejňovať rýchlo a často, musíte ich rozdeliť na kúsky, ktoré sa dajú urobiť za pár dní. Chceme malé a jasné príbehy na začiatku lievika a veľké a nejasné na konci. Tým, že toto rozdelenie urobíme v čase, môžeme využiť naše najnovšie objavy o produkte a potrebách používateľov. Toto všetko sa nazýva čistenie Backlogu.
Pat organizuje upratovanie Backlogu každú stredu od 11:00 do 12:00. Zvyčajne sa na ňom stretne celý tím a niekedy aj niekoľko zainteresovaných strán. Obsah stretnutí je rôzny. Zamerajte sa na hodnotenie, na členenie príbehu, na kritériá prijatia.
Majiteľ IT produktu musí neustále komunikovať s každým
Skúsení vlastníci produktov identifikujú dve zložky úspechu: vášeň pre prácu a komunikáciu. Aké problémy rieši produktový vlastník spolu s tímom?Vyváženie komplexnosti vývoja a hodnoty používateľského príbehu
V počiatočnom štádiu je súvaha ohrozená neistotou a niekoľkými rizikami naraz.
Riziká
Podnikateľské riziko: "Robíme správnu vec?"Sociálne riziko: "Môžeme urobiť to, čo musíme?"
Technické riziko: "Bude projekt fungovať na tejto platforme?"
Riziká spojené s nákladmi a časom realizácie: „Zvládneme to včas a bude dostatok peňazí?“
Vedomosti možno považovať za opak rizika. Keď je neistota vysoká, zameriavame sa na získavanie vedomostí – prototypy rozhraní, technické experimenty,
Kompromis medzi hodnotami vedomostí a hodnotami zákazníka
Z pohľadu zákazníka vyzerá krivka takto:
Z pohľadu hodnoty zákazníka vyzerá krivka takto. Keď sa znížia neistoty, môžeme sa zamerať na hodnotu pre zákazníka. Vieme, čo a ako máme robiť. Ostáva už len to urobiť. Po implementácii hlavných príbehov vytvoríme bonusové funkcie alebo spustíme nový projekt.
Kompromis medzi krátkodobým a dlhodobým myslením
Čo implementovať ako prvé? Naliehavo opravte chyby alebo začnite vyvíjať úžasnú funkciu, ktorá používateľov ohromí. Alebo urobte komplexný upgrade platformy, ktorý urýchli prácu v budúcnosti. Neustále je potrebné nájsť rovnováhu medzi reaktívnou a proaktívnou prácou.
Robiť správne veci, robiť veci správnym spôsobom alebo robiť veci rýchlo?
Ideálne všetky tri naraz, no v skutočnosti si musíte vybrať.
Povedzme, že sme tu. Snažíme sa vytvoriť dokonalý produkt pomocou dokonalej architektúry. Ak trávime veľa času, môžeme premeškať marketingové okno a skončiť s problémami s peniazmi.
Vyrobíme rýchly prototyp produktu. Z krátkodobého hľadiska to nie je zlé. Z dlhodobého hľadiska dostávame technické riziko. A rýchlosť vývoja klesne na nulu.
Sme tu a vytvárame nádherný chrám v rekordnom čase. Ale používateľ nepotreboval chrám, potreboval obytný automobil.
Medzi rolami v Scrume je zdravé napätie
Product Owner sa zameriava na budovanie správnych vecí. Tím sa sústreďuje na správne budovanie vecí. Scrum Master alebo Agile Coach sa zameriava na skrátenie spätnej väzby.
Tiež stojí za to zdôrazniť dôležitosť rýchlosti, pretože krátka spätná väzba urýchľuje učenie. To nám umožňuje rýchlo sa naučiť, ktoré veci sú správne a ako ich správne zostaviť.
Kompromis medzi vývojom nového produktu a vylepšením starého
Produkt nemôže byť nikdy úplne dokončený, pretože neustále potrebuje zmeny. Keď tím začne pracovať na novom produkte, čo sa stane so starým? Prenos produktu z jedného tímu do druhého je veľmi nákladný a riskantný. Tím zvyčajne udržiava starý produkt pri vývoji nového. Preto sa pojem „Backlog“ netýka produktu, ale tímu. Nevybavená položka je zoznam vecí, ktoré chce produktový vlastník od tímu. A súbor príbehov pre rôzne produkty. Produktový vlastník musí neustále vyberať relevantné pre implementáciu.
Plán zničenia príbehu
Z času na čas sa zainteresované strany spýtajú Pata: „Kedy bude moja funkcia uvoľnená?“ alebo "Koľko funkcií bude vydaných do Vianoc?" Produktový vlastník musí byť schopný riadiť očakávania používateľov. A realisticky riadiť očakávania.
Dva trendy – optimistický a pesimistický (vidíte ich od oka). Vzdialenosť medzi trendmi ukazuje, aká nestabilná je rýchlosť tímu. Postupom času sa tieto trendy stabilizujú a kužeľ neistoty sa zníži.
Povedzme, že záujemca sa opýta, kedy bude táto funkcia hotová?
Ide o otázku s pevným obsahom a neurčitou dobou. Pat používa na odpoveď dve trendové čiary. Odpoveď je v apríli alebo máji.
Záujemca sa pýta Pata: „Koľko sa toho urobí do Vianoc? Ide o otázku s pevným termínom a neurčitým obsahom. Trendové čiary odrežú vo vertikálnom meradle pravdepodobný segment toho, čo stihnú implementovať.
Zainteresovaná strana sa pýta: „Budeme mať čas urobiť tieto funkcie do Vianoc?“ Toto je otázka s pevným časovým rámcom a pevným obsahom. Pat so zameraním na trendy odpovedá: "Nie." Dodáva: „Do Vianoc toho stihneme toľko urobiť, ale toľko nám bude trvať, kým celú túto prácu dokončíme úplne.“
Zvyčajne je lepšie zredukovať obsah projektu ako predĺžiť čas. Ak znížime obsah, budeme mať možnosť posunúť termín. Niektoré môžeme pustiť tu a zvyšok neskôr.
Vlastník produktu robí výpočty na týždennej báze a namiesto zbožných prianí používa iba empirické údaje. Úprimne hovorí o neistote. Tím si udržiava pracovné tempo a Pat ich nenúti zrýchľovať.
Načítava...
