15 tapaa epäonnistua kehitysjonon hallinnassa
Ketterässä kehittämisessä korostuu tehokas kommunikointi ja jatkuvan palautteen avulla tapahtuva oppiminen. Kehitysjonot ovat työkaluja, joiden avulla kehittyvän tuotteen ominaisuuksista käytävää keskustelua hallitaan. Ne ovat muodoltaan yksinkertaisia, mutta sisällöltään vaativia. Ohessa muutama kehitysjonon haaste
1. Liian yksityiskohtainen
Kirjoittamalla perinteisen vaatimusmäärittelyn kaltaisia yksityiskohtaisia kehitysjonoja tuoteomistaja tuhlaa aikaansa ja vie tilan kehitystiimin luovuudelta. Muodoltaan kehitysjonossa olevat asiat ovat verrattavissa perinteisissä projektisuunnitelmissa esitettyihin tuotteen osituksiin. Ne ovat tarkoituksellisesti epätäydellisiä.
Ohjelmistokehittäjä todennäköisesti tietää esimerkiksi, millainen ohjelmalogiikka tarvitaan käyttöliittymässä olevien paluu, OK, lisää, muuta ja poista -painikkeiden toteuttamiseen. Tällöin kehitysjonoon ei tarvita erillisiä käyttäjätarinoita näitä kuvaamaan.
2. Liian iso, ennakoitu liikaa
Useita satoja tai jopa tuhansia kohtia sisältävä kehitysjono ennustaa kehitystiimin työt vuosiksi eteenpäin. On ennenaikaista sisällyttää kehitysjonoon asioita, joiden tekeminen ei ole ajankohtaista. Ei ole edes varmaa tullaanko niitä koskaan tekemään.
3. Liiketoiminnan hyöty, mittarit puuttuvat
Kehitysjonon priorisoinnin kannalta on tärkeää ymmärtää, miksi tuotteessa on juuri nämä ominaisuudet. Kustannus-hyöty-laskelmiin pitää olla mahdollisuus ainakin karkealla tasolla. Esimerkiksi käyttäjätarina: Markkinoinnin edustajana haluan verkkosivustomme käyttävän evästeitä, jotta voimme hyvin kohdistaa myynti- ja markkinointitoimenpiteemme asiakkaisiimme. Tästä voimme jatkaa keskustelua siitä, onko evästeiden käyttö hyvää liiketoimintaa.
4. Käyttäjätarinan ”miksi” on väärin
Esimerkiksi käyttäjätarina: ”Asiakkaana haluan käyttää digipalvelu X.ää, jotta voin säästää luontoa” kuvaa tarvetta todennäköisesti heikommin kuin ”Yhtiön omistajan haluan asiakkaidemme käyttävän digipalvelu X:ää, jotta voimme säästää kustannuksissamme 10%. Mittareiden lisääminen paljastaa usein olemmeko tekemässä niitä asioita, joita tuotteen onnistumiselta todellisuudessa vaaditaan.
5. Konkretia puuttuu, liian abstrakti
Pelkkä liiketoiminnan tarve riittää harvoin. Kehitystiimi haluaa tietää, mitä heidän pitää tuottaa. Mitä kehitystiimin pitäisi tehdä esimerkiksi käyttäjätarinan ”Yhtiön omistajana haluan strategian jotta omistaja-arvon kasvu tulevina vuosina turvataan” toteuttamiseksi?
6. Koko sivun käyttäjätarina
Käyttäjätarinamuoto ei sovellu kaikkiin tilanteisiin. Sen käyttö ei ole pakollista. Esimerkiksi monimutkaista ohjelmistologiikkaa tai visuaalista ilmettä on vaikea kuvata yhdellä virkkeellä. Kehitysjonoa voi täydentää erilaisilla kaavioilla, luonnoksilla ja laskentasäännöillä.
7. Arkkitehtuuri puuttuu
Kehitysjonon rakenne kuvaa meneillään olevan työn lisäksi myös tuotteen arkkitehtuuria. Hyvässä arkkitehtuurissa ja kehitysjonossa rakenneosat (etenkin teemat ja epicit) ovat itsenäisesti rakennettavissa, julkaistavissa ja korvattavissa. Tikettilistasta syntyy helposti spagettikoodia.
8. Ei synny inkrementtejä
Perinteisessä vaatimusmäärittelyssä kuvataan usein suuri joukko komponentteja, jotka integroidaan vasta lopussa yhteen. Ketterän toimintatavan inkrementaalinen ja iteratiivinen malli jossa meillä on koko ajan toimiva ja kehittyvä tuote vaatii tätä tukevaa kehitysjonoa. Esimerkiksi, koska käyttöliittymää ja taustajärjestelmää ei rakenneta erillään toisistaan, niitä ei eroteta myöskään kehitysjonossa omiksi kokonaisuuksikseen.
9. Ei keskustelua tiimin ja käyttäjien kanssa
Koska kehitysjono on tarkoituksellisesti epätäydellinen tulee tuoteomistajan, käyttäjien ja kehittäjien aktiivisesti keskustella keskenään. Ymmärrys tuotteesta ei välity dokumentteja ja sähköposteja lähettämällä vaan yksilöiden välisessä vuorovaikutuksessa.
10. Ei palautetta: POC, alfa, beta, MVP
Kehitysjonoa kirjoitettaessa pitää huomioida se, että tuote kehittyy pala kerrallaan. Tuote annetaan käyttäjien ja asiakkaiden arvioitavaksi mahdollisimman varhaisessa vaiheessa. On parempi epäonnistua proof-of-concept:in kanssa kuin kalliin tuotekehitysputken lopuksi. Kehitysjono arvioi julkaistaanko piirre POC:ssa, alfa-versiossa, betassa vai myöhemmin.
11. Ei muutoksia, ei katselmuksia
Kehitysjono kuvaa kullakin hetkellä rakenteilla olevan osan tuotteesta. Se poikkeaa projektisuunnitelmasta siinä, että sitä ei jäädytetä projektin alkaessa. Sen sijaan tuotetta pyritään tarkoituksellisesti parantamaan asiakas- ja käyttäjäpalautteen avulla. Katselmus on tapahtuma, jossa Scrum Tiimi keskustelee sidosryhmien kanssa tuotteen tulevaisuudesta.
12. Yleismääritykset valmiin määritelmään
Yleismääritykset kuten ei-toiminnalliset vaatimukset, tietoturvapolitiikka ja käyttöliittymästandardit kuvataan valmiin määritelmässä. Tällöin niitä ei toisteta tarpeettomasti kehitysjonossa.
13. Työn ositus tiimeille ei kommunikoidu
Kehitysorganisaation, tuotteen ja kehitysjonon rakenteet vastaavat yleensä toisiaan, jotta riippuvuudet voidaan hallita kunkin tiimin sisällä. Vahva ennakkosuunnittelu tai isot tiimien väliset kokoukset eivät ole osoittautuneet tarpeeksi nopeaksi ja vuorovaikutteiseksi tavaksi kommunikoida.
14. Alustaspesifiset tiimit
Tuoteomistajan on vaikea optimoida kehitysorganisaation työn arvoa, jos tämä koostuu osaamissaarekkeista. Kehitysjonossa alustat kuten Android, IOS ja Windows otetaan huomioon vasta alatasolla, joka kuuluu yhdelle tiimille.
15. Kaksinkertainen työ, puuttuvia osia
Kaikille avoin kehitysjono levittää kokonaiskuvaa tuotteesta niin, että kukin piirre rakennetaan tasan yhden kerran. Komponenttien uudelleenkäytön suhteen ketterä maailma on opportunisti.
Perinteet ja töiden organisointi ovat juurisyitä ylläoleviin. Seuraukset avautuvat kun huomioi ymmärryksen kehittymisen ja tarpeiden muuttumisen kehitystyön edetessä.
Tieturin ketteryyskoulutuksia
- Kehitysjonojen (Backlog) hallinta -koulutus antaa käytännönläheiset opit haasteiden voittamiseen.
- Product owner I (PO I)
- SAFe Product Owner/Product Manager with POPM Certification
- Scrum Master I (SM I)
- Scrum perusteet
- Ketterä projekti – agile projektijohtaminen
Meiltä löydät lähes 30 koulutusta ketteryyteen, katso kaikki ketteryyskoulutukset.
Pentti Virtanen
Pentti on koulutukseltaan filosofian tohtori ja Certified Scrum Trainer. Hänen erityisalueenaan on toiminnan kehittäminen erityisesti ketterillä Lean- ja Scrum-ajattelumalleilla.
Pentin pitkä ja monipuoleinen työkokemus sisältää mm. käytännön projektijohtamista suuryhtiössa ja IT start-upin kasvutarinan 15 henkilöstä 500 henkilöön. Pentin tilaisuuksissa yhdistyvät vahva teoreettinen tausta ja opettavat tarinat hänen käytännön kokemuksistaan.
