Olen pöytälaatikkoprojektinani - muun ollessa vielä korkeampaa prioriteettiä - tutustunut aktiivisesti määrittelyyn esimerkein, SBE - Specification by Example, ja siinä erityisesti Cucumber/Gherkin -tyyliseen määrittelemiseen. Elävän dokumentaation - määrittelyn ja testiautomaation - yhdistämisen konsepti on varsin houkutteleva nykyiseen projektien kuukausirytmiin.
Minulla on tähän tutustumiseen oikeastaan kaksi motivaatiotekijää. Toinen lähtee siitä, että tiimini kehittäjät voivottelevat aika usein tehtävänantojensa epämääräisyyttä, ja tämä voisi olla tapa määrittää tarkemmin mitä muutosta esimerkein tavoiteltiinkaan. Toinen lähtee siitä, että kuukausisyklissä sekoaa, jos ei jotenkin saa sitä testiautomaatiota kuvioon ja mikään "erillinen projekti" ei vielä tälläkään kertaa tule kestämään elossa tiimini kanssa. Niinpä siis mietin aktiivisesti määrittelyn ja testiautomaation yhdistämistä.
Kirjoitin ihan lähiaikoina ensimmäisen kokonaisen esimerkkini ominaisuudesta ja laadin yleensäkin listan ominaisuuksista joita kyseiseen alueeseen voisi liittyä. Ajatukseni on, että sen sijaan että vielä koittaisimme tuotepäälliköiden kanssa alkaa tehdä määrittelyä esimerkein kaikelle uudelle, luotaisiin ensin vähän keskustelun pohjaa nykyisestä toiminnallisuudesta.
Ensiesimerkkini osui ominaisuuteen, jota juuri opiskelin testatessani sitä. Tutkin ja selvittelin miten se käyttäytyy, ja selvitellessäni kyselin toteuttajalta tarkoituksesta. Ja kirjasin esimerkiksi sen mitä opin. Testausheuristiikkoja vasten - yhdenmukaisuus - ominaisuus toimii ilman logiikkaa. Kyseisessä ominaisuudessa seurataan muutoksia kokonaisuuteen, ja nykytoiminnallisuuden mukaan kokonaisuuden muuttamista seurataan, mutta osan muuttaminen ei ole kokonaisuuden muuttamista. Ja muuttaminen muuttamalla on eri asia kuin muuttaminen poistamalla.
Näytin esimerkkiä projektipäällikkö / tuotepäällikkötasolla. Ensireaktio oli kysymys siitä kenen tälläisiä pitäisi laatia ja ajatus siitä, että ei näin tarkkaan tarvitse ainakaan kertoa ominaisuuksista tuotepäälliköiden toimesta. Mutta, mahtaa olla tuskaista jos ei kerrota, ja sitten lopulta minä testatessani speksaan kaikenlaista, mitä speksissä olisi alkujaan pitänyt / voinut ottaa huomioon.Tuotepäälliköt luottavat tiimiin toteutuksen yksityiskohdissa, koska yksityiskohtainen keskustelu vaatisi aikaa jota ei ehkä olekaan varattuna. Joskus luottamus palkitaan hyvällä toteutuksella. Ja joskus saa jotain vähän sinne päin. Mutta onneksi kaikkea voi vähitellen sitten muuttaa ja korjata.
Toisaalta oma ensireaktioni oli, että nämä asiat itse pienemmällä työmäärällä nostaisin bugiraportteina siitä että mitä erilaisia heuristiikkoja sitten emme noudattaneet tai millä tapaa toiminnallisuus vaan on käyttäjän perspektiivistä käsittämätön. Toisaalta pelkään, että en olisi tarpeeksi hyvä osatakseni myöskään ajatella noita asioita ilman toteutettua tuoteversiota, joka inspiroi minua testaamaan ja tutkimaan käyttötilanteen kannalta.
Meitä on kehitystiimissä vähän ja edestakaisin kirnuaminen syö motivaatiota sekä vähäisiä voimavarojamme. Jatkan siis hetken pöytälaatikkoprojektina ja esimerkein selvittelyä sen osalta miten tätä meillä saadaan oikeasti käyttöön.
Lupaan julkaista lähiaikoina speksit "nykytoiminnallisuudesta" ja "tavoitellusta toiminnallisuudesta". Ja muutenkin pitäisi kirjoittaa enemmän siitä, mitä olen jo tähänkin mennessä oppinut siitä kuinka tälläisiä speksejä yleensäkään kirjoittaisi.
Ei kommentteja:
Lähetä kommentti
Huomaa: vain tämän blogin jäsen voi lisätä kommentin.