Ketterä kehitys on ollut yksi kuluneen vuoden hype-termejä. Jopa julkishallinnossa ollaan oltu innostuneita ketterästä kehittämisestä. IT-integraattorit ovat myös sankoin joukoin liittyneet tähän ylistyshuutoon. Moni ketteryyteen ”hurahtanut” suhtautuu tähän ohjelmistokehityksen malliin myös korostuneen innostuneesti, jopa uskonnollisesti. Ja miksipä ei – onhan ketteryys yksi isoimpia paradigmamuutoksia mitä IT-alalla on vähään aikaan koettu.
North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
2.12.2013
Mutta muuttaako se aivan kaiken tekemisen tavan? Ja pitääkö asiakkaidenkin muuttaa toimintatapansa? Vastaan tässä intranet-projektien näkökulmasta tähän kysymykseen.
Väitän nimittäin, että esimerkiksi intranet-projekteihin ketterä kehitys ei tällä hetkellä liity mitenkään luontevasti. Ketterät menetelmät ovat ensisijaisesti räätälöityjen sovelluksien kehitysmenetelmiä ja niiden soveltaminen intranet-projekteissa voi olla jopa ongelmallista.
Isoimpana syynä tähän pidän sitä, että hyvä intranet-projekti on paljon muutakin kuin ohjelmistokehitystä. Väitän jopa, että onnistuneimmat intranet-projektit ovat vain pieneltä osin ohjelmistokehitysprojekteja – onnistuneimmat projektit ovat ennenkaikkea toimintatapamuutosprojekteja joissa ihmisten koulutus ja sisältöjen organisointi saavat isoimman huomion. Eikä näihin osa-alueisiin tarvita ketterän kehityksen tuomaa intensiivistä ohjelmistokehityksen mallia automaattisine testauskäytänteineen ja jatkuvine tuotantoonsiirtoineen.
Toisena merkittävänä syynä ketteryyden ja intranet-projektien huonoon yhteensopivuuteen pidän intranet-projektien tuotevetoisuutta. Riippumatta siitä otetaanko käyttöön SharePointtia vai vaikkapa Confluencea, niin hyvä intranet-projekti tapahtuu tuotetta kunnioittaen ja sen ominaisuuksia maksimaalisesti hyödyntäen. Tässä taas on kyse paljon enemmän vaikkapa ”ketterästä konsultoinnista” ja ”jatkuvasta pilotoinnista” kuin ketterästä kehittämisestä.
Kolmantena ketteryyden soveltamista rajoittavana asiana pidän intranet-palveluiden yleensä kovin maltillisia vuosittaisia kehitysbudjetteja. Vain maailman suurimmilla organisaatioilla on olemassa ”intranet-tiimejä”, jotka kehittävät palvelua jatkuvasti eteenpäin. Suurin osa intraneteista porskuttaa käyttöönoton jälkeen varsin pienillä kehitysbudjeteilla. Sisältöjä kyllä kehitetään ja uusia ominaisuuksia otetaan käyttöön jos päivitykset niitä tuovat, mutta aivan uutta ohjelmistokehitystä tehdään hyvin vähän vuosittain ”normaalille intranetille”.
Tosin tarkoitukseni ei tässä ole väittää, että ketterät menetelmät olisivat jotenkin epäyhteensopivia intranet-projektien kanssa. Uskon, että moni hyvä intranet voi syntyä aidon ketterän kehityksen kautta – ja olen pari tällaista isoa ja laadukasta projektia todistanutkin. En vain usko, että ketteryys auttaa ratkaisemaan niitä isoimpia ongelmia joita intranet-projekteissa on – enkä usko, että investoimalla ketteriin menetelmiin voidaan saavuttaa merkittävästi parempaa teknistä laatua intranetteihin – tai ainakaan sellaista laatua jolla olisi huomattavaa merkitystä käyttäjien näkökulmasta.
Nyrkkisääntönä sanoisinkin, että ketteriä menetelmiä kannattaa intranet-hankkeissa harkita jos toteutusprojektin ennakkoarviot tuntuvat menevän reilusti yli 200 henkilötyöpäivän. Tällöin alkaa todennäköisesti olla kyse jo varsin isosta ohjelmistokehitysprojektista jonka hallittavuutta voivat ketterät menetelmät parantaa. Tosin tuolloinkin ensisijaisesti suosittelisin projektin pilkkomista pienempiin osiin, ja näin mahdollistaen paremman keskittymisen sisältöprojektiin ja toimintatapamuutoksiin.
PS. Sinua voisi kiinnostaa tulossa oleva ilmainen webinaarimme: Parhaat muotoiluratkaisut tuote- ja palvelusivuille (15.5.2024 klo 10:00). Ilmoittaudu webinaariin
