Kuvien merkityksestä

Viime syksynä kirjoitin artikkelin siitä, kuinka sanoilla on suuri merkitys IT-järjestelmiä määriteltäessä. Monimerkityksiset lauseet, slangi ja lyhenteet, liiallinen tarinointi ja kielimuuri aiheuttavat monasti ymmärtämisvaikeuksia. Tekstejä joudutaan tarkastamaan ja muokkaamaan paljon, jotta niistä saadaan selkeät ja ymmärrettävät eri osapuolille.

Kaikki tämä vie aikaa ja resursseja. Tähän haasteeseen olisi kuitenkin helppo ratkaisu, jota käytämme aivan liian harvoin. Miksi emme piirtäisi selventävää kuvaa tai kaaviota?

Kuvat ovat yleismaailmallisesti ymmärrettäviä, joten niiden viesti välittyy varmemmin vaikka lukija ei ymmärtäisikään kaikkia tekstejä tarkasti. Etenkin asioiden riippuvuuksien esittäminen on usein jopa paljon helpompaa erilaisten visuaalisten kaavioiden ja taulukoiden kuin pelkän tekstin avulla. Joillakin meistä on hyvä visuaalinen muisti jolloin graafisesti havainnollistetut mallit jäävät helpommin mieleemme.

Minkälaisen kaavion tekisin?

Kaavioita ja malleja on tietysti monenlaisia. IT-järjestelmien alueella yleensä halutaan piirtää kuva toiminnasta (prosessista) tai järjestelmistä ja niiden keskinäisistä suhteista (arkkitehtuureista). Tässä keskityn nyt lähinnä prosessien kuvaamiseen, koska ne tulevat useimmiten vastaan määrittelytöissä. Hyvät arkkitehdit osaavat yleensä visualisoida järjestelmiä kyllä ja tykkäävät sitä tehdä.

Prosessit voivat olla liiketoimintaprosesseja, jotka kiinnostavat asiakkaita, tai sitten teknisempiä järjestelmien toimintaa kuvaavia. Samat periaatteet pätevät kuitenkin. Aika usein ajatellaan, että piirretään vain laatikoita ja nuolia ja sillä hyvä. Tämä on tietysti parempi kuin ei mitään, mutta oikeasti iso sudenkuoppa vähänkin haastavammissa tilanteissa. Mietitäänpä vaikka näitä kysymyksiä:

• Mitä laatikot kuvaavat: tehtäviä, tekijöitä, vai tuotoksia?
• Mistä prosessi alkaa ja mihin päättyy?
• Onko siinä erilaisia kulkuja tiettyjen ehtojen täyttyessä?
• Onko samanaikaisia tehtäviä, toistuvia juttuja, tms?

Oma suosikkini prosessien mallinnuksessa on BPMN - Business Process Model and Notation. Se on mallina riittävän havainnollinen, jotta sitä voi pääosin ymmärtää ilman suurempaa perehtyneisyyttä. Toisaalta siinä on mahdollisuus detaljien kuvaamiseen tarkemmin, jos tarvetta tulee.

Eri tyyppisiä työkaluja BPMN-kaavioiden tuottamiseen on myös runsaasti tarjolla, paljon ilmaisiakin. On työasemaan asennettavia, verkossa toimivia tai wiki-järjestelmien plugareita.

Alla malliksi yksinkertainen esimerkki katselmointiprosessista.

Yksi mainio ominaisuus näissä malleissa on se, että niitä voi tutkia ja simuloida liikuttelemalla kuviteltua pelinappulaa (tai useampaa) mallissa. Tämä on mielestäni myös kriteeri, mistä voi tunnistaa hyvän prosessimallin. Esimerkin mallissa tarvitaan kaksi nappulaa, koska rinnakkainen portti (+-merkitty salmiakki) haarauttaa prosessin.

Esteitä

Miksi käytämme kaavioita tai prosessimallinnusta niin vähän, vaikka siitä olisi monissa tapauksissa selkeää hyötyä? Syitä voi olla esimerkiksi seuraavia:

