Co je agilní vývoj a skutečně si myslíte, že ho máte?

06/11/2024

Za svou kariéru jsem prošel spoustou různých firem, spolupracoval s desítkami týmů a viděl různé přístupy k vývoji a řízení vývoje softwarových produktů.

Když jsem začínal, svatým grálem bylo mít projekt správně naplánovaný od začátku do konce. Nejcennější dovedností v týmu bylo projektové řízení a tvorba promyšleně vypadajících Gantt diagramů, které žádného klienta nenechaly na pochybách, že víte co děláte a že projekt doručíte tak, jak je to potřeba. Přece na to máte plán!

Většina firem ale časem zjistí, že plány a odhady jsou jen teorie, která se často míjí s dennodenní praxí a fungováním softwarových týmů.

Osvícení manažeři a šéfové softwarových týmů tak začnou pošilhávat po tom, jak dělat svou práci jinak, lépe. Tak, aby byli více spokojení oni, členové jejich týmů, zákazníci a samozřejmě také uživatelé, kteří budou s vyvíjenými produkty pracovat.

Pomyslné prozření přijde, když objeví agilní vývoj.

Všechno najednou začne dávat smysl:

• nemusejí se dávat dohromady několikasetstránkové specifikace produktu, který vymysleli manažeři odtržení od zákaznické reality
• vývojáři netráví desítky hodin při odhadech časové náročnosti funkcí, u kterých vlastně nemají představu, jak budou ve finále fungovat
• díky fungování v krátkých iteračních cyklech jsou schopni mnohem lépe reagovat na změny
• zákazník uvidí funkční výsledek dříve než na konci projektu
• produkt můžou testovat a vylepšovat v průběhu vývoje (a nikoliv až na konci projektu)
• na vývoji produktu budou více spolupracovat se zákazníkem a jeho uživateli, díky čemuž výrazně sníží riziko toho, že doručí nefunkční paskvil
• produkt budou vytvářet všichni společně, zlepší týmovou komunikaci a pocit odpovědnosti za výsledek

A tak dále a tak dále.

Na první pohled je agilní vývoj oproti tzv. vodopádu no-brainer.

Postulát dnešní doby je jasný: Agilní vývoj je jediná správná metodika podle jaké by moderní softwarové týmy měly vyvíjet produkty.

Rigidní plánování a vodopádový vývoj patří ve spoustě firem na seznam zakázaných praktik.

A přesně tyhle firmy se také budou navenek bít do prsou a tvrdit vám, jak k vývoji přistupují moderně a pracují agilně. Jasně, co jiného by měly říkat?

Ovšem nic není černé nebo bílé.

Mezi oběma extrémy existují stupně šedi. A vězte, že jejich paleta je pěkně široká. Skoro se nabízí říct, že těch odstínů je víc jak hvězd na obloze...

Když se firmy ale zeptáte, jestli je její vývoj vodopádový nebo agilní, dostanete jednu odpověď (agile) a málokdo bude zabíhat do detailů, které by vám o jejím fungování napověděly více.

Chápu, lidi mají rádi zkratky.

A pokud máte o agilním vývoji něco málo načteno (a ideálně také na vlastní kůži prověřeno), odpověď na tuhle otázku vám s sebou nese i jistá očekávání.

A tady se podle mé praxe teorie rozchází s realitou. Častokrát více, než je zdrávo.

Co tím myslím?

Inu – i když vám firma skálopevně bude tvrdit, jak agilně funguje, ve chvíli kdy se zanoříte do denní operativy a přičichnete k některým interním procesům a praktikám, bude vám nad slunce jasné, že agilní vývoj ve své ryzí podobě je pouze zbožné přání a praxe má mnohem blíže k vodopádu...

Pojďme se mrknout na ty nejčastější prohřešky, s nimiž jsem se za 20 let mé praxe setkal:

• Nedoručení hodnoty – jedním ze základních principů agilního vývoje je generování hodnoty pro zákazníka as soon as possible. Většina agilních týmů jede scrum (protože mají Jiru 🙃) s dvoutýdenními sprinty, během nichž by se mělo dodat něco, co rozšíří to, co jste měli předtím. Podle slabikáře byste tu věc měli také zpřístupnit zákazníkům. Ne nutně všem, ale tolika, abyste získali zpětnou vazbu. To se u většiny větších týmů neděje a vytvořená hodnota se drží lokálně na jejich prostředí a čeká se na naplánovaný release. Čest výjimkám, které do svých procesů adoptovaly principy continuous delivery a vývojáři jsou schopni pushovat změny do produktu, jakmile jsou hotové.

