Vodopád, nebo agile?

Nejde o to, zda je jeden přístup lepší než druhý. Jak vodopád, tak agile mají své přínosy, pokud jsou ovšem použity pro správný projekt, což je často kámen úrazu. Podívejme se blíže na nejvýznamnější oblasti, které je potřeba vyřešit při potřebě současné existence klasických a agile projektů.

1. Struktura projektů a jejich řízení odráží strukturu organizace

Je důležité si uvědomit, že problematika zavádění kombinace agilních a klasických projektů je téměř výhradně doménou firem, které vyrostly jako hierarchické firmy a stejným způsobem mají nastaveno i řízení projektu. Agile přináší jiný přístup k řízení, rozdělení odpovědnosti, hodnocení, plánování atd. Zavádí do organizace nové způsoby práce, které ale zároveň zpochybňují metody, díky kterým byla firma doposud úspěšná. A ještě podstatnější je, že to samé platí i na úrovni jednotlivých manažerů.

Co s tím:

• Použití agilního přístupu si dobře připravte (viz. body 2 a 3. níže). Začněte projekty, které jsou pro agilní metodiky nejvhodnější – tvorba nových inovativních produktů formou prototypů, jednodušší webové prezentace, mobilní aplikace … Naopak velké, integrované projekty, nasazování balíkových řešení, implementace SAPu apod. nejsou vhodnými projekty, na kterých je dobré se učit nové metodiky.
• Počítejte s odporem řídicích struktur, srozumitelně a otevřeně komunikuje, snažte se dopředu lidem představit jejich místo v novém způsobu fungování. Nezapomeňte na pracovníky, kteří sice formálně nejsou ve vedení, ale jsou neformálními autoritami a názorovými leadery. Hodně pozornosti věnujte střednímu managementu, lidem z PMO, architektům a business analytikům – to jsou skupiny, které se novými pořádky většinou cítí nejvíce ohroženy.
• Agile projekty svým způsobem řízení nemohou dostát všem požadavkům na rozsah a formální náplň dokumentace vyžadované pro klasicky řízené projekty. To ovšem neznamená, že nebude vytvořena žádná dokumentace a projekt nebude řízen. Dokumentaci je nutné upravit tak, aby podporovala myšlenku agile přístupu, od plánování času a zadávání práce, až po sledování postupu a reporting. Nezapomeňte proto včas komunikovat potřebu jiné struktury dokumentace na centrální jednotky, jako jsou PMO.
• Počítejte také s nutností upravit způsob financování takového projektu. Pro začátek je vhodný investiční model – stanovíme celkovou částku, kterou chceme do projektu investovat. Určíme si tým, jehož kapacitu chceme do řešení investovat a čas, který jim dáme na zodpovězení základních otázek typu „Jak by měl vypadat produkt xy, aby ho kupovali naši zákazníci?“, „Jak by měl vypadat nový modul našeho systému, aby se dobře a rychle ovládal našim pobočkovým pracovníkům?“, „Je tato technologie dostatečně konfigurovatelná a robustní, aby ji bylo možné použít v našem prostředí?“ Na základě odpovědí, pak určujeme další cíle projektu a přidělujeme finance do dalších etap.
• Agile přístup není jediný správný. Pro některé projekty se hodí více, než pro jiné, proto úspěch agile projektu nepoužívejte k demonstraci slabých stránek klasických přístupů. Berte si ze současné metodiky ověřené a fungující části a účelně je využijte. Stejně tak můžete inspirovat „tradicionalisty“ v obohacení klasických přístupů o některé nové prvky.
• Nezapomínejte, že cílem projektu je přinést vaší organizaci zisk nebo jiný prospěch, a ne si hrát s technologickými hračkami viz. také bod 5.

2. Úspěšné řešení některých problému se bez iterací neobejde

Problémy se obecně dají rozdělit do 4 kategorií (viz následující schéma):

