Esitys FlowIT-hankkeen Ketterän kehittämisen seminaarissa Työterveyslaitoksella 13.12.2013.

1. Ketterä kehittäminen
julkishallinnossa
Työterveyslaitoksen ketterän
kehittämisen seminaari
Karoliina Luoto, Codento· 13.12.2013

2. Karoliina Luoto + Codento
Konsultti, ketterä
projektinhallinta,
konseptointi
Aiemmin: tuoteomistaja, verkkotyön
kehittäjä, viestintäihminen
Älykkään ohjelmistokehityksen
konsulttiyritys

3. Ketterät projektit onnistuvat useammin kuin
vesiputousmallilla tehdyt.

4. Miksi?
• Suunnittele – toteuta – testaa –
julkaise toimii hienosti selkeissä,
tarkkarajaisissa kokonaisuuksissa
• Tällaisia on maailmassa vähän

5. Tyypillisimmät ongelmat
vesiputousprojekteissa:
1.
2.
3.
4.
5.
6.
7.
Kommunikoinnin puute
Kasautuvat ongelmat
Hutiin menevä toiminnallisuus
Viivästykset
Aikaa ja rahaa kuluu riitelemiseen
Vastuun välttely varsinkin asiakkaan päässä
Muuttuvia vaatimuksia / kasvavaa ymmärrystä ei saada hallittua

6. Mistä ketterän etu syntyy?
Ketterän ohjelmistokehityksen julistus
”Kokemuksemme perusteella arvostamme:
Yksilöitä ja kanssakäymistä enemmän
kuin menetelmiä ja työkaluja
Toimivaa ohjelmistoa enemmän kuin
kattavaa dokumentaatiota
Yhteistyötä enemmän kuin
sopimusneuvotteluja
Vastaamista muutokseen enemmän
kuin pitäytymistä suunnitelmassa
Jälkimmäisilläkin asioilla on arvoa, mutta arvostamme ensiksi mainittuja enemmän.”
Ks. http://agilemanifesto.org/iso/fi/

7. Ketterä mallikaan
ei kuitenkaan ole hopealuoti
Kuva: Chris Turner Photography, Flickr

8. Miten julkishallinto onnistuu
ketterässä kehityksessä?
Avainrooleissa:
1.
2.
3.
4.
5.
6.
Vastuun otto visiosta eli projektin suunnasta
Resursointi
Koko päätöksentekoketjun pohtiminen läpi
Hankinta
Sopimushallinta
Läpinäkyvyys

9. 1. Vastuun otto
visiosta
Kuva: aglet, Flickr

10. Vastuun otto visiosta
Tärkeä huomioida:
•
•
•
•
Jatkuvan kehittämisen ja sitoutumisen paradigma
Toiminnan ja käyttäjän tarpeita ei voi ymmärtää
kukaan paremmin kuin tilaaja
Ominaisuuksien priorisointi tärkein tilaajan tehtävä
Tiimin jäsenten vastuunoton tukeminen
teknologiavisiosta

11. 2. Resursointi
Photo: California Bakery, Flickr

12. Resursointi
Tärkeä huomioida:
•
•
•
Tuoteomistajapanos 20 % työvoimasta
-> 5 hengen tiimissä kokonainen työpanos
Jos tuoteomistajan ensimmäinen ketterä projekti,
koulutusta tarvitaan
Pistemäinen ketteryysvalmennus voi olla hyväksi
matkan varrella

13. 3. Käy läpi
koko päätöksentekoketju
Photo: PittCaleb, Flickr

14. Koko päätöksentekoketju
Tärkeä huomioida:
•
•
Ohjausryhmän oltava vision takana ja ymmärrettävä
työtapa -> ohjausryhmäsopimus?
Monesti metodieroja suhteessa ketterän tiimin
toimintaan on esim. päätöksenteossa
•
•
•
Tärkeää tehdä läpinäkyväksi
Yhteistyön aluksi hyvä katsoa läpi metodit koko ketjun
läpi johtoryhmästä toteutustiimiin
Retrospektiivit, varsinkin parannusten tekeminen,
ketteryyden ytimessä

15. Photo: Aarni Heiskanen, Flickr
4. Hankinta

16. Hankinta
Tärkeä huomioida:
•
•
Ostetaan työtä, ei tiettyä lopputulosta
Huippuosaamisen houkutteleminen
•
•
•
•
sitoutumalla itse ja ilmaisemalla se, tarjouskilpailua
mainostamalla, julkisella referenssillä, henkilökohtaisilla
onnistumispalkinnoilla
Osaamisen arvioiminen: arvioidaan nimettyjen
resurssien, ei yrityksen osaamista
Osaamisen säilyttäminen: vaihdoksista sopiminen
Yhteistyökyvyn ostaminen, esim.
yhteistyökokemuksesta palkitseminen

17. 5. Sopimushallinta
Photo: SanFranAnnie, Flickr

18. Sopimushallinta
Tärkeä huomioida:
•
•
•
•
Sopimuksen keskeyttäminen tärkein pelote toimittajalle
Pienin hyväksyttävä tuote (mimum viable product)
50 % budjetista, jotta ketteryys toteutuu
Läpinäkyvyys tärkein riskinhallintamekanismi
Koodi jäätävä ostajalle, esim. GitHub

19. 6. Läpinäkyvyys
Photo: decade_null, Flickr

20. Läpinäkyvyys
Tärkeä huomioida:
•
•
Kaikki tärkeimmät artefaktit oltava kehitystiimiin asti
saatavilla
Myös budjettinäkymä

21. Mistä tietää että on ketterä?
Esimerkki kriteeristöstä:
1.
2.
3.
4.
5.
Käyttäjät osallistetaan kehitysprosessiin
Tiimillä on valtaa tehdä päätöksiä
Vaatimukset elävät mutta aikataulu ei
Vaatimukset kuvataan ylätasolla, kevyesti ja visuaalisesti
Kehitystyö tapahtuu pienissä osajulkaisuissa, joita voidaan kehittää
edelleen
6. Keskitytään säännölliseen tuosten ulos saamiseen
7. Tehdään jokainen ominaisuus valmiiksi ennen kuin siirrytään seuraavaan
8. 80/20 -sääntö: keskitytään etsimään 20 %:n ratkaisuja jotka täyttävät 80
% tarpeesta
9. Testausta tehdään koko projektin läpi – testaa ajoissa ja usein
10. Yhteiskehittelevä ote kaikilta projektin pelaajilta

22. Kiitos!
Kommentteja, kysymyksiä?
Karoliina.luoto@codento.com · @totoroki · +358 40 7658504