Néha olyan kiáltásokat hallok, mint például "Gantt halott", "az agilis módon kell vezetni", vagy akár "a projektmenedzsment halott". Bár sokuk csak marketing szemét példája, gyakran találkozom projektportfólió-menedzserekkel, scrum mesterekkel és más projektmenedzsment szakemberekkel, akik komolyan vitatkoznak az Agilis vs. Vízesés (
Gantt) technikák kérdéséről. Ez a bejegyzés rövid bevezetést nyújt a témába.
A projektmenedzsment vas háromszöge valójában nagyon egyszerű ábrázolása a sikeres projekttervezéshez szükséges kulcsfontosságú elemeknek. A hatókör, az idő és az ár/erőforrások. Az erőforrások az árban az egyetlen és/vagy kritikus elemek sok iparágban. Az emberek a legértékesebb eszközök, amelyeket nem lehet egyszerűen növelni, csökkenteni vagy szaporítani. Hasonlóképpen, a gépi erőforrásoknak bizonyos termelési kapacitása van, és nem lehet egyszerűen egy kattintással megváltoztatni.
De hogyan illeszkedik a vas háromszög az átfogó képbe? Nagyon kényelmesen. Egyszerű, de hatékony választ kínál arra, hogy mikor kell a Vízesés módszer tervezését használni, és mikor válasszunk egy
agilis megközelítést.
A Vízesés módszer leginkább olyan projektekhez illik, amelyek hatóköre pontosan meghatározott, és a projekt kulcsfontosságú eleme, például ingatlanépítés, konferencia-tervezés vagy
Easy Redmine szoftverimplementáció.
Technika: A projekt hatóköre meghatározott (rögzített). Példánkban ez azt jelenti, hogy nem változtathatom meg az ingatlanom ablakainak számát, nem változtathatom meg a konferencia helyét vagy témáját stb. A projekt időkorlátot jelent, vagy abszolút (pl. konferencia), vagy majdnem abszolút (pl. szoftverimplementáció). Egy szorosan meghatározott hatókörrel rendelkező projektmenedzser vagy portfóliómenedzser fő feladata, hogy ütemezze az összes típusú erőforrást a párhuzamosan futó projektek idővonalán, és figyelembe vegye az egyes projektekben szükséges cselekvéssorrendet (feladatokat).
Gondoljunk például egy ház építésére: a cement szállításáért felelős munkásoknak időben be kell fejezniük a munkájukat, mert a cementhiány okozta késések megakadályozhatják a téglafalazókat a saját feladataik elvégzésében. Amint a beton elég szilárd, már másik helyen is megtalálhatók.
Az agilis megközelítés hasznos olyan projektek esetén, ahol az idő szilárdan meghatározott, az erőforrások meghatározó tényezők, és a hatókör tervezés tárgya (prioritizálás). Jó példa lehet a szoftverfejlesztés (sprintek), a kiadási tevékenység (magazin/újság kiadási dátuma) vagy a marketing tartalom (kampány).
Technika: A scrum mesterek vagy hasonló szerepekben dolgozó tervezők prioritizálják a következő sprint feladatait. Általában a scrum masternek különböző backlogjai és scrum táblái vannak különböző típusú erőforrásokhoz, például a fejlesztőknek, akik hibákat javítanak és új funkciókra vonatkozó kéréseket kezelnek, és a másik oldalon a politikai vagy sport média újságíróinak.
Mit jelent ez?
Nyilvánvalóan a projektmenedzsment teljes kérdése még mindig az "vas háromszög" körül forog. Az operatív tervezés csak különböző részeire összpontosít ugyanannak. Tehát mit vonhatunk le ebből?
- Majdnem minden szervezetben találunk olyan projekt típusokat, ahol hatékony munkafolyamatok létrehozásához mindkét projektmenedzsment technikát használni kell. Egyik módszer sem jobb a másiknál, csak különböző kihívásokra ad választ.
- Az idővonalhoz kapcsolódó erőforrások minőségi ütemezése minden Waterfall projekt esetében alapvető fontosságú, különösen a projektportfólió tervezésekor. Ez igaz az Easy Redmine projektekre is.
- Agil projektmenedzsment kezelése: A prioritások kezelése általában különböző eszközökkel történik. Gyakran probléma merül fel a konkrét backloghoz való pontos erőforrás-allokációval. Ezért ebben az összefüggésben határozottan javaslom, hogy konzisztensen térképezze fel és allokálja erőforrásait. Például egy szoftverfejlesztőt több backloggal is használhat egyszerre (pl. hibajavítások vs. funkciókérések ugyanabban a nyelvben). Azonban a prioritási szállítások ütemezése nem lehetséges a backlogokra vonatkozó kvantitatív erőforrás-allokáció meghatározása nélkül, és a scrum masternek folyamatosan fel kell oldania ezeket a prioritásbeli eltéréseket. Egy másik kellemetlen következmény az új kulcsfontosságú termékfunkciók, például hibajavítások vagy funkciókövetelmények késleltetett kiadása lesz, amelyek kihasználják a stratégiai fejlesztési erőforrásokat.
Mindkét menedzsment módszer kombinációja
Az alábbi képen látható, hogy van egy alapvető Waterfall projektunk, amely magában foglal néhány szoftverfejlesztési tervet, amely sorrendeket és függőségeket mutat. Azonban a projektben résztvevő csapatok (értékesítők, technikai írók) nem csak ebben az példában, hanem agilis módon is kezelhetik saját szállításaikat a saját részlegeikben.

Easy Redmine Gantt - Waterfall projekt példa