Ketterät menetelmät - projektien pelastus?

Olen viime aikoina opiskellut lisää aihetta ketterät menetelmät. Ketterät menetelmät ovat käytössä jo monella toimialalla. Käyttö tulee laajenemaan varmasti.

Hyvä olisikin jokaisen projektiammattilaisen ymmärtää menetelmien viitekehystä. Parhaan hyödyn ketteryydestä varmasti saa, kun käyttää parhaiten oman organisaation kulttuuriin ja toimintatapoihin soveltuvia menetelmiä. Ketterää projektinhallintaa ei mielestäni voi toteuttaa irrallisena, vaan organisaation muiden funktioiden tulee tukea tätä ajattelutapaa ja prosessia. Siirtyminen perinteisestä vesiputousmallista ketteryyteen vaatii aikaa, johdon tukea, ketteryyttä tukevia prosesseja ja sitoutumista.

Agile Manifestoa/ Ketterä manifesti, pidetään ketterän kehityksen perusmääritelmänä. Manifestissa määritellään ketterille menetelmille neljä tyypillistä arvoa sekä 12 periaatetta, joita menetelmät noudattavat.

”Me etsimme parempia keinoja ohjelmistojen kehittämiseen tekemällä sitä itse ja auttamalla siinä muita. Tässä työssämme olemme päätyneet arvostamaan:

  • Yksilöitä ja vuorovaikutusta enemmän kuin prosesseja ja työkaluja
  • Toimivaa sovellusta enemmän kuin kokonaisvaltaista dokumentaatiota
  • Asiakasyhteistyötä enemmän kuin sopimusneuvotteluita
  • Muutokseen reagoimista enemmän kuin suunnitelman noudattamista

Vaikka oikeallakin puolella on arvoa, me arvostamme vasemmalla olevia asioita enemmän”.

Edellisessä artikkelissani toin esille miksi työmääräarviot ja projektikustannukset yleensä ylittyvät. Esimerkki oli arkielämästä. Otetaan tämä sama esimerkki ja pohditaan tilannetta ketterästä näkökulmasta.

Ketteränä menetelmänä käytän Scrumin viitekehystä, joka perustuu empirismiin eli kokemusperäiseen tietoon. Scrum hyödyntää iteratiivis-inkrementaalista ( toistuvaa ja lisäävää) lähestymistapaa ennustettavuuden optimoimiseen ja riskien kontrolloimiseen.

Scrumin peruspilareita ovat:

  • läpinäkyvyys
  • tarkastelu 
  • sopeuttaminen

Läpinäkyvyys vaatii, että merkittävät tekijät, esimerkiksi testauksen hyväksyntäkriteerit määritellään ja sovitaan yhdessä. Kaikilla on yhteinen näkemys siitä mitä tarkoittaa ”valmis tuotantoon”. Läpinäkyvyys tarkoittaa myös luottamusta ja uskallusta nostaa esille niin hyvät kuin huonot uutiset, juuri niin kuin ne ovat.

Tarkastelussa käydään säännöllisesti läpi tuotokset, työn edistyminen ja haitalliset poikkeamat. Esimerkkinä voidaan käyttää kehitystiimiä, joka esittelee tuotteen ja sen toiminnallisuudet asiakkaalle jokaisen kehityssyklin eli sprintin jälkeen. Näin asiakkaalta saadaan tärkeää palautetta. Tarkastelu antaa pohjan sopeuttamiselle.

Sopeuttamisella tarkoitetaan sitä, että työn edistyessä minimoidaan mahdollisimman paljon poikkeamia säätämällä prosessia ja työstettävää aineista. Jos tarkastelussa nousee esille muutostarpeita, nämä käydään läpi ja priorisoidaan.

Lisää Scrumin viitekehyksestä voit lukea lataamalla oppaan osoitteesta https://www.scrumguides.org/.

Palataan arkielämän esimerkkiin. Prosessi voisi olla Scrumia hyödyntäen jokseenkin seuraavanlainen.

Vaihe 1. Myynti

Myynti on saanut vinkin potentiaalisesta asiakkaasta. Myynti pääsee tapaamaan asiakasta. Myyjällä on asiakkaasta jotain alkutietoja ja oletuksia. Tiedot tarkentuvat  ja asiakas kertoo tarpeensa ja toiveensa palvelun suhteen.

Myyjä keskustelee asiakastapaamisen jälkeen omassa organisaatiossaan tuoteomistajan kanssa. Tuoteomistaja vastaa tuotteesta täysimääräisesti. Tuoteomistaja keskustelee kehitystiimin kanssa tapauksesta ja pyytää heitä arvioimaan työmäärän kyseisen palvelun toteutukseen. Työmäärä pilkotaan osasiin. Kukin osanen vastaa asiakkaan toivomaa palvelun toiminnallisuutta.

