Trendisanahelinää

Ohjelmistokehityksestä pitää saada trendikästä hinnalla millä hyvänsä. On valittava muodikkaita termejä kuvaamaan kehityksen toimintatapoja ja ennalta sovittuja prosesseja. Ollaan ketteriä kehittäjiä ja käytetään uusimpia web 2.0 tai jopa 3.0 (?) työkaluja, mutta kuinka käykään todellisuudessa? Katsotaanpa asiaa tavallisen ohjelmistokehittäjän tai vaikkapa testaajan silmin.

Ketteryys on kommunikaatiota. Huippuunsa hiottua, tehokasta ja tuottavaa.

Ongelmia ei puida pitkissä sähköpostiketjuissa, puhelinpalavereissa ja hyväksyntäprosesseissa. Ne pitäisi pystyä ratkaisemaan siltä seisomalta, tekemällä yhteistyötä ongelman ratkaisemiseksi, ei sen dokumentoimiseksi. Kuinka juuri sinun projektissa toimitaan kun testaaja törmää ongelmaan?

Tyypillisesti vika tai virhe dokumentoidaan ensimmäisenä virheidenhallintajärjestelmään ja ilmoitetaan siitä error managerille, jos muistetaan. Dokumentointi tehdään käsin ja se vie aikaa. Testit seisovat ja suorituspaineet kasaantuvat. Raportointi unohtuu helposti tai se jätetään vaiheeseen, jossa kaikki määrätyt testit on ensin ajettu. Täytyy olla tuottavia, muka ketteriä.

Kun vika on lopulta raportoitu, error manageri määrää vian selvitettäväksi kehittäjälle. Kehittäjä alkaa ihmetellä asiaa siinä vaiheessa, kun muistaa tarkistaa sähköpostin “defect notifications” -kansion. Jos virhe on käsin naksuteltu virhetietokantaan raportti on yleensä osin puutteellinen tai perustelematon. Siitä saattavat puuttua oleelliset logitiedostot tai askeleet virhetilanteeseen pääsemiseksi. Korjaaminen unohtuu kun ei jaksa lähteä selvittämään alkuperäistä ongelmaa. Onko tämä ketterää vaikka niin itselle uskotellaan?

Miksei asiaa voisi hoitaa todellisuudessakin ketterämmin? Raportoidaan ongelmasta mahdollisimman toimivalla kommunikointikanavalla. Laajakaistalla. Jos ajatellaan kommunikaatiokanavien nopeuksia modeemista 100megaiseen laajakaistaan, voitaisiin ketteryyttä tai kommunikaatiota käydä mittaamaan samalla skaalalla.

Virheiden perinpohjainen dokumentointi ja siitä informoiminen sähköpostitse prosessin mukaisesti on yleensä hidasta. Asetetaan tälle toimintatavalle kaistanleveydeksi 56.6kbps. Virheen voi myös raportoida suoraan kehittäjälle.

Vetämällä kehittäjää hihasta ja näyttämällä, että näin virhe tapahtuu ja näin softa kaatuu. Kommunikaation kaistanleveys on tällöin huipussaan. 100mbps.

Välimuotojakin toki on. Asia voidaan hoitaa esimerkiksi puhelimella (512mbps) tai pikaviestimellä (384kbps).

Jos yhteisesti sovittu toimitatapa vaatii dokumentointia ja prosessia, olisi hyvinkin mahdollista valita ensisijaisesti nopein yhteys. Viestin mentyä perille se voidaan varmentaa jollain hitaammalla välineellä kun aikaa on. Tai mikä vielä parempaa: Jos organisaatio on oikeasti mukautumiskykyinen ja ketterä, ottaa käyttöön työkaluja ja apuvälineitä joilla voi automatisoida varmennusväylän.

Kun sinä valitset kotiisi laajakaistaa, eikö olisikin järkevintä valita nopein… varsinkin jos se on kaiken hyvän lisäksi vielä halvin? Ohjelmistokehitykseshän näin käy.

Nopein ratkaisu tulee myös kustannuksiltaan kaikkein halvimmaksi, tuottavimmaksi ja oikeasti ketterimmäksi.