Ohjelmistoa koodatessa jokaisen valinnan vaikutukset voivat ulottua vuosien päähän. Mitä aikaisemmin yksittäinen puute tai määrittelyissä tehty virhe tunnistetaan, sitä laadukkaampi on lopputulos. Ja toisin päin: jos virhe pääsee etenemään pitkälle, sen haittavaikutukset kasvavat enemmän kuin eksponentiaalisesti. Tätä kutsutaan laatuvipuajatteluksi.
Oikea-aikaisesti käytettynä laatuvipu säästää aikaa ja kustannuksia. Itse asiassa toimiva vaatimusten hallinta tekee koko ohjelmistokehittämisestä mielekkäämpää. Miten vaatimusten hallintaan sitten voi lisätä laatua ja läpinäkyvyyttä ketterissä ohjelmistokehitysprojekteissa?
Tärkeitä avaimia ovat yhteistyö asiakkaan kanssa, vaatimusten kytkeminen tuotehallintaan sekä selkeät kriteerikäytännöt. Palataan pian siihen, mitä ne vaatimusten hallinnan näkökulmasta tarkoittavat.
Lue myös tutkimusraportti: Tuoteomistajien rooli ja sen haasteet
Joustava vaatimusten hallinta – uhka vai mahdollisuus projektitiimille?
Onnistunut vaatimusten hallinta on siis todellisten tarpeiden ja vaatimusten tunnistamista mahdollisimman aikaisessa vaiheessa. Onnistuminen vaatii myös valintojen ja rajausten tekemistä sekä vaatimusten dokumentointia ymmärrettävällä tavalla. Koska jokainen projekti ja asiakas on erilainen, tärkeintä on soveltaa vaatimusmäärittelyn työkaluja tilanteeseen sopiviksi.
Ennen agile-menetelmien yleistymistä vaatimusmäärittely oli suhteellisen pysyvä paketti, joka rakennettiin uuden hankkeen alussa. Ketterässä ohjelmistokehityksessä vaatimukset sen sijaan elävät matkan varrella. Uudet ideat ovat tervetulleita, vanhoja tarkastellaan kriittisin silmin ja iteroidaan uuteen asentoon.
Onko ketterä vaatimusten hallinta notkea tapa kehittää softaa hektisessä maailmassa? Ehdottomasti.
Onko tekijöiden hankalaa koodata juuri oikeita asioita, kun vaatimukset ovat jatkuvassa muutoksessa? Todennäköisesti on, ellei ketterän kehityksen käytäntöihin ole kiinnitetty riittävästi huomiota. Epäselvät vaatimukset johtavat helposti juuri siihen, mitä laatuvivulla koetetaan välttää: turhaan työhön.
Jotta tällaiselta tilanteelta vältyttäisiin, pitää ensinnäkin tunnistaa, mistä puhutaan, kun puhutaan vaatimuksista. Toisaalta on löydettävä yhteisiä kriteereitä, joiden avulla vaatimuksiin yltämistä voi arvioida.
Päävastuu vaatimusten hallinnasta kuuluu ketterän softakehityksen viitekehyksessä tiimin Product Ownerille eli tuoteomistajalle. Tuoteomistajalla on oltava riittävästi aikaa ja osaamista suuntaviivojen määrittelyyn, mutta periaatteiden toteuttamiseen sitoutuu koko tiimi yhdessä.
Tunnista vaatimukset yhdessä asiakkaan kanssa
Ohjelmistohankkeen vaatimukset ovat lyhyesti sanottuna nippu tietoa siitä, miten järjestelmä toimii. Niiden määrittelyä ohjaavat mm. eri sidosryhmien tarpeet, teknologian mahdollisuudet ja rajoitteet sekä toimialakohtainen lainsäädäntö. Esimerkiksi terveydenhuollon järjestelmään kohdistuu erilaisia vaatimuksia kuin teollisuuden IoT-sovellukseen.
On olennaista tunnistaa juuri oikeat vaatimukset ja ymmärtää, että niillä on elinkaarensa. Ketterässä kehityksessä vaatimukset eivät ole pysyviä, vaan perusluonteeltaan muuttuvia. Meille ohjelmistokehittäjille tämä kaikki saattaa olla selvää. Asiakas voi nähdä vaatimukset toisin: kehityksen ulkopuolisina asioina, joihin palataan vasta, kun jokin on mennyt vinoon. Olenkin kokemuksen kautta huomannut, miten tärkeää projektin alussa on avata ajattelua yhdessä asiakkaan kanssa.
Lue myös: Ei tuotetalo, ei konsulttitalo – kokemuksia työskentelystä ratkaisutalossa
Asiakkaan puolelta lähtötilanteessa ei ole aina mukana asiantuntijaa, joka osaisi kuvata vaatimuksia riittävän tarkasti. Silloin me ohjelmistokumppanina voimme tukea asiakkaan Product Owneria, tai jopa sopia, että tekninen tuoteomistaja nimetään meidän kehitystiimimme joukosta. Jos näin päätetään tehdä, on samalla laajennettava asiakkaan sidosryhmäkenttää ja löydettävä ne henkilöt, jotka pystyvät avaamaan liiketoiminnan pelikenttää koodareille.
Alkuvaiheen yhteisiin työpajoihin ja ymmärryksen rakentamiseen kannattaa varata riittävästi aikaa. Ketterässä prossessissa vuoropuhelu jatkuu koko kehityshankkeen ajan. Kuten ehkä arvaatkin: panostus keskusteluihin maksaa itsensä takaisin tulevina vuosina.
Kytke vaatimukset tuotehallintaan eli projektin backlogille
Monesti vaatimuksia dokumentoidaan erilliseen listaan, joka säilötään paikkaan X. Lista ei ehkä ole helposti edes projektitiimiläisten saatavilla. Laadun näkökulmasta olisi tärkeää tehdä vaatimuksista saavutettavia ja läpinäkyviä. Se onnistuu, jos vaatimukset liitetään osaksi projektin backlogia. Vaatimusten hallinta on tuotehallintaa, joka pitää sisällään muutostenhallintaa ja sitä kautta myös riskien hallintaa.
Mitä kaikkea backlogilta tulisi löytyä? Sitäkin on hyvä käydä asiakkaan kanssa läpi. Monet ohjelmiston ostajan mielestä kriittiset asiat voivat olla isossa kontekstissa pieniä, kertaluontoisesti toteutettavia ja näkyvään käyttöliittymään liittyviä toiminnallisuuksia. Todellisuudessa backlog on ennen kaikkea paikka, johon tulisi kirjata muun muassa tietoturvaan ja suorituskykyyn liittyviä parannuksia.
Lue myös: 5 tietä parempaan käyttäjäkokemukseen: Ohjelmistokehitys on jatkuvaa vuoropuhelua
Luo yhteiset standardit: Definition of Ready ja Definition of Done
Otetaan seuraavaksi luupin alle yksittäisten vaatimusten hallinnan taso. Tässä apuna ovat kriteerit, jotka kertovat, minkä nimettyjen ehtojen pitää täyttyä, jotta yksittäinen vaatimus pääsee sprint backlogille (Definition of Ready, DoR) ja minkä ehtojen taas täyttyä, jotta kehitysjonossa ollut asia voidaan katsoa tehdyksi (Definition of Done, DoD). Valmiita kriteerejä ei ole, vaan niistä sovitaan yhdessä asiakkaan kanssa.
DoR-ehtoja sprint backlogille pääsemiseen voi olla esimerkiksi 3–10. Ne varmistavat esimerkiksi, onko vaatimus lainmukainen tai yhteensopiva tiettyjen teknologioiden kanssa. Kriteerien tarkasteluun eli backlog grooming-/refinement-työhön kuuluu säännöllisiä palavereja kulloinkin sovituilla kokoonpanoilla. Sekin on osa laatuvipuajattelua.
Jotkin projektin vaatimukset – kuten kriittisen järjestelmän korkea saatavuus – voivat olla melko pysyviä. Toimintaympäristö, kuten teknologia tai lainsäädäntö, kuitenkin muuttuu jatkuvasti. DoR- ja DoD-standardeihin voi palata jokaisessa demosessiossa, kun uusia ominaisuuksia tuodaan esiteltäväksi. Näin sovittu taso pysyy yllä läpi vuosien.
DoR- ja DoD-kriteerit tehdään yleensä alkumetreillä, mutta niitä saa ja kannattaa muuttaa, jos tilanne myöhemmin sitä vaatii.
Tarkastele vaatimuksia lisäksi toiminnallisten hyväksyntäkriteerien valossa
Ohjelmiston osien lopullinen hyväksyntätestaus perustuu yksittäisten vaatimusten hyväksyntäkriteereihin (Acceptance Criteria, AC). Siinä missä DoR- ja DoD-standardit ovat ennen kaikkea teknistä laadunvarmistusta, hyväksyntäkriteerit painottuvat enemmän toiminnallisuuksiin ja käytettävyyteen.
Tällaisten kriteerien kohdalla ohjelmistokehitystä ostavien asiakkaiden omat kyvykkyydet ovat usein pisimmällä. Juuri toiminnalliseen ja käyttöliittymätasoon kiteytyy usein asiakkaan alkuperäinen visio lopputuloksesta.
Tunnista kohdat, joissa tarvitaan sparrausta ja vuoropuhelua
Laatuvipuajattelun kannalta on tärkeää, että ohjelmistoratkaisujen toteuttajat pystyvät ajattelemaan proaktiivisesti. Kun yhteistyö alkaa, tunnistamme aktiivisen vuoropuhelun kautta asiakkaan valmiudet ketterillä menetelmillä työskentelyyn ja etsimme ne kohdat, joissa yhteinen sparrailu on erityisen tärkeää.
Monesti juuri määrittely ja vaatimusten hallinta on se alue, jossa asiakas arvostaa saamaansa apua ja rakentavia ehdotuksia. Positiivinen haastaminen turvaa asiakkaan tulevaa liiketoimintaa: “Pitäisikö tämä toiminnallisuus tehdä sittenkin eri tavalla, jotta lopputulos olisi GDPR:n mukainen?”
Vaatimusten pallotteluun kuluvaa aikaa ei välttämättä osaa arvostaa siinä hetkessä, mutta kun ohjelmisto on ollut tuotannossa vuoden tai kaksi, jokainen näkee hyödyt selkeästi.
Ohjelmistoa ostavan yrityksen mielessä saattaa olla kirkkaastikin se liiketoimintatarve, joka tulisi ratkaista. Kehittäjinä me tuomme hankkeeseen ne rakennuspalikat, joilla tuo visio voidaan saavuttaa. Laatuvipuajattelu varmistaa, että suurestakin rakennelmasta tulee kestävä.
Millaista tukea tuotekehityksen onnistumiseen tarvitaan? Kysyimme sitä yli 80 suomalaisen organisaation tuoteomistajilta. Lataa tutkimusraportti!