Waterfall projektijuhtimine - tänapäeval otsib enamik IT-meeskondi Agile Project Management süsteemide kasutuselevõtmist. Kuid lõpuks teevad nad oma projektidele agara projektijuhtimise süsteemide kasutuselevõtu. See tähendab traditsiooniliste projektijuhtimissüsteemide (mida nimetatakse juga projektijuhtimissüsteemideks) kombinatsiooni agiilse juhtimise põhimõtetega, nagu on täpsustatud algses Agile manifestis.
Kuna rohkemates projektides kogu maailmas kasutatakse Agile projektijuhtimise tavasid, kas see tähendab jugaprojektide juhtimise lõppu? Kas kõik IT-projektid on lõpuks Agile Project Management?
Erinevate mudelite, sealhulgas Agile, mõistmiseks ja teie olukorrale kõige paremini sobiva mudeli kasutamiseks on oluline kõigepealt mõista, mis on traditsiooniline projektijuhtimissüsteem, mida nimetatakse Waterfall Project Management Modeliks.
Jugaprojekti juhtimismudelit, mida tööprotsessi olemuse tõttu nimetatakse, iseloomustab järgmine:
- Esmalt visualiseeritakse lõpptoode väga detailselt.
- Seejärel rakendatakse töövoo etapid järjestikku:
- Nõuded ja analüüs
- Kujundus
- Rakendamine
- Testimine
- Paigaldamine
- Hooldus
- Projektiplaan peaks olema lollikindel, sest kui etapi jada on lõpule viidud, ei saa arendajad seda uuesti läbi vaadata, ilma et alustataks uuesti planeerimist.
- Muudatuste või vigade jaoks on vähe ruumi ja projekti kava tuleb hoolikalt järgida.
Waterfall projektijuhtimismudeli päritolu:
IT-tööstuse varases staadiumis polnud tarkvara arendamiseks konkreetset mudelit.
Niisiis, tööstus võttis kasutusele järjestikuse töövoo mudeli, mida kasutati töötlevas tööstuses. Nendel tööstusharudel olid selgelt määratletud tööetapid ja nad olid välja töötanud mudeli, mis rahuldas nende vajaduse range kulude kontrolli järele. Nii et riistvaratööstuse mudel rakendati tarkvara tööstusele.
Winston W Royce esitas selle mudeli esmakordselt 1970. aastal, kuid ta ei kasutanud mõistet “Waterfall Project Management”. Tegelikult esitas ta mudeli puuduliku mudelina. Mudeli piltlik kujutis nägi välja nagu kaskaadne juga. Thomas E. Bell ja TA Thayer kasutasid hiljem oma 1976. aasta artiklis “Tarkvara nõuded: kas need on tõesti probleem?” Mõistet “juga” ja termin jäi püsima.
Sellel mudelil on mitmeid variante. Järgnevalt selgitatakse Waterfall-projekti juhtimismudeli tavaliselt kasutatavaid kuut erinevat etappi. Sõltuvalt projektist võib kaks etappi siiski ühendada.
Vaatleme näitena kooli ehitamise näidet, et jugaprojekti juhtimismudelit paremini mõista.
-
Nõuded ja analüüsietapp:
Esiteks peame täpselt teadma, mida me projekteerime. Selleks võiksime:
- Pidage kliendiga üksikasjalikke arutelusid
- Proovige toodet visuaalselt visandada selle kõige üksikasjalikumate üksikasjadega
- Analüüsige vajalikku riist- ja tarkvarakomponente
- Loetlege üksikasjad, mis hõlmavad järgmist: probleem, mida toode peaks lahendama, kliendi piirangud, jõudluse tase ja ühilduvus juba olemasolevate süsteemidega.
- Viige läbi sarnase toote juhtumianalüüsid.
- Kaaluge iga sidusrühma nõudeid
- Loetlege spetsifikatsioonid tootenõuete dokumendis, mis on järgmise sammu sisendiks.
Kooli ehitamise näites loetleme selles etapis klassiruumide arvu, ehitamiseks vajaliku materjali, vajalikud inimesed, juba olemasoleva infrastruktuuri. Samuti paneksime tähele, mida kooli juhtkond nõuab (kontoriruum, personaliruum) ja mida õpilased vajavad (paremad tualetid, mänguväljakud)
-
Kujundus:
Projekteerimisetapis tehakse kõik, mis on esimeses etapis visualiseeritud, eskiis.
IT-projektides koosneb see järgmiste osade määratlemisest:
- Kasutatav riistvara
- Kasutatav tarkvaraplatvorm, sealhulgas kohalik või pilve juurutamine
- Tarkvara arhitektuur, sealhulgas erinevad loodavad komponendid ja moodulid
- Projekti edukaks toimimiseks vajalikud sisendid
- Oodatavad väljundid (ideaaljuhul sünkroonib see varasemas etapis üksikasjalikult esitatud nõuetega)
Tarkvaraprojektis mängitakse kahte tüüpi disaini:
- Loogiline kujundus
- Füüsiline kujundus
Loogiline kujundus:
See hõlmab põhiandmeid ja protsesse, mis projekti kaasatakse. Selles kirjeldatakse üksikasjalikult vormide ja aruannete kujundamist, liidese ja andmebaasi kujundust. Näiteks rongipiletite veebisaidi puhul määrab see kujundus kogu protsessi toimimise: ekraan, kuhu reisija sisestab oma andmed ja kuidas need andmed voolab andmebaasi, ning ka seda, millist tüüpi andmebaasis need üksikasjad talletatakse.
Füüsiline kujundus:
See puudutab füüsilise andmebaasi, programmide ja protsesside ning hajutatud süsteemide kujundamist. Seda tehakse pärast loogilist kujundust ja see hõlmab projekti teostamise viisi: riistvara, platvormi, millel seda arendatakse, mitmesuguseid kasutatavaid andmebaase, ekraane ja vorme jne.
-
Rakendamine:
- Siin toimub tarkvara / süsteemi tegelik arendamine.
- Selle etapi sisendiks on eelmise etapi esitatud tehnilised kirjeldused.
- Väljund on üks või mitu tootekomponenti, mis on ehitatud vastavalt spetsifikatsioonidele, silutud, testitud ja integreeritud süsteemi arhitektuuri rahuldamiseks.
- Selle etapi eest hoolitseb tavaliselt arendusmeeskond, mis koosneb programmeerijatest, liidesedisaineritest ja muudest spetsialistidest ning kasutatavateks tööriistadeks on koostajad, silurid, tõlgid ja meediumitoimetajad.
- See etapp võtab tavaliselt maksimaalse aja ning on oluline hoolikalt jälgida protsesse ja kavandamist. Sellel etapil on konstruktsiooni muudatused Waterfall Project Management'is rasked.
- Mitut meeskonda hõlmava suure projekti korral on versioonikontroll soovitatav koodipuu muudatuste jälgimiseks ja eelmistele hetktõmmistele vigade käsitlemiseks naasmiseks.
- Meie näites: selles etapis tehakse hoone tegelik ehitamine tööjõu ja materjalide abil.
-
Testimine:
Testimist saab teha toote kui terviku või üksikute komponentide osas. Testijuhtumeid saab kontrollida, et näha, kas toode saab lubatud viisil pakkuda. Seal saab testida mooduleid, integreeritud toote süsteemi testimist ja aktsepteerimise testimist. Vastuvõtu testimine hõlmab toote lünkade testimist lõppkasutaja või kliendi poolt. Defektid võetakse kasutusele, et rakendusmeeskond saaks need parandada. Kui parandused on tehtud, koostatakse ametlik toote dokumentatsioon.
Näites testitakse kooli infrastruktuuri, tõenäoliselt auditimeeskonna poolt. Mõnel juhul kutsutakse õpetajaid tulema sisse ja kasutama ruume tagasiside andmiseks.
-
Paigaldamine:
Kui toote testimine on kõigis aspektides lõpule viidud, saab toote turule lasta või kliendi ruumidesse paigaldada. Selles etapis antakse üle ka kogu toote dokumentatsioon.
Meie kooli puhul avatakse see ametlikult (soovitavalt suure hooga!) Ja kool alustab tegevust!
-
Hooldus:
Selles etapis lahendab IT-meeskond kõik probleemid, mis võivad ilmneda siis, kui klient tegelikult toodet kasutama hakkab või kui toote täiustusi on tehtud. Hea dokumentatsioon on hoolduse alustala. Probleemid lahendatakse koodide muutmise teel, mida nimetatakse “paikadeks”.
Kui on vaja suuri muudatusi, võib projekt minna uue projektina tagasi arendusmeeskonna juurde.
Meie näites vajab kool regulaarset hooldust, enamasti infrastruktuurilist, näiteks vigaseid elektrijuhtmeid või lekkivat vannituba. Nende probleemidega tuleb aeg-ajalt tegeleda.
Nagu nüüd näete, on Waterfall Development Project Management etapid erinevad ja kuigi tavaliselt toimub pidev suhtlus kliendiga, tuleb peamiselt arutada projekti kulgu, mitte projekti ega nõudeid. Kuid jugaprojektide juhtimismudel oli IT-tööstust piisavalt aastaid teeninud ja enamiku projektide jaoks on etapid endiselt head, kuid mitte nii jäigad.
Siiski on mitu projekti, millele Waterfall projektijuhtimismudel sobib.
Millisele projektile Waterfall Project Management sobib?
Toote määratlus:
Esiteks peab lõpptulemust (toodet) olema võimalik alguses hästi määratleda. Projektid, milles toote omanik pole soovitud toote täpsetes spetsifikatsioonides väga kindel, võivad Agile juhtimispraktikat järgida.
Dokumentatsioon:
Projekt peaks olema selline, mida saab dokumenteerida. Dokumentatsioon on projekti Waterfall projektijuhtimismudeli oluline nõue. Tootenõuded, kujundus ja lähtekood peaksid olema kõigis etappides selgelt dokumenteeritud. Kui meeskonna algsed liikmed lahkuvad, moodustab see projekti järjepidevuse juhendi.
Aeg ja ressursid:
Toote vabastamine ei tohi olla kiireloomuline. Ajagraafikud pannakse paika projekti alguses ja meeskond peab saama neist kinni pidada. Lisaks peab tööjõu ja tehnoloogia osas olema piisavalt ressursse.
Risk ja ebakindlus:
Waterfall projektijuhtimise tööriistad ei tööta hästi riski ja ebakindluse keskkonnas. Näiteks on mobiilirakendus seda tüüpi toode, mis seisab silmitsi pideva ebakindlusega klientide nõusoleku ja sarnaste rakenduste konkurentsi osas.
Selgelt määratletud etapid:
Süsteemi etapid peaksid olema täpselt määratletud, kuna need tuleb järjestikku lõpule viia ja need ei tohi kattuda.
Kui luuakse olemasoleva tarkvara uus versioon .
Väljaspool IT-valdkonda on Waterfall projektijuhtimismudelit edukalt kasutatud sellistes suurtes projektides nagu
- Lennuki hoone
- Infrastruktuuriprojektid, näiteks sillad
- Kaitsevarustuse tootmine
- Tervishoiusüsteemid haiglates
IT-projektides sobib Waterfall Project Management eriti nende projektide jaoks, kus on vaja välist riistvara. Selle tehnilisi andmeid ei saa vahepeal muuta, kuna see võib kaotada miljoneid dollareid.
Kui veetranspordi projektijuhtimise puudused ilmnesid tarkvaratööstuses, mõeldi palju sellele, kuidas IT-meeskonnad saaksid pakkuda klientidele maksimaalset väärtust, tagades samas töövooprotsessi paindlikkuse.
Ja nii sündiski Agile projektijuhtimissüsteem, mida enamus tarkvaraettevõtteid võtab kasutusele.
Waterfall projektijuhtimine vs Agile Systems:
Agiilne projektijuhtimissüsteem on paindlik mudel, mis sai populaarseks 1990ndatel. See hõlmab projekti jagamist miniprojektideks, mida nimetatakse sprintideks, ja iga projekti iseseisvat tööd. Selline mudel võimaldab arendajatel nõutavad muudatused kiiremini sisse viia ja see on väga efektiivne, kui kliendikeskkond on muutuv.
Waterfall projektijuhtimise etappide positiivsed küljed on järgmised:
- Kuna lõpptoode on tervikuna teada, on planeerimine ja kujundamine ühemõttelised.
- Projekti käigus tekkida võivad probleemid saab lahendada juba projekteerimisetapis; enne kui kood on kirjutatud.
- Töö edenemist on lihtne mõõta, kuna etapid on täpselt määratletud.
- Meeskonna stabiilsus on olemas, kuna meeskond püsib projekti lõpuni. Agile puhul meeskond vahetub pidevalt ja see nõuab teatavat kohandamist.
- Dokumentatsioon on ulatuslik, mis teeb meeskonnaliikmetest lahkumise korral hõlpsamaks haldamise.
- Arendajatel on selle mudeliga hõlpsam töötada, kuna sellest on lihtne aru saada,
- Pärast Nõuete etappi on lõppkliendi aktiivne osalemine vajalik ainult testimisetapis. Seda seetõttu, et kõiki nõudeid on arutatud keerukalt, jätmata ebaselgust.
- Toodet saab osade kaupa arendamise asemel tervikuna välja töötada.
- Lepingute ja kliendihaldusega seotud probleeme saab paremini lahendada projekti Waterfall projektijuhtimismudeli alusel.
Agiilse projektijuhtimise plussid on:
- Klient saab kogu projektitsükli vältel suhelda projektimeeskonnaga ja teha aeg-ajalt tootes muudatusi, mis sobivad muutuva keskkonnaga.
- Kui toode tuleb turutingimuste tõttu väga kiiresti välja anda, saab Agile Project Management meeskond välja anda põhiversiooni, millel võivad olla hiljem ka edasijõudnud versioonid.
- Süsteem on kliendi vaatevinklist üsna läbipaistev ja tal on aimu, mis etapis tema toode on.
- Kuna klient pakub funktsioonide prioriteetsust, teab meeskond, et ta peab keskenduma funktsioonidele, mis pakuvad ettevõttele kõige suuremat väärtust.
- Protsessil on oma hoog.
- Võistkonnad on sujuvad ja paindlikud, võimaldades kõigil liikmetel mõtteid avaldada
- Dokumenteerimine on minimaalne ja nii vabaneb aeg nendest ülesannetest.
Pärast pikki aastaid mõlemat mudelit, mis eksisteerivad kõrvuti, on ilmne, et:
Waterfall projektijuhtimismudel on efektiivne projektijuhtimisel, kus pärast projekti valmimist on minimaalseid muudatusi.
Agiilne projektijuhtimine sobib rohkem tootehalduseks, kus on oluline olla muutuste suhtes paindlik.
Vaatamata sellele on Waterfalli projektijuhtimissüsteem enamiku IT-projektide oluline komponent. Ei saa kindlalt öelda, et konkreetne projekt järgib rangelt Agiilset juhtimispraktikat. Tavaliselt integreeritakse IT projektidesse agiilsed põhimõtted.
Mõnel Agiilsel projektijuhtimisel on projektijuhid, samas kui Agiilsel mudelil on ainult Scrum Masters. See on Agile ja Waterfall projektijuhtimise mudelite hübriidkombinatsioonid, mida mõned kutsuvad projektideks “Agifall” või “Agency Agile”.
Waterfalli projektijuhtimissüsteemi populaarsus tuleneb ka asjaolust, et lepingu ja kliendihaldusküsimusi käsitlevad Waterfalli projektijuhtimismeetodid paremini.
Kui üha enam projekte kuulub Agile Projektijuhtimise volti ja üha rohkem ettevõtteid näeb paindliku juhtimismudeli eeliseid, on Waterfalli projektijuhtimismudeli populaarsus kahtlemata kahanemas.
IT-projektide jaoks, mis on täiesti liikuvad, on lähitulevikus keeruline ette kujutada. Ja juga Waterfall Project Management, mis aitas tarkvara tööstusele juba lapsekingades, elab projektijuhtimise mõnes komponendis veel vähemalt paar aastat edasi.
Esimene pildi allikas: picjumbo.com
seotud artiklid
- 6 kasulikke töökorralduse etappe jugaprojektide juhtimisel
- Tõhusad näpunäited rühmaaruteluks (ekspertide nõuanded)
- 10 parimat projektijuhtimise müüti katkestasid
- 6 tõhusat põhjust, miks igaüks vajab tööl kirgprojekti
- Projektijuhtimise aruandlustööriista 5 parimat tüüpi
- Tootehaldus vs brändihaldus - kasulikud erinevused