Avainsanat: ‘tuottavuus’

1,7 miljardin euron projekti myöhässä vuosia – tilaaja ei huolissaan

tiistai, 12 heinäkuuta, 2011 | Kirjoittaja: Jaakko Sakaranaho

Vaikka Antti väitti taannoin, että heinäkuussa ollaan kesätauolla, niin tästä on pakko kirjoittaa.

Tämmönen uutinen osui eilen silmään Tietoviikosta.  Uutinen kertoo, että USAn armeijan SAP-projekti on vuosia myöhässä. Projekti on alkanut vuonna 2005, sen piti olla valmis vuonna 2007, jolloin uusi valmistumistavoite asetettiin vuoteen 2010. Tämän hetken arvaus on, että uusi ERP olisi käytössä tämän vuoden joulukuussa.

Muutama mehukas poiminta jutusta:

Uusi SAP-järjestelmä korvaa valmistuessaan yli 140 erillistä vanhaa järjestelmää. Uudella erpillä hallinnoidaan 140 miljardin dollarin vuosibudjettia, ja se palvelee 80 000 käyttäjää. Noin 15 500 ihmistä käyttää jo nyt järjestelmää.

Vau, projekti on neljä vuotta myöhässä alkuperäisestä suunnitelmasta, ja vajaa viidesosa käyttäjistä käyttää järjestelmää!

Vuodesta 2005 käynnissä olleessa projektissa ei ole vieläkään tunnistettu kaikkia vaatimuksia ja kuluja. Myös tarkastajien vuonna 2008 antamasta 16 suosituksesta seitsemän on edelleen toteuttamatta.

Yhtäkkiä tuo arvio käyttöönotosta tämän vuoden joulukuussa alkaa kuulostaa kovasti optimistiselta.

Tilintarkastajien mukaan projekti on tullut jo yli 53 miljoonaa dollaria budjetoitua kalliimmaksi. Vaarana on myös se, ettei järjestelmä valmistuessaan palvele alkuperäisiä tavoitteitaan.

Yhdysvaltain armeija ei tarkastajien raportin mukaan ole itse yhtä huolissaan projektin tulevaisuudesta vaan toteaa, että esitetyt riskit ovat hallittavissa eivätkä ne vaikuta hankkeen kustannuksiin tai aikatauluun.

Anteeksi mitä täh häh? “Ei vaikuta kustannuksiin tai aikatauluun”? Kuinkahan paljon projektin pitäisi olla myöhässä, että se vaikuttaisi aikatauluun. Melko varma olen siitä, että armeijan päälliköt eivät tee tuota projektia omilla rahoillaan.

Älyttömän tarinan lopussa on kuitenkin jotakin järkevääkin.

Amerikkalaisen konsulttifirma Asuretin toimitusjohtaja Michael Krigsman muistuttaa, että kaikissa suurissa erp-projekteissa vaikuttaa aina kolme tekijää: ohjelmistotoimittaja, järjestelmäintegraattori ja asiakas. Jotta hanke onnistuu, kaikkien täytyy hoitaa oma roolinsa hyvin.

Eittämättä tässä tilanteessa asiakas, USAn armeija, ei ole vahtinut toimittajien perään riittävästi. Miksi pitäisikään, koska riskit ovat hallittavissa eikä aikatauluongelmia ole.

Yritykselläsi ei ole rahaa yhtä paljon kuin USAn armeijalla. Ennen toimitussopimuksen allekirjoittamista valitse itsellesi puolueeton kumppani, joka auttaa yritystäsi pitämään toimittaja aikataulussa.

Share

Askel kerrallaan kohti toimivaa testausta

torstai, 5 toukokuuta, 2011 | Kirjoittaja: Antti Niittyviita

Kun testaus puuttuu tai se ei toimi, ongelman myöntäminen on yhtä tuskaa. Yleensä se paljastuu vasta kun tavara on jo osunut tuulettimeen. Edelleenkin liian usein puhelin soi meidän toimistolla kun huonot on jo housussa.

