Myös ketterät projektit epäonnistuvat joskus! Mitä ihmettä? Eikö ketteryyden pitäisi olla vastaus ja ratkaisu kaikkiin sovelluskehityksen ongelmiin? Ehkä, mutta se vaatii myös asiakkaalta ketteryyden ymmärtämistä ja sitoutumista ketteryyteen. Andersin COO Jon Tarkiainen kirjoittaa onnistuneeseen projektiin tarvittavista elementeistä erityisesti tilaajan näkökulmasta.
Haastavinta sovelluskehitysprojektissa tilaajalle on se, että hänen pitää osata priorisoida sovelluksensa toiminnallisuudet. Kaikki ominaisuudet eivät voi olla yhtä tärkeitä ja jostakin ominaisuuden pitää olla valmis luopumaan.
Vaihtoehtoisesti tilaajan pitää olla valmis joustamaan muissa muuttujissa, eli budjetissa ja aikataulussa, mikäli sisällön laajuuteen ei haluta puuttua. Ketteryys ei tarkoita sitä, että lähdetään tekemään täysin ilman suunnitelmaa. Ketteryys antaa mahdollisuuden muokata suunnitelmaa silloin kun siihen on tarvetta ja tilaajan tulee olla valmis hyväksymään nämä muutokset.
Tilaajalla tulee olla kirkas visio siitä, mitä halutaan saavuttaa, jotta osataan tarvittaessa tehdä päätökset missä järjestyksessä toiminnallisuudet rakennetaan. Digitaalisen vision pitää olla kirkas koko organisaatiossa, jotta tilaajan päätökset priorisoinnista tukevat koko yrityksen strategiaa, eivät vain yhden liiketoiminta-alueen visiota.
KETTERÄSSÄ PROJEKTISSA PRIORISOINTI ON KAIKKI KAIKESSA
Backlogin avulla järjestetään toiminnallisuudet yksiselitteisesti tärkeysjärjestykseen, jossa kohta yksi on prioriteettilistan kärjessä. Listaa tehdään toiminnallisuus kerrallaan. Toiminnallisuudet voidaan myös lokeroida, josta voidaan tulkita priorisointijärjestys.
Yleisesti käytetään MoSCoW -lokerointia, jossa toiminnallisuudet jaetaan seuraaviin:
- Must have (pakko olla)
- Should have (pitäisi olla)
- Could have (voisi olla)
- Won’t have (ei tarvita)
Lopputulos saattaa siis muuttua (lue, lopputulos muuttuu) matkan varrella. Tilaajan pitää olla siis hereillä projektin aikana, jottei päädytä pyörimään iteraatio-luupissa kerta toisensa jälkeen niin, ettei osata sanoa koska projekti on valmis. Kommunikoinnin merkitys on tärkeä ja asiakkaan vastuulla on testata ja kommentoida toiminnallisuuksia koko kehitystyön ajan.
Ei ole mitään järkeä kehittää iteraatioissa ja kuitenkin jättää kaikki testaaminen vasta loppuun. Tilaajan on siis varattava resursseja koko sovelluskehitysprojektin ajaksi, jotta ketteryys voidaan säilyttää. Tärkeysjärjestys ja tavoite on pidettävä kirkkaana mielessä koko projektin ajan.
YHTEISTYÖLLÄ JA SITOUTUMISELLA ONNISTUTAAN
Ketterät menetelmät koettiin vielä 10-15 vuotta sitten turhan eksoottiseksi toimintamalliksi ja sovelluksia kehitettiin perinteisemmin vesiputousmallissa. Ongelmana oli se, että määrittelyn jälkeen kehitystyötä voitiin tehdä jopa puoli vuotta ilman testausta tai tilaajan kommentteja. Puolen vuoden jälkeen testauksessa huomattiin, että oli tehty täysin vääriä asioita ja paljon turhaa työtä.
Tällaiset projektit olivat kankeuden lisäksi todella kalliita tilaajille. Toisaalta tilaajalle itse kehitysvaihe oli hyvin vaivaton, kaikki tekeminen oli toimittajan puolella. Ketteryydessä asianlaita on toinen. Työtä tehdään tiiviisti yhdessä koko ajan ja toimittajan on sitouduttava tähän, jos projektissa halutaan onnistua.
Nykypäivänä valtaosa projekteista tehdään ketterästi, mutta ketteryyttä on syytä myös soveltaa, jos 100% ketteryys ei onnistu tilaajan puolelta. Sovelluksia tekevien, niin kehittäjien kuin tilaajien, on tärkeää ymmärtää ketteryyden merkitys, jotta ketterä kehitys on ylipäätään mahdollista. Oleellista on myös, että tilaajan odotukset ja projektin sisältö ovat linjassa, jotta lopputulokseen voidaan olla tyytyväisiä. Onnistunut projekti vaatii sitoutumista, priorisointikykyä ja kommunikaatiota kaikilta osapuolilta.
ONNISTUNUT ESIMERKKI KETTERÄSTÄ SOVELLUSKEHITYSPROJEKTISTA
Erinomainen esimerkki onnistuneesta sovelluskehitysprojektista oli Hankkijan kanssa toteuttamamme mobiiliapplikaatio, jossa tilaaja sitoutui erinomaisesti tuotteensa kehitykseen ja yhteistyö sujui mutkattomasti. Projektin aikana tehtiin useita muutoksia alkuperäiseen suunnitelmaan, sekä asiakkaan toiveesta, että myös kehittäjien ehdotusten perusteella. Tärkeintä oli kuitenkin se, että projektia tehtiin yhdessä, hyvässä yhteistyössä ja toisia kunnioittaen. Hankkija-projektistamme lisää blogissamme.
Otsikon kysymykseen Onnistunut ketterä projekti – yksin vai yhdessä? Vastaus: ehdottomasti yhdessä.
Kirjoittaja:
Jon Tarkiainen
Chief Operations Officer
”Jedi of Agile”
Tutustu aiheeseen lisää:
Ketterän kehityksen periaatteet
Ketterän kehityksen myytti – trendien vaikutus projektijohtamiseen
Ketterästi kehitetty mobiiliapplikaatio – Hankkija Oy