Avainsanat: ‘ketterä’

Testaaja istuu kartturin paikalla

torstai, 16 kesäkuuta, 2011 | Kirjoittaja: Antti Niittyviita

Kauhukahvasta ei voi ohjata. Siitä pidetään kiinni rystyset valkoisena kun tie yllättäen käy kuoppaiseksi.

Istuin alkuviikosta kartturina matkalla lounaalle. Tehtäväni oli kertoa mistä käännytään matkalla kiinalaiseen ravintolaan. Istun autossa harvoin muualla kuin ratin takana ja siksi matka oli opettavainen. Minulle se opetti paljon testaajan elämästä ohjelmistoprojektissa.

Kartturin saappaissa näin tietysti jatkuvasti kaiken mitä liikenteessä tapahtui ja ketä muita tien päällä liikkui. Saatoin jatkuvasti tuntea jos nopeus olisi ollut liian kova tai ehkä liian hidas. Tunsin tietysti senkin oliko matka kuoppainen ja kuinka jyrkkiä hidasteet olivat. Kuskin jarrutukset ja kiihdytykset olivat minulle päivänselvä juttu. Ne olisin havainnut vaikka silmät kiinni. Näin myös jatkuvasti onko takana tuleva liian lähellä. Osasin myös arvioida näyttääkö tien pinta sateen jälkeen vaaralliselta. Eikä huomioiden tekeminen siihen loppunut. Listaa voisi jatkaa loputtomiin.

Kaiken tämän informaation pystyin keräämään pelkästään tilanteen seuraamisesta ja tuntemisesta. Niin varmasti kuskikin teki. Ja menestyksellähän ei ollut mitään tekemistä auton mittareiden kanssa. Ajatelkaapa jos olisimme kuskin kanssa molemmat tuijotelleet koko matkan nopeus-, kierros-, kulutus- ja matkamittareita, kuten softaprojekteissa niin usein on tapana. Äkkiä olisimme löytäneet itsemme ojasta.

Testaaja, kuten kartturikaan eivät pysty suoraan vaikuttamaan matkantekoon. Oikeanlainen kommunikaatio on kaiken a ja o.

Tämä reissu oli siksi onnellinen, että pystyin todella vaikuttamaan matkantekoon. Kuski oli fiksu ja hän ymmärsi ohjeet mainiosti. Meillä oli myös ennalta sovittu yhteinen tavoite mielessä. Kommunikaatio pelasi erinomaisesti molempiin suuntiin.

Kartturina yritin tietysti antaa ohjeet rakentavasti ja hyvissä ajoin. Ilmeisesti myös onnistuin siinä, koska kiinalaista saimme lounaaksi ja vielä molemmat samassa paikassa. Mutta mitäpä olisikaan tapahtunut, jos olisin vain viisastellut ja kuittaillut “tuosta olisi pitänyt jo kääntyä”? Veikkaan, että omalta osaltani matkanteko olisi jatkunut jalan.

Minusta mittarit ovat oivallinen apuväline matkan tekoon. Pääpaino oikeiden ratkaisuiden tekemisessä ei kuitenkaan voi ikinä olla niissä. Kysmys on lähes aina perstuntumasta ja oikeasta keskustelutavasta. Kysymys on fiiliksestä. Jotkut kutsuvat sitä intuitioksi, toiset taas kokemukseksi. Homman nimi on kuitenkin aina sama niin autoilussa, kuin softakehityksessäkin.

Faktat, mittarit ja numerot ovat oivallinen apuväline, mutta todelliset ratkaisut ja onnistumiset rakennetaan aina lopulta tunnepohjalta. Luottamuspula tunteisiin on päätöksen pahin vihollinen.

P.S. Tällä matkalla kauhukahvaan ei tarvinnut tarttua. Kyyti oli mukava ja tiimi toimi!

Share

Kaikki aseet mitä tarvitset

maanantai, 30 toukokuuta, 2011 | Kirjoittaja: Antti Niittyviita

Sucker Punch oli hyvä leffa. Uskallan sen sanoa, vaikka eriäviä mielipiteitä sataa kaatamalla. Päällimmäisenä koko elämyksestä minulla jäi mieleen uskomattoman osuva lainaus:

You have all the weapons you need… now fight!

Tuo kohtaus pysäytti minut. Se pysäytti siksi, että sain itseni kiinni mitä typerimmästä ajatusmaailmasta. Olen kai aina ajatellut, että tuloksen aikaansaamiseksi tarvitaan työkaluja. Aseita, joilla homma hoituu aina tehokkaasti ja mutkattomasti.

