Kirjoittamisen makuun …

… kai toivoisi jo pääsevänsä.

No kai sitä sivu pari tuli, vaikka aamupäivä meni ihastellessa erästä hyvin tuotteistettua kotimaista high-tech -värkkiä, jota ehkä ollaan hankkimassa töihin. Toivottavasti, sillä noiden entisten vehkeiden kanssa hiukset harvenee niin sangen helposti.

Mut joo. Tämän viikon asia tuntuu niin itsestäni triviaalilta, että on hiukan hankala motivoitua siihen. Tiedän kyllä kokemuksesta (tahallinen kaksoismerkitys, engl. pun intended), että käytännössä vaatimusmäärittelyprosessi ja käyttötapaukset eivät ole mitenkään triviaaleja juttuja hallita. Parannettavaa olisi valtavasti myös täällä työpaikalla ja toivottavasti pääsen joskus sitä parannusta saarnaamaan.

Mutta mainittakoon myös, että sama henk.koht. -triviaalius kosketti myös viimeviikon aihetta. Ehkä tämä tästä taas lutviintuu.

Mitä on kokemus?

Tämä postaus on jäänyt roikkumaan, mutta juuri nyt se on taas ajankohtainen. Julkaisenpa sen siis (vaikkakin siinä on hiukan puutteita) ja johdattelen itseni seuraavan luvun kirjoittamiseen.

–

Minulta kysyttiin äskettäin mitä tarkoitan kokemuksella. Aivotoiminta oli pitkän työpäivän jälkeen päänsäryssä ja juuri ennen työpaikan pikkujouluja melkolailla nollissa, joten koitan vastata tässä vielä uudelleen.

Palveluorientoitunut arkkitehtuuri ja palveluorientoituminen yleensäkin perustuu vahvasti hyviksi havaittuihin käytäntöihin (engl. best practice) [Erl05]. Pääosin näiksi lasketaan joukko yleisesti hyväksyttyjä sääntöjä (engl. industry-wide acceptance), mutta näitä parhaita käytäntöjä syntyy myös kehittäjätalojen sisällä menneitä projekteja arvioimalla. Yksi tällainen havaittu esimerkki on nykyisessä projektissa tehty palveluiden jaottelu. Eräänkin kerran aiemmin noviisina koko alalle ja palvelusuuntautumiselle tuli eräässäkin kokouksessa minulle henkilökohtaisesti yllätyksenä eräänkin komponentin muille itsestäänselvä sijoittuminen järjestelmään, vaikka henkilökohtaisesti tekisin toisin. Tällaista hiljaista kokemusta (engl. tacit knowledge) löytyy muualtakin, eikä pelkästään talon sisäisistä parhaista käytännöistä.

Kokemus on siis oppia menneestä. Kehittäjät oppivat vanhoista mokistaan ja asiakkaat voivat oppia kehittäjien tavoista. Työkalut ja menetelmät tulevat tutummiksi sekä ennen kaikkea ongelmakenttä tulee tutummaksi samojen toimijoiden ollessa kyseessä.

Myös vaatimusmäärittelyyn on kokemuksella vaikutusta. Tehdyt kysymykset ja vaatimusten tarkentaminen helpottuu ja kehittäjät voivatkin kysyä mielestään oleellisempia asioita. Myös kysymyksiin vastaavat asiakkaat oppivat mitkä kysymykset ovat tärkeitä ja miten kysymyksiin kannattaa vasta, jotta saa äänensä näkyviin lopulliseen tuotteeseen.

Myönnän, että vaikeaahan kokemusta on eksaktisti todentaa tai saati sitten mitata. Herääkin kysymys, että voidaanko epäonnistuneen tutkimuksen kuvausta pitää onnistuneena graduna?

[Erl05] Erl, Thomas, Service-Oriented Architectures: Concepts, Technology and Design, Prentice Hall Professional, 2005

Kylläpä aika kulkee

Projektitöitä kahdella (ja useammallakin) rintamalla. Siinähän meni sitten ihan pari viikkoa sitten viimeisen merkinnän.

Kokemuksen merkityksestäkin minulta on kysytty, mutta vastauskirjoitus odottaa draftseissa kuvitusta ja paria lisäjuttua. Ehkä joskus, muttei nyt.

Seuraavaksi sukellan milteinpä viimeistä kertaa parin tärkeän lähdekirjan pariin. En jaarittele siis pidempään.

Spotify on aika helmi ja pelastus huonekaverin näpytykseltä. Didon uusin (spotify:album:4KNKqXUmibcRVNs5drC2xd) soi tällä erää ja muistan kuinka olen vastaavassa tilanteessa kuunnellut häntä ennenkin.

Ongelmakentästä

Sen ongelmakenttänä on siis palveluorientoitunut arkkitehtuuri (engl. Service-Oriented Architecture ja Service-Orientation). Ongelmakentän kuvaamiseen olen varannut parisenkymmentä sivua, sillä palveluorientoituneen arkkitehtuurin suunnittelussa on nimenomaan kyse Sen aihepiiristä, eli aikaisemmasta kokemuksesta aiheen parissa ja parhaista käytännöistä (niin kokemuksen tuomista, kuin kollektiivisesti hyväksi todetuista).

Tässä siis miellekartta kyseisestä kappaleesta. Käyn läpi sitä myöhemmin, kun nyt pitää rientää jo palaveriin…

SOA -kappaleen miellekartta

Ongelmakenttä on hyvä tuntea

Täydennän ongelmakenttälukua parhaillaan ja koko ajan tulee kirjallisuudesta esiin avainsanoja, joita Siinä käytännössä tutkin. Eli parhaat käytännöt, kokemus ja kommunikointi.

Jännää…