Pojem agilní vývoj existuje od roku 2001, kdy vznikl takzvaný agilní manifest. Ten se pokusil shrnout metody, které jeho signatáři již v té době používali do jednoho konzistentního celku. Zároveň se nepřímo vymezili proti vodopádovému (sekvenčnímu) modelu vývoje, který funguje asi takto.
Vodopádový model
Vodopádový model rozděluje projekt do fází, které následují jedna po druhé. Často se zobrazuje v diagramu, který připomíná vodopád (viz níže), odtud pochází jeho jméno. Sekvenční model předpokládá, že požadavky na vývoj software se dají nadefinovat předem a další fáze jsou navrženy tak, aby tyto požadavky jenom naplnily a nějak dostaly do produktu.
Když se na to podíváme podrobněji, vidíme, že vodopádový model potřebuje tři fáze. Fáze dvě je plánování. Třetí fází je provedení plánu. Nejdůležitější je ale fáze jedna, která je mnohdy nevyslovená: spekulace. Ve vodopádovém modelu firmy předstírají, že mají znalosti o tom, co zákazníci chtějí a spekulují, že když se jim dodá funkcionalita X, budou to opravdu chtít.
Agilní vývoj
Agilní vývoj na to jde jinak. Jedná se vlastně o aplikaci vědecké metody na softwarový vývoj. Naše nulová hypotéza je, že nevíme nic – předpokládáme, že když vyvineme funkcionalitu X, tak ji zákazníci nebudou chtít. Tuto hypotézu se snažíme vyvrátit – máme tedy motivaci k tomu, abychom ji vyvrátili co nejrychleji a mohli zformulovat další hypotézu. Vyvracení probíhá tím, že vyvineme kousek dané funkcionality, dáme ji zákazníkům do rukou a pozorujeme, jestli je pro ně užitečná. Pokud ano, vyvrátili jsme nulovou hypotézu a celý postup opakujeme.
V čem je agilní vývoj lepší než vodopád
Vývoj software je střelba na běžící cíl. Zákazníci neví přesně co chtějí a jsou schopni to pojmenovat až tehdy, když mají něco v ruce. Agilní vývoj jde této charakteristice naproti a díky častému vydávání produktu do rukou zákazníka je schopen častěji sbírat zpětnou vazbu na produkt a tím pádem častěji upravovat cíl.
Tato vlastnost (schopnost často měnit směr) je klíčovou vlastností agilního vývoje a odlišuje jej například od štíhlého (lean) vývoje (víz níže).
Druhou zásadní výhodou je lepší ekonomická návratnost. Dejme tomu, že vyvíjíte produkt vodopádovým modelem a trvá vám to šest měsíců a od chvíle, kdy ho vyvinete vám vydělává 1 mil měsíčně. Když stejný produkt vyvíjíte agilně dejme tomu ve dvoutýdenních iteracích a po dvou měsících jste schopni dodat čtvrtinu funkcionality a po čtyřech měsících polovinou, vaše finanční situace se zásadně zlepší.
Nejenom že svoje peníze dostanete dřív, což je dobré pro firemní cashflow, ale v součtu jich dostanete mnohem víc. Konkrétně po 7 měsících máte na kontě 2,5 mil Kč (viz tabulka). Navíc je pravděpodobné, že na začátku se soustředíte na funkce, které budou vynášet nejvíc peněz, takže návratnost bude nejspíš ještě lepší.
| Vývoj | 1 | 2 | 3 | 4 | 5 | 6 | 7 | Celkem |
| Vodopád | – | – | – | – | – | – | 1000 | 1000 |
| Agilní | – | – | 250 | 250 | 500 | 500 | 1000 | 2500 |
Metody agilního vývoje
Způsobů, jak organizovat agilní vývoj, je nepřeberné množství. Ty nejčastější techniky autoři sdružili do skupin, kterým se někdy trochu nepřesně říká agilní metodiky. Zde uvádím ty nejčastější.
Extrémní programování
Jedna z prvních metodik, dnes neprávem trochu pozapomenutá, protože dala softwarovému vývoji techniky jako průběžná integrace (continuous integration), sdílené vlastnictví kódu (collective code ownership), párové programování, přímá interakce se zákazníkem a další.
Scrum
Dnes asi nejznámější – dělí vývoj do krátkých iterací, kterým říká sprinty. Každý sprint končí formální událostí, která umožňuje změnit směr vývoje. Velké rozšíření Scrumu bohužel přineslo i jeho časté zneužívání (viz níže).
Lean
Lean neboli štíhlý vývoj by zpopularizován pro vývoj software knihou Lean Software Development od Mary a Toma Poppendieckových. Princip štíhlého vývoje vychází z Toyota Production System – místo vývoje ve velkých dávkách (v automobilce velká série automobilů, v software velká skupina funkcí) se snažíme systém nastavit tak, aby bylo výhodné vyvíjet v co nejmenších dávkách (v automobilce jedno auto, v software jedna malinká funkce).
Tady je dobré zdůraznit, že vývoj v malých dávkách ještě neznamená agilní vývoj. Vývoj v malých dávkách pouze umožňuje agilní vývoj tím, že po každé dávce je možné zastavit a změnit směr. Pokud ovšem tuto změnu směru neděláme, tak agilní vývoj stále nemáme.
Kanban
Kanban je metoda opět převzatá z výroby, která zajišťuje to, že ve výrobě je vždy optimální množství inventáře pro další fázi výroby. Zajišťuje to takzvaným pull systémem – předchozí fáze nemohou nic dělat, dokud jim další fáze neuvolní místo konzumací částečně opracovaného výrobku.
Při vývoji software se často používá notně upravená verze kanbanu, která nerespektuje mnoho jeho principů (například tzv. WIP limity), proto je většinou lepší se pojmu kanban vyhýbat.
Agilní divadlo
V poslední větě jsme narazili na častý problém při používání agilního vývoje. Zaměstnanci firma uvidí nějaký nový pojem, zalíbí se jim a bez hlubšího pochopení jej začnou používat. Tím pádem ovšem dojde k tomu, že tento pojem se vyprázdní a splyne s tím, co už se ve firmě používalo. Tento proces bohužel potom dělá agilnímu vývoji velmi špatné jméno.
Je to nejspíš téma na samostatný článek, takže jenom nejčastější prohřešky:
- WaterScrumFall – na začátku naplánujeme celý projekt, potom pracujeme jakoby ve sprintech a na konci to teprve vydáme. Říkáme tomu Scrum.
- Jeden produkt, více Product Ownerů – v takovém případě to nejsou vlastníci produktu, ale spíš byznys analytici a mezitýmoví koordinátoři
- Mezitýmoví koordinátoři jsou vůbec téma. Když se to nepodaří u Product Ownera, zkusíme to u Scrum Mastera.
- Přitom nutnost mezitýmové koordinace plyne hlavně z toho, že týmy nejsou úplné. Patří do týmu architekt, UX designer, byznys analytik, DB administrátor, atd.? Pokud ne, není to multifunkční tým, jak ho chápe Scrum a nemůžete očekávat jeho výhody.
V tomto seznamu by se dalo pokračovat, ale jako ilustrace to, myslím, stačí. Pokud chcete rychle posoudit, jestli je nějaká metoda agilní, můžete použít slovníkovou definici z Cambridge Dictionary:
- schopný hýbat se rychle a plynule
- (pro firmy) schopný zvládat nové situace nebo změny rychle a úspěšně.
Pokud metoda vede k témto výsledkům, je agilní. Jinak agilní není, i kdyby si to třikrát napsala do jména.
Při vývoji a při práci s firmami používám principy, které vycházejí z agilního vývoje. Pokud se vám článek líbil, sledujte mě na LinkedIn nebo Twitter.