Download as PDF, PPTX
Uploaded byMarko Taipale
Julkishallinnon IT-hankinnat @Mearra
Julkishallinnon tilaisuudessa pidetty esitys ketterästä kehityksestä.
More Related Content
Similar to Julkishallinnon IT-hankinnat @Mearra
Julkishallinnon IT-hankinnat @Mearra
- 1. Ketterän kehityksen Mitä, Miksija Miten Marko Taipale / Huitale Oy
- 2. Marko Taipale • AgileCoach, CTO, Co-founder, Advisor • 15+ vuotta ohjelmistotuotantoa • Riippumaton konsultti: ostajat, toimittajat, tuotetalot • Kymmeniä kansainvälisiä julkisia esiintymisiä Kansainvälinen online-pelitalo (TO 100+ Meur) lyhensi TTM:a 24 kuukaudesta 3 kuukauteen Suomalainen energiayhtiö hankki prosessinohjaus/tilausjärjestelmän 20Meur hankkeessa ketterästi ja sai järjestelmän 4 kertaa kaavailtua nopeammin Suomalainen finanssisektorin toimija tehosti hanke- ja projektihallintoaan ja säästi 2,3Meur/vuosi hallintokuluissa
- 3. Mitä teen jamiten? • Autan yrityksiä muuttumaan, jotta he – saavuttaisivat paremman asiakastyytyväisyyden, – lyhyempiä läpimenoaikoja arvoketjussa, – tehokkaamman organisaation – paremman laadun ja; – paremman läpinäkyvyyden • Mahdollistan paremman ohjattavuuden ja seurannan
- 4. Seuraavat 30min… 1) Haasteet,joita kohtaamme IT-hankkeissa 2) Mikä ketterä 3) Miksi ketterästi 4) Miten ketteryyttä sovelletaan
- 5. “All models arewrong but some are useful” - George E. P. Box
- 6. 1) Haasteet, joitakohtaamme IT- hankkeissa 2) Mikä ketterä 3) Miksi ketterästi 4) Miten ketteryyttä sovelletaan
- 7. Perinteinen ajattelutapa 2010: “Tämäsisältö, tässä aikataulussa, tällä budjetilla.” (Suunnitelma, jonka emme tiedä vielä epäonnistuvan) (… mutta onneksi meillä on sopimus …) 2011: “Missäköhän mahdetaan oikein mennä…” 2012: “Mehän olemme myöhässä! Eikä tämä itseasiassa palvele edes meidän (muuttuneita?) tarpeita! Tarvitaan muutosprojekti.” Sisältö Kulut Aikataulu
- 8. Arvioinnin virheellisyydestä Määrittelyt Samat määrittelyt – enemmän sivuja 117 h How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006
- 9. Arvioinnin virheellisyydestä Määrittelyt Samat määrittelyt – enemmän sivuja 117 h 173 h How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006
- 10. Arvioinnin virheellisyydestä Määrittelyt Samat määrittelyt – lisätty epäolennaisuuksia A A B B C C 20 h How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006
- 11. Arvioinnin virheellisyydestä Määrittelyt Samat määrittelyt – lisätty epäolennaisuuksia A A B B C C 20 h 39 h How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006
- 12. Projektit 1994: 15% ITprojekteista onnistuu ~170% ylitys kustannuksissa ja aikataulussa 2004: 34% IT projekteista onnistuu ~70% ylitys kustannuksissa ja aikataulussa 2009: 32% IT projekteista onnistuu ~60% ylitys kustannuksissa ja aikataulussa Standish Group on tutkinut 40 000 projektia 10 vuoden aikana
- 13. Jim Johnsson, StandishGroup “Pääasiallisin syy kehitykselle on projektien pienentyminen” “Iteratiivinen prosessi vesiputousmallin sijasta on merkittävä askel eteenpäin.” “Vaikkei täydellistä mallia ole, niin ketterät menetelmät pääsevät hyvin lähelle.”
- 14. Ominaisuudet Vain 20% ominaisuuksista on jatkuvassa käytössä Yli 60% ei käytetä lainkaan tai harvoin 7% 13% Ei koskaan Kustannukset 45% Harvoin Joskus 16% Usein Aina 19% Ominaisuuksien määrä Standish Group raportoi XP2002 konferenssissa
- 15.
- 16. 1) Haasteet, joitakohtaamme IT-hankkeissa 2) Mikä ketterä 3) Miksi ketterästi 4) Miten ketteryyttä sovelletaan
- 17. 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 • Asiakasyhteistyö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.
- 18. 12 periaatetta • Tärkein tavoitteemme on tyydyttää • Tehokkain ja toimivin tapa tiedon asiakas toimittamalla tämän tarpeet välittämiseksi kehitystiimille ja tiimin täyttäviä versioita ohjelmistosta jäsenten kesken on kasvokkain käytävä aikaisessa vaiheessa ja säännöllisesti. keskustelu. • Otamme vastaan muuttuvat • Toimiva ohjelmisto on edistymisen vaatimukset myös kehityksen ensisijainen mittari. myöhäisessä vaiheessa. Ketterät • Ketterät menetelmät kannustavat menetelmät hyödyntävät muutosta kestävään toimintatapaan. Hankkeen asiakkaan kilpailukyvyn edistämiseksi. omistajien, kehittäjien ja ohjelmiston • Toimitamme versioita toimivasta käyttäjien tulisi pystyä ylläpitämään ohjelmistosta säännöllisesti, työtahtinsa hamaan tulevaisuuteen. parin viikon tai kuukauden välein, ja • Teknisen laadun ja ohjelmiston hyvän suosimme lyhyempää aikaväliä. rakenteen jatkuva huomiointi edesauttaa • Liiketoiminnan edustajien ja ketteryyttä. ohjelmistokehittäjien tulee • Yksinkertaisuus - tekemättä jätettävän työskennellä yhdessä päivittäin koko työn maksimointi - on oleellista. projektin ajan. • Parhaat arkkitehtuurit, vaatimukset ja • Rakennamme projektit motivoituneiden suunnitelmat syntyvät yksilöiden ympärille. Annamme heille itseorganisoituvissa tiimeissä. puitteet ja tuen, jonka he tarvitsevat ja luotamme siihen, että he saavat työn • Tiimi tarkastelee säännöllisesti, kuinka tehtyä. parantaa tehokkuuttaan, ja mukauttaa toimintaansa sen mukaisesti.
- 19. Menetelmät Scrum XP Kanban Crystal DSDM FDD EVO
- 20. Scrum Tuotteen kehitysjono Päiväpalaveri (Product Backlog) (Daily Scrum) Sprintin tehtävälista Tuoteversio (Sprint Backlog) (Product increment) Sprint 2-4 vkoa Edistymiskäyrä
- 21. Scrum Tuotteen kehitysjono Päiväpalaveri (Product Backlog) (Daily Scrum) Sprintin tehtävälista Tuoteversio (Sprint Backlog) (Product increment) Sprint Sprintin suunnittelu 2-4 vkoa Katselmus Edistymiskäyrä Retrospektiivi
- 22. Scrum Tuotteen kehitysjono Päiväpalaveri (Product Backlog) (Daily Scrum) Sprintin tehtävälista Tuoteversio (Sprint Backlog) (Product increment) Sprint Sprintin suunnittelu 2-4 vkoa Katselmus Edistymiskäyrä Retrospektiivi Tuoteomistaja Scrummaster Kehitystiimi Sidosryhmäläinen (Product Owner)
- 23. Oikeassa elämässä Hanke Organisaatio A Organisaatio B LTO, PP LTO, PP Tukitiimi / organisaatio
- 24. 1) Haasteet, joitakohtaamme IT-hankkeissa 2) Mikä ketterä 3) Miksi ketterästi 4) Miten ketteryyttä sovelletaan
- 25. Perinteinen ajattelutapa 2010: “Tämäsisältö, tässä aikataulussa, tällä budjetilla.” (Suunnitelma, jonka emme tiedä vielä epäonnistuvan) (… mutta onneksi meillä on sopimus …) 2011: “Missäköhän mahdetaan oikein mennä…” 2012: “Mehän olemme myöhässä! Eikä tämä itseasiassa palvele edes meidän (muuttuneita?) tarpeita! Tarvitaan muutosprojekti.” Sisältö Kulut Aikataulu
- 26. Ketterä ajattelutapa 2010: “Aloitetaantällä sisällöllä, katsotaan jatkuvasti mitä on järkevä tehdä” 2010 (4 viikkoa myöhemmin): “Ei näytä toteutuvan tavoiteaikataulussa, tehdään sittenkin XYZ heti, jotta saamme edes perustoiminnallisuudet” Sisältö Kulut Aikataulu
- 27. Ketteryyden hyödyt Näkyvyys Ketterä Vesiputous
- 28. Ketteryyden hyödyt Näkyvyys Sopeutuvaisuus Ketterä Vesiputous
- 29. Ketteryyden hyödyt Näkyvyys Sopeutuvaisuus Liiketoiminnallinen arvo Ketterä Vesiputous
- 30. Ketteryyden hyödyt Näkyvyys Sopeutuvaisuus Liiketoiminnallinen arvo Riski Ketterä Vesiputous
- 31. Tuloksia • Ketterät projektionnistuvat 60-80% (vrt. Keskimääräinen 30%) • Lyhyempi läpimenoaika, vähemmän virheitä, pienemmät kulut ja parempi tuottavuus http://www.ambysoft.com/surveys/agileFebruary2008.html http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf
- 32. 1) Haasteet, joitakohtaamme IT-hankkeissa 2) Mikä ketterä 3) Miksi ketterästi 4) Miten ketteryyttä sovelletaan?
- 33. Aloita paremmin Tarjouspyyntö Sopimus • Tiimi, yhdessä • = yhteinen ymmärrys • Muutokset ok • Tavoitteilla linjattu • Kilpailuta ketterästi Win-Win toimitustapa http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts
- 34. Kiitos! • marko.taipale@huitale.com • www.huitale.com • +358 40 5786 447 • twitter: @markotaipale • linkedin: http://fi.linkedin.com/in/markotaipale
- 35. Asiakkaan rooli, toimittajanrooli • Sisältövastuuta ei voi ulkoistaa – “riskin myyminen” tyypillinen virhe • Ketterässä yhteistyön oltava tiivistä • Asiakkaan tuoteomistaja <-> Toimittajan tuoteomistaja
- 36.
- 37.