Vízesés projektmenedzsment - Manapság a legtöbb informatikai csapat az agilis projektmenedzsment rendszerek bevezetésére törekszik. De amit végül csinálnak, az Agile Projektmenedzsment rendszert alkalmazzák projektjeikhez. Ez a hagyományos projektmenedzsment rendszerek (úgynevezett Waterfall Project Management Systems) kombinációját jelenti, az agilis menedzsment alapelveivel kombinálva, amint azt az eredeti Agile Manifestó részletezi.
Mivel az egész világon több projekt foglalkozik az agilis projektmenedzsment gyakorlatokkal, ez azt jelenti, hogy véget ér a vízesés projekt menedzsmentje? Vajon minden informatikai projekt agilis projektmenedzsment lesz?
A különféle modellek - köztük az Agile - megértése és az Ön helyzetéhez legmegfelelőbb modell használata érdekében fontos, hogy először megértse, mi szól a hagyományos, a Waterfall Project Management Model nevű projektmenedzsment-rendszerről.
A vízesés projekt menedzsment modelljét, amelyet a munkafolyamat jellege miatt neveztek el, az alábbiak jellemzik:
- A végterméket először nagyon részletesen vizualizálják.
- Ezután a munkafolyamat szakaszai sorrendben kerülnek végrehajtásra:
- Követelmények és elemzés
- Tervezés
- Végrehajtás
- Tesztelés
- Telepítés
- Karbantartás
- A projekttervnek bolondnak kell lennie, mivel ha a sorozat egyik szakasza befejeződik, a fejlesztők nem láthatják újra ugyanazt a helyet, ha a tervezést újra megkezdenék.
- Kevés lehetőség van a változtatásokra vagy hibákra, és a projekt tervet gondosan be kell tartani.
A Waterfall Project Management modell eredete:
Az informatikai ipar korai szakaszában még nem volt konkrét modell a szoftverfejlesztéshez.
Így az ipar elfogadta a gyártási és építőiparban alkalmazott szekvenciális munkafolyamat-modellt. Ezeknek az iparágaknak jól meghatározott munkafázisai voltak, és kidolgozták azt a modellt, amely kielégítette a szigorú költségkontroll szükségességét. Tehát a hardveripar modelljét alkalmazták a szoftveriparban.
Winston W Royce először mutatta be ezt a modellt 1970-ben, de nem használta a „Waterfall Project Management” kifejezést. Valójában hibás modellként mutatta be a modellt. A modell képi ábrázolása lépcsőzetes vízesésnek tűnt. Thomas E. Bell és TA Thayer később a „vízesés” kifejezést használta 1976-os, „Szoftverkövetelmények: valóban probléma?” Című cikkükben, és a szó megmaradt.
Ennek a modellnek számos változata létezik. A Waterfall projektmenedzsment modellben általánosan alkalmazott hat különálló fázist az alábbiakban ismertetjük. A projekttől függően azonban két szakasz kombinálható.
Vegyük például az iskolaépítés példáját a vízesés projektvezetési modelljének jobb megértése érdekében.
-
Követelmények és elemzési szakasz:
Először is pontosan tudnunk kell, mit tervezünk. Ehhez a következőket szeretnénk:
- Vegyen le részletes megbeszéléseket az ügyféllel
- Próbáljon világosan megjeleníteni a terméket a legfrissebb részleteivel
- Elemezze, hogy mely hardver és szoftver összetevőkre van szükség
- Sorolja fel a részleteket, amelyek tartalmazzák: a termék által megoldandó problémát, az ügyfelek korlátait, a teljesítmény szintjét és a már létező rendszerekkel való kompatibilitást.
- Hasonló termék esettanulmányainak lefolytatása.
- Vegye figyelembe az érdekelt felek követelményeit
- Sorolja fel a termékkövetelményekről szóló dokumentum specifikációit, amely a következő lépés bemeneti elemét képezi.
Az iskolaépítésre vonatkozó példánkban ebben a lépésben felsoroljuk az osztálytermek számát, az építéshez szükséges anyagokat, az igényelt embereket, a már meglévő infrastruktúrát. Megjegyezzük azt is, amit az iskola vezetése megkövetel (irodahelyiség, dolgozói szoba), és mit igényel a diákok (jobb WC-k, játszóterek)
-
Tervezés:
A tervezési szakaszban mindazt, amit az első szakaszban megvilágítottak, tervrajzzá teszik.
Az informatikai projektekben ez a következő meghatározásából áll:
- A használt hardver
- A használandó szoftverplatform, ideértve a helyi vagy felhőalapú telepítést
- A szoftver architektúrája, beleértve a létrehozandó különféle összetevőket és modulokat
- A projekt sikeres működéséhez szükséges bemenetek
- Várható eredmények (ideális esetben ez szinkronizálódik a korábbi szakaszban részletezett követelményekkel)
Kétféle tervezés létezik egy szoftverprojektben:
- Logikai tervezés
- Fizikai tervezés
Logikai tervezés:
Ez magában foglalja azokat az alapadatokat és folyamatokat, amelyeket a projektbe beépítenek. Bemutatja az űrlapok és jelentések tervezését, az interfész és az adatbázis tervezését. Például egy vonatjegy-webhely esetében ez a terv meghatározza, hogy az egész folyamat hogyan fog működni: a képernyő, amelyre az utazó beírja adatait, és hogy az adatok hogyan kerülnek az adatbázisba, és azt is, hogy milyen típusú adatbázis tárolja ezeket az adatokat.
Fizikai tervezés:
Ez a fizikai adatbázis, a programok és folyamatok, valamint az elosztott rendszerek kialakítását érinti. Ez a logikai tervezés után történik, és magában foglalja a „hogyan” a projekt megvalósítását: a hardvert, a platformot, amelyen kifejlesztésre kerülnek, a különféle adatbázisokat, képernyőket és a használni kívánt űrlapokat stb.
-
Végrehajtás:
- Itt történik a szoftver / rendszer tényleges fejlesztése.
- E szakasz bemenete az előző szakasz által megadott tervezési előírások.
- A kimenet egy vagy több termékösszetevő, amely specifikációk szerint épül fel, hibakeresésre, tesztelésre és integrálásra kerül a rendszer architektúrájának kielégítésére.
- Ezt a szakaszt általában a programozókból, interfész-tervezőkből és más szakemberekből álló fejlesztőcsoport gondoskodja, és az alkalmazott eszközök fordítók, hibakeresők, tolmácsok és médiaszerkesztők.
- Ez a szakasz általában a maximális időt vesz igénybe, és fontos a folyamatok és a tervezés gondos nyomon követése. A terv módosítása ebben a szakaszban nehéz a Waterfall Projektmenedzsment területén.
- Több csapatot bevonó nagyprojekt esetén a verzióvezérlés ajánlott a kódfában bekövetkezett változások nyomon követésére, és a hibakezeléshez való visszatérésre az előző pillanatképekre.
- Példánkban: Az épület tényleges építése munkaerő és anyagok felhasználásával történik ebben a szakaszban.
-
Tesztelés:
Tesztelni lehet a termék egészére vagy az egyes alkatrészekre. A „teszt esetek” ellenőrizhetők, hogy a termék az ígérteknek megfelelő módon szállíthasson-e. Lehetséges modulok tesztelése, az integrált termék rendszer tesztelése és elfogadási tesztelés. Az elfogadási tesztelés magában foglalja a termék kiskapuinak a végfelhasználó vagy az ügyfél általi tesztelését. A hibákat a végrehajtó csapat javításának céljából rögzítik. A javítások elvégzése után elkészül egy hivatalos termékdokumentáció.
A példában az iskola infrastruktúráját valószínűleg egy ellenőrző csoport teszteli. Egyes esetekben a tanárokat felkérik, hogy jöjjenek be és használják a helyiségeket visszajelzés nyújtására.
-
Telepítés:
Miután a termék tesztelése minden szempontból befejeződött, a termék forgalomba hozható vagy telepíthető a vevő telephelyén. Ebben a szakaszban a teljes termékdokumentációt is átadják.
Iskolánkban hivatalosan is megnyitják (lehetőleg nagy lövéssel!), És az iskola megkezdi a működést!
-
Karbantartás:
Ebben a szakaszban az informatikai csapat kijavít minden olyan problémát, amelyek felmerülhetnek, amikor az ügyfél ténylegesen elkezdi használni a terméket, vagy ha van termékfejlesztés. A jó dokumentáció a karbantartás gerince. A problémákat a „javításoknak” nevezett, módosító kódokkal orvosolják.
Ha nagyobb változtatásokra van szükség, a projekt új projektként visszatérhet a fejlesztői csapathoz.
Példánkban az iskola rendszeres karbantartást igényel, többnyire infrastrukturális, például hibás elektromos vezetékeket vagy szivárgó fürdőszobákat. Ezeket a problémákat időről időre meg kell oldani.
Mint láthatja, a Waterfall Development Project Management szakaszai különböznek egymástól, és bár általában állandó kapcsolat van az ügyféllel, elsősorban a projekt előrehaladásának, nem pedig a tervezésnek vagy a követelményeknek a megvitatására kell irányulni. A vízeséses projektmenedzsment-modell azonban jó évek óta szolgálja megfelelően az informatikai ipart, és a legtöbb projektnél a szakaszok továbbra is jóak, miközben nem annyira merevek.
Számos olyan projekt van, amelyekre a Waterfall projektmenedzsment modell rendkívül alkalmas.
Milyen projekthez alkalmas a Waterfall Project Management?
Termék meghatározása:
Először is, a végeredménynek (terméknek) a kezdetben jól meghatározhatónak kell lennie. Azok a projektek, amelyekben a terméktulajdonos nem nagyon biztos a kívánt termék pontos specifikációjában, jól követhetik az Agile Management gyakorlatot.
Dokumentáció:
A projektnek dokumentálhatónak kell lennie. A dokumentáció a Waterfall projektmenedzsment modell fontos követelménye. A termékigényeket, a kialakítást és a forráskódot minden szakaszban egyértelműen dokumentálni kell. Ha a csapat eredeti tagjai kilépnek, ez a útmutató a projekt folyamatosságához.
Idő és források:
A termék kiadására nem szabad azonnal sürgetni. Az ütemterveket a projekt elején állítják be, és a csapatnak képesnek kell lennie arra, hogy betartsa azokat. Ezenkívül rengeteg erőforrással kell rendelkeznie a munkaerő és a technológia terén.
Kockázat és bizonytalanság:
A vízesés projektmenedzsment eszközei nem működnek jól a kockázat és a bizonytalanság környezetében. Például a mobilalkalmazás egy olyan típusú termék, amely állandó bizonytalansággal néz szembe az ügyfelek elfogadása és a hasonló alkalmazások versenyképessége szempontjából.
Világosan meghatározott szakaszok:
A rendszer fázisait jól meg kell határozni, mivel sorrendben kell kitölteni, és nem lehetnek átfedések.
Amikor a meglévő szoftver új verziója készül.
Az informatikai területen kívül a Waterfall projektmenedzsment modellt sikeresen alkalmazták olyan hatalmas projektekben, mint például a
- Repülőgép épület
- Infrastruktúra-projektek, például hidak
- Védelmi felszerelések gyártása
- Egészségügyi rendszerek a kórházakban
Az informatikai projektekben a Waterfall Projektmenedzsment különösen alkalmas azokhoz a projektekhez, amelyekhez külső hardver szükséges. Ennek előírásait nem lehet félúton megváltoztatni, mivel ez millió dolláros veszteséget eredményezne.
Amikor a Waterfall Projektmenedzsment hiányosságai nyilvánvalóvá váltak a szoftveriparban, sokat gondolkodtak azon, hogy az informatikai csapatok hogyan tudnak maximális értéket képviselni az ügyfeleknek, miközben biztosítják a munkafolyamat rugalmasságát.
Így megszületett az Agile Projektmenedzsment Rendszer, amelyet a legtöbb szoftvercég elfogad.
Vízesés projekt menedzsment vs agilis rendszerek:
Az Agile Projektmenedzsment rendszer egy rugalmas modell, amely az 1990-es években vált népszerűvé. Ez magában foglalja a projekt felbomlását „mini projektekké”, az úgynevezett sprint-eket, és mindegyikükön önálló munkát. Ez a fajta modell lehetővé teszi a fejlesztők számára a szükséges változtatások gyorsabb beépítését, és nagyon hatékony, ha az ügyfélkör változó.
A vízesés projektmenedzsment lépéseinek pozitívjai a következők:
- Mivel a végtermék teljes egészében ismert, a tervezés és a kivitele egyértelmű.
- A projekt során felmerülő esetleges problémákat a tervezési szakaszban ki lehet oldani; mielőtt bármilyen kódot megírt volna.
- A munka előrehaladásának mérése egyszerű, mivel a szakaszok jól definiáltak.
- A csapat stabilitása ott van, mivel a csapat a projekt végéig megmarad. Agilis esetében a csapat folyamatosan változik, és ehhez bizonyos mértékű kiigazításra van szükség.
- A dokumentáció kiterjedt, így a csapatok könnyebben kezelhetők, ha egy tag távozik.
- A fejlesztők könnyebben használhatják ezt a modellt, mivel könnyen érthető,
- A Követelmények szakasz után a végfelhasználó aktív részvételére csak a tesztelési szakaszban van szükség. Ennek oka az, hogy az összes követelményt menet nélkül megvitatták, és nem hagytak félreérthetőséget.
- A termék egésze fejleszthető, ahelyett, hogy részben fejlesztené.
- A szerződéses és ügyfélkezelési kérdéseket jobban lehet kezelni a Waterfall projektmenedzsment modell keretében.
Az Agile Projektmenedzsment pozitívjai a következők:
- Az ügyfél a ciklus során kapcsolatba léphet a projekt csapatával, és időről időre változtatásokat végezhet a termékben, hogy megfeleljen a változó környezetnek.
- Ha a terméket piaci körülmények miatt hamarosan meg kell engedni, az Agile Projektmenedzsment csapata kiadhat egy alapváltozatot, amely később továbbfejlesztett verzióval is rendelkezhet.
- A rendszer a vásárló szempontjából meglehetősen átlátható, és van egy jó elképzelése arról, hogy a termék mely szakaszában van.
- Mivel az ügyfél biztosítja a szolgáltatások prioritását, a csapat tudja, hogy azokra a szolgáltatásokra kell összpontosítania, amelyek a legnagyobb üzleti értéket képviselik.
- A folyamatnak megvan a maga lendülete.
- A csapatok folyékonyak és rugalmasak, lehetővé téve minden tag véleményét
- A dokumentáció minimális, ezért az idő felszabadul e feladatoktól.
A két év egymás után létező modellje után sokáig nyilvánvaló, hogy:
A Waterfall projektmenedzsment modell hatékony a projektmenedzsmentben, ahol a projekt elvégzése után minimális változások történnek.
Az agilis projektmenedzsment jobban megfelel a termékmenedzsmentnek, ahol fontos, hogy rugalmas legyen a változásokhoz.
Függetlenül attól, hogy a Waterfall projektmenedzsment rendszer a legtöbb informatikai projekt fontos eleme marad. Nem mondhatjuk biztosan, hogy egy adott projekt szigorúan követi az agilis irányítási gyakorlatokat. Általában az agilis alapelveket beépítik az informatikai projektekbe.
Néhány agilis projektmenedzsmentnek van projektmenedzsere, míg egy agilis modellnek szigorúan csak a Scrum Masters van. Ez az Agilis és Vízesés Projektmenedzsment modellek hibrid kombinációja, amelyeket egyesek „Agifall” vagy „Agency Agile” projekteknek hívnak.
A Waterfall projektmenedzsment rendszer népszerűsége annak is köszönhető, hogy a szerződéses és ügyfélkezelési kérdéseket jobban kezelik a Waterfall Project Management módszerek.
Míg egyre több projekt kerül az Agile Projektmenedzsment körbe, és egyre több vállalat látja a rugalmas irányítási modell előnyeit, a Waterfall projektmenedzsment modell népszerűsége kétségkívül csökken.
A közeljövőben azonban nehéz elképzelni a teljesen agilis informatikai projektek jövőjét. És a Waterfall Projektmenedzsment, amely a gyerekcipőben járult hozzá a szoftveriparhoz, a projektmenedzsment néhány eleménél fog élni, legalább néhány évig.
Első képforrás: picjumbo.com
kapcsolódó cikkek
- 6 hasznos munkafolyamat a vízesés projekt menedzsmentjében
- Hatékony tippek a csoportbeszélgetéshez (Szakértői tanácsok)
- A 10 legnépszerűbb projektmenedzsment mítosz megtörtént
- 6 hatékony ok mindenki számára szenvedélyes projektet igényel a munka
- A projektmenedzsment jelentéstételi eszköz legfontosabb öt típusa
- Termékmenedzsment vs Márkamenedzsment - Hasznos különbségek