Mietteitä ketterän ohjelmistokehityksen julistuksesta

20 vuotta julistuksesta

Minulla kävi hyvä tuuri, kun tulin ammatillisessa mielessä täysi-ikäiseksi juuri ketterän ohjelmistokehityksen alkutaipaleella. Ketterät menetelmät alkoivat kiinnostaa ihmisiä 2000-luvun puolivälissä, kun ohjelmistokehityksessä janottiin uusia ajattelu- ja toimintatapoja. Ennen Nortalia olin töissä konsultointiyrityksessä, jossa työskenneltiin ketterään ohjelmistokehitykseen siirtymisen ja Extreme Programming ‑menetelmän parissa ja autettiin suuryrityksiä ja julkista sektoria tutustumaan tähän lupaavaan uuteen toimintatapaan. Se oli huumaavaa aikaa!

Viime vuosina olen kuitenkin nähnyt monen yrityksen palaavan vanhoihin käytäntöihin. Ketterät toimintatavat ovat jääneet taka-alalle, eikä ohjelmoijilla tunnu olevan minkäänlaista perusymmärrystä ketterän ohjelmistokehityksen ydinperiaatteista. Pahinta on, ettei tilalle ole edes tullut mitään parempaa. Itse asiassa organisaatiot kamppailevat juuri niiden samojen ongelmien kanssa, joita ketterillä menetelmillä pyrittiin ratkaisemaan, ja vastauksia etsitään vääristä paikoista. Vastaukset ovat kuitenkin koko tämän ajan olleet tarjolla Ketterän ohjelmistokehityksen julistuksessa (Agile Manifesto). Tämä vuonna 2001 laadittu uraauurtava asiakirja kuuluu seuraavasti:

Julistuksen synty ja vaikutus alaan selitetään hyvin The Atlanticin erinomaisessa artikkelissa, joka kannattaa lukea jo historiikin ja anekdoottienkin vuoksi. Tässä blogikirjoituksessa haluan kuitenkin jakaa omia mietteitäni julistuksesta ja sen käytännön vaikutuksista.

Yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja

Ensinnäkin on todettava, että menetelmä on työkalu ja että työhön on aina mahdollista valita väärä työkalu. Vääräkin työkalu saattaa toimia jonkin aikaa, mutta ennen pitkää se käy kalliiksi. Julistuksen kirjoittajat tuntuivat vastustavan sitä ajatusta, että jotain tiettyä menetelmää tuotaisiin esiin ainoana oikeana tapana tehdä ketterää ohjelmistokehitystä. Sen sijaan aidosti ketterää on keskittyminen ihmisiin ja siihen, miten he toimivat yhdessä.

”Yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja” voidaan kiteyttää yhteen sanaan: itseohjautuvuus. Itseohjautuva tiimi, jolla on terve ja ketterä kulttuuri, valitsee omia tarpeitaan palvelevat menetelmät ja työkalut sen sijaan, että taipuisi työkalujensa ja menetelmiensä vaatimuksiin. Tämä tarkoittaa sitä, että tiimin jäsenet otetaan huomioon yksilöinä sen sijaan, että heidät nähtäisiin pelinappuloina tai pakotettaisiin mukautumaan tietyn työkalun rajoituksiin. Itseohjautuvuus edellyttää luottamusta, mutta palkitsee sen joustavuudella ja viime kädessä tuottavuudella. Lisäksi, hyvä lukija: älä hyvällä tahdollakaan kutsu ketään ”resurssiksi”.

Toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota

Haluaisin esittää pari väitettä:

• Dokumentaatio on turhaa, jos sitä ei lueta.
• Vanhentunut dokumentaatio voi olla jopa haitallista.

Siksi kannatankin sitä ajatusta, että dokumentaatiota tarvitaan ainoastaan sen verran, että työt saadaan tehtyä. Ihmisten on ihan turha käyttää työaikaansa tekstimassojen läpi kahlaamiseen, kun vähempikin riittäisi saman lopputuloksen tuottamiseen. Dokumentaatiota on myös uskomattoman kallista tuottaa ja ylläpitää. Eipä tästä oikein muuta voi sanoa.

Mitä tulee ”toimivaan ohjelmistoon”, itse määrittelisin sen ohjelmistoksi, jossa ei ole vikoja ja joka täyttää tarkoituksensa. Tämä taas edellyttää, että ohjelmoijat ymmärtävät ohjelmiston tarkoituksen. Siksi tarvitaan vahvaa tuotteen omistajuutta ja viestintää, ja näiden merkitystä ketterässä ohjelmistokehityksessä ei voi korostaa liikaa. Entä miten vikoja voi ehkäistä? Itse väitän, että kattava testaus ja automaatio ovat laadun parhaat takeet. Etenkin testivetoinen kehitys (TDD, Test-Driven Development) voi olla tehokas tapa kehittää ohjelmistoa niin, että komponenttien välissä on selkeät sopimukset ja testikattavuus on suuri.

