Waterfall vs. Agile: Jakou metodologii zvolit pro své projekty Redmine?

Někdy slyším výkřiky jako "Gantt je mrtvý," "musíš to řídit agilním způsobem," nebo dokonce "Projektové řízení je mrtvé." Přestože je řada z nich jen příkladem marketingového svinstva, často se setkávám s manažery projektového portfolia, scrum mastery a dalšími profesionály projektového managementu, kteří chtějí vážně polemizovat o Agile vs. Waterfall (Gantt) techniky. Tento příspěvek je stručným úvodem do tématu.

Železný trojúhelník řízení projektů

Železný trojúhelník je ve skutečnosti velmi jednoduchým znázorněním klíčových prvků potřebných pro úspěšné plánování projektu. Rozsah, čas a náklady/zdroje. Zdroje jsou jedinými a/nebo kritickými prvky ceny v mnoha průmyslových odvětvích. Lidé jsou nejcennějším aktivem, které nelze jednoduše zvětšit, snížit nebo znásobit. Podobně strojní zdroje mají určitou výrobní kapacitu a nelze je změnit pouhým kliknutím.

Easy Redmine - Trojúhelník železa #1

Jak ale železný trojúhelník zapadá do celkového obrazu? Velmi pohodlně. Nabízí nám jednoduchou, ale účinnou odpověď, kdy bychom měli plánování metodiky Waterwall využít a kdy naopak zvolit agilní přístup.

Řízení projektu Redmine Waterfall

Metodika Waterfall se nejlépe hodí k projektu, jehož rozsah je přesně definován a je klíčovým prvkem projektu, jako je výstavba nemovitostí, plánování konferencí, popř. Snadná implementace softwaru Redmine.

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 atd. Čas projektu je omezujícím faktorem buď absolutně (např. konference) nebo téměř absolutně (např. implementace softwaru). Při přesně definovaném rozsahu je hlavním úkolem projektového manažera nebo portfolio manažera rozvrhnout všechny typy zdrojů na časové ose napříč paralelně běžícími projekty a zohlednit požadovanou posloupnost akcí (úkolů) v jednotlivých projektech.

Zvažte napří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ů mohou zabránit zedníkům v dokončení vlastních úkolů. Jakmile je beton dostatečně pevný, může být již nalezen na jiném místě.

Easy Redmine - Trojúhelník železa #2

Agilní řízení projektů Redmine

Agilní přístup je vhodný pro projekty, kde Čas je pevně definován, Zdroje jsou rozhodujícím faktorem a Rozsah je předmětem plánování (upřednostňování). Dobrým příkladem může být vývoj softwaru (sprinty), publikační činnost (datum vydání časopisu/novin) nebo marketingový obsah (kampaň).

Technika: mistři skrumru nebo plánovači v podobných rolích upřednostňují úkoly pro příští sprint. Obvykle má master scrum různá nevyřízená místa a desky pro různé typy zdrojů, jako jsou vývojáři, kteří chtějí opravit chyby a zpracovávat požadavky na nové funkce, a na druhé straně novináře v politických nebo sportovních médiích.

Easy Redmine - Trojúhelník železa #3

Co to znamená?

Je zřejmé, že celá problematika řízení projektů se stále obrací kolem železného trojúhelníku. Operační plánování se zaměřuje pouze na různé části stejné věci. Takže co z toho můžeme čerpat?

1. Prakticky v každé organizaci nalezneme typy projektů, u kterých je třeba používat obě techniky projektového řízení Pro vytváření efektivních pracovních procesů. Jedna metodika není lepší než druhá, ale pouze řeší různé výzvy.
   
   
2. Kvalitní plánování zdrojů spojená s časovou osou je nezbytná pro každý projekt Waterfall, zejména pro plánování portfolia projektů. Totéž platí pro Easy Redmine projektů.
   
   
3. Řízení agilních projektů: Správa priorit se obvykle provádí pomocí různých nástrojů. Často je problém s přesnou alokací zdrojů pro konkrétní nevyřízené položky. V tomto ohledu vám tedy vřele doporučuji Mapujte a přidělujte své zdroje důsledně. Například vývojář softwaru může být použit pro více nevyřízených záležitostí současně (např. opravy chyb vs. požadavky na funkce ve stejném jazyce). Bez definování kvantitativní alokace zdrojů pro nevyřízené položky však nebudete moci plánovat prioritní dodávky a scrum master bude muset neustále řešit nesrovnalosti mezi těmito prioritami. Dalším nepříjemným důsledkem bude opožděné vydání nových klíčových funkcí produktu, jako jsou opravy chyb nebo požadavky na funkce, které zneužívají zdroje strategického rozvoje.

Kombinace obou metod řízení

Jak můžete vidět na obrázku níže, máme základní projekt Waterfall, který zahrnuje plán vývoje softwaru, který ukazuje sekvence a závislosti. Týmy zapojené do tohoto projektu (prodejci, techničtí autoři) však mohou řídit své vlastní dodávky ve svém oddělení nejen, jak ukazuje tento příklad, ale také agilním způsobem.

Snadné Redmine Gantt - Příklad vodopádu