Ketterässä kehityksessä ei ole tapana tehdä täydellistä vaatimusmäärittelyä etukäteen, vaan vaatimukset tarkentuvat projektin kuluessa. Jollain tavalla projektissa on kuitenkin päästävä alkuun ja ketterä tapa siihen on käyttäjäkertomukset (engl. user stories).

Vaatimusten määrittäminen, priorisointi ja aikataulutus

Vaatimusten määrittäminen on kommunikointiongelma. Heidän, jotka sovellusta haluavat, on osattava kommunikoida tarpeensa kehittäjille. Usein tosin käy niin, että asiakas/käyttäjä ei itsekään tiedä tarkalleen mitä haluaa, ennen kuin hän näkee jotain sinnepäin olevaa. Siksi on turha yrittää määritellä sovellusta täydellisesti etukäteen.

Määritystyössä on kriittistä, että asiakas ja toimittajapuoli toimivat tiiviissä yhteistyössä.

Projekteissa tulisi löytää malli, jossa käytettävissäolevien resurssien (aika, raha) jako-ongelmasta tulisi yhteinen ongelma. Mikäli kumpi tahansa osapuoli dominoi, projekti kärsii:

1. Jos asiakaspuoli hallitsee, vaatimuksia ja päivämääriä vain sanellaan kehittäjille ilman mitään tietoa, ovatko kehittäjät todella ymmärtäneet vaatimukset ja toisaalta millaisia onnistumismahdollisuuksia heillä on tuottaa toivottu toiminnallisuus annetussa ajassa. Usein näin käynnistetystä projektista seuraa se, että vaatimuksia joudutaan loppuvaiheessa karsimaan rankasti.
2. Jos kehittäjäpuoli hallitsee, tekninen jargon pelottaa asiakkaat karkuun ja todelliset tarpeet jäävät tiedostamatta. Tällöin myös usein kehittäjät tinkivät laadusta tuottaaksen enemmän toimintoja ja tekevät ominpäin ratkaisuja, joilla voi olla merkittäviäkin taloudellisia merkityksiä.

On tärkeää kiinnittää huomiota siihen, miten asiakkaalta kysyy vaatimuksista. Jos esimerkiksi esitetään kysymys ”haluatko sovelluksesta web-käyttöisen?” asiakas voi hyvin vastata ”Hmm, nyt kun kysyt, niin kyllä”. Kysymyksen ongelma on sen binäärinen luonne (kyllä/ei).

Jos kysymys olisi aseteltu toisin, esim. ”Mitä ajattelet, jos sovelluksesta tehtäisiin web-sovellus windows-käyttöliittymän sijaan, vaikka se tarkoittaisi huonompaa suorituskykyä, heikompaa käytettävyyttä ja vähäisempää interaktiivisuutta?” saattaisi asiakkaan vastaus olla toinen. Tämä kysymys on parempi, koska sen vastaus ei ole rajoitettu kahteen vaihtoehtoon, mutta siinä on yhä ongelmana sen sekavuus, ja siinä tuodaan vahvasti esille (vain) tietyt kompromisoitavat seikat. Paras tapa olisi esittää kysymys muodossa ”mistä olet valmis luopumaan, jotta saisit sovelluksen web-ympäristöön”.

Vaatimuksia kannattaa kuitenkin kysyä mahdollisimman vähän. Parempi vaihtoehto on sitouttaa asiakas tiiviiseen yhteistyöhön, missä vaatimukset löydetään yhdessä. Järjestelmän suunnittelijat tekevät päätöksiään opiskelemalla todellisten käyttäjien oikeita tarpeita, mahdollisesti seuraamalla heidän työskentelyään vanhan järjestlemän parissa.Vastaavasti käyttäjät osallistuvat tiimin jäseninä aktiivisesti järjestelmän suunnitteluun.

 

Vuosien saatossa on havaittu, että aikataulun täydellinen ennustaminen ei onnistu mm. seuraavista syistä:

• Kun käyttäjät näkevät sovelluksen, heille tulee usein uusia ajatuksia, mitä he tarvitsevat lisää, tai miten olemassa olevaa toiminnallisuutta pitäisi muuttaa.
• Liian paljon täsmentymättömiä tarpeita (epämääräisiä käsitteitä)
• Estimointi on usein vaikeaa

Kun emme osaa täysin ennustaa aikataulua, emme myöskään osaa täysin ennustaa, mitä kaikkea toiminnallisuutta toimitetaan.

