Eihän tässä nyt mitään vaatimusmäärittelyä tarvita – sutaistaan nopeasti muutama user story ja siinä se! Vai?
Taannoin eräs toimeksiantajani kertoi, ettei ammattimaisia määrittelijöitä tahdo löytyä millään. Ovatko määrittelijät siis kadonneet ketteryyden yleistymisen myötä? Vai eikö tuota nimikettä enää käytetä? Väittäisin kuitenkin, että todellisuudessa tarvetta on. Ehkä määrittelijät ovat ”pesiytyneet” isoihin softataloihin ja sellaisiin organisaatioihin, joilla itsellään on IT-osasto.
Turvasatama isoissa hankkeissa
Isoja hankkeita tehdään vielä aika paljon perinteisemmillä projektinhallintamenetelmillä. Ja silloin luontaisesti lähdetään vaatimuksista liikkeelle. Miksikö? No, kun pitää saada tulevan järjestelmän koko ja mittaluokka selville hankintaa varten.
Isoihin hankkeisiin liittyy tyypillisesti myös monimutkaisia käsittelysääntöjä, jotka vielä ovat riippuvaisia toisistaan. Eli pienissä paloissa rakentaminen ei välttämättä onnistu. Tai pahimmassa tapauksessa joudutaan rakentamaan joitakin osia uusiksi, kun koko totuus valkenee. Tällaisissa tapauksissa kunnon vaatimusmäärittelystä on oikeasti hyötyä, ja hyvät määrittelijät ovat arvossaan.
Mutta ei näissäkään nykyään kaikkea tehdä yhtenä möhkäleenä. Tyypillistä on kerätä ja kuvata vaatimukset ensin liiketoiminnalta karkealla tasolla. Ja sen jälkeen vaiheistaa niiden tarkentamista jakaen vaatimukset fiksuihin kokonaisuuksiin. Eli tehdään iteroiden. Ja mahdollisesti kunkin osakokonaisuuden tarkentamisen jälkeen lähdetäänkin kehittämään järjestelmää niiden pohjalta – siis tehdään inkrementaalisesti. Ei siis puhdasta vesiputousmallia.
Eihän määrittelijöitä tarvita ketteryydessä…
Ketterissä menetelmissä on harvemmin erilaisia rooleja, vaan ”kaikki” ovat kehittäjiä. Ja pahimmillaan tapahtuu juuri kuten aloituksessani kuvasin: väsätään joitakin käyttäjätarinoita, jotka jäävät sille esimerkkitasolle: Asiakkaana haluan selata tuotteita, jotta tiedän mitä on tarjolla. Tämä on lähinnä tarpeen kuvaus, ei vaatimuksen. Helposti käy myös niin, että käyttäjätarinat eivät muodosta mitään kokonaisuutta, vaan ovat joukko irrallisia juttuja. Yritä siinä sitten saada selvää kokonaisuudesta – mitä järjestelmä oikeastaan tekee.
Itse asiassa on väärin sanoa, ettei ketteryydessä ole määrittelijöitä. Nimittäin esim. Scrum Product Owner eli tuoteomistaja on mitä suurimmassa määrin määrittelijä. Hänen vastuullaan on kerätä liiketoiminnan vaatimukset, viedä ne Product Backlogiin eli tuotteen kehitysjonoon ja priorisoida ne. Kunkin sprintin eli kehityskierroksen alussa valitaan kehitysjonosta joukko kärjessä olevia vaatimuksia, jotka tarkennetaan sille tasolle, että kehittäjät ymmärtävät ne ja osaavat niiden pohjalta toteuttaa. Tarkennus tehdään yhteistyönä kehittäjien ja tuoteomistajan kesken. Lisäksi tuoteomistajan pitää olla AINA kehittäjien tavoitettavissa tarkentavia lisäkysymyksiä varten.
Vaan kuinka usein tuoteomistaja oikeasti pystyy vastaamaan kaikkiin kysymyksiin? Harvemmin. Hänen tehtävänsä onkin ottaa selville vastaukset liiketoiminnasta, jos hän ei itse tiedä. Tämä tarkoittaa täysipäiväistä työtä projektissa – ei siis mitään silloin tällöin läsnä oloa. Valitettavan usein näin ei kuitenkaan tapahdu.
Entäs sitten lean…?
Lean-menetelmistä tunnetuin on SAFe® (Scaled Agile Framework), joka on kehitetty auttamaan isojen hankkeiden ketteröittämisessä. Sen avulla voi olla useita toimitusjunia (ART = Agile Release Train) liikkeessä – eli oikeastaan osaprojekteja käynnissä. Toimitusjunat eivät kuitenkaan ole välttämättä toisistaan riippumattomia, vaan niiden välillä voi olla paljonkin kytköksiä. Tällöin toimitusjunat muodostavat yhdessä ratkaisujunan (Solution Train).
Vaikka ei mentäisi ihan noin monimutkaiseen ”rakenteeseen”, jo yhdessä toimitusjunassa on yleensä useita tiimejä, joilla kullakin on omat ScrumMasterit ja Product Ownerit. Toimitusjunan tiimien Product Ownerit muodostavat yhdessä Product Management -tiimin, jonka vastuulla ovat koko Product Backlogin vaatimukset: he omistavat, määrittelevät ja priorisoivat vaatimukset. Koko Product Backlogin omistaa kuitenkin yksi henkilö, Product Manager, jonka vastuulla on kokonaisuus.
Entäs se vaatimusmäärittely? No, kunkin Program Incrementin (PI) lopusta varataan aikaa varsinaisen suunnittelukokouksen valmisteluun. Eli kaikki Product Ownerit ja muut tarvittavat henkilöt valmistelevat kaksipäiväisen suunnittelukokouksen, jossa käytännössä määritellään ja priorisoidaan seuraavan PI:n vaatimukset ja tutkitaan riippuvuudet sekä arvioidaan liiketoiminta-arvot. Ja nuo 2 päivää saattavat olla hyvinkin pitkiä kestoltaan. Suunnittelukokoukseen osallistuvat KAIKKI yhtä aikaa. Eli jos toimitusjunassa on 5 tiimiä ja niissä kussakin 10 henkeä, niin suunnitteluun osallistuu 50 henkeä! Suunnittelua jatketaan, kunnes KAIKKI voivat sitoutua määriteltyihin priorisointeihin ja työmääriin jne.
Eli kyllä tehdään vaatimusmäärittelyä!
Edellä käytin tarkoituksella englanninkielisiä nimityksiä, sillä niiden sisältö eroaa jonkin verran Scrumin vastaavista nimityksistä.
Työmäärä kuriin kokonaisarkkitehtuurilla!
Oli työskentelytapa mikä tahansa, ison helpotuksen työmäärään voi saada kokonaisarkkitehtuurin kuvauksista. Tyypillisesti täytyy kuitenkin ymmärtää, millaiseen ympäristöön uusi järjestelmä tulee. Toisin sanoen pitää selvittää, miten järjestelmän tulee tukea toimintaprosesseja ja toiminnan palveluja, samoin pitää tietää erilaiset sidosryhmät. Pitää tietää naapurijärjestelmät, joihin tarvitaan integraatioita. Ja ymmärtää myös käytössä oleva teknologia-alusta – eli minkälaiseen teknologiaympäristöön uusi järjestelmä tulee. Jos järjestelmän tarvitseva organisaatio on kuvannut kokonaisarkkitehtuuria, sen malleista määrittelijät saavat todella paljon aineksia vaatimusmäärittelyn pohjaksi! Ei tarvitse tehdä samaa työtä moneen kertaan.
Summa summarum: ei vaatimusmäärittely ole kuollut! Se on vain muuttanut muotoaan. Ja määrittelijöitä kutsutaan monilla eri nimillä.
Ps. Jos haluat tietää, millaisia ominaisuuksia odotetaan määrittelijältä, niin lukaisepa blogini Vaatimusmäärittely on supervoima! Ja kokonaisarkkitehtuurin tehosta voit kuunnella webinaaristani Nopeuta projektia kokonaisarkkitehtuurin avulla.
Ps.2 Lisää tietoa vaatimusmäärittelystä saat myös kurssilta Tehokas vaatimusmäärittely.