Kun suomalaista miestä kohtaa ongelma, pihalamppu on palanut tai toimiston wc-istuin on rikki, mies lähtee rautakauppaan. Reissulta tarttuu mukaan uskomattoman tarpeellinen joukko uusia työkaluja, joita ilman ei takuuvarmasti olisi tullut toimeen. Joskus siinä hässäkässä saattaa unohtua jopa itse asia, eli se pihalamppu tai istuin.

Sama ongelma lyö päivittäin kapuloita rattaisiin lukuisissa softaprojekteissa ympäri maailman. Tuskallisen luovan työn ja hommiin ryhtymisen sijasta ihmiset etsivät mitä hienoimpia työvälineitä netistä, virittelevät niitä toimintaan ja saattavat jopa maksaa niistä mansikoita. Kuitenkin lähes poikkeuksetta nämä työvälinehankinnat ovat tuloksen aikaansaamisen pahin este.

Testauksenhallintajärjestelmä on yksi näistä vehkeistä. Useimmiten niitä otetaan isolla tohinalla käyttöön ja aletaan paiskimaan kunnolla töitä työkalun täyttämiseksi dokumentaatiolla. Suomeksi sanottuna siis testitapauksilla, vaatimuksilla ja testien toistokierroksilla. Oikeasti samat testaustyön tulokset olisi voinut saavuttaa hyödyntämällä järkevästi vain 10% järjestelmän ominaisuuksista. Tai kokonaan ilmankin!

Tieturin Testaus 2011 -seminaarista minulle jäi elävimmin mieleen Elisa Puoskarin puheenvuoro Sulakkeen toimintatavoista. Sulakkeella sprintit ovat päivän mittaisia. Sulakkeella on heitetty myös virhetietokantajärjestelmät mäkeen. Projektihuoneen seinällä komeilee taulu post-it lappuja, yksi erroria kohti. Sillä ei voi haaskata aikaa rautakaupassa norkoiluun, konffaukseen, servereihin, tietohallintoon eikä käyttäjäoikeuksiinkaan.

Työkaluihin keskittymisen sijaan Sulakkeella on ymmärretty se, mitä Sucker Punch yritti sanoa.

Lopeta joutava esteiden, ongelmien tai syyllisten etsintä ulkopuolelta ja pysähdy hetkeksi miettimään. Sinulla on jo kaikki työkalut, mitkä onnistumiseen tarvitset. Älä pelkää käyttää niitä!

Share

Omaan ketteryyteen on helppo kompastua

tiistai, 19 huhtikuuta, 2011 | Kirjoittaja: Jussi Niittyviita

Scrum! Ketteryys! Nopeus ja tehokkuus! Kuulostaa hienolta ja käytännölliseltä. Näitä hyveitä soveltaen ei mikään voi mennä pieleen! Motivaatio on huipussaan ja tekeminen alkaa hampaat hulmuten. Jossain vaiheessa tie kuitenkin käy kiviseksi.

Liikkuvia lajeja harrastaneena voin kertoa, että liika luottamus omaan ketteryyteen ja nopeuteen ei vie kovin pitkälle. Juosten ja kärrynpyöriä/voltteja tehden liikkuminen näyttää tyylikkäältä ja vakuuttavalta, mutta suorittajan kannalta on valittu juurikin se mahdollisimman epäedullinen liikkumismuoto.

Kävellessä ehtii havainnoimaan paljon enemmän mitä ympärillä tapahtuu, kompastumisen vaara on huomattavasti pienempi ja liikkuminen on myös tehokkaampaa. Kävellessä on aikaa katsoa mihin seuraavan askeleen astuu.

Nokkelimmat saattoivat jo päätellä tämän metaforan juontavan työtapojen kehittymiseen. Maltillinen ja jatkuvan tarkkailun alla oleva muutos on aina lopputulokseltaan tehokkaampi kuin päätäpahkaa metsään juokseminen. “Kokeillaan toimiiko tämä, koska se toimi myös naapurin organisaatiossa!” -mentaliteetti johtaa väistämättä ongelmiin. Jokainen organisaatio on erilainen. Jokainen organisaatio vaatii erilaisia työmenetelmiä.

