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 ne lehet egyszerűen egy kattintással megváltoztatni. De hogyan illeszkedik a váš háromszög az átfogó obrázek? 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 projektkhez 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
Snadná implementace Redmine. 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ípusu erőforrást a párhuzamosan futó projektekvé idővonalán, és figyeksoregessel s det (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 késések megakadályozhatvégát a tééslaiké okotják a tééslaiké oko. Amint a beton elég szilárd, mar massik 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 oldakét a politika kések mánik, vagy sport média újságíróinak.
Co to znamená?
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 projektkre 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éseketbeli. Egy massik 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ő Vodopád 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