Ketterän projektin projektisuunnitelma – Osa 1: Kaikki haluavat olla ketteriä, sillä kukapa haluaisi olla jäykkä?
”Voisitko kirjoittaa blogiin ketterän projektin projektisuunnitelmasta?” minulta kysyttiin. Kysymys juonsi siitä, että nykyään ketteryys on kaikkien huulilla – tai ellei vielä puheissa, niin ainakin mielessä. Yllättävää kyllä, vasta suhteellisen pieni osa organisaatioista kuitenkaan tietää, mistä ketterässä kehityksessä on käytännössä kyse ja on tehnyt tarvittavat rakenteelliset muutokset ketterän kehityksen mahdollistamiseksi. Selkeästi isompi joukko organisaatioita on vielä tilassa ”Meilläkin pitää ryhtyä tekemään kehitystä ketterästi nykyisen jäykästi (lue: projektina) tekemisen sijasta!” Kirjoitukseni onkin suunnattu lähinnä niille, joille ketteryys on vasta termi ilman toimintaa.
Periaatteet eivät vielä ole muotoutuneet yksiselitteisiksi
Melko pian hihat käärittyäni totesin, että omilla kirjallisen viestinnän taidoillani yksittäisen blogipostauksen kirjoittaminen tästä aiheesta on mahdotonta, joten tulkoon tästä blogisarja. Itseltäni kun puuttuu kokonaan sellainen suurpiirteisyys, että pystyisin kirjoittamaan omasta mielestäni tulkinnanvaraista asiatekstiä. Lisäksi aiheeseen liittyy useita vielä toistaiseksi määrittelemättömiä periaatteita. Siksi toivoisinkin projektimaailmassa käytävän hieman periaatteellista keskustelua nyt, kun digitalisaation myötä yhä useammat organisaatiot alkavat kehittää tuotteita, palveluita ja toimintoja, ja keskeisen osan kehityksestä muodostavat erilaiset tietojärjestelmät.
Mikä kuuluu ketterän projektin suunnitteluun, mikä tuotoksen ominaisuuksiin?
Yksi itselleni edelleenkin hieman epäselvä periaate on mihin vedetään raja sen suhteen, mikä tietojärjestelmän rakenteissa kuuluu ositukseen ja mikä tuotoksen ominaisuuksiin. Onko jokainen ominaisuus oma työpakettinsa tuotososituksessa? Vai ovatko yhden ominaisuuden tai toiminnallisuuden muodostamat koodirivit yksi tuotoksen osa? Vai ovatko nämä jo tietyn osatuotoksen, kuten esimerkiksi rajapinnan, ratkaisua? Vaatimusmäärittelyt ovat selkeästi projektin tuotoksia, mutta ovatko käyttötapaukset, käyttäjätarinat tai epicit omia tuotoksiaan vai jonkun tietyn tuotoksen ominaisuuksia? Entäpä vanha rakkauteni testaus? Testaussuunnitelmat, testitapaukset ja -skriptit ovat varmasti projektin tuotoksia, jotka on osituksessa huomioitava. Mutta toisaalta vikaraportitkin ovat melko konkreettisia, ja jonkun on nekin projektin aikana tuotettava – ja silti tuntuu vieraalta, että osituksessa voisimme kuvata edes montako vikaraporttia projektin aikana tullaan tekemään. Onko se siis projektin laajuuspoikkeama, jos vikaraportteja tehdäänkin suunnitellun kymmenen sijasta sata? Tähän pohdintaan kuulisin mielelläni muidenkin ajatuksia,koska omassa pääkopassa nämä osat eivät vielä ole täysin kristallinkirkkaasti löytäneet paikkaansa kokonaisuudessa.
“Ketterän” merkitys riippuu puhujastakin
Tätä blogisarjaa varten on rajattava, mitä ketteryys tässä yhteydessä tarkoittaa. Tänä päivänä puhutaan paljon ketteryydestä ja hyvin erilaisissa asiayhteyksissä. On ketterää organisaatiota, ketterää johtamista ja ketterää muutosta. Näihin ei kuitenkaan toistaiseksi ole kehitetty ainakaan yhtä laajalle levinneitä ja yleisesti käytettyjä teorioita tai viitekehyksiä kuin ketterään ohjelmistokehitykseen, joten rajaan ne tämän ketteryyspohdinnan ulkopuolelle. Niitäkin tulee toki pohtia ja tarkastella niiden mahdollisia hyötyjä projektien onnistumisen edellytysten parantamiseksi, mutta niitä ei pidä sekoittaa ketterään kehitykseen. Erilaisia ketterän kehityksenkin menetelmiä on kymmeniä, ja jokaisesta niistäkin on erilaisia organisaatiokohtaisia sovelluksia. Tyypillisesti kaikki nämä kuitenkin pohjautuvat nk.Agile Manifestoon. Koska kymmeniin erilaisiin sovelluksiin viittaaminen voi käydä sekavaksi, keskityn käyttämään esimerkkinä näistä toistaiseksi yleisintä, eli Scrumia.
Scrum on toimivaksi todettu viitekehys
Scrum on siis tekijöidensä Ken Schwaberin ja Jeff Sutherlandin mukaan prosessiviitekehys, jossa on määritelty periaatteita, arvoja, tapahtumia, rooleja ja välineitä, joilla tehdään ohjelmistokehityksestä ketterää: lopputuotosta kehitetään siis pienissä paloissa siten, että siihen kehitettäviä ominaisuuksia säädetään asiakastarpeen mukaisesti jatkuvasti kehityksen aikana. Käytäntö on osoittanut, että Scrumilla ohjelmistoista saadaan ominaisuuksiltaan käyttäjäystävällisempiä ja tarkoituksenmukaisempia.
Scrum ja projektijohtaminen
Nykyään myös projektiammattilaiset ovat jo sisäistäneet melko kattavasti sen, mikä on tämän Scrum-nimisen prosessiviitekehyksen ja projektijohtamisen viitekehysten välinen suhde. Vielä kymmenen vuotta sitten näitä kahta pidettiin jotenkin toisensa poissulkevina vaihtoehtoina. Alati digitalisoituvassa maailmassa tietojärjestelmäkehitystä sisältävien projektien onneksi näin ei kuitenkaan ole. Yleisimmin projektijohtamisen viitekehyksissä projekti jaetaan muutamaan elinkaaren vaiheeseen. Tyypillisesti vaiheet ovat projektin valmistelu, projektin suunnittelu, projektin toteutus ja projektin lopetus. Scrum istuu täydellisesti toteutusmallina näistä toiseksi viimeiseen eli projektin toteutusvaiheeseen, jonka sisällä (toteutustavasta riippumatta) projektin tuotosten ominaisuudet tai tekniset ratkaisut suunnitellaan, toteutetaan, testataan ja otetaan käyttöön. Tässä mielessä Scrumia voisi pelkistetysti pitää yhtenä vaihtoehtoisena vaihejakomallina vesiputous-, inkrementti- ja muiden iteratiivisten vaihejakomallien rinnalla.
Vaikuttaako valittu toteutusmalli projektin suunnitteluun?
Miten siis Scrumin valinta työskentelytavaksi, jolla tuotoksen ominaisuudet suunnitellaan, toteutetaan ja testataan, vaikuttaa projektin suunnitteluun? Vaikuttaako vesiputousmallinkaan valinta tuotoksen suunnittelun ja toteuttamisen vaihejakomalliksi siihen, miten projekti suunnitellaan? Ja jos toteutusmalli vaikuttaa projektin suunnitteluun, niin miten, ja mihin projektin suunnittelun osa-alueisiin erityisesti? Näitä näkökulmia tulen pohtimaan omien ja asiakkaiden kokemusten kautta tämän blogisarjan seuraavissa osissa.
Annika Oinonen, Suomen Projekti-Instituutti Oy