Refaktorointi, eli toimivan koodin muokkaaminen, on monessa tuotekehitysorganisaatiossa vähän vaikea asia. Usein karsastetaan ajatusta käyttää aikaa jo toteutetun koodin muuttamiseen, ja voimavarat laitetaan mieluummin uuden toiminnallisuuden tekemiseen. Tässä blogissa kuitenkin kerromme, miksi refaktorointi kannattaa.
Bugien estimoinnin sijaan projektin kannattaisi yksinkertaisesti seurata bugien inflowta ja outflowta. Lisäksi olisi hyvä ajatella, että tehtäisiin hyvää laatua mahdollisimman vähällä bugimäärällä – ennaltaehkäistään, eli siis karvataan! Bugien ennaltaehkäisy säästää aikaa ja auttaa myös välttämään turhat arvailut.
Kokoukset ovat osa nykyistä työelämää. Niissä keskustellaan ja päätetään asioita ja niitä ilman ei vaan tulla toimeen. Aika usein kokouksissa on kuitenkin paljonkin toivomisen varaa. Tässä blogipostauksessa kerromme, miksi.
Tuotekehityksessä työskentelevien olisi hyvä osata käyttää järjestelmällisen ongelmanratkaisun keinoja, sillä niiden avulla esimerkiksi mysteeribugien selvitys helpottuu ja nopeutuu huomattavasti. Ongelmanratkaisun metodiikkaa onkin syytä opetella ja harjoitella – se on todellista salapoliisityötä!
Suuren projektin käynnistyksessä on valtava työ. Ponnistuksissa on monta sudenkuoppaa, jotka hidastuttavat helposti prosessin aloittamista. Mitä isompi projekti, sitä tärkeämpää olisikin käyttää ulkoista apua!
Välillä tiimeille tulee vastaan harvinaisen hankala bugi, kuten ongelma, jota ei tiimin käytettävissä olevilla testiympäristöillä saada toistettua. Tällaisessa tilanteessa olisi tärkeää käyttää ylivoimaa bugin selvittämiseen, sillä ratkaisuun tarvitaan koko tiimin aivoja ja voimavaroja. Lisäksi porukalle olisi luotava positiivinen mielentila, jossa ihmiset ajattelevat, että juttu ratkeaa tavalla tai toisella. Ihmiset ratkovat ongelmia paljon paremmin ja tehokkaammin kun heidän ajatuksensa ja aivonsa eivät ole negatiivisilla ajatuksilla alustettuja.
Usein vastaan tuleva ongelma on se, että tiimillä on kertynyt ”verifiointivelka”, eli bugeja on fiksattu nopeammin kuin testaus pystyy niitä verifioimaan. Tässä onkin sellainen piilevä vaara, että jos tuo verifioitavana olevien bugien määrä kasvaa kovin isoksi, siitä tuleekin aikamoinen suo, kun sitä aletaan sitten myöhemmin kahlaamaan läpi. Tämä on todennäköisempää bugeille kuin tarinoille, koska agile-metodit pitävät huolen siitä, että aloitettavat tarinat ovat aika korkealla backlogilla. Lisäksi tarinat ovat usein hitaampia implementoida kuin bugifiksit.
Ketterien menetelmien yksi ultimatum on tehdä projektit tarpeettomiksi. Jatkuva työskentely on väliaikaisia projekteja tehokkaampaa, kun aikaa ei kulu turhaan joutokäyntiin ja odotteluun.
Eipä juuri enää tule vastaan tuotekehitystiimejä, joilla ei olisi käytössä jonkin sortin online-bugityökalu. JIRA on ehkä suosituin, mutta bugeja voidaan hallita myös muillakin työkaluilla. Oli tiimi sitten miten kokenut tai laatutyötä tekevä tahansa,...
Nykyään töissä tuntuu aina olevan kiire. Tuotekehitysprojektit eivät ole tästä mikään poikkeus. Ketterillä toimintatavoilla voidaan tiimiläisten kiireen tuntua vähentää, mutta toimintaa ohjaaville henkilöille, tuotteen omistajalle tai projektin vetäjälle kasautuu...
Suosituimmat ketterät toiminnanohjauskeinot ovat Scrum ja Kanban. Näistä Scrum on tuotekehityksessä yleisemmin käytössä. Scrummin pääetu Kanbaniin verrattuna on se, että fiksatun mittaisissa iteraatioissa on helpompi mitata tiimin nopeutta, velocityä, ja sitä kautta ulottaa ennustettavuutta pitemmälle tulevaisuuteen. Scrummin iteraatiot myös pakottavat tiimin tekemään suunnitelmia ja retrospektiivejä. Jo käynnissä olevaan Scrum – sprinttiin ei kuitenkaan yleensä ole hyvä lisätä mitään, joten tyypillisesti Scrum-tiimi voi reagoida kiireellisiin asioihin vasta seuraavassa sprintissä.
PI-suunnittelutapahtumassa tuotekehitystiimit sidosryhmineen yhdessä suunnittelevat ja sitoutuvat liiketoimintatarpeiden mukaiseen seuraavaan toteutettavaan kokonaisuuteen. Tapahtuma kestää yleisimmin kaksi työpäivää ja mutkat suoristaen sisältää kahvin, vision, suunnittelun, sitoutumisen sekä retron.