Tradičně řízené projekty s fixním zadáním, cenou a termínem nedopadají tak dobře jako agilně řízené projekty. Proto je jedním z IT trendů poslední dekády přechod k agilnímu řízení projektů a metodice Scrum.
Stalo se vám někdy, že jste si jako zadavatel nebo dodavatel webového projektu domluvili dílo v konkrétním rozsahu, času a ceně a projekt nedopadl podle vašich představ a možná ani představ druhé strany?
Nejste sami.
Mnohokrát jsme byli v této situaci jako dodavatel a spálili se. Odepsali práce za stovky tisíc Kč. Ani klient v této situaci nejásal z prodlouženého termínu a výsledku, který nebyl přesně tím očekávaným.
Např. FBI v roce 2000 „hodila do kanálu“ $170 milionů dolarů za interní systém, jehož tradičně řízený vývoj trval 5 let a nakonec se musel bez výsledku zastavit. (V roce 2010 ho zkusili znovu vyvíjet agilně a povedlo se. Vývoj stál polovinu a systém se začal používat v reálných případech.)
Jaká jsou nejčastější příčiny těchto selhání?
- Původní zadání se dostatečně nespecifikuje. Obsahuje mezery. Klient i dodavatel předpokládají určitý rozsah a kvalitu, ale každý jinou. (O tom, že není rozumné dávat a vyžadovat záruku na software jsme již psali.)
- Zadání se mění v průběhu práce. Např. klient dodá obsah, který je podstatně bohatší než se předpokládalo v původním návrhu.
- Odhady bez rezerv. Při vývoji se často narazí na nečekané překážky, které nelze nikdy předem 100% odhadnout. Z našich zkušeností je potřeba počítat s rezervou hlavně na:
- Napojení aplikace na jiné systémy např. účetní software. Dodavatel vlastně odpovídá za práci jiných lidí (např. vývojářů účetního software), které si ale sám nevybral. Komplikovaným napojením můžou naházet spoustu klacků pod nohy a prodloužit termíny dodávek.
- Použití nové technologie, která sice může slibně vypadat, ale také přinést nečekané překážky s vývojem i nasazením aplikace.
Řešení?
Vyvíjet sotware agilní metodikou.
Agilní manifest
V roce 2001, kdy agilní hnutí vznikalo, přišli jeho hlavní strůjci s manifestem, na jakých hodnotách by měl být založen vývoj software.
Jednotlivci a interakce před procesy a nástroji.
Agile Manifesto
Fungující software před vyčerpávající dokumentací.
Spolupráce se zákazníkem před vyjednáváním o smlouvě.
Reagování na změny před dodržováním plánu.
Jakkoliv jsou body napravo hodnotné, bodů nalevo si ceníme více.
Na těchto hodnotách jsou pak založeny metodiky agilního vývoje.
Vodopád vs agilní vývoj
V levé části obrázku je znázorněn klasický vodopádový vývoj softwarového projektu – tedy projektu, kde je definováno co, kdy a za kolik. Jak vidíte, zadavatel prakticky nemůže vnést nové požadavky do už rozjetého projektu. Může pouze připomínkovat, že nebylo dodáno to, co je ve specifikaci. Jenže ani skvěle napsaná specifikace nevystihuje realitu 100%. Pokud dodavatel přijme za specifikaci pouhou poptávku zadavatele – obvykle vágní – tak si právě ustlal na seně s doutnajícím uhlíkem.
Největším problémem je však změna zadání. Z našich zkušeností se do jisté míry upraví zadání u každého projektu nad 100 hodin práce.
Naproti tomu v agilním vývoji řízení projektů se počítá se změnou zadání, protože se projekt tvoří iterativně. Práce se rozdělí na menší části, které se dodávají postupně.
Stále existuje celkový plán tvorby projektu. Jsou definovány milníky, kterých má projekt postupně dosahovat.
| Vodopád | Agilní vývoj | |
|---|---|---|
| Zadání | ❌ Na začátku potřeba přesné specifikace, jejíž změna znamená navýšení termínu i ceny | ✔️ Se změnami se počítá |
| Rychlost dodání | ❌ Výsledek je vidět až na konci projektu | ✔️ Výsledky jsou vidět postupně (po iteračních kolečcích) |
| Jasný rozpočet a termín | ✔️ Fixní cena i termín na celé dílo (pokud se nezmění zadání) | ❌ Pouze odhad dílčích úkolů, platba dle odpracovaných hodin |
| Cena změn v zadání | ❌ Vysoká (předělává se až hotový produkt) | ✔️ Nízká (na problémy se reaguje hned, prioritizuje se v průběhu) |
| Vztah dodavatel-odběratel | ❌ Dohadování nad měsíce starou specifikací a smlouvou | ✔️ Spolupráce a komunikace |
Výsledky Agilního vývoje
V roce 2013 byla se 173 softwarovými týmy provedena studie, ve které měly týmy hodnotit úspěchy vývoje dle použité metodiky. Úspěchy agilního vývoje jasně převážily nad tradičním vodopádovým přístupem.
Agilní vývoj také získal v této studii jasně lepší hodnocení než vodopádový co se týče kvality výsledku, hodnoty pro zadavatele, návratnosti/výdělečnosti projektu i času/termínu.
„Náš“ odlehčený Scrum
Pro agilní řízení projektů se nejčastěji používá metodika Scrum. V plném rozsahu se hodí pro projekty, na kterých pracuje alespoň několik lidí full-time (nepřetržitě). Viz dokumentace celé metodiky.
Autor: Lakeworks – Vlastní dílo, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=3526338
Naše webové projekty se pohybují spíše na dolní hranici použitelnosti plného Scrumu, proto používáme „naši“ odlehčenou verzi Scrumu.
Jak prakticky vývoj probíhá?
- Na začátku projektu vytvoříme obvyklý plán, jak budeme postupovat. To se příliš neliší od vodopádového přístupu, jen s tím rozdílem, že v agilním plánu jdeme méně do detailu. Odhadneme potřebný čas a finance na vývoj jednotlivých milníků a tedy i celého projektu. Odhad je nezávazný, byť se snažíme odhadovat realisticky.
- S klientem si domluvíme pravidelné 2-4 týdenní schůzky (tzv. Sprinty). Na schůzce probereme:
- Demo. Ukážeme, co jsme vytvořili od minulé schůzky. Probereme i co se nestihlo nebo kde se objevily problémy či nejasné zadání.
- Požadavky. Je dodaná práce OK nebo provedeme nějaké změny? Vyvinuly se požadavky a bude třeba upravit zadání? Zapíšeme si požadavky klienta, abychom z nich později mohli vytvořit proveditelné zadání.
- Plán. Naplánujeme úkoly pro další Sprint, tedy do další schůzky. Na vývoj půjdou typicky práce s nejvyšší prioritou a přijatelnou cenou (odhadnutým počtem hodin). Jednodušší požadavky z předchozího kroku můžeme rovnou odhadnout a naplánovat, složitější požadavky zpracujeme později po schůzce do proveditelného zadání.
Téměř všechny větší projekty (za vyšší stovky hodin práce) dnes již vyvíjíme agilně. Zdá se, že i klienti tento způsob práce oceňují, viz naše reference:
Nic není nemožné, cokoliv jsme si vymysleli, bylo zrealizováno do nejmenšího detailu.
Ladislav Meškán, Dokonalý Zážitek
