Blogisarjamme kolmas osa valaisee kolmatta ketteryyden periaatetta. Sen ytimessä on säännölliset ja lyhyellä aikavälillä tapahtuvat toimitukset, joita tarkastellaan tässä blogikirjoituksessa niin asiakkaan kuin kehittäjänkin näkökulmasta. Kolmas onnen avain on kokonaisuudessaan:
Toimitamme versioita toimivasta ohjelmistosta säännöllisesti,
parin viikon tai kuukauden välein, ja suosimme lyhyempää aikaväliä.
Kolmas periaate on tiukasti sidoksissa kahteen ensimmäiseen. Tiimin on vaikea toimittaa aikaisessa vaiheessa ja säännöllisesti, jos toimitusten aikavälit ovat pitkiä. Lisäksi muutosten aikaansaaminen vaikeutuu, jos toimitusten väliset aikavälit kasvavat.
Kolmannesta periaatteesta löytyy kaksi tärkeää osa-aluetta:
Suunnitteluprosessi on ajateltava uudelleen, jotta tätä periaatetta päästään toteuttamaan. Koko tuotteen elinkaarta ei suunnitella kerralla, vaan tuotetta lähdetään suunnittelemaan asiakkaalle eniten hyötyä antavasta osasta ja mahdollisimman pienellä toteutuksella (Minimum Viable Product, MVP). Suunnittelua tehdään siis pienesti ja koko ajan.
Tarpeellinen dokumentaatio
Tämä tarkoittaa myös usein dokumentaation tarpeen vähenemistä, kun tiimin ei tarvitse tehdä tuotteesta kattavia vaatimusmäärittelyjä tai suunnitella ja ylläpitää projektin kokonaissuunnitelmaa tuleville vuosille. Usein riittää, että tuotteen ja inkrementtien kehitysjono ja niiden toteutus on tarpeellisella tasolla dokumentoitu.
Mikä on riittävää dokumentointia? Oikean dokumentointitason voi ratkaista vain tiimi. Kyse on yksinkertaisesti siitä, mitä tiimi ja loppuasiakas tarvitsevat toimivaan kommunikointiin ja ongelmien ratkaisemiseen. Dokumentointia pitäisi rajoittaa siihen, mikä auttaa tiimiä rakentamaan ohjelmistoa. Toinen dokumentoinnin tasoa ohjaava tekijä voi olla eri sidosryhmien, kuten sääntelijöiden, johdon tai sijoittajien, tarpeet.
Dokumentointi nojaa vahvasti tarpeeseen. Jos esimerkiksi tiimissä huomataan, että on hyödyllistä kirjoittaa toiminnallisen vaatimuksen asiakirja, tiimi voi sen tehdä ja olla edelleen ketterä. Kaikki ratkaisut tehdään tiimin ja sidosryhmien tavoitteiden kannalta parhaalla toimivalla tavalla. Tämä on yksi niistä vapauksista, joita ketteryys tuo mukanaan.
Toimiva versio
Minä pidän ensimmäistä osa-aluetta myös tärkeimpänä. Jokainen toimitettava versio tuotteesta tai palvelusta on oltava myös toimiva ja tuotantokelpoinen. Tämä ei välttämättä tarkoita, että jokainen versio olisi vietävä tuotantoon asti.
Tämä vaatii onnistuakseen sitä, että asiakkaiden, tuoteomistajien ja tiimin on opittava pilkkomaan tekemistään pienempiin osiin kuin aikaisemmin on totuttu. Asiakkaiden on myös opittava hyväksymään toiminallisuuksien jatkuva katselmointi pienemmissä erissä, koska tuotteita tai palveluita ei hyväksytäkään kerrallaan vaan osina.
Tiimille tämä tarkoittaa opettelua tekemään yhdessä kaikkia kehittämisen vaiheita samanaikaisesti. Aikaisemmin ensiksi määriteltiin, sitten tehtiin, testattiin ja siirrettiin valmis ohjelmistotuote tuotantoon. Nyt ketterässä mallissa kaikkia vaiheita tehdään päällekkäin ja limittäin. Historiaa on myös siiloissa työtä tekevät ryhmät. Nyt tiimin vastuulla on kaikki kehittämisen vaiheet, ja sen jäsenet toteuttavat kutakin tehtävää omien osaamistensa puitteissa.
Asiakkaan tai heidän edustajien on oltava tiimin saatavilla jatkuvasti ja helposti. Tällöin ei enää riitä, että alussa tehdään kattava dokumentaatio, mitä halutaan ja lopussa todetaan, että emme saaneet haluamaamme lopputulosta.
Säännöllinen toimitus
Toinen osa-alue on säännöllinen toimitus, mikä palvelee erityisen hyvin läpinäkyvyyden periaatetta. Myös LEAN opettaa, että meidän on hyvä tuottaa tuotetta tai palvelua pienissä erissä tuottavuuden parantamiseksi.
Avain myönteisten muutosten tekemiseen ilman kaaosta on toimittaa usein toimivaa ohjelmistoa. Tiimi käyttää iteraatiota katkaisemaan tekemisen säännöllisin määräajoin. Jokaisen iteroinnin lopussa tiimin hallussa on demo, jonka avulla he näyttävät asiakkaalle, mitä he ovat tehneet. Tässä vaiheessa tuotteen tai palvelun sisältöä voidaan muokata seuraaviin inkrementteihin. Retrospektiiveillä varmistetaan, että koko ajan pyritään tekemään asioita peremmin ja tehokkaammin. Ennustettavissa oleva aikataulu (iteraation pituus) ja jatkuvat tarkistuspisteet (demo) auttavat tiimiä tehokkaaseen tekemiseen ja muutosmyönteiseen ympäristöön.
Ketteryydessä on tavoitteena saada tiimi ja jokainen tiimin jäsen jatkuvasti tarkastelemaan kokonaiskuvaa ja varmistaa, että heillä kaikilla on sama tavoite. Tämä on helpompi saada aikaiseksi, kun tiimissä tehdään lyhyitä iteraatioita, joiden avulla tuotetaan toimivaa ohjelmistoa. Tämä menettelytapa antaa jokaiselle tiimissä konkreettisia tavoitteita ja paljon parempaa käsitystä siitä, mitä he toimittavat. Tällä tavalla myös tiimille rakennetaan tunne, että jokainen on vastuussa paitsi siitä, mitä on itse tehnyt, mutta myös siitä, mitä koko tiimi toimittaa iteroinnin lopussa. Näin he voivat vastata muutoksiin ja toimittaa parempaa tuotetta.