• Jednoduché – u těchto problémů dokáže zkušený odborník rovnou navrhnout, jak bude problém řešit, většinou existuje jedno nejlepší řešení.
• Komplikované - Komplikované problémy vyžadují odborníky často z několika oblastí a jejich společné soustředěné analytické úsilí, aby bylo nalezeno řešení problému. Existuje více možností řešení, hledá se optimální varianta.
• Komplexní – Při řešení komplexních problémů je nejlepší využít metodu testování a prototypování, díky kterým ověříme, jestli jdeme po správné cestě. Problematika je natolik složitá, s mnoha proměnnými a neznámými, že pouhá analýza je nedostatečná.
• Chaotické - tato oblast je bez pravidel a vládne zde model pokus/omyl/náhoda/štěstí.

Klasické projekty řízené podle vodopádového přístupu se staví k zadání tak, jako by všechna řešená témata pocházela pouze z oblasti Jednoduché, nebo Komplikované. To ovšem přestává fungovat v okamžiku, kdy má projekt využít dosud nevyzkoušenou technologii, nebo řešení zadání není možné vytvořit pouhou analýzou. V okamžiku řešení inovací, ať už na straně výsledného produktu, nebo použité technologie, nastupuje potřeba použití iterací, prototypování, empirického testování se zákazníkem atp. Toto jsou oblasti, ve kterých má agile přístup největší přidanou hodnotu. Díky zvyšující se potřebě inovací, zaměření na zákazníka, velké konkurenci a preferenci digitálních kanálů a nových technologií lze očekávat, že do budoucna bude čím dál více zadání pro projekty právě z oblasti Komplexních problémů.

Co s tím:

• Na začátku projektu si ujasněte:
  • jaký typ problému řešíte,
  • jak velká míra nejistoty je ukrytá v požadavcích zákazníka
  • jak moc jste si jisti technologiemi a nástroji, které chcete použít.
• Pokud je v obojím jasno, použijte metodiku, na kterou je tým, který máte k dispozici, zvyklý.
• V případě, že v technologické nebo business rovině vidíte větší míru nejistoty, zařaďte do svého projektu iterace, prototypy, testování s reálnými zákazníky, a to hned od začátku. Nemá cenu sepisovat analýzu na produkt, který nebude nikdo kupovat. Narazili jste na projekt, kde je vhodné použít agilní metodiku.

3. Synchronizace a architektura

Nejčastěji zmiňovanými problémy současné existence agilních a klasických projektů je jejich vzájemná synchronizace k daným milníkům nebo releasům a schopnost agilních projektů naplnit architektonické a integrační požadavky a omezení. Vodopádové projekty řeší architekturu v rámci úvodní analytické fáze a kontrola naplnění integračních požadavků a pravidel je většinou kontrolována pomocí schvalování jednotlivých fází architektonickými komisemi a účastí integračních architektů na projektu.

Nejpoužívanější agilní metodika SCRUM toto nijak neřeší a vychází z principů agilního manifestu [1] „Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů.“. To může dobře fungovat u malých nezávislých projektů nebo v případě, že celá infrastruktura organizace je přizpůsobena agilnímu způsobu vývoje. Hodně to také závisí na senioritě vývojářského týmu. Pokud máte zkušený tým, který má za sebou již řadu projektů, na kterých se mohli naučit, které cesty vedou k cíli a které končí ve slepých uličkách, můžete jim nechat výrazně větší prostor, než nováčkům.

Pro použití ve velkých organizacích a na velkých projektech vzniklo několik agilních metodik, které se snaží řešit problematiku architektury a synchronizace systematičtěji. Z těch známějších jmenujme SAFe [2], DSDM [3] a LeSS[4]. Rozsah těchto metodik, je nad rámec tohoto článku, ale níže najdete několik základních doporučení.

Co s tím:

• Základem je sdílení informací a vzájemné zapojení lidí z projektů, které mají spolupracovat, do klíčových rozhodnutí.
• Integrace s prostředím - Agilní metodiky doporučují pravidelné schůzky k předvedení hotové práce (demo) a prioritizace práce do budoucna. Je třeba zajistit účast integračních architektů (případně dalších rolí např. z infrastruktury a bezpečnosti) na těchto schůzkách a zahrnout jejich požadavky/připomínky do zadání agilního projektu. Z toho plyne velmi důležitá role facilitátora těchto schůzek – většinou je jím Scrum Master nebo Projektový manažer.
• Integrace s projekty – Schůzek agilního týmu by se měli účastnit také zástupci všech projektů, na které se agilní projekt integruje. Pokud to není možné, měl by se zástupce agilního týmu účastnit schvalování fází/milníků okolních projektů.
• Vodopádový projekt má milníky, agilní projekt pravidelné iterace. Agilní iterace bývají krátké (obvykle dva týdny), neměl by tedy být problém sladit termíny vodopádového projektu s koncem některé iterace a domluvit se, že nejpozději v této iteraci dodá projekt potřebné úpravy architektury/podklady pro integraci/definice rozhraní atd. Agilní metodiky mají nástroje (např. User Story/Epic s omezením na požadovaný sprint), jak tyto závislosti zaznamenat, řídit a vizualizovat. To by mělo usnadnit ověření ze strany vodopádových projektů, že dostanou včas, co potřebují.
• Agilní projekt by měl dodávat pravidelně funkční kód, na základě, kterého lze průběžně testovat a kontrolovat průběh prací, funkčnost sytému v integrovaném prostředí …
• Agilnímu týmu se snažte dát co nejvíce volnosti (kvůli flexibilitě a rychlosti přeci agile používáte), ale podle zkušeností členů týmu nastavte případně pomoc/dohled seniorních architektů, aby místo flexibility nevládl chaos a neúčelné plýtvání zdrojů.
• Při integraci s projektem řízeným podle vodopádu si nezapomeňte ujasnit, jak budou připraveni na testování dodávek z agilního projektu.
• Snažte se také do vodopádového projektu vnést priority z pohledu integrovaných agilních projektů – včasné definice rozhraní, společná rozhodnutí o architektonických principech, identifikace oblastí řešení, kde může docházet ke změnám (funkce, časování).
• Včas se domluvte na integračním prostředí, harmonogramu a způsobu nasazování do tohoto prostředí.
• Snažte se zvýšit efektivitu vodopádových projektů zavedením agilních prvků:
  • Iterace komplexních částí projektu se zákazníkem formou, které zákazník rozumí (funkční aplikace, návrhy obrazovek), nikoliv formou BPMN/UML diagramů.
  • Nové technologie podrobte včas testu pomocí prototypů nebo PoC (Proof of Concept).
  • Nasazujte včas – lepší je nasazovat opakovaně před finálním termínem a včas začít testování na cílovém prostředí, než nasadit na poslední chvíli a doufat, že vše dopadne dobře.

4. Agilní neznamená bez pravidel a disciplíny

Občas se setkáváme s interpretací agile, jako posvěcením chaosu a nedostatku řízení a směřování projektu. To je ale zcela mylné pojetí. Všechny agilní metodiky mají zcela jasná pravidla a vycházejí z principů [1], které na všechny účastníky kladou poměrně velké nároky. Agilní projekt má jasně dané iterace a průběžně i jasně daný výstup jednotlivých iterací. Tím, že agilní tým ukazuje výsledky své práce průběžně a průběžně i získává zpětnou vazbu, je výrazně menší riziko, že na konci dostane zákazník něco neužitečného.