Kuinka sitten ketteryys näkyy käytännön työelämässä? Valitettavan monissa projekteissa ei osata naulata seinälle selkeitä toimintatapoja, joita kaikkien on helppo noudattaa. Valitettavan monissa projekteissa menettelytavat ovat jatkuvasti suunnittelu- ja muutostilassa. Ei ehditä kokeilemaan mitään tapaa kunnolla ja kokemukset jäävät keräämättä. Parhaat käytännöt jäävät oppimatta.

Valitettavan useat firmat ovat sokaistuneet sanan Scrum valovoimasta ja ajautuvat aina vain kauemmaksi tehokkaan kehityksen tieltä. Lopulta ne vieraantuvat tuotekehityksen todellisuudesta. Tekijät, tiimipäälliköt ja sadanpäämiehet istutetaan samaan suureen tilaan siinä toivossa, että tieto kulkisi vaivattomammin. Työkaluiksi valitaan massiivisia ja kalliita multimonitoimi-vasaraporamittanauharuuvimeisseli-työkaluja, joiden pitäisi tukea Scrumin periaatteita. Tämäkö on sitä ketterää ohjelmistokehitystä?

Lare Lekman  on listannut Ketteryys.fi blogissa Scrumin tärkeimpiä asioita:

  1. Toimita säännöllisesti jotain
  2. Varmista, että toimitat korkeimman prioriteetin asiat
  3. Pyri parempaan jokaisessa iteraatiossa/julkaisussa

Ketteryys ohjelmistokehityksessä perustuu selkeisiin suuntaviivoihin, joita kaikki pystyvät noudattamaan. Se ei ole jatkuvasti muuttuvaa sekameteliä tai nopean näköistä sähläystä. Se on asiantuntemuksella otettuja hallittuja askelia. Jatkuvaa liikettä eteenpäin.

Kiireelliset deadlinet eivät muuta toimintatapaa tyylikkäiksi juoksuaskeliksi. “Toimita säännöllisesti jotain” ei tarkoita, että merkataan keskeneräinen taski valmiiksi. Sähläten puoliksi implementoitu done tuottaa varmasti enemmän ylimääräisiä kustannuksia kuin vähän myöhemmin kunnolla implementoitu done. Siitä myös testaus pitää huolen.

Oikeaa ketteryyttä on siis ottaa laadukkaita, tasapainoisia ja riittävän lyhyitä askeleita tavoite kirkkaana mielessä.

Share

Testausguru parantaa prosessia

tiistai, 5 huhtikuuta, 2011 | Kirjoittaja: Antti Niittyviita

Testausguru Esko työskenteli softakehittäjien kanssa tiiviissä yhteistyössä projektissa, jonka työtapa oli jatkuva integraatio. Eskon vastuulla oli huolehtia, että softan laatu on aina hyvä. Testauksen lisäksi Esko huolehti siitä, että löydetyt virheet myös korjataan.

Jatkuva integraatio tähtää aina toimivaan järjestelmään. Kun kehittäjä lyö tekemänsä muutoksen versionhallintaan, niin järjestelmän pitäisi olla sen jälkeen ehommassa iskussa. Yleensä järjestelmästä tehdään buildi heti muutosten jälkeen tai joka yö töiden päätyttyä. Perinteisesti testaaja iskee kiinni nimenomaan näihin yöllisiin buildeihin.

Esko tiesi tämän tavan ongelmat. Kun testaaja työstää yöllistä buildia, niin kehittäjä painiskelee jo uusien asioiden kanssa. Vaikka kehitys ketterää onkin, niin silloin testaaja työstää vanhaa softaa. Kun virhe löytyy tässä vaiheessa, se on jo myöhäistä. Testaaja ja kehittäjä joutuvat hyppäämään aikakoneeseen ja palaamaan ongelman alkulähteelle.

Tämä menetelmä lähestyy aivan huomaamatta perinteistä vesiputousmallia. Se on siis sarja pieniä vesiputouksia. Speksaus-devaus-testaus. Näin toimii hämmästyttävän iso osa yrityksistä, jotka väittävät testauksen olevan saumaton osa ketterää kehitystä.

Jotta testaus kulkee ketterän kanssa käsi kädessä, edellä kuvattua kuilua pitää kaikin tavoin kaventaa. Esko osasi hommansa, otti härkää sarvista ja kavensi kuilua. Esko ehdotti kehitykselle yhteistyön tiivistämistä entisestään. Mitä siis Esko ehdotti?

Kehittäjä toimittaa JOKAISEN tuotoksensa AINA ensin testaukseen. Vasta sen jälkeen tulee versionhallinnan vuoro.