Asiakasyhteistyötä enemmän kuin sopimusneuvotteluja

Olin kerran mukana pelastamassa erästä konsultointiprojektia, jossa projektitiimin osaamisprofiili ei vastannut kovinkaan hyvin asiakkaan teknisiä tarpeita. Tiimi yritti urheasti toteuttaa asiakkaan toiveita, mutta ei lopulta pystynyt siihen. Johto reagoi asiaan liian myöhään, ja epäonnistunut projekti oli vähällä johtaa oikeusjuttuun. Sitouduimme tekemään työn uudelleen omalla kustannuksellamme ja pystyimme pikkuhiljaa voittamaan taas asiakkaan luottamuksen. Yllätyksekseni kuulin, että projektin valmistumisen jälkeen asiakas tilasi meiltä kaksi lisäprojektia ja ryhtyi yrityksemme suureksi puolestapuhujaksi. Olisimme voineet saivarrella sopimuksen yksityiskohdista, täyttää sopimusvelvoitteemme rimaa hipoen ja pyrkiä eroon vaikeasta sopimuksesta, mutta asiakassuhteen vaaliminen ja asiakkaan tarpeiden täyttäminen hyödyttivät lopulta kumpaakin osapuolta.

Haluan huomauttaa, että tämä kohta ei koske ainoastaan konsultointisuhteita, vaan kaikilla ohjelmistokehitystiimeillä on asiakkaita. Jos ylempi taho sanelee kaiken eikä varsinaista työtä tekevällä tiimillä ole mitään sananvaltaa projektin laajuuden, aikataulun ja muiden asioiden suhteen, kyse ei ole yhteistyöstä. Tällaiset projektit on tuomittu epäonnistumaan. Ohjelmoijilla on ammatillinen intressi saattaa projektinsa kunnialla maaliin, ja heihin tulisi luottaa yhteistyökumppaneina. Ohjelmoijilla on myös oltava suora yhteys tuotteensa asiantuntijoihin, tai muuten he tuottavat väistämättä vääränlaisia ohjelmistoja. Tällöin ohjelmisto ei useinkaan vastaa asiakkaan tarpeita, siinä priorisoidaan vääriä ominaisuuksia tai se aiheuttaa jollain muulla tavalla kitkaa asiakasyhteistyöhön.

Vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa

Tämän kirjoituksen inspiraationa toimivat omat havaintoni siitä, että yritysten ymmärrys ketterästä ohjelmistokehityksestä ja sen tarkoituksesta, käytännöistä ja ohjenuorista on taantumassa. Etenkin Scaled Agile Frameworkin (SAFe) kaltaiset ”uudet” ideat tuntuvat enemmän vesiputousmallin paluulta, sillä niissä ei oteta huomioon ohjelmistokehityksen muuttumattomia realiteetteja. On täysin ymmärrettävää, että johto ei halua kuulla, että staattinen tiimi ei voi toteuttaa haluttua tuotetta määrätyssä aikataulussa. Tämä on kuitenkin realiteetti, joka on ollut tiedossa paljon ennen ketterää ohjelmistokehitystä. Ketterissä menetelmissä hyväksytään se ja priorisoidaan sitä, että tehdään tärkein asia seuraavaksi.

Aforismista ”mikään suunnitelma ei selviä kohtaamisesta vihollisen kanssa” on monia eri versioita. Ketterässä ohjelmistokehityksessä se tarkoittaa sen faktan tunnustamista, että mikään suunnitelma ei selviä tuntemattomista tekijöistä. Siksi mikä tahansa tuntemattomille tekijöille altistuva projekti (eli käytännössä lähes jokainen) on välttämätöntä suunnitella sen pohjalta, että asiat muuttuvat. Mikään yhtään suurempi projekti ei tule onnistumaan, jos siinä noudatetaan ehdoin tahdoin jäykkää suunnitelmaa. Tästä ei vain pääse yli eikä ympäri. Ole siis valmis muutoksiin.

Mitä siis seuraavaksi?

Nortalin tiimit pääsivät hiljattain kuuntelemaan Ketterän ohjelmistokehityksen julistuksen allekirjoittajiin kuuluvan Kent Beckin yksityistä verkkoluentoa. Esityksen jälkeen oli varattu aikaa kysymyksille, joten esitin seuraavan, kieltämättä hieman johdattelevan, kysymyksen:

