Blogi: Vaatimusten määrittely hybridiprojekteissa
Kokoan tähän artikkeliin ajatuksiani vaatimusten määrittämisestä hybridiprojekteissa, joissa sovelletaan perinteistä projektinohjausta yhdistettynä ketterän kehittämisen menetelmiin. Tällainen malli on tänä päivänä erittäin yleinen tapa toteuttaa ohjelmistoja muun muassa suurissa suomalaisyrityksissä.
Hybridiprojektin dilemma
Perinteisen projektin eteneminen on tyypillisesti sidottu joihinkin ohjauspisteisiin, laatuportteihin tms. Yksi kriittinen portti on se, jossa projektille myönnetään rahoitus ja muut resurssit varsinaista kehittämisvaihetta varten. Perinteisellä mallilla tässä vaiheessa kyseisen vaiheen vaatimukset olisivat valmiit ja niiden perusteella voitaisiin arvioida työmäärä ja sitoutuminen vaiheen tavoitteisiin.
Ketterässä mallissa sen sijaan tällaista laajempaa sitoutumista ei tehdä, vaan työhön lähdetään yksi sprintti - yleensä kaksi viikkoa - kerrallaan. Vaatimuksia backlogissa voidaan tarkentaa, lisätä tai poistaa sprinttien aikana kun tarpeet ja toteutuksen reunaehdot tarkentuvat. Ketteriin työtapoihin kuuluu kuvata vaatimukset pääsääntöisesti yksinkertaisesti käyttäjätarinoiden muotoon. Esimerkiksi näin:
Asiakkaana haluan, että voin antaa osoitteeni profiilitiedoissani, jotta saan toimitukset oikeaan osoitteeseen.
Haasteeksi muodostuu helposti "liikkuva maali". Projektinohjauksen edellyttämät korkean tason tavoitteet on ollut pakko määritellä ilman tarkkoja vaatimuksia. Riskialtteissa hankkeissa nämä tavoitteet todennäköisesti elävät paljonkin projektin aikana kun ketterä toteutus tuottaa uusia prototyyppijulkaisuja ja ymmärrys niiden toiminnasta lisääntyy. Lopputulos voi olla hieno, mutta se ei vastaa alkuperäisiä tavoitteita. Projektin ohjausryhmä on vähintään hämillään ja liikennevalot keltaisena tai punaisena.
Miten tätä dilemmaa voidaan lievittää?
Hybridiprojektien määrittelyssä lähtökohtana ei tulisi olla pelkästään käyttäjätarinat. Monet ketterien mallien variaatiot antavat mahdollisuuden koota tiettyyn toiminnallisuuteen liittyvät tarinat featureiksi ja/tai epiceiksi. Onkin järkevää käyttää näitä samoja määrittelyn elementtejä myös projektin tavoitteiden kuvaamiseen. Pelkkä featureiden nimeäminen ei kuitenkaan ratkaise asiaa, vaan niihin täytyy sisällyttää tarpeeksi yksityiskohtia, jotta tiedetään ainakin:
- Featuren hyväksymiskriteerit ja työmäärä (karkealla tasolla)
- Riippuvuudet muihin projekteihin
- Toteutukseen liittyvät riskit (esim. uudet alustat tai teknologiat)
Hybridiprojektissa ei siis yleensä kannata lähteä heti alussa ajamaan toteutusta eteenpäin kehitystiimin kanssa. Sen sijaan seuraavan kehittämisvaiheen featuret tulisi ensin määritellä riittävällä tasolla, jotta projektinohjauksen tarpeet katetaan. Kun laatuportista on sitten päästy läpi, sprinttien suunnittelu on jatkossa helpompaa, kun riippuvuudet ja riskit on jo kartoitettu.
Projektin testausorganisaatio on yleensä myös mielissään, jos heillä on selkeät feature-tason vaatimukset käytettävissään kun kehitysvaihe alkaa.
Sitten on tälläinen NFR
Ei-toiminnalliset vaatimukset, (Nonfunctional Requirements) voivat ketterissä tai hybridiprojekteissa tulla tiimille yllättäen tietoon. Nimensä mukaisesti nämä eivät yleensä tule ilmi, kun käyttäjätarinoita kartoitetaan käyttäjien kanssa. Ei-toiminnalliset vaatimukset liittyvät yleensä johonkin seuraavista osa-alueista:
- Suorituskyky
- Tietoturva
- Käytettävyys
- Saavutettavuus
- Brandin mukaisuus
Projektilla tulisikin olla sovittu menettely, jolla nämä kootaan ja käsitellään tarvittavien sidosryhmien kanssa. Tyypillisesti muun muassa organisaation laki-, tietoturva- ja tietohallinto-osasto määrittelevät omia ei-toiminnallisia vaatimuksia uusille projekteille tai tuotteille. Jos nämä jätetään huomiotta projektin alussa, niin kustannus niiden lisäämisestä jälkikäteen voi olla huomattavasti korkeampi.
Lopputuloksena ei-toiminnallisten vaatimusten käsittelystä syntyy projektin backlogille käyttäjätarinoita vastaavia teknisiä "enabler-tarinoita", tarvittaessa myös kokonaisia teknisiä featureita. Kun pidetään mielessä edellä mainittu hybrididilemma, niin nämä tulisi sisällyttää alkuvaiheen feature-suunnitteluun.