Miten ketterä ohjelmistokehitys ja dokumentointi sopivat yhteen? Varsin hyvin, kunhan dokumentointia tehdään aidosti tarpeesta eikä vain dokumentoinnin ilosta. Lue tarkemmin, miten dokumentointi ketterästi onnistuu.
”Ketteryyshän on hei sitä, että mitään ei dokumentoida, heh heh”
Sieltä se tuli taas, säännöllisesti kuin ruuhkapäivän bussi. Tämän irvailun tai jonkin sen variantin kuulee melkein aina jonkun erehtyessä mainitsemaan ketteryyden korporaatiovetoisessa ohjelmistokehitysmaailmassa. Väliin sen kuulee kehittäjiltä, toisinaan ns. bisneksen edustajilta, silloin tällöin huolestuneelta asiakkaalta, mutta lähes aina sen kuulee joltakulta.
Dokumentaatio on ohjelmistokehityksessä aina ollut vähän vaikea aihe. Ennen kuin tehostamisgurut siivosivat heidät organisaatiouudistuksissa ja kehityksen ulkoistamisissa pois alan yrityksistä, meillä oli itse asiassa dokumentaatioon perehtyneitä ammattilaisia, teknisiä kirjoittajia, jotka olivat opetelleet tälle tehtävälle olennaiset taidot, kuten salatieteeltä kuulostaneen teknisen leksikografian.
Nämä dokumentaation iskurityöläiset olivat päävastuussa merkittävimmän dokumentaation laatimisesta. Heidän olemassaolostaan huolimatta kipukohtia oli ja usein erityisesti siellä, missä dokumentointia odotettiin ohjelmistokehittäjiltä. Näitä ongelmia käsitelleissä tarinoissa algoritmisesti orientoituneet koodarit inhosivat aina luontaisen kielen kirjoittamista ja jättivät dokumentoinnin säännönmukaisesti viimeiseksi. Sitten he upottivat dokumentointiin budjetoidun ajan kaikkeen muuhun, ensin koodinsa parantamiseen ja sitten kiillottamiseen.
Yllä olevasta voidaan päätellä, että dokumentaatioon liittyy joitakin sellaisia ongelmia, jotka eivät ole erityisiä ketterälle kehitykselle.
Palataan dokumentaation yleisiin ongelmiin kohta, kun kerron miten ketterä lähestymistapa aihetta käsittelee ja miksi se on tässäkin kehitystyön kulmassa tavoiltaan paras ja kaunein. Haluan kuitenkin ensin (jälleen kerran) murtaa tätä yleistä myyttiä ketterän kehityksen suhtautumisesta dokumentaatioon.
Myytti on peräisin ketterän ohjelmistokehityksen julistuksen (omaa sukua Agile Manifeston) virhetulkinnasta. Julistuksen ensimmäisellä sivullahan meillä on tekstinä (johon olen merkinnyt tämän asian kannalta olennaiset kohdat alleviivauksin ja korostuksin):
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Lähtiessämme purkamaan lukemaamme, voimme havaita, että ohjelmistokehityksen ketterässä maailmassa on opittu arvostamaan toimivaa järjestelmää (siis eheäksi ja oikeasti käyttäjiä palvelevalla tavalla toimivaksi kehitettyä koodia) enemmän kuin kattavaa dokumentaatiota. Tähän liittyy vielä julistuksen loppuosa, jossa eksplisiittisesti (siis tavalla, jossa nuoriso käyttäisi helposti ns. aggressiivi-muotoa) sanotaan, että myös julistuksen oikealla laidalla olevalla asialla, tässä tapauksessa kattavalla dokumentaatiolla, on arvoa.
Tarkkaavainen lukija lienee myös tässä vaiheessa huomannut, että olen julistuksen avainkohdasta esittämässäni käännöksessä kovasti koettanut painottaa sanaa ”kattava”. Jotta julistuksen tarkoitukset tässä yhteydessä voitaisiin ymmärtää kunnolla, täytyy muistaa millaista kehitystyö oli ennen siirtymistä ketterään lähestymistapaan (tai siihen, että ketteräksi kehitykseksi ruvettiin kutsumaan aivan luokattoman huonosti valmisteltuja suunnitelmavetoisia projekteja).
Suunnitelmavetoiset projektit ovat lähtökohtaisesti vaiheistettuja ja vaiheportitettuja. Ohjelmistoprojektien maailmassa varhaisemmista vaiheista syntyy tyypillisesti dokumentteja. Ensin vaatimusmäärittely, joka hyväksytään, leimataan, nuijitaan pöytään ja sinetöidään myöhempien vaiheiden pohjaksi. Vaatimusmäärittelydokumentin pohjalta kirjoitetaan funktionaalinen määrittelydokumentti, jossa kerrotaan miten järjestelmän tulee toimia, saatetaan antaa sen tietomallit jne. Sitten sille tehdään projektinhallinnan konklaaveissa samat temput kuin tehtiin vaatimusmäärittelylle, yksinkertaisesti sanoen se hyväksytään ja jäädytetään ennen kuin edetään seuraavalle suunnittelun vaiheelle, jossa syntyy taas lisää dokumentteja.
Näissä projekteissa ohjelman toteutuksen pitäisi olla verrattain yksinkertainen asia, kun toteutuksessa ei tarvitse tehdä muuta, kuin uudelleen muotoilla olemassa olevat määrittelyt formaalilla kielellä, jolloin tuloksena on toimiva järjestelmä. Aivan näin se vain ei valitettavasti ole useinkaan mennyt, mutta se on tämän päivän epistolaan nähden jo toinen tarina.
Toteutusta seuraa suunnitelmavetoisessa työskentelyssä testausvaihe, jossa varmistetaan järjestelmän toteuttavan kaikki määrittelyt oikein ja sitten se voidaankin ottaa käyttöön. Luonnollisesti testausta varten on pitänyt kirjoittaa testisuunnitelmat ja tulokset dokumentoidaan testauskertomukseen. Käyttäjiä varten kirjoitetaan toki myös omat dokumentaationsa siitä, miten järjestelmää olisi tarkoitus käyttää.
Kuten edellä kuvatusta näkyy, syntyy vaiheistetussa projektissa ohjelmistojärjestelmästä tolkuttoman paljon dokumentaatiota. Kokemusperäisesti oli julistusta kirjoitettaessa jo opittu, että kaikesta tuosta dokumentaatiosta hyvin pieni osa oli järjestelmien tekemisessä aidosti arvokasta ja vielä vähemmän näistä dokumenteista oli vastaanottajilleen hyötyä tekemisen jälkeen.
Julistuksessa erityisesti nämä määrittelydokumentit ovat sitä dokumentaatiota, johon nähden toimiva järjestelmä on tosiaankin ensisijainen. Tämä ei kuitenkaan missään tapauksessa tarkoita, ettemme haluaisi ketterässä kehityksessä dokumentoida tekemäämme. Me vain suhtaudumme dokumentaatioon samoin, kuin suhtaudumme kaikkeen muuhunkin järjestelmäkehitykseen liittyvään työhön eli haluamme tehdä siitä vain olennaisen ja sen, jolla on arvoa tämän työn tulosten vastaanottajille.
Olen viime kuukausina taas päässyt ihmettelemään enemmän ohjelmistojärjestelmien kehitystä koskevia tarjouspyyntöjä. Näissä RFP-dokumenteissa (niinpä niin…) itselleen jotain uutta tai sitten vanhan kehitystä tarvitseva taho kertoo oman yrityksemme kaltaisille toimijoille, että nyt olisi keikkaa tarjolla, kysyen samalla pystyttekö tämmöisen näillä reunaehdoilla kehittämään ja mihin hintaan.
Dokumentaatiotyön kannalta RFPt ovat useimmiten masentavaa luettavaa. Dokumentaatio esitetään yleisenä reunaehtona, mutta toki ehdottomana vaatimuksena. Esitys tulee jotakuinkin muodossa ”järjestelmästä tulee kirjoittaa riittävä ja asianmukainen dokumentaatio”. Tämähän ei kerro kenellekään sitä, mitä oikeasti pitäisi dokumentoida ja millaista arvoa dokumenttien odotetaan tuottavan, mutta koska tarjouksissa ja niistä keskustelussa jyllää vahvasti ”Keisarin uudet vaatteet”-ilmiö, eivät tarjouksien laatijat kehtaa nostaa aiheesta kissaa pöydälle.
Niinpä tarjouksen voittaneen tahon projektipäällikköparka sitten tuskaileekin jonain iltana miettien mitä kaikkea järjestelmästä pitäisi dokumentoida ja illan hiipiessä lähemmäs puolta yötä kirjoittaa epätoivonkyyneleet poskilla valuen projektisuunnitelmansa loppupuolelle ”Tehty järjestelmä dokumentoidaan ja dokumentit annetaan asiakkaalle katselmoitaviksi, kesto 5 htp” tai vaihtoehtoisesti arvelee, että vaiheittain edettäessä syntyvät suunnitteludokumentit varmaankin ajavat asian ja käsittelee näitä vaiheporttien dokumentteja sitten projektityössään, kuin hukkuva pelastusrengasta.
Palaamme nyt siihen dokumentaation perusongelmaan, johon viittasin jo aiemmin tässä blogissa. Tiedämme, että riippumatta siitä yritetäänkö projektissa edetä suunnitelmavetoisesti tai jollain tapaa ketterästi, jää dokumentaatio usein syntymättä ja silloin kun sitä syntyy, on laatu usein vaihtelevan tasoista.
Väitän dokumentaation huonon tilan johtuvan pitkälti siitä, että edes projektia suunniteltaessa, silloin kun dokumentaatiota keksitään vaatia, ei sille nähdä eikä määritetä mitään selkeää arvoa. Suhtautuminen dokumentaation tekemiseen on tällöin suunnilleen sama, kuin se, miten usein lähestymme kodinhoidollisia töitä. Sauna kuuluu pestä siinä karmeassa joulusiivouksessa, jonka hyvä ihminen tekee ennen tätä juhlista rakkainta ja kunnon emäntä uusii keittiön hyllypaperit reunapitseineen kevätsiivouksessa. Martat ovat jo pidempään ohjeistaneet joulusiivouksessa siivoamaan sen, mikä on juhlimiselle olennaista ja armahtamaan itsensä siitä muusta, jota tehdään vain koska ”niin kuuluu tehdä”. Ketterä kehitys pyrkii suhtautumaan ja suhtautuu dokumentaatioon suunnilleen tähän samaan tapaan, jolloin keskeiseksi kysymykseksi nousee dokumentaatiolla tavoiteltu ja tuotettava arvo.
Ketterässä kehityksessä on huomattava, että laajat määrittelyt ja isot tekemistä edeltävät suunnitelmat eivät lähtökohtaisesti kuulu ollenkaan normaaliin työhömme. Tämä tarkoittaa myös sitä, että ne laajat, etukäteen tehtävät järjestelmää kokonaisuutena esittävät määrittelydokumentit putoavat lähtökohtaisesti pois. Erityisen vahvasti tämä korostuu sellaisessa ketterässä kehityksessä (jota valtaosan ketterästä kehityksestä toki pitäisi olla), jossa seurataan Leanin ohjelmistokehityksen periaatteita.
Ketterässä kehityksessä suositaan ”vaatimusmäärittelyssä” tällä haavaa aika laajalti extreme programmingista lainattuja käyttäjätarinoita mieluummin kuin perinteisiä vaatimuksia. Käyttäjätarinat tarjoavat erinomaisen lähtökohdan myös dokumentaation tekemiseen. Käyttäjätarinassahan ideana on kuvata järjestelmältä tarvittavaa toiminnallisuutta jonkun oikean käyttäjän näkökulmasta ja mielellään vielä perustella tuon toiminnallisuuden tarve hänen näkökulmastaan. Tämän kuvion kaikille tuttu kaavahan kuuluu:
käyttäjäroolissa voin/haluan tehdä jotain, koska mitä hyötyä tällä saavutetaan.
Jos määrittelemme dokumentaatiotarpeet tällä samalla mallilla, pystymme paitsi poistamaan projektista turhan dokumentaatiotyön, niin myös tuottamaan aidosti aiottuja käyttäjiään palvelevaa dokumentaatiota.
Jotta tämän mallinen dokumentointitarpeiden määrittely olisi mahdollista, on meidän tunnistettava käyttäjärooleja, joille dokumentaatio on merkittävää. Esimerkkejä tällaisista rooleista voidaan löytää helpostikin, mutta aavistuksen vaikeampaa on varmistua siitä, että kaikki tällaiset persoonat on huomioitu. Tässäkin ongelmassa voimme kuitenkin tukeutua ketterän kehityksen perusperiaatteisiin eli jos järjestelmän kehittäjät ovat jatkuvasti (tai ainakin jatkuvahkosti) tekemisissä sen käyttäjien kanssa, tulevat jälkimmäisten tarpeet ensimmäisten tietoon.
Muutamia selkeitä kohdepersoonia voidaan kuitenkin löytää helposti tukeutumalla pelkästään ohjelmistokehitystä koskevaan yleistietoon. Näitä ovat:
Uuden kehittäjän tarpeet liittyvät oletusarvoisesti järjestelmään tutustumiseen ja sen arkkitehtuurin oppimiseen. Hänelle on merkittävää saada tietää mistä asiasta mikäkin lähdekoodimoduuli on vastuussa, ja mistä päin lähdekoodia nämä asiat löytyvät. Esimerkki hänelle tyypillisestä tarinasta voisi olla:
Uutena kehittäjänä haluan saada dokumentaatiosta nopeasti selville sen, missä toiminnallisuuden X toteuttava koodi sijaitsee, jotta voisin työskennellä nopeasti ja tehokkaasti tuhraamatta aikaani tämän lähdekoodin etsimiseen.
Tässä esimerkissä tarina on myös kirjoitettu tarkasti toiminnallisuudelle X, koska ketterän tekemisen periaatteiden kautta tiedämme, että pienten ja käyttäjää palvelevien asioiden tekeminen on isojen kokonaisuuksien tekemistä helpompaa. Se ei tokikaan tarkoita sitä, etteikö tarinaa voisi toteuttaa päivittämällä sellaista dokumenttia, joka kuvaa saman asian kaikille toiminnallisuuksille, mutta kun tarina koskee vain yhtä toiminnallisuutta, se voidaan saada nopeasti valmiiksi ja ymmärtää helposti niin kehityksessä kuin katselmoinnissakin.
Toisenlainen tarina on kyseessä, kun tarkastellaan tietoturvaa edistävän auditoijan roolia. Auditoinnissahan etsitään evidenssiä siitä, että järjestelmään on oikeasti toteutettu tietoturvaa ja se on vieläpä tehty oikein. Auditoijaa ajatellen kehitysjonoon voi hyvinkin siis ilmaantua käyttäjätarina:
Tietoturva-auditoijana haluan todeta dokumentaatiosta, että järjestelmä on suunniteltu Privacy by Design -periaatetta noudattaen, nähdäkseni suunnittelun noudattavan myös arvopohjaisesti yleisen tietosuoja-asetuksen vaatimuksia.
Tämä tarina on itse asiassa epicin kokoinen, sen koko ylittää moninkertaisesti yksittäisten käyttäjätarinoiden koon ja sen toteuttaminen joudutaan scrumia tehtäessä jakamaan lukuisille sprinteille – itse asiassa jokaiselle eli jatkuvaksi – työksi. Tarina toimii myös loistavana aasinsiltana seuraavaan tapaan, jolla ketteryydessä hoidetaan dokumentaatiovaatimuksia: hyväksymiskriteereihin.
Tämän esimerkin tietoturvan auditoijan tarina on nimittäin parhaiten toteutettavissa järjestelmän toiminnallisuuksia koskevissa käyttäjätarinoissa, joissa sen toteutuminen käsitellään hyväksymiskriteerinä. Esimerkiksi seuraavasti:
Ostajana haluan syöttää tilaukseni toimitustiedot järjestelmään mahdollisimman helposti, saadakseni tilauksen tehtyä pienimmällä mahdollisella vaivalla
Tälle tarinalle sitten täytyy määritellä hyväksymiskriteerit:
Tämän esimerkin mukaiset valmiin määrittelyt määritellään toki yleensä yhteisesti kaikille käyttäjätarinoille, ei yksittäisille. Se mitä tällä haetaan, on laadun sisään rakentaminen. Määrittelemme eksplisiittisesti mitä kaikkea täytyy olla tehtynä, jotta jokin järjestelmän osa olisi kunnollisesti tehty. Teemme tämän määrittelyn myös aina niin pienille osille, että sekä toiminnallisuus, että siihen olennaisesti kuuluvat muut tuotokset eli testit ja dokumentit tulevat tuotetuksi nopeasti toiminnallisuutta kehitettäessä.
Tätä samaa lähestymistapaa voidaan soveltaa myös moniin muunkinlaisiin vaatimuksiin kuin dokumentaatioon, mutta tänään käsittelemme ketterää dokumentaatiota.
Kun ketterää työtä päätetään tehdä ns. ”aikuisten oikeesti” eli tosissaan, hyväksymiskriteereistä otetaan irti paljon enemmän, kuin vain kuvauksia. Hyväksymiskriteerit voidaan jalostaa testimäärittelyiksi ja kun päästään oikeasti vauhtiin, testimäärittelyt voidaan jalostaa testattaviksi määrittelyiksi, joiden toteutumista testataan järjestelmässä automaattisesti.
Toimintatavan kehitys on kulkenut yksikkötestien tasolla toteutetusta testivetoisesta kehityksestä, funktionaalisten (toiminnallisuutta testaavien) testien tasolla tapahtuvaksi testivetoiseksi kehitykseksi (TDD, Test Driven Development) ja siitä edespäin järjestelmän käyttäytymistä testaavien testien varassa pyöriväksi kehitykseksi (Behaviour Driven Development), jota on nyt viimeisimpänä kehityksenä alettu kutsua hyväksymistestivetoiseksi kehitykseksi (ATDD, Acceptance Test Driven Development). Jos minulta kysytään, kaksi viimeisintä näyttävät käytännössä kovin samanlaisilta, jälkimmäinen ehkä onnistuu paremmin alleviivaamaan sitä, kuinka järjestelmällistä homman pitäisi olla.
Mitä tällä tavoitellaan on siirtymä suunnitelma- ja määrittelyvetoisesta vesiputousprojektista:
Testattavia speksejä hyödyntäviin ketteriin projekteihin:
Tässä lähestymistavassa toiminnallisuus kuvataan ensin käyttäjätarinana (kuten oikein on), mutta sen hyväksymiskriteerit kirjoitetaan BDD-syntaksilla. Tällaisten testikuvausten joukko voi olla huomattavan kattavakin, mikä monesti pelottaa lähestymistapaan tutustuvia. Sen voima on kuitenkin huomattava.
Asia hahmottuu yleensä parhaiten käytännön esimerkeillä, joten katsotaan esimerkkitarinoitamme. Otetaan ensiksi selkeä toiminnallisuutemme, toimitustietojen syöttö:
Ostajana haluan syöttää tilaukseni toimitustiedot järjestelmään mahdollisimman helposti, saadakseni tilauksen tehtyä pienimmällä mahdollisella vaivalla
Kun tälle ruvetaan määrittelemään hyväksymiskriteerejä BDD-testisyntaksilla, se voisi varhaisemmissa luonnoksissaan näyttää seuraavalta:
Testi: Toimitustietojen syöttäminen
GIVEN Ostaja on koonnut tilauksen
WHEN Ostaja siirtyy ostoskorista varsinaiseen tilaukseen
THEN Ostajaa pyydetään täyttämään nimensä
AND Ostajaa pyydetään täyttämään katuosoitteensa
AND Ostajaa pyydetään täyttämään postinumeronsa
AND Ostajaa pyydetään täyttämään postitoimipaikkansa
AND Ostajaa pyydetään täyttämään puhelinnumeronsa
AND Ostajaa pyydetään täyttämään sähköpostiosoitteensa
AND tietokentät täydentyvät selainikkunassa automaattisesti
Tässä kohtaa siis käyttäjän kanssa tehtävästä bisneksestä kiinnostunut henkilö kuvailee sitä, miten tarinan pitäisi mennä.
Meidän on kuitenkin pysähdyttävä sillä huomaamme pyytävämme ostajalta enemmän tietoja, kuin mitä ehdottomasti tarvitaan. Toimitushan onnistuu, jos meillä on käytössämme puhelinnumero tai sähköpostiosoite. (Pitäisihän sen toki onnistua postiosoitteellakin, mutta kokemuksesta tiedämme, että imoitukset asiakkaalle viivästyvät ja asiakastyytyväisyys kärsii, joten emme jää sen varaan). Tai-operaattoria meillä ei tässä syntaksissa ole käytössämme. Sen sijasta käytetään rinnakkaisia skenaarioita.
Eli A)
GIVEN Ostaja on koonnut tilauksen
WHEN Ostaja siirtyy ostoskorista varsinaiseen tilaukseen
THEN Ostajaa pyydetään täyttämään nimensä
AND Ostajaa pyydetään täyttämään katuosoitteensa
AND Ostajaa pyydetään täyttämään postinumeronsa
AND Ostajaa pyydetään täyttämään postitoimipaikkansa
AND Ostajaa pyydetään täyttämään puhelinnumeronsa
AND Ostajaa pyydetään täyttämään sähköpostiosoitteensa
AND tietokentät täydentyvät selainikkunassa automaattisesti
ja B)
GIVEN Ostaja on koonnut tilauksen
WHEN Ostaja siirtyy ostoskorista varsinaiseen tilaukseen
THEN Ostajaa pyydetään täyttämään nimensä
AND Ostajaa pyydetään täyttämään katuosoitteensa
AND Ostajaa pyydetään täyttämään postinumeronsa
AND Ostajaa pyydetään täyttämään postitoimipaikkansa
AND Ostajaa pyydetään täyttämään puhelinnumeronsa
AND Ostajaa pyydetään täyttämään sähköpostiosoitteensa
AND tietokentät täydentyvät selainikkunassa automaattisesti
BDD-syntaksi on niin lähellä luontaista kieltä, että näitä testikuvauksia voidaan käydä läpi järjestelmän varsinaisten käyttäjien ja projektin sidosryhmien edustajien kanssa. Parhaassa tapauksessa nämä sidosryhmien edustajat kykenevät myös kirjoittamaan itse näitä testispeksejä ja projektin tiimoilta niitä voidaan käyttää hyvin laajasti projektin asioista ja toiminnallisuuksista puhumiseen ja sopimiseen. Näin testispekseillä päädytään dokumentoimaan järjestelmäkehityksen oikeat tarpeet ja toiveet. Huolimatta vahvasta ilmaisuvoimastaan, BDD-speksit ovat kuitenkin muodollisia määrittelyitä ja niitä vasten voidaan kirjoittaa ne toteuttavat testit, jotka varmentavat järjestelmän toimivan aiotulla tavalla.
Kun näitä testejä sitten ajetaan automaattisesti aina buildin yhteydessä, saadaan samalla ilmainen ja jatkuva hyväksymistestauksen iterointi kehitykseen. Testitoteutukset puolestaan dokumentoivat osaltaan sitä, miten toiminnallisuutta on toteutettu, kutsuessaan toteutuksen tarjoavia järjestelmän rajapintoja.
Kerraten: testispeksit pystyvät siis dokumentoimaan järjestelmän toiminnallisuuksien hyväksymistestireunaehtoja, niitä tarkoituksia, joita toiminnallisuudella yritetään toteuttaa sekä sitä, mistä toiminnallisuuden toteutus järjestelmässä löytyy. Ihmisillä on toki erilaisia makuja, mutta minun on vaikea kuvitella montaakaan yhtä hyvää lähestymistapaa järjestelmän funktionaalisen dokumentaation esittämiseen, kuin se, jonka tämäntyyppiset testimäärittelyt tarjoavat.
Ketteryyden ja Leanin lähestymisen keskeisenä ajatuksena on paitsi keskittyä olennaiseen, myös katsoa sitä pitopöydän elefanttia rehellisesti huomioiden kaiken sen, mikä jää kärsän pään ja hännän pään väliin. Dokumentaatiota katsotaan ohjelmistotuotannossa laajasti pitäen käsiä silmien edessä ja vältellen tunnustamasta tuon työn laajuutta ja merkitystä.
Kun dokumentaatiota tehdään ketterän kehityksen periaatteiden ja tapojen mukaisesti, keskitytään siihen, mitä dokumentaatiolla tavoitellaan ja pyritään täyttämään nuo tavoitteet mahdollisimman hyvin ja tehokkaasti. Ketteryydessä on erinomaisia toimintamalleja ja käytäntöjä, joiden kautta asiaa voidaan lähestyä. Dokumentaatio on kuitenkin sillä tavoin vahva vaatimus, että jos se uitetaan projektiin sivulauseessa, kuin viekkaat varkaat ja väärät valtiaat, voidaan sillä tehdä paljon vahinkoa projektin onnistumismahdollisuuksille.
Jos yksikin tilaaja tämän blogin rohkaisemana osaa ottaa dokumentaation esiin arvoa tuottavana tekemisenä pakollisen lisän sijasta tai mikä vielä parempaa, siirtää toiminnallisen dokumentaation painopistettä dokumenteista jo itsessään arvoa tuottaviin testeihin, voin pitää tätä ulostuloa onnistuneena.
Kuulisin mielelläni miten tällaisia ajatuksia sovelletaan ”kentällä” niin digialaisilta, kuin kollegoiltamme muissakin yrityksissä.