Johdanto

Tom Gilb on yksi maailman vanhimmista sovelluskehitysguruista. Hän on ollut mukana erittäin monen tunnetun yrityksen toimintamallien kehittämistyössä. IT-uransa hän aloitti IBM:llä vuonna 1958. Gilbiä voidaan pitää kaikkien ketterien menetelmien esi-isänä, sillä hän on puhunut samoista asioista jo 80-luvulla. Gilb on luonut oman EVO-mallinsa ja PLanguage-kielen ohjelmistokehityksen vaatimusten ja suunnitelmien esittämiseen. Hän on kuitenkin esittänyt paikoin voimakastakin kritiikkiä tämän hetken vallitsevia ketteriä kehitysmenetelmiä kohtaan. Tässä artikkelissa on koottuna Gilbin ajatuksia siitä, kuinka ohjelmistokehitystä pitäisi tehdä, ja missä kohtaa ketterät mallit voivat johtaa harhaan.

Mitä vikaa on Ketterissä menetelmissä?

Scrum, XP ja muut menetelmät eivät käytännössä ota lainkaan kantaa siihen, miksi projekti ylipäätään on olemassa. Jokaisella projektilla on muutama perusvaatimus, miksi sille löytyy rahoitusta. Näiden vaatimusten tarkka kirjaaminen ja mittaaminen on oleellista, jotta ylipäätään voidaan sanoa, eteneekö projekti vai ei. Monet menetelmät keskittyvät liikaa teknisiin yksityiskohtiin ja suunnitteluun ilman, että huomioivat todelliset asiakkaan tarpeet. On kuitenkin huomattava, että myöskään valtaosa "epäketteristä" menetelmistä ei huomioi näitä vaatimuksia.

Kaiken tekemisen tärkein päämäärä pitäisi olla asiakkaan tarpeiden tyydyttäminen ja tuloksiin keskittyminen. Oleellista projektissa ei ole tekniikka (testaus, koodaus jne.). Ketterät menetelmät ovat ohjelmistokehittäjien luomia ja se selittääkin, miksi niistä puuttuu usein tarvittava hallinnollinen ote.

Suuri osa ongelmista ei kuitenkaan ole ohjelmointiongelmia. Useimmiten kannattaa hyödyntää olemassa olevia toteutuksia, joskus jotain ongelmaa ei oikeasti ole edes olemassa, vaan tarve syntyi jostain väärinymmärryksestä. Korkean tason vaatimusten selkeä määrittäminen auttaa löytämään oikeanlaisen ratkaisun.

Parannusehdotuksia sovelluskehitysmenetelmiin

Tässä luvussa on esiteltynä muutamia Gilbin tärkeimpiä havaintoja, miten parantaa projektin onnistumistodennäköisyyksiä.

Todelliset vaatimukset

Oleellista on tunnistaa, ketkä kuuluvat projektin sidosryhmään ja analysoida heidän kriittiset vaatimuksensa. Valtaosa monisatasivuisista ns. vaatimusmäärittelyistä on turhaa proosaa ja sisältää enemmän suunnitelmia kuin todellisia vaatimuksia. Projektin koosta riippumatta, jokaisen projektin "top ten" -vaatimukset mahtuvat yhdelle sivulle. Nämä kriittiset vaatimukset, jotka viime kädessä määrittävät, oliko projekti onnistunut vai ei, on esitettävä yksiselitteisesti, testattavasti ja mitattavasti.

Näitä vaatimuksia ei voi esittää sanallisesti. Esimerkiksi lause "Uuden järjestelmän tulee tehostaa käyttäjän työskentelyä merkittävästi, olla salasanasuojattu, helppokäyttöinen ja helposti ylläpidettävä." on täysin kelvoton vaatimus. Kuinka paljon sen pitää tehostaa työskentelyä? 1%? 100%? Mitä tarkoittaa helppokäyttöinen? Entä ylläpidettävä? Miksi sen on oltava salasanalla suojattu, eikö joku muu varmistusmenetelmä käy? Vain mitattavissa olevat selkeät vaatimukset käyvät. Salasanasuojaus on tekninen keino turvallisuuden toteuttamiseksi, ei todellinen vaatimus.

Suurin osa IT-alalla toimijoista on niin tottunut epäselviin vaatimusmäärittelyihin, että ei osaa edes ajatella parempaa. On hämmästyttävää, miten paljon ihmiset ovat valmiita maksamaan epäselvistä vaatimuksista ja epämääräisistä projekteista. Yksinkertaisuus ja selkeys ovat avaimia kilpailukykyiseen sovelluskehitykseen.

Tyypillisesti vaatimusmäärittelyt täyttyvät suunnitteluideoista, koska määrittelijät ovat kyvyttömiä tunnistamaan todellisia vaatimuksia. Niiden arvaileminen on paha synti, kuten myös vaatimusten liiallinen kerääminen. Jos jollekin vaatimukselle ei ole osoittaa selkeää omistajaa ja tarvetta, kyseessä ei ole oikea vaatimus vaan satunnainen toive.

