Return to site

Viisi käytännön neuvoa: Näin teet tarkoituksenmukaisen dokumentaation ketterässä kehitysmallissa

Ketterän ohjelmistokehityksen julistus (agile manifesto) arvostaa toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota. Tämä on hyvä lähtökohta, kunhan sen vain ymmärtää oikein. Julistus ei tarkoita sitä, etteikö dokumentaatiolla olisi arvoa lainkaan tai että dokumentaatio olisi täysin turhaa. Julistus pyrkii kertomaan ennemminkin sen, että ohjelmistokehityksen tärkeimpänä tavoitteena pitäisi olla toimivan ohjelmiston rakentaminen eikä massiivisen dokumentaation tuottaminen. Ideana on korvata turhaa dokumentointia esimerkiksi kasvokkain käytävällä keskustelulla kehitystyön aikana.

"Kehitystiimi saattaa tuottaa liiketoimintakriittisen ohjelmiston ketterällä menetelmällä siten, että siitä ei käytännössä jää asiakkaalle käteen minkäänlaista käyttökelpoista dokumentaatiota."

On helppo uskoa julistuksen mukaisen lähtökohdan tehostavan ohjelmistokehitystä. Eihän dokumentaation tekeminen pelkästään dokumentoinnin vuoksi ole järkevää. Mutta joskus ketterän ohjelmistokehityksen julistuksen nimissä tehdään asiakkaalle kalliiksi käyviä ylilyöntejä. Kehitystiimi saattaa tuottaa liiketoimintakriittisen ohjelmiston ketterällä menetelmällä siten, että siitä ei käytännössä jää asiakkaalle käteen minkäänlaista käyttökelpoista dokumentaatiota. Silti kehitystiimi voi olla tyytyväinen omaan suoritukseensa. On voitu kehittää nopeasti ja sujuvasti uutta toimivaa sovellusta ja saavutettu tiimin toiminnalle asetetut tavoitteet.

Dokumentaatiota kaivataan viimeistään silloin, kun jonkun muun kuin alkuperäisen kehittäjän täytyy ymmärtää ohjelmiston sisältö sovellushallintavaiheessa. Silloin alkuperäisten kehittäjien tietotaidosta ei ole apua, sillä kehittäjät harvemmin jäävät hoitamaan sovellushallintavaihetta. Jos kehityksestä ei siirry riittävää dokumentaatiota sovellushallintavaiheeseen, ollaan tilanteessa johon yksikään yritys ei halua joutua.

" Ohjelmiston toimintaa kuvaava kokoava dokumentaatio ei ole niinkään tarkoitettu järjestelmän toiminnassa sisällä olevalle kehitystiimille, vaan erityisesti kehitystiimin ulkopuolisille henkilöille ja sovellushallintavaiheen tiimille."

On hyvä huomata, että koko ohjelmiston toimintaa kuvaava kokoava dokumentaatio ei ole niinkään tarkoitettu järjestelmän toiminnassa sisällä olevalle kehitystiimille, vaan erityisesti kehitystiimin ulkopuolisille henkilöille ja sovellushallintavaiheen tiimille. Ulkopuolisia henkilöitä voivat olla esimerkiksi asiakkaan operatiivisen toiminnan sujuvuudesta huolehtivat järjestelmävastaavat tai kehitystiimiin mukaan tulevat uudet jäsenet. Sovellushallintavaiheessa tarvitaan tietoa ohjelmistokokonaisuuden toiminnasta esimerkiksi häiriöiden selvittämiseen ja muutosten vaikutusten arvioimiseen. Ylläpito voi muuttua painajaiseksi, jos järjestelmän toiminnan ymmärtääkseen pitää lukea vaikkapa 200 sekalaisessa järjestyksessä olevaa ”user storya” ja 5000 riviä koodia. Dokumentaatiolle kannattaa siis ehdottomasti antaa arvoisensa painoarvo jo kehitysvaiheessa käytettävästä sovelluskehitysmenetelmästä riippumatta ja varsinkin silloin kun toteutetaan monimutkaista ja yrityksen liiketoiminnan kannalta kriittistä operatiivista järjestelmää.

Seuraavassa on listattu viisi käytännön neuvoa, joilla varmistat tarkoituksenmukaisen dokumentaation.

1. Tee jo etukäteen karkean tason vaatimusmäärittely koko kokonaisuudesta!

Monesti vaatimusmäärittely jää liian pienelle huomiolle uutta ohjelmistoa suunniteltaessa. Kokonaiskuvan hahmottamiseksi on tärkeää tehdä edes karkean tason vaatimusmäärittely työn alla olevasta kokonaisuudesta. Vaatimukset on hyvä ryhmitellä toiminnallisiin kokonaisuuksiin ja kokonaisuuksien suunniteltu käyttöönottoajankohta on hyvä asettaa aikajanalle.

2. Päivitä vaatimusmäärittelydokumentaatiota säännöllisin väliajoin!

Ketterässä menetelmässä vaatimusmäärittelykin muuttuu ja elää matkan varrella. On hyvä päivittää vaatimusmäärittelydokumentaatiota säännöllisesti niin, että seuraavia käyttöönotettavia toiminnallisuuksia täsmennetään, täydennetään ja muutetaan tarvittaessa.

3. Tee tarkempi käsittelysääntöjen määrittely sitä mukaa kun kehitystyö etenee!

Älä yritä tehdä kerralla kattavaa käsittelysääntöjen määrittelyä, vaan tee käsittelysääntöjen määrittely palasissa sitä mukaa kun kehitystyö etenee. Hyvä käytäntö on tehdä toiminnallinen määrittely vähän ennen kun kehitystiimi ottaa kyseessä olevan ”storyn” työn alle. Ideana on tuottaa dokumentaatiota tarkoituksenmukaiseen aikaan, ei liian yksityiskohtaista dokumentaatiota liian aikaisin!

4. Kokoa rinnalla pysyvää dokumentaatiota!

Tuota kehitystiimille dokumentaatiota sitä mukaa kun kehittäjillä on siihen tarvetta. Dokumentoinnin tulee olla siinä muodossa, mikä parhaiten edistää kehitystiimin toteutustyötä (esim. user storyt, yksittäiset taskit). Koosta samaan aikaan tästä kehitystiimille tarkoitetusta dokumentaatiosta koko järjestelmän toiminnan kattavaa kokoavaa ja pysyvää dokumentaatiota (esim. prosessikuvaukset, käyttötapauskuvaukset yms.)

5. Varmista, että teet dokumentoinnin oman organisaation tarpeita palvelevalla tavalla!

Ei ole lopulta yhtä nyrkkisääntöä millä välineellä, millä tasolla tai millä tyylillä dokumentaatio pitää olla koostettu. Voit kuvata asiat prosessikaaviona, käyttötapauskuvauksina tai jollakin muulla sinulle sopivalla tavalla. Voit kuvata tarkasti tai karkealla tasolla. Mieti tapaa valitessa, mitä lisäarvoa se tuo eri osapuolille koko järjestelmän elinkaaren aikana. Älä mieti yksin kehitystiimiä vaan myös sovellushallinnan aikana ohjelmiston kanssa työskenteleviä tahoja tätä valintaa tehdessäsi!

Kirjoittanut Reflectorin konsultti Seija Kälkäjä, jonka erikoisalaa on mm. ketteriin menetelmiin liittyvä mentorointi, vaatimusmäärittely ja määrittely. (https://fi.linkedin.com/in/seija-kälkäjä-7846057)

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly