Ihmisläheiset määrittelyt ovat avain parempiin ohjelmistoihin

Hyvä liiketoimintajohtaja,

Oletko kyllästynyt kuulemaan IT- tai tuotekehitysosastolta selityksiä, kuten ”jotain tuli eteen” ja ”tätä ei voitu ennakoida”, juuri sinä päivänä, kun odotit näkeväsi IT-järjestelmän tai loppukäyttäjäpalvelun?

Mitä tapahtui? Huutaako toimitusorganisaatio, etteivät vaatimuksesi olleet riittävän selkeitä, vaikka otit loppuasiakkaan mukaan suunnitteluvaiheeseen?

Entä jos löytäisit kaikkien näiden ongelmien perimmäisen syyn?

Me kaikki haluamme luoda ihmisille arvokasta ohjelmistoa maailmassa, jota vaivaavat virhealttiit prosessit, asiantuntijoiden ennakkoasenteet ja organisaatioiden haasteet. Kollegani Tatu kirjoitti erinomaisen johdannon ATDD:hen ja TDD:hen, jossa hän kuvaa, mitä ne ovat ja miten ne auttavat organisaatiota ”shift left” -ajattelussa.

Perehdytään tarkemmin liian myöhään suunnittelun ongelmiin ja siihen, miksi liiketoimintavaatimukset eli määrittelyt kannattaa yhdistää Definition of Doneen.

Definition of Done vie Agilea eteenpäin

Myös Agile-menetelmissä keskittyminen todelliseen asiakasarvoon voi olla erittäin vaikeaa.

Kun ohjelmisto-organisaatiot (liiketoiminta ja IT/tuotekehitys) aloittavat Agile-transformaationsa ja ryhtyvät toimimaan aidosti Agilen mukaisesti, yleinen ongelma on Definition of Done -termin (DoD) epäselvyys loppukäyttäjävaatimusten näkökulmasta. Toisin sanoen: miten varmistat, että teet vaatimusten näkökulmasta oikeita asioita?

Heikkolaatuinen DoD voi olla oire monista ongelmista. Se tarkoittaa yleensä sitä, ettei teillä ole hyvää tapaa tarkentaa loppukäyttäjän hyväksymiskriteerejä.

Sanoisin, että jos UX-suunnittelijasi, kehittäjäsi, ylläpidon asiantuntijat ja testaajasi alkavat väitellä demo-palaverissa ominaisuuksien oikeellisuudesta, ohjelmistokehitysprosessissanne on paljon tarpeetonta koodia ja teknistä velkaa. Ohjelmistoprojekteissa tästä velasta käytetään yleisesti nimitystä ”hukkaa”.

Demo-palaveria tulisi käyttää katselmointivaiheena, jossa tarkistetaan työkohtien DoD. Samalla voit näyttää toimitettavan kokonaisuuden loppukäyttäjille ja kerätä palautetta tulevia sprinttejä varten.

Suunnittelu on kuollut – vaan ei kuitenkaan

Kehittäjänä ja automatisoidun testauksen asiantuntijana olen kokenut Agile-transformaatiot kantapään kautta. Kun Agile-evankelistat ovat ”lähteneet rakennuksesta” ja todenneet, ettei ”teknistä ja määrittelyihin keskittyvää ennakkosuunnittelua” tarvita (olemme kaikki kuulleet tämän ennenkin...), jäät melko avuttomaan tilanteeseen. Miten kohdistat päivittäisen työsi ja viestit selkeästi siitä, mitä liiketoiminnan näkökulmasta pitää tehdä, jotta ominaisuudet ja epicit ovat valmiita demoihin?

Ja muista: User Story ei ole määrittely!

Ongelmat korostuvat entisestään, kun yrität saada varsinaisen releasen ulos. Viestintä alkaa pyöriä päästä päähän -käyttötapausten ympärillä, vaikka sinun pitäisi viimeistellä release. Tässä vaiheessa nämä pohdinnat ovat yleensä jo liian myöhäisiä.

Viestintä on toki helpompaa, kun loppukäyttäjäpalvelun tai -tuotteen parissa työskentelee alle kaksikymmentä ihmistä, kaikki sidosryhmät mukaan lukien. Mutta jos ihmisiä on enemmän, voin kertoa, ettei määrä tuo onnea.

Ilman selkeää visiota eli loppukäyttäjän DoD:tä Agile-menetelmällesi (Scrum tai Kanban) kehitystyöltäsi puuttuu tarvittava fokus. Lisäksi tiimeiltäsi puuttuu selkeä suunta.

Sekasotku, joka syntyy, kun koko järjestelmälle ei ole selkeää tavoitetta

