Kävin tänään tapaamassa pitkäaikaista asiakastamme, jonka kanssa palvelukehitystä on tehty usean vuoden ajan. Tovi oli kuitenkin mennyt pienkehitysmoodissa, ja nyt on taas tarkoitus lähteä suunnittelemaan hieman isompaa uudistusta. Uteliaana he kyselivät lähestymistapaamme. Mieleeni ei tullut ehdottaakaan muuta kuin ketterää kehitystä. Miksi asiakas odottaisi kuukausia saadakseen palvelun seuraavan version ensimmäistä kertaa nähtäväksi? Maailma muuttuu hurjaa vauhtia vuosineljänneksittäin, jollei jopa nopeammin. Niin me siinä yksissä tuumin mietimme, että ehdottomasti ainoa lähestymistapa on ensin kerätä liiketoiminnan vaatimukset määrityksiksi product backlogiin, jonka jälkeen lähdemme ensimmäistä versiota uudesta palvelusta toteuttamaan. Toteutus tehdään kolmen viikon pituisissa sprinteissä. Näin asiakas voi muuttaa liiketoiminnasta ja etenkin omista asiakkaistaan kumpuavia vaatimuksia pitkin matkaa. Jokaisen sprintin lopputuloksena syntyy uusi käypä versio liiketoiminnallisesti kriittisestä verkkopalvelusta.

Intranet käpisteltävissä kahdessa päivässä

Perinteisellä vaiheittain etenevällä prosessilla, mallia vesiputous, asiakkaat kokevat saavansa kirkkaan käsityksen projektissa syntyvästä lopputuotoksesta käyttöönoton kannalta liian myöhäisessä vaiheessa. Ketterät projektit taas lähestyvät kehitystä siten, että prototyyppi tai jonkinlainen ensimmäinen versio lopputuloksesta on käpisteltävissä mahdollisimman nopeasti. Parhaimmillaan esimerkiksi Valo-intranettimme on ollut asiakkaalla tutkittavana jo kahden päivän kuluttua projektin aloituksesta. Näin projektin lopputuotteesta saa käsityksen jo mahdollisimman aikaisessa vaiheessa projektin aikana tehtäviin päätöksiin. Sehän on se joka onnistumisen ratkaisee.

Ei vain yhdenlaista ketteryyttä

Ketteriäkin projekteja voidaan tehdä hyvin eri tavoin. Puhtaasti scrumilla tehtävissä projekteissa on päämäärästä tiedossa vain visio. Pre-game-vaiheen aikana tämä visio kirkastetaan tulevan palvelun sisältöä kuvaavaksi product backlogiksi, jonka avulla ensimmäinen sprintti toteutetaan. Tämän lisäksi on erilaisia asiakkaan lähtökohdista suunniteltuja ketteriä toimituksia, joissa protoillaan tai muulla tavoin testaillaan tulevaa lopputuotetta. Usein asiakas myös haluaa, että lopputuotos saadaan käyttöön määrätyssä aikataulussa ja määrätyllä budjetilla. Myös tähän tarpeeseen ketterä kehitystapa sopii mainiosti. Tekemisen läpinäkyvyys koko projektin ajan auttaa asiakasta valitsemaan tärkeimmät ja keskeisimmät toiminnallisuudet toteutettavaan kokonaisuuteen.

Tulemme mielellämme keskustelemaan kanssanne viestinnän tai digitaalisen liiketoiminnan tarpeistanne ja suunnittelemaan kanssanne sopivaa lähestymistapaa.

Aiheesta lisää

YLE:n Sekasin voitti Kultaisen Venlan Yle, Suomen Mielenterveysseura, Mielenterveyden keskusliitto ja Mannerheimin lastensuojeluliitto toteuttivat Sekasin-kampanjan, jonka tarkoituksena ol...
Suutarin ja räätälin kengät Viimeaikoina on ollut keskustelua IT-alalla siitä, että mikä on ns. räätälikoodin ja valmiiden teknologioiden erot ja hyödyt. Aika useasti teknologiat...
Kolme tapaa varmistaa softahankkeen epäonnistuminen Digiratkaisuita voidaan ottaa käyttöön tuotteina tai tehdä itse räätälöitynä sekä usein myös näiden yhdistelmänä. Jos löytyy olemassa oleva testattu j...
Tutkimusmatkailua IoT-maailmaan Kokoonnuimme perjantaina, niin Helsingin kuin Jyväskylän toimistoilla, keskustelemaan ja testailemaan juttuja Internet of Things -teeman ympärillä. Ha...
Asiakas on kunkku myös laadunvarmistuksen näkövinkkelistä Mitä paremmin onnistumme laadunvarmistuksessa, sitä parempi on myös asiakkaamme tuntema asiakaskokemus. Tätä asiaa käsiteltiin myös Testing Assembly –...
Yhden ihmisen luovuustrippi Verkkopalveluiden kilpailutuksissa tarjoajan kannattaa usein luottaa intuitioon siitä, milloin asetelmassa ei ihan kaikki ole kuin Strömsössä. Hälytys...

Tietoa kirjoittajasta

Kommentoi