Projektinhallintamenetelmät, jotka ovat syklisiä #
Edellä käsiteltyjen ongelmien vuoksi viime vuosina on kehitetty useita vaihtoehtoisia projektinhallintatekniikoita. Nämä tekniikat sopivat erityisen hyvin tietotekniikan kehityshankkeisiin.
Syklinen projektinhallinta on menetelmä projektin tavoitteen saavuttamiseksi lyhyiden, peräkkäisten syklien avulla. Jokainen sykli on lyhyt, mieluiten alle kuukauden. Jokainen sykli täydentää osan projektista. Jokainen sykli sisältää analyysin, suunnittelun, toteutuksen ja testauksen. Tämä eroaa merkittävästi vesiputouslähestymistavasta, jossa jokainen näistä tehtävistä tapahtuu omassa erillisessä vaiheessaan. Lisäksi vesiputous-lähestymistapa määrittää rajoitetun määrän erillisiä hetkiä konseptille, suunnittelulle, toteutukselle ja testaukselle. Tämä tapahtuu monta kertaa peräkkäin syklisessä lähestymistavassa.
Ymmärtäminen Projektinhallintaohjelmisto Kierrä #
Erilaisia ohjelmistokomponentteja toteutetaan läpi syklien, jotka ovat siksi itsenäisiä. Jokainen sykli arvioidaan valmistumisen jälkeen. Jos hankkeelle ilmaantuu uusia tai vaihtoehtoisia tarpeita ymmärryksen lisääntymisen seurauksena, tulevien syklien toimintaa mukautetaan sisällyttämään ne.
Jakso alkaa aikataulun laatimisesta tai muuttamisesta. Tämän jälkeen arvioidaan syklin tuotantotarpeet. Suunnittelu kehitetään, koodataan ja validoidaan. Tämän jälkeen tapahtuu arviointi, ja tietyissä tapauksissa uusi ohjelma otetaan käyttöön. Seuraavaksi seuraava sykli voi alkaa projektin myöhempien osien viimeistelemiseksi. (Yksityiskohtaista keskustelua syklisistä tekniikoista ja niiden eroista, katso esimerkiksi Kroll, 2004; Chromatic, 2003; Stapleton, 2002.)
Seuraavat ovat syklisen menetelmän käytön tärkeimmät edut:
- Parempi tuotteiden laatu ja toiminnallisuuden toteutus;
- Parempi tuotteiden laatu ja toiminnallisuuden toteutus;
- realistisemmat aika- ja kustannusarviot;
- Vähemmän rasitusta projektitiimiin;
- Korkeampi laatu.
Edelliset luvut osoittavat, kuinka vaikeaa tai mahdotonta on määritellä oikein tarvittavat valmiudet projektin alkuvaiheessa. Sykliset tekniikat toteuttavat vaaditut toiminnot lyhyiden syklien sarjassa. Jokainen sykli ei vain tutki, vaan myös suunnittelee, toteuttaa ja testaa pienen osan vaaditusta toimivuudesta. Suunnittelun, toteutuksen ja testauksen nopea peräkkäisyys on kriittistä laadun parantamisen kannalta. Tämän seurauksena joukkueilla on mahdollisuus tehdä muutoksia. Jos malli ei toimi todellisuudessa, se tulee ilmeiseksi koko syklin ajan, mikä mahdollistaa muuttamisen. Lisäksi tällainen toiminta antaa kuluttajille mahdollisuuden pyytää muutoksia.
Laadun ylläpitäminen #
Toinen syy, miksi syklinen projektinhallinta parantaa laatua, on se, että jokainen sykli vaatii tiivistä yhteistyötä asiakkaan, suunnittelijoiden ja ohjelmoijien välillä. Monitieteinen tiimi kehittää ja toteuttaa ratkaisuja yhdessä. Asiakas on pääasiassa mukana alussa, vaatimusten kehittämisessä; Seuraavaksi suunnittelijat luovat suunnittelun ja viimeiseksi ohjelmoijat rakentavat ohjelmiston. Hankkeen johtaja toimii yhteyshenkilönä kaikkien eri osapuolten välillä ja on vastuussa siitä, että toimitetut tiedot toimitetaan oikealle vastaanottajalle. Todellisuudessa monet ohjelmoijat ja suunnittelijat eivät koskaan kohtaa asiakasta, joka vain ilmestyy uudelleen koko ohjelmistokehitysprosessin ajan.
Projektinhallinnan sykliset tekniikat sopivat erityisen hyvin hankkeisiin, joissa lopputavoitetta ei voida määritellä selkeästi etukäteen, kuten taiteellisiin tai tutkimusaloitteisiin. Työskentely sykleissä monipuolisen, loppukäyttäjiä sisältävän tiimin kanssa antaa tiimille mahdollisuuden määrittää projektin todellisen tarkoituksen ja parhaan tavan saavuttaa se. Jokainen sykli tarjoaa mahdollisuuden pohdiskeluun ja korjaukseen.
Vesiputoushankkeille määritellään tavoite etukäteen. Alkuperäisen tavoitteen pohdiskelu on epätodennäköisempää. Alun perin muotoiltu tavoite ei koskaan (täysin) toteudu, eikä alun perin suunniteltu eikä toteutunutkaan ole todennäköisesti juuri sitä, mitä oli tarkoitus.
Lopuksi sykliset projektinhallintamenetelmät tarjoavat ylivoimaisia tuloksia, koska asiakas suorittaa hyväksymistestauksen. Lisäksi laatua parannetaan sisällyttämällä testit korkean suorituskyvyn kriteeriksi alusta alkaen. Siksi ohjelmoijien on luotava ”epäonnistuneet testit” (tai yksikkötestit) ennen koodin kirjoittamista. Vain koodi, joka läpäisee epäonnistuneen testin, katsotaan hyväksyttäväksi.
Johdonmukainen testaus #
Testilähtöinen työ vaatii ohjelmoijia osoittamaan, että uusi koodi on virheetön ennen sen kirjoittamista. He tekevät tämän luomalla testin (epäonnistunut testi), joka tunnistaa mahdolliset puutteet ennen koodauksen aloittamista. Harkitse tapausta, jossa ohjelmisto on kehitettävä, jotta voidaan määrittää oikea määrä makeiskoneelta vastaanotettavia muutoksia. Aluksi on tarkistettava muutoksen aiheuttavan toiminnon olemassaolo. Tätä toimintoa voidaan kutsua ”anna muutos”. Yksinkertainen testi voidaan suorittaa, ja se paljastaisi, että ”anna muutos” -toimintoa ei vielä ole olemassa. Testi menee läpi, jos ohjelmoija luo funktion, mutta ei vielä anna sille mitään ainetta.
Seuraava vaihe on selvittää, palauttaako kone oikean summan rahaa, kun tuote ostetaan. Aseta kuusikymmentä senttiä koneeseen ja osta viisikymmentä senttiä. Testi epäonnistuu, koska funktio jää tyhjäksi. Sen jälkeen ohjelmoija kirjoittaa koodin. Hän määrittelee ”anna vaihtoa” -toiminnossa, että palautettavan muutoksen määrä on yhtä suuri kuin koneeseen laitettu rahamäärä, josta on vähennetty valitun karkin hinta. Testin pitäisi nyt läpäistä onnistuneesti. Tämä toimenpide on toistettava jokaiselle ohjelman osalle.
Ei vain koodia täytyy testata teknisesti; toiminnot on myös testattava (eli hyväksymistestit). Ennen koodauksen aloittamista asiakas määrittelee kriteerit, joiden perusteella kehitettävät ominaisuudet voidaan hyväksyä (esim. kuinka nopeasti tietokoneen tulee reagoida tiettyyn käyttäjän toimintaan). Sitä ennen niiden kriteerien määrittäminen, joiden mukaisesti lisäkapasiteetti voidaan hyväksyä, osoittautui erittäin monimutkaiseksi ja aikaa vieväksi. Kuluttajien aktiivinen osallistuminen testaukseen on kuitenkin ratkaisevan tärkeää projektin onnistumisen kannalta.
Aika- ja rahaarviot #
Toteutettavien toimintojen ymmärtäminen ei ole ennalta määrätty syklisen projektin alussa. Käytettävissä oleva aika ilmoitetaan. Hankkeen suunnasta päästään sopimukseen ja koko prosessin aikana selvitetään, mikä on todella tarpeellista, hyödyllistä ja toteutettavissa olevan ohjelman kannalta. Koska toteutettavat toiminnot eivät ole asetettuja tavoitteita, suhdanneprojektit minimoivat riskin, että vaaditut työtunnit ja siten myös rahat voivat karkaa käsistä. Tämän skenaarion välttämiseksi lähtökohtana käytetään käytettävissä olevaa aikaa ja koko prosessin aikana selvitetään, mitä on kohtuullista ennakoida tässä ajassa.
Lisäksi sykliset projektinhallintatekniikat ovat huomattavasti miellyttävämpiä projektitiimille. Tiimi tekee kaikkensa annetussa ajassa, mutta sitä ei pakoteta saavuttamaan kohtuuttomia määräaikoja tai toimimaan riittämättömällä budjetilla.
Lisäksi suhdannetekniikat yksinkertaistavat ulkomaisten palveluntarjoajien hallintoa. Waterfall-lähestymistavan avulla projekti voi kasvaa riippuvaiseksi yhdestä toimittajasta, kunnes projekti on valmis, riippumatta toimittajan suorituskyvystä. Teoreettisesti on mahdollista tehdä uusia sopimuksia jokaisesta syklistä tai jopa jokaisesta syklisessä työstötekniikassa toimitettavasta komponentista ja tarvittaessa vaihtaa toimittajaa.
