Z existujících přístupů se nám dosud nejvíce osvědčilo agilní řízení, které je velkým tématem pro jednotlivé týmy, malé firmy, startupy i korporace. V posledních letech se mu intenzivně věnuje i Komora projektových manažerů, která pořádá na toto téma přednášky, panelové diskuse a workshopy. Dalšími oblastmi, které považuji za důležité zmínit, je cloudifikace, DevOps a automatizace, konkrétně testování, kontrola kvality kódu a jeho nasazování. To jsou základní cesty, kterými je dobré se hlouběji zabývat.

Co je to agilní manifest a proč by ho měl znát i klient

Agilní manifest jsou základní principy, kterými by se měli řídit nejen vývojáři a projektoví manažeři, ale znát by je měl i klient. Za nosnou myšlenku manifestu považuji důraz nejen na vývoj jako takový, ale i na přebírání zodpovědnosti za hodnotu a přínos produktu. Hlavními body jsou: upřednostňování jednotlivců a interakcí před procesy a nástroji, funkčního softwaru před obsáhlou dokumentací, spolupráce s klientem před vyjednáváním o smlouvě a reakce na změnu před sledováním plánu.

Metodiky samy o sobě samozřejmě nejsou všemohoucí, důležitý je hlavně mindset. Jak klient, tak vývojáři by si měli hlavně sladit základní představu o tom, jak má produkt vypadat, ale nesnažit se ho dokonale navrhnout od začátku. Nikdo totiž při vývoji nedokáže předvídat, co bude v praxi fungovat. Dávno se proto nehraje na obsáhlou dokumentaci a zadání, které byly v podstatě vždy nedostatečné. Naopak, upřednostňuje se prototypování, iterativní vývoj, PoC (Proof of Concept, tedy ověření koncepce) a MVP (Minimum Viable Product čili základní životaschopný produkt). Snaha je zkrátka vytvářet menší celky a rovnou je nasazovat do provozu, aby se ověřilo, zda nápad či myšlenka funguje. Iterativní vývoj pak zabezpečuje pravidelnou kontrolu ve spolupráci s klientem. Ta probíhá vždy, když vývojáři dokončí iteraci, a přijde s funkční částí produktu. Zároveň se tím posiluje důvěra a vzájemné vztahy.

Tento přístup se snaží podporovat například společnost Atlassian se svými nástroji, které z těchto metodik vychází. Zejména se soustřeďuje na snadné zadávání, správu a distribuci úkolů, stejně jako na podporu sprintů a práci s backlogem (prioritizovaný seznam úloh pro vývojáře). Opět je ale třeba připomenout, že samotné nástroje nejsou nikdy samospasitelné a důležité je nastavení týmu a jeho členů, aby je sami přirozeně dokázali používat.

Mohutné systémy jsou přežitek

Dávno již neplatí, že je nutné stavět celý systém naráz. Na začátku je naopak žádoucí vyvinout malou aplikaci, na které se vyzkouší, zda bude produkt funkční a použitelný pro zákazníky i uživatele systému. Vzniká tak MVP, který je v podstatě prototypem. A tomu odpovídá i složení týmů, které jsou malé, autonomní a mají za dodání části produktu zodpovědnost. Tým musí být schopen si po dobu sprintu převzít zadání a dodat ho. Jakým způsobem to provede, je jenom na něm. Tým může během vývoje využívat na dořešení některých otázek různé role, jako je business analytik, architekt nebo i zákazník. Následně vyvíjí produkt v rámci sprintu, který trvá typicky týden až tři týdny. Pokud je třeba něco v produktu upravit nebo rozšířit jeho funkce, vyřeší se to během dalších sprintů. Právě to zajistí rychlou reakci na změny požadované zákazníkem.

V rámci vývoje produktu pak hraje zásadní roli automatizace. Jako příklad lze uvést automatickou analýzu zdrojového kódu, která byla ještě donedávna silně opomíjena. Díky ní se často přijde na chyby, které způsobují problémy ve funkčnosti a ve výkonu aplikace. Typicky by se na ni měly zaměřit firmy, které vytváří produkty a chtějí udržet kvalitu po celou dobu jejich životnosti. Dále je to automatizace samotného testování. Obvykle stačí několik automatizovaných testů a za týden už z nich má klient výsledek v podobě test reportu. Za každým nasazením části systému se udělá další test, který pokryje nové funkce. Třeba u jednoho produktu nám automatizovaný test ušetřil až 19 nasazení jedné verze. Každé nasazení produktu přitom může trvat v řádu několika hodin a zatěžuje zbytečně klienta i uživatele.

Bez kvalitních základů to nejde

Jestli se aplikace staví z jednotlivých cihel, pak architektura představuje stavební projekt. Nástroje, postupy a kultura DevOps jde často ruku v ruce s cloudem. Zkušenosti expertů na DevOps se tak uplatní právě v projektech, kde se provádí migrace na cloud. Kombinují totiž v sobě know-how vývojářů, architektů i administrátorů. Tím, že ovládají kombinaci těchto oborů a znají specifika cílové platformy, dokážou jej nastavit tak, aby jednotlivé aplikace fungovaly co nejefektivněji. Cloudifikace je velký trend, který časem zcela odstraní držení serverů ve firmách.

Druhou možností je přímo tvorba cloudových aplikací. Pro ty je třeba správně cloud nakonfigurovat a získat co nejvíce muziky za co nejméně peněz. Samotný přechod do cloudu tedy nemusí být samospasitelný, pokud není proveden odborně. Rostoucí oblibu mají serverless (bezserverové) aplikace, které nepotřebují rezervovaný serverový výkon. Normálně zůstávají neaktivní a vezmou si jej pouze v případě, když potřebují provést výpočet nebo komunikaci. Poté se zase vypnou. Navíc cloud umožňuje snadné škálování výkonu – a to jak vertikální (což znamená navýšení výpočetního výkonu serveru), tak horizontální (spuštění dalších instancí téhož serveru či komponenty). Díky tomu lze snadno řešit zvýšené požadavky na flexibilitu a výkon. Často to bývá doménou startupů, když potřebují zvýšit dočasně výkon kvůli testování nového produktu či řešit postupný či skokový nárůst počtu uživatelů.

Jako hlavní trendy tedy vidím zaměření se na funkčnost a efektivitu produktu po stránce vývoje, stejně jako na jeho byznysovou hodnotu. Klíčová je proto zejména kompetence a převzetí odpovědnosti IT firmy, která produkt dodává, stejně jako interakce a spolupráce ze strany klienta. Ten může průběžně sledovat, jak práce vývojářům roste pod rukama, a vyhodnocovat pravidelně reporty, jestli plní jeho očekávání. Tomu se přizpůsobuje i velikost týmů, které se snaží fungovat autonomně a soustředit se pouze každý na svou část úkolu, aby dodaly co nejkvalitnější práci. Pokud tohle obě strany dodrží, minimalizují tím riziko již v průběhu vývoje a zajistí, že výsledek splní očekávání obou stran.

Boris Zovčák Autor článku působí jako COO vývojářské společnosti BOOTIQ. Firmu spoluzaložil a stará se o její slovenskou pobočku – BOOTIQ SK. Je také viceprezidentem a marketingovým ředitelem Komory projektových manažerů a současně vede její slovenskou část.