Waterfall Project Management - Dnes sa väčšina IT tímov zameriava na prijatie agilných systémov projektového riadenia. Nakoniec však zaviedli do svojich projektov systémy agilného riadenia projektov. To znamená kombináciu tradičných systémov projektového riadenia (nazývaných Waterfall Project Management Systems) v kombinácii so zásadami agilného riadenia, ktoré sú podrobne opísané v pôvodnom Agile Manifeste.
Keďže viac projektov po celom svete zahŕňa postupy agilného riadenia projektov, znamená to koniec riadenia projektových vodopádov? Skončia všetky IT projekty ako agilné riadenie projektov?
Aby sme porozumeli rôznym modelom, vrátane Agile, a aby sme použili ten, ktorý najlepšie vyhovuje vašej situácii, je dôležité najprv pochopiť, o čom je tradičný systém riadenia projektov, nazývaný Model riadenia vodopádových projektov.
Model riadenia projektu Waterfall, ktorý je pomenovaný kvôli charakteru procesu pracovných tokov, sa vyznačuje týmto:
- Konečný produkt sa najskôr podrobne vizualizuje.
- Potom sú fázy pracovného toku implementované postupne:
- Požiadavky a analýza
- dizajn
- uskutočnenie
- testovanie
- inštalácia
- údržba
- Plán projektu by mal byť spoľahlivý, pretože keď je fáza v sekvencii dokončená, vývojári ju nemôžu znovu navštíviť bez opätovného začatia plánovania.
- Existuje malý priestor na zmeny alebo chyby a musí sa dôsledne dodržiavať plán projektu.
Pôvod modelu riadenia vodopádových projektov:
V počiatočných fázach IT priemyslu neexistoval žiadny špecifický model pre vývoj softvéru.
Odvetvie tak prijalo model postupného sledu práce používaný vo výrobnom a stavebnom priemysle. Tieto odvetvia mali dobre definované fázy práce a vyvinuli model, ktorý uspokojil ich potrebu prísnej kontroly nákladov. Takže hardvérový priemyselný model bol aplikovaný na softvérový priemysel.
Winston W Royce prvýkrát predstavil tento model v roku 1970, ale nepoužil termín „Waterfall Project Management“. V skutočnosti predstavil model ako chybný. Obrazová reprezentácia modelu vyzerala ako kaskádový vodopád. Thomas E. Bell a TA Thayer neskôr vo svojom článku z roku 1976 použili pojem „vodopád“, „Požiadavky na softvér: Sú skutočne problémom?“ A tento termín sa zastavil.
Existuje niekoľko variantov tohto modelu. Nižšie sú vysvetlené bežne používané šesť rôznych fáz modelu riadenia projektu Waterfall. V závislosti od projektu sa však môžu dve fázy spojiť dohromady.
Uvažujme príklad budovania školy ako príklad na lepšie pochopenie modelu riadenia vodopádových projektov.
-
Požiadavky a fáza analýzy:
Najprv musíme presne vedieť, čo navrhujeme. Za týmto účelom by sme mohli chcieť:
- Uskutočnite podrobné rozhovory so zákazníkom
- Pokúste sa jasne vizualizovať produkt s jeho najmenšími detailami
- Analyzujte, ktoré hardvérové a softvérové komponenty sú potrebné
- Uveďte podrobnosti, ktoré zahŕňajú: problém, ktorý by mal produkt vyriešiť, obmedzenia zákazníkov, úroveň výkonu a kompatibilita s už existujúcimi systémami.
- Vykonajte prípadové štúdie podobného výrobku.
- Zvážte požiadavky každej zúčastnenej strany
- Uveďte špecifikácie v dokumente Požiadavky na produkt, ktorý tvorí vstup pre ďalší krok.
V našom príklade budovania školy sme v tomto kroku uviedli počet tried, materiál, ktorý sa má použiť na výstavbu, požadované osoby, už existujúcu infraštruktúru. Zaznamenali sme tiež to, čo vedenie školy vyžaduje (kancelárska miestnosť, miestnosť pre zamestnancov) a čo študenti požadujú (lepšie toalety, ihriská)
-
prevedenie:
Vo fáze návrhu je všetko, čo bolo vizualizované v prvej etape, prevedené do plánu.
V IT projektoch to pozostáva z definovania:
- Hardvér, ktorý sa použije
- Softvérová platforma, ktorá sa má použiť, vrátane lokálneho alebo cloudového nasadenia
- Softvérová architektúra vrátane rôznych komponentov a modulov, ktoré sa majú vytvoriť
- Vstupy potrebné na úspešné fungovanie projektu
- Výstupy, ktoré možno očakávať (v ideálnom prípade sa to bude synchronizovať s požiadavkami podrobne uvedenými v predchádzajúcej fáze)
V softvérovom projekte prichádzajú do úvahy dva typy dizajnu:
- Logický dizajn
- Fyzický dizajn
Logický dizajn:
To zahŕňa základné údaje a procesy, ktoré budú zahrnuté do projektu. Podrobne popisuje návrh formulárov a správ, návrh rozhrania a návrh databázy. Napríklad pre webovú stránku predaja lístkov na vlak bude tento návrh určovať, ako bude celý proces fungovať: obrazovka, na ktorej cestujúci zadá svoje údaje a ako tieto údaje budú plynúť do databázy, a tiež aký typ databázy tieto údaje uloží.
Fyzický dizajn:
Týka sa to návrhu fyzickej databázy, programov a procesov a distribuovaných systémov. Uskutočňuje sa to po logickom návrhu a bude zahŕňať „ako“ sa projekt uskutoční: hardvér, platforma, na ktorej sa bude vyvíjať, rôzne databázy, obrazovky a formuláre, ktoré sa budú používať, atď.
-
realizácie:
- Tu dochádza k skutočnému vývoju softvéru / systému.
- Vstupom pre túto fázu sú konštrukčné špecifikácie poskytnuté v predchádzajúcej etape.
- Výstupom je jedna alebo viac súčastí produktu zostavených podľa špecifikácií, ladených, testovaných a integrovaných tak, aby vyhovovali architektúre systému.
- O túto fázu sa zvyčajne stará vývojový tím, ktorý sa skladá z programátorov, návrhárov rozhraní a ďalších odborníkov a použité nástroje sú kompilátory, debuggery, tlmočníci a redaktori médií.
- Táto fáza zvyčajne trvá maximálny čas a je dôležité dôsledne sledovať procesy a návrh. Zmeny dizajnu v tejto fáze sú pri projektovaní riadenia vodopádov ťažké.
- V prípade veľkého projektu, ktorý zahŕňa niekoľko tímov, sa odporúča kontrola verzií na sledovanie zmien v stromovom kóde a návrat na predchádzajúce snímky kvôli spracovaniu chýb.
- V našom príklade: Skutočná výstavba budovy pomocou práce a materiálov sa vykonáva v tejto fáze.
-
testovanie:
Testovanie sa môže vykonať pre produkt ako celok alebo pre jednotlivé komponenty. „Testovacie prípady“ sa dajú overiť, aby sa zistilo, či sa produkt dá dodať podľa sľubu. Môže existovať testovanie modulov, systémové testovanie integrovaného produktu a akceptačné testovanie. Akceptačné testovanie zahŕňa testovanie produktu na medzery koncovým používateľom alebo zákazníkom. Chyby sa zaznamenávajú, aby sa implementačný tím odstránil. Po vykonaní opráv sa pripraví formálna dokumentácia k produktu.
V príklade je infraštruktúra školy testovaná pravdepodobne audítorským tímom. V niektorých prípadoch sú učitelia vyzvaní, aby prišli a využili priestory na poskytnutie spätnej väzby.
-
inštalácie:
Akonáhle je testovanie produktu dokončené vo všetkých aspektoch, môže byť produkt prepustený na trh alebo nainštalovaný v priestoroch zákazníka. V tejto fáze sa odovzdáva aj kompletná dokumentácia k produktu.
V prípade našej školy je slávnostne otvorená (pokiaľ možno veľkým záberom!) A škola začína svoju činnosť!
-
údržba:
V tejto fáze rieši tím IT problémy, ktoré sa môžu vyskytnúť, keď zákazník produkt začne skutočne používať alebo keď dôjde k vylepšeniu produktu. Dobrá dokumentácia je chrbtovou kosťou údržby. Problémy sa odstránia úpravou kódov nazývaných „záplaty“.
Ak sú potrebné väčšie zmeny, projekt sa môže vrátiť k vývojovému tímu ako nový projekt.
V našom príklade škola potrebuje pravidelnú údržbu, väčšinou infraštruktúru, napríklad chybné elektrické zapojenie alebo netesné kúpeľne. Tieto problémy je potrebné z času na čas vyriešiť.
Ako vidíte už teraz, fázy riadenia projektu rozvoja vodopádu sú zreteľné a hoci zvyčajne existuje neustála interakcia s klientom, je predovšetkým potrebné diskutovať o priebehu projektu, nie o jeho návrhu alebo požiadavkách. Model riadenia vodopádových projektov však dostatočne dlho slúžil IT priemyslu po mnoho rokov a pre väčšinu projektov sú fázy stále dobré, aj keď nie také rigidné.
Existuje však niekoľko projektov, pre ktoré je model riadenia projektu Waterfall veľmi vhodný.
Na aký druh projektu je projekt Waterfall Project Management vhodný?
Definícia produktu:
Po prvé, konečný výsledok (produkt) musí byť dobre definovateľný na samotnom začiatku. Projekty, v ktorých vlastník produktu nie je veľmi istý presnou špecifikáciou požadovaného produktu, môžu byť v súlade s postupmi agilného riadenia.
dokumentácia:
Projekt by mal byť taký, ktorý je možné dokumentovať. Dokumentácia je dôležitou požiadavkou modelu riadenia projektu Waterfall. Požiadavky na výrobok, dizajn a zdrojový kód by sa mali jasne dokumentovať vo všetkých fázach. Ak pôvodní členovia tímu prestanú, bude to tvoriť návod na pokračovanie projektu.
Čas a zdroje:
Na prepustenie výrobku nesmie byť žiadna naliehavá potreba. Časové limity sú stanovené na začiatku projektu a tím musí byť schopný ich dodržať. Musí existovať aj dostatok zdrojov, pokiaľ ide o pracovnú silu a technológiu.
Riziko a neistota:
Nástroje na riadenie projektov vodopádu nefungujú dobre v prostredí rizika a neistoty. Napríklad mobilná aplikácia je typom produktu, ktorý čelí neustálej neistote, pokiaľ ide o akceptáciu zákazníkom a konkurenciu podobných aplikácií.
Jasne definované fázy:
Fázy systému by mali byť dobre definované, pretože sa musia dokončovať postupne a nedochádza k prekrývaniu.
Pri vytváraní novej verzie existujúceho softvéru.
Mimo oblasti IT sa model riadenia projektov Waterfall úspešne použil vo veľkých projektoch, ako sú
- Stavba lietadla
- Projekty v oblasti infraštruktúry, ako sú mosty
- Výroba obranných zariadení
- Systémy zdravotnej starostlivosti v nemocniciach
V IT projektoch je projekt Waterfall Project Management obzvlášť vhodný pre tie projekty, v ktorých sa vyžaduje externý hardvér. Špecifikácie tohto sa nedajú zmeniť uprostred, pretože by to malo za následok stratu miliónov dolárov.
Keď sa v softvérovom priemysle prejavili nedostatky v projekte Waterfall Project Management, objavilo sa veľké množstvo úvah o tom, ako môžu tímy IT poskytovať klientom maximálnu hodnotu a zároveň zabezpečiť flexibilitu v pracovnom toku.
A tak sa zrodil Agile Project Management System, ktorý teraz prijíma väčšina softvérových spoločností.
Waterfall Project Management vs Agile Systems:
Systém Agile Project Management je flexibilný model, ktorý sa stal populárnym v 90. rokoch 20. storočia. Zahŕňa to rozdelenie projektu na „mini projekty“ s názvom sprinty a samostatnú prácu na každom z nich. Tento model umožňuje vývojárom rýchlejšie začleniť požadované zmeny a je veľmi efektívny v prípade, že sa prostredie zákazníka mení.
Pozitívne kroky manažmentu projektu vodopádu sú:
- Pretože konečný produkt je známy ako celok, plánovanie a dizajn sú jednoznačné.
- Potenciálne problémy, ktoré by sa mohli vyskytnúť v projekte, sa dajú vyriešiť počas samotnej fázy návrhu; pred napísaním kódu.
- Meranie postupu práce je ľahké, pretože fázy sú dobre definované.
- Stabilita tímu je tu, pretože tím zostáva až do konca projektu. V prípade Agile sa tím neustále mení a vyžaduje si to určité úpravy.
- Dokumentácia je rozsiahla a umožňuje tímom ľahšiu správu, ak člen odchádza.
- Vývojári považujú tento model za ľahšiu prácu, pretože je ľahko pochopiteľný,
- Po fáze Požiadavky je aktívna účasť koncového zákazníka potrebná iba vo fáze testovania. Je to tak preto, lebo o všetkých požiadavkách sa diskutovalo nepripravene, bez akýchkoľvek nejednoznačností.
- Produkt sa môže vyvíjať ako celok, namiesto toho, aby sa vyvíjal po častiach.
- Otázky riadenia zmlúv a klientov sa lepšie riešia v rámci modelu riadenia projektu Waterfall.
Pozitívne stránky agilného projektového riadenia sú:
- Zákazník môže počas celého cyklu interagovať s projektovým tímom a môže z času na čas vykonať zmeny produktu tak, aby vyhovovali meniacemu sa prostrediu.
- Ak má byť produkt uvedený na trh veľmi skoro kvôli trhovým okolnostiam, tím Agile Project Management môže vydať základnú verziu, ktorá môže mať rozšírené verzie neskôr.
- Systém je z pohľadu zákazníka celkom transparentný a má férovú predstavu o tom, v akom štádiu je jeho produkt.
- Keďže klient poskytuje prioritu funkcií, tím vie, že sa musí zamerať na funkcie ponúkajúce najvyššiu obchodnú hodnotu.
- Tento proces má svoju vlastnú dynamiku.
- Tímy sú plynulé a flexibilné, umožňujú nápady od každého člena
- Dokumentácia je minimálna, a preto sa od týchto úloh uvoľňuje čas.
Po mnohých rokoch existencie oboch modelov vedľa seba je zrejmé, že:
Model riadenia projektu Waterfall je efektívny pre riadenie projektov, keď po dokončení projektu dôjde k minimálnym zmenám.
Agilný projektový manažment je vhodnejší pre produktový manažment, kde je dôležité byť flexibilný voči zmenám.
Bez ohľadu na to zostáva systém riadenia projektu Waterfall dôležitou súčasťou väčšiny IT projektov. Nemôžeme s istotou povedať, že konkrétny projekt prísne dodržiava postupy agilného riadenia. Spravidla sú agilné princípy „začlenené“ do IT projektov.
Niektoré agilné projektové riadenie majú projektových manažérov, zatiaľ čo prísne agilný model má iba Scrum majstrov. Toto sú hybridné kombinácie modelov riadenia agilných a vodopádových projektov, ktoré niektoré nazývajú projekty „Agifall“ alebo „Agency Agile“.
Popularita systému riadenia projektu Waterfall je tiež spôsobená skutočnosťou, že problémy riadenia zmlúv a klientov sa lepšie riešia metódami riadenia projektu Waterfall.
Aj keď stále viac projektov spadá pod zložku Agile Project Management a stále viac spoločností vidí výhody flexibilného modelu riadenia, popularita modelu Waterfall project management je bezpochyby slabnúca.
Je však ťažké predstaviť si budúcnosť IT projektov, ktoré sú v blízkej budúcnosti úplne agilné. A Waterfall Project Management, ktorý pomohol softvérovému priemyslu v jeho začiatkoch, bude žiť v niekoľkých zložkách projektového riadenia aspoň niekoľko ďalších rokov.
Prvý zdroj obrázka: picjumbo.com
Súvisiace články
- 6 Užitočné fázy pracovného toku pri riadení projektu vodopádu
- Efektívne tipy pre skupinovú diskusiu (odborné poradenstvo)
- Top 10 Bratov o riadení projektu Busted
- 6 Efektívne dôvody, prečo každý potrebuje vášnivý projekt v práci
- 5 najčastejších typov nástrojov na podávanie správ o projektovom riadení
- Produktový manažment vs Riadenie značky - užitočné rozdiely