Agilní vývoj od A do Z: Průvodce, který dává smysl

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 je iterativní přístup k tvorbě software, který staví na častém vydávání fungujících verzí produktu, průběžné zpětné vazbě od zákazníků a flexibilitě reagovat na změny. Místo toho, aby tým strávil měsíce plánováním celého projektu, práce probíhá v krátkých cyklech (typicky 1-4 týdny), po kterých se dodává použitelný kus funkcionality a vyhodnocuje, zda jde správným směrem.

Agilní vývoj na to jde jinak než vodopád. 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ší.

Agilita mimo IT: Proč by vás to mělo zajímat jako byznysový vedoucí

Pokud vedete tradiční firmu – energetiku, výrobní podnik, banku nebo pojišťovnu – možná si říkáte: “To je pěkné pro startupy, ale my máme regulace, dlouhé investiční cykly a stabilní zákazníky. Agilní vývoj není pro nás.”

Opak je pravdou. Právě ve velkých firmách s dlouhou historií může agilní přístup přinést největší hodnotu. Zde je proč:

Problém: IT jako černá díra investic

Typický scénář v large-scale firmě vypadá takto:

1. Byznys oddělení definuje požadavky na nový systém (6 měsíců)
2. IT zpracuje analýzu a odhad (3 měsíce)
3. Schvalovací proces a budgeting (3 měsíce)
4. Vývoj (12-18 měsíců)
5. Testování a spuštění (3-6 měsíců)

Výsledek po 2-3 letech: Systém, který řeší problém, jaký jste měli před třemi lety. Trh se posunul, regulace se změnily, konkurence vás předběhla. Investovali jste desítky milionů do něčeho, co je zastaralé ještě před spuštěním.

Řešení: Agilní přístup k byznysu

Agilita není o Scrumu nebo Kanbanu. Agilita je byznysová strategie, která vám umožňuje:

Rychleji reagovat na změny trhu:

• Nová regulace? Místo projektu na 18 měsíců máte základní řešení za 6 týdnů
• Konkurent spustil novou službu? Můžete mít MVP (Minimum Viable Product) za dva měsíce
• Změna zákaznických potřeb? Zjistíte to během vývoje, ne po roce marné práce

Snížit riziko investic:

• Místo 50 mil. Kč slepé investice investujete postupně po 5 mil. Kč
• Po každé iteraci víte, jestli jdete správným směrem
• Můžete projekt zastavit, pokud přestal dávat smysl (a ušetřit 80 % investice)

Zvýšit zapojení byznysu:

• IT přestává být černá skříňka
• Byznys vidí výsledky každé 2-4 týdny, ne po 2 letech
• Spolupráce namísto “přehození přes plot”

Co to znamená pro vás

Agilita není jen “jiný způsob, jak dělat IT”. Je to způsob, jak:

• Zkrátit time-to-market pro nové služby a produkty
• Snížit náklady na IT o 30-50 % (méně zbytečného vývoje)
• Zvýšit spokojenost zákazníků (rychlejší reakce na potřeby)
• Přilákat a udržet talenty (lidé chtějí vidět výsledky své práce)

Otázka není, jestli si můžete dovolit být agilní. Otázka je, jestli si můžete dovolit nebýt agilní, když vaše konkurence už ano.

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). Pro správné pochopení Scrum principů a vyhnutí se častým chybám pomůže Scrum školení, které pokrývá jak teorii, tak praktické aplikace.

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. A ne, nedá se z toho uhnout tím, že výstup každého týmu prohlásíte za “produkt”.
• Mezitýmoví koordinátoři jsou vůbec téma. Když se to nepodaří u Product Ownera, zkusíme to u Scrum Mastera
• Jeden produkt, více produktových backlogů. Variace na předchozí téma. Každou komponentu prohlásíte za produkt vlastně jenom proto, aby se vám lépe řidila. Zažil jsem firmu, která měla 10 “produktových” backlogů na 14 lidí ve vývoji. Potom samozřejmě není vůbec jasné, jestli to, na čem se pracuje, je pro firmu důležité.
• 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šechno je User Story. Naučili jsme se, že v agilním vývoji se používají User stories, proto se pokoušíme každý zákaznický požadavek formulovat tímto způsobem. Ale pořád děláme technické dělení.

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:

1. schopný hýbat se rychle a plynule
2. (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.

Ve své konzutační a školicí praxi vycházím z mnohaletých zkušeností s vývojem software. Používám techniky, které jsou v souladu s touto zkušností, i s principy agilního vývoje. Pokud se vám článek líbil, sledujte mě na LinkedIn nebo X (Twitter).