Jos tämä kuulostaa tutulta, suunnittelussasi on todennäköisesti parannettavaa. Puutteelliset määrittelyt ja niiden Agile-mukaisen varmistamisen työkalujen puute – eli liiketoimintatason ja loppukäyttäjälähtöisen testiautomaation puuttuminen – hidastavat sinua, vaikka niiden ei enää pitäisi olla esteenä.

Korostan vielä asiaa. Jos suunnittelusi on sekaisin, annat ihmisille tilaa tehdä oletuksia, ja se on vähintäänkin riskialtista. Tekniset ongelmat eivät yleensä ole varsinainen ongelma, vaan liiketoimintavaatimukset ja niiden testaaminen.

Selkeä merkki siitä, että teette ”mini-vesiputousta” tai ”Scrum, But” -mallia, on se, että toteutus ja testaus tehdään eri sprinteissä ilman selkeitä toiminnallisia määrittelyjä Word-dokumentin luettelomerkkien lisäksi.

Kukaan ei halua tästä syntyvää hukkaa ja teknistä velkaa. Projektia voi pyörittää näin jonkin aikaa, mutta lisämuutosten tekeminen sen päälle johtaa lopulta käyttökelvottomaan ja toimimattomaan järjestelmään.

Koska DevOps pyrkii poistamaan hukkaa

DevOps-kirjallisuudessa toistuu jatkuvasti yksi teema: hukan poistaminen. Täysin väärän asian tekeminen on suurin hukan aiheuttaja eikä se ole kenenkään etu!

Jos suunnittelu on puutteellista, tarvitset menetelmiä ja työkaluja loppukäyttäjäarvon validoimiseen sekä mahdollisimman nopeaan arvon testaamiseen.

Specification by Example Gherkinin ja Robot Frameworkin avulla

Jos ohjelmistokehittäjät eivät panosta riittävästi määrittelytyöhön, lopputuloksena on valtavasti hukattua aikaa ja rahaa.

Tarvitset määrittelyjä myös Agile-maailmassa! Tärkeintä on kuitenkin tämä: ne on laadittava niin, että ihminen ymmärtää ne. Tekniset määrittelyt on kyettävä välittämään loppukäyttäjille ja heidän kanssaan on tehtävä yhteistyötä – tämä on Agile-menetelmien ytimessä. Erityisesti suurissa ja monimutkaisissa organisaatioissa, joissa kaikki eivät ole ohjelmistokehittäjiä.

Specification By Example (SBE) auttaa muodostamaan selkeän käsityksen ongelmasta ja löytämään siihen ratkaisun.

1. Yhdistä SBE ja Design Thinking, jotta voit tutkia ja valita hyvän ratkaisun validoituun liiketoimintaongelmaan.

2. Tuloksena saat loppukäyttäjien käyttäytymisen dokumentoituna Gherkin-syntaksilla (Given, When, Then). Aloita muutamalla "aurinkoisella tapauksella".

3. Kun olet pitänyt työpajan näistä Gherkin-muotoisista käyttötapauksista, sinulla on selkeä käyttäjäpolku toteutettavaksi ja testattavaksi.

Seuraavaksi pääset hyödyntämään avainsanaohjatun testauskehyksen, kuten Robot Frameworkin, voimaa ja helppoutta. Voit automatisoida näiden vaiheiden taustalla olevat toiminnot, jolloin saat järjestelmänlaajuisen E2E-testitapauksen, joka toimii samalla liiketoimintavaatimusten määrittelynäsi!

Nyt käytössäsi on Acceptance Test Driven Development (kuva 2)! Tästä hyötyvät muutkin kuin testauksen ja QA:n asiantuntijat: koko projektilla on nyt selkeä tavoite, jota kohti edetä.

Yhteinen ymmärrys tuo tehokkuutta ja fokusta kehitystyöhön.

Selkeä Definition of Done tuo fokusta

Kokemukseni mukaan sprintin suunnittelu ja toteutus sujuvat erittäin hyvin, kun toiminnallisia ja teknisiä määrittelyjä käsitellään näin.

Erityisesti sprintin aikana rauha ja fokus ovat vihdoin mahdollisia, kun DoD saavutetaan ennen Demoa/Review'tä. Jotta tämä työnkulku toimii tiimissäsi, se vaatii paljon kurinalaisuutta jokaiselta sidosryhmältä – kyllä, erityisesti Business Ownerilta ja Product Ownereilta. Koulutusta tarvitaan kaikille osapuolille. Etenkin alussa sidosryhmien kannattaa järjestää ensimmäiset työpajat kasvokkain.

Olemme aina valmiita auttamaan. Ota yhteyttä, jos tarvitset apua hukan vähentämisessä.