Arkisto: syyskuu 2009



Virheet ja vit…harmitus

24. syyskuuta, 2009 | Kirjoittaja: Jaakko Sakaranaho

Yritykset tekevät jatkuvasti enemmän yhteistyötä. Hyvänä esimerkkinä on työkalun räätälöintiprojekti. Koska kehityksen aikana syntyy koodia, syntyy myös virheitä.

Ohjelmistovirheet voidaan jakaa käyttäjän näkökulmasta raakasti kahteen kategoriaan. Niihin, jotka estävät käytön kokonaan ja niihin, jotka hankaloittavat käyttöä. Käytön estävät virheet tulee karsia pois jo kehitysvaiheessa. Mitä pitäisi tehdä niille pienille bugeille, jotka eivät aiheuta harmitusta kummempaa vahinkoa?

Tein pienen kyselykierroksen softa-alan ammattilaisten keskuudessa.

Ärsyttävimpiä virheitä ovat ne, jotka tulevat yllätyksenä. Ennakkoon tiedossa olevien virheiden olemassaolo ei juurikaan haittaa, jos ne eivät kohtuuttomasti häiritse käyttöä.

Loppujen lopuksi ajateltuna suppean kyselyn tulos on varsin looginen. Arvaamattomuus ja epätietoisuus softan toiminnassa aiheuttavat jatkuvaa päänvaivaa. Lisäksi ohjelmistoja ammatikseen käyttävät ovat hyvin hanakoita reklamoimaan ja informoimaan virheistä toimittajalle. ”Eivätkö ne saamari ole edes tätä virhettä saaneet kiinni omassa testauksessa?” Tämä lisää toimittajan tukipalvelun työkuormaa.

Jos yhdellä iskulla voisit listiä kolme kärpästä?

Perinteiset ajattelumallit ja jäykät ”yrityssalaisuusasiat” pitää jälleen unohtaa. Olisiko syytä pelata avoimilla korteilla salailun sijaan? Olisko aivan älytön ajatus avata virhetietokanta loppukäyttäjille?

Avaamisella on kolme selkeää etua:

1. Loppukäyttäjien ärsyyntymiskynnys nousee, kun virheen olemassaolo on tiedossa. Vielä kun tietokannassa on kätevä work-around virheen välttämiseksi, niin hienoa. Ennakkoon tiedossa oleva ongelma ei aiheuta turhaan ärsytystä.

2. Luottamus toimittajan laadunvarmistukseen kasvaa. Jokainen softa-alan ammattilainen ymmärtää, että ohjelmistoista löytyy aina virheitä. Parempi on, että toimittaja löytää virheen ennen loppukäyttäjää.

3. Reklamaatioiden duplikaatit vähenevät. Ja kun reklaamaation perusteella löydetään uusi virhe, tulee tästä välittömästi informoida esimerkiksi käyttäjien forumilla. Näin vähennetään tukipalvelun työmäärän. Jos virhetietokannan avaaminen tuntuu teknisesti tai henkisesti liian raskaalta, tee ainakin kunnollinen listaus tiedetyistä ongelmista ja julkaise se.

Miksi virhetietokantaa ei voisi avata asiakkaille? Mikäli yhteistyö toimii hyvin ja avoimesti, minä en keksi yhtään perusteltua syytä.

Tutkiva testaus ja offshore

18. syyskuuta, 2009 | Kirjoittaja: Antti Niittyviita

Kävin eilen Agile Finlandin järjestämässä Agile Dinner -tapahtumassa. Paikalla oli joukko Oululaisia ohjelmistoalan ammattilaisia useista eri yrityksistä. Tapahtuman tarkoitus on kerran kuussa istua iltaa samanhenkisessä seurassa ja keskustella ketteryydestä.Tällä kertaa, kiitos Testaus OSY:n, aiheena oli testaus.

Maaret Pyhäjärvi alusti keskustelun erinomaisesti. Hän kertoi omia kokemuksiaan suuren organisaation muutoksesta kohti Scrummia. Aihetta käsitellessä keskusteltiin paljon myös tutkivasta testauksesta. Tähän liittyen kerroin omista kokemukistani kiinalaisen testaustiimin kanssa.

Ajatuksena kiinalaiset ja tutkiva testaus nostaa varmasti hymyn huulille. Eikö totta?

Kyllä meitäkin alkuun hymyilytti. Projektissa, jossa työskentelin oli kaksi suomalaista ja isompi tiimi kiinalaisia. Testaus oli suunniteltu vahvasti etukenossa ja testitapaukset oli dokumentoitu step-by-step.

Projektin ensimmäisen puolen vuoden testitulokset olivat erinomaisen näköiset, mutta virhekertymän lineaarinen kasvutahti herätti kuitenkin hämmästystä. Aikaisempien kokemustemme mukaan projektien virhejakauma osui kivasti Gaussin käyrälle ja testauksen tehokkuuttakin oltiin ennen mitattu myös virhekertymällä. Outoa.