Esko otti rohkeasti vastuun muutoksen lanseeraamisesta. Hän rohkaisi kehittäjiä tuomaan kaikki korjaukset ensin itselleen ja vasta sitten versionhallintaan. Tuloksena löytyi iso määrä bugeja jo ennen yöllisiä buildeja. Virheet siis löytyivät yli vuorokauden aikaisemmin, mikä oli oikeasti merkittävä aika kahden viikon sprintissä.

Regressiovirheiden määrä yöllisissä buildeissa putosi 60% ja niistä löytyneiden muiden virheiden selvittelyyn haaskattu aika putosi lähes puoleen.

Kun testausguru parantaa prosessia, se tuottaa hyvää tiimin kaikille pelaajille.

Share

Hyvin suunniteltu ei ole puoliksi tehty

torstai, 17 helmikuuta, 2011 | Kirjoittaja: Antti Niittyviita

Juuri pöllimäni tarina kertoo ukrainalaisesta luutnantista, joka lähetti pienen tiedustelujoukon Alpeille. Raju lumimyrsky yllätti ryhmän ja pyryä jatkui taukoamatta kaksi päivää. Luutnantti oli varma karvaasta miestappiosta, kun ryhmästä ei toisenkaan päivän iltana kuulunut uutisia. Kaikkien suureksi yllätykseksi ryhmä kuitenkin palasi vuorilta kolmantena päivänä ja vieläpä ehjin nahoin. Mitä oli tapahtunut? Kuinka ryhmä selviytyi tukalasta tilanteestaan?

Helmikuun kuumottavin puheenaihe on ollu palava lautta. Erityisesti Nokian sellainen. Stephen Elopin kirje työntekijöille kertoi karua kieltä. Erityisesti siitä että Nokialla tehtään yhä paljon vääriä asioita.

Chinese OEMs are cranking out a device much faster than, as one Nokia employee said only partially in jest, “the time that it takes us to polish a PowerPoint presentation.”

Karkeasti ottaen kysymys on siitä, että kiinalainen laitevalmistaja pukkaa tuotteen markkinoille nopeammin kuin Nokialla saadaan PowerPoint kalvot kasaan. Sama ongelma vaivaa isoa siivua suomalaisia yrityksiä tuotekehityksestä testaukseen. Työpanoksesta suuri osa valuu monesti suunnitteluun, säätämiseen ja excelien pyörittelyyn. Tuloksen syntymisen kannalta siis joutavaan puuhasteluun.

Ukrainalainen tiedustelijaryhmä selvisi tukalasta tilanteestaan nopealla toiminnalla. Tilanne oli näyttänyt epätoivoiselta myös tiimin näkökulmasta kunnes joku oli löytänyt taskustaan kartan. Sen jälkeen tiimi ryhtyi toimeen. He pystyttivät leirin, odottivat myrskyn loppumista ja selvisivät lopulta takaisin tukikohtaan. Mielenkiintoista tarinassa on se, että tämä kartta oli Pyreneiltä, ei Alpeilta.

Jos ryhmä olisi alkanut viilaamaan suunnitelmaa, selviytymisstrategiaa ja vielä dokumentoimaan sitä, kaikki olisivat auttamatta paleltuneet kuoliaaksi. Sen sijaan he päättivät rauhoittua, ottaa härkää sarvista ja panna toimeksi. Tarinan opetus tietysti on se, että usein huonokin suunnitelma riittää.

Testaustyössä kuvitellaan usein, että hyvä testiplani ja tarkka testispeksi ovat olleet menestyksen salaisuus. Esimiehet ovat tykänneet kivoista exceliraporteista ja softakin on saatu yleensä aikataulussa valmiiksi, kiitos devausgurujen. Siksi liian moni testausasiantuntija urautuu. Hän kuvittelee, että menestys on saavutettu nimenomaan suunnitelmien ja speksien kautta ja alkaa panostaa aina enemmän näihin asioihin.

Kun urautunut asiantuntija panostaa jatkuvasti enemmän suunnitteluun ja excel-harjoituksiin, amatööriltä näyttävä kilpailija painaa ohi oikealta ja vasemmalta.

Kun yksi laittaa töpinäksi, hän tutkii hetkessä monta reittiä loppuun saakka. Samassa ajassa ns. fiksut hädin tuskin ehtivät valmistautua edes ensimmäiselle etapilleen.

Todelliset onnistujat menestyvät, koska he riisuvat kravaatin, käärivät hihat ja ryhtyvät heti toimeen! Siksi hyvin suunniteltu ei ole puoliksi tehty.

Share