1. Tiedon tai osaamisen puute. Ajatellaan, että mallintaminen on jotenkin erityisen vaikeaa tai työlästä.  Ei tunneta uusia välineitä tai malleja riittävän hyvin.
2. Ennakkoluulot. Mallintamisella voi olla huono maine. On totta, että 2000-luvun alkuvuosina alalla vallitsi iso innostus mallintamiseen ja sitä tehtiin monissa organisaatioissa oikein hartaasti. Monet harjoitukset epäonnistuivat ylisuurien odotusten ja lupausten takia ja hyvätkin käytännöt hylättiin. Voidaan myös väittää, että ketterässä kehittämisessä ei tarvittaisi mallintamista. Oikeasti optimi on tietysti jossakin näiden ääripäiden välillä.
3. Talon tavat. Jos kaavioiden tai mallien käyttö ei ole yksinkertaisesti kuulunut tapaan toimia, kynnys käyttöönottoon voi olla korkea.
4. Kiire. Ajatellaan, että kuvan piirtäminen on liian vaikeaa ja siihen kuluu liikaa aikaa. Sepustetaan vaikeasti ymmärrettäviä tarinoita ja sittenhän meillä kohta onkin kiire, kun joudumme niitä selittämään ja korjaamaan.

Askel eteen

Nyt kannattaakin kokeilla tätä, vaikeaa se ei ole. Ehdota mallintamista työtoverillesi tai esimiehellesi. Harvoin perusteltuja ehdotuksia lytätään, ja sitten vain testaat hommaa käytännössä. Voit yllättyä positiivisesta palautteesta, jota saat kun kollegat ihastelevat aikaansannoksiasi. Miksi tätä ei kokeiltu aiemmin!

Linkkejä

Tässä vielä muutamia linkkejä hyviin työkaluihin ja muihin saitteihin, joissa on lisää tietoa.

• Bizagi Modeler, ilmainen BPMN-työkalu Windows-ympäristöön
• Cawemo, verkossa toimiva BPMN-mallinnusväline
• Gliffy, yleinen verkossa toimiva piirtotyökalu. Tukee myös BPMN:ää ja saatavilla Confluence plugari
• BPMN Quick Guide, pika-opas

Ketterä testaus

Perinteisesti testaus on ollut viimeinen vaihe järjestelmän kehityksessä ennen valmistumista. Lähtökohtaisesti se ei siis ole voinut tapahtua kovinkaan ketterästi koska kattava testaus tarvitsee toimivan version koko järjestelmästä.

Uudet kehitysmallit kuitenkin kyseenalaistavat tätä ajattelua, ja harvassa projektissa on enää mahdollisuutta varata testaukseen riittävä aika ja resurssit projektin loppuvaiheeseen. Tarvitsemme siis ehdottomasti testausta pitkin matkaa, mutta käytännössä siinä on kuitenkin erilaisia haasteita.

Ketterän testauksen haasteita

Muuttuvat vaatimukset

Kattava ja laadukas järjestelmän testaus edellyttää riittävän tarkkoja määrittelyitä, joiden pohjalta testitapaukset ja mahdollinen testiautomaatio rakennetaan. Ketterässä kehityksessä vaatimukset kuitenkin tarkentuvat tai jopa muuttuvat matkan varrella. Käyttäjätarinat ovat harvoin projektin alkuvaiheessa riittävän tarkkoja kaikkien testitapausten määrittelyä varten. Sprinttien valmistumisen ja katselmoinnin myötä tiimin näkemys ratkaisusta muuttuu tai vähintään tarkentuu ja sitä kautta testejä tulee tarkentaa projektin edetessä.

Testausasiantuntijat onkin syytä ottaa mukaan tärkeisiin kokouksiin, kuten sprintin suunnitteluun ja katselmointiin. Ja on tärkeää että he ymmärtävät sekä asiakkaalle tärkeimmät ominaisuudet että ei-toiminnalliset vaatimukset (kuten tietoturvan) ja osaavat kohdistaa testauksen panokset näihin. Mutta heidän roolinsa ei enää ole suorittaa kaikkea testausta.

Sprinttien testaus

Kehitystiimi toteuttaa tuotteeseen uutta toiminnallisuutta jokaisessa sprintissä viikon-kahden välein. Miten nämä saadaan testattua kattavasti niin, että tiimi voi luottavaisesti demonstroida uusia toimintoja? Tämä onkin keskeinen kysymys, jota kannattaa pohtia jo ennen kuin projekti on käynnissä.

Ketterän testauksen periaatteiden mukaan koko tiimi testaa ja valvoo laatua aina kun tuotoksia syntyy. Kehittäjät tekevät yksikkötestit ennen koodauksen aloittamista ja testaavat tarinat niiden valmistuttua. Ihanteellisesti näiden tulisi olla mahdollisimman pitkälle automatisoitu. Tuoteomistaja (Product Owner) määrittelee käyttäjätarinoille hyväksymiskriteerit, ja myös testaa niiden toteutumisen kun kyseinen tarina on toteutettu. Asiakas tekee hyväksymistestauksen kun sopiva julkaisu on valmiina tuotantoympäristössä.

