Return to site

Onko vaatimusmäärittelylle paikkaa SAFe junassa?

Joskus IT ammattilaisten kahviautomaattikeskusteluja kuunnellessa syntyy vaikutelma, että ketteryys, scrum esimerkkinä, kadottaa tarpeen perinteiseen järjestelmäkehitykseen kuuluvalle vaatimusmäärittelylle ja kattavalle toiminnalliselle määrittelylle. Kun keskusteluun tuodaan vielä koko organisaation laajuinen ketteryys eli esimerkiksi SAFe, tuntuu, että vanhat opit halutaan unohtaa tyystin. On paljon seremoniaa, puhutaan uusilla termeillä ja rakennetaan entistä itsenäisempiä toteutustiimejä. Välillä tuntuu, että uusien termien ja tiimimallin innostuksessa unohtuu vanhojen vaatimusmäärittely- ja määrittelyvaiheiden käyttökelpoisuus.

Uusien termien ja tiimimallin innostuksessa unohtuu vanhojen vaatimusmäärittely - ja määrittelyvaiheiden käyttökelpoisuus.

Reflector Oy:n vaatimusmäärittelijällä Seija Kälkäjällä on pitkä kokemus vaatimusmäärittelystä perinteisessä vesiputousmaailmassa, ketterissä projekteissa sekä SAFe-junissa. Hän ei näe SAFen lopulta yleisellä tasolla muuttavan vaatimusmäärittelyn tarvetta. Vaatimukset on SAFe-maailmassa edelleenkin syytä miettiä ja kuvata ennen toteutusta. Vaatimusmäärittelyllä on edelleen oltava paikkalippu SAFe-junaan.

Tekemisen rytmitys ja vaiheistus vaatimusmäärittelyn osalta kuitenkin muuttuu SAFe-maailmassa.

Tekemisen rytmitys ja vaiheistus vaatimusmäärittelyn osalta kuitenkin muuttuu SAFe-maailmassa perinteiseen vesiputousmaailmaan verrattuna. Vesiputousmaailmassa vaatimusmäärittely pyritään hoitamaan kertaluontoisesti alkuvaiheessa. Oli kyseessä sitten pieni tai iso projekti, vaatimukset pyritään keräämään kerralla niin, että koko järjestelmän toiminnallisuus saadaan kuvattua. Yleensä massiivisen vaatimusten keräysvaiheen jälkeen järjestetään vielä vaatimusten katselmointi, kommenttien läpikäynti ja vaatimusten hyväksyntä. Vaatimusmäärittelyprosessi vesiputousmaailmassa on verrattain raskas, joskin yleensä vaivansa palkitseva prosessi.

SAFe-maailmassa ei ole tarkoitus kerätä kaikkia vaatimuksia kerralla. Näin SAFessa säästytään massiiviselta vaatimusmäärittelyvaiheelta ja sitä seuraavilta katselmointi- ja hyväksyntäkierroksilta. SAFessa vaatimusmäärittelyä voidaan tehdä jatkuvasti. Toiminnallisuuksia täsmennetään ja tarkennetaan syklisesti. SAFessa koko maailmaa ei yritetä kartoittaa kerralla, vaan vaatimuksia täsmennetään toiminnallisuus kerrallaan portfolio-tason prioriteettien ja roadmapin mukaisessa järjestyksessä. Työn alla on aina rajattu kokonaisuus.

Työn alla on aina rajattu kokonaisuus. Tämä vaatii uutta ajattelutapaa työhön osallistuvilta vaatimusmäärittelijöiltä.

Tämä vaatii uutta ajattelutapaa työhön osallistuvilta vaatimusmäärittelijöiltä. On hyväksyttävä se tosiasia, että SAFe maailmassa eletään jonkinlaisessa epätietoisuudessa kokonaisuuden osalta. On pystyttävä edistämään asioita, vaikka kokonaisuus ja prioriteeteissa vähemmän tärkeät osa-alueet voivat vielä olla epäselviä tai epämääräisiä. Ajatukset vaatimusmäärittelyssä on kulloinkin keskitettävä niihin toiminnallisuuksiin ja ratkaisuihin, jotka ovat prioriteeteissa tärkeimpiä. Uuden ajattelutavan omaksuminen koskee myös muita sovelluskehitykseen osallistuvia, sillä sen vaikutukset heijastuvat myös mm. toteutukseen. Vaiheittaisen vaatimusmäärittelyn seurauksena voi olla se, että jo toteutettua ratkaisua joudutaan refaktoroimaan uuden vaatimuksen mukanaan tuoman toiminnallisuuden vuoksi. Se voi tuntua turhalta työltä, mutta todellisuudessa se on yleensä paras ratkaisu. Näin ei n tehdä etukäteen turhia monimutkaisia ratkaisuja sellaisten marginaalisten vaatimusten vuoksi, jotka jatkuvan priorisoinnin myötä eivät koskaan päädy toteutettavaksi.

Toisaalta kaikki samat vanhat vaatimusmäärittelyn peruskysymykset elävät SAFessakin. On mietittävä, miten vaatimukset kuvataan, mille tasolle vaatimukset kuvataan milläkin SAFen tasolla, mikä on riittävä arkkitehtuurikuvausten taso ja milloin vaatimusmäärittely on valmis. SAFessakin on muistettava, että mitään turhaa ei pidä kuvata, mutta kuvausten olisi kuitenkin oltava riittäviä.

Kaikkea ei pidä yrittääkään määritellä tarkalla tasolla etukäteen. ​

Jotta vaatimusmäärittely SAFe-maailmassa olisi onnistunutta, kannattaa tiedostaa ylimäärittelemisen riski. Toteutustiimiimille pitää uskaltaa antaa valtaa ja vastuuta parhaan mahdollisen ratkaisun kehittämiseen. Totetustiimiä tulee myös tukea siinä, että he todellisuudessa ottavat valtaa. Kaikkea ei pidä yrittääkään määritellä tarkalla tasolla etukäteen. Tämä vaatii luottamusta liiketoiminnan ja toteutustiimin välillä sekä vahvaa kommunikoiintia liiketoiminnan, arkkitehtien ja toteutustiimin kesken. Vaikka päävastuu vaatimusten tarkentamisesta on liiketoiminnan asiantuntijoilla ja arkkitehdeillä, on todella tärkeää käydä toteutustiimin kanssa hyvissä ajoin läpi seuraavaan inkrementtiin suunnitellut toiminnallisuudet. Myös toteutustiimín kommentit on syytä ottaa huomioon vaatimusten tarkentamisessa.

Vaatimusmäärittelyn pitää muuttaa muotoaan ja se pitää pitää järkevissä raameissa.​ Mutta sille pitää olla aina paikka SAFe-junassa.

Hyvään lopputulokseen päästään, kun SAFessakin huomioidaan vaatimusmäärittely osana kehityssykliä. Vaatimusmäärittelyn pitää muuttaa muotoaan ja se pitää pitää järkevissä raameissa. Mutta sille pitää olla aina paikka SAFe-junassa.

Seija Kälkäjä työskentelee Reflectorissa ja hänen erikoisalaansa ovat mm. vaatimusmäärittely ja määrittely ketterissä kehitysmalleissa. https://www.linkedin.com/in/seijakalkaja/

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly