Embed Size (px)
Citation preview
Ketterä kehittäminen julkishallinnossaTyöterveyslaitoksen ketterän kehittämisen seminaari
Karoliina Luoto, Codento· 13.12.2013
Karoliina Luoto + CodentoKonsultti, ketterä projektinhallinta,konseptointiAiemmin: tuoteomistaja, verkkotyön kehittäjä, viestintäihminen
Älykkään ohjelmistokehityksen konsulttiyritys
Ketterät projektit onnistuvat useammin kuin vesiputousmallilla tehdyt.
Miksi?
• Suunnittele – toteuta – testaa – julkaise toimii hienosti selkeissä, tarkkarajaisissa kokonaisuuksissa
• Tällaisia on maailmassa vähän
Tyypillisimmät ongelmatvesiputousprojekteissa:1. Kommunikoinnin puute 2. Kasautuvat ongelmat3. Hutiin menevä toiminnallisuus4. Viivästykset5. Aikaa ja rahaa kuluu riitelemiseen 6. Vastuun välttely varsinkin asiakkaan päässä7. Muuttuvia vaatimuksia / kasvavaa ymmärrystä ei saada hallittua
Mistä ketterän etu syntyy?Ketterän ohjelmistokehityksen julistus”Kokemuksemme perusteella arvostamme:
Yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja
Yhteistyötä enemmän kuin sopimusneuvotteluja
Toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota
Vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassaJälkimmäisilläkin asioilla on arvoa, mutta arvostamme ensiksi mainittuja
enemmän.”Ks. http://agilemanifesto.org/iso/fi/
Ketterä mallikaanei kuitenkaan ole hopealuoti
Kuva: Chris Turner Photography, Flickr
Miten julkishallinto onnistuu ketterässä kehityksessä?
Avainrooleissa:1. Vastuun otto visiosta eli projektin suunnasta2. Resursointi3. Koko päätöksentekoketjun pohtiminen läpi4. Hankinta5. Sopimushallinta6. Läpinäkyvyys
1. Vastuun ottovisiosta
Kuva: aglet, Flickr
Vastuun otto visiostaTä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
Photo: California Bakery, Flickr
2. Resursointi
ResursointiTä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
Photo: PittCaleb, Flickr
3. Käy läpikoko päätöksentekoketju
Koko päätöksentekoketjuTä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ä
Photo: Aarni Heiskanen, Flickr
4. Hankinta
HankintaTä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
Photo: SanFranAnnie, Flickr
5. Sopimushallinta
SopimushallintaTä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
Photo: decade_null, Flickr
6. Läpinäkyvyys
LäpinäkyvyysTärkeä huomioida:• Kaikki tärkeimmät artefaktit oltava
kehitystiimiin asti saatavilla • Myös budjettinäkymä
Mistä tietää että on ketterä?Esimerkki kriteeristöstä:1. Käyttäjät osallistetaan kehitysprosessiin2. Tiimillä on valtaa tehdä päätöksiä 3. Vaatimukset elävät mutta aikataulu ei 4. Vaatimukset kuvataan ylätasolla, kevyesti ja visuaalisesti5. Kehitystyö tapahtuu pienissä osajulkaisuissa, joita voidaan
kehittää edelleen6. Keskitytään säännölliseen tuosten ulos saamiseen7. Tehdään jokainen ominaisuus valmiiksi ennen kuin siirrytään
seuraavaan8. 80/20 -sääntö: keskitytään etsimään 20 %:n ratkaisuja jotka
täyttävät 80 % tarpeesta9. Testausta tehdään koko projektin läpi – testaa ajoissa ja usein10. Yhteiskehittelevä ote kaikilta projektin pelaajilta
