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ä.
Lisätietoja
Tagit
Liiketoimintaprosessi
Projektinhallinta |
Tarjonnan tyyppi
Koulutus |
Omat tagit
Tieturi - Asiantuntijat ja yhteyshenkilöt
Tieturi - Muita referenssejä
Tieturi - Muita bloggauksia
It- ja ohjelmistoalan työpaikat
- Laura - Tietoturva-asiantuntija
- Nordea - Senior Full Stack Developer with IAM knowledge
- Tecinspire Oy - Dev Team Lead - Kehityksen tiimipäällikkö
- Laura - IT Manager
- Laura - Network Specialist
- Laura - Tiedonhallinnan erityisasiantuntija
- Laura - Junior Cyber Security Specialist
Premium-asiakkaiden viimeisimmät referenssit
- Ampersand Design Oy - Asiantuntijuuden vahvistaminen referenssitarinoilla
- Verkkovaraani Oy - Lentorata.fi-sivuston saavutettavuusauditointi
- Innofactor Oyj - Apotek 1 tarjoaa innovatiivisia palveluja Azure Kubernetes -ratkaisun avulla
- Innofactor Oyj - Business Centralin lisäarvoratkaisut tehostavat Domicetin liiketoimintaa
- Efima Oyj - Case Martela: Luottamus ERP-kumppaniin rakentui tehtaan lattialla
- Valve - Korsisaari uudistunut verkkopalvelu
- Valve - Musiikkituottajat – IFPI Finland ry verkkopalvelun uudistus
Tapahtumat & webinaarit
- 21.05.2024 - The path to productization
- 21.05.2024 - Ilmainen ERP-webinaari: NAV:stä Business Centraliin | Business Centralin mahdollisuudet versionvaihdon jälkeen
- 23.05.2024 - Ilmainen BI ja ERP-webinaari: Paradigman muutos
- 28.05.2024 - SprintIT webinaari ti 28.5. klo 10: Odoo Raportointi - Sitä saat mitä mittaat!
- 29.05.2024 - Efistream-webinaari: Näin rakennat modernin taloushallinnon, joka tukee tiedolla johtamista
- 29.05.2024 - Ilmainen ERP-webinaari: Forbesin maailman parhaaksi valitseman liiketoimintaohjelmiston, Business Centralin, esittely ja demo
- 30.05.2024 - Palvelumuotoilu osana DevOpsia
Premium-asiakkaiden viimeisimmät bloggaukset
- Ready Solutions Oy - Tietomallit osana informaatioarkkitehtuuria
- Timeless Technology - Milesight UR32L Lite Series teollisuusreititin hintaan 115,00€!
- Innofactor Oyj - Dynasty Asiointipalvelun 3 tärkeintä hyötyä
- Efima Oyj - Microsoft Fabric -sanakirja: esittelyssä Fabricin analytiikkatyökalut
- Staria Oyj - Citycon ulkoistaa pohjoismaiseen talous- ja vuokrahallintoon liittyvät toiminnot Starialle
- Timeless Technology - Perlen 4G ja 5G reitittimet: Virtaviivaista verkonhallintaasi Docker OCI-säilöillä.
- Ready Solutions Oy - Lakehouse – alusta vai tietovarasto moderniin analytiikkakehitykseen?
Digitalisaatio & innovaatiot blogimediaBlogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä |