← Back to front page

Agilehipit eivät vain saa sitä – vai saavatko sittenkin?

Blogahdus on julkaistu aiemmin Ambientian intranetissä 11.3.2013 keskustelun- ja ajatusten herättäjäksi. Vaikka tässä nyt ei mitään uutta ja mullistavaa esitetäkään, keskustelua se sai aikaiseksi. Kiitos siitä! (Etukäteen muuten pieni anteeksipyyntö vähän kököistä manifestin suomennoksista. Löytyykö näihin “virallista” käännöstä?)

Lisäys 2.4.2013:  Ja sieltähän ne suomennokset löytyivät. Kiitos Aki.


Erinäisten twiittien, blogien ja blogikommenttien kautta päädyin tälläiseen blogahdukseen. Siinä Cédric Beust (mm. Java TestNG-testiframeworkin kehittäjä) väittää, että me (te, ne) agilehipit eivät saa sitä vaan ovat ottavana osapuolella, epäonnistuvia idealisteja, jotka eivät ymmärrä käytännöstä mitään. No, kaikkihan tietävät, että tämä on diibadaabaa ja täyttä potaskaa. Vanha PL1-koodarikin ymmärtää, että ketteryys määrää ja TDD on pop ja tuottaa puhdasta koodia. Mutta tämä fakta ei ole tämän blogahduksen pointti.

Kirjoitus minut miettimään mikä on olennaista ja mikä ei, mikä tekee ketterän hipin, kehittäjän, tiimin tai yrityksen? Vai onko ketteryys ajattelutapana kuollut tai niin viime vuosikymmentä, kuten eräässä käytäväkeskustelussa kollega huomautti, joko tosissaan tai sitten ei. Tekeekö TDD ketteräksi, pelastaako Scrum kiireisen projektin tai järjestääkö Kanban ylityölistetyn ylläpitotiimin työjonon? Olenko ketterä, kun minulla on CSM-plakaatti seinällä roikkumassa. Oletko sinä ketterä, kun tiedät mikä on “story point” ja osaat “gruumata” perälokia?

Vuosituhannen alussa törmäsin ensimmäisen kerran tähän sivuun (mikä kertoo siitä että ei tämä ketteryys ja muu hippeily nyt niin kovin tuoretta enää ole). XP-käytännöt olivat cooleja jo silloin. TDD, “test first”, refactoring jne. Niistä oli kiva puhua ymmärtämättä mitään tai mitä hyötyä niistä on. No, Javaa tuli opeteltua pariohjelmoimalla. Pari viikkoa meni mukavasti, kunnes pohjalaisen kollegani kanssa menivät sukset niin pahasti “disainista” ristiin, että oli pakko repiä napanuora irti ja jatkaa sinkkuna. Mutta kieltämättä hyötyä tuon “ketterän” työtavan jalkauttamisesta oli: softa saatiin valmiiksi, yhteistyöllä.

Vaihdoin työpaikkaa, ja “ketteryys” ja muu hapatus unohtuivat vähäksi aikaa, koska näistä ei ko. organisaatiossa puhuttu tai ainakaan se ei meikäläiselle näkynyt. Hommia tehtiin ja ne saatiin valmiiksi. Jälkeenpäin ajateltuna, homma oli ajoittain hyvinkin ketterää lukuunottamatta sitä, että suoria asiakaskontakteja ei minulla ollut. Meillä oli speksi joko paperilla tai sitten projektipäällikön päässä, ja sen mukaan koodattiin. Välillä joku kävi kysymässä, että onko valmista. Jos oli, toimitettiin. Itse tuli jo tuolloin koodattua niin, että homma oli koko ajan “paketissa” ts. aina oli jotain näytettävää, jos statusta kysyttiin. Toisaalta, tulipa törmättyä ihan aitoihin vesiputoustyyppisiin projekteihinkin: speksiä oli kilotolkulla ja sieltä sitten ensimmäiseltä sivulta lähtien alettiin koodaamaan.

Puhelin pärähti ja siirryin seuraavaan organisaatioon. Nyt “ketteryyttä” kaadettiinkin niskaan oikein kansiokaupalla, RUPin muodossa. Oli eri vaiheita, oli manuaalia josta “voidaan implementoida vain tarpeelliset osat”. Syntyi testejä (lieviä ongelmia oli kyllä talon sisällä tehtyjen stub-objektien kanssa: ne generoivat invalidia dataa, mikä asia selvisi minulle 2 päivää liian myöhään). Syntyi “vain tarpeellinen” dokumentaatio. Huolimatta hyvin koulutetusta ja dokumentoidusta prosessista tilanne oli kuitenkin ajoittain kaoottinen, eikä aina ollut täyttä ymmärrystä siitä mitä tehtiin. Lopulta päädyttiin siihen, että heitettiin RUPpi roskiin ja mietittiin tosissaan mitä tarvitaan ja mitä ei. Viimeisestä projektista muistan päällimmäisenä sen, kun projektipäällikkö antoi tiimille speksin ja tuli parin kuukauden päästä noutamaan hyvin toimivan, virheettömän softan. Ilman iteraatioita, ilman daily scrumeja, ilman mitään “ketterää”. Tässä välissä oli myös muutama välivaihe ja pari muuta projektia, mutta mielestäni kaikki kulminoitui tuohon viimeiseen.

Noihin vuosiin mahtui enimmäkseen onnistuneita projekteja. Ja jos projektissa kaikki ei toiminut heti alkuunsa, homma saatiin silti jossain vaiheessa pelaamaan. On ehkä syytä miettiä, mikä noissa onnistuneissa projekteissa on yhteistä. Ketterä mies kaivaa naftaliinista tietenkin vanhan kunnon “Ketterän manifestin”, jota vasten asiaa peilaa.

Individuals and interactions over processes and tool (Ihmiset ja vuorovaikutus ennen prosesseja ja työkaluja)

Kylmä fakta on se, että kaikissa onnistuneissa projekteissa oli mukana vähintään yksi kovan luokan kehittäjä, joka omalla esimerkillään ja teknisellä osaamisellaan veti myös kokemattomampia eteenpäin. Mikään prosessi tai työkalu ei voi korjata ihmisten henkilökohtaista osaamista ja kuten tuo viimeinen esimerkkikin kertoo: jos porukka on tarpeeksi hyvä henkilökohtaisella tasolla, hyvän sovelluksen tekeminen onnistuu käytännössä ilman mitään (muodollista, kuvattua) prosessia suhteellisen kivuttomasti.

Osaamiseen lasketaan toki myös hyvät kommunikaatiotaidot: ilman näitä tiimin työ on mahdotonta. Esim. päivittäiset Scrum-kokoukset saattavat muuttaa tiimin yhteistyötä aivan olennaisesti. Monesti isoissa perinteisellä tavalla toteutetuissa projekteissa on se ongelma, että ihmiset eivät tiedä mitä kaverit tekevät ja em. syystä tekevät esim. päällekkäisiä asioita. Pistä porukka aamulla piiriin kertomaan tekemisistään, niin tilanne helpottuu. Tässäkin on hyvä esimerkki siitä kuinka yksinkertaisesta asiasta ketteryydessä on kysymys ja myös siitä, että kaikkia käytäntöjä ei tarvitse tuoda yhdellä kertaa tiimille. Edetään pienin askelin ja opitaan samalla siitä, mitä ollaan tehty.

Working software over comprehensive documentation (Toimiva sovellus ennen kattavaa dokumentaatiota)

Tässä vaiheessa on syytä korostaa tuota manifestissa esiintyvää englanninkielistä “over”-sanaa. Ketterät menetelmät EIVÄT siis suosittele poistamaan kaikkea dokumentaatiota ja pelkästään koodamaan Post-it-lappujen perusteella, kyse on priorisoinnista. Toisaalta, ei ole mitään sääntöä sille, kuinka paljon dokumentaatiota tuotetaan. Kaikki tehdään tarpeen mukaan, ja jokaisella tuotoksella pitää olla käyttöä ja selkeä kohderyhmä. Mitään ei tehdä vain siksi, että “prosessi niin sanoo”. Jokaista lausetta kirjoitettaessa pitää miettiä a) kuka tätä lukee ja b) miksi. Eräs arvostamani arkkitehti totesi kerran, että jos dokumentaatio muuttuu päivittäin, se on liian tarkalla tasolla. Nyrkkisääntö tuokin, eikä välttämättä ihan huono.

Toisaalta, hyvin menneissä projekteissa on julkaistu paljon ja aikaisin. Ja on keskitytty siihen, että se olennaisin tuotos toimii eli sovellus. Esim. tuossa viimeisessä mainitusta projektista ei julkaisuhetken jälkeen löytynyt kuin yksi bugi puoleen vuoteen, vaikka ko. härveli oli kovassa käytössä. Koodi on ollut keskiössä ja se, että se on ylläpidettävää. On ollut joku joka siitä välittää. Paljon puhutaan siitä, että “koodi on kaikkien omaisuutta”. Toki näin on, mutta monesti on vielä joku, joka välittää muita enemmän. Muuten koodin laadulle saattaa käydä kuin yhteiskäytössä olevan auton siisteydelle.

Jotenkin tämä teesi on mielestäni näistä kaikista naurettavin: eikö pitäisi olla itsestään selvää, että jos ostetaan sovellus, koodi ja valmis tuote on se tärkein asia?

Customer collaboration over contract negotation (Asiakasyhteistyö ennen sopimusneuvotteluja)

On totta, että sopimuksia tarvitaan luomaan turvallinen ympäristö toteuttaa projektia, turvallinen sekä asiakkaalle, mutta myös toimittajalle. Toisaalta ei myöskään ole kenenkään etu se, että pilkuntarkasti noudatetaan sovelluksen jokaista pykälää sillä hinnalla, että asiakas ei saakaan sitä, mitä oikeasti tarvitsee vaan sitä, mitä jollain ajanhetkellä menneisyydessä halusi. Tämä saa myös toimittajan näyttämään hölmöltä. “Eihän me tätä haluttu?”, on usein kuultu lausahdus ei niin ketterästi toteutetuissa projekteissa. Sitten pohditaan kenen syy oli: oliko vika epätäydellisessä “speksissä” vai toimittajassa, joka ei toimittanut sitä mitä tuossa “epätäydellisessä speksissä” määriteltiin. Ja tästä päästään siihen vanhaan totuuteen, että yleensä se mitä haluaa selkenee vasta siinä vaiheessa, kun nähdään valmiina jotain konkreettista. Ja täydellisen, kaikki yksityiskohdat huomioiva määrittelyn kirjoittaminen on kutakuinkin mahdotonta. Asiat muuttuvat, asiat nähdään eri valossa projektin eri vaiheissa, tärkeysjärjestys muuttuu jne.

Mieleenpainuvin kommentti menneisyydestä liittyy juuri tähän yhteistyöhön asiakkaan kanssa. Aiemmasta “dokumentoi koko maailma”-tyylistä siirryttiin ylläpitovaiheessa jatkuvaan, liki päivittäiseen asiakkaan kanssa kasvokkain kommunikointiin. Muutaman viikon kuluttua kuulimme kommentin: “munhan ei tarvitse tehdä enää mitään.” Asiakkaan ei enää tarvinnut yksin miettiä speksiä, vaan mietimme sitä yhdessä päivittäin, pienissä paloissa. Homman vaikeustaso laski inhimilliseksi.

Responding to change over following plan (Muutoksiin vastaaminen ennen suunnitelman noudattamista)