Evolutiivinen toimitus

Maailmalta löytyy suuri joukko esimerkkejä projekteista, joille on alunperin budjetoitu miljoonia euroja, mutta jotka ovat kuluttaneet moninkertaisen määrän eivätkä silti ole saaneet toimitettua mitään, mistä olisi yhdellekään projektin sidosryhmäläiselle mitään hyötyä. Miten on mahdollista, että alallamme tehdään useita vuosia kestäviä projekteja ilman että saavutetaan mitään näkyvää? Gilbin ratkaisu on evolutiivinen toimitus, missä jokainen toimitusten väli on enintään kaksi prosenttia projektin kokonaiskestosta - tai pienissä projekteissa viikko. Mikäli tässä ajassa ei kyetä toimittamaan jotain näyttöä siitä, että toimittaja on kykenevä selviytymään projektista, on aika vaihtaa toimittajaa.

Jokainen osatoimitus on valittava siten, että siitä on asiakkaalle maksimaalinen hyöty - siis vaatimusten on oltava priorisoituja. Se, valitaanko "eniten hyötyä millä tahansa kustannuksilla" vai "paras hyötysuhde riippumatta saavutetuista eduista" on asiakkaan tehtävä liiketoimintapäätös. Jonkun vaatimuksen (vaikkapa "Matkalaskun tekemiseen käytettävän ajan on vähennyttävä 50%") täyttämiseksi voi olla kaksi vaihtoehtoista ratkaisutapaa. Tällöin on tehtävä tietoinen valinta siitä, edetäänkö vaihtoehdon 1 mukaan, jonka tarjoama ajansäästö on 30-80% (emme tiedä vielä, kun toimintoa ei ole toteutettu) vai vaihtoehdon 2, jonka tarjoama ajansäästö on 45-55%.

Maksu seuraa hyötyä -sopimusmalli

Gilbin menetelmässä on ideana, että mikäli toimittaja ei toimita sovittua toiminnallisuutta, siitä ei makseta. Yleensä sopimuksissa ja vaatimusmäärittelyissä dokumentoidaan laveasti suunnitelmia, teknologioita, käyttötapauksia, työmääriä ja ehkä nimetään kriittiset menestystekijät. Samalla kuitenkin unohdetaan määritellä, ketkä kaikki kuuluvat projektin sidosryhmään, mitä ominaisuuksia käyttäjät arvostavat ja mikä on se (mitattavissa oleva) laatutaso, josta asiakas on halukas maksamaan.

Kyseessä on hallinnollinen ongelma. Johto epäonnistuu jatkuvasti työssään tekemällä virheellisiä arvioita asiakkaan arvoista, haukkaamalla liian suuria paloja kerralla ja hyväksymällä heikkolaatuisia "markkinointivaatimusmäärittelyitä" työmääräarvioiden pohjaksi.

Nykyisin projektit määritellään usein rajoitteiden eikä tulosten kautta. Kun projektia ollaan käynnistämässä, sille asetetaan tietty budjetti, mitä ei saa ylittää, kiinteä deadline milloin projektin on oltava valmis jne. Miksi heti alkuun on tarpeen rajoittaa projektia? Tämä aiheuttaa suurimman osan epäonnistumisista ja tappioista.

Jos projekteja ajateltaisiin tulosvetoisesti, projektin vaatimuksille ei oltaisi mietitty vain niiden kustannuksia, vaan myös niiden tuottama hyöty. Tällöin toimittajaosapuoli voisi sanoa "Anna minulle X dollaria joka viikko, niin saat takaisin n*X dollaria". Mitä järkeä tilaajan olisi tässä tilanteessa rajoittaa projektin kestoa niin kauan, kun lisäarvoa syntyy (n>1)? Tässä lisäarvolla käsitetään joko suoraa nettotulosta tai säästyneitä kuluja. Tässä vaiheessa budjetit ja muut rajoitukset menettävät merkityksensä.

Maksuerien sitominen asiakkaan saamaan hyötyyn mahdollistaa projektin tarkemman ohjaamisen. Viikon alussa sovitaan, mitkä ovat tavoitteet seuraavalle viikolle, ja viikon lopussa todetaan, saavutettiinko tavoitellut hyödyt. Mikäli kyllä, viikon työ voidaan laskuttaa. Tässä on huomattava, että hyöty ei välttämättä ole uusia toimintoja tai edes parempaa laatua. Viikottainen maksuerien laskuttaminen olisi luultavasti tarpeettoman byrokraattista ja raskasta, mutta ideaa on mahdollista soveltaa laveamminkin.

Mittaamisesta

"I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of Science, whatever the matter may be."

  - Lord Kelvin

