V UniCredit Bank nedávno stáli před složitou situací. Zbývaly čtyři měsíce do začátku hlavní prodejní sezóny a očekávaný nový produkt byl stále jen v zárodku. Bylo jasné, že tradičním způsobem řízení není šance jeho dokončení stihnout. Klasický vodopádový model vyžaduje detailně popsané zadání všech kroků a funkcí, interní sladění obchodní specifikace a její přetavení na vývojovou specifikaci. Plynou dlouhé týdny, než se vůbec začne cokoliv dít. Proto přišlo rozhodnutí zkusit cestu agilního vývoje ve spolupráci se společností Trask. Agile umožňuje velice rychle začít pracovat na prvních úkolech a podrobnější zadání chystat postupně „za běhu“.

„Namísto podrobné technické specifikace jsme na začátku měli jednoduchou definici úspěchu – dodání ve stanoveném čase a zákaznickou spokojenost. Dohodli jsme pevný rozsah funkcionalit, ale detaily se upřesňovaly až v průběhu. Zatímco vývoj pracoval na jedné části, probíhala příprava dalších. Klíčové bylo ustanovení týmu a jeho mandátu. Při agilním vývoji nelze čekat na něčí rozhodnutí týden nebo dva, takže jsme pojmenovali klíčové kompetence a dle toho sestavili realizační tým. Stanovili jsme si pravidlo rozhodování do jednoho dne,“ popsala Eva Juhásová, Head of Multichannel Sales ve společnosti UniCredit Bank Czech Republic and Slovakia.

Společná práce namísto čekání na výsledek

Při agilním vývoji je dodavatel s klientem ve velmi těsném vztahu a fungují v rámci společného týmu. Jeho členové jsou v každodenním kontaktu při řešení jednotlivých úkolů, proto je nutné mít k dispozici vhodné nástroje pro online spolupráci i vyhrazený prostor pro vzájemné setkávání. Díky tomu pak zadavatel vidí vývojářům „pod ruce“, takže má přehled o postupu prací a kvalitě produktu, a tvůrci produktu zase vidí klientovi „do hlavy“, což umožňuje efektivní řízení očekávání. Neustále také mohou ověřovat míru vzájemného porozumění – jak se říká, nejhorší věta vývojáře je „Já jsem myslel…“. A protože celý tým sdílí jednotné měřítko úspěchu a definici cíle (např. určitý počet prodejů), nerozchází se cíle businessu a IT.

„Správný výběr partnera je půlka úspěchu. Při agilním vývoji se z něj stane téměř partner životní. Musíte se na něj spolehnout, měli byste proto mít stejný zájem a ideální je spolupracovat dlouhodobě. Důvěra je skutečně zásadní, ne všechno je totiž na papíře a často je dohoda jen ústní. Má to samozřejmě i své nevýhody – naším poučením je, že dokumentace musí vznikat průběžně. My jsme to nechali na konec a bylo těžké pak všechny předchozí dohody a rozhodnutí zahrnout. Ale pořád platí, že software je nadřazen vyšperkované dokumentaci. Projekt i tak naplnil naše očekávání z hlediska kvality a rychlosti dodání funkčního řešení,“ dodala Juhásová.

Když je rychlost zásadní

S plně on-linovou půjčkou bez papírů přišla na českém trhu jako první Česká spořitelna, při spoléhání na tradiční metody vývoje by už však mohlo být pozdě. Namísto rozsahu díla tak byly na začátku definovány jen cíle, namísto dokumentace byl příslib. Trask společně s partnerem EY proto musel přijít s novým způsobem, jak dodat produkt zákazníkovi. V těchto případech lze uplatňovat různé alternativní business modely – success fee, sdílení rizika nebo exkluzivitu.

 Oproti full-scope zakázce je zadaný jen konečný cíl, vše nadbytečné odpadne a nedělají se podružné věci jen proto, že je někdo na počátku zadal do dokumentace. „Heslem agilního vývoje je: úspěch je, když něco nemusíme udělat. Důležitým aspektem agile přístupu je také transparentnost a těsná spolupráce celého týmu,“ vysvětlil Jiří Soukeník, Executive Director Trask.

Důležité je také poznamenat, že agilní přístup lze kombinovat s vodopádovým modelem. Pokud je u některých technických subdodávek k dispozici přesné zadání, není důvod toho nevyužít. A tam, kde je prostor pro inovaci, se pak uplatní agile. Produktový tým navíc málokdy získá opravdu všechny potřebné kompetence a čas od času musí spoléhat na práci jiných, „neagilních“ oddělení či dodavatelů. Pak nezbývá než dobře plánovat termíny, domluvit se na předávání po dávkách. Externí závislosti je nutné řešit vždy jako první, aby vznikl dostatečný prostor na vzájemnou synchronizaci.

