Slovo agilně se stalo buzzwordem, prázdnou frází která téměř nic neznamená. Projekty často končí neúspěchem, nejsou na nich dodržovány domluvené termíny dodávek, případně jsou vnímány jako velmi chaotické a velmi často „vyšumí do ztracena“. Proč se tedy agilem vůbec zabývat, když jeho celkové vnímání v praxi vypadá tak rozporuplně?
Pojďme si je rozdělit na tři základní přínosy:
- Agilním přístupem je možné rychle reagovat na změny – zákazník by měl na konci dne dostávat produkt, který potřebuje právě v době, kdy produkt dostává. Nikoliv produkt, který potřeboval před rokem, kdy běžela analýza.
- Agilním přístupem je možné pracovat s vizí – není nutné mít detailně rozmyšlené a specifikované zadání, sepsané všechny okrajové podmínky a varianty chování produktu. Stačí mít vizi produktu, který budujeme, vědět proč ho vytváříme, jaký problém má vlastně řešit a pro koho je určen.
- Možnost průběžně si osahávat výsledek – pokud je vize produktu, měla by být i představa, jakým směrem se půjde dále. Jaké budou další kroky, další funkčnosti produktu. Během krátkých iterací si lze osahávat další nápady a případně korigovat směr.
Všechny tyto přínosy lze eliminovat problémy z následujících sedmi oblastí.
1. Marketing do firmy
Má-li firma fungovat agilně, musí v ní proběhnout hlavně kulturní změna a změna ve způsobu uvažování a fungování Vašich lidí. Tato změna kultury se nedá nařídit, nedá se vynutit. Musí se lidem trpělivě vysvětlovat, motivovat je a také je třeba vědět, že ne všichni zaměstnanci s ní budou kompatibilní. S agilní transformací to dotáhnete jen tak daleko, jak vysoko v organizační struktuře je zajištěna podporu managementu. Při této kulturní změně je vhodné zkombinovat top-down (podporu managementu) a bottom-up (pilotní průkopnické týmy) přístup a být připraven na rezistenci. Proto je naprosto zásadní mít pro transformaci od začátku dostatečně dobrou motivaci a investovat úsilí i do interního marketingu.
2. (Ne)spolupráce byznysu a IT
Agile celkově mění přístup k procesu tvorby softwaru. Byznys si u IT nenakupuje IT službu nebo „krabicový produkt“. Tvorba software nemůže probíhat jako nákup auta, kdy se vybere karoserie, barva, z katalogu výbava, vyjednají se výhodné slevy a pak se čeká, kdy dodavatel auto přiveze. Takto se software dělat nedá – byznys se musí stát přímým účastníkem procesu, musí se zapojit a ovlivňovat vytvářený produkt.
3. Silný product owner
Klíčovou osobou je tzv. product owner, tedy člověk, který je nositelem vize produktu. Musí vědět, proč se produkt buduje, jaký problém a pro koho řeší a jakým směrem ho chce rozvíjet. Často se v praxi lze setkat s tím, že product owner má na starost několik produktů najednou a nemá čas se zapojit. Pokud tuto osobu vidíte jen jednou za dva týdny na hodinu, pak máte problém. Stejně tak, pokud daný člověk není dostatečně kompetentní a silný, aby byl schopen přijímat důležitá rozhodnutí de facto od stolu a ve své organizaci je uměl prosadit, stojíte opět před velkou překážkou.
4. Omluva pro absenci procesu
Agile neznamená nedodržovat proces, neplánovat, neplnit závazky a nic nedokumentovat. Proces může být velmi jednoduchý, ale měl by být definovaný. Plán alespoň na další jednu či dvě iterace by rovněž měl existovat a měl by být dodržován. Pokud se chronicky neplní, co se naplánuje a co se skutečně dodá, pak jde o chaos, ne agile. Navzdory většinovému přesvědčení se ukazuje, že během agilního projektu musí vzniknout i dokumentace. Jiná než u tradičních SW metodik (zejména proto, že slouží k jinému účelu), může např. vznikat paralelně s vývojem. Vhodným přirovnáním účelu dokumentace u tradičních přístupů (waterfall) a agilní dokumentace je stavební dokumentace nového rodinného domu. Původní projektová dokumentace před stavbou (waterfall) versus průběžné dokumentování (např. formou fotografií) pokroku přímo na stavbě (kde jsou reálně umístěny trubky, rozvody elektřiny atp.).
5. Doing agile vs. being agile
Příliš velká koncentrace na praktiky a na dodržování metodiky je v praxi asi nejčastějším problémem. Předpokládejme, že většina lidí se někdy setkala s týmem, který každý den poctivě držel stand-up meeting. Po zhruba 40 minutách, kdy dva členové týmu horlivě diskutovali nad jednou konkrétní částí aplikace, již zbytek týmu posedával (někdo na stole, jiný opřený o zeď), ale všichni (nejspíš s výjimkou těch dvou diskutujících) by se nejraději vrátili ke své práci. Jenže šéf řekl, že stand-up meetingy jsou pro všechny povinné.
Není důležité, zda se drží stand-up meetingy, používá backlog, odhaduje ve story pointech nebo v hodinách. To tým nečiní agilním. Agilní je, pokud je schopen rychle reagovat na změny, a pokud je schopen pružně dodávat funkční software v krátkých iteracích. Rovněž nefunguje napodobování praktik jiných týmů – co funguje jednomu týmu, druhému fungovat nemusí. Nebuďte jako domorodci na ostrovech v Indonésii, kteří po druhé světové válce napodobovali chování spojeneckých vojáků. Stavěli letištní budovy a letištní plochy ze svých materiálů, dokonce byla spatřena osoba letištního operátora (domorodec se sluchátky z kokosových ořechů). To vše dělali v naději, že se díky tomu na nebi opět objeví obří ptáci a budou shazovat krabice s jídlem (tzv. cargo cult).
6. Agile jako silver-bullet
Agile nevyřeší všechny problémy, kterými organizace trpí. Agile dokonce nevyřeší žádné problémy, kterými organizace trpí. Pouze je učiní natolik viditelnými, že si uvědomíte, že s ní budete muset opravdu něco udělat. Projekt dodávaný agilně může rovněž skončit neúspěchem, stejně jako projekt dodávaný pomocí tradičních metodik. Hlavní výhodou však je, že agilně dodávaný projekt skončí neúspěchem daleko dříve. Je určitě dobré vědět, že projekt nepovede k cíli již po měsíci stráveného času, než po roce a půl. Stává se, že agilní přístup byl použit i v situaci, kdy vůbec nebylo jasné, jaký produkt se má vlastně budovat a proč – tedy kdy naprosto chybělo jakékoliv zadání. Pokud není ani základní představa o problému který má být řešen, je lepší projekt zastavit, nebo redefinovat. Agilní přístup se navíc nehodí pro všechny situace, neměl by být brán jako dogma nebo jako náboženství. Jsou problémy, které může být vhodné řešit tradičními metodikami – například hodně prointegrované systémy (typicky frontend, integrační platforma a několik backendových systémů). Toto lze samozřejmě řešit i agilně například s předsazením několika analytických sprintů, ale pokud v tomto případě tradiční metodiky fungují, pak nemusí být důvod cokoliv měnit. Řada firem dnes úspěšně používá bimodální IT, kdy například core systémy jsou dodávány waterfallem a ostatní aplikace agilním přístupem.
7. Agile a fixování rozsahu
Firmy se často ptají, zda lze agilně dodávat v režimu fixed time & fixed price. Navzdory častým negativním zkušenostem to jde – stačí, pokud si zákazník uvědomí rozdílná očekávání, která ve světě softwaru vždy panují (myšleno mezi zákazníkem a vývojářem)a skutečně zapojí kompetentního product ownera. Pak může v agilní dodávce získat oproti běžnému přístupu obrovskou přidanou hodnotu. Tradiční rozpor v očekáváném byznysu (co si kupuje) a IT (co má dodat) řeší ve waterfall modelu formální analýza, psaná specifikace a kontrakt. V agilním světě to vše musí nahradit vzájemná komunikace a důvěra. Firmy by si tak měly nastavit prostředí kontrolované důvěry – v agilním světě oblíbený model team lease, kdy tým sedí přímo on-site u zákazníka se zapojením jeho interních lidí, na které tak přirozeně přechází projektové know-how a zároveň mají vhled a kontrolu nad každou částí projektu. Jen tak je možné v projektu pracovat s neměnnou pravdou agilního světa – ať už si obě strany na začátku domluví jakýkoliv rozsah projektu, bude se vždy měnit. Rozsah projektu je často jen rámec na úrovni definovaných user stories, kdy cca 80 % dokáže tým poměrně přesně odhadnout. Bohužel zbylých 20 % může mít i několikanásobně vyšší pracnost (což ale platí i pro waterfall projekty). S rozsahem projektu je tedy potřeba pracovat a v případě problémů musíte být připraveni z něj škrtat. Za to vše ovšem zákazník získá na konci nejen produkt šitý přesně na míru neustále se vyvíjejícím potřebám a řešení, do kterého tak říkajíc vidí, ale také vyladěný proces, jak software dále rozvíjet a přizpůsobovat neustále se měnícímu trhu.
Jak z toho ven? Pokud s některým z uvedených problému trpíte, položte si prosím nejprve dvě jednoduché otázky: 1. Víme, proč to vlastně chceme řešit agilně? 2. Jaká je naše motivace abychom to dělali tímto způsobem?
Pokud je odpověď na tyto otázky v duchu: „Náš IT ředitel byl na prezentaci od Gartnerů a tam se o tom mluvilo,“ pak je velmi pravděpodobné, že neuspějete. Pakliže v odpovědi prosakují alespoň střípky typu: „Chceme být schopni rychle reagovat na změny, nechceme dopředu analyzovat všechny detaily, ale máme představu produktu, který budujeme,“ či „Chceme si produkt průběžně osahávat a přizpůsobovat,“ potom jste sami na velmi dobré cestě. S problémy které máte, si můžete nechat od někoho externího poradit. Ale je důležité si uvědomit, že motivaci pro tuto kulturní změnu, vám nikdo zvenčí nepřinese.
Pavel Krayzel
Senior Delivery Manager, Profinit
Článek vyšel v časopise IT Systems 10/2016