Vízesés vs. Agile: Melyik módszertant választjuk a Redmine projektekhez?

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 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öket, nem lehet egyszerűen növelni, csökkenteni vagy szaporítani. Hasonló, 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 egyet agilis megközelítést. A Vízesés módszer legjobb 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 teljesen teljesen (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 párhuzamosan futó projektek idővonalán, és 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 a munkájukat, mert a cementhiány okozta késések kizárhatják a téglafalazókat a saját feladataik elvégzésében. Amint a beton elég szilárd, már a 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. jelenleg 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 vagy a politikai 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 ugyanannak. akkor mit vonhatunk le ebből?

1. Majdnem minden szervezetben találunk olyan projekt típusokat, ahol hatékony munkafolyamatok létrehozásához mindkét projektmenedzsment technikát kell használni. Egyik módszer sem jobb a másiknál, csak különböző kihívásokra ad választ.
   
   
2. 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ésénél. Ez igaz az Easy Redmine projektekre is.
   
   
3. Agil projektmenedzsment kezelése: A prioritások kezelése általában különböző eszközökkel történik. Gyakori 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 fel és allokálja térképeit. Például egy szoftverfejlesztőt több backloggal is használhat egyszerre (pl. hibajavítások vs. funkciókért 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 funkciókövetelmények késleltetett kiadása lesz, használjuk vagy használjuk a stratégiai fejlesztési erőforrásokat.

Két menedzsment módszer választásja

Az alábbi képen látható, hogy van egy alapvető Waterfall projektünk, amely magában foglal néhány szoftverfejlesztési tervet, amely sorrendeket és függőségeket mutat. Azonban a projektben saját résztvevők (értékesítők, technikai írók) nem csak ebben az példában, hanem agilis módon is kezelhetik saját részlegüket.

Easy Redmine Gantt - Waterfall projekt példa