Meiltä puuttuu toimiva testaus. Miten tässä nyt kannattaa toimia?

Koska epävarmuus niin usein kalvaa toimivan testauksen rakentajaa, ne ensiaskelet jäävät ottamatta. Vasta pakko pistää liikettä niveliin. Silloin asiakas hengittää jo niskaan ja softakehittäjän aika palaakin yllättäen virheiden korjailuun.

Me päätimme tarjota ilmaisen opetuksen siitä, miten toimiva testaus voidaan rakentaa sopivan pienistä rakennuspalikoista.

  1. Kehitä: Rakenna softakehittäjien kanssa säännöllinen elämänrytmi. Jotain testattavaa on tultava tuutista ulos usein. Ilman tätä ei ole mitään järkeä investoida testaukseen.
  2. Resurssoi: Palkkaa riittävän kokenut testausosaaja tai osta palvelu partnerilta. Pääasia on, että tyyppi on oikeasti testaaja, eikä vain huono devaaja!
  3. Testaa: Polkaise hommat käyntiin tutkivan testauksen menetelmällä. Asiakkaasi elämään vaikuttavien vikojen löytyminen mahdollisimman aikaisin on oikeasti se, mihin kannattaa investoida heti!
  4. Rakenna: Tuo mukaan uusia työkaluja. Paranna testauksen- ja virheidenhallintaa. Rakenna systemaattinen tapa toimia esimerkiksi tarkistuslistoilla. Voit pohtia myös automaatiota.
  5. Tiivistä: Tiivistä kuilua kehityksen ja testauksen välillä. Tähtää testauksessa pitkistä vesiputouksista lyhyisiin tai Agileen.
  6. Mittaa: Rakenna enintään kolme helppokäyttöistä mittaria softan laadun arviointiin. Meidän mittarimme perustuvat kaikki virhetietoihin.
  7. Optimoi: Säädä testauksen määrää asteittain kunnes optimaalinen taso on löytynyt.

Hoitamalla yhden asian kerrallaan pääsee softakehityksessä jo pitkälle. Näiden askelmerkkien avulla on mahdollista rakentaa täysin uusi ja laadukas näkökulma ohjelmistojen rakentamiseen alle kuukaudessa.

Voit rakentaa toimivan testauksen pienistä osatavoitteista. Sinun on vain otettava härkää sarvista ja ryhdyttävä toimeen!

P.S. Jos alkuun pääseminen tuntuu vinkeistä huolimatta hankalalta, voit tilata meiltä Kick-offin. Me hoidamme kohdat 1.-4. pois kuleksimasta vain kahdessa viikossa! Sinun ei tarvitse osallistua kuin aloitustapaamiseen ja loppukatselmointiin.

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

Pakkopaita vai Havaijipaita?

torstai, 10 maaliskuuta, 2011 | Kirjoittaja: Jussi Niittyviita

