Nykyään laadunvarmistuksen edistymisen seurantaan käytetään runsaasti mittareita. Useimmat niistä ovat varsin hyödyllisiä, mutta ne ovat kaikki yleensä yksiulotteisia siinä mielessä, että ne ovat tilannekuvia tietystä ajanhetkestä tai sprintistä. Tämä pätee jopa nopeus- ja trendimittareihin, jotka ovat uskomattoman tärkeitä mutta ovat jälleen kerran vain tilannekuvia.
Kun työskentelin Symantecilla, huomasin seuraavaa:
Laadunvarmistukseen käytettiin paljon mittareita määrittämään toimituspäivään mennessä (väitetysti) saavutetun laadun *tason*. Mutta mitään mittareita ei kerätty sen mittaamiseksi, kuinka paljon tämän laadun saavuttaminen *maksoi*, ei prosessin aikana eikä jälkikäteen.
Toisin sanoen meitä ei kiinnostanut, kuinka tehokkaasti kyseinen laatu saavutettiin projektin aikana.
Tuotteesi on ehkä toimitettu korkealaatuisena, mutta tarvittiinko sen saavuttamiseen todella niin paljon aikaa ja vaivaa kuin käytettiin?
Tämä on tehokkuuskysymys, ei sinänsä laatukysymys, mutta nämä kaksi liittyvät vahvasti toisiinsa.
Laadun ja tehokkuuden leikkauspiste
Laatu ja tehokkuus kohtaavat, koska yksi merkittävistä syistä siihen, että ohjelmistoprojektit ylittävät usein huomattavasti sovitun aikataulunsa (ja tämä tulee usein odottamattomana “koukkuna” projektin loppuvaiheessa), on koodin heikko laatu. Eikä kyse ole vain alkuperäisen koodin laadusta, vaan laadusta koko projektin ajan.
Toinen syy, joka on oikeastaan vain väistämätön seuraus koodin heikosta laadusta, ovat virheet, jotka vaativat useita korjausyrityksiä ja kattavat useita testikierroksia tai sprinttejä ennen kuin virhe todella korjataan. Jos se ylipäätään korjataan.
Nämä loputtomat korjaamisen, testaamisen ja uudelleen epäonnistumisen kierrokset lisäävät lähes jokaiseen ohjelmistoprojektiin lukemattomia henkilötyöviikkoja.
Silti mielenkiintoista kyllä, tämä epäonnistumismalli ei näy yksilöitynä missään muissa näkemissäni projekti- tai laatumittareissa. Kuten edellä todettiin, kaikki nämä mittarit ovat ajanhetken tilannekuvia eivätkä siksi onnistu kuvaamaan tätä ilmiötä.
Minulle tuli mieleen, että tämän epäonnistumismallin kuvaamiseen olisi yksinkertainen tapa. Kehitin mittarin, jolle annoin nimeksi ”Aika laatuun” eli TTQ.
Have an account? Log In
Uuden mittarin esittely: Aika laatuun (TTQ)
Itse mittari on varsin yksinkertainen. Se toimii näin:
Seuraa jokaisesta testikierroksesta (määrittelitpä sen miten tahansa) paitsi läpäisseiden tai hylättyjen testien määrää, myös ensimmäisellä yrityksellä läpäisseiden testien määrää. Seuraa lisäksi, kuinka moni testi vaati kaksi, kolme tai useampia yrityksiä ennen kuin samat testit lopulta läpäisivät.
Yksinkertaisena esimerkkinä: jos suoritat 20 testiä ja niistä 5 läpäisee ensimmäisellä yrityksellä, TTQ-suhteesi on 25 %. Mitä suurempi luku, sitä parempi. Se on yksinkertainen, laskettavissa oleva ja helposti saatavilla oleva kokonaiskoodin laadun indikaattori.
Tämä mittari kertoo erittäin hyvin koodin alkuperäisestä laadusta.
Se johtuu siitä, että mitä laadukkaampaa koodi on, sitä harvemmin joudut suorittamaan testin sitä vastaan ennen kuin testi läpäistään. Ja päinvastoin. Tämä mittari on paljon tarkempi kuin virhemäärät ja trendit.
TTQ on myös uskomattoman hyödyllinen projektin seurantamittari.
Jos esimerkiksi 70 % testeistä läpäistään ensimmäisellä testikierroksella ja 30 % epäonnistuu, voit kohtuudella olettaa, että projektisi on edelleen aikataulussa. Mutta jos sanotaan, että vain 20 % testeistä läpäistään ensimmäisellä suorituskerralla, niin teknisin termein ilmaistuna ”tyttö, olet pulassa! ”
Tämä tarkoittaa, että et todellisuudessa suorittanut onnistunutta ensimmäistä kierrosta. Ja tuo aika on lisättävä uudelleen tulevaan kierrokseen laatuvelkana.
TTQ-mittari on erittäin hyödyllinen niin sanottuna ”laukaisumittarina”.
Jos käytät sitä johdonmukaisesti, se tarjoaa erittäin tarkkaa tietoa, jonka avulla projektipäällikkö voi selvittää, onko projekti suistumassa raiteiltaan jo kauan ennen kuin juna todella lähtee raiteilta.
Tämä tarkoittaa, että ennakoiviin toimiin voidaan ryhtyä paljon aikaisemmin tilanteen palauttamiseksi hallintaan. Näin vältetään kiusalliset myöhäisen vaiheen tunnustukset siitä, että projektin aikataulu on repaleina. Toisin sanoen käytä TTQ-kynnysarvoa määrittämään, onko projektin tila edelleen vihreä, keltainen vai muuttumassa punaiseksi. Tee siitä olennainen osa projektin tilaa.
Koska myönnetään nyt, että yksi ohjelmistokehityshankkeiden jatkuvista ongelmista on itsepintainen kieltäminen siitä, että asiat menevät pahasti pieleen, kun tämä käy ensimmäisen kerran ilmeiseksi. Kaikki pelkäävät leimautuvansa ”negatiivisiksi” tai että heitä pidetään liian laiskoina tai sitoutumattomina korjaamaan asioita tai ettei heitä pidetä ”joukkuepelaajina”. Yhteys toimimattomiin perheisiin on epämukavan ilmeinen.
Tämä kaikkien tiedossa olevien tosiasioiden kieltäminen ja tukahduttaminen synnyttää epäonnistumismallin, jossa kieltäydytään myöntämästä projektin olevan pahasti, pahasti myöhässä aina viime hetkeen asti.
Kun tätä ei enää voida salata ylemmältä johdolta, siitä heille aiheutuva epämiellyttävä yllätys vain horjuttaa, joskus pysyvästi, heidän luottamustaan omiin kehitystiimeihinsä. Ja kukapa voisi syyttää heitä?
Mutta jos otat TTQ:n johdonmukaisesti osaksi mittareitasi ja projektinhallintaasi—ja toimit sen perusteella, mitä mittari sinulle kertoo—voit välttää tämän.
Laadun saavuttamiseen kuluvan ajan mittaaminen poistaa henkilökohtaisuuden päätöksestä tunnistaa aikataulu- ja laaturiskien kasvavan projektin varhaisimmissa vaiheissa.
Asiasta tulee hyvin yksiselitteinen, numeroihin perustuva. Kyse ei ole henkilökohtaisesta sankaruudesta, joka koituu usein henkilölle kalliiksi.
More Articles
TTQ-mittari on myös erittäin hyödyllinen projektin retrospektiivissä/jälkianalyysissä.
Sen avulla tiimi pystyy paikantamaan tarkasti, mitkä koodin osat olivat ja pysyivät heikkoina koko projektin ajan. Samalla voidaan arvioida, kuinka tehokkaasti tiimi tuotti laatua. Tai kuinka kallista se oli.
Tätä kysymystä vältellään suurelta osin projektien retrospektiiveissä. Osittain siksi, ettei tiimeillä ole käsitteellistä sanastoa sen muotoilemiseen, ja osittain siksi, että suunnittelun jatkuvasti heikosta koodin laadusta huomauttaminen on usein poliittisesti arkaluonteista.
Yhteenveto
TTQ tuo projekteihisi valtavasti läpinäkyvyyttä ja ennustettavuutta lähes ilman aika- tai työpanoskustannuksia, koska kyse on yksinkertaisesti jo keräämiesi mittareiden meta-analyysistä.
Olen käyttänyt TTQ:ta QA-projekteissani kaksi vuosikymmentä, ja se on saanut laajan hyväksynnän sitä kouluttamieni projektipäälliköiden keskuudessa kaikista edellä mainituista syistä.
Kokeile sitä, niin näet itse. Se muuttaa todella tiimisi toimintaa merkittävästi. Kuten aina, onnea matkaan.
P.S. Jos haluat kuulla lisää tositarinoita ja TTQ:n taustalla olevista syistä, keskustelin Jonathon Wrightin kanssa QAL Podcastissa.