„Na základě řešení jednoho problému a konkrétního produktu u nás vznikla celá platforma, koncepce pro další digitální produkty. Lidé se naučili komunikovat a spolupracovat, změnilo se jejich vnitřní nastavení. Objevili jsme nové digitální procesy, ale také schopnost učit se z neúspěchu a rychle na něj reagovat. Zpětnou vazbu z uživatelského testování jsme byli schopni promítat do produktu na denní bázi,“ shrnul své zkušenosti Lukáš Pudil, Head of Digital Sales České spořitelny.

Plánování a měření agilního projektu

I na agilní dodávku se dá dívat očima projektového řízení. Základní časovou jednotkou, se kterou pracuje SCRUM (jedna z nejpopulárnějších agilních metodik), je sprint. Ten obvykle trvá od dvou do čtyř týdnů a začíná plánováním konkrétního úkolu, pro který v tu chvíli již musí být k dispozici dostatečné zadání. Končí funkčním „výrobkem“ (aplikací), který je předveden zákazníkovi. Sprinty se v průběhu vývoje celého produktu pravidelně opakují, čehož lze využít k optimalizaci práce – v každém následujícím sprintu se dá poučit z předchozích a průběžně se tak zlepšovat.

„Vývoj v dnešní době je střelba na pohyblivý cíl. Projekt je vždy plný překážek, je třeba učit se z chyb a přizpůsobovat se. Jelikož agilní vývoj probíhá v úzkém týmu, je také důležitá týmová dynamika a sehranost, která nepřijde hned. Pokud například v průběhu projektu přidáte nového člena, může to efektivitu týmu namísto zvýšení na dlouho zpomalit,“ poradil Petr Fanta, Senior Project Manager Trask.

Opakující se sprinty mají vždy stejnou délku, což umožňuje odhadovat plánovaný termín dokončení – vyhodnocuje se, zda tým „sprintuje“ dostatečně rychle k cíli. Na základě zbývající práce a dosavadní rychlosti jednotlivých sprintů lze modelovat optimistické i pesimistické scénáře a případně provádět korekce.

Společnosti ale nesmí zapomínat, že ani odevzdáním produktu dodavatelem proces nekončí. Produkt je totiž v souladu s agilními principy používán již od tzv. minimální verze, která je obvykle dále rozvíjena a obohacována o další funkce. Podle toho je třeba plánovat a připravit si prostor a peníze pro další vývoj, protože základní produkt zákazníky neuspokojí na dlouho.

Agilní architektura

I když je do agilního vlaku možné naskočit za jízdy, v ideálním případě je potřeba, aby se agilní přístup zrcadlil už v architektuře a plánovalo se s ním od začátku. Zatímco zažitý model vývoje totiž funguje ve vrstvách, kterým se věnují oddělené týmy (business, aplikace, data, prezentace…), v agile jsou tyto vrstvy propojené do vertikál, funkčních celků. Martin Pitra z Trasku vyjmenoval pět principů agilní architektury, kterých je dobré se od počátku držet:

1. Rozpad na vertikály. Architekt musí mít pohled shora, znát obchodní souvislosti a závislosti (konzultace s business analytikem). Nezačíná se od technologií, ale svrchu.
2. Princip konzistence. Podobná zadání by se měla řešit stejným způsobem pro všechny vertikály. Je třeba odmítat přílepky a nezanášet do aplikace dočasná řešení, která tam nakonec obvykle zůstanou.
3. Přímočarost. Navrhovat věci jen tak akorát složité a jít k jádru problému. Přináší to rychlejší a intuitivnější implementaci. Kód má zrcadlit daný problém a nesnažit se řešit věci přehnaně univerzálně. Při návrhu nepředvídejme budoucnost– stejně se netrefíme a budeme jen dělat komplikovanější řešení.
4. Držet se předpokladů. Při návrhu změn je třeba se zamýšlet, zda se pohybujeme v původních předpokladech. Je třeba upozornit zákazníka na požadavky, které jsou mimo původní rámec a vyžadují třeba změnu technologie.
5. Úplnost informací. Architekt musí mít dostatek informací, aby navrhl řešení dané vertikály. A to na základě schválených a definovaných předpokladů.