Teppo Testaajan (nimi muutettu) harteille on vyörytetty suuri vastuu. Tepon on valmisteltava testausraportti viimeisimmästä testikierroksesta. Useita kertoja raportin tehneenä Tepon otsaan alkaa jo ennen kierroksen loppumista ilmestymään pieniä hikipisaroita. Viimein tulee raportoinnin aika. Tärisevin käsin Teppo suorittaa piinaavan pitkän ja turhauttavan prosessin:

  1. Teppo exporttaa kalliilla rahalla hankitusta testauksenhallintajärjestelmästä testikierroksen tarkat tiedot käyttäen hyväksi Excel-makroa (jonka hän on itse verta ja kyyneliä vuodattaen tehnyt).
  2. Excel-makron tuottamasta taulukkojen sekasotkusta Teppo eristää olennaisimmat tiedot – kuvat ja diagrammit – ja liittää ne lopuksi lähetettävään sähköpostiin. Useat kuvista ja diagrammeista vaativat tarkkaa uudelleen skaalausta liittämisen jälkeen, jotta sähköpostista tulisi luettavan näköinen.
  3. Managerit haluavat myös nähdä tarkan listauksen testitapauksista, joten Tepon on edelleen palattava Excel-taulukoiden pariin. Koska suoraan Excelistä rivien liittäminen sähköpostiohjelmaan ei ikinä toimi halutulla tavalla, Teppo joutuu avaamaan notepadin, jonka kautta rivit saadaan liitettyä lopulta sähköpostiin sopivan näköisenä ja muotoisena.
  4. Hiki otsalla kimallellen Teppo lisää postin alkuun lyhyen kuvauksen testikierroksen tapahtumista, ongelmista ja niiden ratkaisuista.
  5. Lopuksi Teppo liittää kalliilla rahalla hankitusta testauksenhallintajärjestelmästä exportatun Excel-taulukkohelvetin kokonaisuudessaan postiin mukaan. Excel-taulukkohelvetissä löytyy kaikki samat tiedot, mitä Teppo oli juuri tuskalla ja vaivalla koostanut postiin. Teppo tekee parhaansa ymmärtääkseen, että Excel-tiedoston avaaminen ja tietojen lukeminen sieltä on monelle manageritason henkilölle kovin vaikeaa.
  6. Teppo lisää sähköpostin vastaanottajakenttään erinäisen määrän osoitteita ja muutaman sähköpostilistankin.
  7. Turhautuneena ja lähes itkua tihrustaen Teppo, iso mies ja aikanaan ylpeä Ammattitestaaja, painaa Send-nappia. Lukeekohan tätäkään raporttia kukaan? Viestiin vastaa odotetusti ainoastaan Testimanageri Urpo joka ilmoittaa, että seuraavaan raporttiin on saatava lisää sitä ja tätä ja sen on oltava myös powerpoint-muodossa. Vastauksen lopussa komeilee vielä kysymys, joka pudottaa pohjan kaikelta testauseettisesti oikealta: Miksi raportissa on niin paljon punaista!? Ikäänkuin Teppoa syytettäisiin tästä…
  8. Takki täysin tyhjänä Teppo alkaa henkisesti valmistautumaan seuraavaan testikierrokseen.

Kuulostaako tutulta? Hyvän testiraportin aikaansaamiseksi ei nykyaikaisessa kustannustehokkuuden säätelemässä bisnesmaailmassa riitä lopputulos, vaan tärkeää on myös raportin tuottamistapa. Harmillisen useat työkalut eivät edelleenkään synny loppukäyttäjän, eli testausasiantuntijan tarpeista. Käyttäjä on se, joka mukautuu työkalun kiristämässä pakkopaidassa.

Onko liikaa vaadittu, että työkalu tarjoaa suoraan mahdollisuuden koostaa sellainen raportti, joka sisältää yksittäisen käyttäjän itsensä vaatimat kohdat? Onko liikaa vaadittu, että millä hetkellä hyvänsä kuka tahansa työkalun käyttäjä näkee projektin etenemisen vaiheet ja kehityksen kannalta olennaisimmat asiat? Olisihan se utopiaa jos kaikki yllämainittu kävisikin muutamalla hiirenklikkauksella!

Helppokäyttöinen, yksinkertainen ja aikaa säästävä työkalu on tulevaisuuden työkalu. Ihmiset, joilla ei ole tietoa paremmasta ovat urautuneet raiteilleen ja eivät näe uusien työkalujen mukanaan tuomia etuja. Jos on koko ikänsä käyttänyt päivittäin pakkopaitaa ja siveysvyötä, saattavat Havaijipaita ja rennot shortsit kommandona tuntua aluksi melko oudoilta.

Lyhyen päänsisäisen tutustumistyön jälkeen vanhat kiristävät tamineet poljetaan kuitenkin syvälle suohon. On vain ajan kysymys kun kankeat suurten firmojen suurille firmoille valmistamat työkalut syrjäytyvät oikeasti käytännöllisten työkalujen tieltä.

Tyydytkö istumaan pehmustetussa huoneessa pakkopaita päällä juoden valkotakkisen miehen tarjoamaa taikajuomaa tikkupillillä, vai istutko aurinkoisella hiekkarannalla Havaijipaita päällä piña colada kädessä seurustellen mukavien kavereiden kanssa?