Gilbin mukaan tämä pätee myös sovelluskehityksessä. Tärkeää on vain muistaa, että ohjelmisto ei juuri koskaan ole olemassa itsensä vuoksi, joten ohjelmistoa itseään ei ole järkevää mitata. Asiakasta ei kiinnostaa lainkaan, montako koodiriviä tai luokkaa ohjelmassa on, eikä oikeastaan edes montako bugia siinä on. Asiakasta kiinnostaa vain se, vastaako sovellus hänen laadullisia tarpeitaan esimerkiksi suorituskyvyn ja toimintavarmuuden osalta. Jotta projektien onnistumista voidaan seurata (ja jotta projektit onnistuisivat) on tärkeää, että jokainen vaatimus on mitattavissa. On oleellista, että seuraavia termejä ei sotketa keskenään:

• Mitallistaminen, kvantifiointi (quantification) - jonkun asian saattaminen mitattavaksi
• Arviointi (estimating) – mittauksen tuloksen arvaaminen
• Mittaaminen (measurement) - suureen mittaaminen

Se, että joku asia on äärimmäisen vaikea mitata, ei ole hyvä syy jättää sitä kvantifioimatta.

Laadullisten vaatimusten mukaan tuominen keskusteluihin on äärimmäisen tärkeää. Usein asiakkaalta saadaan vain lista tarvittavia toimintoja, ja todelliset tarpeet jäävät huomioimatta. Samoin laadulliset attribuutit, kuinka hyvä järjestelmän on oltava. Laadun lähentyessä huippua kustannukset lähestyvät ääretöntä. Asiakkaan on tiedostettava, mikä on se laatutaso, mikä tyydyttää hänen tarpeensa. On tarpeen mitata myös laadulliset vaatimukset, ei vain toiminnalliset.

Mitattavien asioiden keksiminen voi tuntua vaikealta. Yksi hyvä keino niiden löytämiseksi on seurata käyttäjää työssään vaikkapa koko päivä. Jos esim. sihteeri päästää kirosanan suustaan, voit mitata montako kirosanaa sieltä lentää päivässä :-)

Yleensä ihmiset eivät ole samaa mieltä siitä, miten jotain asiaa pitäisi mitata. On oleellista neuvotella yhteinen mitta-asteikko ja kirjata se ylös. Kuten kaikessa muussakin toiminnassa, parhaat tulokset saavutetaan yleensä siten, että työn tuloksia näytetään muille ja parannetaan sitä yhdessä.

Yleensä raha on ainut asia mitä mitataan. Usein sitä jopa yritetään säästää tavoilla, joita ei kunnolla mitata.

Oppimisesta

"Learning: modification of a behavioral tendency by experience"

Oppimista ei ole tapahtunut, elleivät toimintamallit muutu. Oppiminen on sovelluskehityksen peruspilareita. Projektin tuotoksia on tärkeää toimittaa pienissä paloissa, jotta jokaisen toimituksen jälkeen voidaan oppia lisää asiakkaasta, toimialasta, tiimin toiminnasta jne. Tavoitteena on saada vastaus kysymykseen "Kuinka kauan toiminnon toteuttaminen kestää, jos:

• käytämme arkkitehtuuria x
• käytämme nykyistä henkilöstöä
• käytämme valittua prosessia

... ja mitä kannattaa muuttaa, mitä taasen ei, jotta projekti valmistuisi nopeammin?"

Oppimisen lähteenä on oltava todellisten käyttäjien kokemukset, ja heiltä saatu nopea palaute.

Tuotantoonasennus ja sen jälkeinen aika ovat tärkeimpiä oppimisen kannalta. Siinä nähdään, kuinka sovellus toteuttaa vaatimuksensa ja millaisia ongelmia prosessiin sisältyy. Tämän vuoksi onkin hyödyllistä, että asennuksia tehdään useampia. Näin oppimistilanteitakin kertyy enemmän.

Yhteenveto

Valtaosasta ketteriä menetelmiä puuttuu pitkän tähtäimen suunnitelmallisuus. Ne ovat tehokkaita toteutusmenetelmiä, mutta järeän järjestelmän toteutukseen yksinään riittämättömiä.

Keskeinen ajatus EVO-menetelmässä on vaatimusten numeerinen määrittäminen ja projektin vieminen hallitusti kohti tavoitetilaa. Tärkeimpänä havaintona Gilbillä on se, että vähänkin suuremman tai monimutkaisemman projektin suunnittelu ja toteutus yhdellä rysäyksellä on mahdotonta. Sen sijaan menetelmässä käytetään lyhyitä iteraatioita (evo steps), joiden pituus on 2-5% koko projektin kestosta. Vuoden mittaisella projektilla tämä tarkoittaa viikon syklejä.

Jokaisen askeleen tavoitteena on tuottaa jotain lisäarvoa jollekin projektin omistajista. Tässä on oleellista muistaa, että lisäarvon saaja voi olla myös joku toimittajaorganisaation sisäinen taho, jonka työn esimerkiksi sovelluskehitysryhmän tekemä väline mahdollistaa.

Gilbin esittämä CE (Competitive Engineering) on hyvin järeä menetelmä, joka sopii kaikenkokoisiin ja –tyyppisiin (softaa tai rautaa) projekteihin.

www.gilb.com