Vesiputousprojektien hallinta - Nykyään useimmat IT-ryhmät tutkivat ketterien projektinhallintajärjestelmien käyttöönottoa. Mutta mitä he lopulta tekevät, on ketterien projektinhallintajärjestelmien omaksuminen hankkeisiinsa. Tämä tarkoittaa yhdistelmää perinteisistä projektinhallintajärjestelmistä (nimeltään Waterfall Project Management Systems) yhdistettynä ketterän hallinnan periaatteisiin, kuten alkuperäisessä Agile-manifestissa on yksityiskohtaisesti kuvattu.
Koska useampaan projektiin ympäri maailmaa sisältyy ketteriä projektinhallintakäytäntöjä, tarkoittaako se vesiputousprojektien hallinnan päättymistä? Saako kaikista IT-hankkeista ketterän projektinhallinnan?
Eri mallien, mukaan lukien ketterä, ymmärtämiseksi ja tilanteeseesi parhaiten sopivan mallin käyttämiseksi on tärkeää ensin ymmärtää, mistä perinteinen projektijohtamisjärjestelmä, nimeltään Waterfall Project Management Model, on kyse.
Vesiputousprojektinhallintamallelle, nimeltään työnkulun prosessin luonteen vuoksi, on ominaista seuraava:
- Lopputuote visualisoidaan ensin erittäin yksityiskohtaisesti.
- Sitten työnkulun vaiheet toteutetaan peräkkäin:
- Vaatimukset ja analyysi
- Design
- Toteutus
- Testaus
- Asennus
- ylläpito
- Projektisuunnitelman tulisi olla tyhjävarma, koska heti, kun sekvenssin vaihe on valmis, kehittäjät eivät voi käydä sitä uudelleen aloittamatta suunnittelua uudelleen.
- Muutoksille tai virheille on vain vähän tilaa ja projektisuunnitelmaa on noudatettava huolellisesti.
Waterfall-projektinhallintamallin alkuperä:
Tietotekniikka-alan alkuvaiheissa ohjelmistojen kehittämiselle ei ollut erityistä mallia.
Joten teollisuus käytti peräkkäistä työnkulkua mallia, jota käytettiin valmistus- ja rakennusteollisuudessa. Näillä toimialoilla oli selkeästi määritellyt työvaiheet ja he olivat kehittäneet mallin, joka tyydyttää heidän tarpeensa tiukalle kustannusten hallitsemiselle. Joten laitteistotekniikan mallia sovellettiin ohjelmistoteollisuuteen.
Winston W Royce esitteli tämän mallin ensimmäisen kerran vuonna 1970, mutta hän ei käyttänyt termiä “Waterfall Project Management”. Itse asiassa hän esitteli mallin virheellisenä. Kuvan esitys mallista näytti CSS-vesiputoukselta. Thomas E. Bell ja TA Thayer käyttivät myöhemmin termiä "vesiputous" 1976-julkaisussaan "Ohjelmistovaatimukset: ovatko ne todella ongelma?", Ja termi tuli jäämään.
Mallista on useita variantteja. Alla selitetään yleisesti käytetyt kuusi erillistä vaihetta Waterfall-projektinhallintamallissa. Projektista riippuen kaksi vaihetta voidaan kuitenkin yhdistää toisiinsa.
Tarkastellaan esimerkkiä koulun rakentamisesta esimerkiksi vesiputousprojektinhallintamallin ymmärtämiseksi paremmin.
-
Vaatimukset ja analysointivaihe:
Ensinnäkin meidän on tiedettävä tarkalleen, mitä suunnittelemme. Tätä varten saatamme ehkä
- Keskustele yksityiskohtaisesti asiakkaan kanssa
- Yritä visualisoida tuote selkeästi yksityiskohtaisimmin
- Analysoi tarvittavat laitteisto- ja ohjelmistokomponentit
- Luetteloi yksityiskohdat, jotka sisältävät: ongelman, jonka tuotteen pitäisi ratkaista, asiakasrajoitukset, suorituskyvyn taso ja yhteensopivuus jo olemassa olevien järjestelmien kanssa.
- Suorita tapaustutkimuksia samanlaisesta tuotteesta.
- Harkitse kunkin sidosryhmän vaatimuksia
- Luettele tekniset tiedot vaatimusasiakirjassa, joka muodostaa tulon seuraavalle vaiheelle.
Esimerkissä koulun rakentamisesta tässä vaiheessa luetellaan luokkahuoneiden lukumäärä, rakentamiseen käytettävä materiaali, tarvittavat ihmiset, jo olemassa oleva infrastruktuuri. Huomaamme myös, mitä koulun johto vaatii (toimistotila, henkilökunnan huone) ja mitä opiskelijat tarvitsevat (parempia wc: tä, leikkikenttiä)
-
Design:
Suunnitteluvaiheessa kaikki se, mikä on visualisoitu ensimmäisessä vaiheessa, tehdään suunnitelmaksi.
IT-hankkeissa tämä koostuu seuraavien määrittelystä:
- Käytettävä laitteisto
- Käytettävä ohjelmistoalusta, mukaan lukien paikallinen tai pilvipalvelu
- Ohjelmistoarkkitehtuuri, mukaan lukien luodut eri komponentit ja moduulit
- Projektin onnistuneen toiminnan edellyttämät tulot
- Odotettavissa olevat tuotokset (ihannetapauksessa tämä synkronoituu aiemmassa vaiheessa yksityiskohtaisesti esitettyjen vaatimusten kanssa)
Ohjelmaprojektissa on kahta tyyppiä suunnittelua:
- Looginen suunnittelu
- Fyysinen suunnittelu
Looginen suunnittelu:
Tämä sisältää perustiedot ja prosessit, jotka sisällytetään projektiin. Se antaa yksityiskohtia lomakkeiden ja raporttien suunnittelusta, käyttöliittymän suunnittelusta ja tietokannan suunnittelusta. Esimerkiksi junalippujen verkkosivuilla tämä suunnittelu määrittelee kuinka koko prosessi toimii: näyttö, johon matkustaja syöttää tietonsa ja kuinka kyseiset tiedot virtaavat tietokantaan, ja myös minkä tyyppinen tietokanta tallentaa nämä yksityiskohdat.
Fyysinen suunnittelu:
Tämä koskee fyysisen tietokannan suunnittelua, ohjelmia ja prosesseja sekä hajautettuja järjestelmiä. Tämä tehdään loogisen suunnittelun jälkeen ja sisältää "miten" projekti tehdään: laitteistot, alusta, jolla sitä kehitetään, erilaiset tietokannat, näytöt ja käytettävät lomakkeet jne.
-
Toteutus:
- Tässä tapahtuu ohjelmiston / järjestelmän varsinainen kehittäminen.
- Tämän vaiheen tulo on edellisen vaiheen tarjoamat suunnittelutiedot.
- Tuloste on yksi tai useampi tuotekomponentti, joka on rakennettu eritelmien mukaan, vianetuksi, testattu ja integroitu vastaamaan järjestelmän arkkitehtuuria.
- Tästä vaiheesta huolehtii yleensä kehittäjäryhmä, joka koostuu ohjelmoijista, rajapintojen suunnittelijoista ja muista asiantuntijoista. Käytettävät työkalut ovat kääntäjät, virheenkorjaimet, tulkit ja mediatoimittajat.
- Tämä vaihe vie yleensä eniten aikaa ja on tärkeää seurata huolellisesti prosesseja ja suunnittelua. Muutokset suunnitteluun tässä vaiheessa ovat vaikeita Waterfall Projektinhallinnassa.
- Useita joukkueita käsittävän suuren projektin kohdalla suositellaan versionhallintaa, jotta voidaan seurata muutoksia koodipuussa ja palata aiempiin tilannekuviin virheiden käsittelyä varten.
- Esimerkissämme: Todellinen rakennus rakennetaan työvoimaa ja materiaaleja käyttämällä tässä vaiheessa.
-
Testaus:
Testaus voidaan tehdä koko tuotteelle tai yksittäisille komponenteille. ”Testitapaukset” voidaan tarkistaa nähdäksesi, pystyykö tuote toimittamaan luvatulla tavalla. Siellä voi olla moduulien testausta, integroidun tuotteen järjestelmätestausta ja hyväksymistestausta. Hyväksyntätestaus sisältää tuotteen testaamisen porsaanreikiä loppukäyttäjän tai asiakkaan toimesta. Viat kirjataan toteutusryhmän korjaamaan. Kun korjaukset on tehty, valmistellaan muodollinen tuotedokumentaatio.
Esimerkissä koulun infrastruktuuria testataan todennäköisesti tarkastustiimillä. Joissakin tapauksissa opettajia kutsutaan tulemaan sisään ja käyttämään tiloja antamaan palautetta.
-
Asennus:
Kun tuotteen testaus on suoritettu kaikilta osin, tuote voidaan vapauttaa markkinoille tai asentaa asiakkaan tiloihin. Tässä vaiheessa myös täydellinen tuote-dokumentaatio annetaan.
Koulumme tapauksessa se virallisesti vihitään (mieluiten isolla ampumalla!) Ja koulu aloittaa toiminnan!
-
huolto:
Tässä vaiheessa IT-ryhmä korjaa ongelmat, joita saattaa ilmetä, kun asiakas tosiasiallisesti alkaa käyttää tuotetta tai kun tuote on parannettu. Hyvä dokumentointi on ylläpidon selkäranka. Ongelmat korjataan muuttamalla koodeja, nimeltään “patches”.
Jos vaaditaan suuria muutoksia, projekti voi palata kehitysryhmään uudella hankkeella.
Esimerkissämme koulu tarvitsee säännöllistä kunnossapitoa, lähinnä infrastruktuurista, esimerkiksi viallista sähköjohdotusta tai vuotavia kylpyhuoneita. Näihin ongelmiin on puututtava ajoittain.
Kuten jo huomaat, vesiputouskehitysprojektinhallinnan vaiheet ovat erilliset, ja vaikka asiakkaan kanssa on yleensä jatkuvaa vuorovaikutusta, ensisijaisesti on keskusteltava projektin etenemisestä, ei suunnittelusta tai vaatimuksista. Vesiputousprojektinhallintamalli oli kuitenkin palvellut IT-alaa hyvien vuosien ajan, ja useimpien hankkeiden kohdalla vaiheet ovat edelleen hyvät, mutta eivät yhtä jäykät.
On kuitenkin useita projekteja, joille Waterfall-projektinhallintamalli sopii erittäin hyvin.
Millaiseen projektiin Waterfall Project Management sopii?
Tuotteen määritelmä:
Ensinnäkin lopputuloksen (tuotteen) on kyettävä määrittelemään hyvin alussa. Projektit, joissa tuotteen omistaja ei ole kovin varma halutun tuotteen täsmällisistä spesifikaatioista, voivat noudattaa ketterää johtamistapaa.
Dokumentointi:
Projektin tulisi olla dokumentoitavissa. Dokumentaatio on tärkeä vaatimus Waterfall-projektinhallintamallissa. Tuotteen vaatimukset, suunnittelu ja lähdekoodi on dokumentoitava selkeästi kaikissa vaiheissa. Jos ryhmän alkuperäiset jäsenet lopettavat, tämä on opas projektin jatkuvuudelle.
Aika ja resurssit:
Tuotteen vapauttaminen ei saa olla kiireellistä. Aikataulut asetetaan projektin alussa, ja tiimin on kyettävä noudattamaan niitä. Lisäksi työvoiman ja tekniikan suhteen on oltava runsaasti resursseja.
Riski ja epävarmuus:
Vesiputousprojektinhallintatyökalut eivät toimi hyvin riskien ja epävarmuuden ympäristössä. Esimerkiksi mobiilisovellus on tuotetyyppi, jolla on jatkuvaa epävarmuutta asiakkaiden hyväksynnän ja vastaavien sovellusten kilpailun suhteen.
Selkeästi määritellyt vaiheet:
Järjestelmän vaiheet tulisi määritellä hyvin, koska ne on suoritettava järjestyksessä eikä päällekkäisyyksiä voi olla.
Kun luodaan uusi versio olemassa olevasta ohjelmistosta.
IT-alueen ulkopuolella Waterfall-projektinhallintamallia on käytetty menestyksekkäästi suurissa projekteissa, kuten
- Lentokoneen rakennus
- Infrastruktuurihankkeet, kuten sillat
- Puolustusvälineiden valmistus
- Terveydenhuoltojärjestelmät sairaaloissa
IT-hankkeissa Waterfall Project Management soveltuu erityisen hyvin niihin hankkeisiin, joissa vaaditaan ulkoista laitteistoa. Tämän määrityksiä ei voida muuttaa puolivälissä, koska se johtaisi miljoonien dollarien menetykseen.
Kun vesiputousprojektin hallinnassa ilmeni puutteita ohjelmistoteollisuudessa, pohdittiin paljon, kuinka tietotekniikkatiimit pystyvät tarjoamaan asiakkaille maksimaalisen hyödyn varmistaen samalla työnkulun prosessin joustavuuden.
Ja näin syntyi ketterä projektihallintajärjestelmä, jonka useimmat ohjelmistoyritykset ovat nyt ottaneet käyttöön.
Vesiputouksen projektijohtaminen vs. ketterät järjestelmät:
Ketterä projektijohtamisjärjestelmä on joustava malli, josta tuli suosittu 1990-luvulla. Siihen kuuluu projektin jakaminen ”miniprojekteiksi”, joita kutsutaan sprintiksi, ja työskenteleminen itsenäisesti kunkin kohdalla. Tällainen malli antaa kehittäjille mahdollisuuden sisällyttää vaadittavat muutokset nopeammin ja se on erittäin tehokas, kun asiakasympäristö on muuttuva.
Waterfall-projektinhallintavaiheiden positiiviset puolet ovat:
- Koska lopputuote tunnetaan kokonaisuutena, suunnittelu ja suunnittelu ovat yksiselitteisiä.
- Projektissa mahdollisesti esiintyvät ongelmat voidaan selvittää itse suunnitteluvaiheessa; ennen koodin kirjoittamista.
- Työn etenemisen mittaaminen on helppoa, koska vaiheet on hyvin määritelty.
- Tiimin vakaus on olemassa, koska joukkue pysyy projektin loppuun saakka. Ketterässä joukkue muuttuu jatkuvasti ja tämä vaatii tietyn määrän säätöä.
- Dokumentaatio on laajaa, joten ryhmien on helpompi hallita, jos jäsen poistuu.
- Kehittäjien mielestä tämän mallin kanssa on helpompi työskennellä, koska se on helppo ymmärtää,
- Vaatimusvaiheen jälkeen loppukäyttäjän aktiivista osallistumista tarvitaan vain testausvaiheessa. Tämä johtuu siitä, että kaikista vaatimuksista on keskusteltu ketjuttamatta, jättämättä mitään epäselvyyttä.
- Tuotetta voidaan kehittää kokonaisuutena sen sijaan, että sitä kehitettäisiin osittain.
- Sopimus- ja asiakashallintakysymyksiä käsitellään paremmin Waterfall-projektinhallintamallissa.
Ketterän projektijohtamisen positiiviset puolet ovat:
- Asiakas voi olla vuorovaikutuksessa projektitiimin kanssa koko syklin ajan ja tehdä muutoksia tuotteeseen aika ajoin muuttuvan ympäristön mukaiseksi.
- Jos tuote on julkaistava pian markkinoiden vuoksi, ketterä projektijohtoryhmä voi julkaista perusversion, jolla voi olla myöhemmin edistyneitä versioita.
- Järjestelmä on asiakkaan kannalta melko läpinäkyvä ja hänellä on reilu käsitys vaiheesta, jossa hänen tuotteensa on.
- Koska asiakas tarjoaa ominaisuuksien prioriteetin, tiimi tietää, että sen on keskityttävä ominaisuuksiin, jotka tarjoavat eniten liikearvoa.
- Prosessilla on oma vauhtinsa.
- Joukkueet ovat joustavia ja joustavia, mikä antaa ideoita jokaiselle jäsenelle
- Dokumentaatio on minimaalista, joten aika vapautuu näistä tehtävistä.
Monien vuosien jälkeen, kun molemmat mallit ovat olleet rinnakkain, on selvää, että:
Waterfall-projektinhallintamalli on tehokas projektinhallinnassa, missä projektin valmistuttua tapahtuu minimaalisia muutoksia.
Ketterä projektijohtaminen sopii paremmin tuotehallintaan, jossa on tärkeää olla joustava muutoksiin.
Siitä huolimatta Waterfall-projektinhallintajärjestelmä on tärkeä komponentti useimmissa IT-hankkeissa. Ei voida sanoa varmasti, että tietty projekti noudattaa tiukasti ketterää johtamistapaa. Tavallisesti ketterät periaatteet ”sisällytetään” IT-hankkeisiin.
Joillakin ketterillä projektijohtajilla on projektipäälliköitä, kun taas ketterässä mallissa on vain Scrum Masters. Tämä on hybridiyhdistelmiä ketteristä ja vesiputousprojektinhallintamalleista, joita jotkut kutsuvat “Agifall” tai “Agency Agile” projekteiksi.
Waterfall-projektijohtamisjärjestelmän suosio johtuu myös siitä, että Waterfall-projektinhallintamenetelmät hoitavat paremmin sopimus- ja asiakashallintakysymyksiä.
Vaikka yhä useammat projektit kuuluvat ketterän projektihallinnan taiteeseen ja yhä useammat yritykset näkevät joustavan johtamismallin edut, Waterfall-projektinhallintamallin suosio on epäilemättä heikentymässä.
Täysin ketterien IT-hankkeiden tulevaisuutta on kuitenkin vaikea kuvitella lähitulevaisuudessa. Ja Waterfall Project Management, joka auttoi ohjelmistoteollisuutta jo lapsenkengissä, elää muutamissa projektinhallinnan komponenteissa ainakin vielä muutaman vuoden ajan.
Ensimmäinen kuvan lähde: picjumbo.com
Aiheeseen liittyvät artikkelit
- 6 hyödyllistä työnkulun vaihetta vesiputousprojektin hallinnassa
- Tehokkaita neuvoja ryhmäkeskusteluun (asiantuntijaneuvoja)
- 10 parasta projektijohtamisen myyttiä katkesi
- 6 tehokasta syytä Jokainen tarvitsee intohimohankkeen työssä
- 5 suosituinta projektijohtamisen raportointityökalua
- Tuotehallinta vs brändinhallinta - Hyödyllisiä eroja