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