Waterfall vs. Agile: Kterou metodologii zvolit pro vaše projekty v Redmine?

Někdy slyším výkřiky jako "Gantt je mrtvý," "musite to řídit agilním způsobem," lub nawet „projektový management je mrtvý”. Ačkoli mnoho z nich jen příkladem marketingového odpadu, často se setkávám s manažery portfela projektů, scrum mastery i dalšími odborníky na projektový zarząd, kteří chtějí vážně discutovat o Agile vs. Waterfall (Gantta) techników. Tento příspěvek je stručným úvodem do tématu.

Železný trojúhelník projektového Managementu

Železný trojúhelník je vlastně velmi jednoduchou reprezentací klíčových prvků potřebných pro úspěšné plánování projekt. Rozsah, čas a náklady/zdroje. Zasoby jsou jediné a/nebo kritické prvky ceny v mnoha odvětvích. Lidé jsou nejcennějším aktivem, které nelze jednoduše zvýšit, snížit nebo násobit. Stejně tak strojové zdroje mají určitou výrobní kapacitu a nelze je změnit jednoduchým kliknutím.

Łatwy Redmine - trójkąt żelaza #1

Ale jak se železný trojúhelník hodí do celkového obrazu? Velmi podhodlně. Nabízí nám jednoduchou, ale účinnou odpověď na to, kdy bychom měli použít plánování metodikou Waterwall a naopak, kdy zvolit agilní přístup.

Zarządzanie projektem Redmine Waterfall

Metodika Waterfall je nejvhodnější pro projekt, jehož rozsah je přesně definován a je klíčovým prvkem projekt, jako je například výstavba nemovitostí, plánování konferencí nebo oprogramowanie implementacyjne Easy Redmine.

Technika: Rozsah projekt je defininován (fixní). V našem příkladu to znamená, že nemohu změnit počet oken v mé nemovitosti, nemohu změnit místo nebo téma konferencja atd. Čas projekt je omezujícím faktorem buď absolutně (např. konferencja) nebo téměř absolutně (např. implementace softwaru). S pevně definovaným rozsahem je hlavním úkolem projektového manažera nebo manažera portfolia naplánovat všechny typy zdrojů na časovou osu při běhu paralelních projektů a zohlednit požadovanou posloupnost akcí (úkolů) v jednotlivých projekte rozdz.

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

Łatwy Redmine - trójkąt żelaza #2

Redmine Agilní projektový management

Agilní přístup je užitečný pro projekty, kde čas je pevně definován, zdroje jsou rozhodujícím faktorem a rozsah je předmětem plánování (ustalenie priorytetu). 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: scrum mastery nebo planovači v podobných rolích prioritizují úkoly pro další sprint. Obvykle má scrum master různé backlogy a scrum boardy pro různé typy zdrojů, jako jsou vývojáři hledající opravy chyb a řešení požadavků na nové funkce a na druhé straně novináři v politických nebo sportovních médiích.

Łatwy Redmine - trójkąt żelaza #3

Co to znaczy?

Zjevně se celá problematika řízení projektů stále točí kolem železného trojúhelníku. Operační plánování se zaměřuje pouze na různé části téhož. Co z toho můžeme vyvodit?

1. V téměř každé organizaci najdeme typ projektů, kde je nutné použít obě techniky řízení projektů pro vytvoření efektivních pracovních procesů. Jedna metodologie není lepší než druhá, pouze řeší různé výzvy.
   
   
2. Kvalitní plánování zdrojů Spojené s časovým plánem je nezbytné pro každý Waterfall projekt, zejména pro plánování portfolia projektů. Stejné platí pro projekty łatwy Redmine.
   
   
3. Řízení agilních projektů: Řízení priorit se obvykle provádí pomocí různých nástrojů. Často istnieje problem s přesným přidělením zdrojů pro konkrétní backlog. Proto v této souvislosti důrazně doporučuji, abyste mapovali a přidělovali své zdroje konzistentně. Například softwarový vývojář může být použit s více backlogy současně (např. opravy chyb vs. požadavky na funkce ve stejném jazyce). Bez defininování kvantitativního přidělení zdrojů do backlogů však nebudete schopni plánovat prioritní dodávky a scrum master bude muset neustále řešit rozpory mezi těmito prioritami. Dalším nepříjemným důsledkem bude zpoždění vydání nových klíčových produktových funkcí, jako jsou opravy chyb nebo požadavky na funkce, které využívají strategiczne vývojové zdroje.

Kombinace obou metoda řízení

Jak můžete vidět na obrázku níže, máme základní Waterfall projekt, který zahrnuje plánování softwarového vývoje ukazující sekvence a závislosti. Týmy zapojené do tohoto projektu (prodejci, techničtí spisovatelé) však mohou spravovat své vlastní dodávky ve svém oddělení nejen tak, jak je ukázáno v tomto příkladu, ale také agilním způsobem.

Easy Redmine Gantt - projekt Příklad Waterfall