Lopussa kilistellään shampanjaa …...

Olen ollut urani aikana mukana useissa erilaisissa projekteissa. Olen samalla huomannut, miten vaatimusten määrittely on muuttunut ajan saatossa. Aina n. 2010 saakka vaatimuksia määriteltiin ns. Perinteisen mallin mukaan, missä kaikki vaatimukset yritettiin määrittää ennen ensimmäistäkään koodirivin kirjoittamista saati testaamista.  Sinällään tuntuu tietysti loogiselta, että määritellään ja toteutetaan sitten määritysten mukaan. Käytännössä hyvin usein määritykset pyrkivät muuttumaan ja elämään projektin edetessä, eikä edellä esitetty tapa sen takia käytännössä toimi.

Noin reilut kymmenen vuotta sitten ketterät menetelmät scrum etunenässä alkoivat jalkautua IT-projekteihin. Sen luvattiin olevan kultainen luoti, minkä avulla saadaan paremmin täytettyä asiakkaan toive ja parempilaatuisia ohjelmistoja. Ideana se, että määritellään vain seuraavan sprintin asiat kerrallaan, minkä jälkeen tarkastellaan suuntaa ja tarvittaessa korjataan kurssia, kuulostaa ideaalilta. Prosessiin kuului lisäksi se, että tuotehallinnoija (PO) toimii linkkinä liiketoiminnan ja kehittäjien välillä mahdollistaen kehittäjille paremmat mahdollisuudet keskittyä  itse ohjelmiston kehittämiseen.

Omat kokemukseni scrum:sta ovat kahtalaiset. Olen ollut mukana projekteissa, mitkä ovat onnistuneet ja toisaalta olen ollut mukana projekteissa, mistä ei hirveästi jää jälkipolville kerrottavaa.  Mielestäni onnistuneissa projekteissa  Scrum ei ole ollut välttämättä onnistumisen tae tai edellytys vaan, se ettei tiimiä ole eristetty liiketoiminnasta. Itseasiassa se, että Scrum:a on noudatettu orjallisesti ja PO on eristänyt tiimin, on ennemmin aiheuttanut sen, että projekti suuremmalla todennäköisyydellä epäonnistuu kuin onnistuu. Tämä johtuu siitä, että kaiken informaation virratessa PO:n kautta, ei toteuttajilla ole parasta mahdollista tietoa käytettävissään.

Miten sitten vaatimuksia saataisiin paremmin määritettyä ja vieläpä niin, että toteuttajat ja liiketoiminnasta vastaavat henkilöt puhuisivat samaa kieltä ja vieläpä ymmärtäisivät toisiaan. Itse olen havainnut tähän hyväksi Event Storming työpajan pitämisen projektin alussa ja aina välillä projektin aikana. Menetelmä on todella toimiva, koska siinä keskitytään liiketoiminnan näkökulmasta järjestelmässä tapahtuviin toimintoihin. Lisäksi menetelmä on erittäin toimiva siinä, että ns. hiljainen / piilossa oleva tieto tulee näkyväksi. Erityisen hyvä menetelmä on siinä, että kehittäjät ja liiketoiminnasta vastuussa olevat puhuvat ns. samaa kieltä ja samalla tasolla. Lisäksi menetelmä parantaa ihmisten välistä kommunikaatiota. Itse olen käyttänyt menetelmää myös uusien kehittäjien perehdyttämisessä ja voin todeta, että se on todella tehokas tapa myös ko. Tarkoituksessa. Uskallan luvata, että Event Storming:a käytettäessä projektin onnistumiselle, ja shampanjan kiliskilistelyyn onnistumisen merkiksi, on paremmat edellytykset.

Kiitos, kun luit tekstin tänne saakka. Ensi kerralla kerron, miten Event Storming työpaja toimii. Jos mielenkiintosi heräsi, laita viestiä minulle, niin kerron mielelläni lisää.