Niinpä on oleellista tehdä päätöksiä käytettävissä olevan tiedon varassa, mutta päätöksiä voi tehdä usein. Sen sijaan että kerralla (yritettäisiin) tehtäisiin etukäteen täydellinen lista kaikista päätöksistä, päätöksenteko voidaan hajauttaa pitkin projektia. Tähän tarpeeseen käyttäjätarinat ovat oiva apuväline.

Käyttäjätarinat

Käyttäjätarina on yksi selkeä toiminnallinen vaatimus, mitä järjestelmän on tuettava. Varsinainen teksti pyritään pitämään mahdollisimman lyhyenä, mutta tekstistä pitää käydä ilmi KUKA pystyy tekemään MITÄ ja MIKSI. Liian usein puhutaan vain ”käyttäjistä”, vaikka järjestelmällä voi oikeasti olla useita erilaisia käyttäjäryhmiä.

Hyvillä tarinoilla on tiettyjä yhteisiä piirteitä:

• Riippumattomuus. Mikäli tarinat ovat vahvasti riippuvaisia toisistaan, niiden estimointi ja priorisointi voi osoittautua mahdottomaksi.
• Neuvoteltavuus. Tarinat eivät ole sopimuksia, vaan niissä pitää olla joustamisen varaa.
• Arvokkuus. Tarinan pitää tuoda lisäarvoa käyttäjälle, ei kehittäjälle.
• Arvioitavuus. Koska suunnitelu tehdään tarinoiden pohjalta, on niiden oltava arvioitavissa.
• Pienuus. Suuret tarinat ovat liian monimutkaisia, ja riskialttiita tehtäväksi. Usein pitkät kertomukset voidaan jakaa pienempiin osatarinoihin.
• Testattavuus. Tarinoiden pitää olla testattavissa.

Käyttäjätarinoita luodaan tarinankirjoitussessioissa, joka on aivoriihen omainen tapahtuma, johon osallistuu järjestelmän kehittäjät, tulevat käyttäjät, asiakas jne. Tavoitteena on kirjoittaa mahdollisimman suuri määrä tarinoita, ottamatta kantaa siihen, mitä niistä oikeasti toteutetaan. Tarinat voivat olla alkuun ylimalkaisia, joita voidaan sitten iteroiden tarkentaa tai jakaa alitarinoihin.

Perinteisten vaatimusmäärittelyiden ongelmana on niiden liiallinen panostaminen kirjoitettuun sanaan. Jokaiselle lukijalla samat sanat voivat tarkoittaa eri asioita. Sanalliset ilmaukset ovat myös epätarkkoja.

            ”I handed in a script last year and the studio didn’t change one word!”

 “The word they didn’t change was on the page 87.”

                        - Steve Martin

Yleinen harhakuvitelma on, että kun vaatimukset on selkeästi kirjoitettu ylös, siitä seuraisi että käyttäjä saa mitä haluaa. Valitettavasti parhaimmillaankin käyttäjä saa mitä paperille on kirjoitettu.

Siksi on äärimmäisen tärkeää, että keskustelemalla saavutetaan yhteinen käsitys siitä, mitä asiakas todella tarvitsee. Käyttäjätarinoiden EI OLE tarkoitus olla täydellinen määrittely, vaan enemmänkin muistuttaa asioista, joista pitää keskustella.

Haasteita

Käyttäjätarinatkaan eivät ole ainut oikea ratkaisu kaikkiin tilanteisiin. Hyvin suurissa projekteissa tarinoita voi kertyä niin suuri määrä, että niiden käsittely käy mahdottomaksi. Ongelmaa voi helpottaa luomalla ”korkean tason” tarinoita (kertomus) alusta lähtien ja myös ryhmitellä tarinoita teemoittain.

Tarinat eivät välttämättä ole oikea valinta, mikäli vaatimusten jäljitettävyys on tärkeää. Hyvässä, luottamukseen perustuvassa asiakassuhteessa tähän ei kuitenkaan ole yleensä tarvetta.

Käyttäjätarinat keskittyvät parantamaan suullista, tiimin sisäistä, eikä formaalia viestintää. Mikäli vaatimuksia on tarpeen kommunikoida useille eri tahoille – esimerkiksi monitoimittajaprojekteissa – tarinoita on tarpeen laajentaa formaalimmilla dokumenteilla.