P.S. Suosittelemme tutustumaan suomalaislähtöiseen ryhmätyökaluun nimeltä FlowDock. Se on tehty juuri oikealla asenteella loppukäyttäjä mielessä pitäen.

Share

Tarkistuslistapohjainen tutkiva testaus

keskiviikko, 2 maaliskuuta, 2011 | Kirjoittaja: Antti Niittyviita

Olemme vuosien varrella valittaneet ankarasti testaukseen liittyvistä asioista. On valitettu huonoista työkaluista, testitapausten suunnittelusta, jäykkäniskaisesta yrityskulttuurista, väärien asioiden tekemisestä ja tehottomuudesta. Valitusta on riittänyt, mutta nyt päätimme muuttaa testaustyön luonnetta heti kerralla. Päätimme kirjata ylös sen mitä useimmat testaajat huomaamattaan jo työkseen tekevätkin.

Me törmäämme yhä maailmalla liikkuessamme muka superhienoihin testispekseihin. Testien suunnitteluun on käytetty pirusti työaikaa ja se tuntuu maksajasta varmasti hyvältä. Yhteistä näille noin 80%:lle perinneprojekteista on törkeän huonot testitapaukset. Yleensä testitapaukset kertovat yksityiskohtaisesti MITEN testi suoritetaan. Silloin nus.. viilataan pilkkua.

En tietenkään sano, että viilaminen on mitenkään tylsää hommaa. Bisneksen tekemisessä paukkuja vain käytetään silloin ihan vääriin asioihin.

Testitapauksen tulee ensisijaisesti kertoa MITÄ tulee tulla testatuksi! Sen voi ihan oikeasti sanoa muutamalla lauseella. Oikeastaan Twitter on todistanut, että useimmat asiat voi sanoa vain 140:llä merkillä!

Testauksenhallintajärjestelmien käyttöä ja testaustyön dokumentointia puoltavia perusteluja on runsaasti. Mutta kuinka voitaisiin yhdistää nopea ja tavoitekeskeinen testaussuunnittelu, tutkiva testaus ja sopiva dokumentoinnin taso raportointia ajatellen?

Erittäin toimivaksi ratkaisuksi olemme huomanneet tutkivan testauksen jota tuetaan tarkistuslistoilla. Homma toimii siten, että testispeksit tehdään yksinkertaisena tarkistuslistana asioista mitä session lopussa tulee vähintään olla testattuna. Otsikointiin riittää helposti tuo 140 merkkiä ilman että järkeään käyttävälle testaajalle jää epäselväksi testin tavoite. Testitapauksen askelet ja muun oheiskrääsän olemme heittäneet mäkeen. Yleensä niiden kanssa säätäminen syö vain aikaa, eli rahaa.

Tarkistuslistaa voi käyttää testauksenhallintajärjestelmästä ja tuloksetkin voi kirjata sinne. Myös Excel toimii varsin helposti kun muistaa minimalistisen lähestymiskulman.

  • Testien suunnittelu ja speksaaminen on supernopeaa
  • Testien ajaminen ei aiheuta putkinäköisyyttä vaan on tutkivaa
  • Virheitä löytyy merkittävästi enemmän käytettyyn rahamäärään nähden
  • Pomokin tykkää kun pystytään lyömään statsit ja rapsat tiskiin
  • Tarkistuslistat kelpaavat myös esimerkiksi käyttöönottoinsinöörin työvälineeksi

Asiaa voi pysähtyä pohtimaan myös testausammattilaisen näkökulmasta. Hänen voi huomata tekevät töitä hyvin saman kaltaisilla menetelmillä jo valmiiksi. Ainoa ongelma on, että usein hän tekee sen kaiken jäykkäniskaisen, pysähtyneen ja muutosvastarintaisen prosessin kahlitsemana. Siksi tuloskaan ei aina tyydytä!

Saat enemmän vastinetta rahoillesi, kun uskallat antaa testausosaajasi hoitaa hommat kuten osaajan kuuluukin.

Share