Testejä tarkasteltiin myös suomalaisin voimin. Silloin havaittiin, että virheitä alkoi löytyä tutkimalla testauksen ohessa myös polkuja testien reuna-alueilta. Ennakkoluuloista huolimatta päätimme jatkaa tutkivan testauksen kokeilua. Puolet speksatuista testikierroksista pudotettiin pois ja ainoa tehtävänanto testaustiimille oli ”etsi virheitä & raportoi”.

Tulokset tässä vaiheessa eivät silti olleet kovin rohkaisevia. Testaajat eivät uskaltaneet tehdä itse ratkaisuita siitä toimiko softa oikein vai ei.

Toimintamallia muutettiin siten, että jokaiselle testaajalle jaettiin omat vastuualueet, joita kierrätettiin säännöllisesti. Bluetooth, Wifi, Kamera jne… Tämän lisäksi kepin sijaan kokeiltiin porkkanaa. Testaajista alettiin pitämään viikottaista top 5 rankin-listaa.

Eniten uniikkeja virheitä raportoinut testaaja sai tietysti mainetta ja feimiä projektin sisällä. Näin virheraporttien määrä projektissa kaksinkertaistui alle kuukaudessa.

Rohkea lähestyminen ja uusien juttujen kokeilu myös perinteisessä projektissa voi piristää kummasti. Vaikka uusi ajatus aluksi vähän hymyilyttää, niin kannattaa pitää mielessä, että kyllä se kiinalainenkin oppii!

Muutama sana asiakaslähtöisyydestä

11. syyskuuta, 2009 | Kirjoittaja: Jaakko Sakaranaho
Kommentit: 3

Kurkkasin pikaisesti muutaman suomalaisen ohjelmistoyritysten verkkosivuja. Monet arvoistaan julkisesti puhuvat ilmoittivat olevansa erityisen Asiakaslähtöisiä. Se on hyvä. Ilman asiakkaita tuskin on tulojakaan.

Uskallan kuitenkin väittää, että liian moni yritys jättää käyttämättä loppukäyttäjien panoksen tuotekehityksensä apuna. Turhaa riesaa ja häiritsevät työtä, voi moni ajatella. Melko asiakaslähtöistä.

Yhdysvaltalainen Standish Group julkaisee säännöllisin väliajoin Chaos Reportin. Raportissa kerrotaan mm. miksi ohjelmistoprojektir onnistuvat tai epäonnistuvat. Vuoden 2009 raportin voi tilata 99USD:n hintaan, mutta koska vuoden 2004 Chaos Reportin dataa on luettavissa ilmaiseksi, katsotaan sitä. Keskustelun herättämiseksi tehdään suoraviivainen oletus, että onnistumisen syyt ovat pysyneet kutakuinkin samana. Vertailun vuoksi kerrotakoon vielä, että vuonna 2004 29% projekteista oli onnistuineita, kun vastavaa luku 2009 on 32%.

Chaos Reportin mukaan onnistuneen softaprojektin tärkeimpänä yksittäisenä tekijänä on käyttäjien kuunteleminen projektin aikana. Lisäksi jo vuoden 1995 Chaos Report totesi, että mikäli projektissa oli haasteita (toimitus oli myöhässä, budjetti ylittyi ja tai toiminnallisuuksia oli karsittu), yksittäisistä tekijöistä suurimpana syynä oli käyttäjäpalautteen puute. Yli joka kymmenes projektin epäonnistuminen johtui siitä, että käyttäjiä ei ole viitsitty/jaksettu/voitu kuunnella kehitysprojektin aikana. Esimerkkinä voidaan mainita sähköisen äänestyksen kokeilu viime syksyn kunnallisvaaleissa. Todellisten käyttäjien käyttäjäkokemukset ja palaute jätettin, ei pelkästään huomiotta, vaan kokonaan hankkimatta.

No, mitenkäs tämä nyt sitten liittyy testaukseen? Ottakaa asiakkaanne (ei pelkästään niitä päätöksentekijöitä vaan myös tuotteenne päivittäiset käyttäjät) mukaan tuotekehitykseen. Minä ainakin olisin riemuissani, jos yritykselleni räätälöitäisiin jokin työkalu ja minua pyydettäisiin mukaan varmistamaan sen toiminnallisuuksia jo kehityksen aikana! Tuotteen käyttäjäystävällisyys kasvaa. Se on mitä mainiointa markkinointia yrityksen muita tulevia projekteja ajatellen. Loppukäyttäjien palaute jo tuotekehitysvaiheessa antaa myös paljon lisää myytävää ja jatkokehitysajatuksia.

