Olen ollut viimeisen vuoden aikana siinä mielessä kiitollisessa asemassa, että lähes jokaisen projektin osalta olen päässyt järjestelemään työtapoja mieleni mukaan. Yksi jo vuosia rassannut ongelma on ollut loppuvaiheen viimeistely ja bugien korjaaminen. Aikoihin en ole joutunut tilanteeseen, jossa sähköpostitse lähetellään päivittyvää exceliä, jonka viimeisimmästä versiosta ei ole havaintoa ja jonka kaikki muutokset on merkitty eri värisin kentin. Halusin kuitenkin päästä eroon kaikesta ylimääräisestä, joten mietin homman siltä kannalta uudelleen.
Edellä mainitsemani excel -säätämisen lisäksi olen päässyt tutustumaan myös järjestelmäsäätämiseen, jossa toinen toista monimutkaisempiin järjestelmiin luodaan tikettejä, joita ratkotaan kun tulee aikaa.
Pyörähän on pakko keksiä ajoittain uudestaan, mutta tällä kertaa lähdin yksinkertaisesti vanhoilla opeilla, mutta uudesta kulmasta. Bugithan on kuitenkin pakko korjata, joten miksei sitä tekisi mahdollisimman tehokkaasti? Kun excel- ja järjestelmäsäätäminen yhdistetään kiihkeään haluun toimia ketterissä iteraatioissa samalla pyörittäen muita projekteja, niin lopputulos on odotusten mukainen. Valmistuvat projektit jyräävät korjailut ja rikkinäinen tuote on kaikkien nähtävillä kohtuuttoman pitkään.
Sen sijaan päätin tehdä jotakin toisin. Kun testaushetki koitti, vihelsin scrumin poikki ja lopetin sprinttien pyörittämisen. Sen sijalle otimme tiimissä käyttöön kanban -taulun Trellosta, johon luotiin yksinkertaiset listat:
- Havainnot ja puutteelliset kortit
- Työn alla
- Lisätty kehitysversioon
- Asennettu testipalvelimelle
- Hyväksytty
Taulun jaoin kehittäjille, projektipäälliköille, testaajille ja asiakkaan edustajille. Työtapana puolestaan toimi vanha kunnon bugiraportointi, jossa
- Kuvataan testitapaus
- Kerrotaan odotettu lopputulema
- Kerrotaan oikea lopputulema
- Lisätään kuvat, linkit ja mahdolliset muut dokumentit.
Huolimatta siitä, että tiimin eteneminen muilla saroilla hidastui, oli kaikille ilmeistä, että bugien korjaaminen oli ensisijainen tehtävä. Läpi koko organisaation oli näkyvissä kuka tekee mitäkin ja missä vaiheessa mennään. Trellon tiketit mahdollistivat keskustelun tekijöiden kesken. Kun lista oli riittävän lyhyt, siirryttiin takaisin normaaliin päiväjärjestykseen.
Asiakkaan kannalta tilanne oli perinteistä kiitollisempi, koska illuusioita etenevästä sprintistä ei ollut ja tämä voitiin kommunikoida ajoissa myös muille sidosryhmille, sekä koko homma oli läpinäkyvää. Projektinjohdon kannalta priorisointi oli niinikään helpompaa ja asiakkaan kanssa välit eivät päässeet kuumentumaan.
Mitä opimme?
- Riittävän yksinkertainen järjestelmä tukee asiakastakin olemaan osa prosessia
- Tiimi kokee olevansa yhteydessä päätöksentekijöiden kanssa
- Korjaukset on helppo todentaa tehdyiksi ja arpominen sen kanssa mikä on tehty ja mikä ei jää pois.
Mitä jäi parannettavaa?
- Isommissa yrityksissä järjestelmäsäätämistä ei voi täysin välttää ja eräässäkin projektissa päällekkäisyyttä tuli hieman.
- Tiimi lähti jopa liiankin etukenossa korjaamaan turhan vähäarvoisia bugeja, jos priorisoimaan ei ehtinyt.
