Waterfall vs. Agile: Mitä menetelmää valita Redmine-projekteihisi?

Joskus kuulen huutoja kuten "Gantt on kuollut", "sinun täytyy ajaa sitä ketterällä tavalla" tai jopa "projektinhallinta on kuollut". Vaikka monet niistä ovat vain markkinointihölynpölyä, törmään usein projektisalkunhallinnan, scrum masterien ja muiden projektinhallinnan ammattilaisten kanssa, jotka haluavat vakavasti väitellä ketterän ja vesiputousmenetelmän (Gantt) tekniikoista. Tämä kirjoitus on lyhyt johdanto aiheeseen. Projektinhallinnan rautainen kolmio on itse asiassa hyvin yksinkertainen esitys onnistuneen projektisuunnittelun avainelementeistä. Laajuus, aika ja kustannukset/resurssit. Resurssit ovat ainoa ja/tai kriittiset elementit hinnassa monilla aloilla. Ihmiset ovat arvokkain omaisuus, jota ei voi yksinkertaisesti lisätä, vähentää tai moninkertaistaa. Samoin koneellisilla resursseilla on tietty tuotantokapasiteetti, jota ei voi muuttaa yksinkertaisella napsautuksella. Mutta miten rautainen kolmio sopii kokonaiskuvaan? Erittäin kätevästi. Se tarjoaa meille yksinkertaisen mutta tehokkaan vastauksen siihen, milloin meidän tulisi käyttää vesiputousmenetelmän suunnittelua ja päinvastoin, milloin valita ketterä lähestymistapa. Vesiputousmenetelmä sopii parhaiten projektille, jonka laajuus on tarkasti määritelty ja joka on projektin keskeinen elementti, kuten kiinteistöjen rakentaminen, konferenssin suunnittelu tai Easy Redmine -ohjelmiston käyttöönotto. Tekniikka: Projektin laajuus on määritelty (kiinteä). Esimerkissämme tämä tarkoittaa sitä, että en voi muuttaa ikkunoiden lukumäärää kiinteistössäni, en voi muuttaa konferenssin paikkaa tai aihetta jne. Projektin aika on rajoittava tekijä joko ehdottomasti (esim. konferenssi) tai lähes ehdottomasti (esim. ohjelmiston käyttöönotto). Tarkasti määritellyn laajuuden kanssa projektinjohtajan tai salkunhallinnan tärkein tehtävä on aikatauluttaa kaikenlaiset resurssit aikajanalle rinnakkain tapahtuvissa projekteissa ja ottaa huomioon yksittäisten projektien vaadittu toimintojen (tehtävien) järjestys. Harkitse esimerkiksi talon rakentamista: betonitoimituksista vastaavien työntekijöiden on suoritettava työnsä ajallaan, koska sementtiresurssien puutteesta johtuvat viivästykset voivat estää muurareita suorittamasta omia tehtäviään. Kun betoni on riittävän kiinteää, he voivat jo olla toisella työmaalla. Ketterä lähestymistapa on hyödyllinen projekteissa, joissa aika on tiukasti määritelty, resurssit ovat ratkaiseva tekijä ja laajuus on suunnittelun alainen (priorisointi). Hyvä esimerkki voisi olla ohjelmistokehitys (sprintit), julkaisutoiminta (lehden/uutislehden julkaisupäivä) tai markkinointisisältö (kampanja). Tekniikka: Scrum masterit tai vastaavissa rooleissa toimivat suunnittelijat priorisoivat tehtäviä seuraavaa sprinttiä varten. Yleensä scrum masterilla on erilaisia backlogeja ja scrum-tauluja eri tyyppisille resursseille, kuten kehittäjille, jotka haluavat korjata bugeja ja käsitellä pyyntöjä uusista ominaisuuksista, ja toisaalta poliittisissa tai urheilumediaan keskittyville toimittajille.

Mitä se tarkoittaa?

Ilmeisesti koko projektinhallinnan kysymys pyörii yhä rautaisen kolmion ympärillä. Operatiivinen suunnittelu keskittyy vain eri osiin samaa asiaa. Mitä siitä voimme päätellä?

1. Käytännössä jokaisessa organisaatiossa löytyy projektilajeja, joissa on tarpeen käyttää molempia projektinhallintatekniikoita tehokkaiden työprosessien luomiseksi. Toista menetelmää ei ole parempi kuin toinen, se vain käsittelee erilaisia haasteita.
   
   
2. Laadukas resurssien aikataulutus on olennainen jokaiselle vesiputousprojektille, erityisesti projektisalkun suunnittelussa. Sama pätee Easy Redmine-projekteihin.
   
   
3. Agile-projektien hallinta: Prioriteettien hallinta tapahtuu yleensä erilaisten työkalujen avulla. Usein on ongelma tarkan resurssien kohdentamisen kanssa tiettyyn backlogiin. Siksi suosittelen vahvasti, että kartoitat ja kohdistat resurssisi johdonmukaisesti. Esimerkiksi ohjelmistokehittäjää voidaan käyttää useissa backlogeissa samanaikaisesti (esim. virhekorjaukset vs. toimintopyynnöt samalla kielellä). Ilman määriteltyä resurssien kohdentamista backlogeihin et kuitenkaan pysty aikatauluttamaan prioriteettitoimituksia, ja scrum masterin on jatkuvasti ratkaistava ristiriidat näiden prioriteettien välillä. Toinen ikävä seuraus on uusien keskeisten tuoteominaisuuksien, kuten virhekorjausten tai ominaisuusvaatimusten, viivästynyt julkaisu, jotka hyödyntävät strategisia kehitysresursseja.

Molempien hallintamenetelmien yhdistelmä

Kuten alla olevasta kuvasta näet, meillä on perusvesiputousprojekti, joka sisältää jonkin ohjelmistokehityssuunnitelman, joka näyttää sekvenssit ja riippuvuudet. Kuitenkin tämän projektin mukana olevat tiimit (myyjät, tekniset kirjoittajat) voivat hallita omia toimituksiaan osastollaan ei vain tässä esimerkissä esitetyllä tavalla, vaan myös ketterällä tavalla.

Easy Redmine Gantt - Vesiputousprojektin esimerkki