Olen ollut urani aikana mukana useissa erilai­sissa projek­teissa. Olen samalla huomannut, miten vaati­musten määrit­tely on muuttunut ajan saatossa. Aina n. vuoteen 2010 saakka vaati­muksia määri­tel­tiin ns. perin­teisen mallin mukaan, missä kaikki vaatimukset yritet­tiin määrittää ennen ensim­mäis­tä­kään koodi­rivin kirjoit­ta­mista saati testaa­mista.  Sinällään tuntuu tietysti loogi­selta, että määri­tel­lään ja toteu­te­taan sitten määri­tysten mukaan. Käytännössä hyvin usein määri­tykset pyrkivät muuttu­maan ja elämään projektin edetessä, eikä edellä esitetty tapa sen takia käytän­nössä toimi.

Noin reilut kymmenen vuotta sitten ketterät menetelmät scrum etune­nässä alkoivat jalkautua IT-projekteihin. Sen luvattiin olevan kultainen luoti, minkä avulla saadaan paremmin täytettyä asiakkaan toive ja parem­pi­laa­tuisia ohjel­mis­toja. Ideana se, että määri­tel­lään vain seuraavan sprintin asiat kerral­laan, minkä jälkeen tarkas­tel­laan suuntaa ja tarvit­taessa korjataan kurssia, kuulostaa ideaa­lilta. Prosessiin kuului lisäksi se, että tuote­hal­lin­noija (PO) toimii linkkinä liike­toi­minnan ja kehit­tä­jien välillä mahdol­lis­taen kehit­tä­jille paremmat mahdol­li­suudet keskittyä  itse ohjel­miston kehittämiseen.

Omat kokemuk­seni scrum:sta ovat kahta­laiset. Olen ollut mukana projek­teissa, mitkä ovat onnis­tu­neet ja toisaalta olen ollut mukana projek­teissa, mistä ei hirveästi jää jälki­pol­ville kerrot­tavaa. Mielestäni onnis­tu­neissa projek­teissa Scrum ei ole ollut välttä­mättä onnis­tu­misen tae tai edellytys vaan se, ettei tiimiä ole eristetty liike­toi­min­nasta. Itseasiassa se, että Scrum:a on nouda­tettu orjal­li­sesti ja PO on eristänyt tiimin, on ennemmin aiheut­tanut sen, että projekti suurem­malla toden­nä­köi­syy­dellä epäon­nistuu kuin onnistuu. Tämä johtuu siitä, että kaiken infor­maa­tion virra­tessa PO:n kautta, ei toteut­ta­jilla ole parasta mahdol­lista tietoa käytettävissään.

Miten sitten vaati­muksia saatai­siin paremmin määri­tettyä ja vieläpä niin, että toteut­tajat ja liike­toi­min­nasta vastaavat henkilöt puhui­sivat samaa kieltä ja vieläpä ymmär­täi­sivä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ä keski­ty­tään liike­toi­minnan näkökul­masta järjes­tel­mässä tapah­tu­viin toimin­toihin. Lisäksi menetelmä on erittäin toimiva siinä, että ns. hiljainen / piilossa oleva tieto tulee näkyväksi. Erityisen hyvä menetelmä on siinä, että kehit­täjät ja liike­toi­min­nasta vastuussa olevat puhuvat ns. samaa kieltä ja samalla tasolla. Lisäksi menetelmä parantaa ihmisten välistä kommu­ni­kaa­tiota. Itse olen käyttänyt menetelmää myös uusien kehit­tä­jien pereh­dyt­tä­mi­sessä ja voin todeta, että se on todella tehokas tapa myös ko. tarkoi­tuk­sessa. Uskallan luvata, että Event Storming:ia käytet­täessä projektin onnis­tu­mi­selle, ja shampanjan kilis­te­lylle onnis­tu­misen merkiksi, on paremmat edellytykset.

Kiitos, kun luit tekstin tänne saakka. Ensi kerralla kerron, miten Event Storming työpaja toimii. Jos mielen­kiin­tosi heräsi, kommentoi alle tai laita viestiä minulle, niin kerron mielel­läni lisää.