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. Lii­an yk­si­tyis­koh­tai­nen

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. Lii­an iso, en­na­koi­tu lii­kaa

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. Lii­ke­toi­min­nan hyö­ty, mit­ta­rit puut­tu­vat

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äyt­tä­jä­ta­ri­nan ”mik­si” 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. Kon­kre­tia puut­tuu, lii­an ab­strak­ti

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 si­vun käyt­tä­jä­ta­ri­na

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. Ark­ki­teh­tuu­ri puut­tuu

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 syn­ny in­kre­ment­te­jä

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 kes­kus­te­lua tii­min ja käyt­tä­jien kans­sa

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 pa­lau­tet­ta: 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 muu­tok­sia, ei kat­sel­muk­sia

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. Yleis­mää­ri­tyk­set val­miin mää­ri­tel­mää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 osi­tus tii­meil­le ei kom­mu­ni­koi­du

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. Alus­tas­pe­si­fi­set tii­mit

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. Kak­sin­ker­tai­nen työ, puut­tu­via 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ä.