Být při vývoji webů a aplikací za každou cenu agilní, nebo to raději spláchnout starým dobrým vodopádem? Jednoznačnou odpověď na tuto otázku vám nikdo nedá (a když dá, nevěřte mu). Dobrá zpráva je, že si nemusíte nutně vybrat jednu metodiku a tu druhou jednou pro vždy zavrhnout. Nejlepší je poznat obě a využít podle situace to nejlepší z nich.
Pojďme si oba přístupy k vývoji softwaru, tedy agilní a tradiční, nejdříve stručně představit, bez ambic poskytnout jejich vyčerpávající popis. To by totiž nebylo na článek, ale na knihu. Jde spíš o to zachytit, co je pro tyto dva přístupy typické a v čem se zásadně liší. Už to vám dá tušit, kdy se který hodí lépe.
Obrázek bude mnohem barvitější, pokud jste se už v minulosti - v jakékoli roli - nachomýtli u redesignu webu, vývoje mobilní aplikace nebo třeba spuštění nového e-shopu. Ve chvíli, kdy si do "kulis" těchto metodik dosadíte sami sebe, své kolegy, úkoly, které jste při těchto projektech řešili, a problémy, které vás při tom potkaly, budete mít dost dobrou představu o silných a slabých stránkách obou metodik.
Pro metodiky založené na "waterfall" přístupu je typické detailní rozplánování projektu na etapy proložené milníky. Etapy na sebe navazují, nelze přeskakovat. Dokud se příslušný milník neschválí, nejde se dál.
To "hlavní" se odehraje na samém začátku - je nutné naprosto detailně specifikovat, co se má vyvinout. Velkou roli tedy hraje podrobná zadávací dokumentace od klienta, ve které by mělo být popsáno úplně vše. Vývojáři dokumentaci analyzují, navrhnou řešení a kvalifikovaně odhadnou jeho pracnost. V této fázi obvykle dojde k vyjednávání. Klient to potřebuje dřív / levněji. Co lze ze scope projektu vynechat? O jaké možnosti se tím klient připraví? Výsledkem je pak projekt definovaný 3 základními pilíři:
Ve chvíli, kdy je takto projekt odsouhlasen, je tím zafixována konečná podoba požadovaného výstupu. Teď už zbývá maličkost - dodat ho :-) Klient schvaluje jednotlivé milníky, jinak mu ale nezbývá, než sedět se založenýma rukama a napjatě očekávat den D, kdy mu má být celé dílo převázané mašlí předáno k akceptačnímu testování.
Jistě už vás napadají různá úskalí tohoto přístupu, pojďme si ale projít nejdříve jeho výhody.
Výhodou pro klienta je, že od začátku ví, co, kdy a v jaké kvalitě dostane. To je typický požadavek zadavatelů v oblasti státní správy. V praxi klient obvykle schvaluje jednotlivé etapy - wireframy, grafiku, nakódované stránky... Krok za krokem je vše posvěceno, vše tedy nasvědčuje, že se ubíráme správnou cestou. To je vhodné pro méně inovativní projekty, kdy je cesta i konečný cíl dobře zmapovaný.
Nevýhody jsou zřejmé: Základem úspěchu je opravdu kvalitní zadání, kterému obě strany rozumí stejně. Důležitá je i součinnost klienta a pečlivé schvalování jednotlivých milníků. Jinak může být klient na konci zklamán ("Takhle jsme to nechtěli") a v krajním případě může dojít i ke sporům, co bylo zadáno a zda tomu výstup odpovídá. Také kvalifikovaný odhad dodavatele musí být opravdu kvalifikovaný, s velkou přesností zohledňující náročnost projektu a schopnosti týmu vývojářů. I přes nejlepší snahu mívají velké projekty tendenci překročit své pevně vymezené časové mantinely.
A nedejbože, aby si klient něco v průběhu projektu rozmyslel nebo se změnila situace na trhu. Změnový požadavek projekt stopne, je třeba analyzovat, co přesně takový požadavek znamená a jaké další funkcionality může ovlivnit. Následně je nutné přepsat dokumentaci, upravit scope, harmonogram a nacenění celého díla. Flexibilní tedy waterfall opravdu moc není. Proto také projekt řízený touto metodikou pravděpodobně mine všechny příležitosti, které se otevřou cestou - jak ušetřit, jak to udělat lépe, rychleji, jak předběhnout konkurenci.
Odpůrci agilních metodik jim vyčítají, že působí, jako by se vše šilo horkou jehlou. Ostatně název té nejznámější z agilních metodik, scrumu, by se do češtiny dala přeložit jako skrumáž, mlýn nebo tahanice. Ale právě proto je tu metodika, aby agilním přístupům k vývoji dala potřebný řád.
I v případě agilního vývoje je potřeba řešit otázky ceny, času a rozsahu. Netrvá se ale na 100procentním zadání. Klient se musí rozhodnout, co je pro něj v dané fázi nejdůležitější. Je to termín spuštění? Nebo se nesmí za žádnou cenu přešvihnout rozpočet? Nebo (čistě hypoteticky) klient trvá na perfektní realizaci svého vysněného díla - bez ohledu na peníze a čas? V celém průběhu může klient ovlivňovat, jak má výstup vypadat, může ho ladit i měnit. Stále má přehled, kolik se čerpá rozpočtu. Může prioritizovat, co má být hotovo dříve a na co si počká. Vystupuje v klíčové roli tzv. product ownera.
Všechna dílčí zadání na základní i nadstavbové funkcionality klient sepíše v jednotlivých user stories. Příkladem takového user story může být: Zákazník se chce přihlásit do zákaznické sekce, aby tam mohl sledovat své poslední objednávky a stav svých bodíků. Tato zadání se před zahájením projektu i v jeho průběhu hromadí v tzv. backlogu. Scrum master je konzultuje se svým týmem i s Product Ownerem. Každé story tak postupně nabírá konkrétnější obsah a rozměry.
Práce vývojářů je rozdělena nejčastěji do zhruba 14denních oken, tzv. sprintů. Podle počtu členů týmu a doby trvání má sprint určitý omezený rozsah. Před každým sprintem se tedy z backlogu podle priorit vytáhnou user stories, kterými je sprint naplněn a která by měla jako celek dávat smysl. Na konci sprintu pak product owner obdrží ucelený kus díla, který lze otestovat a ideálně rovnou nasadit.
Na začátku tvoří každé user story třeba jen pár vět, postupně se prohlubuje, přibývá detailů. Když je dostatečně specifické, vývojáři ho "nacení" pomocí tzv. story points. Proč ne hodinami nebo man-days, jak jsme zvyklí z waterfallu? Je to snaha o odhad bez ohledu na individuální schopnosti programátora (kodéra, grafika), jen rychlým porovnáním s obdobnými úkoly, které už tým v minulosti řešil. Otázka nezní: Za jak dlouho bys tu vzdálenost Jardo uběhl? ale Jak daleko to Jardo podle tebe je?
Scrum master pak není žádný otrokář (hyperkorektní čtenáři stejně odešli už u předchozího mezititulku), jeho rolí je udržovat tým motivovaný a zajistit, aby všichni věděli, co se děje, kdo na čem pracuje a jak se mu daří. Agilní tým by měl držet spolu, jeho členové si mají pomoci, aby společně doručili klientovi to, k čemu se pro daný sprint zavázali. Scrum master řídí diskusi, motivuje lidi a dbá na předávání zpětné vazby všemi směry. K tomu slouží i tzv. sprint retrospective, tedy jakési zhodnocení právě dokončeného sprintu. Agilní metodiky jsou sympatické v tom, že nejsou perfekcionistické. Nemusí být vše na první dobrou dokonalé, ale je důležité se poučit.
Přínosem agilních metodik je možnost průběžně upřesňovat zadání, prioritizovat úkoly a tím optimalizovat náklady. Hodí se hlavně tam, kde už je ustálena vizuální stránka díla a řeší se hlavně jeho funkcionality, tedy na aplikace, interní systémy a další software.
Pomocí agile lze rychle reagovat na změny podmínek, jako jsou nečekané škrty v rozpočtu nebo změny na trhu. Je ideální cestou, jak rychle něco vyvinout, otestovat, získat feedback a hned zapracovat změny. Hodí se tedy nejlépe na inovativní projekty, kde přesně nevíme, jak má cílový stav vypadat.
Agilní nebo tradiční vývoj? Umíme obojí a víme, jak oba přístupy používat smysluplně. A třeba je i kombinovat. Třeba tak, že na začátku si stanovíme milníky a půjdeme klasickou cestou waterfallu. Stejně by to k němu sklouzlo - wireframy, grafika a další vizuální záležitosti se nejlépe řeší v iteracích. Když máme vizuální stránku věci odsouhlasenou, můžeme projekt přepnout do scrumu a agilně vyvíjet jeho funkcionality.
Když se pustíte do vývoje s námi, ten správný přístup společně promyslíme hned na začátku. Dostali jste se ve vývoji do slepé uličky? Rádi to s vámi proberme při nezávazné konzultaci a poradíme vám, jak z ní ven. Můžeme vám slíbit, že čas vývojářů využijeme hospodárně a metodiku zvolíme podle toho, co přinese lepší výsledek. Ne podle toho, co zní trendy.
Zdeněk Poroda
Account manager (Project Manager / SCRUM master)
Zdeněk vystudoval vysokou školu v oboru ICT projektového řízení a mezi Pixmany získal mnohaletou praxi na webových projektech středního a většího rozsahu. Nespí na vavřínech a svou kvalifikaci si dál rozšiřuje, což potvrdil i mezinárodní certifikací SCRUM master v agilním projektovém řízení. "Cest k cíli je vždycky víc. Proto klientům nabízím různé možnosti řešení a mluvím naprosto upřímně a otevřeně. Důvěra je jen jedna," popisuje Zdeněk svůj přístup k práci. ...
Copyright PIXMAN 2024