Testaustiimin laajempi rooli

Kun ketterässä kehittämisessä koko tiimi on vastuussa laadusta, perinteisen testaustiimiin (tai paremminkin testausasiantuntijoiden) rooli on hyvin erilainen. Heidän tehtävänsä on ennen kaikkea tukea muuta tiimiä, niin että testaus voi edetä muun kehittämisen mukana. Käytännössä tähän voi kuulua esimerkiksi:

• Testausnäkökulman (hyväksyntäkriteerit) edistäminen ja varmistaminen käyttäjätarinoiden kirjoittamisessa
• Testiautomaation ja muiden testausvälineiden käyttöönotto ja tuki
• Muun tiimin avustaminen laadunvarmistamiseen liittyvissä tehtävissä

Tehokas testaus ja sen automaatio edellyttää tänä päivänä vahvaa osaamista sekä siihen käytettävistä välineistä että testattavasta järjestelmästä. Jos esimerkiksi järjestelmiin rakennetaan uusia rajapintoja, tulisi nämä testata erikseen eikä vain niitä käyttävien sovellusten kautta.

Riittävää osaamista ei kuitenkaan välttämättä kaikilla kehittäjillä tai tuoteomistajilla ole, ja testaajien apu on tällöin kullan arvoinen. Tämä pitää myös muistaa kun tiimejä resurssoidaan, valitettavan usein käytännössä testausosaaminen on pahasti aliedustettuna.

Automaation merkitys

Miksi automaatio on tärkeää ketterässä testauksessa? Vastaus on lopulta varsin yksinkertainen. Iteratiivinen kehitys tuottaa uusia toiminnallisuuksia tietyn perustan päälle, joka kasvaa joka iteraatiossa, mutta on (yleensä) muuttumaton tulevissa iteraatioissa. Olisi tärkeätä, että tähän perustaan kohdistuvat testit saataisiin automatisoitua mahdollisimman pitkälle ja suoritettua kaikkien tulevien iteraatioiden aikana regressiotesteinä.

Mikäli automaatiota ei saada rakennettua, tarvittavan testauksen määrä kasvaa kohtuuttoman suureksi kun uutta toiminnallisuutta on testattava tarkkaan, mutta perustakin on testattava, jotta varmistutaan että muutokset eivät ole vaikuttaneet sen ulkoiseen toimintaan. Kannattaa myös muistaa, että ketterään kehittämiseen usien kuuluva refaktorointi lähtökohtaisesti lisää regressiotestauksen tarvetta.

Sanojen merkityksestä

Vaatimusten määrittely on periaatteessa yksinkertainen tehtävä. Kuunnellaan, mitä asiakas haluaa ja kirjoitetaan vaatimukset sopivaan muotoon, niin että kehittäjät voivat ne toteuttaa. Tehtävä sisältää kuitenkin monia haasteita ja mahdollisia sudenkuoppia.

Kehitysmalleja on erilaisia ja vaatimukset voivat olla käyttäjätarinoita tai muodollisempia kuvauksia määrittelydokumentissa. Silti lähes poikeuksetta ne kuvataan sanallisesti, Suomessa yleensä suomeksi, ruotsiksi tai englanniksi.

Luonnollisen kielen haasteita

Kieli on viestintää kirjoittajalta lukijalle, ja on todennäköistä että kirjoittajan ja lukijan tiedoissa ja kokemuksissa on eroja. Tällöin tekstin ymmärtäminen voi olla vaikeata tai monimerkityksinen ilmaisu ymmärretään väärin. Esimerkiksi seuraavat asiat aiheuttavat usein haasteita vaatimusteksteissä:

• Ammattislangi ja lyhenteet
• Epäselvät sanat
• Sekavat ja monimutkaiset lauserakenteet
• Liiallinen tarinointi
• Kielimuuri

Slangi ja lyhenteet

