Projektin valmistelun ja suunnittelun ohittamista perustellaan usein ketterillä projektimalleilla, mutta projektin laadukas valmistelu ei ole ristiriidassa ketterän kehittämisen kanssa – päin vastoin.
North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
19.4.2021
Useimmat ketterät projektimenetelmät lähtevät siitä, että projektin visiota ja tärkeimpiä linjauksia koskevat suunnitelmat tehdään ennen ketterän toteutuksen aloittamista, ja yksityiskohtien suunnittelu tehdään osana toteutusvaiheen sprintejä.
Ketterissä menetelmissä projektin suunnittelun ja valmistelun työvaiheet on kuitenkin usein kuvattu hyvin kevyesti, tai yksinkertaisesti niissä on vain oletettu, että linjaukset on jo tehty ennen projektin käynnistämistä. Tämä johtaa usein siihen harhakäsitykseen, ettei ketteriin projekteihin lainkaan kuuluisi valmistelutyötä.
Product owner ei keksi vaatimuksia tyhjästä
Ketterissä menetelmissä (esim. Scrum) tuoteomistajan eli product ownerin vaativana roolina on välittää organisaation tarpeet ja prioriteetit toteuttajien tietoon. Usein erityisesti teknisten toimittajien odotuksena on, että asiakkaan product owner pystyisi yksin kuvaamaan hankkeen vaatimukset ja vastaamaan kaikkiin kysymyksiin ”lennosta”.
Product owner laatii ja priorisoi projektin backlogin, mutta esimerkiksi scrum ei juuri ota kantaa siihen, miten product owner sen tekee.
Projektin kehitysjonon eli backlogin luominen edellyttää kuitenkin paljon yhteistyötä, suunnittelua ja dokumentointia asiakasorganisaation sisällä. Projektin vaatimukset syntyvät harvoin product ownerin ”omasta päästä”, vaan ne perustuvat käyttäjiltä ja organisaatiolta kerättyihin tarpeisiin ja niiden pohjalta tehtävään suunnittelutyöhön, johon osallistuu usein laajojakin työryhmiä.
Hankkeen valmisteluvaiheessa tehty työ toimii toteutuksen aikaisen tarkemman suunnittelutyön pohjana ja mahdollistaa product ownerin mielekkään itsenäisen työskentelyn, kun projektin suuntaviivat on jo ennakkoon määritelty asiakasorganisaation sisällä.
Valmistelu- ja suunnittelutyön dokumentointi ketterässä prosessissa
Ketterät menetelmät korostavat toimivan ohjelmiston olevan ensisijainen tavoite, eikä dokumentaatiolla ole samaa itseisarvoa kuin useissa perinteisemmissä malleissa. Tämä ei kuitenkaan tarkoita, ettei ketterään projektiin sisältyisi suunnittelua ja suunnitelmien dokumentointia. Suunnittelua tehdään päinvastoin jatkuvasti, sekä ennen projektin käynnistystä että koko projektin ajan.
Seuraavassa kuvassa esitetty Agile alliancen malliin perustuva Microsoft Azure DevOps Boardsin dokumentointihierarkia kuvaa hyvin projektin tavoitteiden ja vaatimusten muodostaman hierarkian.
Ylätasolla olevat suunnitelmat (Portfolio Backlog; Epic, Feature) kuvaavat projektin tavoitteet ja keskeisimmät toiminnalliset vaatimukset, jotka määräytyvät jo ennen projektin käynnistystä. Tämän tason suunnitelmat linjataan yleensä projektin esiselvitysvaiheessa.
Toteutusvaiheen suunnitelmat (Backlog, User story, Task) taas syventävät vaatimusten määrittelyä sekä toteutuksen yksityiskohtia, ja ne tarkentuvat toteutuksen kuluessa. Ennen toteutuksen käynnistystä laadittu vaatimusmäärittely toimii toteutusvaiheen suunnitelmien pohjana.
Kuva 1. Suunnittelutyön dokumentointi ketterässä projektissa.
(Agile-prosessi: https://docs.microsoft.com/en-us/azure/devops/boards/work-items/guidance/choose-process )
Suunnittelu scrum-projektissa
Yleisimmin ohjelmistotyössä käytetyn projektimallin, Scrumin, ydin on sprinteinä tapahtuvan toteutustyön organisoinnissa ja hallinnassa. Scrum itsessään ottaa yllättävän vähän kantaa siihen, kuinka suunnittelutyö tulisi organisoida ennen projektia ja sen aikana.
Projektimalli olettaa, että projektilla on olemassa visio, mutta malli ei ota kantaa siihen, kuinka se syntyy. Projektimalli myös olettaa, että product owner laatii ja priorisoi projektin backlogin, mutta ei juuri ota kantaa siihen, miten product owner sen tekee.
Arkkitehtuurisuunnittelua (tai arkkitehdin roolia) scrum ei myöskään sisällä, vaan arkkitehtuurin oletetaan syntyvän ketterästi tiimin työnä. Käytännössä projektin onnistumisen kannalta on kuitenkin toivottavaa, että arkkitehtuuri on ainakin karkealla tasolla määritelty ennen kuin projekti käynnistyy.
Myöskään esim. käyttöliittymä- tai visuaaliselle suunnittelulle scrumissa ei ole varsinaista toimintatapaa, vaan sen oletetaan tapahtuvan toteutustiimin sisällä osana toteutusta. Tämä on ristiriidassa käytännön kanssa, sillä asiakasorganisaatio harvoin haluaa käynnistää toteutusta näkemättä minkäänlaista ajatusta lopputuloksen toiminta-ajatuksesta tai lopputuloksista.
Projektia edeltävä valmistelu- ja suunnitteluvaihe siis käytännössä vaaditaan lähes aina projektin käynnistämiseksi, mutta suunnittelutyötä ei yleensä piirretä auki scrum-prosessiin, vaan se ikään kuin piilotetaan ”kaikkivaltiaan” product owner -roolin sisälle.
Seuraavassa kuvassa on esitetty karkea kuvaus siitä, kuinka esiselvitys- ja vaatimusmäärittelyvaiheissa tehtävä valmistelu- ja suunnittelutyö käytännössä toimii scrum-projektin lähtökohtana.
Kuva 2. Esiselvitys ja vaatimusmäärittely Scrum-projektin lähtökohtina.
(Scrum-prosessi: https://scrumstudy.wordpress.com/2014/07/24/what-is-scrum/)
Vaatimusmäärittely on digiprojektissa keskeinen dokumentti, jonka avulla konkretisoidaan tietojärjestelmän tai verkkopalvelun suunnittelu, hahmotetaan tekniset ratkaisut, pyydetään toteuttajalta perusteltu työmäärä- tai kustannusarvio ja ohjataan ketterän toteutustyön työtehtäviä. North Patrolin vetämässä määrittelytyössä vaatimukset saadaan kirjattua laadukkaasti, asiantuntevasti ja kustannustehokkaasti.
Esiselvitys varmistaa projektin lähtökohdat
Riippumatta käytettävistä projektimenetelmistä, ennen uuden digihankkeen käynnistämistä projektin tavoitteet ja laajuus kannattaa aina tarkentaa tekemällä esiselvitys, joka toimii pohjana projektin tarkemmalle suunnittelulle ja toteutustyölle.
Ketterän projektin esiselvityksen tärkein tehtävä on tunnistaa, mitä projektin ensimmäiseltä julkaistavalta lopputulokselta (MVP) odotetaan.
Esiselvityksen tavoitteena on kirkastaa projektin tavoitteet ja sen lopputuloksena olevan ratkaisun pitkän tähtäimen visio sekä konkreettinen ensimmäisen vaiheen konsepti. Toinen tehtävä on luoda projektille riittävät linjaukset ratkaisun arkkitehtuurista ja käytettävistä teknologioista. Kolmas keskeinen tehtävä esiselvitysvaiheessa on luoda taloudelliset ja aikataululliset raamit projektin toteutukselle.
Hyvässä esiselvityksessä otetaan kantaa seuraaviin asioihin:
- projektin tausta ja tavoitteet
- alustava palvelukonsepti ja keskeiset vaatimukset
- arkkitehtuuri ja toteutusteknologiat
- työmäärä ja kustannukset
- projektin vaiheistus ja aikataulu (tiekartta)
- projektin resursointi, organisointi ja hallinta
Esiselvitysvaiheessa voidaan kartoittaa tarpeita esim. haastattelemalla ratkaisun käyttäjiä ja muita sidosryhmiä sekä kokeilla erilaisia ratkaisuvaihtoehtoja esim. kevyillä prototyypeillä. Ketterän projektin esiselvityksen ehkä tärkein tehtävä onkin tunnistaa, mitä projektin ensimmäiseltä julkaistavalta lopputulokselta (MVP) odotetaan.
Ketterä hankinta vaatii selkeän vision ja arkkitehtuuriratkaisut
Ketterien menetelmien käyttöä perustellaan usein sillä, että isoja, monimutkaisia järjestelmiä ei voi suunnitella etukäteen. Yksityiskohtien suunnittelu voidaankin hyvin jättää toteutusvaiheen tehtäväksi, mutta erityisesti suurissa kehittämishankkeissa selkeä visio ja arkkitehtuuriratkaisut ovat ensiarvoisen tärkeitä ketterän toteutuksen sujuvalle läpiviennille ja onnistuneille lopputuloksille.
Lue lisää: Tietojärjestelmähankkeiden esiselvitys – North Patrolin mallit ja menetelmät
PS. Sinua voisi kiinnostaa tulossa oleva ilmainen webinaarimme: Digitaaliset asiointipalvelut – Erilaiset konseptit ja toteutuksen eri vaihtoehdot (11.12.2024 klo 10:00). Ilmoittaudu webinaariin