Elämmekö ketterän ohjelmistokehityksen jälkeisessä maailmassa? Kävikö niin, että innostuimme kokeilemaan ketteriä menetelmiä ja saimme yritykset ottamaan niitä käyttöön, mutta sitten raskaat menetelmät pääsivät hiipimään takaisin ja piileskelevät nyt ketterien rituaalien takana? Olemmeko menettäneet maagisen ketteryyden? 

Beck tarjosi tämän ilahduttavan, odottamattoman vastauksen (Olen muokannut sitä hiukan luettavuuden parantamiseksi.):

Ei, ei! Elämme edelleen ketterää ohjelmistokehitystä edeltävässä maailmassa!

Useimmat ihmiset eivät ole edes vielä kokeneet, miten maagista se oikeasti on. Mielestäni perimmäinen syy tähän on, että valtasuhteissa ei ole tapahtunut muutosta. Ja jos valtasuhteet eivät muutu, kehityskään ei muutu. Tässä kaikille tuttu esimerkki aikatauluista: Minä sanon, että ”Hmm, voin tehdä tämän aikaisintaan neljässä kuukaudessa”, ja joku toinen sanoo: ”Tuo ei ole oikea vastaus, oikea vastaus on kahdessa kuukaudessa”, ja minä sanon: ”Ai, no hyvä on, kahdessa kuukaudessa sitten…” – siinä näkyy valtasuhteen vaikutus. Tämä asettaa meidät tilanteeseen, jossa tiedämme jo valmiiksi, että meillä ei tule olemaan toivoa, koska teknisen henkilön mielipide sivuutettiin täysin. Energia ja motivaatio tiimissä laskee, emme opi mitään, saatamme joutua paniikkiin ja tiimin sisäiset suhteet rasittuvat, koska kaikelle pitää aina löytyä syypää… Aargh!

Tässä toinen esimerkki hankalasta tilanteesta, jossa minulta kysytään deadlineista, välitavoitteista… Minä sanon: ”No, katsotaanpa, meillä on tuhat asiaa tehtävänä, mutta voimme tehdä viisi asiaa tässä kuussa”, ja joku sanoo: ”Tuo ei ole oikea vastaus.” Minä vastaan: ”Sinä kysyit, kuinka monta asiaa saamme tehtyä tässä kuussa, ja vastaus on viisi. Kerron kyllä, jos vastaus muuttuu, mutta suunnitelmat on paras tehdä viiden pohjalta.” Osa minusta haluaa jatkaa keskustelua sillä linjalla, että…”Jos sinä haluat 50 asiaa…se ei ole minun ongelmani.” Kun tätä tilannetta tarkastelee askeleen kauempaa, kyse on jälleen kerran valtasuhteesta. Harjoittelen itsekin edelleen taitoa, miten voin käydä tällaisia keskusteluja päätymättä jankkaamaan asioista samaan tapaan kuin isäni kanssa. Tämä oppiminen kuuluu kai henkilökohtaisen kasvun piiriin, mutta siinä sitä riittääkin työsarkaa koko elämän ajaksi. Lyhyenä yhteenvetona, meidän on työstettävä uudenlaisia valtasuhteita, ja sen avulla teemme ohjelmistokehityksestä uudenlaista. Silloin siitä tulee maagista, kun kaikki ovat samalla aaltopituudella ja auktoriteetit ja vastuut sovitetaan yhteen. Tämä on keskeinen periaate, joka joutuu KOKO AJAN sivuutetuksi. Eli, ketterä kehityksen tulevaisuus… Emme ole vielä KOSKAAN kokeneet, miten maagista se voi olla. Ihmiset eivät VIELÄKÄÄN ole aidosti kokeneet sitä. Ohjelmistokehitys voi olla niin paljon muutakin kuin mitä se on nykyään. Ja se on minusta todella turhauttavaa, että ihmiset eivät anna tälle tilaisuutta. He voisivat kuluttaa vähemmän aikaa ja energiaa, saada paremman kokemuksen, mutta he valitsevat toisin. Miten haluaisinkaan asioiden muuttuvan…

Allekirjoitan tämän täysin.

Ketterän ohjelmistokehityksen julistus ei lupaa, että tuote tulee valmiiksi ajallaan ja alittaa budjetin. Se kuitenkin lupaa, että rakennat oikean ratkaisun asiakkaallesi mahdollisimman tehokkaasti ja että tiimisi työskentelee tyytyväisempänä. On vaikeaa kuvitella, että millään muulla menetelmällä saisi aikaan parempia tuloksia. Ne, jotka uskovat sen olevan mahdollista, eivät varmastikaan ota huomioon laajuuden, kustannusten ja ajan keskinäistä riippuvuussuhdetta eli pahamaineista rautakolmiota. Siinä puolestaan on aihetta uuteen blogikirjoitukseen.