Ketterä (agile) tietojärjestelmien suunnittelu

Ketterä (agile)
tietojärjestelmien
suunnittelu
Abrahamsson P, Conboy B and Wang X, Lots done, more to do: the
current state of agile systems development research
European Journal of Information Systems 18, 2009, 281-284
Lan Cao, Kannan Mohan, Peng Xu and B Ramesh, A framework for
adapting agile development methodologies. European Journal of
Information Systems 18, 2009, 332-343
Li Jiang and Armin Eberlein,
Towards A Framework for Understanding the Relationships between
Classical Software Engineering and Agile Methodologies
APOS 2008 ACM Workshop
17.2.2015
Pirkko Nykänen
1
Mitä ketteryys on?
• perusteluna on jatkuva muutos
• ketterät menetelmät ovat käytäntökokoelmia,
jotka sopivat tietyn tyyppisiin projekteihin ja
tietyn tyyppisille organisaatioille
• ohjelmistokehityksen tärkeimmät asiat kiteytetty
4 arvoon
• 12 pääperiaatetta kertovat tavat miten arvot
realisoidaan
• Käytännöt (engineering practices) kertovat
miten periaatteet toteutetaan käytännössä
Pirkko Nykänen
2
AGILE MANIFESTO 2001
– Me etsimme parempia keinoja ohjelmistojen kehittämiseen
tekemällä sitä itse ja auttamalla siinä muita
– Ketteryyden 4 arvoa
Arvostamme:
• Yksilöitä ja vuorovaikutusta enemmän kuin prosesseja ja
työkaluja
• Toimivaa sovellusta enemmän kuin kokonaisvaltaista
dokumentaatiota
• Asiakasyhteistyötä enemmän kuin sopimusneuvotteluja
• Muutokseen reagoimista enemmän kuin suunnitelman
noudattamista
www.agilemanifesto.org
Pirkko Nykänen
3
Ketteryyden 12 periaatetta
1 Tärkeintä on täyttää asiakkaan vaatimukset
julkaisemalla jatkuvasti ja aikaisin uusia hyödyllisiä
versioita ohjelmistosta
2 Hyväksytään ja otetaan vastaan muuttuvat
vaatimukset, jopa kehityksen loppuvaiheessa, ketterät
menetelmät valjastavat muutokset asiakkaan
kilpailueduksi.
3 Luovutetaan toimivia versioita kehitettävästä
ohjelmistosta säännöllisesti, mielellään lyhyin väliajoin
(muutamasta viikosta kuukauteen)
4 Liiketoiminnan ammattilaisten ja kehittäjien täytyy
työskennellä päivittäin yhdessä koko projektin ajan
Pirkko Nykänen
4
5
6
7
8
Rakennetaan projektit motivoituneiden
yksilöiden ympärille ja annetaan heille
ympäristö ja tuki jota he tarvitsevat sekä
luotetaan että he saavat työn tehtyä
Kaikkein tehokkain tapa välittää tietoa
kehitystiimille ja kehitystiimissä on kasvokkain
tapahtuva keskustelu
Toimiva ohjelmisto on ensisijainen edistymisen
mittari
Ketterät menetelmät suosivat kestävää
kehitystä. Rahoittajien, kehittäjien ja käyttäjien
tulisi kyetä pitämään jatkuvasti yllä tasainen
työtahti.
Pirkko Nykänen
5
9
Jatkuva huomion kiinnittäminen tekniseen
laatuun, sekä hyvään rakenteeseen ja
suunnitteluun, lisää ketteryyttä
10 Yksinkertaisuus – taito maksimoida työn
määrä, jota ei tarvitse tehdä, on olennaista
11 Parhaat arkkitehtuurit, vaatimukset ja
suunnitelmat nousevat itseorganisoituvista
tiimeistä
12 Tasaisin väliajoin tiimi miettii miten voisi tulla
entistä tuottavammaksi, ja siten säätää ja
muokkaa toimintaansa sen mukaan
Pirkko Nykänen
6
Ketterät käytännöt,
www.ketteratkaytannot.fi
•
•
•
•
•
Mahdollistavat työn tekemisen ketteryyden periaatteiden
mukaisesti
Arvovirtakartoitus
– Arvovirran ja siihen kuuluvien prosessin kartoitus, arvovirta on
esim virhekorjauksen läpimenoaika (kuinka paljon tehdään
hyödyllistä, arvoa tuottavaa työtä)
Jatkuva integraatio
– koko ohjelmisto koostetaan ja integroidaan jatkuvasti,
komponentteja integroidaan koko kehitysvaiheen ajan
Jälkitarkastelu
– Retrospective meeting/reflection workshop, mietitään ovatko
toimintatavat ja käytännöt ok vai olisiko parannettavaa
Koodikatselmointi
– varmistetaan tuotetun koodin toteutuskäytäntöjen mukaisuus ja
annetaan palautetta ohjelmoijille, jaetaan tietoa toteutetuista
komponenteista
Pirkko Nykänen
7
• Käyttäjätarinat
– ei tehdä vaatimusmäärittelyä etukäteen, vaatimukset
tarkentuvat työn kuluessa
– Alkuun lähdetään käyttäjätarinoilla (user stories),
kuvataan KUKA tekee, MITÄ tekee, MIKSI tekee,
tarinankirjoitussessiot, iteroidaan ja tarkennetaan
• Pariohjelmointi
– kaksi ohjelmoijaa työskentelee yhdessä yhdellä
koneella, toinen pääohjelmoija, toinen seuraa
vierestä, rooleja vaihdetaan
• Pienet julkaisut
– asennuspaketit ovat kooltaan pieniä ja niitä tehdään
usein, ketterän kehityksen inkrementit ovat yleensä 16 viikon mittaisia, kukin inkrementti on oltava
laadultaan asennuskelpoinen
• Prosessin muotoilu
– millaisia käytäntöjä juuri tässä projektissa, juuri tällä
tiimillä, juuri tälle asiakkaalle, juuri tällä teknologiaalustalla tarvitaan
• Päiväpalaveri
– Päivittäinen tapaaminen jossa koko tiimi koolla
– Päiväpalaverissa käydään läpi: Mitä teit edellisenä
päivänä, mitä aiot tehdä tänään, mitkä seikat
haittaavat työskentelyäsi
• Refaktorointi
– ohjelmakoodin muuttamista niin ettei toiminnallisuus
muutu, parannetaan koodin ylläpidettävyyttä
• Tasainen tahti (sustainable pace)
– Työtahti tasainen (40t/v), ylitöitä ei suositella
• Testivetoinen kehitys
– ohjelmiston kehitys testivetoisesti, virheiden määrä
pyritään pitämään koko ajan minimissä
• Toteutuskäytännöt
– pelisäännöt sille millaista koodia tuotetaan, kaikkien
koodi mahdollisimman samanlaista
• Yhteisomistus
– koodi on tiimin yhteisessä omistuksessa
• Yksikkötestaus
– kehittäjätestaus, matalan tason testaus, koodi toimii
ohjelmoijan tarkoittamalla tavalla
Ketterät menetelmät
• Pyritään minimoimaan riskejä jakamalla
ohjelmistokehitys lyhyisiin vaiheisiin,
iteraatioihin, kukin iteraatio on pieni projekti, joka
sisältää kaikki ohjelmistokehityksen vaiheet ja
tuottaa periaatteessa julkaisukelpoisen /
toimivan ohjelmiston
• jokaisen iteraation lopussa arvioidaan mitä on
saatu aikaan ja päätetään seuraavasta
iteraatiosta
Pirkko Nykänen
11
• Ketterät menetelmät ovat työskentelytapoja, joilla
tehostetaan ohjelmistotuotantoa ja kehitetään ohjelmistot
vastaamaan paremmin asiakkaan todellisia tarpeita
• Ketterien menetelmien tärkein uusi tekijä on koko
organisaation läpileikkaava uusi ajattelumalli, jossa
arvot, periaatteet ja käytäntö kohtaavat saumattomasti
• Myös tuottavuus ja ohjattavuus on nostettu entistä
keskeisempään asemaan
– Uudet menetelmät mahdollistavat huomattavasti
joustavamman ja tehokkaamman
tuotekehitysprosessin, koska menetelmällä voi tehdä
muutoksia ohjelmistoihin jokaisessa prosessin
vaiheessa
– Tämä on tarpeen, koska maailma muuttuu kiivaassa
tahdissa ja asiakkaan tarpeet sen mukana
Pirkko Nykänen
12
Ketterien menetelmien filosofiaa
• Perusfilosofia:
– ohjelmointi on voima eikä teollisuusprosessi,
luovaa työtä eikä tuotteen valmistamista
• Ketterät menetelmät
– vastavoima mekaanisille, ”epäinhimillisille”
suunnitelmavetoisille metodologioille
Pirkko Nykänen
13
Ketteryyden perustelua
• Ketteryyttä vaaditaan liiketoiminnassa yhä
enemmän niin yrityksissä kuin julkisella
sektorillakin, myös teknologian muutotokset ovat
nopeita
• ICT-projektien pitää sopeutua nopeasti
muuttuviin tilanteisiin
– tarvitaan uudenlaisia ohjelmistokehitysprosesseja,
jotka tuottavat valmiita sovelluksia aikaisempaa
nopeammin, mutta kuitenkin laadukkaasti
• Tunnetuimmat ketterät brändit ovat Extreme
Programming (XP), Scrum ja Lean Software
Development
Pirkko Nykänen
14
Scrum
•
•
Scrum tarjoaa sovelluskehitykseen mallin, jonka mukaan projektia
ohjataan
Scrumin lähtökohta = ajatus siitä, että ohjelmistokehityksen pitäisi
olla empiirinen prosessi, jolle on ominaista läpinäkyvyys,
tarkastelu ja sopeuttaminen
– Läpinäkyvyys tarkoittaa sitä, että kaikki osatekijät, jotka vaikuttavat
ohjelmistokehitysprojektin lopputulokseen, ovat ohjelmistokehitys-projektiin
osallistuvien henkilöiden tiedossa
– Ohjelmistokehitysprojektiin osallistuvat henkilöt tarkastelevat näitä osatekijöitä
jatkuvasti ohjelmistokehitysprojektin edetessä
– sopeuttavat omaa toimintaansa tarkastelun pohjalta saavuttaakseen toivotun
lopputuloksen.
•
Tavoitteena oleva tuote kehittyy pikkuhiljaa täydellisemmäksi ja
valmiimmaksi useiden kehitysjaksojen aikana
•
www.ketteratkaytannot.fi
Scrum
•
Scrum-projektissa esiintyy vain kolme eri roolia: Tuotteen omistaja, Scrummestari ja tiimi
– Tuotteen omistaja on henkilö, joka viime kädessä vastaa tuotteen
ominaisuuksista, siis "omistaa" tuotteen
• Tuotekehitysprojekteissa omistaja on tyypillisesti tuotepäällikkö,
asiakasprojekteissa se voi olla asiakkaan edustaja tai toimittajan tekninen
projektipäällikkö, omistajan tehtävänä on tehdä kaikki päätökset tuotteen
ominaisuuksista ja toiminnallisuuksiin vaikuttavista seikoista
– Scrum-mestarin tehtävänä on huolehtia siitä, että tiimi voi tehdä työtään
optimaalisella tavalla
• Tiimiläiset raportoivat päivittäin ongelmista, jotka hidastavat töiden
etenemistä ja mestarin tehtävänä on ratkoa nämä ongelmat, hän johtaa
päivittäiset aamupalaverit ja vastaa siitä, että Scrumia noudatetaan oikein
– Tiimiin kuuluvat kaikki henkilöt, jotka projektia ovat tekemässä
• Tiimin sisältä ei erikseen nimitetä arkkitehteja, ohjelmoijia, testaajia tai
käyttöliittymäsuunnittelijoita, vaan tiimiin kasataan henkilöitä, joilla on
tarvittava osaaminen, tiimi yhdessä rakentaa tuotteen, halutaan korostaa
kunkin tiimiläisen olevan projektin kannalta yhtä tärkeä ja että tiimi
yhdessä vastaa tuotteen kaikista puolista, ei koskaan yksittäinen henkilö
• Scrumissa työskennellään toistavasti ja lisäävästi (iterativeincremental) ennustettavuuden optimoimiseksi ja riskien
kontrolloimiseksi
• Kehitysjaksoa kutsutaan sprintiksi
– Sprintti on 1-4 viikon mittainen aikaraja, jonka sisällä tuotetaan “valmiin”
määritelmän täyttävä, käyttökelpoinen ja potentiaalisesti
julkaisukelpoinen tuoteversio
– Jokaisen sprintin sisältö sovitaan sprintin suunnittelupalaverissa ennen
sprintin aloitusta, ja toteutettaviksi valitaan sellaisia tuotteen
kehitysjonon kohtia, joilla on sillä hetkellä suurin merkitys projektin
onnistumiselle
– Sprintin lopuksi järjestetään sprinttikatselmus, jossa kehitystiimi
esittelee sprintin konkreettiset saavutukset (esim. ohjelmiston
uusimman version) tuoteomistajalle sekä mahdollisille sidosryhmien
edustajille palautteen saamiseksi ja ymmärryksen lisäämiseksi
kehityksen tilasta
– Ennen seuraavan sprintin aloittamista pidetään vielä sprintin
retrospektiivi, jossa tarkastellaan prosessin näkökulmasta mikä sprintin
aikana sujui hyvin ja mitä voitaisiin parantaa seuraavassa sprintissä
Pirkko Nykänen
17
•www.ketteratkaytannot.fi
Tällä erottelulla on Scrumissa keskeinen merkitys. Siat määräävät miten projektissa toimitaan, kanat voivat vain tehdä havaintoja.
Pirkko Nykänen
19
Pirkko Nykänen
20
Pirkko Nykänen
21
• Scrumissa kaikki ihmiset jaetaan kahteen ryhmään: sikoihin ja
kanoihin
• Sikoja ovat kaikki, joilla on jokin rooli projektissa (tuotteen
omistaja, scrum-mestari tai tiimiläinen)
• kanoja ovat muut, jotka ovat kiinnostuineita projektista. Nämä
voivat olla esimerkiksi ylempää johtoa tai toisen Scrum-tiimin
jäseniä.
– "A chicken and a pig are walking down the road. The
chicken says to the pig: "Do you want open a restaurant
with me?" The pig considers the question and replies:
"Yes, I'd like that. What do you want to call the
restaurant?" The chicken replies: "Ham and eggs!" The pig
stops, pauses and replies:"On second thought, I don't think
I want to open a restaurant with you. I'd be committed, but
you'd only be involved.”
• Tällä erottelulla on Scrumissa keskeinen merkitys. Siat
määräävät miten projektissa toimitaan, kanat voivat vain
tehdä havaintoja
SCRUM – edut, haasteet
• Scrum on yksinkertainen ja helposti opittava viitekehys
• Kehitystiimi voi käyttää vapaasti valitsemiaan prosesseja,
menetelmiä, tekniikoita ja työkaluja scrumin viitekehyksen
sisällä
• Scrum voidaan ottaa käyttöön ohjelmistokehitysprojektin
alussa tai kesken ohjelmistokehitysprojektin
• Oikein noudatettuna scrum tuo useita hyötyjä ohjelmistokehitysprojekteihin ja kehittäjät pitävät työskentelystä scrumprojekteissa.
• Scrumin käyttöönotto voi olla työlästä, aikaavievää ja
haastavaa, kehittäjät voivat vastustaa scrumin käyttöönottoa.
• Jos scrumtiimi muuttaa scrumin viitekehystä tai käyttää vain
osaa viitekehyksen rooleista, tapahtumista ja tuotoksista,
Pirkko
Nykänen
23
scrumin hyödyt voivat jäädä
toteutumatta
• Scrum soveltuu parhaiten pienten kehitystiimien käyttöön,
koska kehitystiimin pieni koko mahdollistaa suoran ja jatkuvan
vuorovaikutuksen sekä nopean tiedon jakamisen kaikkien
kehittäjien välillä
• Jos kehitystiimi on liian pieni, sen vuorovaikutus, osaaminen,
tehokkuus ja tuottavuus vähenevät - jos kehitystiimi on liian
suuri, sen toiminta vaatii liikaa koordinointia.
• Jos kehittäjät toimivat samaan aikaan useissa eri
projekteissa, heidän voi olla vaikea osallistua ja sitoutua
• On toivottavaa että scrum-tiimi työskentelee yhteisessä
työtilassa, maisemakonttorissa, jolloin tiedonvaihto on
helppoa ja jatkuvaa
• Työskentely monitaitoisessa kehitystiimissä tukee kehittäjien
välistä tiedon jakamista ja parantaa kehittäjien osaamista
Pirkko Nykänen
24
• Osaamisen kehittyessä scrum-projektin eteneminen ei
ole kiinni ainoastaan yhden kehittäjän työpanoksesta
• Kukaan ei johda kehitystiimin toimintaa, vaan kehitystiimi
päättää itse työnjaosta ja työskentelytavoistaan.
– Työskentely itseohjautuvassa kehitystiimissä lisää
kehittäjien mahdol-lisuuksia vaikuttaa omiin
työtehtäviinsä ja parantaa kehitystiimin toi-minnan
koordinointia ja parantaa kehittäjien motivaatiota,
sitoutumista scrum-projektiin, tehokkuutta ja
tuottavuutta
• Jos scrumista ei ole aikaisempaa kokemusta,
scrummaster ja muut scrum-projektin sidosryhmät voivat
vastustaa päätöksentekovallan antamista kehitystiimille
ja kehitystiimin voi olla vaikea ottaa vastuu
päätöksenteosta
Pirkko Nykänen
25
Ketterien menetelmien odotuksia
•
Uusien ratkaisumallien ylle on asetettu merkittäviä odotuksia
laadun ja tuottavuuden parantamisessa
– Voidaan saavuttaa huomattavia säästöjä ohjelmistoprojekteissa
•
•
•
Nykyiset avainsanat ovat tehokkuus, jatkuva muutosvalmius ja
erittäin lyhyet tuotantosyklit
Perinteisten painopistealueiden – prosessien, dokumentoinnin
ja sopimusten – väitetään jäykistävän organisaatioita ja
kehitystiimejä siten, että liiketoimintaedut jäävät saamatta
Suomen ohjelmistoteollisuutta uhkaa tuotannon siirtyminen halpoja
tuotantokustannuksia tarjoaviin maihin, joten uusia innovaatioita ja
ohjelmistojen toiminta- ja kehitysmalleja on omaksuttava ripeästi
käyttöön
– Ketterän ohjelmistotuotannon menetelmillä suomalaisilla
yrityksillä on entistä paremmat kilpailumahdollisuudet alan
globaalilla kilpailukentällä
– Lupaava alue tulevaisuudessa: ketteryyden ja
käyttäjäkeskeisyyden yhdistäminen
Pirkko Nykänen
26
Agiilit versus traditionaaliset
menetelmät
• Jakavat saman filosofisen perustan, ovat
teknisesti toisiaan täydentäviä ja tukevia
• AGILITY
– The continual readiness of an entity to rapidly
or inherently, proactively or reactively,
embrace change, through high quality,
simplistic, economical components and
relationships with its environment.
• Conboy & Fitzgerald 2004
Pirkko Nykänen
27
Ketteryys ja käyttäjäkeskeisyys
• Molemmat iteratiivisia ja nostavat
asiakkaan ja käyttäjät keskeiseen rooliin
ohjelmistotuotantoprosessissa
• onko näiden yhdistäminen järkevää?
Pirkko Nykänen
28
Käyttäjäkeskeisyys
• Kantava ajatus: käyttäjä on keskeinen osa
ohjelmistokehitysprosessissa
– käyttäjiä haastatellaan, käyttäjiä tarkkaillaan heidän
työssään, tutkitaan ja analysoidaan käyttäjäryhmän
tietoja
– käyttäjä kokeilee prototyyppejä
– palautteiden, tietojen ja havaintojen avulla löydetään
uusia vaatimuksia, parannuksia ja ymmärretään eri
osien / toimintojen merkitys ja tärkeys
– etukäteissuunnittelua tehdään paljon: kuvataan
kohdekäyttäjiä, tehdään käyttöliittymäsuunnittelua etc
– kaikki suunnittelu ja kehitys dokumentoidaan
perusteellisesti
Pirkko Nykänen
29
ketteryys vs käyttäjäkeskeisyys
• ketterät menetelmät eivät korosta
etukäteissuunnittelua ja dokumentointi on
kevyttä
• Molemmissa: luodaan useita prototyyppejä,
joista haetaan palautetta ja jatketaan
kehitystyötä eteenpäin
– palaute tulee ketterissä menetelmissä asiakkaan
vastuulliselta edustajalta, käyttäjäkeskeinen
suunnittelu hakee palautteen loppukäyttäjiltä
– yhdistely toisi palautteen molemmilta
Pirkko Nykänen
30
• Ketteryyden ja käyttäjäkeskeisyyden
yhdistäminen
– Käyttäjäkeskeinen suunnittelu projektin alussa
– yhtenäisen käyttöliittymän suunnittelu, muttei liikaa
suunnittelua rajaavia päätöksiä
– iteroiden ja testaten haetaan käytettävyydeltään
oikeanlainen käyttöliittymä
– paperiprotot ja käyttäjien kanssa kommunikointi >>
käyttöliittymän yleinen rakenne
• Ongelmallista: käytettävyyssuunnittelijoiden ja
kehittäjien välinen kommunikaatio
– me ja ne muut- ajattelu, erilaiset ajatusmallit
Pirkko Nykänen
31
Summary
• Ketterät menetelmät ja työtavat ovat tulleet jäädäkseen myös
julkishallinnollisten asiakasorganisaatioiden hankkeisiin ja
ketteriä menetelmiä käyttäen on mahdollista saavuttaa hyviä
tuloksia, mutta myös epäonnistuneita lopputuloksia aivan
sanoin kuin perinteisimmillä projektinhallinnan menetelmin
johdetuilla ohjelmistoprojekteilla
• Ketteryys tarkoittaa parhaimmillaan varsin joustavaa
tekemisenmallia, jossa asiakas saa jatkuvasti hyviä tuloksia ja
vastinetta projektityöhön sitomalleen pääomalle ja jossa
toimittaja pystyy hallitsemaan työhön sidottuja resursseja
entistä joustavammin sekä vakuuttamaan asiakkaan paljon
perinteisiä projektinhallinnan menetelmiä tehokkaammin
• Mutta toisaalta huonoimmillaan ketteryys on molemmille
osapuolille riippakivi, josta halutaan eroon ja jolla työn
tuottavuus on kaukana sille asetetuista tavoitteista.
Pirkko Nykänen
32
www.agile.fi
• Agile Finland's mission is to help the
development and application of Agile Software
Development in Finland
• The Agile and Leadership Academy is an
initiative between Agile Finland and University of
Helsinki to bring some of the key practitioners in
our community and some of the best experts
world-wide together. Through a learning process
that will support those of us in the community
that have some years experience with Agile and
are looking for the next step. Check it out in the
site: www.acla.fi