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

Marko Taipale

•  15+ vuotta ohjelmistotuotantoa •  Agile Coach, CTO, Co-founder, Advisor

•  Riippumaton konsultti: ostajat, toimittajat, tuotetalot

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

•  Kymmeniä kansainvälisiä julkisia esiintymisiä

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

Seuraavat 30min…

1)  Haasteet, joita kohtaamme IT-hankkeissa

2) Mikä ketterä 3) Miksi ketterästi 4) Miten ketteryyttä sovelletaan

“All models are wrong but some are useful” - George E. P. Box

2) Mikä ketterä 3) Miksi ketterästi 4) Miten ketteryyttä sovelletaan

1) Haasteet, joita kohtaamme IT-hankkeissa

Perinteinen ajattelutapa

Sisältö

Kulut Aikataulu

2010: “Tämä sisältö, tässä aikataulussa, tällä budjetilla.” (Suunnitelma, jonka emme tiedä vielä epäonnistuvan) (… mutta onneksi meillä on sopimus …)

2012: “Mehän olemme myöhässä! Eikä tämä itseasiassa palvele edes meidän (muuttuneita?) tarpeita! Tarvitaan muutosprojekti.”

2011: “Missäköhän mahdetaan oikein mennä…”

Arvioinnin virheellisyydestä

How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006

Määrittelyt

117 h

Samat määrittelyt – enemmän sivuja

Arvioinnin virheellisyydestä

How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006

Määrittelyt

117 h

Samat määrittelyt – enemmän sivuja

173 h

Arvioinnin virheellisyydestä

How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006

Määrittelyt

20 h

Samat määrittelyt – lisätty epäolennaisuuksia

A

B

C

A

B

C

Arvioinnin virheellisyydestä

How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006

Määrittelyt

20 h

Samat määrittelyt – lisätty epäolennaisuuksia

39 h

A

B

C

A

B

C

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

Projektit

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.”

Standish Group raportoi XP2002 konferenssissa

45%

19%

16%

13%

7% Ei koskaan Harvoin Joskus Usein Aina

Vain 20% ominaisuuksista on jatkuvassa käytössä

Yli 60% ei käytetä lainkaan tai harvoin

Ominaisuudet

Ominaisuuksien määrä

Kus

tann

ukse

t

Kommunikointi

1)  Haasteet, joita kohtaamme IT-hankkeissa

3) Miksi ketterästi 4) Miten ketteryyttä sovelletaan

2) Mikä ketterä

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.

12 periaatetta •  Tärkein tavoitteemme on tyydyttää

asiakas toimittamalla tämän tarpeet täyttäviä versioita ohjelmistosta aikaisessa vaiheessa ja säännöllisesti.

•  Otamme vastaan muuttuvat vaatimukset myös kehityksen myöhäisessä vaiheessa. Ketterät menetelmät hyödyntävät muutosta asiakkaan kilpailukyvyn edistämiseksi.

•  Toimitamme versioita toimivasta ohjelmistosta säännöllisesti, parin viikon tai kuukauden välein, ja suosimme lyhyempää aikaväliä.

•  Liiketoiminnan edustajien ja ohjelmistokehittäjien tulee työskennellä yhdessä päivittäin koko projektin ajan.

•  Rakennamme projektit motivoituneiden yksilöiden ympärille. Annamme heille puitteet ja tuen, jonka he tarvitsevat ja luotamme siihen, että he saavat työn tehtyä.

•  Tehokkain ja toimivin tapa tiedon välittämiseksi kehitystiimille ja tiimin jäsenten kesken on kasvokkain käytävä keskustelu.

•  Toimiva ohjelmisto on edistymisen ensisijainen mittari.

•  Ketterät menetelmät kannustavat kestävään toimintatapaan. Hankkeen omistajien, kehittäjien ja ohjelmiston käyttäjien tulisi pystyä ylläpitämään työtahtinsa hamaan tulevaisuuteen.

•  Teknisen laadun ja ohjelmiston hyvän rakenteen jatkuva huomiointi edesauttaa ketteryyttä.

