Začnu hned jednou krutou pravdou, abych dál neplýtval vaším časem: Pokud nemáte schopné lidi v týmu, agile (potažmo SCRUM) vás rozhodně nezachrání. Když jsme si v minulém díle představovali možnosti vývojové metodiky, agile metodika vypadala jako svobodný postup, kde se i výraznější nedostatky snadno schovají.

Možná se to nezdá, ale tato metoda má daleko větší nároky na vývojáře a designéry než klasický Waterfall. Jak to? Od lidí se totiž očekává vyšší míra disciplíny, samostatnosti a zodpovědnosti.

Klasický ortodoxní přístup k managementu vývoje softwaru pochází z doby non-IT projektového managementu. Původní úvaha evidence-based decision making procesu má správné kořeny. Nicméně projektoví manažeři mohou mít nebezpečnou tendenci zavádět více a více metrik, KPI a kvantitativních ukazatelů měřících produktivitu při tvorbě softwarového produktu. Nakonec se tak můžete dostat do situace, kdy máte skvělé výsledky založené více na počtu dodaných reportů než na reálných výsledcích.

Jak pracovat s Agile

Agile metodika funguje v rámci krátkých časových úseků, takzvaných sprintů. Každý člen týmu má jasně přiřazené úkoly a odpovědnost za odevzdání své části. Oproti tomu Waterfall metoda pracuje s většími časovými úseky, takže případnou nekompetenci či nedostačující schopnosti odhalíte mnohem později. Všechny činnosti navíc běží současně, a proto je mnohdy náročné hodnotit konkrétní výstupy jednotlivců. Složitější je i koordinace předávání úkolů, protože obvykle zpracováváte velký kus softwaru najednou.

Například si naplánujete, že za šest měsíců musíte odevzdat daný software. Ale časem zjistíte, že si kód mezi sebou předávají tři různí lidé a je pro všechny příliš složité výsledný zmatek v rámci vymezeného času opravovat. Nebo zjistíte, že je kód nepoctivě napsaný: jsou v něm kličky a workaroundy. Tímto způsobem vznikají technické dluhy a ve výsledku je software o to dražší, než kdyby se psal načisto a poctivě už od začátku.

Tolik k neduhům Vodopádového modelu. Ale ještě než se pustíte do zásadních projektových změn, zapamatujte si: nemá smysl zavádět SCRUM, pokud nemáte schopné zaměstnance a zadavatele.

Že potřebujete opravdu skvělé vývojáře nemusím dále rozvádět. Ale proč zmiňuji zadavatele? Protože od zadání projektu se zadavatel stává majitelem produktu a nedílnou součástí SCRUM týmu. Očekává se od něj, že umí dobře definovat své požadavky a na práci se s dodavatelem dobře domluví.

V eManu máme šikovné lidi, takže si můžeme za agile přístupem stát a tuto metodiku nabízet. A jak už jsem zmiňoval: snadno zjistíte, zde mluvíme pravdu, protože v téhle metodice je úspěch jednoduše měřitelný na základě dodaného funkčního softwaru. Takže všechna řešení problémů začínají a končí jedinou otázkou: Umíte? Ano / Ne.

Na druhou stranu ale agile metodiku také mohou zneužívat velké společnosti a překrucovat si ji po svém. Příště si povíme, jak poznáte, že něco nehraje.

Čtěte dále: When Waterfall Principles Sneak Back Into Agile Workflows (HBR)