Atte Tuomisto KETTERÄÄN OHJELMISTOKEHITYKSEEN SIIRTYMISEN HAASTEET SUUREN ORGANISAATION NÄKÖKULMASTA
|
|
- Pia Kyllönen
- 8 vuotta sitten
- Katselukertoja:
Transkriptio
1 Atte Tuomisto KETTERÄÄN OHJELMISTOKEHITYKSEEN SIIRTYMISEN HAASTEET SUUREN ORGANISAATION NÄKÖKULMASTA JYVÄSKYLÄN YLIOPISTO 2017
2 TIIVISTELMÄ Tuomisto, Atte Ketterään ohjelmistokehitykseen siirtymisen haasteet suuren organisaation näkökulmasta Jyväskylä: Jyväskylän yliopisto, 2017, 23 s. Tietojärjestelmätiede, kandidaatin tutkielma Ohjaaja: Kollanus, Sami Ketterä ohjelmistokehitys ja ketterät menetelmät ovat kasvattaneet suosiotaan vuosi vuodelta ja niiden menestyksen johdosta myös suuremmat organisaatiot ovat kiinnostuneet niiden käyttöönotosta. Kuitenkin suuri organisaation koko saattaa vaikeuttaa muutosta ketterään ohjelmistokehitykseen, sillä ketterät menetelmät ovat suunniteltu pieniä projekteja ja organisaatioita ajatellen. Näin ollen se tuo organisaation muutokselle uusia haasteita. Tässä tutkielmassa käsitellään ketteryyttä ja sen merkitystä organisaatiolle sekä määritellään mitä suuren mittakaavan ketterällä ohjelmistokehityksellä tarkoitetaan. Tutkimuksessa haluttiin tutkia, mitä muutoksen haasteita organisaatiolla on siirryttäessä ketterään ohjelmistokehitykseen. Tutkielman tulokset osoittavat, että tyypillisimmät haasteet suuren organisaation muutoksessa ketterään ohjelmistokehitykseen olivat muutosvastaisuus, ketteryyden käyttöönoton vaikeus, riittämätön panostus, ketteryyden heikko sisällyttäminen kaikkiin organisaation osiin ja vaatimusmäärittelyyn liittyvät haasteet. Näiden lisäksi haasteina olivat myös yleinen kommunikoinnin ja koordinoinnin haasteet sekä läpinäkyvyyden ylläpitäminen muutoksessa. Asiasanat: ketteryys, ketterät menetelmät, suuri organisaatio, muutos, ohjelmistokehitys
3 ABSTRACT Tuomisto, Atte Challenges in large-scale agile transformations Jyväskylä: University of Jyväskylä, 2017, 23 p. Information Systems, Bachelor s thesis Supervisor: Kollanus, Sami Agile software development and agile methods have been gaining popularity through the recent years and because of their success also the larger organizations have been getting more interest in applying them into their organization. However, the size of the organization might make the transformation more challenging, because agile methods have been designed for small projects and organizations. Therefore, it brings new challenges to the organization's transformation. This research discusses about agile software development, its meaning for organization and define the criteria for large-scale agile and what kind of challenges large organization faces when it is transforming to large scale agile. For the research problem, it has been answered by searching articles with systematic search method. The results showed that the most typical challenges in large-scale agile transformation were change resistance, implement difficulties, not enough investment, implementing agile to other organization functions and challenges with requirements engineering. Also, there were challenges about communication, coordination and transparency. Keywords: large-scale agile, transformation, agile methods, software development
4 TAULUKOT Taulukko 1 Analyysiin valitut lähteet... 15
5 SISÄLLYS TIIVISTELMÄ ABSTRACT TAULUKOT 1 JOHDANTO KETTERÄ OHJELMISTOKEHITTÄMINEN Ohjelmistokehittäminen ja ketterä ohjelmistokehittäminen SUURI KETTERÄ KEHITTÄMINEN JA SIIHEN SIIRTYMINEN Suuri ketterä kehittäminen Suureen ketterään ohjelmistokehittämiseen siirtyminen HAASTEET SIIRRYTTÄESSÄ SUUREEN KETTERÄÄN OHJELMISTOKEHITTÄMISEEN Aineiston keräämisen metodit ja löydetyt havainnot Haasteet siirryttäessä suureen ketterään ohjelmistokehittämiseen Vertaaminen aiempaan tutkimukseen YHTEENVETO JA POHDINTA LÄHTEET... 21
6 6 1 JOHDANTO Ketteryyden ja siihen liittyvien menetelmien alkaminen ohjelmistokehityksessä voidaan ajoittaa noin 1990-luvun loppuun ja 2000-luvun alkuun (Boehm, 2002; Dybå & Dingsøyr, 2008). Vuonna 2001 kirjoitetun Agile manifeston asetettuihin arvoihin ja periaatteisiin pohjautuvaa ajatusmaailmaa käytetään laajalti ohjelmistokehityksessä ja se on kasvattanut suosiotaan vuosi vuodelta (Dingsøyr ym., 2012; Campanelli & Parreiras, 2015). Ketteryyteen liittyvät menetelmät ovat tapa tehdä töitä projektinomaisesti noudattaen tiettyjä asetettuja arvoja ja toimintatapoja (Hamed & Abushama, 2013). Ketteryys on syntynyt vastareaktiona niin sanottujen perinteisten ohjelmistokehityksen malleihin ja niiden tapaan toimia suunnitelmallisesti ja prosessinomaisesti (Dybå & Dingsøyr, 2008). Ketteryydessä korostetaan nopeaa reagoimista muuttuviin ympäristöihin ja ihmiskeskeisyyteen (Nerur ym., 2005). Ketterässä ajatusmaailmassa hyväksytään se, ettei kaikkeen ei voida varautua etukäteen, vaan on pystyttävä mukautuvaan muuttuviin vaatimuksiin ja esiintyviin ongelmiin (Dybå & Dingsøyr, 2008; Campanelli & Parreiras, 2015). Hyvät kokemukset ketterien menetelmien toimivuudesta ja tehokkuudesta on saanut eri suuruiset organisaatiot kiinnostumaan näistä menetelmistä (Dingsøyr & Moe, 2013). Organisaation muuttaminen ketteräksi ja ketterien menetelmien käyttöönottaminen ei ole kuitenkaan helppoa, sillä se vaatii valtavasti panostusta, organisaation kulttuurin muovaamista ja ihmisten muutoksen hyväksymistä (Dybå & Dingsøyr, 2008). Lisäksi näihin menetelmiin siirtymisen haastavuus on liitoksissa myös organisaation kokoon, joka tuo muutokseen lisää haasteita mitä suurempi organisaatio on kyseessä (Kettunen & Laanti, 2008). Suurissa organisaatioissa lisävaikeutta muutokseen aiheuttaa erityisesti erityisempi tarve koordinoinnille ja monimutkaisempi organisaatiorakenne (Olszewska ym., 2016). Siitä huolimatta suurien organisaatioiden kiinnostus ketteryyttä kohtaan on jo viimeistään nyt herännyt ja ketterien menetelmien käyttäminen suuressa mittakaavassa on kasvattanut suosiotaan (VersionOne, 2016, Paasivaara ym., 2014). Vaikka aihealueeseen on kiinnostusta, tutkimus laahaa pahasti käytännön perässä. (Dikert ym. 2016). VersionOnen tekemän vuosittaisen kyselyn (2016)
7 7 perusteella kuitenkin yli puolet vastanneista työskentelivät organisaatioissa, joissa työskentelee vähintään 100 henkilöä, jota voidaan pitää jo melko suurena organisaationa. Järjestetyssä XP2010 konferenssissa tehdyn kyselyn perusteella Freudenberg ja Sharp (2010) tekivät ammatinharjoittajien vastauksista kymmenen halutuinta tutkimuskohdetta. Näistä eniten ääniä sai ketteryys ja suuret projektit. Lisäksi mainintoja sai ketteryyden adoptoiminen organisaatioon. Tarve aihealueen tutkimukselle on siis perusteltua. Tämän tutkielman tarkoituksena on selvittää mitä tarkoitetaan suuren mittakaavan ketteryydellä, mitä siihen siirtyminen vaatii ja mitä haasteita muutosvaiheessa organisaatiolla saattaa esiintyä siirryttäessä ketterään ohjelmistokehittämiseen. Tutkimuksen tavoitteena on lisätä ymmärrystä siitä, mitä suuren organisaation on otettava huomioon silloin kun se on muuttamassa organisaatiotaan käyttämään ketterää lähestymistapaa ja ketteriä menetelmiä. Tämän perusteella kirjallisuuskatsauksen tutkimuskysymykseksi on asetettu seuraava kysymys: Mitä haasteita on raportoitu organisaation muuttuessa suuren mittakaavan ketterään ohjelmistokehittämiseen? Tutkielma koostuu johdannon lisäksi neljästä muusta luvusta. Luvussa 2 käsitellään ketterää ohjelmistokehittämistä ja sen tuomia hyötyjä sekä sen eroja traditionaaliseen ohjelmistokehittämisen. Luvussa 3 määritellään, mitä tarkoitetaan suurella ketterällä kehittämisellä ja käsitellään yleisesti suuren organisaation muutosta ketterien menetelmien käyttöön. Luvussa 4 esitetään tässä tutkielmassa tehdyn systemaattisen aineistonkeruun metodit ja raporttien analysoinnista löydetyt havainnot tämän tutkielman tutkimuskysymykseen ja verrataan löydöksiä aiempaan tutkimukseen. Luvussa 5 on tämän tutkielman yhteenveto ja johtopäätökset, jossa vedetään yhteen tämän tutkielman tärkeimmät kohdat, pohditaan löydöksien merkitystä ja nostetaan niistä tärkeimmät havainnot ja esitetään mahdollisia jatkotutkimuskohteita.
8 8 2 KETTERÄ OHJELMISTOKEHITTÄMINEN Tässä luvussa käsitellään ohjelmistokehitystä ja siihen kuuluvaa ketterää kehittämistä sekä kerrotaan lyhyesti traditionaalisen ja ketterän ohjelmistokehityksen eroista ja ketteryyden hyödyistä. Aluksi luvussa esitellään kaksi lähestymistapaa, joilla ohjelmistokehitystä tehdään, eli traditionaalista ohjelmistokehitystä ja ketterää kehittämistä. Tämän jälkeen näitä verrataan ja lopuksi esitetään lyhyesti mitä etuja ketteristä menetelmistä on verrattuna traditionaalisiin menetelmiin. Nämä asiat luovat ymmärrystä tutkielman aihealueelle, termistölle ja se antaa pohjaa tutkielman varsinaiseen tutkimusongelmaan. 2.1 Ohjelmistokehittäminen ja ketterä ohjelmistokehittäminen Ohjelmistoja on ehditty kehittämään jo muutamia vuosikymmeniä. Tässä ajassa niiden tekemiseen on kehitetty jo lukuisia tekniikoita ja menetelmiä, joiden avulla ohjelmistojen tekemisestä saadaan mahdollisimman tehokasta ja hyvää laatua tuottavaa (Hamed & Abushama, 2013). Yhteistä näille menetelmille kuitenkin on se, että ohjelmistoja tehdään projektinomaisesti tiimeissä (Hamed & Abushama, 2013). Näitä eri tapoja on monia, joista kaksi yleisintä on traditionaaliset menetelmät ja ketterät menetelmät (Dybå & Dingsøyr, 2008). Näihin lähestymistapoihin kuuluu lukuisia erilaisia kehitettyjä viitekehyksiä, jotka antavat raamit toiminnalle. Ne sisältävät esimerkiksi joukon tehtäviä ja vaiheita, joita projektin elinkaaren ajan tulisi projektissa toteuttaa. Näitä viitekehyksiä on esimerkiksi ketteriin malleihin kuuluvat suosituimmat Scrum ja Extreme programming, jotka on kehitetty alan harjoittajien toimesta (Dybå & Dingsøyr, 2008.) Koko tämän vuosituhannen ajan ketterät menetelmät ovat kasvattaneet suosiotaan ohjelmistokehityksen käytössä ja se on alkanut vakiinnuttaa asemaansa alalla (Dingsøyr ym., 2012). Ketteristä malleista ja ketteryydestä eli agilesta on ajan saatossa muodostunut varteenotettava ja suosittu vaihtoehto mainituille traditionaalisille tavoille (VersionOne, 2016).
9 9 Traditionaalisissa lähestymistavoissa tyypillistä on niiden perusteellinen tarvesuunnittelu kehityksen alussa, jonka mukaan projekti viedään läpi ja pyritään siihen, että siitä poikettaisiin mahdollisimman vähän (Highsmith & Cockburn, 2001). Kyseisessä lähestymistavassa tyypillisesti edetään vaihekokonaisuudesta toiseen ja vaiheissa erityisesti korostuu alkuvaiheen tarkka tarvemäärittely ja yleinen prosessikeskeinen luonne. Lisäksi kommunikaatio on usein virallista ja muodollista. Näissä organisaatioissa yleisesti on myös enemmän byrokratiaa (Nerur ym., 2005.) Tässä ajatusmaailmassa on kuitenkin vahvuutensa ja heikkoutensa. Traditionaalisissa lähestymistavoissa perusajatuksena on, että riittävän perusteellisella tarvemäärittelyllä ja suunnittelulla voidaan ennustaa projektin eteneminen ja näin ollen välttää kustannuksia. Tämä tarkoittaa myös sitä, että suunnitelmien muutoksiin projektin aikana suhtaudutaan negatiivisesti (Highsmith & Cockburn, 2001.) Tämänkaltainen ajattelu ei kuitenkaan vastaa muuttuvan maailman tarpeisiin vaan se tekee työskentelystä jäykkää ja vaikeaa (Highsmith & Cockburn, 2001). Koska traditionaalinen lähestymistapa ei sovi hyvin muutoksiin on ketterien mallien käytöstä pyritty löytämään vastaus tähän ongelmaan (Dybo & Dingøyr, 2008). Ketterät menetelmät pohjautuvat vuonna Basili & Turner (1975) kehittämään inkrementaaliseen kehitykseen ja vuonna Fowlerin ja Highsmithin (2001) esittämään Agile manifestoon. Tässä manifestissa määriteltiin arvot ja periaatteet ketterälle ohjelmistokehittämiselle ja ne ovat muodostuneet ketteryyden kulmakiviksi (Dikert ym., 2016; Fernandes & Almeida, 2010). Manifesti koostuu seuraavista neljästä perusarvosta: 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 Ketteryys nähdään siis koko organisaation ajattelutavan ja toimintaperiaatteiden kokonaisuutena, jotka pohjautuvat yllä esitettyihin arvoihin (Misra ym., 2010). Ketteryyttä noudattavassa ajattelumaailmassa on hyväksytty se, että maailma on ennalta-arvaamaton ja suunnittelemattomia muutoksia esiintyy väistämättä. Tämän lisäksi ketteryydessä laitetaan toiminnan keskiöön ennemminkin ihmiset ja ihmisten luovuus kuin tekemiseen kuuluvat prosessit (Dybå, 2000; Nerur ym ) Tähän filosofiaan pohjautuvia ketterän ohjelmistokehityksen menetelmiä on monia. Näillä ketterillä menetelmillä on omat käytänteet ja tekniikat, jotka antavat raamit ohjelmistojen tekemiselle. Näissä viitekehyksissä ja ketteryydessä yleisesti perusideana on, että asioita tehdään lyhyissä iteraatioissa, eli tyypillisesti muutaman viikon mittaisissa kehityssykleissä, joissa pyritään saada aikaiseksi jokin pieni kokonaisuus projektista. Näitä iteraatioita tehdään tarvitta-
10 10 van monta, jotta kehitettävä projekti saadaan valmiiksi (Fernandes & Almeida, 2010; Hamed & Abushama, 2013.) Näistä menetelmistä suosituimmat ovat Scrum ja Extreme Programming (XP) (Hamed ja Abushama, 2013) ja ne käydään seuraavaksi läpi lyhyesti. Scrum on menetelmä, joka on keskittynyt ketterään kehittämiseen projektinhallinnan näkökulmasta (Schwaber and Beedle, 2002). Tällä viitekehyksellä on tukeva asema ohjelmistokehityksen alalla (Hamed & Abushama, 2013; VersionOne, 2016). Se sisältää projektin jatkuvaa monitorointia, tiimityöskentelyn korostamista, henkilökohtaisia tapaamisia ja tehokasta ajanhallintaa. Siihen kuuluu vahvasti myös asiakkaan kanssa käytävä kontakti ja retrospektiiviset tapaamiset, joissa pyritään ehkäisemään ja vastaamaan vastoinkäymiset ja muutokset (Schwaber and Beedle, 2002.) Extreme programming eli XP on toinen suosittu ketterän kehittämisen menetelmä. Se on kehitetty varsinkin pienille tiimeille ja se pyrkii auttamaan ohjelmistokehitysympäristöissä, jossa muutos on jatkuvaa ja vaatimukset epämääräisiä (Beck, 1999). Tässä menetelmässä korostetaan lyhyitä kehityssyklejä, joiden tarkoituksena on pystytä vastaamaan uusiin vaatimuksiin ja parantamaan työn tehokkuutta. XP sisältää monia eri käytänteitä, joihin kuuluu niin pariohjelmointia, jatkuvaa ohjelmistokoodin testausta ja yleistä yksinkertaisuutta (Beck, 1999.) Dybå ja Dingsøyr (2008) mukaan tutkimuksissa on osoitettu, että ketterän ohjelmistokehityksen hyötyjä on esimerkiksi vaikutus asiakkaiden välisen kanssakäymisen parantumisena, parempana virheiden ja ongelmien ratkomisena ja hallitsemisena, työntekijöiden nopeampana oppimisena esimerkiksi pariohjelmoinnilla, parempana tapahtumien ennakoimisena, työn tehokkaampana kohdistamisena ja arviointien parantumisena. Ketteryyden hyvästä soveltuvuudesta ohjelmistokehitykseen ja sen tuomista hyödyistä johtuen on ketterät menetelmät jatkuvassa suosiossa ja ne ovat herättäneet kaiken kokoisten organisaatioiden mielenkiinnon (Dikert ym. 2016).
11 11 3 SUURI KETTERÄ KEHITTÄMINEN JA SIIHEN SIIRTYMINEN Tämän luvun tarkoituksena on määritellä mitä tarkoitetaan suuren mittakaavan ketterällä kehittämisellä (large-scale agile), millä kriteereillä se määritellään ja mitä muutos vaatii suurelta organisaatiolta. Termin määrittely on tärkeää tutkimuksen kannalta ja kriteerien määrittely auttaa tämän tutkimuksen tutkimuskysymykseen vastaamista, antaen rajat sille, mitä organisaatiota kooltaan suurena. 3.1 Suuri ketterä kehittäminen Ketterää ohjelmistokehittämistä suuressa mittakaavassa ei ole tutkittu riittävästi ja sille ei ole vakiintunutta termiä. (Dikert ym., 2016). Myöskään sille millä kriteerillä suuruutta mitataan ei ole yhtenäistä tapaa (Dingsøyr & Moe, 2013). Tämänhetkinen lähin termi aiheelle on large-scale agile. Tälle termille ei ole vakiintunutta suomenkielistä vastinetta, joten tässä tutkielmassa käytetään termiä kuvaamaan suuren mittakaavan ketterää ohjelmistokehittämistä tai yleisesti suurta ketterää kehittämistä. Kuitenkaan siitä mitä termi merkitsee ja mitä se kokonaisuudessaan sisältää ei ole alan tutkimuksissa täyttä selkoa ja yhtenäisyyttä (Dingsøyr & Moe, 2013). Aihealue kuitenkin yleisesti käsittelee organisaation tai projektiin liittyvää suuruutta ketterässä ohjelmistokehittämisessä ja siitä johtuvia ja liittyviä havaintoja (Dikert ym., 2016; Dingøyr & Moe, 2013). Myöskään siitä, millä kriteerillä suuruutta tulisi mitata ei ole yhtenäistä sopimusta. Suuruutta voidaan mitata projektin esimerkiksi kustannusten, lähdekoodin rivien, tiimien lukumäärän, vaatimusmäärän tai ihmismäärän perusteella (Dingsøyr, Fægri & Itkonen, 2014). Dingsøyr, Fægri ja Itkonen (2014) artikkelissaan ovat pyrkineet esittämään luokittelun, jonka perusteella voitaisiin määritellä suuri mittakaava ketterissä projekteissa ja kriteerin, jonka perusteella määrittely tehdään. Kyseisessä raportissa ehdotetaan, että luokittelu tehtäisiin projektien tiimien määrän perusteella. Raportissa ehdotetaan, että pienen ja
12 12 suuren mittakaavan ero olisi se, että jos tiimejä on enemmän kuin yksi, sitä pidettäisiin suuren mittakaavan ketteränä projektina ja jos tiimien määrä on enemmän kuin kymmenen olisi se todella suuren mittakaavan projekti (Dingsøyr ym., 2014). Raportissa sitä perustellaan sen olevan helposti hahmotettavissa. Williams ja Cockburnin (2003) mukaan ketteryyden arvot ja toimet soveltuvat parhaiten alle 50 henkilön organisaatioihin. Samaa on myös todettu muualla ja luokiteltu alle 50 henkilön organisaatiot tai projektit pieniksi (Koehnemann & Coats, 2009). Asiasta on kuitenkin monia mielipiteitä. Dingsøyrin ja Moen (2014) mukaan XP2014 konferenssissa järjestetyn kyselyn perusteella sen käsitys siitä mitä on suuren mittakaavan ketterä kehittäminen (large-scale agile development) vaihteli. Yleisesti se määriteltiin kuitenkin jonain suurena koko organisaation tasoisena asiana ja se määriteltiin käsittävän yli 50 henkilöä, jotka tekevät projekteja käyttäen jotain ketterää menetelmää. Dikert, Paasivaara ja Lassenius (2016) ovat omassa aihealueeseen liittyvässä tutkimuksessaan määritelleet rajan suurelle analysoituaan aihealueen tutkimuksia. Kyseisessä tutkimuksessa määriteltiin suuren mittakaavan ketterä kehitys siten, että organisaatiossa tulee olla 50 henkilöä ja sen täytyy sisältää vähintään kuusi erillistä tiimiä. Näistä kaikkien jäsenten ei tarvitse olla mukana ohjelmistokehityksessä, mutta niiden tulee olla mukana kehitettävän tuotteen elinkaaressa. Näiden havaintojen perusteella voidaan määrittää, että suuruutta määritellään organisaation henkilömäärän perusteella. Karkeana rajana suuren mittakaavan ketteränä ohjelmistokehityksenä voidaan pitää yli 50 henkilöistä organisaatiota. Lisäkriteerinä voidaan pitää myös samaa kriteeriä kuin Dikert ym. (2016) tutkimuksessa eli organisaation tulee sisältää vähintään kuusi erillistä tiimiä, joiden tulee olla mukana kehitettävän tuotteen elinkaaressa. 3.2 Suureen ketterään ohjelmistokehittämiseen siirtyminen Vaikka ketterät menetelmät ovat kasvattaneet suosiotaan niihin siirtyminen ei ole yksinkertaista tai helppoa. Etenkin suurten organisaation muutokset ketteryyteen koetaan haastaviksi (Tessem & Maurer, 2007; Dikert ym., 2016; Boehm, 2006; Dybå & Dingsøyr, 2008.) Kuitenkin niiden hyvien tulosten ja tehokkuuden johdosta niistä ovat kiinnostuneet myös suuret organisaatiot (Dingsøyr, Moe, 2014). Ketteryys ja ketterät menetelmät on kehitetty pieniä tiimejä ja organisaatioita ajatellen (Boehm & Turner, 2005). Näin ollen ne eivät sovellu kovin hyvin suurempiin organisaatioihin (Campanelli & Parreiras, 2015). Ketterät menetelmät eivät yleisesti sellaisinaan sovellu suureen mittakaavaan, vaan niihin on tehtävä räätälöintiä ja niiden käyttöönottoon on käytettävä erityistä huomiota ketteryyden aikaansaamiseksi (Campanelli & Parreiras, 2015). Yleisesti ottaen muutokset suuremmissa organisaatioissa vaativat tarkempaa koordinointia ja
13 13 organisaation koon johdosta sen osat kuten esimerkiksi markkinointi ja myyntiosastot tuovat omat lisävaikeutensa muutokseen (Dikert ym, 2016). Koska ketteryys on nähtävä enemmänkin organisaation ajattelutavan kokonaisena muutoksena ja toimintatapojen muuttamisena, tärkeintä ei ole se, mitä menetelmiä käytetään, vaan että ketteryys omaksutaan organisaation kulttuurin tasolla (Misra ym., 2010). Ketteryydessä ja siihen siirtymisessä on myös otettava huomioon se, ettei se pelkästään vaikuta vain organisaation ohjelmistokehitykseen vaan, että se vaikuttaa myös muihin organisaation osiin (Dikert ym, 2016). Näin ollen organisaation eri osastot ja niiden mahdolliset toiminnot tulisi sovittaa ketteryyteen sopiviksi, jotta kaikki osa-alueet noudattaisivat iteratiivista toimintaperiaatetta (Nerur ym. 2005). Ketteryys vaikuttaa siis organisaation rakenteeseen ja sen kulttuuriin sekä myös sen hallintoon. Samoin se vaikuttaa ihmisiin, niin tiimityöskentelyssä kuin myös asiakkaan kanssakäymisen korostamisena (Dikert ym., 2016). Lisäksi prosessit muuttuvat ominaisuus- ja ihmiskeskeisiksi, joissa asioita tehdään lyhyin, iteratiivisin syklein (Nerur ym. 2005). Yleisesti ero pienen ja suuren organisaation välillä on organisaation monimutkaisempi rakenne ja sen vaativan enemmän koordinointia (Lindvall ym. 2004). Tämän lisäksi suurissa organisaatioissa saattaa olla osia, joissa ei toimita ketterästi ja siitä syystä se vaikuttaa organisaation sisäistä toimintaa (Boehm & Turner, 2005). Näin ollen suuren organisaation muutos on yleisesti hankalampaa kuin pienen organisaation.
14 14 4 HAASTEET SIIRRYTTÄESSÄ SUUREEN KETTE- RÄÄN OHJELMISTOKEHITTÄMISEEN Tässä luvussa käsitellään tämän kirjallisuuskatsauksen tutkimuskysymystä ja siihen löytyneitä vastauksia, eli mitä haasteita on raportoitu muutoksen aikana, kun suuri organisaatio muuttaa toimintaansa käyttämään ketteryyttä ja ketteriä menetelmiä. Ensimmäisessä alaluvussa on esitetty tässä tutkielmassa tehty systemaattisen tiedonhaun menetelmät ja asetetut kriteerit sekä esitetty hausta löytyneet havainnot. Toisessa alaluvussa on esitelty tutkimuksen tulokset ja käyty ne aiheittain tarkemmin läpi. Lopuksi kolmannessa luvussa löydettyjä havaintoja on verrattu aikaisempaan tehtyyn tutkimukseen ja niistä on pyritty löytämään yhtäläisyyksiä ja poikkeuksia. 4.1 Aineiston keräämisen metodit ja löydetyt havainnot Tässä tutkimuksessa valittiin, että asetettuun tutkimuskysymykseen pyrittiin löytämään vastaus käyttäen systemaattista tiedonhakumenetelmää. Tutkimusta tehdessä määriteltiin hakutavat ja kriteerit, joiden perusteella raportteja etsittiin. Raporttien etsimiseen käytettiin hakukonetta, johon syötettiin ennalta määritellyt hakusanat. Hakukoneena käytettiin Google Scholar -hakukonetta ja siihen syötettiin yhteensä 7 eri hakusanaa. Näistä löydöksistä otokseen valittiin hakutulosten löytämät artikkelit, jotka sijaitsivat kolmella ensimmäisellä sivulla. Hakusanoiksi pyrittiin asettamaan muutama mahdollisimman laajakäsitteinen termi ja muutama tarkempi termi sekä valitsemaan myös sanojen synonyymejä, jotta hakutuloksista saataisiin mahdollisimman kattavia ja relevantteja. Hakusanoiksi asetettiin seuraavat termit: agile problems in large organizations, agile scaling challenges, agile transformation, agile transformation challenges, challenges in large agile, large agile software development challenges ja large scale agile challenges. Näillä hakusanoilla raportteja löytyi yhteensä 198 kappaletta. Samojen raporttien karsimisen jälkeen raportteja jäi 80 kappaletta. Tämän jälkeen löydetyt
15 15 artikkelit luettiin manuaalisesti ja ennalta-asetettujen kriteerien perusteella raporteista valikoitiin ne raportit, jotka täyttivät määritellyt kriteerit. Kriteereinä jotta raportti otettiin mukaan käsittelyyn, tuli sen täyttää aiemmassa luvussa asetetut rajaehdot sille, mitä pidetään suurena ketteränä ohjelmistoprojektina. Raporteissa esitetyissä organisaatioissa tuli olla yli 50 työntekijää ja vähintään 6 erillistä tiimiä sekä toiminnan sisältää ohjelmistokehitystä. Muutamia poikkeuksia otettiin myös mukaan analyysiin, joissa ei tarkkaan kerrottu organisaation kokoa, mutta artikkelista pystyi päättelemään organisaation suuren koon. Tämän tehdyn rajauksen jälkeen otoksesta valikoitui 17 artikkelia, jotka täyttivät nämä asetetut kriteerit. Näiden löydösten perusteella tässä tutkielmassa on esitetty havainnot näissä artikkeleissa raportoiduista muutoksen haasteista liittyen suuren mittakaavan ketteryyteen. Löydetyt haasteet on esitetty taulukossa 1. Näistä raporteista löydettyjä haasteita ja niistä tehtyjä yhtäläisyyksiä käsitellään seuraavassa alaluvussa. Taulukko 1 Analyysiin valitut lähteet # Tyyppi Viittaus Koko Menetelmä Esitetyt haasteet 1 Tapaustutkimus Bjarnason ym Scrum IM, P, VM (2011) hlö 2 Tutkimus Xu (2009) - Agile/Scrum VM 3 Haastattelututkimus Sekitoleko ym. +50 hlö Agile/XP IM, P, VM (2014) 4 Haastattelututkimus Paasivaara & Lassenius 170 hlö Scrum MV, IM (2011) / 20t 5 Haastattelututkimus Paasivaara ym. 20 t & Scrum MV, IM (2012) 25 t 6 Haastattelututkimus Paasivaara ym. 400 hlö Agile/Scrum MV, IM (2013) 7 Grounded theory Gandomani ym. +50 hlö Agile MV, IM (2014) 8 Kokemusraportti Fry & Greene - Agile/Scrum MV, IM, P (2007) 9 Kokemusraportti Lindvall ym. (2004) - XP SKO 10 Kokemusraportti Beavers (2007) 10 t Scrum MV 11 Kokemusraportti Benefield (2008) 150 t Scrum MV, IM, P 12 Kokemusraportti Goodman & Elbaz - Scrum P, SKO, VM (2008) 13 Kokemusraportti Lehto & Rautiainen 150 hlö Agile IM, P (2009) 14 Kokemusraportti Maples (2009) 300 t Scrum MV, IM, P, VM 15 Kokemusraportti Hui (2013) 200 Agile P 400 hlö 16 Kokemusraportti Greening (2010) 25 t Scrum IM, SKO, VM 17 Kokemusraportti Ktata & Lévesque (2009) - Scrum IM, VM MV = muutosvastaisuus, IM = implementointi, P = panostus, SKO = sisällyttäminen kaikkiin osiin, VM = vaatimusmäärittely, hlö = henkilöä, t = tiimiä
16 Haasteet siirryttäessä suureen ketterään ohjelmistokehittämiseen Tässä tutkielmassa tehdyn aineistonkeruun ja sen analysoinnin perusteella haasteet muuttaessa suureen ketterään ohjelmistokehitykseen voidaan jakaa seuraaviin kokonaisuuksiin: Muutosvastaisuus, ketteryyden käyttöönoton vaikeus, riittämätön panostus, ketteryyden sisällyttäminen kaikkiin organisaation osiin ja vaatimusmäärittely. Tämän lisäksi on listattuna myös muita huomionarvoisia seikkoja. Tässä luvussa lähdeviittaukset on numeroitu ja niillä viitataan taulukossa 1 esitettyihin artikkeleihin. Jokaisen artikkelin numero on esitetty taulukon 1 vasemmassa laidassa ja lähdeviittaus sijaitsee taulukon viittaus - otsakkeen alla kullakin rivillä. Löydöksiä käydään seuraavaksi läpi tarkemmin. Muutosvastaisuus. Tutkituissa artikkeleissa valtaosassa esiintyi yleistä muutosvastarintaa ja erityisesti muutosvastarintaa esiintyi johdon ja hallinnon osa-alueille. Niissä pelättiin muutoksen heikentävän henkilöiden valtaa ja näin ollen vähentävän näiden kontrollia organisaatiossa (7, 11, 16). Muutosta ei myöskään nähty tarpeellisena, eikä osattu nähdä ketteryyden tuomia hyötyjä vaan siihen suhtauduttiin epäillen (16, 7, 11). Muutosvastarintaa ei kuitenkaan pidetty organisaatioissa ylitsepääsemättömänä haasteena vaan luonnollisena osana muutosta (6, 7). Ketteryyden käyttöönoton vaikeus. Ketteryys koettiin erittäin haastavana integroida omaan organisaatioon ja suureen kokoon (6, 10). Ketterissä menetelmissä esiintyi skaalautuvuusongelmia ja niihin ei osattu varautua eikä tehdä oikeita toimia asian korjaamiseksi (10, 17). Ketteryyden ja siihen liittyvän ajatusmaailman sekä menetelmien ymmärtäminen oli haastavaa. Ei myöskään pitäydytty ketteryydessä vaan siirryttiin ainakin osittain käyttämään vanhoja menetelmiä ketterien menetelmien sijasta (6, 10.) Organisaation muutoksen suuruus ja sen tuoma muutoksen monimutkaisuus oli monesti syynä muutoksen heikkoon aikaansaantiin. Riittämätön panostus. Monessa löydetyssä artikkelissa mainittiin, ettei organisaatiossa otettu muutosta tarpeeksi vakavasti ja siihen ei ymmärretä käyttää riittävästi resursseja (6, 12, 10, 8). Näihin resursseihin ja ongelmakohtiin liittyy henkilöstön kouluttaminen uuteen toimintatapaan ja riittävä ohjaus muutoksessa. Kun koulutusta ja ohjausta ei ollut tarpeeksi se vaikeutti ja hidasti huomattavasti muutosprosessia (6, 7, 8, 11, 14, 15.) Haasteena nähtiin myös, että liian vähäisellä panostuksella oli vaikutusta myös yhteisen vision löytämiseen organisaatossa ja näin ollen se aiheutti motivaatio-ongelmia (6, 17). Ketteryyden sisällyttäminen kaikkiin organisaation osiin. Organisaation koon ollessa suuri, toi se haasteita organisaation muuttamiseen ketteryyteen etenkin muissa organisaation osissa kuin ohjelmistokehityksessä (9, 12, 16). Suurien organisaatioiden toimintojen ollessa monimutkaisia, ei ketteryys ole helppoa omaksua ja muuttaa kaikkiin osa-alueisiin (9). Ei myöskään nähty sitä, että muidenkin osa-alueiden tulisi muuttua käyttämään ketteriä menetelmiä (12,
17 17 16). Nämä muut osiot eivät aina myöskään olleet halukkaita muutokseen tai niiden oli erittäin haasteellista muuttaa toimintatapojaan ketteriksi (12). Vaatimusmäärittely. Ketteriin menetelmiin siirtymisen mukana tuleva jatkuva vaatimusten määrittely asettaa omat haasteensa organisaatiolle. Suuressa organisaatiossa se tuottaa haasteita etenkin kommunikaation ja monimutkaisuuden kanssa (1, 2, 14, 16, 17). Kommunikointi muuttuvissa organisaatioissa saattaa kärsiä ja siten vaikeuttaa vaatimustenmäärittelyä ja näin ollen samalla haitata työn laatua (1, 12). Monesti koettiin, että jo valmiiksi monimutkainen osa toimintaa monimutkaistuu entisestään ja se vaikuttaa työn laatuun ja vain sekoittaa vaatimusmäärittelyn tekemistä (1, 14). Muita huomionarvoisia seikkoja. Lähteistä raportoitiin myös muita haasteita, jotka liittyvät läheisesti jo edellä mainittuihin haasteisiin. Haasteita toi myös koordinointi, joka koettiin haasteelliseksi suurissa organisaatioissa. Koordinointia pidettiin haastavana siitä syystä, että muutoksen aikana oli vaikeaa organisaation muutoksen kokonaiskuvaa ja ei tiedetä missä järjestyksessä ja missä vaiheissa muutosta tulisi suorittaa (4, 6). Lisäksi kommunikaation tärkeys ja organisaation läpinäkyvyys muutoksessa ovat myös olennaisia haasteita. Koettiin, että yrityksessä ei kerrota tarpeeksi muutoksesta ja syistä muutokseen (1, 3, 4). Suurissa organisaatioissa monesti työtä tehdään globaalisti eri tiimeissä. Näin ollen maantieteellinen sijainti aiheuttaa sekin haasteita organisaation muutoksessa ketteryyteen. Näissä esimerkiksi kommunikaatio- ja koordinointihaasteet korostuvat entisestään sekä eri kulttuurit luovat omat haasteensa (2, 6, 9). 4.3 Vertaaminen aiempaan tutkimukseen Löydetyn aineiston lisäksi tässä tutkimuksessa löydettyjen haasteiden vertailukohdaksi on valittu Dikert ym. (2016) tekemä systemaattinen kirjallisuuskatsaus. Kyseinen tutkimus ei esiintynyt tehdyssä systemaattisessa tiedonhaussa, mutta se löytyi yleisessä haussa kirjoitelmaa tehdessä. Tämä tutkimus on laajan lähdeaineistonsa ja sopivuutensa vuoksi otettu mukaan tämän tutkielman käsittelyyn, jotta siinä löydettyjä havaintoja voitaisiin verrata tämän tutkimuksen löydöksiin. Kyseisen kirjallisuuskatsauksen tutkimuskysymyksistä toinen on yhtäläinen tämän kirjallisuuskatsauksen tutkimuskysymykseen. Tämän lisäksi mainitussa tutkimuksessa pyrittiin myös löytämään mahdollisia menestystekijöitä muutoksessa. Kyseisen tutkimuksen löytämiä haasteita voidaan siis tarkastella ja verrata tämän kirjallisuuskatsauksen löytämiin havaintoihin. Kyseisessä tutkimuksessa analysoitiin 1875 artikkelia, joiden perusteella pyrittiin löytämään raportoidut siirtymisen haasteet ja menestystekijät suuren mittakaavan ketteryyteen. Lopulliseksi määräksi muodostui 52 tutkimusta, joista 47 oli konferenssitoimenpiteitä, 4 aikakausilehtijulkaisuja ja yksi tekninen reportaasi. Kyseisessä tutkimuksessa on kerätty lähdeaineistoa käyttäen eri hakukoneita kuin tässä kirjallisuuskatsauksessa ja niissä on käytetty hieman eri-
18 18 laisia hakusanoja. Kyseisessä tutkimuksessa myös todettiin, että artikkeleita etsiessä yksi haaste oli hyvien hakusanojen määritteleminen ja mahdollisten synonyymien takia jotkin tutkimukset saattoivat jäädä sen tästä syystä löytämättä. Näin ollen on mahdollista, että tässä tutkielmassa tehdyllä haulla käyttäen eri hakukonetta ja erilaisia hakusanoja saattaa löydetyistä artikkeleista löytyä jotain uutta tietoa. Havainnot Dikert ym. (2016) tutkimuksessa pääosin yhtäläisiä tässä kirjallisuuskatsauksessa tehdyn analyysin havaintoihin. Yleisin ilmoitettu haaste oli ketteryyden vaikea käyttöönotto ja toiseksi yleisin haaste oli haasteet liittyen ketteryyden sisällyttämiseen organisaation kaikkiin osiin. Samoin myös muutosvastaisuus, panostuksen puute ja vaatimusmäärittely olivat kyseisessä tutkimuksessa yleisiä ilmoitettuja haasteita. Kuitenkin siinä esitettiin myös hieman erilaisia ja tarkempia huomioita esiintyneistä haasteista. Näitä asioita olivat huomiot fyysisten työtilojen muuttamiseen liittyvät haasteet, työnteon itsenäistymiseen liittyvät haasteet, sekä ohjelmistojen testaukseen liittyvät ongelmat projekteissa. Lisäksi tutkimuksen löydöksissä korostettiin, että haasteita organisaatioille toi se, ettei aihealueesta ole kirjallisuutta, jotka auttaisivat esimerkiksi ketterien menetelmien skaalauksesta. Toinen korostettu haaste oli muiden organisaation toimintojen vastustus muutokseen. Kyseisestä tutkimuksesta löytyi muutamia poikkeuksia verrattuna tässä tutkielmassa esitettyihin havaintoihin. Kyseisessä tutkimuksessa kommunikaatioon ja läpinäkyvyyteen liittyviä seikkoja ei esitetty haasteina vaan muutoksen menestystekijöinä. Menestystekijät ja haasteet ovat kuitenkin lähellä toisiaan, joten varsinaisesta poikkeavuudesta ei kuitenkaan ole kyse. Näin ollen näitä tekijöitä voidaan yhtä lailla pitää niin menestystekijöinä kuin myös haasteina.
19 19 5 YHTEENVETO JA POHDINTA Tässä kirjallisuuskatsauksessa tutkittiin mitä haasteita saattaa liittyä siihen, kun suuri organisaatio on muuttamassa ohjelmistokehitystään ketteräksi ohjelmistokehitykseksi. Tutkimuksessa myös pyrittiin määrittelemään, millä kriteereillä suuruutta määritellään. Tutkielman tutkimuskysymykseksi oli asetettu, että mitä haasteita on raportoitu organisaation muuttuessa suuren mittakaavan ketterään ohjelmistokehittämiseen. Tutkimusmenetelmänä käytettiin kirjallisuuskatsausta ja tutkimuksen tutkimuskysymykseen vastaaminen suoritettiin noudattaen systemaattista lähteiden keräämistä ja analysointia. Tutkimuksen lähdeaineisto koostuu pääosin alan tieteellisistä artikkeleista ja muutamista kokemusraporteista. Tutkimuksen keskeiset tulokset voidaan jakaa viiteen eri haasteiden asiakokonaisuuteen. Nämä kokonaisuudet ovat muutosvastaisuus, ketteryyden käyttöönoton vaikeus, riittämätön panostus, ketteryyden sisällyttäminen kaikkiin organisaation osiin ja vaatimusmäärittely. Muutosvastaisuuteen liittyvissä haasteissa muutosvastaisuutta koettiin etenkin johdon ja hallinnon osa-alueilla, sillä pelättiin muutoksen vähentävän näiden valtaa ja kontrollia. Ketteryyden käyttöönottoon liittyviä haasteita oli ketterien menetelmien skaalausongelmat, vanhoihin tapoihin palattiin takaisin ja ettei ketteryyttä ymmärretty oikein. Panostuksen riittämättömyyteen liittyviä haasteita oli, ettei ymmärretty käyttää resursseja riittävästi esimerkiksi koulutukseen, ohjaukseen ja yhteiseen vision luomiseen. Ketteryyden sisällyttäminen muihin organisaation osiin koettiin myös haasteelliseksi. Haasteita tähän toi se, ettei ketteryyttä osattu soveltaa myös organisaation muuhun toimintaa tai sitä ei ylipäätään ymmärretty laajentaa myös näihin organisaation osiin. Viimeisenä kohtana on vaatimusmäärittelyyn liittyvät haasteet, jotka organisaation koon kasvaessa ja ketteryyteen muututtaessa koki haasteita sen tullessa monimutkaisemmaksi ja vaativammaksi kuin ennen. Tämän lisäksi tutkimuksessa löydettiin muita huomionarvoisia seikkoja, jotka liittyvät läheisesti myös yllämainittuihin osioihin. Näitä olivat kommunikaatioon liittyvät haasteet, muutoksen läpinäkyvyyden korostuminen, eri maantieteellisten sijaintien tuomat haasteet ja kirjallisuuden puuttuminen aihe-
20 20 alueesta. Löydetyistä havainnoista on kuitenkin huomattava, että montaa esitettyä muutoksen haastetta esiintyy koosta huolimatta. On silloin siis pohdittava, mitkä näistä muutoksen haasteista mahdollisesti ovat juuri koosta johtuvia haasteita. Seuraavaksi on pyritty esittämään ne haasteet, jotka mahdollisesti ovat koosta johtuvia haasteita. Ensimmäisenä on muutosvastaisuus, jota esiintyy väistämättä muutoksessa. Kuitenkin muutosvastaisuus saattaa olla korostunutta suuremmissa organisaatioissa johdon ja hallinnon osalta, sillä yleisesti ottaen byrokratiaa on enemmän. Johdon saattaa olla vaikeaa nähdä ketteryyden tuomia hyötyjä ja sitä voidaan pitää liian haastavana muutoksena. Voidaan myös pelätä, että se saattaa heikentää johdon asemaa. Toinen koosta riippuva haaste on ketterien menetelmien skaalaushaasteet ja aihealueen heikko kirjallisuus. Koska menetelmiin ei ole toistaiseksi kehitetty riittävästi ohjeita siihen, miten niitä tulisi skaalata ja kirjallisuutta on niukalti aihealueesta, saattaa tämä aiheuttaa haasteita. Kolmantena haasteena on ketteryyden sisällyttäminen muihin osiin kuin ohjelmistokehitykseen. Jos koko organisaatio halutaan ketteräksi, tuo silloin haasteita ne organisaation osat, joissa ei jostain syystä pystytä ketteryyteen. Oletettavasti suuresta koosta johtuen, näitä osioita on enemmän ja ne voivat olla toiminnaltaan monimutkaisempia ja haasteet kasvavat. Neljäntenä on vaatimusmäärittely, joka etenkin projektien kasvaessa muuttuu haastavammaksi. Silloin nykyisillä menetelmillä saattaa olla hankalaa seurata kaikkia projektin vaatimuksia. Lisäksi oletettavasti projektien kasvaessa tiimien ja asianomistajien väliset vaatimusmäärittelyt saattavat heikentyä ja monimutkaistua. Viidentenä voidaan pitää kommunikaatio- ja läpinäkyvyyshaasteita, jotka saattavat korostua organisaation ja projektien kasvaessa. Suuresta koosta johtuen on tärkeää kommunikoida muutoksesta ja suuressa organisaatiossa haasteena on, että kommunikaatiota on riittävästi ja se on tarpeeksi informatiivista, jotta se on läpinäkyvää. Tämä asia saattaa korostua suuressa organisaatiossa enemmän kuin pienessä. Kuudentena voidaan pitää koordinointihaasteita, joiden merkitys oletettavasti kasvaa suurissa organisaatioissa ja projekteissa. Suurten organisaatioiden ja projektien rakenteet ovat monimutkaisemmat ja näin ollen on oletettavaa, että ne tuovat lisähaasteita muutokseen. Aihealue tarvitsee kuitenkin vielä jatkotutkimusta, jotta sen haasteista voidaan olla varmoja. Jatkotutkimusaiheina on yleisesti tapaustutkimukset aihealueeseen liittyen, sillä aihealueesta on erittäin niukasti tutkimusta. Tutkimusta tarvitaan erityisesti myös siitä, millä tavoin ketteriä menetelmiä voidaan skaalata ja mitä eri viitekehyksiä niihin on kehitetty ja miten ne soveltuvat käyttöön. Lisäksi tutkimusta tulisi tehdä myös siitä, mitä haasteita suurissa projekteissa ja organisaatioissa silloin on, kun ne ovat jo muuttaneet toimintansa ketteriksi ja harjoittavat niitä toiminnassaan. Lisäksi suuri ketterä ohjelmistokehitys hajautetuissa organisaatioissa ja projekteissa kaipaa lisää tutkimusta.
21 21 LÄHTEET Basili, V. R., & Turner, A. J. (1975). Iterative enhancement: A practical technique for software development. IEEE Transactions on Software Engineering, SE- 1(4), Beavers, P. A. (2007). Managing a Large "Agile" Software Engineering Organization. Teoksessa Agile Conference (AGILE), 2007 (s ). IEEE. Beck, K. (1999). Embracing change with extreme programming. Computer, 32(10), Benefield, G. (2008). Rolling out agile in a large enterprise. Teoksessa Hawaii International Conference on System Sciences, Proceedings of the 41st Annual (s ). IEEE. Bjarnason, E., Wnuk, K., & Regnell, B. (2011). A case study on benefits and sideeffects of agile practices in large-scale requirements engineering. Teoksessa Proceedings of the 1st Workshop on Agile Requirements Engineering (s. 3). ACM. Boehm, B. (2002). Get ready for agile methods, with care. Computer, 35(1), Boehm, B. (2006). Some future trends and implications for systems and software engineering processes. Systems Engineering, 9(1), Boehm, B., & Turner, R. (2005). Management challenges to implementing agile processes in traditional development organizations. IEEE Software, 22(5), Campanelli, A. S., & Parreiras, F. S. (2015). Agile methods tailoring A systematic literature review. The Journal of Systems and Software, (110), Chandra Misra, S., Kumar, V., & Kumar, U. (2010). Identifying some critical changes required in adopting agile practices in traditional software development projects. International Journal of Quality & Reliability Management, 27(4), Dingsøyr, T., Fægri, T. E., & Itkonen, J. (2014). What is large in large-scale? A taxonomy of scale for agile software development. Teoksessa Jedlitschka, A., Kuvaja, P., Kuhrmann, M., Männistö, T., Münch J. & Raatikainen, M. (toim.), International Conference on Product-Focused Software Process Improvement (s ). Springer International Publishing. Dingsøyr, T., & Moe, N. B. (2013). Research challenges in large-scale agile software development. ACM SIGSOFT Software Engineering Notes, 38(5), Dingsøyr, T., & Moe, N. B. (2014). Towards principles of large-scale agile development. Teoksessa Dingsøyr, T., Moe, N., Tonelli, R., Counsell, S., Gencel, C., Petersen, K. (toim.), International Conference on Agile Software Development (s. 1-8). Springer International Publishing.
22 22 Dingsøyr, T., Sridhar, S., Balijepally, V. G., & Moe, N. B. (2012). A decade of agile methodologies: Towards explaining agile software development. The Journal of Systems & Software, 85(6), Dybå, T. (2000). Improvisation in small software organizations. IEEE Software, 17(5), Dybå, T., & Dingsøyr, T. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 50(9), Fernandes, J. M., & Almeida, M. (2010). Classification and comparison of agile methods. Quality of Information and Communications Technology Fowler, M., & Highsmith, J. (2001). The agile manifesto. Software Development, 9(8), Freudenberg, S., & Sharp, H. (2010). The top 10 burning research questions from practitioners. IEEE Software, 27(5), 8-9. Fry, C., & Greene, S. (2007). Large Scale Agile Transformation in an On- Demand World. Teoksessa Agile Conference (AGILE), 2007 (s ). IEEE. Gandomani, T. J., Zulzalil, H., Ghani, A. A., Sultan, A. B. M., & Sharif, K. Y. (2014). How human aspects impress Agile software development transition and adoption. International Journal of Software Engineering and Its Applications, 8(1), Goodman, D., & Elbaz, M. (2008). "It's Not the Pants, it's the People in the Pants" Learnings from the Gap Agile Transformation What Worked, How We Did it, and What Still Puzzles Us. Teoksessa Agile, AGILE'08. Conference (s ). IEEE. Greening, D. R. (2010). Enterprise Scrum: Scaling Scrum to the executive level. Teoksessa System Sciences (HICSS), rd Hawaii International Conference (s. 1-10). IEEE. Hamed, A. M. M., & Abushama, H. (2013). Popular agile approaches in software development: Review and analysis. Teoksessa Computing, Electrical and Electronics Engineering (ICCEEE), 2013 International Conference (s ). IEEE. Hui, A. (2013). Lean change: Enabling agile transformation through lean startup, kotter and kanban: An experience report. Teoksessa Agile Conference (AGILE), 2013 (s ). IEEE. Kettunen, P., & Laanti, M. (2008). Combining agile software projects and largescale organizational agility. Software Process: Improvement and Practice, 13(2), Kim Dikert, Maria Paasivaara, & Casper Lassenius. (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review. The Journal of Systems and Software, 119, Koehnemann, H., & Coats, M. (2009). Experiences applying agile practices to large systems. Teoksessa Agile Conference, AGILE'09 (s ). IEEE. Ktata, O., & Lévesque, G. (2009). Agile development: Issues and avenues requiring a substantial enhancement of the business perspective in large
23 23 projects. Teoksessa Proceedings of the 2nd Canadian conference on computer science and software engineering (s ). ACM. Laurie Williams, & Alistair Cockburn. (2003). Agile software development: It's about feedback and change. Computer 36 (6), Lehto, I., & Rautiainen, K. (2009). Software development governance challenges of a middle-sized company in agile transition. Teoksessa Proceedings of the 2009 ICSE Workshop on Software Development Governance (s ). IEEE Computer Society. Lindvall, M., Muthig, D., Dagnino, A., Wallin, C., Stupperich, M., Kiefer, D.,... & Kahkonen, T. (2004). Agile software development in large organizations. Computer, 37(12), Maples, C. (2009). Enterprise agile transformation: The two-year wall. Teoksessa Agile Conference, AGILE'09 (s ). IEEE. Nerur, S., Mahapatra, R., & Mangalaraj, G. (2005). Challenges of migrating to agile methodologies. Communications of the ACM, 48(5), Olszewska (née Pląska), M., Heidenberg, J., Weijola, M., Mikkonen, K., & Porres, I. (2016). Quantitatively measuring a large-scale agile transformation. The Journal of Systems & Software, 117, Paasivaara, M., Behm, B., Lassenius, C., & Hallikainen, M. (2014). Towards rapid releases in large-scale xaas development at ericsson: A case study. Teoksessa 2014 IEEE 9th International Conference on Global Software Engineering (s ). IEEE. Paasivaara, M., & Lassenius, C. (2011). Scaling scrum in a large distributed project. Teoksessa 2011 International Symposium on Empirical Software Engineering and Measurement (s ). IEEE. Paasivaara, M., Lassenius, C., & Heikkilä, V. T. (2012). Inter-team coordination in large-scale globally distributed scrum: Do Scrum-of-Scrums really work?. Teoksessa Proceedings of the 2012 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement (s ). IEEE. Paasivaara, M., Lassenius, C., Heikkilä, V. T., Dikert, K., & Engblom, C. (2013). Integrating global sites into the lean and agile transformation at Ericsson. Teoksessa 2013 IEEE 8th International Conference on Global Software Engineering (s ). IEEE. Sekitoleko, N., Evbota, F., Knauss, E., Sandberg, A., Chaudron, M., & Olsson, H. H. (2014). Technical dependency challenges in large-scale agile software development. Teoksessa International Conference on Agile Software Development (s ). Springer International Publishing. Tessem, B., & Maurer, F. (2007, June). Job satisfaction and motivation in a large agile team. Teoksessa Concas G., Damiani E., Scotto M., Succi G. (toim.), International Conference on Extreme Programming and Agile Processes in Software Engineering (s ). Springer Berlin Heidelberg. VersionOne (2016). The 10th annual State of Agile survey. Haettu osoitteesta Xu, P. (2009). Coordination in large agile projects. The Review of Business Information Systems, 13(4), 29.
Tutkittua tietoa. Tutkittua tietoa 1
Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.
Globaalisti Hajautettu Ohjelmistokehitys Mitä, Miksi & Miten? Maria Paasivaara
Globaalisti Hajautettu Ohjelmistokehitys Mitä, Miksi & Miten? Maria Paasivaara Mitä? Mitä? Yrityksen sisäinen Mitä? Yrityksen sisäinen Alihankinta Mitä? Yrityksen sisäinen Open Source -kehitys Alihankinta
Prosessiajattelu. Prosessikuvaukset ja elinkaarimallit. Organisaation prosessikuvaus - CMMI. Sami Kollanus TJTA330 Ohjelmistotuotanto 3.4.
Prosessikuvaukset ja elinkaarimallit Sami Kollanus TJTA330 Ohjelmistotuotanto 3.4. Organisaation prosessikuvaus - CMMI Level5 Level4 Organizational Innovation and Deployment Causal Analysis and Resolution
Prosessiajattelu. Organisaation prosessikuvaus - CMMI. Prosessikuvaukset ja elinkaarimallit. Organisaation prosessien määritys CMMI käytänteet
Organisaation prosessikuvaus - CMMI Prosessikuvaukset ja elinkaarimallit Sami Kollanus TJTA330 Ohjelmistotuotanto 7.2.2007 Level5 Level4 Level3 Requirements Development Technical Solution Product Integration
Tohtorixi. Pasi Tyrväinen , Päivitetty Prof. Digital media
Tohtorixi 9.2. 2004, Päivitetty 9.1. 2005 http://www.jyu.fi/~pttyrvai/papers/tohtorixi.pdf Pasi Tyrväinen Prof. Digital media email: Pasi.Tyrvainen@jyu.fi Tutkinnon sisältö Tohtori Väitöskirja Lisensiaattityö
Käytettävyyslaatumallin rakentaminen web-sivustolle. Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -suunnitelma Timo Laapotti 28.9.
Käytettävyyslaatumallin rakentaminen web-sivustolle Tapaus kirjoittajan ABC-kortti Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -suunnitelma Timo Laapotti 28.9.2005 Kirjoittajan ABC-kortti
Lyhyt johdatus ketterään testaukseen
TTY:n Testauspäivät, Tampere 15.8.2006 Lyhyt johdatus ketterään testaukseen eli Ketterän ohjelmistokehityksen laatukäytäntöjä Juha Itkonen SoberIT Teknillinen korkeakoulu Juha.Itkonen@tkk.fi Ketterä ohjelmistokehitys
Ketterien periaatteiden merkitys projektityössä
Ketterien periaatteiden merkitys projektityössä Suvi Jentze-Korpi Helsinki 18.10.2012 Kandidaatintutkielma-kurssin aine HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Sisältö i 1 Johdanto 1 2 Lineaarinen
Tietojenkäsittelytieteiden koulutusohjelma. Tietojenkäsittelytieteiden laitos Department of Information Processing Science
Tietojenkäsittelytieteiden koulutusohjelma Tietojenkäsittelytieteet Laskennallinen data-analyysi Ohjelmistotekniikka, käyttöjärjestelmät, ihminen-kone -vuorovaikutus Teoreettinen tietojenkäsittelytiede
CMMI CMMI CMM -> CMMI. CMM Capability Maturity Model. Sami Kollanus TJTA330 Ohjelmistotuotanto
CMM Capability Maturity Model CMMI Sami Kollanus TJTA330 Ohjelmistotuotanto 16.1.2007 Software Engineering Institute (SEI) www.sei.cmu.edu Perustettu vuonna 1984 Carnegie Mellon University 1985 SEI aloitti
Network to Get Work. Tehtäviä opiskelijoille Assignments for students. www.laurea.fi
Network to Get Work Tehtäviä opiskelijoille Assignments for students www.laurea.fi Ohje henkilöstölle Instructions for Staff Seuraavassa on esitetty joukko tehtäviä, joista voit valita opiskelijaryhmällesi
CMM Capability Maturity Model. Software Engineering Institute (SEI) Perustettu vuonna 1984 Carnegie Mellon University
CMMI Sami Kollanus TJTA330 Ohjelmistotuotanto 13.3. CMM Capability Maturity Model Software Engineering Institute (SEI) www.sei.cmu.edu Perustettu vuonna 1984 Carnegie Mellon University 1985 SEI aloitti
CMMI CMM -> CMMI. CMM Capability Maturity Model. Sami Kollanus TJTA330 Ohjelmistotuotanto Software Engineering Institute (SEI)
CMMI Sami Kollanus TJTA330 Ohjelmistotuotanto 13.3. CMM Capability Maturity Model Software Engineering Institute (SEI) www.sei.cmu.edu Perustettu vuonna 1984 Carnegie Mellon University 1985 SEI aloitti
KANNATTAVUUDEN ARVIOINTI JA KEHITTÄMINEN ELEMENTTILIIKETOIMINNASSA
LAPPEENRANNAN TEKNILLINEN YLIOPISTO TEKNISTALOUDELLINEN TIEDEKUNTA Tuotantotalouden koulutusohjelma KANNATTAVUUDEN ARVIOINTI JA KEHITTÄMINEN ELEMENTTILIIKETOIMINNASSA Diplomityöaihe on hyväksytty Tuotantotalouden
Software engineering
Software engineering Alkuperäinen määritelmä: Naur P., Randell B. (eds.): Software Engineering: A Report on A Conference Sponsored by the NATO Science Committee, NATO, 1968: The establishment and use of
Tietohallinnon liiketoimintalähtöinen toiminnanohjaus IT-ERP
Tietohallinnon liiketoimintalähtöinen toiminnanohjaus IT-ERP 27.9.2007 Juha Berghäll Efecte Oy juha.berghall@efecte.fi / +358 40 589 5121 Kuka puhuu? z Juha Berghäll z Country Manager Finland z Laaja kokemus
Juuso Järvi KETTERÄN OHJELMISTOKEHITYKSEN MENESTYS- TEKIJÄT
Juuso Järvi KETTERÄN OHJELMISTOKEHITYKSEN MENESTYS- TEKIJÄT JYVÄSKYLÄN YLIOPISTO INFORMAATIOTEKNOLOGIAN JYVÄSKYLÄN YLIOPISTO TIEDEKUNTA INFORMAATIOTEKNOLOGIAN TIEDEKUNTA 2018 2018 TIIVISTELMÄ Järvi, Juuso
Ostamisen muutos muutti myynnin. Technopolis Business Breakfast 21.8.2014
Ostamisen muutos muutti myynnin Technopolis Business Breakfast 21.8.2014 Taking Sales to a Higher Level Mercuri International on maailman suurin myynnin konsultointiyritys. Autamme asiakkaitamme parantamaan
Ketterä projektinhallinta
Ketterä projektinhallinta Petri Heiramo Agile Coach, CST 1 Petri Heiramo Ikä: 37 (vielä pari päivää ) Oma koulutus- ja valmennusyritys, Agilecraft Oy, reilut 3 viikkoa Lähes 10v ohjelmistokehitys- ja -prosessitausta
TietoEnator Pilot. Ari Hirvonen. TietoEnator Oyj. Senior Consultant, Ph. D. (Economics) presentation TietoEnator 2003 Page 1
TietoEnator Pilot Ari Hirvonen Senior Consultant, Ph. D. (Economics) TietoEnator Oyj presentation TietoEnator 2003 Page 1 Sallikaa minun kysyä, mitä tietä minun tulee kulkea? kysyi Liisa. Se riippuu suureksi
Enterprise Architecture TJTSE Yrityksen kokonaisarkkitehtuuri
Enterprise Architecture TJTSE25 2009 Yrityksen kokonaisarkkitehtuuri Jukka (Jups) Heikkilä Professor, IS (ebusiness) Faculty of Information Technology University of Jyväskylä e-mail: jups@cc.jyu.fi tel:
Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO
Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO Opinnäytetyö KESKI-POHJANMAAN AMMATTIKORKEAKOULU Puutekniikan koulutusohjelma Toukokuu 2009 TIIVISTELMÄ OPINNÄYTETYÖSTÄ Yksikkö Aika Ylivieska
Ohjelmistoprojekteista. Datanomiopiskelijat 2.vuosi
Ohjelmistoprojekteista Datanomiopiskelijat 2.vuosi Yleistä projekteista Projekti on selkeästi asetettuihin tavoitteisiin pyrkivä, ajallisesti rajattu kertaluonteinen hanke, jonka toteuttamisesta vastaa
VERSIONHALLINTA. PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D
VERSIONHALLINTA PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D Versio Päivä Tekijä Kuvaus 0.1 26.10.2005 Kaarlo Lahtela Ensimmäinen versio 0.2 10.12.2006 Lauri Kiiski Suomennettu 3 (8 ) SISÄLLYS
Ammatillinen opettajakorkeakoulu
- Ammatillinen opettajakorkeakoulu 2 JYVÄSKYLÄN KUVAILULEHTI AMMATTIKORKEAKOULU Päivämäärä 762007 Tekijä(t) Merja Hilpinen Julkaisun laji Kehittämishankeraportti Sivumäärä 65 Julkaisun kieli Suomi Luottamuksellisuus
Ketteryys pähkinänkuoressa. Kokopäivän Scrum-kurssin sisältö tislattuna ja tiivistettynä kolmeen varttiin
Ketteryys pähkinänkuoressa Kokopäivän Scrum-kurssin sisältö tislattuna ja tiivistettynä kolmeen varttiin Empiirinen prosessinhallinta Iteraatiot ja inkrementit riskienhallinnassa Imuohjaus Ketteryyden
Arkkitehtuuritietoisku. eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä
Arkkitehtuuritietoisku eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä Esikysymys Kuinka moni aikoo suunnitella projektityönsä arkkitehtuurin? Onko tämä arkkitehtuuria?
Prosessien kehittäminen. Prosessien parantaminen. Eri mallien vertailua. Useita eri malleja. Mitä kehitetään?
Prosessien kehittäminen Prosessien parantaminen Sami Kollanus TJTA330 Ohjelmistotuotanto 21.2.2007 Mitä kehitetään? CMMI, SPICE yms. Miten kehittämishanke saadaan toteutettua? Organisaation kehittämisen
Ketteryys kokeilemalla. Leo Malila Kehittämispäällikkö, Kela
Ketteryys kokeilemalla Leo Malila Kehittämispäällikkö, Kela 1.11.2016 Agenda Kelan ICT Ketteryys tavoitteena Teetetyn tutkimuksen ja sen kohteen esittely Havaintoja tutkimuksen perusteella Kelan ketteryys
Kandi/Gradu Tieteellinen (systemaattinen) kirjallisuuskatsaus. Perinteisen kirjallisuuskatsauksen sudenkuopat:
Kandi/Gradu 2016 Risto Hotulainen OKL/Helsingin yliopisto Risto.Hotulainen@Helsinki.fi 3.2.2016 1 Tieteellinen (systemaattinen) kirjallisuuskatsaus Perinteisen kirjallisuuskatsauksen sudenkuopat: 1. Lähteiden
Constructive Alignment in Specialisation Studies in Industrial Pharmacy in Finland
Constructive Alignment in Specialisation Studies in Industrial Pharmacy in Finland Anne Mari Juppo, Nina Katajavuori University of Helsinki Faculty of Pharmacy 23.7.2012 1 Background Pedagogic research
Hankkeiden vaikuttavuus: Työkaluja hankesuunnittelun tueksi
Ideasta projektiksi - kumppanuushankkeen suunnittelun lähtökohdat Hankkeiden vaikuttavuus: Työkaluja hankesuunnittelun tueksi Erasmus+ -ohjelman hakuneuvonta ammatillisen koulutuksen kumppanuushanketta
Menetelmäraportti - Konfiguraationhallinta
Menetelmäraportti - Konfiguraationhallinta Päiväys Tekijä 22.03.02 Ville Vaittinen Sisällysluettelo 1. Johdanto... 3 1.1 Tärkeimmät lyhenteet... 3 2. Konfiguraationhallinnan tärkeimmät välineet... 4 2.1
RANTALA SARI: Sairaanhoitajan eettisten ohjeiden tunnettavuus ja niiden käyttö hoitotyön tukena sisätautien vuodeosastolla
TURUN YLIOPISTO Hoitotieteen laitos RANTALA SARI: Sairaanhoitajan eettisten ohjeiden tunnettavuus ja niiden käyttö hoitotyön tukena sisätautien vuodeosastolla Pro gradu -tutkielma, 34 sivua, 10 liitesivua
Julkaisun laji Opinnäytetyö. Sivumäärä 43
OPINNÄYTETYÖN KUVAILULEHTI Tekijä(t) SUKUNIMI, Etunimi ISOVIITA, Ilari LEHTONEN, Joni PELTOKANGAS, Johanna Työn nimi Julkaisun laji Opinnäytetyö Sivumäärä 43 Luottamuksellisuus ( ) saakka Päivämäärä 12.08.2010
Tietojärjestelmä uusiksi? Toimijaverkostot, niiden haasteet ja ratkaisut
Tietojärjestelmä uusiksi? Toimijaverkostot, niiden haasteet ja ratkaisut Samuli Pekkola Aki Alanne Taru Salmimaa Novi Research Center Tampereen teknillinen yliopisto Sisältö tausta, motiivi ja konteksti
Luottamuksen ja maineen rooli palveluperustaisten yhteisöjen muodostamisessa
Luottamuksen ja maineen rooli palveluperustaisten yhteisöjen muodostamisessa Eija Henritius Helsinki 1.2.2009 Seminaari (työsuunnitelma/tiivistelmä) HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Ryhmädynamiikka ja ketterät menetelmät
Ryhmädynamiikka ja ketterät menetelmät Ohjelmistoprojektien johtaminen ja ryhmädynamiikka 13.2.2018 Fabian Fagerholm Scrumban-tiimin päiväkokous (Flickr, Creative Commons) Johdanto Fabian Fagerholm fabian.fagerholm@helsinki.fi
BIMin mahdollisuudet hukan poistossa ja arvonluonnissa LCIFIN Vuosiseminaari 30.5.2012
BIMin mahdollisuudet hukan poistossa ja arvonluonnissa LCIFIN Vuosiseminaari 30.5.2012 RIL tietomallitoimikunta LCI Finland Aalto-yliopisto Tampereen teknillisen yliopisto ja Oulun yliopisto Tietomallien
Tutkielman rakenne. Tellervo Korhonen. Tutki Hjelt-instituutti Kansanterveystieteen osasto Helsingin yliopisto
Tutkielman rakenne Hjelt-instituutti Kansanterveystieteen osasto Helsingin yliopisto Tutki 2 30.10.2013 1 Periaatteet tieteellisessä tekstissä Tieteellä omat traditionsa Esitystavassa Rakenteessa Perusajatus
Onnistunut ohjelmistoprojekti
Onnistunut ohjelmistoprojekti ICT-ajankohtaisseminaari 15.4.2009 Hermanni Hyytiälä Reaktor Innovations Oy Agenda Yritysesittely Keinoja onnistuneeseen ohjelmistoprojektiin Ihmiset Menetelmät Käytännöt
7. Product-line architectures
7. Product-line architectures 7.1 Introduction 7.2 Product-line basics 7.3 Layered style for product-lines 7.4 Variability management 7.5 Benefits and problems with product-lines 1 Short history of software
Siirtyminen ketterien menetelmien maailmaan! Maarit Laanti 24 October 2013!
Siirtyminen ketterien menetelmien maailmaan! Maarit Laanti 24 October 2013! Sisältö! 1. Tilanne nyt: waterscrumming! 2. Kokonaisvaltainen ketteryys mitä sillä haetaan, mitä sillä saadaan?! 3. Ketterän
On instrument costs in decentralized macroeconomic decision making (Helsingin Kauppakorkeakoulun julkaisuja ; D-31)
On instrument costs in decentralized macroeconomic decision making (Helsingin Kauppakorkeakoulun julkaisuja ; D-31) Juha Kahkonen Click here if your download doesn"t start automatically On instrument costs
Tuotekehitysverkoston läpimenoajan lyhentäminen tuotemuutostenhallinnalla ja verkoston tietojärjestelmien integroinnilla
Tuotekehitysverkoston läpimenoajan lyhentäminen tuotemuutostenhallinnalla ja verkoston tietojärjestelmien integroinnilla Yhteenveto NetData-tutkimusprojektin tuloksista http://www.soberit.hut.fi/netdata/
Kokemuksia eettisen tapauskeskustelun käytöstä Tampereella
Kokemuksia eettisen tapauskeskustelun käytöstä Tampereella 28.3.2019 Tanja Saarela perinnöllisyyslääketieteen el vs. yl Tays perinnöllisyyspoliklinikka Miksi MCD? Terveydenhuollossa työntekijöillä on paljon
Väitöskirjan kirjoittaminen ja viimeistely
1 Väitöskirjan kirjoittaminen ja viimeistely Pekka Kohti tohtorin tutkintoa 19.4.2017 UniOGS 2 Ensimmäinen versio väitöskirjasta Käytä Acta -kirjoituspohjaa Aloita väitöskirjan / yhteenvedon tekeminen
Aineiston analyysin vaiheita ja tulkintaa käytännössä. LET.OULU.FI Niina Impiö Learning and Educational Technology Research Unit
Aineiston analyysin vaiheita ja tulkintaa käytännössä LET.OULU.FI Niina Impiö 14.4.2010 Väitöskirjatutkimuksen tavoite Ymmärtää opettajayhteisöjen yhteisöllistä työskentely- ja toimintakulttuuria. Tutkia
Johdatus tutkimustyöhön (811393A)
Johdatus tutkimustyöhön (811393A) 5 op eli 128 h opiskelijan työtä 6. luento 4.10.2016 Tutkimuksen lähestymistapa osa 3 Kertausta... Miksi tutkimusta tehdään? Tuotetaan uutta tietoa Luodaan uusia käsitteitä
Teollinen Internet & Digitalisaatio 2015
VTT TECHNICAL RESEARCH CENTRE OF FINLAND LTD Teollinen Internet & Digitalisaatio 2015 Jukka Kääriäinen 18.11.2015 VTT, Kaitoväylä 1, Oulu Teollinen Internet & Digitalisaatio 2015 - seminaari Teollinen
Onnistunut ohjelmistoprojekti
Onnistunut ohjelmistoprojekti 2.12.2008 Hermanni Hyytiälä Reaktor Innovations Oy Agenda Yritysesittely Keinoja onnistuneeseen ohjelmistoprojektiin Ihmiset Menetelmät Käytännöt ja työkalut Tulevaisuuden
PSY181 Psykologisen tutkimuksen perusteet, kirjallinen harjoitustyö ja kirjatentti
PSY181 Psykologisen tutkimuksen perusteet, kirjallinen harjoitustyö ja kirjatentti Harjoitustyön ohje Tehtävänäsi on laatia tutkimussuunnitelma. Itse tutkimusta ei toteuteta, mutta suunnitelman tulisi
Estimointityökalut. Pekka Forselius, Senior Advisor Finnish Software Measurement Association FiSMA ry
Estimointityökalut Pekka Forselius, Senior Advisor Finnish Software Measurement Association FiSMA ry 1 Työkalujen rooli ohjelmistotyössä A fool with a tool is still a fool! Ohjelmistotyökalujen käyttäminen
Co-Design Yhteissuunnittelu
Co-Design Yhteissuunnittelu Tuuli Mattelmäki DA, associate professor Aalto University School of Arts, Design and Architecture School of Arts, Design and Architecture design with and for people Codesign
Trialoginen oppiminen: Miten edistää kohteellista, yhteisöllistä työskentelyä oppimisessa?
Trialoginen oppiminen: Miten edistää kohteellista, yhteisöllistä työskentelyä oppimisessa? Tekijä: Sami Paavola, Helsingin yliopisto 1 Muuttaako uusi teknologia oppimista? Miten oppimisen tulisi muuttua?
Skene. Games Refueled. Muokkaa perustyyl. napsautt. @Games for Health, Kuopio. 2013 kari.korhonen@tekes.fi. www.tekes.fi/skene
Skene Muokkaa perustyyl. Games Refueled napsautt. @Games for Health, Kuopio Muokkaa alaotsikon perustyyliä napsautt. 2013 kari.korhonen@tekes.fi www.tekes.fi/skene 10.9.201 3 Muokkaa Skene boosts perustyyl.
Sähkötekniikan tutkintoohjelma. DI-tutkinto ja uranäkymät
Sähkötekniikan tutkintoohjelma DI-tutkinto ja uranäkymät Tervetuloa opiskelemaan sähkötekniikkaa Oulun yliopistoon! ITEE RESEARCH UNITS Tutkinto-ohjelman tuottajat CAS CIRCUITS AND SYSTEMS PROF. JUHA KOSTAMOVAARA
Prognos Julkaisusuunnitelmat
Prognos Julkaisusuunnitelmat Työsuunnitelmiin liittyvien raporttien ja vuosiseminaarien lisäksi suunnitellut julkaisut Casejoryt 09/2005 & JR4 25.1.2005 päivitetty tilanne Casejoryt 04/2006 päivitetty
Kysymys 5 Compared to the workload, the number of credits awarded was (1 credits equals 27 working hours): (4)
Tilasto T1106120-s2012palaute Kyselyn T1106120+T1106120-s2012palaute yhteenveto: vastauksia (4) Kysymys 1 Degree programme: (4) TIK: TIK 1 25% ************** INF: INF 0 0% EST: EST 0 0% TLT: TLT 0 0% BIO:
On instrument costs in decentralized macroeconomic decision making (Helsingin Kauppakorkeakoulun julkaisuja ; D-31)
On instrument costs in decentralized macroeconomic decision making (Helsingin Kauppakorkeakoulun julkaisuja ; D-31) Juha Kahkonen Click here if your download doesn"t start automatically On instrument costs
HAY GROUPIN PALKKATUTKIMUS
HAY GROUPIN PALKKATUTKIMUS 2015 Palkitsetteko kustannustehokkaasti, johdonmukaisesti ja kannustavasti? Ota selvää Hay Groupin palkkatutkimuksen avulla! Varmista palkitsemisenne kustannustehokkuus, sisäinen
Fenomenografia. Hypermedian jatko-opintoseminaari Päivi Mikkonen
Fenomenografia Hypermedian jatko-opintoseminaari 12.12.2008 Päivi Mikkonen Mitä on fenomenografia? Historiaa Saksalainen filosofi Ulrich Sonnemann oli ensimmäinen joka käytti sanaa fenomenografia vuonna
Ammatillisen koulutuksen opettajien liikkuvuus ja osaamisvaatimukset
Ammatillisen koulutuksen opettajien liikkuvuus ja osaamisvaatimukset Matti Taajamo Ammatillisen koulutuksen tutkimusseminaari 21.1.2016 Pedagoginen asiantuntijuus liikkeessä (kansallinen tutkimus- ja kehittämishanke)
Johdattelua, motivointia, eli missä ollaan ja kuinka siihen on tultu
Johdattelua, motivointia, eli missä ollaan ja kuinka siihen on tultu 581259 Ohjelmistotuotanto 1 Ohjelmistotuotanto Kuinka valmistaa laadukkaita ja tehokkaita ohjelmistoja mahdollisimman edullisesti? Ohjelmistotuotanto
Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus
LAADUNVARMISTUS 135 Projektinhallinnan laadunvarmistus Projektinhallinnan laadunvarmistus tukee ohjelmistoprojektien ohjaus- ja ylläpitotehtäviä. Projektinhallinnan laadunvarmistustehtäviin kuuluvat seuraavat:
PROJEKTI- PÄÄLLIKÖSTÄ PRODUCT OWNERIKSI MEERI CEDERSTRÖM
PROJEKTI- PÄÄLLIKÖSTÄ PRODUCT OWNERIKSI MEERI CEDERSTRÖM TAUSTA Otaniemi UX (User Experience) Teknologiaa kaikille Silta tekniikan ja bisneksen välillä Testaaja (Tanska) Scrum Käyttöliittymäsuunnittelija
Ohjelmistoarkkitehtuurit Kevät 2016 Johdantoa
Ohjelmistoarkkitehtuurit Kevät 2016 Johdantoa Samuel Lahtinen http://www.cs.tut.fi/~ohar/ 8.1.2014 1 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3
Tapahtuipa Testaajalle...
Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman
Juha Taina, Marko Salmenkivi ja Kjell Lemström,
Ohjelmistotuotanto Johdattelua, motivointia, eli missä ollaan ja kuinka siihen on tultu Kuinka valmistaa laadukkaita ja tehokkaita ohjelmistoja mahdollisimman edullisesti? Ohjelmistotuotanto (Software
LAADUNVARMISTUS KETTERISSÄ OHJELMISTOKEHITYSMENETELMISSÄ
Henri Kulju LAADUNVARMISTUS KETTERISSÄ OHJELMISTOKEHITYSMENETELMISSÄ JYVÄSKYLÄN YLIOPISTO TIETOJENKÄSITTELYTIETEIDEN LAITOS 2014 TIIVISTELMÄ Kulju, Henri Laadunvarmistus ketterissä ohjelmistokehitysmenetelmissä
Ubicom tulosseminaari
ITEA2 project #11011 2012 2015 Ubicom tulosseminaari Pertti Kortejärvi, Pohto Oy Helsinki 03.10.2013 Taustaa ja tavoitteita Nykyisin monien systeemien (teollisuusautomaatio, kommunikaatioverkot, jne.)
Ville Isomöttönen. Agile. Jyväskylän Yliopisto Sivu 1 Tietotekniikan laitos
Agile Jyväskylän Yliopisto Sivu 1 Tietotekniikan laitos Manifesto of Agile Software Development(2001): We are uncovering better ways of developing software by doing it and helping others doit.throughthisworkwehavecometovalue:
Vertaispalaute. Vertaispalaute, /9
Vertaispalaute Vertaispalaute, 18.3.2014 1/9 Mistä on kyse? opiskelijat antavat palautetta toistensa töistä palaute ei vaikuta arvosanaan (palautteen antaminen voi vaikuttaa) opiskelija on työskennellyt
TT Eija Hanhimäki Helsingin yliopisto
TT Eija Hanhimäki Helsingin yliopisto Väitöskirjaprojekti alkaa Vuoden 2006 alusta Comenius-projektiin tutkijaksi gradu saatava valmiiksi tammikuussa 2006 Valmistuminen teologian maisteriksi 03/2006 Tutkimustyö
Cover letter and responses to reviewers
Cover letter and responses to reviewers David E. Laaksonen, MD, PhD, MPH Department of Medicine Kuopio University Hospital Kuopio, Finland Luennon sisältö Peer review Vinkit vastineiden kirjoittamista
Innovation
Innovation Scout @Tampere3 SCOUT - NEW FRONTIERS 15.5.2018 Business Finland Innovation Scout @Tampere3 Kolmen korkeakoulun yhteisprojekti Yksi ohjausryhmä ja yhteinen sisäinen hallinto/seuranta Työpaketit
ProAgria. Opportunities For Success
ProAgria Opportunities For Success Association of ProAgria Centres and ProAgria Centres 11 regional Finnish ProAgria Centres offer their members Leadership-, planning-, monitoring-, development- and consulting
MUSEOT KULTTUURIPALVELUINA
Elina Arola MUSEOT KULTTUURIPALVELUINA Tutkimuskohteena Mikkelin museot Opinnäytetyö Kulttuuripalvelujen koulutusohjelma Marraskuu 2005 KUVAILULEHTI Opinnäytetyön päivämäärä 25.11.2005 Tekijä(t) Elina
Scrum-käytännöt ja käyttäjäkokemustyö ohjelmistoalan yrityksessä. Marie-Elise Kontro
Scrum-käytännöt ja käyttäjäkokemustyö ohjelmistoalan yrityksessä Marie-Elise Kontro 25.03.2015 Sisältö 1. Tutkimuskysymykset 2. Scrum ja käyttäjäkokemustyö 3. Tutkimusmenetelmä 4. Tulokset 5. Luotettavuuden
NAO- ja ENO-osaamisohjelmien loppuunsaattaminen ajatuksia ja visioita
NAO- ja ENO-osaamisohjelmien loppuunsaattaminen ajatuksia ja visioita NAO-ENO työseminaari VI Tampere 3.-4.6.2015 Projektisuunnittelija Erno Hyvönen erno.hyvonen@minedu.fi Aikuiskoulutuksen paradigman
Käyttäjäkeskeisen suunnittelun sulauttaminen osaksi tuotekehitysprosessia
http://www.cs.tut.fi/ihte http://www.cs.tut.fi/ihte/projects/kaste Käyttäjäkeskeisen suunnittelun sulauttaminen osaksi tuotekehitysprosessia Kati Kuusinen Esityksen sisältö Työn taustasta Työn tavoitteista
Prosessien kehittäminen osa 2
Prosessien kehittäminen osa 2 Sami Kollanus TJTA330 Ohjelmistotuotanto 26.4. SEI:n mukan kolme odotettavissa olevaa ongelmaa Tämä ei sovellu meille Resurssit valuvat prosessien kehittämisestä tärkeämpiin
Prosessien kehittäminen osa 2
Prosessien kehittäminen osa 2 Sami Kollanus TJTA330 Ohjelmistotuotanto 26.4. SEI:n mukan kolme odotettavissa olevaa ongelmaa Tämä ei sovellu meille Resurssit valuvat prosessien kehittämisestä tärkeämpiin
Data Quality Master Data Management
Data Quality Master Data Management TDWI Finland, 28.1.2011 Johdanto: Petri Hakanen Agenda 08.30-09.00 Coffee 09.00-09.30 Welcome by IBM! Introduction by TDWI 09.30-10.30 Dario Bezzina: The Data Quality
BaRE Käyttövalmis vaatimusmäärittelymenetelmä
BaRE Käyttövalmis vaatimusmäärittelymenetelmä Uolevi Nikula, Tietotekniikan osasto, LTKK, Uolevi.Nikula@lut.fi 13.11.2002 un/tsoft 1 Esityksen sisältö Jatko-opinnot Lisensiaatintutkimus BaRE menetelmä
OPPIMINEN ja SEN TUKEMINEN Supporting learning for understanding
OPPIMINEN ja SEN TUKEMINEN Supporting learning for understanding Vetäjät: Jonna Malmberg jonna.malmberg@oulu.fi Tutkimusryhmä: Oppimisen ja Koulutusteknologian Tutkimusyksikkö (LET) LET tutkii (1) Conceptual
Prosessien kehittäminen osa 2. Prosessien kehittämisen haasteita. SEI:n mukan kolme odotettavissa olevaa ongelmaa
SEI:n mukan kolme odotettavissa olevaa ongelmaa Prosessien kehittäminen osa 2 Sami Kollanus TJTA330 Ohjelmistotuotanto 27.2.2007 Tämä ei sovellu meille Resurssit valuvat prosessien kehittämisestä tärkeämpiin
Scrum is Not Enough. Scrum ei riitä. Ari Tanninen & Marko Taipale. Nääsvillen oliopäivä 2009 Tampereen teknillinen yliopisto 9.12.
Scrum is Not Enough Scrum ei riitä Ari Tanninen & Marko Taipale Nääsvillen oliopäivä 2009 Tampereen teknillinen yliopisto 9.12.2009 Ari Tanninen Vanhempi ohjelmistoinsinööri Marko Taipale Teknologiajohtaja,
Ketterä ja asiakaslähtöinen palvelukehitys tietoliikenneteollisuudessa
Ketterä ja asiakaslähtöinen palvelukehitys tietoliikenneteollisuudessa Tommi Luhtala Aalto-yliopiston Sähkötekniikan korkeakoulu Tietoliikennetekniikan laitos Työn valvoja: Prof. Raimo Kantola Työn ohjaaja:
Digitalisaation rakenteellisista jännitteistä. Tero Vartiainen tieto- ja tietoliikennetekniikan yksikkö
Digitalisaation rakenteellisista jännitteistä Tero Vartiainen tieto- ja tietoliikennetekniikan yksikkö Luennon sisältö Digitalisaation perusta Tietojärjestelmätiede ja digitalisaatio Rakenteellinen jännite
Master's Programme in Life Science Technologies (LifeTech) Prof. Juho Rousu Director of the Life Science Technologies programme 3.1.
Master's Programme in Life Science Technologies (LifeTech) Prof. Juho Rousu Director of the Life Science Technologies programme 3.1.2017 Life Science Technologies Where Life Sciences meet with Technology
Project group Tete Work-time Attendance Software
Project group Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: etenemisraportti Versionhallinta BitKeeper-työkalun avulla Tuomas Heino Muutosloki Versio Pvm Tekijä Kuvaus 1.0 01.12.2003
Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistoprosessit ja ohjelmistojen laatu (4op)
581361 Ohjelmistoprosessit ja ohjelmistojen laatu (4op) Ohjelmistojärjestelmien syventävien opintojen kurssi Myös ohjelmistotekniikan profiilin pakollinen kurssi eli ohjelmistotekniikka-aiheisen gradun
Käyttökokemuksen evaluoinnista käyttökokemuksen ohjaamaan suunnitteluun. ecommunication & UX SUMMIT 18.9.2013 Eija Kaasinen, VTT
Käyttökokemuksen evaluoinnista käyttökokemuksen ohjaamaan suunnitteluun ecommunication & UX SUMMIT 18.9.2013 Eija Kaasinen, VTT 2 Hyvä käyttökokemus Laadukas käyttökokemus Ylivoimainen käyttäjäkokemus
Tehostettu kisällioppiminen tietojenkäsittelytieteen ja matematiikan opetuksessa yliopistossa Thomas Vikberg
Tehostettu kisällioppiminen tietojenkäsittelytieteen ja matematiikan opetuksessa yliopistossa Thomas Vikberg Matematiikan ja tilastotieteen laitos Tietojenkäsittelytieteen laitos Kisällioppiminen = oppipoikamestari
A Plan vs a Roadmap. This is a PLAN. This is a ROADMAP. PRODUCT A Version 1 PRODUCT A Version 2. PRODUCT B Version 1.1. Product concept I.
A Plan vs a Roadmap PRODUCT A Version 1 PRODUCT A Version 2 PRODUCT B Version 1.1 This is a PLAN Component A RESEARCH project Development project B COMP. C COMP. B RESEARCH project Product concept I This
Ketteristä menetelmistä ja niiden ryhmädynamiikasta. Ohjelmistotuotantoprojektien johtaminen ja ryhmädynamiikka Fabian Fagerholm
Ketteristä menetelmistä ja niiden ryhmädynamiikasta Ohjelmistotuotantoprojektien johtaminen ja ryhmädynamiikka 25.11.2014 Fabian Fagerholm Tohtorikoulutettava ohjelmistojärjestelmät-linjalla Tutkimusaihe:
Virheraportoijien virhemäärien jakaumat virhetietokannassa
Virheraportoijien virhemäärien jakaumat virhetietokannassa (Valmiin työn esittely) 13.9.2010 Ohjaaja: TkT Mika Mäntylä Valvoja: prof. Harri Ehtamo Yleistä ohjelmistoissa virheitä, jotka estävät ohjelmistojen
Tutkielman teko: kirjallisuus ja rajaus
Tutkielman teko: kirjallisuus ja rajaus Ville Isomöttönen Tieotekniikan laitos Jyväskylän yliopisto TIE-graduseminaari Outline 1 Kirjallisuus tutkimuskysymystä pohdittaessa 2 3 4 Tutkimuskysymystä pohdittaessa