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

Ketterä kehittäminen julkishallinnossa

Tags:

Embed Size (px)

DESCRIPTION

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

Citation preview

  • 1. Ketter kehittminen julkishallinnossa Tyterveyslaitoksen kettern kehittmisen seminaariKaroliina Luoto, Codento 13.12.2013

2. Karoliina Luoto + Codento Konsultti, ketterprojektinhallinta,konseptointi Aiemmin: tuoteomistaja, verkkotyn kehittj, viestintihminenlykkn ohjelmistokehityksen konsulttiyritys 3. Kettert projektit onnistuvat useammin kuin vesiputousmallilla tehdyt. 4. Miksi? Suunnittele toteuta testaa julkaise toimii hienosti selkeiss, tarkkarajaisissa kokonaisuuksissa Tllaisia on maailmassa vhn 5. Tyypillisimmt ongelmat vesiputousprojekteissa: 1. 2. 3. 4. 5. 6. 7.Kommunikoinnin puute Kasautuvat ongelmat Hutiin menev toiminnallisuus Viivstykset Aikaa ja rahaa kuluu riitelemiseen Vastuun vlttely varsinkin asiakkaan pss Muuttuvia vaatimuksia / kasvavaa ymmrryst ei saada hallittua 6. Mist kettern etu syntyy? Kettern ohjelmistokehityksen julistus Kokemuksemme perusteella arvostamme: Yksilit ja kanssakymist enemmn kuin menetelmi ja tykalujaToimivaa ohjelmistoa enemmn kuin kattavaa dokumentaatiotaYhteistyt enemmn kuin sopimusneuvottelujaVastaamista muutokseen enemmn kuin pitytymist suunnitelmassa Jlkimmisillkin asioilla on arvoa, mutta arvostamme ensiksi mainittuja enemmn. Ks. http://agilemanifesto.org/iso/fi/ 7. Ketter mallikaan ei kuitenkaan ole hopealuotiKuva: Chris Turner Photography, Flickr 8. Miten julkishallinto onnistuu ketterss kehityksess? Avainrooleissa: 1. 2. 3. 4. 5. 6.Vastuun otto visiosta eli projektin suunnasta Resursointi Koko ptksentekoketjun pohtiminen lpi Hankinta Sopimushallinta Lpinkyvyys 9. 1. Vastuun otto visiosta Kuva: aglet, Flickr 10. Vastuun otto visiosta Trke huomioida: Jatkuvan kehittmisen ja sitoutumisen paradigma Toiminnan ja kyttjn tarpeita ei voi ymmrt kukaan paremmin kuin tilaaja Ominaisuuksien priorisointi trkein tilaajan tehtv Tiimin jsenten vastuunoton tukeminen teknologiavisiosta 11. 2. ResursointiPhoto: California Bakery, Flickr 12. Resursointi Trke huomioida: Tuoteomistajapanos 20 % tyvoimasta -> 5 hengen tiimiss kokonainen typanos Jos tuoteomistajan ensimminen ketter projekti, koulutusta tarvitaan Pisteminen ketteryysvalmennus voi olla hyvksi matkan varrella 13. 3. Ky lpi koko ptksentekoketju Photo: PittCaleb, Flickr 14. Koko ptksentekoketju Trke huomioida: Ohjausryhmn oltava vision takana ja ymmrrettv tytapa -> ohjausryhmsopimus? Monesti metodieroja suhteessa kettern tiimin toimintaan on esim. ptksenteossa Trke tehd lpinkyvksiYhteistyn aluksi hyv katsoa lpi metodit koko ketjun lpi johtoryhmst toteutustiimiin Retrospektiivit, varsinkin parannusten tekeminen, ketteryyden ytimess 15. Photo: Aarni Heiskanen, Flickr4. Hankinta 16. Hankinta Trke huomioida: Ostetaan tyt, ei tietty lopputulosta Huippuosaamisen houkutteleminen sitoutumalla itse ja ilmaisemalla se, tarjouskilpailua mainostamalla, julkisella referenssill, henkilkohtaisilla onnistumispalkinnoillaOsaamisen arvioiminen: arvioidaan nimettyjen resurssien, ei yrityksen osaamista Osaamisen silyttminen: vaihdoksista sopiminen Yhteistykyvyn ostaminen, esim. yhteistykokemuksesta palkitseminen 17. 5. SopimushallintaPhoto: SanFranAnnie, Flickr 18. Sopimushallinta Trke huomioida: Sopimuksen keskeyttminen trkein pelote toimittajalle Pienin hyvksyttv tuote (mimum viable product) 50 % budjetista, jotta ketteryys toteutuu Lpinkyvyys trkein riskinhallintamekanismi Koodi jtv ostajalle, esim. GitHub 19. 6. Lpinkyvyys Photo: decade_null, Flickr 20. Lpinkyvyys Trke huomioida: Kaikki trkeimmt artefaktit oltava kehitystiimiin asti saatavilla Mys budjettinkym 21. Mist tiet ett on ketter? Esimerkki kriteeristst: 1. 2. 3. 4. 5.Kyttjt osallistetaan kehitysprosessiin Tiimill on valtaa tehd ptksi Vaatimukset elvt mutta aikataulu ei Vaatimukset kuvataan yltasolla, kevyesti ja visuaalisesti Kehitysty tapahtuu pieniss osajulkaisuissa, joita voidaan kehitt edelleen 6. Keskitytn snnlliseen tuosten ulos saamiseen 7. Tehdn jokainen ominaisuus valmiiksi ennen kuin siirrytn seuraavaan 8. 80/20 -snt: keskitytn etsimn 20 %:n ratkaisuja jotka tyttvt 80 % tarpeesta 9. Testausta tehdn koko projektin lpi testaa ajoissa ja usein 10. Yhteiskehittelev ote kaikilta projektin pelaajilta 22. Kiitos! Kommentteja, [email protected] @totoroki +358 40 7658504