Myyjä ja tuoteomistaja laativat asiakkaalle tarjouksen. Tarjous käydään läpi asiakkaan kanssa. Tarjous koostuu n määrästä kehityssyklejä eli sprinttejä, joiden aikana toiminnallisuudet toteutetaan, testataan ja siirretään tuotantoon julkaisuina. Jokaisen sprintin päätteeksi valmistuu yksi tai useampi julkaisu. Sprintin pituus on yksi kuukausi.

Asiakas toteaa tarjouksen liian kalliiksi. Asiakasta pyydetään priorisoimaan toiminnallisuudet; mitkä ovat tärkeimpiä ja mitkä on saatava tuotantoon toivotussa aikataulussa, mitä voidaan jättää jopa kokonaan pois. Asiakas tekee päätöksen ja päästään yhteisymmärrykseen sisällöstä. Eli aika ja kustannukset eivät jousta, mutta sisältö joustaa.

Vaihe 2. Toteutus

Palvelun toteutus voi alkaa. Kehitystiimi toteuttaa palvelun itseohjautuvasti ja monitaitoisesti Scrumin periaatteita ja käytäntöjä noudattaen. Ensimmäisen sprintin julkaisut valmistuvat testattavaksi asiakkaan kanssa. Asiakas ilmoittaa, ettei se voi toimittaa testiaineistoa suunnitellusti.

Vaihe 3. Testaus

Kehitystiimi testaa sillä aineistolla mitä asiakas saa toimitettua. Laatua peilataan yhteisten hyväksyntäkriteerien pohjalta.  Todetaan, että aineisto ei ollut riittävän laadukasta kaikilta osin, mutta tietyillä riskeillä ensimmäiset julkaisut voidaan siirtää tuotantoon tuoteomistajan ja asiakkaan hyväksynnällä.  Asiakas pitää aikataulua tärkempänä ja  ottaa tietoisen riskin. Asiakas saa käyttöönsä palvelun ensimmäisen version.

Vaihe 4. Katselmointi

Sprintin jälkeen pidetään katselmointi. Katselmoinnissa ovat läsnä Scrum- tiimi ja asiakas.  Tuoteomistaja kertoo kehitysjonon tilanteen ja arvioi valmistumisajankohdan lopuille asiakkaan vaatimille toiminnallisuuksille. Ryhmä pohtii yhdessä mitä voidaan ja kannattaa tehdä seuraavassa sprintissä. Katselmoinnissa käydään läpi myös projektin aikataulu ja jäljellä oleva budjetti.

Katselmoinnissa tiedostetaan, että ensimmäisen sprintin aikana on syntynyt teknistä velkaa, eli lisätestaus ja mahdolliset korjaustoimenpiteet on tehtävä jossain vaiheessa. Mieluiten mahdollisimman pian.

Kuinka tämä malli poikkesi perinteisestä vesiputousmallista?

Ensimmäiseksi voittanee todeta, että asiakkaan sitoutumisaste on todennäköisesti korkeampaa, koska hän on oleellinen osa palvelun suunnittelua ja toteuttamista. Toteutus koostuu kuukauden mittaisista kehityssykleistä ja jokaisen syklin jälkeen on tuotannossa jotakin. Asiakas on tietoinen, ettei ensimmäinen versio ole ”lopullinen”, vaan seuraavien kehityssyklien aikana palvelu täydentyy/kehittyy.

Kustannukset ovat myös todennäköisesti helpommin ymmärrettävissä ja hyväksyttävissä.  Vaakakupissa on saako asiakas lähes kaiken mitä toivoo, muutokset mukaanlukien ja hyvällä laatutasolla ja oikeaan aikaan. Vai saako asiakas kaiken mitä haluaa, mutta jotain saattaa jäädä huomioimatta.

Entäpä aikataulu? Scrumin periaatteisiin kuuluu määritellä selkeät aikajänteet kaikelle työlle ja tapahtumille. Kehityssyklin päätteeksi tulee saada aina aikaiseksi jotakin julkaisukelpoista.

Perinteisessä mallissa pääpaino on sopimuksella ja määrittelyillä. Toteutus pohjautuu määrittelyihin ja mahdollisiin muutoksiin muutoksenhallinnan kautta. Muutokset yleensä lisäävät kustannuksia ja aikataulua pitää myös muuttaa. Perinteinen malli pitää tärkeänä roolitusta ja tehtävien selkeyttä sekä dokumentaatiota.

Ovatko ketterät menetelmät projektien pelastus?

Sanoisin, että yksin se tuskin on autuaaksi tekevä asia. Ketteryys ei tapahdu yhdessä yössä ja se vaatii organisaatiolta paljon. Toimintojen ja kulttuurin pitää olla ketteryyttä tukevia. Ketteryys on vaikea laji.

Näkisin, että molemmille, sekä vesiputoukselle, että ketteryydelle on tarvetta. Paljon riippuu organisaatiosta itsestään ja toimialasta. Joitakin toimialoja säätelee lait ja standardit. Molemmissa menetelmissä on omat haasteensa ja hyvät puolensa.

 

Tutustu muihin artikkeleihini täällä.

 

 

Close Menu