Waterfall vs. Agile: kterou metodiku zvolit pro vaše projekty?

Agile vs. Waterfall - v tomto příspěvku vám nabídnu diskusi o dvou metodikách projektového řízení, jaké jsou jejich výhody, jak vám mohou pomoci a jak je kombinovat.

Občas slýchám výkřiky jako "Gantt je mrtvý" nebo "musíš to řídit agilně", nebo dokonce "projektové řízení je mrtvé".

Třebaže mnohé z toho je jen příklad špatného marketingu, často se setkávám s manažery projektových portfolií, scrum mastery a dalšími profesionály projektového řízení, kteří chtějí vážně polemizovat na téma agile vs. waterfall (Gantt). Tento příspěvek je stručným úvodem do tématu.

Trojimperativ projektového řízení

Trojimperativ projektového řízení je ve skutečnosti velmi jednoduchá reprezentace klíčových prvků potřebných pro úspěšné plánování projektu. Rozsah, čas a cena/zdroje. Zdroje jsou v mnoha odvětvích jediným a/nebo kritickým prvkem ceny.

Lidé jsou nejcennějším aktivem, který nelze jednoduše zvýšit, snížit ani vynásobit. Obdobně strojové zdroje mají určitou výrobní kapacitu a nelze je měnit pouze jednoduchým kliknutím.

Easy Project - Trojimperativ projektového řízení #1

Jak ale trojimperativ projektového řízení zapadá do celkového obrazu? Velice příhodně. Nabízí nám totiž prostou, avšak efektivní odpověď, kdy bychom měli využívat plánování metodikou Waterfall a kdy naopak zvolit agilní přístup.

Projektové řízení metodikou Waterfall

Metodiku Waterfall nejvhodněji užijeme na projektu, jehož rozsah je přesně definován, a je klíčovým prvkem projektu, tedy například při výstavbě nemovitosti, plánování konference či implementace softwaru Easy Project.

Technika: Rozsah projektu je definován (pevně stanoven). V našem příkladu to znamená, že nemohu změnit počet oken v mé nemovitosti, nemohu změnit místo nebo předmět konference apod. Doba projektu je omezujícím faktorem buď absolutně (konference), nebo téměř absolutně (implementace softwaru).

S pevně definovaným rozsahem je hlavním úkolem projektového manažera či správce portfolia naplánovat všechny typy zdrojů na časové ose, napříč paralelně běžícími projekty a s ohledem na požadovanou posloupnost akcí (úkolů) v jednotlivých projektech.

Vezměme si za příklad výstavbu domu: pracovníci odpovědní za dodávku cementu musí dokončit svou práci včas, protože zpoždění způsobené nedostatkem cementových zdrojů může zabránit tomu, aby zedníci dokončili své vlastní úkoly. Ve chvíli, kdy je beton pevný, mohou se již nacházet na jiném staveništi.

Easy Project - Trojimperativ projektového řízení #2

Agilní řízení projektů

Agilní přístup je vhodné užívat na projektech, kde je pevně definovaný čas, zdroje jsou určujícím faktorem a rozsah je předmětem plánování (prioritizace). Vhodným příkladem může být například vývoj softwaru (sprinty), publikační činnost (datum vydání časopisu/novin) či marketingový obsah (kampaň).

Technika: scrum masteři či pracovníci obdobných rolí plánují priority úkolů pro následující sprint. Obvykle má scrum master odlišné backlogy a scrum boardy pro různé typy zdrojů, například vývojáře starající se o opravy chyb a žádosti o nové funkce a na druhé straně novináře v politických či sportovních médiích.

Easy Project - Trojimperativ projektového řízení #3

Co z toho vyplývá?

Je zřejmé, že celá problematika projektového řízení se stále otáčí kolem trojimperativu. Operační plánování se jen více zaměřuje na různé části téže věci. Co z toho tedy můžeme vyvodit?

Prakticky v každé organizaci bychom nalezli typy projektů, kde je zapotřebí použít obě dvě metodiky projektového řízení pro vytváření efektivních pracovních procesů. Jedna metodika není lepší než druhá, zkrátka jen řeší různé výzvy.
Kvalitní plánování zdrojů spojených s časovou osou je zásadní pro každý projekt typu Waterfall, a zvláště pak pro plánování portfolia projektů. To samé platí v projektech Easy Project.
Řízení agilních projektů: Správa priorit se obvykle provádí prostřednictvím různých nástrojů. Často je problém přesné vyčlenění zdrojů pro konkrétní backlog. Takže v tomto směru doporučuji důsledně mapovat a vyčleňovat své zdroje. Například vývojář softwaru může být využit větším počtem backlogů současně (např. chyby vs. požadavky na funkce v témže jazyce). Bez definování kvantitativního přidělování zdrojů k backlogům však nebudete schopni naplánovat prioritní deliverables a scrum master bude muset neustále řešit nesrovnalosti mezi těmito prioritami. Dalším nepříjemným důsledkem bude zpožděné vydávání nových klíčových funkcí produktu, jako jsou opravy chyb nebo požadavky na funkce, které vytěžují zdroje strategického rozvoje.

Kombinace obou metodik řízení

Jak vidíte na obrázku níže, máme základní projekt typu Waterfall, který obsahuje nějaký plán softwarového vývoje, v němž jsou zřejmé sekvence a závislosti.

Týmy, které se na tomto projektu podílejí (obchodníci, dokumentaristé), však mohou vlastní dodávky ve svém oddělení řídit nejen tak, jak je uvedeno na tomto příkladu, ale i agilní cestou.