2020 on kääntynyt jo loppupuoliskolleen, joten nyt on oiva aika palata takaisin aikaisemmin esitellyn Laatu 2020 termin ääreen. Olemme Bytecraftilla jo aikaisemmin kertoneet pyrkimyksestä hieman ravistella suomalaisen IT-konsultoinnin standardeja käyttäen mm. Software Craftmanshipin työkaluja ja menetelmiä.

Software Craftmanship (lue esimerkiksi aikaisempi postaus aiheesta: Mitä Software Craftsmanship tarkoittaa pähkinänkuoressa) tiivistää manifestissaan ideologian yksinkertaiseen lauseeseen: Raising the bar. Nostetaan rimaa tekemiselle, joka manifestissa sekä Bytecraftin tekemisessä tiivistyy seuraaviin periaatteisiin:

• Emme rakenna vain toimivia ohjelmistoja, vaan hyvin rakennettuja ohjelmistoja
• Emme vastaa vain muutokseen ympärillä, vaan tuotamme jatkuvasti lisäarvoa
• Emme usko vain yksilöiden vuorovaikutukseen, vaan uskomme ammatilliseen yhteisöön
• Emme ole vain yhteistyössä asiakkaan kanssa, vaan pyrimme tiiviisiin kumppanuuksiin

Manifesto for Software Craftsmanship

Tässä blogipostauksessa haluaisin alleviivata kahta ensimmäistä periaatetta Software Craftmanshipista: laatua ja arvoa. Ja lopulta niiden väistämätöntä symbioosia, jotta voidaan palvella loppukäyttäjän tarpeita hyvin.

Laatu ja arvo

Laatua on perinteisesti arvioitu monistakin näkökulmista, keskittyen usein konkreettisiin aihealueisiin kuten funktionaalinen toimivuus, performanssi, ylläpidettävyys tai esimerkiksi tietoturva. Lisää perinteisiä mittareita löytyy esimerkiksi alla olevasta ISO/IEC 25010 -standardista.

Haluaisin tuosta korostaa, että laatu on ehdottomasti mielestäni yllä mainittuja mittareita, mutta tuotetun ohjelmiston tärkein piirre ei ole esimerkiksi täyttää ennalta määrättyä speksiä täysin oikein, vaan se on ymmärtää loppukäyttäjän ongelma ja tehostaa kyseisen aihealueen käsittelyä. Parhaimmillaan jopa tavalla, joka ilahduttaa loppukäyttäjää. Tämä ei toki tarkoita sitä, etteikö speksi ja tämän kaltainen lopputulos voisi olla jopa yksi ja sama asia. Turhan usein softaprojekteissa se ei sitä valitettavasti ole.

Aiheesta voisi kirjoittaa huimat määrät tekstiä, mutta lyhyesti tiivistäen ohjelmistojen tehtävä on tuottaa loppukäyttäjilleen arvoa, englanniksi sopiva termi on customer value. Tämän voi tiivistää siihen, että softan avulla käyttäjille tuotettu arvo koostuu lopulta yksinkertaisesti hyödyistä ja haitoista heidän tarpeisiinsa nähden softaa käytettäessä Viite: Customer value creation. Tämä on nimenomaan kontekstisidonnaista, mutta esimerkkinä hyödystä voi olla vaikkapa säästetty aika tai säästetty raha. Haitoista esimerkkinä käy hyvin tuhlattu aika prosessin parissa. Onnistuneessa lopputuloksessa tulee ymmärtää mitä loppukäyttäjä tarvitsee, jotta hyödyt voidaan maksimoida ja haitat pitää minimissä. Kärjistäen erittäinen yksinkertainen esimerkki käyttäjän prosessista: keiton syönti. Käytössä voi olla maailman laadukkain hopeinen haarukka, kun oikeasti käyttäjälle olisi riittänyt muovinen lusikka. Täysin bugiton softa voi olla loppupeleissä raivostuttava käyttäjälleen.

Mielestäni ehkäpä paras tähän astisista vastaantulleista laadun mittareista on Peter J. Denningin, “Kuinka hyödyllistä softa on käyttäjälleen?”

Kuusi tasoa laadun arvioimiseksi

• 4. Ohjelmisto ilahduttaa - selkeästi yli odotusten. Uusia yllättäviä positiivisia vaikutuksia.
• 3. Ohjelmisto ei aiheuta negatiivisia vaikutuksia - Ei ennaltanäkemättömiä ongelmia, jotka aiheuttavat häiriöitä tai menetyksiä
• 2. Ohjelmisto sopii käyttökohteeseen - Ohjelmisto parantaa käyttäjän mahdollisuuksia saada työnsä tehtyä ja tärkeät tehtävät valmiiksi
• 1. Ohjelmisto täyttää kaikki peruslupaukset - Taso, jonka laatustandardit määrittävät
• 0. Jonkin asteinen uskottavuus - Käytettävissä tiettyyn pisteeseen, mutta sisältää paljon ongelmia
• -1. Ei uskottavuutta - Käyttökelvoton

Viite: Software quality