Omassa työporukassa on luontevaa käyttää ammattislangia ja lyhenteitä. Kuitenkin, jos halutaan tuottaa muille sidosryhmille ymmärrettävää tekstiä, slangi tulisi korvata selkeällä yleiskielellä. Usein esimerkiksi teknisten järjestelmien vaatimuksissa toki tarvitaan täsmällisiä ammattitermejä. Näistä voidaan tehdä erillinen sanasto, jossa niiden merkitys avataan sidosryhmille tarpeellisella tarkkuudella. Samalla varmistetaan, että yhdestä käsitteestä käytetään aina samaa termiä. Lyhenteet voidaan koota samaan sanastoon.

Epäselvät sanat

Adjektiivit ovat usein luonnostaan epätarkkoja, vailla selkeää mittaria tai vertailukohtaa. Vaatimusteksteissä näkee edelleen valitettavan usein epämääräisiä määreitä kuten "helppokäyttöinen", "standardinmukainen" tai "nopea vasteaika". Korusanat ovat käytännössä vailla merkitystä ellei niihin saada liitettyä todennettavia mittareita. Helppokäyttöisyyteen voi pureutua esimerkiksi määrittämällä tarvittavien hiiren klikkausten määrän jonkin tehtävän suorittamiselle.

Sekavat ja monimutkaiset lauserakenteet

Matematiikassa loogisissa lauseissa eri operattoreilla on määrätyt ensisijaisuudet (EI, JA, TAI) ja lauseita voidaan tarvittaessa myös selventää sulkumerkeillä. Luonnollisessa kielessä näitä keinoja ei ole, vaan lauserakenne on muotoiltava niin että väärinymmärrys ei ole mahdollinen.

Esimerkiksi seuraava lause: "Bonuskorttia käyttävät tai alennuskoodi-asiakkaat ja yli 100 eurolla tilaavat saavat ilmaisen toimituksen" voidaan tulkita kahdella eri tavalla:

1. bonuskortti TAI (alennuskoodi JA yli 100 €)
2. (bonuskortti TAI alennuskoodi) JA yli 100 €)

Monimutkaisia ehtoja sisältävät pitkät lauseet kannattaakin yleensä purkaa erillisiksi lauseiksi taikka taulukoiksi. Jos tarkoitettiin tulkintaa 1, voidaan muotoilla esimerkiksi: "Bonuskorttia käyttävät saavat aina ilmaisen toimituksen. Lisäksi ilmainen toimitus annetaan, jos käytössä on alennuskoodi ja tilaus on arvoltaan yli 100 euroa."

Liiallinen tarinointi

Monet puhujat pitävät puhumisesta ja jatkavat tarinaansa erilaisilla täytesanoilla ja poikkeavat asiasta sivuraiteille. Samoin sitten käy helposti kirjoitettaessa.

Vaatimuksia kirjoitettaessa kannattaa sensijaan harkita tarkkaan jokaisen sanan merkitys ja miettiä lauseista onko se tarpeellinen asian ymmärtämisen kannalta vai turhaa täytettä. Asioiden kertaaminen on ehdottoman turhaa. Tulee muistaa, että turhaan pidennetty teksti hidastaa lukemista ja tekee mahdollisista muutoksista aina vaikeampia.

Toki liian niukkakaan ei saa olla, vaan tekstissä tulee olla kaikki tarpeellinen muttei mitään ylimääräistä.

Kielimuuri

Englannin kieltä käytetään Suomessa ja muissa ei-englanninkielisissä maissa paljon työkielenä. Monet kieltä osaavat (yli 75%) eivät kuitenkaan puhu sitä äidinkielenään. Vaikka kieli on yleinen, se ei ole erityisen helppo, muun muassa sanaston rikkauden johdosta. Tästä seuraa paljon potentiaalisia ymmärtämisen ongelmia.

Mitä siis neuvoksi? Yllä olevat keinot auttavat paljon tässäkin. Kannattaa ehkä harkita onko aina pakko käyttää englantia vai voisiko täysin kotimaassa tehtävän projektin määritellä suomeksi.

Kokemuksen ja koulutuksen kautta opimme paremmiksi vieraan kielen käyttäjiksi. Jos teksti on tärkeä, kannattaa se aina tarkastuttaa toisella lukijalla. Myös ammattiapua on tarjolla. ImproveIt:n tytäryhtiö WriteIt tarjoaa englannin kielentarkastusta vankalla kokemuksella. Siitä voit lukea lisää täältä.

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 voidaan tarkentaa, lisätä tai poistaa vaiheen 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:

1. Featuren hyväksymiskriteerit ja työmäärä (karkealla tasolla)
2. Riippuvuudet muihin projekteihin
3. 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.