Teskně hučí Niagara

Klasickým vývojovým postupem, jehož kořeny sahají do šedesátých let, je vodopádový přístup. V něm projekt kaskádovitě prochází jednotlivými fázemi analýzy požadavků, návrhu, implementace, testování (validace), integrace atd. Jako první formální popis vodopádového modelu je často citován článek, který publikoval v roce 1970 Winston W. Royce. Již v jeho článku přitom vodopádový model sloužil jako příklad chybného, nefungujícího modelu.
Mezi problémy vodopádového přístupu je zejména zdlouhavé uvádění novinek na trh zapříčiněné souběžným vývojem mnoha funkcionalit produktu. Z prodlužování uvedení novinek v život však pramení nespokojenost zákazníků, daná mimo jiné pomalejší odezvou na hlášené chyby a podněty ke zlepšení. Navíc se situace u zákazníka může v době mezi specifikací požadavků a odevzdáním výsledného produktu výrazně změnit, což vede k další nespokojenosti. Zákazník sice dostane přesně to, co je uvedené ve smlouvě, ale to rozhodně neznamená, že dostane to, co chce. Počáteční specifikace, jakkoli je podrobná a obsáhlá, nikdy nemůže zachytit kompletní funkčnost a dojem z výsledného programu. Výsledně je často zklamaný jak zákazník, tak i vývojový tým, který pracoval nejlépe, jak mohl, ale ani tak zákazníka neuspokojil – ostatně ani nemohl.
Oblibu vodopádového modelu v praxi částečně vysvětluje jeho uchopitelnost z hlediska finančního a právního řízení projektu, které se podobá například řízení projektů ve stavebnictví nebo strojírenství. Možnou zdánlivou výhodou pro zákazníka je odstínění od vývoje. Jenže vývoj softwaru má mnohem více stupňů volnosti než stavba a dialog je základem opravdu dobrého díla.

Jak zastavit vodopád

Přejít z vodopádového systému vývoje na agilní ale zdaleka není jednoduché. Nejde totiž jen o formální změnu. Agilní vývoj mění myšlení. Podívejme se na to, jak přechod z vodopádu na agilní vývoj probíhal ve společnosti LMC, kde se týká osmdesáti vývojářů – specialistů, designerů a programátorů.
K rozhodnutí změnit způsob vývoje dospělo vedení naší firmy již na sklonku předchozího roku. Silným impulzem bylo mimo jiné působení Martyho Cagana, uznávaného světového odborníka na oblast produktového vývoje, přímo na půdě LMC.
Záhy se rozběhl rozsáhlý program Rediscovery zaměřený na nutnost změny nejen v rámci IT, ale celého produktového vývoje. Při hledání bodu, ze kterého změnu začít, nakonec došli členové týmu k definování základních hodnot, které každý náš produkt musí splňovat:

• hodnota pro zákazníka – aby ho uživatelé chtěli využívat,
• použitelnost – aby ho byli schopni snadno ovládat a využít všech jeho možností,
• proveditelnost – aby naše firma byla schopna produkty v daném čase a s danou technologií úspěšně vyvinout.

Po vyhodnocení možných cest, jak tohoto cíle dosáhnout, se jako nejvhodnější nástroj v daných podmínkách ukázalo nasazení metodiky SCRUM.

Who is who?

Její praktické nasazení zcela změnilo podobu vývojových týmů. Výraznou změnou bylo přerozdělení produktových týmů tak, aby existovalo co nejméně sdílených zdrojů (shared resources). Kvůli splnění výše zmíněných třech požadavků, které musí splňovat každý náš produkt, vznikly tři důležité role – produktový manažer, UX tým a lead engineer.
Produktoví manažeři jsou primárně zodpovědní za vyhledání tzv. minimum viable product , tedy vymyšlení jádra produktu. To musí obsahovat klíčové funkce, doplňkové rysy, které uživatelům mohou pomoci, ale nejsou zásadní pro daný účel, se do produktu dodávají až později, na základě zpětné vazby od uživatelů.
Výraznou roli sehrávají interaction designéři, kteří navrhují podobu produktu a společně s ostatními členy „user experience“ týmu testují jeho použitelnost a ověřují možnosti přijetí produktu na trhu. Tým testující uživatelskou zkušenost je součástí vývojového cyklu produktu hned na počátku.
Nově došlo také k vytvoření rolí lead engineerů, kteří jsou garantem za oddělení Technology (dříve IT). Lead engineer poskytuje konzultaci a připomínkuje produkt ještě před samotným Scrumem.

Svatá trojice