Tämä on ehkä vaikein asia käsiteltäväksi. Muutoksen hyväksyminenhän on rakennettu sisään syvälle ketteryyden ajatusmaailmaan. Jo vuosia sitten ketteryyden kritiikissä, toisaalta myös perusteluna käytettiin sitä, että sallitaan muutos, kunhan koodataan, ei suunnitella ja saadaan valmiiksi tai sitten ei saada. Joitakin päiviä sitten kuulin kommentin, että ketterä projektimalli tarjoaisi “avoimen valtakirjan” toimittajalle: kunhan tehdään mitä tehdää ja vaikkei valmista tulisikaan, lasku lähtee silti.

Väitän, että ketterä projektimalli tarjoaa ENEMMÄN kontrollia projektin kulkuun asiakkaan näkökulmasta kuin perinteinen vesiputousmalli (no, eipä tuo ketterä mallikaan enää mikään uusi asia ole, kuten jo aiemmin tuli mainittua). Asiakas voi projektin edetessä priorisoida asioita, pyytää uusia ominaisuuksia, joita ei ole aiemmin määritelty tai jopa muuttaa koko projektin suuntaa tai laajuutta tarpeidensa mukaan. Mikään ei tietenkään tule ilmaiseksi: ketterässä mallissa ei tehdä mitään ylimääräistä, tehdään vain tarpeellinen. Tällöin saattaa jäädä osa alkuperäisen suunnitelman ominaisuuksista toteuttamatta, toisaalta yleensä saadaan enemmän tarkoitukseen sopiva sovellus ja saatetaan jopa säästää rahaa, kun ei tehdä mitään turhaa. “Inspect and Adapt”, vanha iskulause. Eikä vain paineta höyryjunan lailla eteenpäin, suoraa raidetta.

Vesiputousmallin tarjoama kontrolli projektiin ja toimittajaan on näennäistä, “toivotaan, toivotaan” kontrollia. Mitäs jos suunnitelmassa oli vikaa? Mitä jos toimittaja ei osaakaan? Mitä jos asia ymmärrettiin väärin? No, lopputulos selviää julkaisuvaiheessa. Itse ainakin jännittäisin vatsa kuralla, mitä tuleman pitää.


Aloin kirjoittamaan tätä viikkoja sitten. Olen vääntänyt ja kääntänyt tätä moneen kertaan ja miettinyt, että onko tämä niin triviaalia huttua että tätä ei kannata julkaista. Miksi julkaista itsestään selviä, yksinkertaisia asioita? Kun näitä teesejä miettii, tajuaa mistä nämä kumpuavat: käytännöstä, käytännön järjestä ja kokemuksesta. Näitä prinsiippejä ovat olleet latomassa ihmiset, joilla on vuosikymmenten kokemus menestyksekkäästä sovelluskehityksestä. Näitä ei ole kehitetty komiteoissa tai johtoryhmissä ja annettu resursseille impelemetoitaviksi. Nämä ovat päätelmiä, joihin jokainen meistä voi omassa työssään päätyä saatuaan riittävästi kokemusta erilaisista projekteista.

Kuitenkin edelleen näihin asioihin liittyy väärinkäsityksiä ja -ymmäryksiä, ketteryydestä tehdään monimutkaisempaa kuin se onkaan. Itselleni ketterä maailma näyttäytyy yksinkertaisena ja suhteellisen selkeänä. Tosin katson maailmaa ruohonjuuritasolta, koodarin näkökulmasta. Kaikki näkökulmat ovat tervetulleita, joten päätin kuitenkin julkaista tämän kirjoituksen, jotta asiaan saataisiin muitakin näkökulmia. Joten kommentit ovat enemmän kuin tervetulleita!

Please, leave us a message and we'll contact you.
You can also contact our Service Desk by phone +358 290 010 500 or email servicedesk@ambientia.fi.