Agilní také neznamená, že se nikdy nedělá analýza dopředu, nebo že se nedělá dokumentace. Obojí se dělá: analýza podle míra složitosti řešeného problému (viz kategorie výše) a dokumentace potřeby konečných konzumentů. Pokud má agilní projekt nalézt odpověď na složitý problém vyžadující analýzu, nebo prototypování, atp. je potřeba ji udělat. Ale pouze v nezbytně nutném rozsahu a míře detailu, s průběžnou kontrolou pro ověření, jestli analýza směřuje k požadovanému řešení. Stejný přístup je třeba zaujmout k dokumentaci. Dokumentace do určité úrovně je nezbytná, zejména u velkých organizací a složitých projektů, ale měla by být tvořena podle potřeb konzumentů, iterativně, se zapracováním zpětné vazby – jako jakýkoliv jiné produkt agilního týmu. U dokumentace nezapomínejte na jednu důležitou věc. Nejde jen o čas a náklady na její vytvoření, ty jsou započítané v projektu. Stejně tak důležitá je i možnost snadné údržby a aktualizace v budoucnu. Pokud v projektu vytvoříte příliš rozsáhlou dokumentaci, za půl roku již bude k ničemu, protože bude zastaralá a neudržovatelná.

Agilní projekt vyžaduje i odlišné zapojení manažerských rolí. Manažer v tomto případě jen stanovuje hranice a závazná pravidla (co nejméně). Pomáhá týmu v jeho fungování, pomáhá s odstraňováním překážek a komunikací v rámci organizace. Velmi dobře je tato problematika popsána v knize Management 3.0 [5].

Největším úskalím startu agilních projektů bývá obsazení role vlastníka produktu (product owner). Tedy zástupce businessu/zákazníka s pravomocí a schopností prioritizovat, schvalovat, určovat další směr projektu a zařídit součinnost dalších lidí. Takových lidí bývá v organizaci málo, mají řadu jiných úkolů, nebo nemají dostatečné kompetence.

Pokud máte dojem, že váš agilní projekt tak nefunguje, zamyslete se nad následujícími body.

Cos tím:

• Zúčastněte se několika schůzek agilního týmu – nejlépe schůzek, na kterých ukazují výstupy (demo) nebo se domlouvají, co v příští iteraci zlepší (retrospektiva).
• Ptejte se na těchto schůzkách na to, co vás zajímá, navrhujte zlepšení, přihlaste se jako konzument některého z výstupů jejich práce.
• Pokud tým začíná, je dobré zařídit jim odpovídající školení nebo kouče, který pomůže vyvarovat se začátečnických chyb.
• Agilní tým by měl používat hodně vizualizačních nástrojů (SCRUM/KANBAN board, různé canvasy, …) ptejte se po nich, diskutujte nad nimi s týmem. Jen tak získáte představu, jak tým funguje.
• Ptejte se, jak je zapojen produktový vlastník, případně pomozte s jeho hledáním, alokací a zařizováním dalších součinností.

5. Show me the money

Při všech úvahách a diskusích o metodikách bychom neměli zapomenout na to, že cílem každého projektu by mělo být přinést sponzorovi projektu domluvený prospěch. Použití libovolné metodiky by mělo být hodnoceno podle aktuální situace v dané organizaci, typu problému, který chceme řešit a týmu který máme k dispozici. Projekt dodaný perfektně podle metodiky, který nepřinese očekávaný benefit, je špatně dodaný projekt – bez ohledu na to, o jakou metodikou byl řízen.

Literatura

[1] Agilní manifest http://agilemanifesto.org/iso/cs/principles.html
[2] SAFe http://www.scaledagileframework.com
[3] DSDM https://www.agilebusiness.org/
[4] LeSS https://less.works/
[5] Jurgen Appelo : Management 3.0

Eva a Zdeněk Macháčkovi Autoři článku, Eva a Zdeněk Macháčkovi, pracují jako konzultanti a projektoví manažeři. Zaměřují se na strategické poradenství, vzdělávání a popularizaci nových trendů businessu a podnikového IT. http://bit.ly/evamachackova http://bit.ly/zdenekmachacek