Na začátku vývoje nového produktu vstupuje do hry tzv. svatá trojice: product manager (PM), lead engineer (LE) a interaction designer (ID). Musí se shodnout na zadání z hlediska produktových požadavků, uživatelské přívětivosti a proveditelnost (feasibility). Nad zadáním musí panovat naprostá shoda, selhání jednoho je selháním všech.
Následuje vlastní vývoj podle metodiky Scrum. V první fázi připraví PM kompletní zadání a podklady. Poté vstupuje do hry ID, jenž se účastní zákaznických prezentací (customer demos). Upozorňuje na dílčí odchylky a úpravy, které je ještě nutné provést. Poslední instancí je LE, který dohlíží na technickou proveditelnost, koordinuje vývoj a reviduje kód.
Důležité je co nejvíce automatizovat celý proces technického sestavování softwarových komponent. Jedním z klíčových požadavků je minimalizace lidských zásahů při sestavování balíků kódů. Manuální proces je pomalý a vzhledem k přítomnosti lidského faktoru náchylný k chybám. Při častém sestavování, které plyne ze samé podstaty agilního vývoje, je tedy manuální sestavování i velmi drahé. Při jeho využití klesá efektivita, rychlost, a výrazně se tak snižuje přidaná hodnota celého procesu častého uvolňování nových verzí a testování.
V této oblasti máme za sebou úspěšnou automatizaci testování a na pořadu dne je automatizace jednotlivých buildů.

Sprintujeme k dokonalosti

Nejmenší jednotkou, během které se odehrává vývoj, je takzvaný sprint. Na jeho začátku je přesná specifikace toho, co má během sprintu vývojový tým udělat a nikdo – kromě LE – do tohoto zadání nemá právo zasahovat. V LMC trvá sprint čtrnáct dní. Již po prvních pěti sprintech je cítit, že rychlá zpětná vazba od uživatelů přináší výsledky. Podstatou je věci realizovat, ne o nich jen mluvit.

Myslete jinak

Klíčem k úspěchu byla již zmíněná změna v myšlení všech zainteresovaných. Je potřeba uvažovat ne o maximalizaci počtu funkcí, ale naopak o jejich minimalizaci tak, aby výsledný produkt byl stále použitelný. Často bývá z pohledu zákazníka výhodnější spokojit se s produktem pokrývajícím požadavky z osmdesáti procent, který vznikl za jeden den, než stoprocentní funkcí produktu získanou na základě pětinásobného úsilí. Důležité je uvést produkt na trh co nejdříve v použitelné podobě a implementovat pouze nezbytné funkce. Zadání pro další rozšíření získává tým díky zpětné vazbě od reálných uživatelů v reálném světě. I zástupci Technology musí přemýšlet z hlediska zákazníka (nikoli zadavatele!).
Konkrétní příklad? Pro uživatele bude pohodlnější, když vývojový tým použije našeptávač místo comboboxu. Při té příležitosti je lákavé vylepšit již existující implementaci našeptávače. V rámci efektivního vývoje může být převzata například jako freeware od třetí strany. Ale opravdu to zákazník v tuto chvíli potřebuje?
Nezbytná je rovněž aktivita ze strany programátorů – ti nesmí pracovat bezmyšlenkovitě podle zadání, ale realizovat ho co nejlépe za co nejméně prostředků. Základem kvalitní práce je pokora před uživatelem a jeho připomínkami. Pro ty, kdo pouze programují, není agilní programování vhodnou volbou.

Závěr

Při přechodu z vodopádu na agilní techniky je nutné vypořádat se i se stávající architekturou aplikací. Pokud jsou aplikace vzájemně úzce provázané (což je obvyklý požadavek uživatele), často vyžaduje změna v kódu jedné z nich změny i v ostatních. Z toho plyne, že jednotlivé týmy nejsou samostatné, a to je na cestě k agilitě vážnou překážkou. Naprostou nutností je tedy tým, který dohlíží na celkovou architekturu aplikací.
Přechod s sebou přináší nemalé režijní náklady, změna je náročná pro celou firmu a jde o běh na dlouhou trať. Rozhodně nepočítejte s tím, že za měsíc bude vše hotovo.
Přínosy jsou ale nepochybné – vyšší spokojenost uživatelů, pozitivní změna v myšlení vývojářů a koneckonců výrazné snížení rizika, které plyne z dlouhého a drahého vývoje velkých programových balíků bez průběžné korekce uživatelů. Kdybychom se o přechodu k agilnímu vývoji rozhodovali znovu, rozhodli bychom se stejně.

Ondřej Mysliveček
Autor působí na pozici head of product ve společnosti LMC.