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!
• [email protected] • 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
Top Related