Kun laatua mitataan sillä, kuinka hyödyllistä softa on loppukäyttäjälleen, se heijastelee itseasiassa suoraan arvoa. Laatu on parhaimmillaan sitä, että softa ilahduttaa käyttäjänsä. Se tekee jotain mitä ei oikeastaan edes osannut odottaa, mutta käytön jälkeen käyttäjä miettii: “hemmetti, näinhän tämän itseasiassa pitääkin olla”. Huonoimillaan softa taasen esimerkiksi toimii vain satunnaisesti tai se ei toimi ollenkaan. Tällöin softan varaan ei voi asettaa mitään takeita ja luottoa järjestelmään ei ole. Haittoja, kuten menetettyä aikaa tai pahimmillaan jopa menetettyjä ihmishenkiä, voi syntyä. Itseasiassa on helppoa yhdistää perinteisiä aiemmin esiteltyjä laadun mittareita (tietoturva, performanssi jne..) myös kaiken kattavaan mittariin, kuinka hyödyllistä softa on käyttäjälleen. On helppoa nähdä, miten esimerkiksi bugit softassa voivat ajaa käyttäjän luoton minimiin. Hankalampaa taasen on yhdistää esimerkiksi se, miten jatkuvat tuotantoon viennit auttavat synnyttämään loppukäyttäjällä riemun kiljahduksia. Tai jos vähän suupieliä edes hymyyn saisi.

Technical Excellence

On selvää, että voidakseen rakentaa oikeita asioita tukemaan loppukäyttäjän prosesseja, tulee vaatimusmäärittelyn (tämän kattotermin alle voi sujauttaa myös esimerkiksi palvelumuotoilun & käyttäjätutkimuksen) olla priimaa. Epäselvempää on miten Software Craftsmanshipin periaate:

• Emme rakenna vain toimivia ohjelmistoja, vaan hyvin rakennettuja ohjelmistoja

Hyvin rakennetut ohjelmistot, lopulta auttavat siihen, että rakennetaan myös oikeita asioita. Tästäkin aiheesta voisi kirjoittaa lukemattomia sivuja tekstiä, mutta jos tämänkin koittaisi tiivistää ytimekkäästi. Ensinnäkin hyvin rakennetun ohjelmiston saavuttamiseksi toimintatapoja ja käytäntöjä on monia, kuten

• automaatiotestaus
• järkevät abstraktiot
• jatkuvat tuotantoonviennit jne..

Nämä ansaitsevat oman laajan käsittelyn myöhemmin, mutta softakehityksen hyvät tavat ja käytännöt tiivistyvät siihen että muutoksien teko tulee olla koko elinkaaren mahdollista. Hinta ja vaadittu aika muutokselle ei saa karata myöskään uusiin sfääreihin, tuli muutospyyntö sitten ensimmäisen kehitys-sprintin jälkeen tai projektin ollessa jo julkaistu aika tovi sitten tuotantoon “elämään villinä ja vapaana”. Loppupeleissä kyseessä on siis siitä, että oikeat tekniset ratkaisut: “technical excellence”, mahdollistavat sen, että vaatimukset voivat elää missä vaiheessa tahansa elinkaarta.

Jos vaatimukset muuttuvat loppukäyttäjiä sitouttavan vaatimusmäärittelyn seurauksena, hyvin rakennettu softa pitää muutoksen kustannukset kurissa. Laadukkaasti rakennettu softa on kestävää, muttei taipumatonta. Seuraavana jälleen kärjistetty esimerkki: leikkitalon rakennus. Jos rakennetaan leikkitalo korteista, eli korttitalo, se voidaan saada nopeastikin kasattua halvoista materiaaleista, mutta se sortuu helposti muutoksista. Erittäin kestävä leikkitalo toisaalta saataisiin esimerkiksi liimaamalla jäätelötikkuja yhteen, mutta siihen on hankala tehdä muutoksia. Lego-palikat sen sijaan liittyvät toisiinsa mukavan modulaarisesti sekä kestävästi, ja niillä voi rakentaa jos jonkinlaista leikkitaloa. Moduuleja, eli lego-palikkoja, voi vaihdella yksittäisiä tai isompiakin kokonaisuuksia helposti. Myös kaverin tekemät lego-rakennelmat voi ympätä mukaan leikkitaloon. Jos oikeita teknisiä ratkaisuja haluaisi verrata softassa leikkitalon rakennukseen (*kuten juuri tässä tekstissä nyt), ovat ne jotakuinkin lego-palikoiden kaltaisia.

Lopulta siis esimerkiksi ne aiemmin mainitut jatkuvat tuotantoonviennit (continuous deployment, CD) voivat olla hyvinkin kriittisessä roolissa loppukäyttäjälle tuotettuun arvoon. Yksinkertaisimmillaan kyse voi olla sitä, että beta-testauksessa havaittu bugi saadaan korjattua nopeammin ja käyttäjillä on bugin aiheuttamat haitat lyhyemmän aikaa esteenä. Hieman ideaa jatkojalostettuna, CD:n yhteys arvoon voi syntyä myös siitä, että loppukäyttäjän prosessia on ymmärretty paremmin. Esimerkiksi havainto voi syntyä siellä beta-testauksessa, ja tähän saadaan reagoitua “välittömästi” CD:n avulla. Toki me Bytecraftilla suosittelemme, että loppukäyttäjän palautetta ei jätetä vasta sinne beta-testaukseen tai ensimmäiseen julkaisuun, mutta myöhään on parempi kuin ei milloinkaan. Ja myös silloin, technical excellence, saattaa olla lopulta se mahdollistaja, jonka ansioista loppukäyttäjä saa jopa pienen hymyn huulille softan parissa: “Aijjai, ompas tää kätevä äppi!”.