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 li...
Opiskellessani IT-alaa reilut kaksikymmentä vuotta sitten ohjelmistoprojektien toteuttamiseen opetettiin käytännössä vain yksi tapa, vesiputousmalli. Tämän jälkeen on tullut monia uusia tapoja, scrum ja kanban muutamia mainitakseni. Jokainen tapa / prosessi kuulostaa paperilla täydelliseltä ja tähtää tietysti ohjelmistoprojektin onnistumiseen ja asiakkaan tarpeen täyttämiseen. Urani aikan olen huomannut, ettei yksi mikään prosessi ole toista parempi. Prosessit ovat yleensä tehty täydellisille ihmisille, enkä ole toistaiseksi tavannut täydellistä ihmistä. Paljon riippuu projektin toteutuksesta. Projektilla on paremmat mahdollisuudet onnistua, jos projektin tavoite on selvä. Selvällä tarkoitan jotain muuta kuin “toteutamme uuden sukupolven sovelluksen X …” . Riippumatta projektimallista projektin tavoite kuvataan yleensä vaatimusten kautta. Joissakin malleissa vaatimukset yritetään kuvata täydellisesti ennen toteutus ja testaus vaiheita. Joissakin toisissa malleissa vaatimukse...