• Plánování výsledku a reagování na změny – je OK mít plán toho, co chcete dosáhnout. Není OK plánovat na měsíce dopředu přesné termíny, úkoly a aktivity. Ze své podstaty by měl být agilní vývoj flexibilní a reagovat na změny a informace, které se v průběhu procesu objeví. A slovy maršála Moltkeho „žádný plán nepřežije setkání s nepřítelem“. Je fakt zbytečné (a týmově kontraproduktivní) se připravovat na všechny možné scénáře dopředu. Přijměte nejistotu jako součást cesty. Důležité je umět reagovat na věci, které se objeví. Vývojáři tohle pochopí celkem rychle; složitěji se to vysvětluje klientům. Ti logicky požadují záruky a jistoty, které jim na první pohled iterativní vývoj nedává. Tohle by bylo na samostatný článek, ale v principu musejí pochopit, že stěžejní výhodou tohoto přístupu je minimalizace rizika potenciálního selhání produktu. (Předpokladem je, že nejste jen order-taker, ale máte s klientem společný zájem na jeho úspěchu).

• Zapojení uživatelů – dalším z pilířů agilního vývoje je kromě častých iterací i zapojení uživatelů. Ti by vám měli dávat zpětnou vazbu na vaše řešení a validovat práci. A i když je vývoj iterativní, není ve firmách pravidlem, aby vygenerovaná hodnota během sprintu skutečně viditelně vylepšila softwarový produkt. A pokud nemáte novinky, není se s uživateli o čem bavit. Nemluvě o tom, že uživatelské testování je i pro spoustu jakožeagilních firem stále pouze krok v celém vývojovém procesu, k němuž se přistupuje častokrát až na konci. Celý problém je spojená nádoba s plánováním: pokud adoptujete princip "já ani zákazník nejsem uživatel", zákonitě budete potřebovat odpovědi od lidí. A kdyby se vám jich dostalo až na konci, budete mít setsakramentský problém.

• Nekompletní týmy pracující v silech – podle agilních principů byste v týmu měli mít zastoupené všechny role, které se na uvedení produktu na trh podílejí. V realitě častokrát jsou součástí core týmu pouze vývojáři a veškeré další role (produkt, testování, design, obchod, brand, marketing,...) sedí někde jinde. To se děje nejčastěji proto, že dané role musejí obhospodařovat i jiné produkty nebo pracovat i na dalších firemních aktivitách. Pokud nemáte všechny potřebné role pro vývoj daného produktu v jednom týmu, exponenciálně narůstá komplexita v otázkách plánování, synchronizace a spolupráce. I malý hodinový úkol se může klidně řešit týdny.

• Polovičaté adoptování metodik – tohle se týká především týmů fungujících podle frameworku scrum: i když scrum existuje zhruba od poloviny 90. let (a jeho fungování a procesy jsou dobře popsané), setkal jsem se s mnoha organizacemi, které jej adoptují jen částečně (a ne, nemyslím si, že za tím bývá zralá úvaha jako spíš neznalost). Snad každý agilní tým má pravidelné stand-upy. Už méně týmů si ale osvojilo další agilní ceremonie jako jsou třeba retrospektivy. Toto vnímám hlavně u týmů, které se agilní vývoj nenaučily formálně, tj. chyběl tam opravdový scrum master nebo jiný průvodce procesem adopce.

Celé to píšu hlavně proto, že nemám rád absolutní pravdy.

Ani v politice nikdy nejste úplně nalevo nebo úplně napravo.

Ve skutečnosti vlastně neoperujete ani na přímce, ale v ploše.

Je tedy vlastně jedno, jakým buzzwordem slovem svůj proces označujete, protože jím bez dalšího kontextu nejste schopni popsat svoje fungování a předat tuto informaci v celé její komplexitě někomu dalšímu.

Nejvypovídající reprezentací vývoje digitálních projektů by byl spider chart, na kterém byste jednoduše viděli, kde přesně se daná firma v jednotlivých oblastech nachází. (Příklad pro ilustraci níže - doporučuju projít tímto jednoduchým cvičením v týmu a potom porovnat výsledky s dalšími týmy; budete překvapeni, jak moc se to může lišit i v rámci jedné firmy 🙂)

Na závěr ještě přihodím tabulku porovnání scrumu a kanbanu, což jsou dva nejčastější frameworky využívané v agilním vývoji. Třeba to někomu pomůže, protože i zde spousta lidí mylně zaměňuje jeden za druhý (anebo prostě mixují jednotlivé aspekty obou dohromady - i to už jsem zažil...).

A něco málo o tom, proč je vlastně kanban nejlepší framework pro agilní projekty