Pilvinen päivä Tallinnassa, eli eBusiness Forum 2010

Tietoyhteiskunnan kehittämiskeskus järjesti eBusiness Forum -seminaarin Tallinnassa 26.-27.5. Seminaarin pääpaino oli yritysten välisessä sanomavaihdossa, ja sitä on järjestetty jo parikymmentä vuotta. Ihan rehellisesti sanoen, EDIFACT, INTMOD ja INVOIC91.1 eivät varsinaisesti ole osaamiseni kovaa ydintä, joten en sano niistä enempää. Tänä vuonna ohjelmaa oli kuitenkin laajennettu myös yleisempii ohjelmistokehitsyaiheisiin, etenkin pilvipalveluihin ja ketterään kehitykseen.

Allekirjoittanut oli paikalla puhumassa pilvipalveluista: mitä ne ovat, kuka niitä myy, ja miten niitä käytetään. Aika pitkälti samoja aiheita joita olemme pyöritelleet aamiaistilaisuuksissamme, kalvot löytyvät Tieken sivuilta. Myös Connexorin Pasi Tapanainen kertoi kuinka he ottivat Pilviratkaisut käyttöön muuan osaavan konsultinputkan avustuksella (ette ikinä arvaa kenen).

Codentolaisista paikalla oli myös CCP-partnerimme, Scrum-kuningas Lare Lekman. Laren esitys käsitteli scrumin jalkauttamista organisaatioon ja lisäksi teollista vallankumousta, T-fordeja, Charles Darwinia, tämän kaimaa Chaplinia ja lyijykynien teroittamista. Ketterään esitykseen mahtuu paljon. NSN:n Ran Nyman esitteli Scrumia yleisesti, ja Hanselin Outi Jousi kertoi miten sitä voi käyttää julkisissa kilpailutetuissa hankkeissa, aihe jonka soisi saavan paljon lisää huomiota.

<kuvitelkaa tähän video Laresta osoittamassa ketteryyttään perinteisessä virolaisessa hevosenlänkilimbossa>

Tämän artikkelin on kirjoittanut Otso Kivekäs ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

URPS

Epäfunktionaaliset vaatimukset, systeemiset vaatimukset, laatuvaatimukset. Kaikki kömpelöiden englanninkielisten termien kömpelöitä suomennoksia. Aihe on kuitenkin tärkeä, vaikka hyvät sanat puhua siitä puuttuvat.

Suurissa projekteissa epäfunktionaalisia vaatimuksia voi käsitellä vaikka miten, koska aikaa ja rahaa on niihin varattu. Kevyissä vaatimusmäärittelyissä ne sen sijaan usein unohdetaan kokonaan, tai korkeintaan käsitellään ilmeisimmät asiat ja unohdetaan loput. Jos tarkoitus on määritellä tuote tai projekti nopeasti, töitä täytyy tietysti karsia. Mutta oman kokemukseni mukaan epäfunktionaalisten vaatimusten hiukan systemaattisempi läpikäynti on vaivan arvoista pienissäkin projekteissa.

Oma käytäntöni on yksinkertaisesti käydä mahdollisia vaatimuksia listan kanssa läpi työpajassa, ja miettiä joka kohdassa, liittyykö tähän jotain huomioimisen arvoista. Melko laaja lista löytyy vaikka wikipediasta, ja toinen vähän fokusoidumpi Julian Brownen blogista. Listan etuna on, että se johdattaa katsomaan projektia myös suunnista, joita ei muuten tulisi ajatelleeksi, vaikkapa onko työpöytäsoftalle yhteensopivuusvaatimuksia tai kohdistuuko sosiaalimediapalveluun juridisia rajoitteita.

Lista ei kuitenkaan vapauta aivojen käytöstä. Jokainen kohta toimii vain keskustelunavauksena. Varsinaisten vaatimusten löytämiseen, muotoiluun ja kirjaamiseen tarvitaan sekä ymmärrystä projektista että kokemusta ohjelmistotuotannosta yleisesti. Mutta tällä tavoin osaava vaatimusmäärittelijä saa muutaman tunnin työllä tehtyä aika hyvän kuvauksen epäfunktionaalisista vaatimuksista.

Tarkoitukseni oli laittaa tähän postauksen loppuun oma checklistini, jolla haarukoin pienten ja keskikokoisten projektien epäfunktionaalisia vaatimuksia. Mutta siinä ei oikeastaan ole mitään järkeä. Generoin listani nimittäin joka kerta uudestaan tiputtamalla wikipedian listasta pois kaiken ilmeisen järjettömän. Siitä, tai yhtä hyvin Brownen listasta lähtemällä pärjää hyvin, turha luoda yhtä lisää.

Tämän artikkelin on kirjoittanut Otso Kivekäs ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.