•  Yksinkertaisuus - tekemättä jätettävän työn maksimointi - on oleellista.

•  Parhaat arkkitehtuurit, vaatimukset ja suunnitelmat syntyvät itseorganisoituvissa tiimeissä.

•  Tiimi tarkastelee säännöllisesti, kuinka parantaa tehokkuuttaan, ja mukauttaa toimintaansa sen mukaisesti.

Menetelmät

Scrum

Kanban

XP

DSDM

Crystal

FDD EVO

Scrum Tuotteen kehitysjono

(Product Backlog)

Sprintin tehtävälista (Sprint Backlog)

Sprint

Päiväpalaveri (Daily Scrum)

Tuoteversio (Product increment)

2-4 vkoa Edistymiskäyrä

Edistymiskäyrä

Scrum Tuotteen kehitysjono

(Product Backlog)

Sprintin tehtävälista (Sprint Backlog)

Sprint

Päiväpalaveri (Daily Scrum)

Tuoteversio (Product increment)

2-4 vkoa Sprintin

suunnittelu Katselmus

Retrospektiivi

Edistymiskäyrä

Scrum Tuotteen kehitysjono

(Product Backlog)

Sprintin tehtävälista (Sprint Backlog)

Sprint

Päiväpalaveri (Daily Scrum)

Tuoteversio (Product increment)

2-4 vkoa Sprintin

suunnittelu Katselmus

Retrospektiivi

Tuoteomistaja (Product Owner) Scrummaster Kehitystiimi Sidosryhmäläinen

Oikeassa elämässä

Tukitiimi / organisaatio

LTO, PP LTO, PP

Hanke

Organisaatio A Organisaatio B

1)  Haasteet, joita kohtaamme IT-hankkeissa

2) Mikä ketterä 4) Miten ketteryyttä sovelletaan

3) Miksi ketterästi

Perinteinen ajattelutapa

Sisältö

Kulut Aikataulu

2010: “Tämä sisältö, tässä aikataulussa, tällä budjetilla.” (Suunnitelma, jonka emme tiedä vielä epäonnistuvan) (… mutta onneksi meillä on sopimus …)

2012: “Mehän olemme myöhässä! Eikä tämä itseasiassa palvele edes meidän (muuttuneita?) tarpeita! Tarvitaan muutosprojekti.”

2011: “Missäköhän mahdetaan oikein mennä…”

Ketterä ajattelutapa

Sisältö

Kulut Aikataulu

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”

Näkyvyys

Ketteryyden hyödyt

Ketterä Vesiputous

Näkyvyys Sopeutuvaisuus

Ketteryyden hyödyt

Ketterä Vesiputous

Näkyvyys Sopeutuvaisuus

Liiketoiminnallinen arvo

Ketteryyden hyödyt

Ketterä Vesiputous

Näkyvyys Sopeutuvaisuus

Liiketoiminnallinen arvo Riski

Ketteryyden hyödyt

Ketterä Vesiputous

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

4) Miten ketteryyttä sovelletaan?

1)  Haasteet, joita kohtaamme IT-hankkeissa

2) Mikä ketterä 3) Miksi ketterästi

Aloita paremmin

Tarjouspyyntö •  Tiimi, yhdessä •  Muutokset ok •  Kilpailuta ketterästi

Sopimus •  = yhteinen ymmärrys •  Tavoitteilla linjattu

Win-Win toimitustapa

http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts

Kiitos!

•  marko.taipale@huitale.com •  www.huitale.com •  +358 40 5786 447 •  twitter: @markotaipale •  linkedin:

http://fi.linkedin.com/in/markotaipale

Asiakkaan rooli, toimittajan rooli

•  Sisältövastuuta ei voi ulkoistaa – “riskin myyminen” tyypillinen virhe

•  Ketterässä yhteistyön oltava tiivistä •  Asiakkaan tuoteomistaja <-> Toimittajan

tuoteomistaja

Arviointi ja kokemusperäisyys

Läpinäkyvyys