Loppukäyttäjien palaute on erinomaisen tärkeää varsinkin siinä tilanteessa, kun vaatimusmäärittely on parhaista yrityksistä huolimatta jäänyt puutteelliseksi. Kun loppukäyttäjiä kannustetaan testaamaan kehityksen alla olevaa toiminnallisuutta, saadaan mahdolliset vaatimusongelmat korjattua.

Pystytä julkinen testiserveri. Lahjo loppukäyttäjät kehitettävien ominaisuuksien testaajiksi. Kirjaa ylös kehityskohdat ja projektin ulkopuoliset toiminnallisuusehdotukset. ”Ihan kiva”-ominaisuuksien lisäksi saat ilmaisia vinkkejä asiakkaasi tuloksen parantamiseksi. Se on rahanarvoista matskua.

Trendisanahelinää

4. syyskuuta, 2009 | Kirjoittaja: Antti Niittyviita

Ohjelmistokehityksestä pitää saada trendikästä hinnalla millä hyvänsä. On valittava muodikkaita termejä kuvaamaan kehityksen toimintatapoja ja ennalta sovittuja prosesseja. Ollaan ketteriä kehittäjiä ja käytetään uusimpia web 2.0 tai jopa 3.0 (?) työkaluja, mutta kuinka käykään todellisuudessa? Katsotaanpa asiaa tavallisen ohjelmistokehittäjän tai vaikkapa testaajan silmin.

Ketteryys on kommunikaatiota. Huippuunsa hiottua, tehokasta ja tuottavaa.

Ongelmia ei puida pitkissä sähköpostiketjuissa, puhelinpalavereissa ja hyväksyntäprosesseissa. Ne pitäisi pystyä ratkaisemaan siltä seisomalta, tekemällä yhteistyötä ongelman ratkaisemiseksi, ei sen dokumentoimiseksi. Kuinka juuri sinun projektissa toimitaan kun testaaja törmää ongelmaan?

Tyypillisesti vika tai virhe dokumentoidaan ensimmäisenä virheidenhallintajärjestelmään ja ilmoitetaan siitä error managerille, jos muistetaan. Dokumentointi tehdään käsin ja se vie aikaa. Testit seisovat ja suorituspaineet kasaantuvat. Raportointi unohtuu helposti tai se jätetään vaiheeseen, jossa kaikki määrätyt testit on ensin ajettu. Täytyy olla tuottavia, muka ketteriä.

Kun vika on lopulta raportoitu, error manageri määrää vian selvitettäväksi kehittäjälle. Kehittäjä alkaa ihmetellä asiaa siinä vaiheessa, kun muistaa tarkistaa sähköpostin ”defect notifications” -kansion. Jos virhe on käsin naksuteltu virhetietokantaan raportti on yleensä osin puutteellinen tai perustelematon. Siitä saattavat puuttua oleelliset logitiedostot tai askeleet virhetilanteeseen pääsemiseksi. Korjaaminen unohtuu kun ei jaksa lähteä selvittämään alkuperäistä ongelmaa. Onko tämä ketterää vaikka niin itselle uskotellaan?

Miksei asiaa voisi hoitaa todellisuudessakin ketterämmin? Raportoidaan ongelmasta mahdollisimman toimivalla kommunikointikanavalla. Laajakaistalla. Jos ajatellaan kommunikaatiokanavien nopeuksia modeemista 100megaiseen laajakaistaan, voitaisiin ketteryyttä tai kommunikaatiota käydä mittaamaan samalla skaalalla.

Virheiden perinpohjainen dokumentointi ja siitä informoiminen sähköpostitse prosessin mukaisesti on yleensä hidasta. Asetetaan tälle toimintatavalle kaistanleveydeksi 56.6kbps. Virheen voi myös raportoida suoraan kehittäjälle.

Vetämällä kehittäjää hihasta ja näyttämällä, että näin virhe tapahtuu ja näin softa kaatuu. Kommunikaation kaistanleveys on tällöin huipussaan. 100mbps.

Välimuotojakin toki on. Asia voidaan hoitaa esimerkiksi puhelimella (512mbps) tai pikaviestimellä (384kbps).

Jos yhteisesti sovittu toimitatapa vaatii dokumentointia ja prosessia, olisi hyvinkin mahdollista valita ensisijaisesti nopein yhteys. Viestin mentyä perille se voidaan varmentaa jollain hitaammalla välineellä kun aikaa on. Tai mikä vielä parempaa: Jos organisaatio on oikeasti mukautumiskykyinen ja ketterä, ottaa käyttöön työkaluja ja apuvälineitä joilla voi automatisoida varmennusväylän.

Kun sinä valitset kotiisi laajakaistaa, eikö olisikin järkevintä valita nopein… varsinkin jos se on kaiken hyvän lisäksi vielä halvin? Ohjelmistokehitykseshän näin käy.

Nopein ratkaisu tulee myös kustannuksiltaan kaikkein halvimmaksi, tuottavimmaksi ja oikeasti ketterimmäksi.