Julkishallinnon tilaisuudessa pidetty esitys ketterästä kehityksestä.

1. Ketterän kehityksen
Mitä, Miksi ja Miten
Marko Taipale / Huitale Oy

2. Marko Taipale
• Agile Coach, 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 ja miten?
• 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 are wrong but some are useful”
- George E. P. Box

6. 1) Haasteet, joita kohtaamme 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% IT projekteista 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, Standish Group
“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. Kommunikointi

16. 1) Haasteet, joita kohtaamme 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, joita kohtaamme
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: “Aloitetaan tä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 projekti onnistuvat 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, joita kohtaamme
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, toimittajan rooli
• Sisältövastuuta ei voi ulkoistaa – “riskin
myyminen” tyypillinen virhe
• Ketterässä yhteistyön oltava tiivistä
• Asiakkaan tuoteomistaja <-> Toimittajan
tuoteomistaja

36. Arviointi ja kokemusperäisyys

37. Läpinäkyvyys