Waterfall vs. Agile: Millist metoodikat valida oma Redmine'i projektide jaoks?

Mõnikord kuulen hüüdeid nagu "Gantt on surnud", "peate seda juhtima paindlikul viisil" või isegi "projektijuhtimine on surnud". Kuigi paljud neist on lihtsalt turundusjama näited, kohtan sageli projektide portfellihaldureid, scrum mastereid ja teisi projektijuhtimise spetsialiste, kes soovivad tõsiselt arutada Agile vs Waterfall (Gantt) tehnikaid. See postitus on lühike sissejuhatus teemasse. Projektijuhtimise rauatristik Rauatristik on tegelikult väga lihtne esitus eduka projekti planeerimiseks vajalikest põhielementidest. Mahu, aja ja kulude/ressurssidega. Ressursid on ainus ja/või kriitilised elemendid hinnas paljudes tööstusharudes. Inimesed on kõige väärtuslikum vara, mida ei saa lihtsalt suurendada, vähendada ega korrutada. Sarnaselt on masinatel teatud tootmisvõimekus ega saa seda lihtsalt klõpsuga muuta. Aga kuidas rauatristik üldpilti sobib? Väga mugavalt. See pakub meile lihtsat, kuid efektiivset vastust, millal peaksime kasutama Waterfalli metoodika planeerimist ja vastupidi, millal valida Agile lähenemine. Redmine Waterfalli projektijuhtimine Waterfalli metoodika sobib kõige paremini projekti jaoks, mille ulatus on täpselt määratletud ja on projekti võtmetegur, nagu kinnisvara ehitus, konverentsi planeerimine või Easy Redmine tarkvara rakendamine. Tehnika: Projekti ulatus on määratletud (fikseeritud). Meie näites tähendab see, et ma ei saa muuta akende arvu oma kinnisvaras, ma ei saa muuta konverentsi kohta ega teemat jne. Projekti aeg on piirav tegur, kas absoluutselt (nt konverents) või peaaegu absoluutselt (nt tarkvara rakendamine). Täpselt määratletud ulatusega on projektijuhi või portfellihalduri peamine ülesanne planeerida kõik tüüpi ressursse ajaskaalal paralleelselt jooksvate projektide jaoks ning arvestada individuaalsete projektide vajalikku tegevuste (ülesannete) järjestust. Võtame näiteks maja ehitamise: betooni tarnega tegelevad töötajad peavad oma töö õigeaegselt lõpetama, sest betooniressursside puudusest tingitud viivitused võivad takistada telliskivide paigaldajatel oma ülesandeid täitmast. Kui betoon on piisavalt kõva, võib neid juba leida teiselt objektilt. Redmine Agile projektijuhtimine Agile lähenemine on kasulik projektide puhul, kus aeg on kindlalt määratletud, ressursid on määrav tegur ja ulatus on planeerimisele allutatud (prioriteetide seadmine). Heaks näiteks võiks olla tarkvaraarendus (sprintid), väljaandetegevus (ajakirja/ajalehe väljaandmise kuupäev) või turundussisu (kampaania). Tehnika: scrum mastereid või sarnastes rollides planeerijaid prioriseerivad ülesandeid järgmise sprinti jaoks. Tavaliselt on scrum masteril erinevad tagalad ja scrum-tahvlid erinevat tüüpi ressursside jaoks, näiteks arendajad, kes soovivad parandada vigu ja tegeleda uute funktsioonide taotlustega, ning teiselt poolt ajakirjanikud poliitika- või spordimeedias.

Mis see tähendab?

Ilmselgelt keerleb kogu projektijuhtimise küsimus ikka veel raua kolmnurga ümber. Operatiivne planeerimine keskendub ainult erinevatele osadele samast asjast. Mida me sellest järeldada saame?

1. Praktiliselt igas organisatsioonis leiame projektitüüpe, kus on vaja kasutada mõlemat projekti juhtimise tehnikat, et luua tõhusaid tööprotsesse. Üks metoodika pole teisest parem, see lihtsalt lahendab erinevaid väljakutseid.
   
   
2. Ressursside kvaliteetne ajakava koos ajaskaalaga on oluline igale Waterfall projekti, eriti projekti portfelliplaneerimise jaoks. Sama kehtib ka łatwy Redmine projektide kohta.
   
   
3. Agile projektide juhtimine: Prioriteetide juhtimine toimub tavaliselt erinevate tööriistade abil. Sageli on probleem täpse ressursijaotusega konkreetsele tagalale. Seetõttu soovitan tungivalt, et te kaardistaksite ja jaotaksite oma ressursid järjepidevalt. Näiteks võib tarkvaraarendaja kasutada korraga mitut tagalat (nt vigade parandused vs funktsioonisoovid samas keeles). Kuid ilma kvantitatiivse ressursijaotuse määratlemiseta tagalatele ei saa te ajakavastada prioriteetseid tarnitavaid ja scrum master peab pidevalt lahendama nende prioriteetide vahelisi erimeelsusi. Teine ebameeldiv tagajärg on uute oluliste tooteomaduste, nagu vigade parandused või funktsiooninõuded, mis kasutavad strateegilisi arendusressursse, hilinenud väljalase.

Mõlema juhtimismetoodika kombinatsioon

Nagu allpool oleval pildil näha, on meil põhiline Waterfall projekt, mis sisaldab mõnda tarkvaraarenduse plaani, mis näitab järjestusi ja sõltuvusi. Siiski saavad selles projektis osalevad meeskonnad (müügimehed, tehnilised kirjutajad) hallata oma osakonna tarnimisi mitte ainult selle näite näitamise viisil, vaid ka paindlikul viisil.

Easy Redmine Gantt - Waterfall projekti näide