Tomi Knuuttila DevOps-käytäntöjen asettamat vaatimukset henkilöstöresursseille Vaasa 2021 Tekniikan ja innovaatiojohtamisen yksikkö Pro gradu -tutkielma Tietojärjestelmätieteen tutkinto-ohjelma 2 VAASAN YLIOPISTO Tekniikan ja innovaatiojohtamisen yksikkö Tekijä: Tomi Knuuttila Tutkielman nimi: DevOps-käytäntöjen asettamat vaatimukset henkilöstöresursseille Tutkinto: Kauppatieteiden maisteri Oppiaine: Tietojärjestelmätiede Työn ohjaaja: Tero Vartiainen Valmistumisvuosi: 2021 Sivumäärä: 63 TIIVISTELMÄ: DevOps on kokoelma käytäntöjä, filosofioita ja työkaluja ohjelmistokehityksen organisoimiksesi. Kyseessä on sateenvarjotermi, joka koostuu useista eri osa-alueista. Se ei tarjoa valmiita työka- luja kuten esimerkiksi ohjelmistokehityksen prosessimallia vaan kokoelman käytäntöjä, joiden avulla sopiva prosessimalli voidaan kehittää. Ne eivät kuitenkaan rajoitu vain ohjelmistokehityk- sen organisoimiseen vaan niiden keskeisenä ideana on organisaation matka kohti oppivaa orga- nisaatiota. Niiden laajamittainen hyödyntäminen vaatii koko organisaation kulttuurinmuutok- sen. DevOps-käytäntöjä hyödyntäville organisaatioille tyypillisiä piirteitä ovat korkea automaa- tion aste, matala organisaatio hierarkia, erilaisten mittareiden aktiivinen seuraaminen, pyrkimys nopeaan reagoimiseen, kommunikaation ja yhteistyön korostunut merkitys sekä ketterien oh- jelmistokehitysmenetelmien hyödyntäminen. Pehmeille taidoille ei ole olemassa yhtä yleisesti hyväksyttyä määritelmää, vaan niiden voidaan- kin katsoa olevan aina sidottuja kontekstiin. Termillä pehmeät taidot tarkoitetaan kuitenkin ylei- sesti ei-kognitiivisia taitoja kuten sosiaalisia taitoja. Tämän lisäksi termin alle mahtuvat henkilö- kohtaiset ominaisuudet, luonteen piirteet sekä yksilön elämänkatsomus. Teknologian kehittymi- sen seurauksena työelämä on murroksessa, jossa toistuvat työtehtävät pyritään automatisoi- maan. Näin organisaatioiden henkilöstöstä yhä pienempi osa työskentelee työtehtävissä, joissa vaaditaan vain kovia taitoja. Sen sijaan yhä suurempi osa työtehtävistä nojaa pehmeisiin taitoi- hin kuten yhteistyökykyyn ja ongelmanratkaisuun. Esimerkkinä tällaisesta muutoksesta on oh- jelmistokehitysorganisaatiot, joissa pyritään hyödyntämään DevOps-käytäntöjä. Muutoksen keskeisenä pyrkimyksenä on parantaa yhteistyön ja kommunikaation astetta kokoamalla monia- laisia tiimejä, joissa eri toiminnot tekevät keskenään yhteistyötä. DevOps-käytäntöjä on tutkittu niiden lyhyen historian aikana varsin runsaasti ja laaja-alaisesti sekä akateemisten- että kaupallistentahojen toimesta. Tästä huolimatta olemassa oleva tutki- mus ei juurikaan ota suoraan kantaa siihen millaisia pehmeitä taitoja DevOps-käytäntöjen kat- tava hyödyntäminen vaatii organisaation henkilöstöresursseilta. Tämä siitäkin huolimatta, että DevOps-organisaatioissa korostuvat erityisesti pehmeät taidot kuten sosiaaliset taidot ja ongel- manratkaisukyky. Tämän tutkimuksen tavoitteena oli selvittää henkilöstöresursseilta vaadittuja pehmeitä taitoja organisaatioissa, joissa pyritään työskentelemään DevOps-käytäntöjen mukai- sesti. Tutkimus suoritettiin systemaattisena kirjallisuuskatsauksena olemassa olevasta DevOps-tutki- muksesta. Sen tavoitteena oli määrittää lista sellaisia pehmeitä taitoja, jotka henkilöstöresurs- seilta vaaditaan DevOps-käytäntöjä hyödyntävässä organisaatiossa. Katsauksessa käytetty tut- kimusaineisto rajatiin käsittämään vain akateeminen DevOps-tutkimus, joka oli saatavilla kah- desta eri tietokannasta. Se suoritettiin käyttäen IS tutkimuksen adaptoitua Fink-mallia. Tutki- muksen tuloksena tutkittavista julkaisuista tunnistettiin 23 kappaletta uniikkeja pehmeitä tai- toja. Tämän lisäksi työn tuloksena syntyi ajantasainen kirjallisuuskatsaus DevOps-käytännöistä. Tutkimuksen tulokset tarjoavat työkalun esimerkiksi oppilaitosten koulutusten suunnitteluun, organisaatioiden henkilöstöhallinnon rekrytointien suunnitteluun sekä tarjoaa pohjan tulevalle tutkimukselle aiheen ympärille. AVAINSANAT: DevOps, henkilöstöresurssit, pehmeät taidot 3 Sisällys 1 Johdanto 6 2 DevOps 9 2.1 Määritelmä 9 2.2 Historia 10 2.3 Osa-alueet 10 2.3.1 Kulttuuri 10 2.3.2 Kommunikaatio 12 2.3.3 Yhteistyö 13 2.3.4 Palautesilmukka 14 2.3.5 Mittarit 15 2.3.6 Automaatio 17 2.3.7 Jatkuva integraatio 19 2.3.8 Jatkuva toimitus 20 3 Pehmeät taidot 22 3.1 Määritelmä 22 3.2 Osa-alueet 22 3.3 Pehmeät taidot ohjelmistokehityksessä 23 4 Menetelmä 24 4.1 Tarkoituksen määrittely 25 4.2 Protokolla 25 4.3 Tutkimuksien haku 26 4.4 Käytännön seula 28 4.5 Laadullinen seula 29 4.6 Katsaus 30 4.7 Tulkinta 31 4.8 Synteesi 35 4.9 Tulokset 51 4 5 Diskussio 53 5.1 Tulosten merkitys 53 5.2 Tulosten luotettavuus 54 5.3 Tulokset suhteessa olemassa olevaan tutkimukseen 55 5.4 Suositukset soveltamiseen 55 5.5 Suositukset tulevalle tutkimukselle 56 5.6 Arviointi 56 Lähteet 57 5 Kuvat Kuva 1 IS tutkimukseen adaptoitu systemaattisen kirjallisuuskatsauksen Fink-malli 24 Kuva 2 Ylä- (merkitty vihreällä) ja alaluokkien (merkitty sinisellä) väliset suhteet. 33 Taulukot TAULUKKO 1. Katsaukseen mukaan otetut julkaisut. 30 TAULUKKO 4. Luokittelun tulokset 32 TAULUKKO 2. Julkaisujen numerointi 36 TAULUKKO 3. Eri julkaisuista löytyneet yläluokat. 37 TAULUKKO 5. Tutkimuksen tulokset 52 Lyhenteet AIS – Association for Information Systems CD – Continuous Delivery CD – Continuous Deployment CI – Continuous Integration IaC – Infrastructure as Code IS – Information Systems 6 1 Johdanto Internet-yhteyksien parantuessa ja teknologian yleistymisen myötä on digitaalisten pal- veluiden ja sisällön tuottamisen merkitys kasvanut. Digitalisaatio on ajanut myös ne or- ganisaatiot, jotka eivät perinteisesti olleet digitaalisten palvelujen tarjoajia ottamaan val- tavaa digiloikkaa niin yksityisellä kuin julkisella sektorilla. Nykyisin valtaosa kuluttajista olettaa palveluiden olevan saatavilla sähköisessä muodossa. Erityisesti nuoremmat su- kupolvet ovat tottuneet asioimaan sähköisesti. (Sosiaali- ja terveysministeriö, 2016, ks.4) Ohjelmistokehityksen rooli onkin muuttunut useissa organisaatioissa puhtaasta tukitoi- minnosta kiinteäksi osaksi organisaation ydintoimintaa. Organisaatioiden tarjoamat ap- plikaatiot ja rajapinnat ovat usein niiden pääasiallinen kommunikaatioväylä asiakkaalle. Tämän lisäksi ohjelmistoja saatetaan käyttää tukemaan toi optimoimaan organisaation oheistoimintoja. (Amazon Web Services, 2021) Erityisesti yksityisellä sektorilla digitaalisten palveluiden tarjoaminen on yrityksille tärkeä kilpailukeino niiden kamppaillessa markkinaosuuksista muiden palveluiden tuottajien kanssa. Digitaalisten tuotteiden ja palveluiden heterogeenin luonne lisää kilpailua enti- sestään kuluttajien pystyessä vaihtamaan palveluiden tarjoajaa pienin tai olemattomin kustannuksin. Kilpailussa pärjäävät parhaiten sellaiset yritykset, jotka kykenevät tuotta- maan parhaita palveluita tehokkaimmin ja toimintavarmasti, samalla reagoiden markki- noiden muutoksiin nopeimmin. (Koch, T., Windsperger, J, 2017) Ohjelmistokehityksen roolin korostuessa on syntynyt tarve pyrkiä tehostamaan organi- saatioiden ohjelmistokehitystä ja digitaalisten palveluiden tarjontaa. Viime vuosina suo- situimmaksi vaihtoehdoksi on noussut DevOps-viitekehys, joka pyrkii virtaviivaistamaan sekä nopeuttamaan digitaalisten palveluiden kehitystä ja julkaisua. Sen kysyntä kasvoi vuoden 2020 aikana 29,4 % ja sille ennustetaan vuoteen 2027 asti 19,9 % vuotuista kas- vua, jolloin sen markkina-arvon ennustetaan olevan 21,4 miljardia. (Global Industry Ana- lysts Inc., 2020) Sen kasvanutta suosiota selittävät tutkimustulokset, joiden mukaan tehokkaimmin De- vOps-käytäntöjä hyödyntävissä organisaatioissa otetaankin uutta koodia käyttöön huo- mattavasti useammin, koodin läpimenoaika on lyhyempi, virheet harvinaisempia ja vir- hetilanteista palautuminen nopeampaa. (DevOps Research & Assestment, 2019, s. 21) 7 Kyseessä on kokoelma käytäntöjä, filosofioita sekä työkaluja, joiden päämääränä on muutos oppivaksiorganisaatioksi iteraation ja jatkuvan oppimisen kautta. Tällainen muu- tos vaati kuitenkin aina kulttuurisen muutoksen, joka koskee koko organisaatiota. (Fors- gren, N., Humble, J. & Kim, G., 2018, s.142–147). Verrattain uusia käytäntöjä onkin tutkittu varsin kattavasti viime vuosien aikana. DevOps yhteisö itsesään on keskittynyt tutkimaan laaja-alaisesti kuinka eri käytännöt vaikuttavat erilaisiin organisaation ulkoisiin ja sisäisiin mittareihin. Aihetta ovat tutkineet niin Piilaak- son suuret teknologia yritykset kuin akateemikot. Laajasta tutkimuksesta huolimatta De- vOps-käytäntöjen asettamat vaatimukset henkilöstölle ovat jääneet pienelle huomiolle. Esimerkiksi DevOps-yhteisössä arvostettuja State of DevOps-tutkimuksia julkaiseva De- vOps Research & Assestment ei ole ole ottanut aiheeseen ollenkaan kantaa monivuotui- sissa tutkimuksissaan. (DevOps Research & Assestment, 2021) DevOps kulttuuri rakentuu muurien murtamisen, avoimuuden, itseohjautuvuuden, luot- tamuksen, yhteistyön, kommunikaation, jatkuvan oppimisen ja psykologisen turvallisuu- den varaan. Perinteisesti kuitenkin ohjelmistotuotannon eri osa-alueet on vahvasti ero- teltu toisistaan. Tällainen asetelma synnyttää helposti kitkaa tuotantoketjun eri osien vä- lille. Ongelman purkamiseksi ei kuitenkaan riitä, että eri toimet liitetään toisiinsa organi- saatiokaaviossa. Sen sijaan tarvitaan kulttuurinmuutosta. Tällainen muutosprosessi on kuitenkin hidas sekä altis vaikutteille ja vaatii aina koko organisaation sitoutumisen. Eri- tyisen tärkeää on organisaation johdon sitoutuminen muutokseen. (Ravichandran A., Taylor K., Waterhouse P., 2016, s. 26–33) On kuitenkin selvää, että kommunikaatiota, avoimuutta ja yhteistyötä korostavaa kult- tuuria ei ole mahdollista rakentaa ilman pehmeitä taitoja. Niiden merkitys korostuu kult- tuurin lisäksi myös eri toimintojen välisessä yhteistyössä. Pehmeiden taitojen roolia ei kuitenkaan ole perinteisesti korostetut teknisessä koulutuk- sessa, vaan niissä on sen sijaan keskitytty kovien taitojen kehittämiseen. Niiden merkitys nousee kuitenkin esille erityisesti, kun organisaatioissa pyritään lisäämään yhteistyötä eri toimintojen välillä tai työskennellessä organisaation sidosryhmien kanssa. (Bancino & Zevalkink 2007) 8 Tässä tutkimuksessa keskitytään siihen, millaisia pehmeitä taitoja DevOps-viitekehys vaatii organisaation henkilöstöltä. Näin tutkimuksen tutkimuskysymykseksi muodostuu: Millaisia pehmeitä taitoja DevOps-organisaation henkilöstöltä vaaditaan DevOps-viitekehyksen yleistyessä ja sen merkityksen kasvaessa tämän tiedon tärkeys ko- rostuu entisestään. Sitä voidaan hyödyntää oppilaitosten koulutusohjelmia suunnitelta- essa, organisaatioiden henkilöstöhallinnossa koulutuksia suunniteltaessa sekä rekrytoinnissa, konsultaatiota tarjoavissa yrityksissä sekä tulevassa tutkimuksessa. Näiden taitojen ymmärtämisen merkitys korostuu erityisesti organisaatioissa, joissa kult- tuurinmuutosprosessi on vasta alkamassa. Erityisesti pienemissä organisaatioissa yksit- täinenkin virheellinen rekrytointi saattaa vaarantaa koko kulttuurinmuutoksen tai aina- kin hidastaa prosessia merkittävästi samalla vaikuttaen organisaatioiden ydintoimintojen tehokkuuteen. Näiden riskien välttämiseksi on ensiarvoisen tärkeää ymmärtää millaisia pehmeitä taitoja DevOps vaatii organisaatioiden henkilöstöltä. 9 2 DevOps DevOps on kokoelma ohjelmistokehityskäytäntöjä, filosofioita ja työkaluja ohjelmistoke- hityksen ongelmakohtien ratkaisemiseksi. Se ei tarjoa valmista prosessimallia tai ratkai- suja siihen, kuinka organisaation toiminta tulisi organisoida. Se voidaankin mieltää työ- kalupakiksi, josta löytyvien työkalujen avulla organisaatiot voivat suunnitella ja rakentaa juuri heidän tarpeisiinsa sopivan ratkaisun. DevOps-viitekehyksen sisältämät käytännöt, filosofiat ja työkalut eivät ole uusia. Sen sijaan ne ovat hyväksi koettuja, testattuja, tut- kittuja ja toimiviksi todettuja ja yhteensopivia. Termin DevOps-alta löytyy useita erilaisia tapoja tehdä asioita, ja viitekehys itsessään ei ota kantaa siihen millaiset ratkaisut sopivat mihinkin organisaatioon tai tilanteeseen. 2.1 Määritelmä Termille DevOps ei ole olemassa yksiselitteistä yleisesti hyväksyttyä määritelmää. Sille on sen lyhyen historian aikana yritetty tarjota useita erilaisia määritelmiä. Esimerkiksi Jab- bari, Ali, Petersen, Tanveer (2016, s.8) ehdottavat määritelmää: DevOps is a development methodology aimed at bridging the gap between Devel- opment and Operations, emphasizing communication and collaboration, continu- ous integration, quality assurance and delivery with automated deployment utiliz- ing a set of development practices. Toisaalta Dyck, Penners, Lichter (2015) määrittelevät sen organitorisena ilmiönä: DevOps is an organizational approach that stresses empathy and cross-functional collaboration within and between teams – especially development and IT opera- tions – in soft are development organizations, in order to operate resilient systems and accelerate delivery of changes. Kun taas Davis ja Daniels (2016) määrittelevät sen kulttuurillisesta näkökulmasta: Devops is a cultural movement that changes how individuals think about their work, values the diversity of work done, supports intentional processes that accelerate the rate by which businesses realize value, and measures the effect of social and technical change. It is a way of thinking and a way of working that enables individ- uals and organizations to develop and maintain sustainable work practices. It is a 10 cultural framework for sharing stories and developing empathy, enabling people and teams to practice their crafts in effective and lasting ways. Yhteistä näille määritelmille on kuitenkin se tavoitetila, johon DevOps-käytäntöjen sovel- tamisella pyritään. Lopullisena tavoitteena on aina tehostaa organisaation ohjelmisto- tuotannon laatua, vakautta ja reaktiokykyä. Muita yhtäläisyyksiä ovat korkean automaa- tion asteen korostaminen, jatkuva integraatio, jatkuva julkaisu, yhteistyö ja kommuni- kaatio. DevOps-käytäntöjen soveltaminen on aina askel kohti oppivaa organisaatiota lo- puttoman iteroinnin ja jatkuvan oppimisen kautta. Ei ole olemassa yhtä yksiselitteistä ratkaisua, joka sopisi jokaiseen organisaatioon. Tässä tutkimuksessa käytetään löyhää määritelmää termille DevOps: kyseessä on koko- elma ohjelmistokehityskäytäntöjä, filosofioita ja työkaluja, joita hyödyntämällä organi- saatiot pyrkivät tehostamaan ohjelmistokehitystä. 2.2 Historia Termin DevOps historia alkaa vuodesta 2009 kun Andrew Clay Shafer tiivisti otsikon ”10+ Deploys per Day: Dev & Ops cooperation” hashtagiin #devops Twitterissä, ilmaistakseen seuraavansa vuoden 2009 O’Reily – Velocity konferenssia, vaikka ei itse fyysisesti ollut- kaan paikalla. Vastauksena tähän viestiin Pris Nasrat ehdotti, että Shafer voisi järjestää oman konferenssinsa Belgiassa. Tästä seuranneen keskustelun seurauksena päädyttiin järjestelmään ensimmäinen DevOpsDays-konferenssi, joka keskittyi erityisesti ohjelmis- tokehityksen ja operatiivisen-IT:n yhteistyölle. Tämän tapahtumasarjan seurauksena jär- jestettiin ympäri maailmaa lukuisia DevOpsDays-tapahtumia ja konsepti alkoi elää omaa elämäänsä. (Davis, Daniels, 2016, s.28 – 29) 2.3 Osa-alueet 2.3.1 Kulttuuri Kulttuurin arvo nostetaan DevOps-viitekehyksessä korkealle. Jokaisen organisaation kult- tuuri on aina yksilöllinen. Näin ollen myös DevOps-organisaatioiden kulttuurit ovat 11 yksilöllisiä ja sidottuja tarkasteltavaan organisaatioon. On kuitenkin olemassa sellaisia kulttuurin piirteitä, joiden voidaan katsoa olevan osa DevOps-organisaatiokulttuuria. Or- ganisaatiot, jotka pyrkivät toimimaan viitekehyksen mukaisesti tavoittelevat näitä teki- jöitä tai saavuttavat ne riippuen siitä missä vaiheessa muutosprosessia kohti oppivaa or- ganisaatiota ne ovat. DevOps-organisaatiokulttuurissa pyritään suosimaan yhteistyötä yksilöiden jalustalle nostamisen sijaan. Yhteisiin tavoitteisiin pyritään tekemällä yhteistyötä jatkuvien iteraa- tioiden kautta. Tavoitteita mitataan aktiivisesti ja niiden avulla pyritään parantamaan eri osa-alueita aina asiakastyytyväisyydestä uusien ohjelmistoversioiden läpimenoaikaan. Jatkuvien iteraatioiden aikana pyritään oppimaan matkalla, kuinka organisaation toimin- taa voitaisiin parantaa. Haitalliseksi katsottua toimintaa kuten vastuun välttelyä, vir- heistä rankaisemistä, syyllisten etsimistä ja niiden rankaisemista pyritään välttämään. Näitä asioita pyritään välttämään useammastakin eri syystä. Koska kyseessä organisaa- tion yhteinen pyrkimys kohti oppivaa organisaatiota tulee virheistä pyrkiä oppimaan sen sijaan että niistä rangaistaisiin. Tällä tavalla muodostuu tilanne, jossa organisaation jäse- net eivät uskalla toimia koska pelkäävät aina rangaistuksia ja tämä syö resursseja, henki- löstön moraalia ja poistaa mahdollisuuden oppimiseen. (Ravichandran, Taylor, Water- house, 2016) Psykologinen turvallisuus onkin erityisen tärkeää DevOps-kulttuurissa, sillä se mahdollis- taa tehokkaan ryhmätyöskentelyn, innovaation ja avoimen tiedon kulun. Psykologisella turvallisuudella tarkoitetaan sitä, ettei ketään rangaista sen perusteella, että hän jakaa ideoita, kysyy jotain tai nostaa esiin ongelmia ja huolenaiheita. Tällaisessa ympäristössä henkilöstö uskaltaa ottaa riskejä ja asettaa itsensä haavoittuvaan tilaan, luottaen siihen, etteivät muut hyväksikäytä hänen potentiaalisesti haavoittuvaa asemaansa. Tämä edes- auttaa oppimista sekä yksilön että organisaation tasolla, tehostaa organisaation tiedon- kulkua ja sitä kautta toimintaa. Organisaatiossa, jossa vallitseva tila ei ole psykologisesti turvallinen henkilöstö ei uskalla tuoda esiin mielipiteitään, ottaa riskejä sekä epäröi heille epäsuotuisan tiedon jakamisen suhteen. Tämä johtaa kommunikaatiokatkoksiin ja siitä aiheutuviin ongelmiin, innovaation vähentymiseen sekä heikentää yhteenkuuluvuuden 12 tunnetta. Psykologisen turvallisuuden kulttuuri vaikuttaakin suoraan organisaation te- hokkuuteen. (Davis & Daniels, 2019, s.4; DevOps Research & Assessment, 2019, s.54) 2.3.2 Kommunikaatio Yhteistyön edellytyksenä on tehokas kommunikaatio. Kommunikaatio auttaa ihmisiä ym- märtämään toisiaan paremmin ja mahdollistaa tiedon kulkemisen organisaatiossa. Tä- män lisäksi se auttaa ihmisiä ymmärtämään toisiaan ja auttaa löytämään yhteisiä näkö- kantoja sekä edesauttaa yhteistyön kulttuurin ja yhteisön muodostumisessa. (Davis & Daniels, 2019, s.5) Samalla se lisää yksilöiden ja yhteisön yhteenkuuluvuuden tunnetta. Tämä yhteenkuulu- vuuden tunne vaikuttaa olennaisesti siihen mitä yksilöt ja yhteisö kestävät vastoinkäymi- siä. Samalla se edesauttaa tiedon kulkemista organisaatiossa. Kommunikaatiolla onkin suuri merkitys ymmärryksen lisäämisessä sekä yksilö että organisaatiotasolla. Sen avulla organisaatiossa voidaan jakaa tietoa ja oppia muilta. Tämä on erityisen tärkeää sellaisen tiedon kannalta, joka elää vain organisaation sisällä dokumentaation ulkopuolella eli niin sanotun hiljaisen tiedon kannalta. Tällainen tieto on kuitenkin usein todella merkittä- vässä roolissa, sen avulla organisaatiossa voidaan oppia historiasta ja välttää toistamasta virheitä, jotka on jo kertaalleen tehty. Kommunikaatio on myös merkittävässä roolissa organisaation henkilöstön hyvinvoinnin ja motivaation kannalta. Jotta yksittäinen orga- nisaation jäsen tuntisi olevansa arvostettu yhteisön jäsen tulee hänen saada positiivista palautetta työstään. Erityisen tärkeää positiivinen palaute on sellaisina ajankohtina, kun yhteisön jäsenen työpanos on ollut suuri, tämä on tehnyt jotain tavallisesta poikkeavaa, oppinut jotain tai muutoin ylittänyt itsensä. Tällaiset hetket ovat merkittäviä yhteisön jäsennelle itselleen ja samalla tarjoavat mahdollisuuden palkita työpanoksesta lisäten näin todennäköisyyttä, että vastaavaa tapahtuu myös tulevaisuudessa. (Davis & Daniels, 2016, s. 90) 13 2.3.3 Yhteistyö Yhteistyö määritellään prosessiksi, jonka aikana ryhmä ihmisiä työskentelee yhdessä saa- vuttaakseen ennalta määrätyn tavoitteen tai määränpään. Termi DevOps syntyi vuonna 2009 kuvaamaan ohjelmistokehityksen (development) ja ylläpidon (operations) yhteis- työtä. Edelleen eri toimintojen välinen yhteistyö on olennainen osa DevOps-käytäntöjä. On kuitenkin painotettava, että yhteistyö ei rajoitu vain ohjelmistotuotannon ja ylläpidon yhteistyöhön vaan se voi koskea mitä organisaation toimintoa logistiikasta markkinoin- tiin. Yhteistyö rakentuu päivittäisissä kohtaamisissa, yhteisissä tavoitteissa, osallistumi- sessa, sekä organisaation tavoissa. Erilaisia yhteistyön ilmentymiä ovat esimerkiksi koo- din katselmointi, tilanne päivitykset tai viikoittaiset demot, jossa esitellään omaa työtä muille. (Davis & Daniels, 2016, s.63 – 71) Yhteistyö DevOps-tiimissä voidaan jakaa kolmeen eri vaiheeseen: tutkimus, implemen- tointi ja julkaisu. Tutkimus vaiheen aikana kehitystiimi keskittyy suunnittelemaan mitä seuraavan ohjelmistokehitysiteraation aikana tehdään. Tämän vaiheen aikana keskity- tään suunnittelemaan, keräämään vaatimusmäärittelyjä, käydään läpi arkkitehtuurillisia ratkaisuja ja suunnitellaan tulevaa ohjelmistokehitystä. Tämän vaiheen aikana tiimi saat- taa tehdä kattavasti yhteistyötä eri toimintojen kanssa varmistaakseen, että muutos on linjassa muun organisaation toiminnan kanssa. Jos kehitettävällä ominaisuudella on riip- puvuuksia organisaation muihin toimintoihin, on tärkeää, että näiden tarve selvitetään tässä vaiheessa ja resurssien jakamisestä sovitaan etukäteen. Onkin olennaista, että kommunikaatio toimii myös organisaation muiden toimintojen välillä. Tutkimusvaihetta seuraa implementaatiovaihe, jonka aikana edellisessä vaiheessa tehty suunnitelma toteutetaan. Ohjelmistokehityksen aikana voi esiintyä useita erilaisia yh- teistyön muotoja. Kirjoitettava koodi tulee liittää samaan lähteeseen versionhallinnassa. DevOps-kontekstissa tämä tarkoittaa jatkuvaa integraatiota. Siinä kehittäjät luovat omia kehityshaarojaan kehitettävän ominaisuuden luomiseksi. Kun työ on valmis, kehitetty koodi testataan yhdessä sovittujen käytäntöjen mukaisesti. Sen jälkeen se käy läpi koo- dinkatselmointi vaiheen, jossa ennalta sovittu määrä muita tiimin kehittäjiä lukee koodin läpi antaen palautetta ja korjausehdotuksia. Kun ehdotetut korjaukset on suoritettu, se hyväksytään yhteispäätöksellä ja liitetään versionhallinnan päähaaraan, josta se on 14 muiden kehittäjien saatavilla. Jos ohjelmistokehityksen aikana ilmenee ongelmia niistä, keskustellaan ja ongelmakohtia pyritään ratkomaan yhdessä. Ohjelmistokehityssyklin jäl- keen tiimi läpikäy edellisen syklin retrospektiivipalaverissa, jossa pohditaan, mikä meni huonosti ja mikä hyvin. Näiden pohdintojen ja löydösten perusteella pyritään oppimaan ja parantamaan prosessia ennen seuraavaa ohjelmistokehityssykliä. Implementaation jälkeen siirrytään julkaisuun. Tämä vaihe ei välttämättä tapahdu ajalli- sesti ohjelmistokehityssyklin jälkeen vaan se voi tapahtua sen aikana jatkuvan julkaisun periaatteen mukaisesti. Jatkuvan kommunikaation periaatteen mukaisesti jokaisen tii- min jäsenen tulee olla tietoinen tapahtuvista julkaisuista. DevOps-viitekehyksen mukai- sesti vastuu kehitettävästä ohjelmistosta ja sen ylläpidosta on kuitenkin aina tiimin har- teilla, joten julkaisun jälkeen tiimi on vastuussa sen ylläpidosta. Ylläpitoa varten tiimin tulee määritellä yhteiset säännöt, miten sen suhteen toimitaan. Jos tiimin jäseniä on tar- peeksi, voidaan taata, että joku on aina tavoitettavissa. Tätä varten tuleekin sopia vuorot, joiden aikana sovitut tiimin jäsenet ovat tavoitettavissa. Näin voidaan samalla mento- roida tuoreita tiimin jäseniä ja lievitetään vaativan tilanteen luomaa stressiä. Vikatilan- teet tulee myöhemmin yhdessä läpikäydä post mortem-käytännön mukaisesti. Siinä vi- katilanne läpikäydään huolellisesti juurisyiden selvittämiseksi ja dokumentoidaan. Kun syy on selvinnyt, suunnitellaan ratkaisu, jotta tällainen vika voidaan välttää tulevaisuu- dessa. Olennainen osa tätä käytäntöä on opitun tiedon jakaminen kaikille, jotta siitä opi- taan kollektiivisesti. (Davis, Daniels, 2019, s.19 – 31) 2.3.4 Palautesilmukka Nopea adaptoituminen muuttuviin vaatimusmäärittelyihin ja loppukäyttäjien palauttee- seen samanaikaisesti pysyen laadukkaana ja luotettavana on oleellinen tapa ohjelmistoja ja IT-palveluja tuottaville yrityksille luoda kilpailuetua. DevOps-organisaatioissa pyritään saavuttamaan kaikkia näitä osa-alueita järjestelemällä prosesseja uudelleen sekä hyö- dyntämällä kattavasti ohjelmistoautomaatiota. Tähän pyritään, jotta loppukäyttäjältä ke- hittäjille tulevaan palautteeseen pystyttäisin reagoimaan mahdollisimman nopeasti. Pa- lautteeseen reagoimiseen vaikuttaa kaksi asiaa: kuinka nopeasti palaute saavuttaa kehit- täjän ja kuinka suuri julkaistu muutos oli. Mitä nopeammin palaute tavoittaa kehittäjän, 15 sitä nopeammin kehittäjän on mahdollista reagoida siihen. Palautteeseen reagoiminen on aina sitä helpompaa mitä nopeammin se saavuttaa kehittäjän. Jos muutoksesta on kulunut jo aikaa, joutuu kehittäjä palaamaan siihen mitä on tehty aiemmin ja pohtimaan ovatko sen jälkeen tehdyt muutokset saattaneet vaikuttaa asiaan. Mitä pienempi edelli- nen muutos oli sitä tarkemmin kehittäjät voivat arvioida mitä saatu palaute tarkoittaa. Nopea ja pienet muutokset mahdollistavatkin esimerkiksi A/B-testauksen. (Forsgren, Humble. & Kim, 2018, s.48) Jokainen muutos vakaaseen järjestelmään on kuitenkin aina riski. Vaikka DevOps-käytän- töjen mukaisesti kehittävän ohjelmisto testataan automatisoidusti ei voida taata, ettei muutos aiheuttaisi ongelmia tuotannossa. Testikattavuus ei välttämättä riitä kattamaan jokaista järjestelmän osaa tai testeissä itsessään on virheitä. Osa ongelmista saattaa esiintyä viiveellä tai niiden havaitseminen vie aikaa. Järjestelmän systemaattinen tark- kailu, analysointi ja läpikäyminen on kuitenkin aikaa vievää sekä altista inhimillisille vir- heille. Tämän takia automaation hyödyntäminen järjestelmän tilaa tulee tarkkailla jatku- vasti hyväksikäyttäen ohjelmistoautomaatiota. Jos järjestelmässä esiintyy poikkeavuuk- sia tai vikatiloja, voidaan ohjelmistoautomaation keinoin vaihtaa jaettava ohjelmistover- sio vanhempaan tai kerätään dataa, jota voidaan hyödyntää järjestelmän korjaamisessa. Jos ongelma esiintyy vain tietyissä olosuhteissa, on sen paikallistaminen hidasta ja vai- keaa ilman olemassa olevaa tietoa siitä millaisissa olosuhteissa ongelma esiintyy. Tämän järjestelmän tavoitteena on tarjota palautesilmukka DevOps-tiimille, joka mahdollistaa reagoimisen järjestelmässä esiintyviin virheisiin mahdollisimman nopeasti, vaikka niitä ei havaittaisi testauksen aikana. Virheiden etsiminen ja korjaus on kallista ja aikavievää työtä, joka vaikeutuu mitä pidempi aika virheen syntymisestä on. Jos virhettä ei huomata ajoissa voi sen jälkeen tapahtua useita julkaisuja, joka vaikeuttaa oleellisesti virheen et- simistä. (Figalist, Biesdorf, Brand, Feld ja Kiermeier, 2019, s. 1) 2.3.5 Mittarit Jotta asioita voidaan kehittää, tulee niitä pystyä mittaamaan luotettavasti. Tämän lisäksi on olennaista ymmärtää mitä asioita mitataan sekä syy-seuraussuhteet, jotka vaikuttavat näihin mittareihin. Koska jokainen DevOps-organisaatio eroaa toisistaan vaihtelevat 16 relevantit mittarit organisaation mukaan perustuen organisaation toiminnan ajureihin. Mittarit saattavat vaihdella myös organisaation sisällä eri toimintojen välillä, jos toimin- tojen tavoitteet eivät ole samat. Mittaaminen ei rajoitu vain tekniikkaan ja prosesseihin vaan myös organisaatiota ja sen kulttuuria tulee mitata aktiivisesti. (Sharma, 2017, s. 33 - 35) Organisaation ohjelmistojen toimituksen suorituskyky korreloi suoraan sekä organisaa- tion kaupallisen tehokkuuden että myös ei kaupallisten tavoitteiden saavuttamisen kanssa. Se muodostuu kahdesta eri komponentista, ohjelmistokehityksestä sekä julkais- tavien ohjelmistojen ylläpidosta. Niiden suorituskyvyn arvioimiseksi tulee organisaation kyetä mittaamaan niiden tehokuutta erikseen. Suorituskyvyn mittarit ovat kuitenkin aina riippuvaisia organisaation toiminnan ajureista ja näin ovat aina spesifejä jokaiselle orga- nisaatiolle. Mittareiden tulisi kuitenkin täyttää kaksi ehtoa: niiden tulee mitata tulosta eikä tuotosta sekä mitata tulosta organisaation näkökulmasta. Ensimmäinen ehto var- mistaa, ettei eri toimintojen välille synny ristiriitaa ja kaikki hyötyvät hyvästä tuloksesta. Toinen ehto on, että mittari mittaa tulosta eikä tuotetta. Näin voidaan varmistaa, ettei mittari mittaa työtä, joka ei suoraan heijastele koko organisaation kannalta positiiviseen tulokseen. Mittaamalla esimerkiksi ohjelmistokehityksen suorittamien tehtävien määrää saattaa antaa väärän kuvan ohjelmistokehityksen tilasta sillä se ei ota kantaa siihen mil- laisia tehtäviä ohjelmistokehityksessä tehdään. Kun mittarit ovat paikallaan voidaan niistä saatua dataa alkaa käyttämään aktiivisesti organisaation toiminnan kehittämiseen. Luotettavan datan avulla organisaatiossa voidaan myös alkaa testaamaan erilaisia hypo- teeseja siitä mitkä asiat vaikuttavat organisaation tehokkuuteen. Vaikka mittarit ovatkin organisaatiospesifejä voidaan avain mittareita vertailla samalla toimialalla toimivien or- ganisaatioiden kanssa, joka auttaa hahmottamaan organisaation suorituskykyä ja mark- kina-asemaa. (Forsgren, Humble & Kim, 2018, s. 44 - 61) Myös organisaatiokulttuurin terveys korreloi suoraan organisaation tehokkuuden ja ei- kaupallisten tavoitteiden saavuttamisen kanssa. Kulttuurin mittaamiseksi tulee kuitenkin olla ensin jokin malli, jota voidaan käyttää mittaamisen lähtökohtana. Kulttuurien mal- lintamiseen on olemassa useita erilaisia malleja, joita on mahdollista käyttää kulttuurien mittaamiseen. Forsgren, Humble & Kim (2018, s.63) suosittelevat DevOps- 17 organisaatioiden mallintamiseen sosiologi Ron Westrumin kehittämää mallia. Sen mu- kaan organisaation kulttuurin perusteella voidaan ennustaa, kuinka informaatio kulkee organisaatiossa ja kuinka tehokas se organisaatio on. Kulttuuria voidaan mitata kysely- tutkimuksilla. On kuitenkin olennaista varmistaa, että jokainen kyselyyn vastannut on ymmärtänyt kysymykset samalla tavalla ja että kysely mittaa oikeita asioita, jotta kyselyn tuloksia voidaan pitää tilastollisesti uskottavina. Westrumin teorian mukaan mitä parem- min informaatio kulkee organisaatiota pitkin, sitä tehokkaampi organisaatio on. Hyvän organisaatiokulttuurin ennakkoedellytyksenä on, että koko organisaatiossa tehdään yh- teistyötä ja ihmiset luottavat toisiinsa. Hyvässä organisaatiokulttuurissa tehdään parem- pia päätöksiä, sillä informaatiota on paremmin saatavilla ja virheelliset päätökset voi- daan nopeammin korjata psykologisesti turvallisessa ympäristössä. Tämä johtaa siihen, että organisaatiossa tehdään kokonaisvaltaisesti laadukkaampaa työtä, kun virheitä löy- detään nopeammin ja niistä uskalletaan puhua avoimesti. (Forsgren, Humble & Kim, 2018, s. 63 - 71) 2.3.6 Automaatio Prosessien automatisointi vähentää manuaalisen työn, energian ja resurssien tarvetta. Samalla se parantaa prosessien laatua, luotettavuutta, täsmällisyyttä ja sen tuloksena lopputulos on aina toistettavissa. Potentiaalisia sovelluskohteita ovat järjestelmän infra- struktuuri, järjestelmä resurssien allokointi, ohjelmiston testaus, ohjelmiston kääntämi- nen sekä sen tarvitsemien artefaktien generointi, mittarit, monitorointi ja palautejärjes- telmät. (Davis & Daniels, 2016, s. 192) Järjestelmän tarvitseman infrastruktuurin ja sen resurssien allokoinnin automatisointi tapahtuu hyödyntämällä sen kuvaukseen suunniteltuja kuvauskieliä (infrastructure as code, IaC). Niiden avulla kuvataan, millaisia resursseja kehitettävä ohjelmisto tarvitsee ja miten näitä resursseja allokoidaan eri tilanteissa. Käytettävät työkalut ovat kuitenkin aina riippuvaisia siitä mikä on haluttu lopputulos ja näin myös riippuvaisia organisaatiosta, joka haluaa automatisoida infrastruktuuriaan. Niitä hyödyntämällä resurssien määritte- lyyn voidaan käyttää samoja prosesseja kuin muuhunkin kehitettävään ohjelmistoon. Sitä voidaan kehittää lokaalissa ympäristössä, se voidaan laittaa versionhallintaan ja sitä 18 voidaan testata ennen julkaisua ja olemassa olevasta infrastruktuurista on olemassa aina ajantasainen dokumentaatio. Kun nämä kuvaukset on kirjoitettu kerran, voidaan niitä hyödyntää niin kauan, kun niiden katsotaan olevan riittäviä. Kun niitä halutaan päivittää, on mahdollista vain päivittää olemassa olevat kuvaukset siten että ne sopivat uuteen tilanteeseen. Jos kehitettävästä järjestelmästä halutaan luoda useita eri versioita, voi- daan samoja kuvauksia uudelleen käyttää. Tällainen käytäntö vähentääkin inhimillisten riskien mahdollisuutta sekä vapauttaa resursseja muihin tehtäviin, parantaa ohjelmisto- kehitystiimin tehokkuutta sekä lisää ketteryyttä ja helpottaa riskien hallintaa. (Davis & Daniels, 2016, s. 181 - 185) Nykyaikaiset ohjelmistot koostuvat useista osista, jotka tulee kääntää oikeassa järjestyk- sessä. Tämän lisäksi niillä on usein riippuvuuksia eri kirjastoihin, joka lisää vielä komplek- sisuutta. Ohjelmistojen monimutkaistuessa on myös niiden käännösprosessista tullut monimutkaisempi, joka on synnyttänyt tarpeen tämän prosessin automatisoinnille. Sitä varten on kehitetty käännösautomaatiotyökaluja, jotka huolehtivat siitä, että ohjelmis- ton eri osat käännetään oikeassa järjestyksessä ja että olemassa olevat ulkoiset riippu- vuudet otetaan käännökseen mukaan ja tarvittavat artefaktit generoidaan. (Davis ja Da- niels, 2016, s. 185 - 187) Käännettävä ohjelmisto on kuitenkin syytä myös testata ennen sen julkaisua. Tällaiseen tilanteeseen voidaankin hyödyntää testiautomaatiota. Testiautomaation avulla pyritään varmistamaan, etteivät uudet muutokset ole rikkoneet olemassa olevaa ohjelmistoa. On kuitenkin huomioitava, että ohjelmistojen kääntäminen saattaa usein viedä huomatta- vasti aikaa. Tämän vuoksi kehitettävässä ohjelmistossa esiintyvät virheet on parempi huomata ennen käännösprosessia. Tähän voidaan myös käyttää testiautomaatiota suo- rittamalla yksikkötestit uudelle koodille. Näin virheet saadaan nopeammin kiinni, joka helpottaa niiden korjaamista ja säästää kehittäjien aikaa. (Sharma, 2017, s. 143 - 145) Monitoroinnilla tarkoitetaan ylläpidettävän järjestelmän ja ohjelmiston tilan seurantaa sekä jatkuvaa tietojen keräämistä. Tietojen keräämiselä tarkoitetaan järjestelmän tilasta kertovien tietojen generointia, organisointia sekä tallentamista. Järjestelmät koostuvat usein useista erilaisista palveluista, joista jokainen saattaa tuottaa huomattavan määrän tietoa omasta tilastaan. Kaiken saatavilla olevan tiedon tallentaminen ei ole välttämättä 19 mielekästä vaan näiden tietojen tulee olla hyvin kohdennettuja ja organisoituja jotta niitä voidaan tehokkaasti hyödyntää tarvittaessa. Monitoroinnin automatisoinnilla pyritään siihen, ettei järjestelmän tilaa tarvitse aktiivisesti tarkkailla vaan voidaan luottaa siihen, että järjestelmän tilan poiketessa halutusta järjestelmä hälyttää sitä ylläpitävälle taholle automaattisesti ennalta määriteltyä sähköistä viestivälinettä käyttäen. Hälytyksien auto- matisoinnin yhteydessä on kuitenkin oleellista suunnitella niiden käyttö etukäteen. Suunnitellessa tulee huomioida hälytyksen syyn vaikutukset, kiireellisyys, ketä asia kos- kee ja käytettävissä olevat resurssit. Jos asian vaikutukset eivät ole järjestelmän toimi- vuuden kannalta välitöntä huomiota tarvitsevia niin käytettävä hälytysmuoto voi olla hie- novaraisempi. Jos asia vaatii taas välitöntä huomiota niin hälytyksen tulee tavoittaa yllä- pitävät tahot mahdollisimman tehokkaasti ja nopeasti. On myös mahdollista, että hälytys syntyy esimerkiksi palvelusta, jota ylläpitää organisaatiossa toinen toiminto. Tällaisessa tapauksessa hälytyksen tulisi informoida kyseistä palvelua ylläpitävää osapuolta. On myös syytä ennalta läpikäydä mihin tilanteisiin organisaatiolla resursseilla kyetään rea- goimaan. (Davis ja Daniels, 2016, s. 188 - 191) 2.3.7 Jatkuva integraatio Ohjelmistokehitys tehdään lähes poikkeuksetta ryhmätyönä, jossa samanaikaisesti useat eri kehittäjät tekevät muutoksia koodiin. Versionhallinta järjestelmät mahdollistavat useiden kehittäjien osallistumisen kehitykseen itsenäisesti. Kehittäjät luovat tehtäväänsä varten oman version ohjelmistosta eriyttämällä versionhallinnan päähaarasta tehtävää varten oman kehityshaaran. Modernissa ohjelmistokehityksessä pyritään myös aktiivi- sesti hyödyntämään jo olemassa olevaa koodia kuten avoimen-lähdekoodin projekteja ja erilaisia ohjelmointirajapintoja. On myös mahdollista, että organisaation muut toimin- not saattavat tehdä jotain osaa kehitettävästä ohjelmistosta tai että siinä hyödynnetään organisaation ulkopuolisia resursseja. Tämä tarkoittaa sitä, että olemassa olevaa ohjel- mistoa muuttaa samanaikaisesti useita ihmisiä, joiden kaikkien työ tulee liittää osaksi kehittävää ohjelmistoa ennen kuin se on valmis. Uuden koodin integrointi olemassa ole- vaan ohjelmistoon on kuitenkin monimutkainen ja aikaa vievä prosessi, jonka vaativuus on suoraan verrannollinen integroitavan muutoksen kokoon. Koodin integroiminen 20 osaksi olemassa olevan ohjelmiston lähdekoodia onkin yksi ohjelmistokehityksen keskei- sistä tehtävistä. Tämän prosessin suorittamista jatkuvasti kutsutaan jatkuvaksi integraa- tioksi (continuous integration, CI). (Sharma, 2017, s. 38) Perinteisesti uusia ominaisuuksia olemassa olevaan ohjelmistoon on kehitetty niiden omissa kehityshaaroissaan, jotka saattavat elää päiviä tai jopa viikkoja ennen kuin ne in- tegroidaan yhteiseen koodikantaan. Pitkällä aikavälillä uutta koodia on kuitenkin kirjoi- tettu todennäköisesti paljon sekä uuden ominaisuuden kehityshaaraan että versionhal- linnan päähaaraan. Tämä kasvattaa riskiä siihen, että integroitavat muutokset eivät ole enää yhteensopivia versionhallinnan päähaaran kanssa. Mitä laajempia muutokset ovat kummassakin haarassa sitä vaikeampi niitä on korjata, joka synnyttää tarpeen uudelleen kirjoittaa osia integroitavasta koodista. Vaihtoehtoisesti jatkuvan integroinnin periaat- teen mukaisesti integroimalla jatkuvasti pieniä muutoksia ovat sekä rikkoutumisen to- dennäköisyys että mahdollisten korjausten pinta-ala pienempiä. Integraatioiden onnis- tumisen testaamiseksi voidaan hyödyntää testiautomaatiota. Ennen koodin lopullista liit- tämistä päähaaraan voidaan vielä varmistaa, ettei integroitava koodi riko mitään. (Davis ja Daniels 2016, s. 38) 2.3.8 Jatkuva toimitus Jatkuvalla toimituksella (continuous delivery, CD) tarkoitetaan kokoelmaa työkaluja, jotka mahdollistavat muutosten viemisen tuotantoon nopeasti ja turvallisesti. Nämä työ- kalut ovat jatkuva integraatio, jatkuva testaus ja kattava kokoonpanon hallinta. Jälkim- mäisellä tarkoitetaan kykyä pystyttää ympäristöjä, kääntää ja testata koodia automati- soidusti ilman tarvetta manuaaliselle konfiguroinnille. Jatkuvan toimituksen implemen- tointi vaatii useiden eri toimintojen yhteistyötä sekä palautesilmukoiden luomista jul- kaistavan ohjelmiston laadun takaamiseksi. Oikein implementoituna jatkuva toimitus kuitenkin mahdollistaa uusien julkaisujen luomisen tarpeen mukaan. Se tarjoaa kehittä- jille työkalut, jotka mahdollistavat ongelmien havaitsemiseen mahdollisimman nopeasti sekä toistuvien tehtävien kuten kääntämisen ja testaamisen automatisointiin. Kun on- gelmat havaitaan heti niiden syntyessä, on niiden korjaaminen helpompaa ja vaikutukset jäävät pienemmiksi. Kun toistuvat tehtävät voidaan automatisoida jää kehittäjille 21 enemmän aikaa keskittyä ohjelmistonkehitykseen sekä ongelmanratkaisuun. Samalla syntyy ympäristö, jossa kehittäjät ottavat vastuun työn tuloksesta, joka heijastelee posi- tiivisesti laatuun ja kehitettävän järjestelmän vakauteen. Organisaatioissa, joissa jatku- vaa toimitusta hyödynnetään, on sillä havaittu olevan positiivinen vaikutus organisaa- tiokulttuuriin, kehitettävän ohjelmiston ja järjestelmän laatuun, ohjelmiston toimituksen tehokkuuteen sekä organisaation tehokkuuteen. (Forsgren, Humble ja Kim, 2018, s. 77 - 88) Jatkuva toimitus mahdollistaa jatkuvan julkaisun (continuous delivery, CD). Samalla ta- valla kuin jatkuva toimitus voidaan nähdä jatkumona jatkuvalle integroinnille, voidaan jatkuva julkaisu nähdä jatkuvan toimituksen seuraavana askeleena. Siinä missä jatkuva toimitus mahdollistaa julkaisun koska tahansa, jatkuvan julkaisun mallissa jokainen muu- tos todella julkaistaan. Sen tavoitteena on minimoida muutosten läpimenoaika (lead time) jolloin se on nopeammin loppukäyttäjien saavutettavissa. Näin kehitettävästä oh- jelmistosta on mahdollista saada palautetta nopeammin. Nopean palautteen avulla ke- hittäjien on mahdollista oppia mitä loppukäyttäjät haluavat ja näin ohjelmistoa voidaan iteroida nopeammin loppukäyttäjien toiveiden mukaan. Sen ansiosta myös näiden muu- tosten julkaiseminen on nopeampaa ja helpompaa. (Davis & Daniels, 2016, s.39) 22 3 Pehmeät taidot 3.1 Määritelmä Pehmeille taidoille ei ole olemassa yhtä yksiselitteistä määritelmää. Niiden määritelmä on aina kontekstisidonnainen. Taidot, jotka tietyssä kontekstissa määritellään koviksi tai- doiksi, voidaan toisessa kontekstissa määritellä pehmeiksi taidoiksi. Niiden voidaan kui- tenkin laajasti sanoa olevan kokoelma persoonallisuuspiirteitä, sosiaalisia taitoja, henki- lökohtaisia ominaisuuksia ja optimismia. Esimerkiksi seuraavat piirteet luetaan pehmei- siin taitoihin: kommunikointikyky, itseohjautuvuus, ajanhallinta, vastuunottaminen, itse- tunto, sosiaalisuus ja empatia. (Schulz, 2008, s. 147 - 149) Tässä tutkimuksessa pehmeät taidot määritellään kahden ehdon kautta. Kyseessä on pehmeä taito, jos se täyttää toisen tai molemmat seuraavista ehdoista: kyseessä on hen- kilökohtainen ominaisuus tai ei kognitiivinen taito. Ei kognitiivisilla taidoilla tarkoitetaan taitoja, jotka eivät perustu opittuun tietoon. Koska laajempi määritelmä on kontekstisidonnainen, määritellään tässä tutkimuksessa käytettäväksi kontekstiksi DevOps-organisaation päivittäinen toiminta sen muutospro- sessin vaiheesta riippumatta. 3.2 Osa-alueet Johtuen siitä, ettei pehmeille taidoille ole olemassa yksiselitteistä määritelmää on myös niiden eri osa-alueille olemassa useita erilaisia määritelmiä. Ne voidaan kuitenkin jakaa kahteen selkeään osa-alueeseen, henkilökohtaisiin- ja sosiaalisiin taitoihin, määritel- mästä riippumatta. Henkilökohtaisilla pehmeillä taidoilla tarkoitetaan niitä taitoja, jotka vaikuttavat siihen, miten yksilö toimii ilman kanssakäymistä muiden kanssa. Tällaisia ovat esimerkiksi ongel- man ratkaisukykyyn, oppimiseen ja ajattelemiseen liittyvät taidot. Sosiaalisilla taidoilla tarkoitetaan niitä taitoja, jotka vaikuttavat yksilön kanssakäymiseen muiden kanssa. Tällaisia taitoja ovat esimerkiksi kommunikointi taitoja tai muiden tun- teiden tulkitsemista. (Cimatti, 2015) 23 3.3 Pehmeät taidot ohjelmistokehityksessä Ohjelmistokehitysorganisaatioihin haetaan yhdeksää eri pehmeää taitoa. Kommunikaa- tiotaitoja, henkilösuhdetaitoja, analyyttisiä- ja ongelmanratkaisutaitoja, kykyä työsken- nellä osana ryhmää, organisointitaitoja, kykyä oppia uusia asioita nopeasti, kykyä työs- kennellä itsenäisesti sekä innovatiivisuutta että avoimuutta ja kykyä adaptoitua muutok- seen. Kommunikaatiotaidoilla tarkoitetaan henkilön kykyä viestiä muiden kanssa siten että viesti vastaanotetaan ja ymmärretään siten kuten se on tarkoitettu. Henkilösuhde- taidot ovat niitä taitoja, joiden avulla henkilö toimii vuorovaikutuksessa muiden kanssa niin suotuisissa kuin epäsuotoisissakin tilanteissa. Analyyttisillä- ja ongelmanratkaisutai- doilla tarkoitetaan henkilön kykyä ymmärtää, viestiä ja ratkaista monimutkaisiakin on- gelmia sekä tehdä päätöksiä olemassa olevan tiedon perusteella. Kyky työskennellä ryh- mässä tarkoittaa, että henkilö kykenee tehokkaasti työskentelemään muiden kanssa ja- kaen heidän kanssaan yhteisiä tavoitteita. Organisointitaidoilla tarkoitetaan henkilön ky- kyä käyttää resursseja kuten aikaa tehokkaasti. Uusien asioiden nopealla oppimisella tar- koitetaan tietotekniikan kontekstissa tapahtuvaa kehitystä eli sitä kykyä, kuinka nopeasti henkilö pystyy oppimaan uusia tekniikoita, konsepteja ja toimintatapoja. Kyky työsken- nellä itsenäisesti tarkoittaa sitä, että henkilö kykenee suoriutumaan tehtävistään ilman valvontaa. Innovatiivisuudella tarkoitetaan henkilön kykyä löytää ja luoda uusia luovia ratkaisuja erilaisiin ongelmiin. Avoimuus ja kyky adaptoitua muutokseen tarkoittaa kuinka hyvin henkilö vastaanottaa muutoksen ja pystyy sopeutumaan siihen. (Ahmed, Capretz & Campbell, 2012) Näiden taitojen kysyntä vaihtelee henkilöstöresurssien roolien mukaan. Esimerkiksi oh- jelmistotestaajien kannalta taitoa työskennellä tiimissä ei pidetä erityisen tärkeänä, mutta jokaisessa muussa roolissa sen merkitystä korostetaan. Kommunikaatiotaitoja vaaditan työtehtävästä riippumatta, kun taas avoimuutta ja adaptoitumiskykyä ei pidetä missään roolissa erityisen tärkeänä. (Faheem, Capretz, Bouktif, Campbell 2013) 24 4 Menetelmä Tutkimus menetelmäksi valikoitu systemaattinen kirjallisuuskatsaus. Systemaattinen kir- jallisuus katsaus on tutkimusmuoto, jossa käydään läpi tutkittavan aihepiirin julkaisuja ja pyritään luomaan niiden perusteella tiivistelmä tutkimuksen kannalta olennaisesta ja mielenkiintoisesta aineistosta. Sitä käytetään usein tukevana tekniikkana tutkimuksen kontekstin asettamiseksi, jonka avulla selvitetään tutkimuksen alkuasetelma. Se on kui- tenkin täysin pätevä myös itsenäisenä tutkimusmuotona. (Salminen, 2011, s.9) Kuva 1 IS tutkimukseen adaptoitu systemaattisen kirjallisuuskatsauksen Fink-malli (Okoli & Schabram, 2010, s. 9) Systemaattisessa kirjallisuuskatsauksessa olemassa olevaa tutkimusta kartoitetaan ja seulotaan läpi systemaattisesti sekä kriittisesti tutkimuksen kannalta olennaisen tiedon 25 löytämiseksi. Tässä tutkimuksessa menetelmänä käytettiin IS tutkimukseen adaptoitua Fink-mallia. Käytetty malli koostuu kahdeksasta eri vaiheesta: kirjallisuuskatsauksen tar- koituksen määrittely, protokollan määrittely, julkaisujen etsiminen, käytännön seula, laa- dullinen seula, tutkimuksen kannalta mielenkiintoisen tiedon talteen kerääminen, syn- teesi ja selonteko. (Okoli, Schabram, 2010, s. 6) Tutkimusmenetelmän valintaan vaikutti erityisesti kaksi hyvin käytännön läheistä syytä. Ensinnäkin koska olemassa oleva tutkimus ei erottele kovia ja pehmeitä taitoja DevOps- kontekstissa, on olennaista koostaa mitä aiheesta tiedetään jo olemassa olevan tutki- muksen perusteella. Toiseksi jokainen organisaatio on yksilöllinen ja näin ollen myös jokaisen organisaation lähtökohdat DevOps-viitekehyksen käyttöönottoon ovat erilaiset. Tämän takia myös jo- kainen DevOps-muutosprosessi on organisaatiokohtainen. Myös se miten organisaa- tiossa tulkitaan ja sovelletaan olemassa olevaa kirjallisuutta ja tutkimuksia on aina yksi- löllistä. Tämän vuoksi myös organisaatioiden tarpeet henkilöstön pehmeiden taitojen suhteen saattavat poiketa toisistaan. On kuitenkin olemassa vain rajallinen määrä ole- massa olevaa tutkimusta ja kirjallisuutta, josta jokaisen organisaation tulee hakea tietoa sekä vaikutteita. Näin suorittamalla tutkimus systemaattisena kirjallisuuskatsauksena, palaamalla tiedon alkulähteille, pyritään minimoimaan riskit siitä, että tutkimuksen tu- loksista löytyisi sellaisia pehmeitä taitoja, jotka eivät ole oleellisia DevOps-organisaa- tiossa vaan liittyvät jonkun tietyn organisaation toimintaan. 4.1 Tarkoituksen määrittely Tutkimuksen tarkoituksena on tutkimuskysymyksen mukaisesti löytää lista sellaisia peh- meitä taitoja, joita DevOps-organisaatiossa työskentelemiseen tarvitaan sekä samalla luoda ajankohtainen kirjallisuuskatsaus DevOps-käytännöistä. 4.2 Protokolla Tutkimus aloitettiin hakemalla valituista kahdesta tietokannasta jokainen julkaisu, jonka tietokantojen hakukoneet palauttivat määritellyillä hakutermeillä. 26 Julkaisujen keräämisen jälkeen ne seulottiin läpi kaksivaiheisesti. Ensimmäisessä vai- heessa julkaisut kävivät läpi käytännön seulan. Käytännön seulan aikana tarkastetaan, onko julkaisu kirjoitettu sellaisella kielellä, jota tutkimuksen tekijä ymmärtää ja voiko sen perusteella vastata tutkimuskysymykseen. Seuraavassa vaiheessa eli laadullisessa seu- lassa, jäljelle jääneet julkaisut läpikäytiin ja pisteytettiin. Julkaisut, jotka eivät täyttäneet tutkimuksen kriteerejä jätettiin tutkimuksen ulkopuolelle. Tämän jälkeen aloitettiin seulonnasta jäljelle jääneiden julkaisujen läpikäyminen. Tässä vaiheessa julkaisut luettiin useaan kertaan läpi. Läpikäymisen aikana julkaisujen kappa- leista tehtiin sekä muistiinpanoja että tiivistelmiä mielenkiintoisten ja tutkimus kysymyk- sen kannalta oleellisista kohdista. Muistiinpanot kirjattiin systemaattisesti käyttäen kaa- vaa: ensimmäisenä kirjattiin ylös lähde, tämän jälkeen sivunumero, otsikko, avainsanat sekä päivämäärä, jolloin muistiinpano lisättiin. Tämän jälkeen kappaleesta tai kohdasta, josta muistiinpano kirjattiin ylös, kirjoitettiin tiivistelmä. Kaikki muistiinpanot sekä tiivis- telmät kirjoitettiin käyttäen sähköisiä työkaluja, jotta niitä voidaan lajitella ja etsiä tehok- kaammin tutkimuksen seuraavissa vaiheissa. Läpikäymisen jälkeen alettiin julkaisuista luomaan synteesiä. Synteesissä luomiseksi käy- tettiin apuna luokittelu menetelmää, jonka avulla pyrittiin materiaalista löytämään kaikki DevOps-organisaatiossa työskentelyyn vaaditut pehmeät taidot. Luokittelun tuloksien analyysin perusteella kirjoitettiin lopullinen synteesi. Tutkimusprosessin selonteko on kirjattu kappaleeseen tulkinta. Sen avulla tutkimuksen toistaminen tarvittaessa on mah- dollista. 4.3 Tutkimuksien haku Hakuehdoiksi määriteltiin kaksi eri ehtoa. Ensimmäisenä ehtona, julkaisun abstraktissa on mainittava termi DevOps. Tällaiseen ehtoon päädyttiin koska kyseessä on varsin tuore ja vähän tutkittu ilmiö, tiedostettiin että olemassa olevaa tutkimusta on saatavilla vain rajallisesti. Rajaamalla hakutuloksia tällä tavoin pyrittiin varmistamaan, että mukaan saa- daan myös sellaiset julkaisut, jotka potentiaalisesti käsittelevät vain yhtä DevOps-viite- kehyksen osa-aluetta. Näin tutkimuksen kannalta potentiaalisesti mielenkiintoisten jul- kaisujen määrää kyettiin kasvattamaan. Tämä hakuehto kuitenkin mahdollisti 27 ääritapauksen, jossa jokainen tutkimuksessa käytettävä julkaisu käsittelisi jotain DevOps- viitekehyksen osa-aluetta. Tällainen tilanne lisäisi riskiä siitä, että tutkimuksessa jätettäi- siin täysin huomioimatta jokin DevOps-viitekehyksen osa-alueista. Koska tässä tutkimuk- sessa keskityttiin siihen, millaisia pehmeitä taitoja DevOps-viitekehys kokonaisuutena vaatii, huomioitiin tämä riski käytännön seulassa. Tarkistamalla että jokainen julkaisu ei keskity yksittäiseen osa-alueeseen voitiin varmistaa, että jokainen viitekehyksen osa- alue on huomioitu. Toisena ehtona on, että julkaisussa mainitaan pehmeät taidot tai jokin termeistä, joita kirjallisuudessa käytetään kuvaamaan taitoja, joita ei lasketa koviksi taidoiksi. Tällaisia termejä ovat: sosiaaliset taidot (social skills), luonteenpiirteet (personality traits), ei-kog- nitiiviset taidot (non-cognitive skills), ei-kognitiiviset kyvyt (non-cognitive abilities), luonne (character) tai sosiaalisemotionaaliset taidot (socio-emotional skills). Huomion arvoista on, että nämä termit eivät ole synonyymeja pehmeille taidoille, vaan niillä tar- koitetaan eri ominaisuuksia, jotka voidaan laskea pehmeiden taitojen alle. (Heckman & Kautz, 2012, s. 4) Näin pyrittiin varmistamaan, että haun tuloksena saatavat artikkelit ovat relevantteja tä- män tutkimuksen kannalta samalla huomioiden olemassa olevan tutkimuksen rajallinen määrä. Tutkimuksessa käytettiin kahta eri tietokantaa julkaisujen etsimiseen ja hakemiseen. Päätös useamman tietokannan käyttämisestä tehtiin käytännön syistä. Sillä pyrittiin kas- vattamaan tutkimuksen kannalta mielenkiintoisten ja vapaasti saatavilla olevien julkai- sujen määrää. Hakukoneina käytettiin valittujen tietokantojen omia hakukoneita. Käyte- tyistä tietokannoista ensimmäinen on Association for Information Systems elektroninen kirjasto AIS Electronic Library. Muotoilemalla hakuehdot sen hakukoneen käyttämään syntaksiin muodostuu ehtolauseeksi: abstract:devops AND ( soft skills ) OR ( social skills ) OR ( personality traits ) OR ( non-cognitive skills ) OR ( non- cognitive abilities ) OR ( character ) OR ( socio-emotional skills ) Haun tuloksena löytyi 29 ehtoihin sopivaa julkaisua. Niistä 23 oli vapaasti saatavilla. 28 Toisena tietokantana käytettiin Association For Computing Machinery ACM DL Digital Library tietokantaa. Muotoilemalla hakuehdot sen hakukoneen käyttämään syntaksiin muodostuu ehtolauseeksi: [Abstract: devops] AND [[All: "soft skills"] OR [All: "social skills"] OR [All: "personality traits"] OR [All: "non-cogni- tive skills"] OR [All: "non-cognitive abilities"] OR [All: "character"] OR [All: "socio-emotional skills"] Tämän haun tuloksena löytyi 12 julkaisua, joista jokainen oli vapaasti saatavilla. Haku- prosessin lopputuloksena tutkimusta varten haettiin yhteensä 35 julkaisua, jokainen va- paasti saatavilla oleva julkaisu. Jokaisen julkaisun on oltava esteettömästi saatavilla, jotta tutkimuksen laatua voidaan myöhemmin arvioida. 4.4 Käytännön seula Käytännön seulan tarkoituksena on seuloa hakuprosessin tuloksena löytyneestä materi- aalista läpi sellaiset julkaisut, joita ei selkeästi voida käyttää tutkimuksessa käytännön syistä. Seulan ensimmäisessä vaiheessa koottiin eri julkaisuista nimi, julkaisu ajankohta, tekijä tai tekijät. Seuraavassa vaiheessa tämän listan perusteella tarkasteltiin, ettei jul- kaisujen joukosta löydy duplikaatteja. Tämän jälkeen aloitettiin julkaisujen systemaatti- nen läpikäyminen, jonka aikana niiden tiivistelmät luettiin. Tässä vaiheessa tarkasteltiin kahta asiaa: onko julkaisu kirjoitettu joko suomeksi tai englanniksi ja voiko julkaisun pe- rusteella vastata tutkimuskysymykseen. Tämän prosessin aikana tarkastettiin myös, kes- kittyykö julkaisu DevOps-viitekehykseen kokonaisuutena vai käsitteleekö se jotain viite- kehyksen osa-aluetta. Näin tehtiin koska tutkimuksen hakuehdot mahdollistivat tilan- teen, jossa jokainen haettu julkaisu käsittelisi yksittäistä DevOps-viitekehyksen osa-alu- etta. Julkaisuja läpikäydessä tarkistettiin, että haetut julkaisut eivät koostuu pelkästään tällaisista julkaisuista. Käytännön seulan läpäisi 20 julkaisua 35 julkaisusta. Joukossa ei ollut ainuttakaan dupli- kaattia. Valta-osa julkaisuista käsitteli DevOps-viitekehystä kokonaisuutena. Tutkimuksen ulkopuolelle jätetyistä julkaisuista yksi jätettiin pois koska se oli kirjoitettu kielellä, jota tutkija ei hallitse. Muiden 14 julkaisun perusteella ei ollut mahdollista vastata 29 tutkimuskysymykseen. Valtaosa näistä keskittyi käsittelemään teknisiä haasteita De- vOps-kontekstissa eivätkä näin ottaneet kantaa vaadittuihin pehmeisiin taitoihin. 4.5 Laadullinen seula Laadullisessa seulassa pyritään varmistamaan tutkimukseen mukaan otettavien julkaisu- jen laatu. Sen helpottamiseksi tutkimuksessa päädyttiin käyttämään ennalta tunnettuja tietokantoja. Näin pyrittiin varmistamaan, että kaikki sieltä löytyvät julkaisut ovat läpi- käyneet jo standardoidun seulan. Laadullisessa seulassa julkaisut luettiin ensimmäisen kerran läpi niiden arvioimiseksi. Siinä julkaisuja tarkasteltiin kolmen tutkimuksesta pois sulkevan kriteerin kannalta. En- simmäinen kriteeri on, että tutkimuksen perusteella on mahdollista vastata tutkimusky- symykseen. Koska käytännön seulassa tutkimuksista luetaan vain tiivistelmät, ei niiden pohjalta voida sanoa varmasti onko tutkimus kysymykseen vastaaminen mahdollista jul- kaisun perusteella. DevOps-terminä on toistaiseksi vailla yleisesti hyväksyttävää määritelmää ja sen ilmiönä voidaan katsoa kehittyvän jatkuvasti. Tulkinnat siitä mitä DevOps on, vaihtelivat enem- män vanhemmassa kirjallisuudessa ja tutkimuksessa johtuen olemassa olevan tutkimuk- sen ja kirjallisuuden puutteesta. Ilmiön kasvaessa ja kehittyessä sekä tutkimuksen lisään- tyessä ovat tulkinnat siitä yhtenäistyneet. Tämän seikan huomioimiseksi haluttiin tutki- mukseen mukaan vain sellaiset julkaisut, jotka on julkaistu viimeisen viiden vuoden ai- kana. Toinen tutkimuksesta pois sulkeva kriteeri onkin, että julkaisu on vanhempi kuin viisi vuotta, eli kirjoitettu ennen vuotta 2016. Kolmas kriteeri on sidottu julkaisujen arviointiin. Kaikki julkaisut käytiin läpi niiden arvi- oimiseksi. Niiden pisteytys tapahtui arvioimalla niiden rakenteellista oikeellisuutta, sisäl- lön pätevyyttä, yleistettävyyttä ja kuinka hyvin konteksti sopii tähän tutkimukseen. Pis- teytys toteutettiin siten että julkaisut saivat yhden pisteen jokaista täytettyä kriteeriä kohden. Jos julkaisu ei täyttänyt yhtään näistä kriteereistä se sai nolla pistettä. Jos se täytti kaikki kriteerit, se sai neljä pistettä. Julkaisujen pisteytyksen kokonaisasteikko oli siis 0 – 4. Toisena pois sulkevana kriteerinä tuli jokaisen tutkimukseen mukaan otettavan julkaisun saada vähintään yksi piste pisteytyksessä. 30 Laadullisen seulan läpäisi 19 julkaisua 20 julkaisusta. Pois jätetyn julkaisun perusteella ei ollut mahdollista vastata tutkimuskysymykseen. 4.6 Katsaus Käytännön ja laadullisen seulan läpäisi yhdeksäntoista julkaisua. Näistä julkaisuista 14 kappaletta on noudettu AIS Electronic Librarysta ja 5 kappaletta ACM DL Digital Libra- rysta. Julkaisuista 17 kappaletta on tutkimusartikkeleita, 1 kappale akateemisia julkai- suja ja 1 kappale konferenssijulkaisuja. Vanhimmat julkaisut ovat vuodelta 2017 ja tuo- reimmat 2020. Taulukossa 1 näkyy kaikki katsaukseen mukaan otetut julkaisut. Katsauk- sena aikana julkaisuja läpikäytiin useaan kertaan etsien niistä tutkimuskysymyksen kan- nalta olennaisia tai mielenkiintoisia kohtia. Protokollan mukaisesti näistä kohdista tehtiin muistiinpanot ja niistä kirjoitettiin tiivistelmät. TAULUKKO 1. Katsaukseen mukaan otetut julkaisut. Julkaisu Tekijät Vuosi A DevOps Collaboration Culture Acceptance Model T. Masombuka, E. Mnkandla 2018 A New Form of Collaboration in IT Teams - Exploring the DevOps Phenomenon A. Wiedemann 2017 A Qualitative Study of the Background, Skill Acquisition, and Learning Preferences of Software Testers R. Florea, V. Stray 2020 Are you ready for DevOps - Required skill set for Devops teams A. Wiedemann, Wiesche, M. 2018 BizDevOps and the Role of S-BPM P. Forbrig 2018 Critical Success Factors of Continuous Practices in a DevOps Context M. van Belzen, J. Tri- enekens, R. Kusters 2019 Dependency Management in Large-Scale Agile: A Case Study of DevOps Teams V. Stray, N. B. Moe, A. Aasheim 2019 DevOps: Concepts, Practices, Tools, Benefits and Challenges G. B. Ghantous, A. Gill 2017 Implementing the Planning Process within DevOps Teams to Achieve Continuous Innovation A. Wiedemann, M. Wiesche, H. Gewald, H. Krcmar 2019 31 Julkaisu Tekijät Vuosi Industry-Academy Collaboration in Teach-ing DevOps and Continuous Delivery to Software Engineering Students: To- wards Improved Industrial Relevance in Higher Education K. Kuusinen, S. Albertsen 2019 Integrating Development and Operations in Cross-Functional Teams - Toward a DevOps Competency Model A. Wiedemann, M. Wiesche, H. Krcmar 2019 Invited Paper A Generalized, Enterprise-Level Systems Devel- opment Process Framework for Systems Analysis and Design Education H. Topi, G. Spurrier 2019 IT Governance Mechanisms for DevOps Teams How Incum- bent Companies Achieve Competitive Advantages A. Wiedemann 2018 Leveraging DevOps for mission critical software M. Gall, F. Pigni 2018 On Devops and Workforce Morale J. Shropshire, B. Sweeney 2017 Productivity Gains of DevOps Adoption in an IT Team: A Case Study M.A. Silva, J.P. Faustino, R. Pereira, M.M. da Silva 2017 SKI: A New Agile Framework that supports DevOps, Continu- ous Delivery, and Lean Hypothesis Testing J. Saltz, A. Sutherland 2020 The Empire Strikes Back: The end of Agile as we know it? J. Babb, J. Nørbjerg, D.J. Yates, L.J. Waguespack 2017 Understanding DevOps Education with Grounded Theory C. Pang, A. Hindle, D. Barbosa 2020 4.7 Tulkinta Synteesin luomiseksi käytettiin apuna luokittelumenetelmää. Sen avulla tutkittavasta materiaalista pyrittiin tuomaan esiin kaikki seljlaiset pehmeät taidot, jotka ovat sidok- sissa DevOps-viitekehyksen mukaisiin käytäntöihin ja toimintatapoihin. Luokittelumenetelmässä aineistosta poimituista tutkimuksen kannalta oleellisista koh- dista muodostetaan ensin pelkistettyjä ilmauksia. Näiden perusteella luokiteltava ai- neisto luokitellaan ala- ja yläluokkiin sekä yhdistävään luokkaan. Luokkien muodostami- nen tapahtuu etsimällä luokiteltavasta materiaalista eroja ja yhtäläisyyksiä, joiden perus- teella luokat muodostetaan. Luokittelun lähtökohtana on aina tutkimuskysymys. (Tuomi & Sarajävi, 2002, s.118) Koska luokittelun tavoitteena oli löytää tutkimusmateriaalista siinä esiintyvät pehmeät taidot, valittiin yhdistäväksi luokaksi pehmeät taidot. Pehmeille taidoille ei kuitenkaan ole olemassa yleisesti hyväksyttyä määritelmää, ne ovat sidottuja kontekstiin, jonka 32 lisäksi niillä on riippuvuuksia toisiinsa. Esimerkiksi ihmissuhdetaidot voidaan jossain kon- tekstissa katsoa pehmeiksi taidoiksi, mutta ne ovat myös osa sosiaalisia taitoja. Tämän takia alaluokat edustavat joko yksittäisiä pehmeitä taitoja, niiden osaa tai henkilökoh- taista ominaisuutta. Yläluokat taas edustavat pehmeitä taitoja tai laajempia kokonaisuk- sia. Sen jälkeen itse luokittelu prosessi aloitettiin listaamalla katsauksen aikana kirjoitetuista tiivistelmistä löytyneet tutkimuksen kannalta mielenkiintoiset ilmaukset ja fraasit eli pel- kistetyt ilmaukset jokaista julkaisua kohden. Vertaamalla näiden pelkistettyjen ilmauk- sien eroja ja yhtäläisyyksiä toisiinsa muodostettiin jokaiselle tutkimuksen julkaisulle ala- luokat. Vertaamalla taas alaluokkien välisiä eroja sekä yhtäläisyyksiä, muodostetiin ylä- luokat. Taulukosta 4 näkyy luokittelun aikana muodostettujen ilmausten sekä ala- ja ylä- luokkien kokonaismäärät sekä kuinka monta uniikkia luokkaa ja ilmausta luokittelun ai- kana syntyi. TAULUKKO 2. Luokittelun tulokset Luokittelun osa-alue Määrä Pelkistetyt ilmaukset 180 Uniikit pelkistetyt ilmaukset 142 Alaluokat 324 Uniikit alaluokat 24 Yläluokat 251 Uniikit yläluokat 14 Johtuen ala- ja yläluokkien määrittelyistä sekä pehmeiden taitojen keskinäisistä riippu- vuuksista ei luokittelu sellaisenaan suoraan tarjoa listaa pehmeistä taidoista. Kuvassa 2 on kuvattu luokkien välisiä moniulotteisia riippuvuus suhteita. Uniikkien pehmeiden tai- tojen löytämiseksi prosessin viimeisessä vaiheessa suoritettiin luokittelun tuloksena syn- tyneiden luokkien seulonta. Tämän prosessin vaiheen tarkoituksena on karsia kaikkien luokittelun tuloksena syntyneiden luokkien joukosta sellaiset luokat pois, jotka eivät edusta pehmeitä taitoja, ovat niiden osia tai ovat duplikaatteja. 33 Kuva 2 Ylä- (merkitty vihreällä) ja alaluokkien (merkitty sinisellä) väliset suhteet. Seulonta prosessi aloitettiin yhdistämällä uniikit ala- ja yläluokat keskenään. Näin saatiin 37 luokan lista, joka sisälsi 3 duplikaattia. Duplikaattien eliminoimisen jälkeen seulan seuraavassa vaiheessa jäljelle jääneistä 34 luokasta eliminoitiin 11 luokkaa. Näistä luo- kista kolme sisälsi useita eri pehmeitä taitoja, esimerkiksi analyyttiset- ja ongelmanrat- kaisutaidot voidaan jakaa kahteen eri taitoon. Loput kahdeksan eliminoitua luokkaa oli- vat joidenkin pehmeiden taitojen osa-alueita, esimerkiksi ihmissuhdetaidot, jotka ovat osa sosiaalisia taitoja. Seulontaprosessin lopputuloksena jäljelle jäi 23 uniikkia luokkaa: adaptoituminen, aktiivisuus, analyyttiset taidot, avoimuus, haavoittuvuus, innovatiivi- suus, itseluottamus, itsenäisyys, itseohjautuvuus, johtajuus, kommunikaatiotaidot, kult- tuurien tunteminen, luottamus, ongelmanratkaisukyky, oppiminen, organisointitaidot, 34 päätöksen tekeminen, paineen ja stressin sietäminen, rohkeus, sosiaaliset taidot, tietoi- suus, vastuullisuus ja yhteistyö Tämän jälkeen seulontaprosessin läpäisseet luokat läpikäytiin arvioiden täyttävätkö ne tässä tutkimuksessa käytetyn määritelmän pehmeistä taidoista: ei kognitiivinen taito tai henkilökohtainen ominaisuus. Jokainen jäljelle jääneistä luokista täyttää vähintään toi- sen näistä ehdoista, joten seulonnan tuloksena saatua listaa voidaan pitää myös vastauk- sena tutkimuskysymykseen. Koska aiheesta ei ole aikaisempaa tutkimusta tai sitä ei ole helposti löydettävissä, on mahdollista, että tuloksena saatu lista on ensimmäinen koonti DevOps-viitekehyksen vaatimista pehmeistä taidoista. Tästä huolimatta tuloksena saatua listaa voidaan verrata olemassa olevaan tietoon. Peh- meitä taitoja mainitaan hajanaisesti olemassa olevassa tutkimuksessa ja kirjallisuudessa. Tässä tutkimuksessa lähteinä käytetyssä kirjallisuudessa esiintyvät pehmeät taidot ovat: innovatiivisuus, luottamus, oppiminen, päätöksien tekeminen, paineen ja stressin sietä- minen sekä yhteistyötaidot. (Davis ja Daniels, 2019; Forsgren, Humble ja Kim, 2018; Ravichandran, Taylor, Waterhouse, 2016) Tämän lisäksi tuloksia voidaan verrata yhdeksään ohjelmistokehitysorganisaatioissa ky- syttyihin pehmeisiin taitoihin: kommunikaatiotaidot, henkilösuhdetaidot, analyyttiset- ja ongelmanratkaisutaidot, kyky työskennellä ryhmässä, organisointitaidot, kyky oppia uu- sia asioita nopeasti, kyky työskennellä itsenäisesti, innovatiivisuus, avoimuus ja kyky adaptoitua muutokseen. (Faheem, Capretz, Bouktif, Campbell 2013) Verrattaessa tutkimuksen tuloksena saatuja pehmeitä taitoja DevOps-kirjallisuudessa esiintyviin pehmeisiin taitoihin, huomataan että tutkimuksen tulokset sisältävät jokaisen edellä mainituista taidoista. Vaikka kyseessä on vain pieni otos olemassa olevasta kirjal- lisuudesta, voidaan tuloksien todeta olevan linjassa olemassa olevan tiedon kanssa. Ver- rattaessa taas ohjelmistokehitysorganisaatioissa kysyttyihin taitoihin, nähdään että tu- lokset ovat linjassa myös niiden kanssa. Tutkimuksen kannalta mielenkiintoisia tuloksia ovat myös yhdeksän kappaletta taitoja, jotka eivät kuulu kumpaankaan vertailu otokseen. Nämä ovat: aktiivisuus, haavoittuvuus, 35 itseluottamus, itseohjautuvuus, johtajuus, kulttuurien tunteminen, rohkeus, tietoisuus, vastuullisuus. 4.8 Synteesi Synteesissä poimitut tiedot kootaan yhteen, järjestetään, vertaillaan ja niiden perus- teella kirjoitetaan kvalitatiivinen meta-analyysi. Synteesi voidaan jakaa seuraaviin aske- leisiin: kirjallisuuden tunteminen, sen ymmärtäminen, sen jakaminen osiin, sen sovelta- minen, sen synteesi ja arviointi. Arvioinnin rooli on erityisen tärkeä. Siinä menetelmä kuvataan siten että se on toistettavissa. Tällä pyritään varmistamaan prosessin tuloksena syntyvän synteesin laatu. (Okoli, Schabram, 2010, s. 31-32) Synteesin lähestymistavaksi valittiin metasynteesi. Siinä tutkimusaineistoa läpikäydään huolellisesti vertaillen, etsien niistä poikkeavuuksia sekä yhtäläisyyksiä. Tämän prosessin tarkoituksena on saada kattava kokonaiskuva tutkimusaineistosta ja tiivistämään tutkit- tavaa materiaalia vastavuoroisen käännöksen tekemiseksi. Vastavuoroisen käännöksen tavoitteena on tulkitsevan synteesin luominen. Siinä materiaalia verrataan keskenään ja havaittuja yhtäläisyyksiä muutetaan yhden muotoiseksi metaforia käyttämällä. Tätä pro- sessia ei kuitenkaan tule tehdä väkisin, jotta aineistosta löytyvä mahdollinen uusi tieto ei jää huomaamatta. (Salminen, 2011) Schryen (2015) toteaa että järjestys, jossa aineistoa lähdetään synteesissä purkamaan, tulisi olla aina konseptikeskeinen eikä esimerkiksi kronologinen tai kirjoittajakeskeinen. Tässä tutkimuksessa valittiin lähestymistavaksi luokittelu, jonka avulla kerätty aineisto läpikäytiin sen sisältämän tiedon esiin tuomiseksi. Luokittelun tuloksena koko tutkimus- aineistosta löydettiin 142 uniikkia pelkistettyä ilmausta, 25 uniikkia alaluokkaa ja 15 uniikkia yläluokkaa. Synteesin runko rakentuu luokittelun tuloksena syntyneiden yläluokkien ympärille. Tau- lukosta 2. on nähtävissä julkaisun numero ja taulukosta 3. tätä numeroa vastaavat ylä- luokat. Yläluokat kuvaavat DevOps-organisaatioissa oleellisimpia pehmeitä taitoja tai useita pehmeitä taitoja sisältäviä joukkoja. Pehmeät taidot ovat usein vahvasti sidoksissa toisiinsa. Esimerkiksi sosiaalisten taitojen alle kuuluu useita erilaisia taitoja kuten ihmis- suhdetaidot, kommunikaatiotaidot sekä itseluottamus. DevOps-kontekstissa tarvitaan 36 kuitenkin usein laajempia kokonaisuuksia kuten sosiaalisia taitoja. Vaikka ihmissuhdetai- dot ovat tärkeitä, ne eivät yksin riitä vaan niitä tukemaan vaaditaan muita samaan ylä- luokkaan kuuluvia taitoja kuten kommunikaatiotaitoja. TAULUKKO 3. Julkaisujen numerointi Julkaisu Nro A DevOps Collaboration Culture Acceptance Model 1 A New Form of Collaboration in IT Teams - Exploring the DevOps Phenomenon 2 A Qualitative Study of the Background, Skill Acquisition, and Learning Preferences of Software Testers 3 Are you ready for DevOps - Required skill set for Devops teams 4 BizDevOps and the Role of S-BPM 5 Critical Success Factors of Continuous Practices in a DevOps Context 6 Dependency Management in Large-Scale Agile: A Case Study of DevOps Teams 7 DevOps: Concepts, Practices, Tools, Benefits and Challenges 8 Implementing the Planning Process within DevOps Teams to Achieve Continuous In- novation 9 Industry-Academy Collaboration in Teach-ing DevOps and Continuous Delivery to Software Engineering Students: Towards Improved Industrial Relevance in Higher Edu- cation 10 Integrating Development and Operations in Cross-Functional Teams - Toward a DevOps Competency Model 11 Invited Paper A Generalized, Enterprise-Level Systems Development Process Frame- work for Systems Analysis and Design Education 12 IT Governance Mechanisms for DevOps Teams How Incumbent Companies Achieve Competitive Advantages 13 Leveraging DevOps for mission critical software 14 On Devops and Workforce Morale 15 Productivity Gains of DevOps Adoption in an IT Team: A Case Study 16 SKI: A New Agile Framework that supports DevOps, Continuous Delivery, and Lean Hy- pothesis Testing 17 The Empire Strikes Back: The end of Agile as we know it? 18 Understanding DevOps Education with Grounded Theory 19 37 TAULUKKO 4. Eri julkaisuista löytyneet yläluokat. Ju lk ai su n n u m e ro A d ap to it u m in en A kt iiv is u u s A n al yy tt is et - ja o n ge lm an ra tk ai su ta id o t H en ki lö ko h ta is et o m in ai su u d et In n o va ti iv is u u s It se n äi sy ys It se o h ja u tu vu u s Jo h ta ju u s O p p im in en O rg an is o in ti ta id o t So si aa lis et t ai d o t Ti et o is u u s V as tu u lli su u s Y h te is ty ö 1 X X X X X X X X X X X 2 X X X X X X X X X X X 3 X X X X X X X X X X X 4 X X X X X X X X X X X X X X 5 X X X X X X X X X X 6 X X X X X X X X X X X X X X 7 X X X X X X X X X X X X X X 8 X X X X X X X X X X X X 9 X X X X X X X X X X X X X X 10 X X X X X X X X X X X X X X 11 X X X X X X X X X X X X X X 12 X X X X X X X X X X X X X X 13 X X X X X X X X X X X X X X 14 X X X X X X X X X X X X X X 15 X X X X X X X X X X X X X X 16 X X X X X X X X X X X X X X 17 X X X X X X X X X X X X X X 18 X X X X X X X X X X X X X X 19 X X X X X X X X X X X X X X 38 Adaptoituminen on luontainen osa työskentelyä DevOps-organisaatiossa. Nopea rea- gointi asiakkaiden toiveisiin, teknisiin haasteisiin ja uuteen informaatioon vaatii, että henkilöstö kykenee adaptoitumaan erilaisiin tilanteisiin päivittäin. Tarve adaptoitumiselle alkaa heti muutosprosessin alkuvaiheessa, kun organisaation eri toimintoja yhdistetään tehokkaamman yhteistyön ja tiedonkulun tavoittelemiseksi. Sen sijaan että ohjelmiston elinkaaren eri vaiheet tapahtuisivat eri toimintojen alaisuudessa, ne yhdistetään saman organisatorisen yksikön alle kommunikaation siiloutumisen estä- miseksi. Tätä prosessia kutsutaan organisaation siilojen purkamiseksi. (Masombuka & Mnkandla, 2018) Tästä seuraa useimmiten tarve muuttaa jo olemassa olevia rooleja siten että ne sopivat muuttuneeseen organisaatiomalliin. Muuttuneet roolit vaativat organisaation henkilös- töltä kykyä adaptoitua uusiin rooleihinsa oppimalla uusia osa-alueita ohjelmistokehitys- prosessin elinkaaren eri vaiheista. Erityisesti ohjelmistokehityksessä työskentelevien henkilöiden tulee pystyä omaksumaan laaja-alaista osaamista yhteen osa-alueeseen eri- koistumisen sijaan. (Wiedemann & Wiesche, 2018; Wiedemann, Wiesche & Krcmar 2019) Kattava ymmärrys erilaisista konsepteista käytettävien tekniikoiden takana onkin olen- naisempaa kuin yksittäisten työkalujen tai kielten hallitseminen. (Pang, Hindle, & Bar- bosa 2020) Roolien muuttumisen seurauksena myös eri toimintojen vastuualueet muuttuvat. Ohjel- mistokehityksen ja ylläpidon tulee kantaa yhdessä vastuuta koko ohjelmiston elinkaa- resta. (Shropshire & Sweeney, 2017) Jaetun vastuun lisäksi tämän uuden toiminnon tulee jakaa arvot, kannustimet ja tavoit- teet. (Silva, Faustino, Pereira & Mira Da Silva 2018). Myös ohjelmistokehityksen prosessit tulevat todennäköisesti muuttumaan. DevOps-käy- täntöjen mukaisesti tämä tarkoittaa siirtymistä ketteriin menetelmiin. Stray, Moe ja Saltz ja Sutherland (2020) Aasheim (2019), Topi ja Spurrier (2019) nostavat esille ketterien menetelmien adaptoitumista vaativan luonteen. Tarve adaptoitua syntyy luonnostaa no- peissa sykleissä tapahtuvan iteratiivisen ohjelmistokehityksen sivutuotteena. 39 Ajatus oppimisesta ja nopeasti muutoksiin reagoimisesta on keskeisessä osassa ketterien menetelmien filosofisia periaatteita. (Babb, J. ja muut, 2017) Koko organisaation laajuinen muutosprosessi ei kuitenkaan ole kivuton vaan sen seu- rauksena saattaa syntyä muutosvastarintaa sekä pelkoa ja epäilystä uusia toiminta tapoja kohtaan. (van Belzen, Trienekens, & Kusters 2019) Olemassa olevan kulttuurin muokkaaminen on haasteellista. Se vaatii aiempaa aktiivi- sempaa kommunikaatiota olemassa olevien asenteiden muokkaamiseksi sekä mahdol- listen pelkojen ja epäilysten poistamiseksi. (Ghantous & Gill, 2017) Muutosprosessi tapahdu hetkessä vaan todennäköisesti osa toiminnoista adaptoituu uu- siin toiminta tapoihin muita nopeammin. (Gall & Pigni, 2018) Ennen kuin käytännöt vakiintuvat, tarvitaan organisaatiossa aktiivisempaa johtamista ja kommunikaatiota. Muutosprosessin alkuvaiheessa eri toiminnot saattavat tarvita aktii- vista ulkopuolista tukea ja seurantaa ennen kuin ovat täysin adaptoituneet muutokseen. (Silva, Faustino, Pereira & Mira Da Silva, 2018) Adaptoitumisen lisäksi DevOps-organisaatioissa vaaditaan henkilöstöltä jatkuvaa aktiivi- suutta. Avoimen kommunikaation periaatteen mukaisesti DevOps-tiimien jäsenten tulee jatkuvasti tietoisia ohjelmiston kehityksen tilasta ja jakaa aktiivisesti tietoa siitä mitä ovat tekemässä. (Masombuka & Mnkandla, 2018) Niissä työskentelee useiden eri ohjelmistokehityksen osa-alueiden asiantuntijoista, jotka tekevät yhteistyötä keskenään. Kommunikaatio vaatii siis myös mentoroivaa otetta ja sa- manaikaisesti aktiivista oppimista vastapuolelta. Työtä ei myöskään tehdä yksin vaan on- gelmia ratkotaan aktiivisesti ryhmässä. (Florea. & Stray, 2020; Wiedemann & Wiesche, 2018) Aktiivisen kommunikoinnin tarve ei rajoitu vain tiimin sisäiseen viestintään, vaan sitä tar- vitaan myös eri toimintojen välillä. Kun ohjelmistokehitykseen otetaan mukaan kaupalli- sia toimintoja, vaaditaan kaikilta osapuolilta aktiivista kommunikaatiota sekä organisoin- tia yhteistyön sujuvuuden takaamiseksi. (Forbig, 2018) 40 Aktiivisen työskentelykulttuurin ylläpitämiseksi ja yhteistyön tehostamiseksi organisaa- tion henkilöstö käy päivittäin lukuisa ad hoc-keskusteluja sekä tiimin sisällä että eri toi- mintojen kesken. (Stray, Moe &. Aasheim, 2019) Aktiivisuutta vaaditaan myös tiimien koordinoinnin ja riippuvuuksien hallinnan suhteen. Riippuvuuksilla tarkoitetaan sellaisia resursseja, joiden puuttuessa ohjelmistokehityksen jotain osa-aluetta ei voida edistää. Tiimien tavoitteiden potentiaaliset ristiriidat tulee tie- dosta jo suunnitteluvaiheessa. Tämän lisäksi suunnittelua tulee tehdä aktiivisesti jatku- van suunnittelun periaatteen mukaisesti. Riippuvuuksien tilaa tulee aktiivisesti seurata ja niiden tarpeet tulee tiedostaa etukäteen. Tämä on erityisen tärkeää niissä organisaa- tioissa, jotka ovat DevOps-muutosprosessin alkutaipaleella tai organisaatioissa, joissa useampi tiimi työskentelee saman tuotteen parissa. (van Belzen, Trienekens & Kusters, 2019; Wiedemann, Wiesche, Gewald & Krcmar, 2019) Aktiivisuuden lisäksi DevOps-organisaatioissa vaaditaan analyyttisiä ja ongelmanratkai- sutaitoja. Ne liittyvät olennaisesti ohjelmistokehitykseen, järjestelmien suunnitteluun ja niiden ylläpitoon. Niiden merkitys kasvaa nopeatempoisessa ympäristössä, jossa tois- tuva manuaalinen työ pyritään automatisoimaan. Organisaatioissa, joissa kyetään hyö- dyntämään automaatiota kattavasti, henkilöstö voi keskittyä aktiivisesti uuden kehittä- miseen ja ongelmakohtien ratkomiseen. Sekä uuden kehittäminen että olemassa olevien ongelmakohtien ratkominen vaativat organisaation henkilöstöltä analyyttisia- ja ongel- maratkaisutaitoja. Tämän vuoksi niiden merkitys korostuu DevOps-kontekstissa. Kattava automaation hyödyntäminen ei kuitenkaan poista järjestelmän ylläpidon ja monitoroin- nin tarvetta. Analyyttiset taidot ovatkin vahvasti sidoksissa ylläpitoon liittyviin tehtäviin DevOps-kon- tekstissa. Niiden varaan rakentuu henkilöstön kyky monitoroida, hallinnoida sekä kehit- tää kehitettävää järjestelmää. Ne liittyvät myös oleellisesti yksilön kykyyn abstraktoida kompleksisia ongelmia niiden ratkaisemiseksi. (Wiedemann & Wiesche, 2018) Analyyttiset- ja ongelmanratkaisutaitojen rooli korostuu erilaisissa poikkeustilanteissa, joissa DevOps-tiimin tulee kyetä reagoimaan nopeasti tekniseen ongelmaan. (Masom- buka & Mnkandla, 2018) 41 Jokaisen ohjelmistokehitystiimin jäsenen odotetaan osallistuvan vikatilanteissa ongel- man ratkaisemiseen ja analysointiin. Tätä pidetään erityisen tärkeänä koska nopean oh- jelmistokehityksen lisäksi yksi DevOps-käytäntöjen hyödyntämisellä tavoiteltava tekijä on kehittävän ohjelmiston luotettavuuden parantaminen. (Wiedemann, Wiesche & Krc- mar, 2019) Onkin tärkeää, että erityisesti ohjelmistokehitys tiimien jäsenet ymmärtävät korkean ta- son tekniset konseptit kehittävästä ja ylläpidettävästä järjestelmästä. DevOps-tiimien jä- seniltä vaaditaankin kattavaa kokemusta erilaisista tekniikoista ja työtehtävistä sekä hy- vää itseluottamusta ja ongelmanratkaisukykyä. (Pang, Hindle & Barbosa, 2020) Tarvittaessa henkilöstön on kyettävä oppimaan uusia konsepteja ja kieliä nopeasti. Tä- män lisäksi tiimien jäsenten tulee pyrkiä oppimaan virheistään ja yhdessä parantamaan ohjelmistokehitysprosessia aktiivisesti jatkuvan oppimisen periaatteen mukaisesti. (Babb, Nørbjerg, Yates & Waguespack, 2017; Topi & Spurrier, 2019) Itseluottamuksen lisäksi työskentely DevOps-organisaatiossa vaatii henkilöstöltä useita muita henkilökohtaisia ominaisuuksia. Henkilökohtaiset ominaisuudet ovat kokoelma yk- silön ominaisuuksia kuten itseluottamus, rohkeus, motivaatio tai paineen ja stressin sie- täminen. DevOps-kontekstissa esiin nousevat yhteistyötä, kommunikaatio, itsenäisyyttä ja itseoh- jautuvuutta sekä ongelman ratkaisua ja päätöksentekoa tukevat ominaisuudet. Yhteis- työn kannalta on olennaista, että henkilöstö luottaa toisiinsa, kykenee kommunikoimaan tehokkaasti sekä omaa vahvat ihmissuhdetaidot. Ongelmien ratkomiseksi nopea tempoi- sessa DevOps-organisaatiossa on taas olennaista, että henkilöstö kykenee rauhallisesti analysoimaan tilannetta, ratkaisemana ongelmia ja kykenee tekemään päätöksiä pai- neenkin alla. (Wiedemann & Wiesche, 2018) Yhteistyön sujuvuuden takaamiseksi tarvitaan myös hienovaraisempia ominaisuuksia ku- ten empatiakykyä ja kulttuurien ymmärtämistä ja tuntemusta. Eri sidosryhmien välisessä yhteistyössä ja kommunikaatiossa on olennaista kyetä ymmärtämään vastapuolen ti- lanne ja kulttuuritausta, josta tämä tulee. Nämä seikat auttavat oikean 42 kommunikaatiostrategian valitsemissa ja edesauttavat luottamuksen rakentamisessa osapuolten välille. (Babb, Nørbjerg, Yates, & Waguespack, 2017; Forbrig, 2018; Stray, Moe & Aasheim, 2019) Henkilökohtaiset ominaisuudet määrittävät myös, kuinka DevOps-muutosprosessi ote- taan organisaatiossa vastaan. Yksittäisten avainhenkilöiden heikko motivaatio, luontai- nen taipumus skeptisyyteen, epäluottamukseen sekä negatiiviseen ajatteluun saattaa vaikeuttaa prosessia ja jarruttaa kulttuurin kehittymistä. Muutoksen voidaan kokea lisää- vän stressiä ja painetta sekä pelkoa siitä, kuinka kykenee adaptoitumaan muutokseen, statuksen menettämisestä organisaatiossa, roolin muuttumisesta tai tarpeesta. (Stray, Moe & Aasheim, 2019) Tällaisessa tilanteessa tarvitaan aktiivista johtamista. Aktiivinen johtaminen vaatii kui- tenkin rohkeutta, paineen ja stressin sietämistä sekä itseluottamusta, jotta kykenee vai- kuttamaan muutosvastarintaan. Skeptisten ja epäluuloisten organisaation jäsenien mo- tivoiminen vaatii myös pitkäjänteisyyttä, empatiakykyä, kulttuurien ymmärtämistä sekä ongelmanratkaisukykyä ja ihmissuhdetaitoja. (Gall & Pigni, 2018) DevOps-organisaatioihin haetaankin ennakkoluulottomia motivoituneita yrittäjähenki- siä kiinnostuneita tiimipelaajia, jotka eivät pelkää muutosta tai paineen alla työskentelyä ja haluavat aktiivisesti oppia uutta. Erityisen tärkeää on virheiden myöntäminen, niistä oppiminen sekä niistä opittujen asioiden jakaminen. Tämä vaatii kuitenkin rohkeutta ja luottamusta muita kohtaan asettaa itsensä haavoittuvaan asemaan muiden edessä. Toi- saalta tämä taas vaatii muilta taas kykyä samaistua toisen asemaan ja kykyä oppia mui- denkin virheistä. (Kuusinen & Albertsen, 2019; Wiedemann 2018) Yksi DevOps-muutosprosessin tavoitteista on luoda ympäristö, joka edesauttaa innovaa- tioiden syntymistä. Yhdistämällä korkean automaation asteen, DevOps-viitekehyksen mukaisen kulttuurin, kattavan mittaamisen ja seurannan sekä tiedon jakamisen, organi- saatiot pyrkivät edesauttamaan innovaatioiden syntymistä. (Wiedemann, 2017) DevOps-tiimit muodostuvat ohjelmiston elinkaaren eri vaiheiden asiantuntijoista. Tätä osaamista saattaa täydentää kehitettävän tuotteen kohde toimialan hallitseva erikoisasi- antuntija tai kaupallisesta toiminnosta tuleva tuotteen omistajana. Tällainen asetelma 43 ruokkii innovaatiota kasvaneen kommunikaation ja yhteistyön ansiosta. (Wiedemann, 2017; Wiedemann, Wiesche, Gewald & Krcmar, 2019) Ketterien menetelmien mukaisesti iteratiivisesti tapahtuva ohjelmistokehitys mahdollis- taa nopean reagoinnin loppukäyttäjiltä saadun palautteen mukaan ja näin edesauttaa innovaatioiden synnyttämistä ja jakamista nopeasti eteenpäin. Jatkuvan innovaation edesauttamiseksi yhteistyö eri toimintojen välillä on ensiarvoiseen tärkeää. Tuotteen omistajan (product owner) tulee osallistua DevOps-tiimin toimintaan aktiivisesti tuoden asiakasrajapinnasta kerätyn tiedon lähemmäs varsinaista kehitysprosessia. Ideaalisessa tilanteessa tällä henkilöllä on kokemusta jostain muusta toiminnosta ja pystyy näin aut- tamaan kehitystiimiä innovoimaan täydentämällä tiimin osaamista omalla asiantuntijuu- dellaan. Tuotteen omistajan rooli korostuu erityisesti suunnitteluvaiheessa. Nopean rea- goinnin mahdollistamiseksi on ensiarvoisen tärkeää, että vastuualueet, riippuvuudet sekä iteraatiossa toteutettavien tehtävien laajuus suunnitellaan huolellisesti. (Wie- demann, Wiesche, Gewald & Krcmar, 2019) Innovaatiot DevOps-kontekstissa liittyvät useimmiten abstraktien ongelmien ratkomi- seen itsenäisesti tai yhteistyössä muiden kanssa. Kyky analysoida ja ratkoa erilaisia oh- jelmistokehityksen aikana eteen tulevia ongelmia on olennainen taito jokaiselle DevOps- tiimin jäsenelle. (Wiedemann & Wiesche, 2018) Itseohjautuvuus on olennainen taito DevOps-organisaation henkilöstölle. Itseohjautu- vuus nousee näkyviin erityisesti päätöksenteon, suunnittelun, johtamisen ja itsensä joh- tamisen yhteydessä. DevOps-tiimit ovat autonomisia yksiköitä, jotka koostuvat monialaisista osaajista, jotka työskentelevät keskenään kohti yhteistä päämäärää. Vaikka tiimillä onkin useimmiten määritelty johtohahmo, osallistuvat kaikki tiimin jäsenet kuitenkin aktiivisesti päätöksen tekoon tuoden mukanaan oman erikoistumisalueensa. Jokaisen tiimin jäsenen tulee kyetä kuitenkin tekemään päätöksiä tarvittaessa itsenäisesti. Tämä korostuu erityisesti poikkeustilanteissa, joissa tiimien jäsenien on kyettävä tekemään nopeita päätöksiä il- man ulkoista tukea ja paineen alla. Ideaalinen DevOps-tiimin jäsen onkin itseohjautuvat, nauttii päätöksenteosta ja ei pelkää vastuunottamista. Tiimin johtohahmon on taas 44 kyettävä ennakoimaan potentiaalisia ongelmia, riippuvuuksia ja hallinnoitava käytössä olevia resursseja. (Wiedemann, 2018; Wiedemann & Wiesche, 2018; A. Wiedemann, Wiesche, Gewald & Krcmar, 2019) Itsensä johtaminen liittyy vahvasti vastuun kantamiseen sekä kommunikaatioon. Jotta työntekijä suoriutuu vastuulleen annetuista tehtävistä, tulee tämän kyetä työskentele- mään tarvittaessa itsenäisesti. Itsenäinen työskentely sisältää työtehtävän suunnittelun, siihen tarvittavien resurssien koordinoinnin, tehtävän implementaation sekä tiedon ja- kamisen. Tämän lisäksi työntekijän tulee tarvittaessa tunnistaa potentiaaliset riippuvuu- det ja kommunikoida niiden tarpeesta aktiivisesti. (Stray, Moe & Aasheim, 2019) Osana DevOps-muutosprosessia organisaatioissa siirrytään pois vahvasti ylhäältä ohja- tusta korkean hierarkian mallista kohti matalan hierarkian mallia, joka muodostuu auto- nomisista yksiköitä. Tästä huolimatta DevOps-organisaatioissa halutuimpien ja etsityim- pien taitojen joukossa mainitaankin johtajuus. (Wiedemann, Wiesche & Krcmar, 2019; Kuusinen & Albertsen, 2019) Johtajuuden merkitys korostuu DevOps-muutosprosessin alkuvaiheessa, kun uudet käy- tännöt eivät ole vielä vakiintuneet organisaatiossa. Suuret muutokset organisaation toi- mintatavoissa, käytännöissä ja rooleissa aiheuttavat todennäköisesti muutosvastarintaa, skeptisyyttä sekä pelkoa ja epätietoisuutta. Näiden ongelmien ratkaisuksi vaaditaan ak- tiivista johtamista, jossa muutoksesta kommunikoidaan avoimesti ja aktiivisesti. (Shrop- shire & Sweeney, 2017; Gall & Pigni, 2018) Vaikka DevOps-tiimit ovatkin autonomisia yksiköitä, joiden jäsenet työskentelevät itse- ohjautuvasti niille valitaan yleensä johtohahmo (team lead). Tämä voi olla joko tuotteen omistaja tai yksi tiimin jäsenistä. Tämän johtohahmon vastuulla toimia tiimin edustajana ja fasilitoida kehitettävän ohjelmiston seuraavan iteraation suunnittelu. Tämän suunnit- teluprosessin aikana tiimin johtajan tulee huolehtia toteutettavien toimintojen laajuu- desta, mahdollisista riippuvuuksista sekä vastuu alueiden jakamisesta. (Stray, Moe, Aasheim 2019; Wiedemann, Wiesche, Gewald & Krcmar, 2019) Johtajuus on kuitenkin DevOps-kontekstissa enemmän palvelevaa johtamista kuin hal- linoivaa. Johtajan tehtävä on pyrkiä raivaamaan tiimin tieltä esteitä ja edesauttaa tiimiä 45 onnistumaan omassa tavoitteessaan. Timin jäsenille ei anneta suoraan käskyjä vaan heitä pyritään hienovaraisesti ohjaamaan oikeaan suuntaan. (Babb, Nørbjerg, Yates & Waguespack, 2017) Tällainen palvelevan johtamisen malli on sisään rakennettu Scrum-viitekehykseen. Mää- ritelmän mukaisesti scrum master toimii palvelevana johtajana ja kehitystiimin valmen- tajana, jonka tehtävänä on auttaa tiimiä eteenpäin raivaamalla potentiaalisia esteitä hei- dän tieltään. (Saltz & Sutherland, 2020) Tällaisissa organisaatioissa scrum master keventää tiimin muiden johtavien osien kuten tiiminjohtajan ja tuotteenomistajan taakkaa osallistumalla suunnitteluun, riippuvuuk- sien hallintaan sekä koordinointiin ja kommunikaatioon muiden tiimien välillä. Näin scrum master pystyy raivaamaan esteitä kehitystiimin tieltä ja antaa tiimin jäsenille mah- dollisuuden keskittyä itse ohjelmistokehitykseen. (Stray, Moe, Aasheim 2019) Oppiminen on keskeinen osa DevOps-kulttuuria. Uuden oppimiseen kannustetaan ja sitä odotetaan tapahtuvan jatkuvasti eri muodoissa. DevOps-tiimien jäsenet pyrkivätkin opiskelemaan uusia taitoja ja hyödyntävät aktiivisesti tilaisuuksia oppia jotain uutta. Tämä oppiminen saattaa olla muodollista opiskelua kuten verkkokursseja tai konferens- seihin osallistumista. Vaihtoehtoisesti se voi olla tiimin sisällä tapahtuvaa oppimista. Täl- lainen oppiminen voi tapahtua useissa eri muodoissa. Se voi olla kokeneemman tiimin jäsenen mentorointia, palautteen vastaanottamista, koodi katselmointia, pari ohjel- mointia, vasta opitun tiedon aktiivista jakamista, virheistä oppimista tai oman erikois- osaamisen jakamista muille tiimin jäsenille. (Wiedemann, Wiesche & Krcmar, 2019) Vikatilanteista pyritään myös aktiivisesti oppimaan analysoimalla mikä aiheutti poikkeus- tilanteen. Tätä käytäntöä kutsutaan Post Mortem-analyysiksi. Niissä kehittävästä ohjel- mistosta vastaava tiimi läpikäy yksityiskohtaisesti syitä siihen miksi tällainen tilanne pääsi syntymään ja kuinka se voitaisiin välttää tulevaisuudessa. (Shropshire & Sweeney, 2017) Organisaatioissa, joissa hyödynnetään Lean-ajattelua, voidaan pyrkiä analysoimaan asi- akkaiden reagointia tuotteeseen testaamalla Lean-hypoteeseja. Niiden ideana on luoda hypoteesi, kuinka loppukäyttäjä potentiaalisesti reagoi johonkin muutokseen 46 kehitettävässä ohjelmistossa. Tämän jälkeen ohjelmistokehitys tiimi luo minimaalisen testattavan toteutuksen ja analysoi kuinka loppukäyttäjät reagoivat tähän. (Saltz & Sut- herland, 2020) Ketterien menetelmien mukaisesti prosessia pyritään aktiivisesti kehittämään. Tasaisin väliajoin tapahtuvassa retrospektiivipalaverissa (retrospective) tiimin jäsenet läpikäyvät edellisissä kehityssykleissä tapahtuneita asioita. Niistä tarkastellaan onnistuneita ja epä- onnistuneita asioita oppimisen mahdollistamiseksi. Löydetyt asiat analysoidaan mahdol- lisimman tarkasti, jotta kehitystiimi pystyy arvioimaan syitä minkä takia jokin asia on on- nistunut tai epäonnistunut. Analysoinnin aikana opittujen tekijöiden avulla prosessia py- ritään hienosäätämään ennen seuraavaa ohjelmistokehityssykliä. Vaikka jatkuva integ- raatio ja julkaisu ovat keskeisiä tekijöitä DevOps-käytännöissä, voidaan joissain organi- saatioissa järjestää myös demotilaisuus ohjelmistokehityssyklin päätteeksi. Tämän tilai- suuden tarkoituksena on esitellä kehitettävän ohjelmiston tilaa eri sidosryhmille ja vas- taanottaa palautetta sekä kehitysehdotuksia tiimin ulkopuolelta. Tämän tilaisuuden ai- kana saadusta palautteesta saatuja oppeja voidaan hyödyntää seuraavien kehityssyklien ja ohjelmiston suunnittelussa. (Saltz, Sutherland, 2020) Babb, Nørbjerg, Yates, & Waguespack (2017) ilmaisevatkin huolensa siitä, että DevOps- käytäntöjen painotus automaation ja jatkuvaan integraatioon sekä julkaisuun heikentää ketterille menetelmille tyypillistä oppimista ja reflektointia ohjelmistokehityssyklien vä- lillä. He argumentoivat, että ketterien menetelmien adaptoiminen tällaiseen ympäris- töön saattaa johtaa niiden eroosioon. DevOps-tiimit ovat itseorganisoituvia yksiköitä jotka muodostuvat monialaisista osaa- jista joilla on yhteinen näkemys siitä miten ohjelmistokehityksen tehtävät tulisi organi- soida. Organisointikyky onkin oleellinen pehmeätaito DevOps-organisaatioissa. (Babb, Nørbjerg, Yates, & Waguespack, 2017; Wiedemann, Wiesche & Krcmar, 2019; Pang, Hin- dle & Barbosa, 2020) Organisointikyky on oleellinen osa itsenäistä työskentelyä. Jotta henkilö pystyy ratko- maan ongelmia ja tekemään loogisia päätöksiä paineen alla muiden puolesta tulee hä- nen kyetä organisoimaan saatavilla olevaa tietoa ja käytettävissä olevaa aikaa. Ollakseen 47 muiden tiiminjäsenien luottamuksen arvoinen tulee tiimin jäsenen tarvittavan asiantun- temuksen ja tietotaidon omaamisen lisäksi kyetä organisoimaan omaa työtään ja saata- villa olevia resursseja mahdollisimman tehokkaasti. (Masombuka & Mnkandla, 2018) Sen merkitys korostuu erityisesti ohjelmistokehityssykliä edeltävässä suunnittelussa, jossa DevOps-tiimien jäsenten tulee kyetä ennalta näkemään mahdollisia riippuvuuksia, resurssitarpeita tai muita implementaatiota estäviä tekijöitä sekä organisoida loppukäyt- täjiltä saatu palaute syklin aikana suoritettaviksi tehtäviksi. Näiden tehtävien laajuus ja potentiaaliset sivuvaikutukset tulee kyetä arviomaan, jotta tehtävät voidaan organisoida käytettäville henkilöstöresursseille. Tämän lisäksi on olennaista tehdä päätöksiä siitä mitkä tehtävistä otetaan mukaan tulevaan ohjelmistokehityssykliin niin että ne olisivat kaikki suoritettavissa ennen seuraavaa sykliä. (Wiedemann, Wiesche, Gewald & Krcmar, 2019) Epäonnistuminen resurssien organisoinnissa tarkoittaa käytännössä resurssien hukkaan heittämistä. Ohjelmistokehitysprojekteissa esiintyy kolmen tyyppisiä riippuvuuksia. Tieto riippuvuus tarkoittaa sitä, ettei ohjelmistokehitys on riippuvainen jonkin tiedon saamisesta. Prosessi riippuvuudella tarkoitetaan tilannetta, jossa ohjelmistokehitystä ei voida jatkaa ennen kuin jokin aiemmin prosessi on valmis. Viimeisimpänä ovat resurssi riippuvuudet. Niissä ohjelmistokehitystä ei kyetä jatkamaan ennen kuin tarvittava re- surssi on saatavilla. Jos ohjelmistokehityksen kannalta riippuvuutta ei saada ajoissa, jar- ruttaa tämä pahimmillaan koko ohjelmistokehitystä. Jo yksittäinen tällainen viivästys saattaa aiheuttaa koko projekti viivästymisen, jolla voi olla vaikutuksia koko organisaa- tion mittakaavassa. (Stray, Moe & Aasheim, 2019) Yhteistyö ja ihmisten välinen kanssakäyminen ovat merkittävässä roolissa DevOps-viite- kehystä. Noin puolet kehittäjien työajasta kuluu yhteistyössä muiden kanssa. Ongelmia ratkotaan ad hoc-keskusteluissa sekä tiimin sisällä että muiden toimintojen kanssa. (Ghantous. & Gill, 2017; Florea, & Stray , 2020; Stray, Moe & Aasheim, 2019) Sosiaaliset taidot ovat välttämättömiä sekä tiimin sisäisen että muiden sidosryhmien kanssa tapahtuvan kanssakäymisen mahdollistamiseksi. Ne luovat perustan yhteistyölle, joka on olennainen osa DevOps-viitekehyksen mukaista työskentelyä. Sosiaalisilla 48 taidoilla tarkoitetaan yksilön kykyä muodostaa ja ylläpitää sosiaalisia suhteita. Wie- demannin ja Wieschen (2018) mukaan DevOps-organisaatiossa työskentelyyn vaaditaan seitsemää erilaista sosiaalista taitoa. Ensimmäisenä he mainitsevat kyvyn vastaanottaa palautetta, joka on olennaista oppimisen ja henkilökohtaisen kehittymisen mahdollista- miseksi. Seuraavana listalla on kyky kommunikoida yleisön mukaisesti. Tämä on olen- naista eri toimintojen yhteistyön kannalta ja sen merkitys korostuu teknisten ja kaupal- listen toimintojen tehdessä yhteistyötä. Luontaisena jatkuman on kykyä oppia kulttuu- rien väliseen kommunikaatioon vaadittavia kommunikaatiotaitoja. Seuraavana listalla on halukkuus oppia uusia taitoja. Se on olennainen taito tiimin jokaiselle jäsenellä vastuun- jakamisen ja yhteistyön ylläpitämiseksi. Sen puuttuessa yhteistyö saattaa kärsiä koska vastuu ei tällöin jakaudu tasaisesti tiimin sisällä ja näin ollen johtaa huonompaan tehok- kuuteen. Sen jälkeen listalta löytyy halukkuus työskennellä tarvittaessa reaktiivisesti sekä ennaltaehkäisevästi. Nämä tekijät vaikuttavat oleellisesti siihen miten erilaiset poikkeus- tilanteet hoidetaan ja toisaalta, kuinka niitä voidaan pyrkiä välttämään tekemällä etukä- teen valintoja, joilla riskejä pyritään minimoimaan. Viimeiset kaksi kohtaa listalla ovat vahvasti sidoksissa toisiinsa: halukkuus jakaa tietoa ja halukkuus oppia muiden jaka- masta tiedosta. Nämä ovat olennaisia taitoja oppimisen ja henkilökohtaisen kehityksen kannalta mutta myös tiimin sisäisen yhteistyön toimivuuden takaamisen kannalta. Jotta tiimi voi iteratiivisesti kehittää toimintaansa ja tuotettavaa ohjelmistoa tai palvelua on olennaista, että tiimin jäsenet oppivat toisiltaan jatkuvasti. Tämä liittyy oleellisesti vah- voihin kommunikaatiotaitoihin. Ideaalisessa tilanteessa tiimin jäsenet kommunikoivat, luottavat toisiinsa ja rakentavat kulttuuria kommunikaation päälle. (Wiedemann & Wie- sche, 2018) DevOps-organisaation henkilöstön tulee aina pyrkiä olemaan aktiivisesti tietoinen siitä mitä organisaatiossa, että sen toimintaympäristössä tapahtuu. Tietoisuudella DevOps- kontekstissa tarkoitetaan henkilön luontaista kykyä ylläpitää tilannekuvaa. Tällaista tie- toisuutta vaaditaankin koko DevOps-organisaation henkilöstöltä. Avoimen kommunikaation periaatteen mukaan jokainen DevOps-tiimin jäsen tulee pitää 49 tietoisena kehitettävän ohjelmiston tilasta jatkuvasti sen koko elinkaaren ajan. Käytän- nössä tämä tarkoittaa sitä, että jokaisen tiimin jäsenen tulee aktiivisesti kertoa oman työnsä vaiheesta. Vastavuoroisesti muiden kehitystiimin jäsenten tulee aktiivisesti pyrkiä seuraamaan valittuja viestintä kanavia ollakseen tietoisia mitä ympärillä tapahtuu. Tie- don jakaminen on olennaista useista eri syistä. Sen avulla voidaan välttää ohjelmistoke- hityksessä tapahtuvia konfliktitilanteita, se toimii yhteistyön mahdollistajana ja samalla yhteen sitoo ohjelmistokehitystiimiä. Tämän lisäksi ohjelmistokehitystiimin jäsenien pi- tää olla tietoisia palvelun ylläpitoon liittyvistä asioista kuten palvelun tila, käännös- ja julkaisuautomaation tila sekä käytettävissä olevista resursseista. (Masombuka & Mnkan- dla, 2018) Jos kehitystiimillä on ulkoisia riippuvuuksia organisaation muihin toimintoihin tai organi- saation ulkopuolelle, on tietoisuus niiden tilasta ensiarvoisen tärkeää. Tällaisia riippu- vuuksia voivat olla jotkin artefaktit, jotka puuttuessaan estävät ohjelmistokehityksen tai haittaavat sitä. Tietoisuus tällaisten riippuvuuksien tilasta on erityisen merkityksellistä suunniteltaessa seuraavaa ohjelmistokehityssykliä. (Wiedemann, Wiesche, Gewald & Krcmar, 2019) Näiden lisäksi on ohjelmistokehitystiimin oltava aktiivisesti tietoisia kehitettävää ohjel- mistoa ja/tai palvelua koskevista laatuvaatimuksista kuten palvelulaatusopimuksista. Tä- hän liittyen on olennaista, että kehitystiimin jäsenet ovat tietoisia siitä mitä seuraa, jos näitä laatuvaatimuksia ei kyetä täyttämään. (Wiedemann & Wiesche, 2018) Tietoisuutta vaaditaan myös DevOps-kulttuurinmuutosprosessin kannalta. Erityisen tär- keää on, että organisaation jäsenet ovat tietoisia käynnissä olevasta muutoksesta ja siitä mitä se tarkoittaa päivittäisen työskentelyn kannalta. Tämän vuoksi ad hoc-muutospros- essi on mahdollista vain tilanteessa, jossa koko ohjelmistokehitysorganisaatio on tietoi- sia muutoksen tuomista eduista. (Wiedemann, 2018) Epätietoisuus vallitsevasta tilanteesta saattaa aiheuttaa muutosvastarintaa ja erilaisia pelkotiloja muutosta koskien, joka hidastaa muutoksen jalkautumista ja jolla saattaa olla pitkäaikaisia ei toivottuja sivuvaikutuksia. Tällaiset ongelmat on kuitenkin mahdollista eliminoida aktiivisella tiedon jakamisella. (Gall & Pigni, 2018) 50 Kyky kantaa vastuuta on olennainen taito DevOps-organisaatioissa. Se on vahvasti sidok- sissa yhteen DevOps-kulttuurin keskeiseen teemaan, yhteiseen omistajuuteen. Yhteinen omistajuus tarkoittaa, että koko DevOps-tiimi jakaa vastuun kehittämästään ohjelmistosta sekä sen tarjoamisesta. Tämä antaa kehitystiimille vapaat kädet tehdä pää- töksiä järjestelmän suhteen mutta samalla sitoo kehittäjät vastuuseen omasta työnjäl- jestään. Vikatilanteissa tiimin jäsenten on kyettävä tarvittaessa tekemään vastuullisia päätöksiä muun tiimin puolesta itsenäisesti. (Wiedemann, Wiesche & Krcmar, 2019; Silva, Faustino, Pereira & Mira Da Silva, 2018) Vastuu palvelusta tarkoittaa sitä, että tiimi on myös vastuussa kehitettävän ohjelmiston ja/tai palvelun suunnittelusta. Koska tiimi on vastuussa kehitettävän tuotteen implemen- toinnista, julkaisusta ja ylläpidosta tulee tämä huomioida suunnitteluvaiheessa. Tiimin on kannettava vastuu kehitettävän ohjelmiston laadusta, tietoturvasta sekä skaalautu- vuudesta. Suunnitteluvastuu kuitenkin samalla edesauttaa vastuun kantamisessa. Kun suunnitteluprosessi tapahtuu tiimin sisällä voivat sen jäsenet luottaa siihen, ettei uusia vaatimuksia ilmaannu tiimin ulkopuolelta ilman että ne otetaan huomioon suunnitte- lussa. (Wiedemann, Wiesche, Gewald & Krcmar, 2019) Yhteisen vastuun kantamisen kannalta on olennaista, että jokainen DevOps-tiimin jäsen ymmärtää eri roolit ja niiden vastuualueet. Jokaisen tulee ymmärtää roolien vastuualu- eet, mitä tämän roolien täyttämiseksi odotetaan, miten rooleissa suoriutumista mitataan ja arvioidaan sekä mitä niissä epäonnistumisesta seuraa. Joissain organisaatioissa oppi- misen tehostamiseksi voidaan vastuualueita vaihtaa tiimin jäsenten kesken syklisesti si- ten että tiimin jäsenet oppivat eri roolit ja niiden vaatimukset. (Masombuka & Mnkandla, 2018; Wiedemann, 2017) Yhteistyökyky on ehdottoman tärkeä pehmeätaito DevOps-organisaation henkilöstölle. Yhteistyö on koko DevOps-kulttuurin kulmakivi, jonka päälle koko kulttuuri rakentuu ja samalla yksi muutosprosessin keskisistä tavoitteista. Yhdistämällä eri toimintoja useampia eri ohjelmistonelinkaaren eri vaiheiden asiantun- tijoita sisältäviksi autonomisiksi DevOps-tiimeiksi organisaatiot pyrkivät kasvattamaan yhteistyön määrää. Tällainen organisaation uudelleen järjestely edesauttaakin eri 51 asiantuntijoiden välisen kommunikaation ja yhteistyön syntymistä, kun tiimin jäsenet työskentelevät yhteistä tavoitetta kohti. (Wiedemann, Wiesche, & Krcmar, 2019) DevOps-kontekstissa yhteistyö muodostuu neljästä eri tekijästä: kommunikaatiosta, vas- tuusta, kunnioituksesta ja luottamuksesta. Kommunikaatio rakentuu avoimen kommuni- kaation periaatteen päälle, jossa DevOps-tiimin jäsenten odotetaan jakavan tietoa avoi- mesti keskenään ja pitävän muut ajan tasalla omasta työstään. Vastuulla tarkoitetaan yhteisvastuuta järjestelmän toimivuudesta sekä kehitettävästä ohjelmistosta. Kunnioitus tässä yhteydessä tarkoittaa DevOps-tiimin jäsenten keskinäistä kunnioitusta. Jokaista jä- sentä tulee kunnioittaa arvokkaana tiimin jäsenenä ja arvostaa tämän kontribuutiota yh- teisen maalin saavuttamiseksi. On myös olennaista, että eri rooleissa toimivia henkilöitä kunnioitetaan tämän periaatteen mukaisesti siten, ettei yksikään rooleista ole arvok- kaampi kuin toinen. Tiimin jäsenten välinen luottamus on tärkeää yhteistyön kannalta. Tehokkaan yhteistyön takaamiseksi tiimin jäsenten on kyettävä asettamaan itsensä vä- lillä haavoittuvaan asemaan ja luottamaan siihen, etteivät muut tiimin jäsenet hyväksi- käytä tätä heikkoutta. Tämä toimii samalla avoimen kommunikaation mahdollistajana. (Masombuka & Mnkandla, 2018) Yhteistyö ei kuitenkaan rajoitu vain DevOps-tiimien sisäiseen toimintaan. DevOps-orga- nisaatioissa eri toiminnot saattavat tehdä yhteistyötä keskenään. Tämän vuoksi onkin oleellista, että tiimien jäsenet ymmärtävät sen toimialueen, jossa toimivat ja siihen liit- tyvät prosessit. (Wiedemann & Wiesche, 2018) 4.9 Tulokset Tutkimuksen tuloksena tutkittavista julkaisuista tunnistettiin yhteensä 23 kappaletta uniikkeja pehmeitä taitoja. Tulokset sekä niiden kuvaukset löytyvät taulukosta 5. Kuvauk- set pyrkivät havainnollistamaan mitä yksittäiset pehmeät taidot tarkoittavat DevOps- kontekstissa. Ne eivät kuitenkaan ole tarkkoja kuvauksia tuloksena saaduista yksittäisistä pehmeistä taidoista. 52 TAULUKKO 5. Tutkimuksen tulokset Pehmeätaito Kuvaus Adaptoituminen Kyky adaptoitua muutokseen Aktiivisuus Kyky aktiiviseen kommunikaation, aulius osallistua Analyyttiset taidot Kyky kerätä ja analysoida tietoa sekä käyttää tätä tietoa Avoimuus Avoimuus uusia asioita kohtaan, Haavoittuvuus Kyky asettaa itsensä haavoittuvaan asemaan Innovatiivisuus Kyky innovoida, ajatella laatikon ulkopuolelta Itseluottamus Alttius luottaa itseensä Itsenäisyys Kyky työskennellä itsenäisesti ilman ulkoista valvontaa Itseohjautuvuus Kyky ohjata omaa toimintaansa ilman ulkoista valvontaa Johtajuus Kyky johtaa muita Kommunikaatiotaidot Kyky kommunikoida tehokkaasti Kulttuurien tunteminen Eri kulttuurien ymmärtäminen ja hyväksyminen Luottamus Kyky luottaa muihin sekä olla itse luottamuksen arvoinen Ongelmanratkaisukyky Kyky ratkoa ongelmia ja ongelmatilanteita Oppiminen Kyky ja alttius oppia uutta Organisointitaidot Kyky organisoida omaa työtään, resursseja ja projekteja Päätöksen tekeminen Kyky tehdä päätöksiä Stressin sietäminen Alttius sietää ulkoista painetta ja stressiä Rohkeus Kyky tehdä rohkeita valintoja Sosiaaliset taidot Kyky luoda ja ylläpitää sosiaalisia suhteita Tietoisuus Tietoisuus itsestä ja ulkopuolisista tekijöistä Vastuullisuus Kyky kantaa vastuuta Yhteistyö Kyky tehdä yhteistyötä muiden kanssa 53 5 Diskussio Tutkimuksen tavoitteena oli löytää sellaiset pehmeät taidot, joita DevOps-viitekehys vaa- tii organisaation henkilöstöltä. Tutkimuksen tuloksena löytyi 23 kappaletta pehmeitä tai- toja, joten tutkimusta voidaan pitää onnistuneena. Olemassa olevaa tutkimusta peh- meistä taidoista, joita DevOps-viitekehys vaatii organisaation henkilöstöltä ei ole ole- massa tai se ei ole helposti saatavilla. Sen sijaan olemassa oleva tutkimus keskittyy tut- kimaan DevOps-viitekehyksen vaatimia taitoja kokonaisuutena erottelematta kovia ja pehmeitä taitoja. Tämä tutkimus laajentaakin olemassa olevaa tietoa keskittymällä puh- taasti pehmeisiin taitoihin. 5.1 Tulosten merkitys DevOps-viitekehyksen suosio on kasvanut viime vuosina huomattavasti ja sen kasvun oletetaan jatkuvan vielä lähitulevaisuudessa. Sen suosiota ovat nostaneet menestysta- rina markkinoiden edellä kävijöistä kuten Googleta ja Amazonilta. Saman aikaisesti orga- nisaatiot etsivät uusia toimintatapoja toimintojen siirtyessä sähköiseen muotoon digita- lisaation seurauksena. (Global Industry Analysts Inc., 2020) Samanaikaisesti kasvava automaation hyödyntäminen eri toimialoilla on kasvattanut kiinnostusta pehmeisiin arvoihin. Kasvava automaation aste tarkoittaa sitä, että organi- saatioiden henkilöstöstä yhä pienempi osa tekee sellaisia työtehtäviä, joissa suoriutumi- nen vaatii pääsääntöisesti vain kovia taitoja. Jäljelle jäävät tehtävät nojaavat kasvavassa määrin pehmeisiin taitoihin kuten ongelmanratkaisuun ja ryhmätyöhön. (Bishop, 2019) Tässä uudenlaisessa työympäristössä ihmiset työskentelevät monimuotoisissa ryhmissä, jotka muodostuvat eri kulttuureista, ikäryhmistä ja joiden jäsenet saattavat sijaita eri puolilla maapalloa. Tällaisessa ympäristössä henkilöstöltä vaaditaan kattavasti erilaisia pehmeitä taitoja kuten kulttuurien ymmärrystä, kykyä ryhmätyöhön ja tehokkaaseen kommunikaatioon. (Dean ja East, 2019, s.1) Samanaikaisesti DevOps-viitekehyksen suosion kasvaessa yksityisellä sektorilla on yli- opistoilla painetta kyetä huomioimaan ilmiö omissa koulutusohjelmissaan. Pelkästään DevOps-organisaatioissa useimmiten käytettyjen työkalujen ja toimintatapojen 54 opettaminen ei yksin riitä vaan opetusohjelmissa tulee kyetä huomioimaan myös De- vOps-kulttuuri. Kulttuurin syntymisen mahdollistavia tekijöitä ovat jaetut arvot, tavoit- teet sekä toimintatavat, onnistumisen määrittely, yhteinen omistajuus, kunnioitus, luot- tamus, jatkuva kommunikaatio, kokeileminen ja oppiminen. (Kuusinen ja Albertsen, 2019) Nousevan suosion seurauksena tarve tutkimukselle ja tiedolle nousee käytäntöjä sovel- tavien organisaatioiden määrän kasvaessa. DevOps-viitekehys itsessään sisältää useita teemoja, jotka korostava pehmeiden taitojen merkitystä kuten jatkuva oppiminen, avoin kommunikaatio, yhteistyö ja empatia. Tulevaisuudessa vaikuttavien tekijöiden ennuste- taankin olevan varsin hyvin linjassa sekä DevOps-viitekehyksen mukaisen toiminnan kanssa kuin myös tämän tutkimuksen fokuksen kanssa. Koko työelämää koskeva muutos, jonka myötä pehmeiden taitojen merkitys korostuu todennäköisesti lisääkin kiinnostusta niihin myös DevOps-kontekstissa. Tutkimuksen tuloksia voidaankin potentiaalisesti hyö- dyntää sekä akateemisessa ympäristössä että kaupallisten toimijoiden taholta. Tutki- muksen tulokset tarjoavat pohjan tulevalle tutkimukselle koskien pehmeitä taitoja De- vOps-kontekstissa. Samanaikaisesti ne tarjoavat lähtökohdan, jota oppilaitokset voivat hyödyntää tulevien opetusohjelmien ja kurssien suunnittelussa. Kuusinen ja Albertsen (2019) nostavat esiin DevOps-kulttuurin ja sen mahdollistavien tekijöiden opetuksen. Nämä kulttuurin mahdollistavat tekijät ovat vahvasti sidoksissa pehmeisiin taitoihin, joi- den opetuksessa tutkimuksen tuloksia voidaan potentiaalisesti hyödyntää. Kaupallisten toimijoiden on mahdollista hyödyntää tutkimuksen tuloksia lukuisissa eri sovelluskohteissa. Tuloksia voidaan käyttää esimerkiksi henkilöstöhallinnon toimesta työkaluna rekrytointiprosessissa, henkilöstön koulutusta suunniteltaessa sekä organisaa- tion rakenteen muutoksien suunnitteluun. Toisaalta ne mahdollistavat myös yksittäisten henkilöiden soveltuvuuden arvioimisen DevOps-organisaatioon. 5.2 Tulosten luotettavuus Tutkimuksessa on pyritty noudattamaan hyvä tieteellistä käytäntöä eli sen aikana on noudatettu tieteellisen yhteisön tunnustamia toimintatapoja. Sen aikana on pyritty re- hellisyyteen, yleiseen huolellisuuteen ja tarkkuuteen tutkimustyössä, tulosten 55 tallentamisessa, niiden esittämisessä ja tutkimuksen sekä tulosten arvioinnissa. Tutki- muksessa käytettiin tiedonhankinta, tutkimus- ja arviointimenetelminä tieteellisen tut- kimuksen kriteerit täyttäviä eettisesti kestäviä menetelmiä. Siinä on otettu huomioon muiden tutkijoiden työ ja saavutukset kunnioittavalla ja asianmukaisella tavalla viittaa- malla heidän julkaisuihinsa asianmukaisella tavalla sekä antamalla niille asiaan kuuluvan tunnustuksen. (Tutkimuseettinen neuvottelukunta, 2021) Tutkimusprosessin kaikki vaiheet on dokumentoitu ja tutkimusprosessi on suoritettu tä- män dokumentaation mukaisesti. Tiedon hankintaan käytettiin tunnettuja, tunnustettu- jen organisaatioiden tietokantoja julkaisujen laadun takaamiseksi. Tutkimuksessa on käy- tetty julkaisuja, jotka ovat vapaasti saatavilla, jotta tutkimuksen tulokset voidaan tarvit- taessa todentaa. 5.3 Tulokset suhteessa olemassa olevaan tutkimukseen Olemassa olevaa tutkimusta, joka keskittyisi ainoastaan siihen millaisia pehmeitä taitoja DevOps-viitekehys vaatii organisaation henkilöstöltä, ei ole olemassa tai sitä ei ole hel- posti saatavilla. Sen sijaan tutkimusta verrataan olemassa olevaan tutkimukseen siitä, millaisia taitoja DevOps-organisaatiossa vaaditaan. Olemassa olevassa tutkimuksessa ja kirjallisuudessa käsitellään pehmeitä arvoja hajanaisesti, joka mahdollistaa tämän tutki- muksen vertaamisen olemassa olevaan tutkimukseen. Vaikka nämä tutkimukset eivät keskity puhtaasti pehmeisiin taitoihin voidaan niiden avulla todentaa tämän tutkimuksen tulosten olevan samassa linjassa olemassa olevan tutkimuksen kanssa. 5.4 Suositukset soveltamiseen Tutkimuksen tuloksia on mahdollista soveltaa sellaisenaan. Koska kyseessä on jatkuvasti kehittyvä ja laaja-alainen ilmiö, on sovellettaessa suositeltavaa käyttää tukena myös muita julkaisuja. Riippuen sovelluskohteesta tulee pohtia ovatko kaikki listatut taidot re- levantteja tässä käyttötapauksessa. Tämän tutkimuksen tulokset ovat koko organisaation kattava listaus niistä pehmeistä taidoista, joita työskentelyyn tarvitaan. Tutkimus ei ota kantaa siihen millaisissa taitoja tarvitaan eri rooleissa. Tämän lisäksi jokainen 56 organisaatio on yksilöllinen, joka on syytä huomioida sovellettaessa. Myös pehmeiden taitojen luonne tulee ottaa huomioon sovellettaessa. Tutkimuksessa ei ote kuitenkaan kantaa siihen miten näiden taitojen tulee esiintyä vaan ne ovat jokaiselle yksilöllisiä. 5.5 Suositukset tulevalle tutkimukselle Tutkimuksen tulokset ovat listaus pehmeistä taidoista, joita työskentelyyn DevOps-orga- nisaatiossa tarvitaan. Olemassa olevan tiedon lisäämiseksi tulevassa tutkimuksessa olisi paljon potentiaalia pyrkiä hienovaraisemmin jaottelemaan tätä listausta. Eri pehmeiden taitojen tarpeen jakautuminen roolin tai organisaation muutosprosessin vaiheen mu- kaan lisäisi tiedon sovellettavuutta. Tämän lisäksi organisaation koolla, toimialalla ja or- ganisaatiomallilla saattaa olla vaikutusta tarvittaviin taitoihin. Tämän lisäksi tutkimus ei ota kantaa siihen millaisia painoarvoja eri taidoille tulisi antaa. Nämä painotukset poik- keavat potentiaalisesti toisistaan, riippuen organisaation koosta, organisaatiomallista tai tuotettavasta lopputuotteesta. On myös mahdollista, että tarvittavien taitojen painotuk- set ovat riippuvaisia organisaation maantieteellisestä sijainnista. Toinen potentiaalisesti vaikuttava tekijä on etätyön määrä organisaatiossa. 5.6 Arviointi Tutkimuksessa käytettyjen julkaisujen määrä on pieni, joka rajoittaa tulosten luotetta- vuutta. Tutkimuksessa on kuitenkin huomioitu DevOps-viitekehyksen jokainen osa-alue puolueettomasti. Tutkimuksessa on myös huomioitu DevOps-ilmiön jatkuva kehitys siten että jokainen siinä käytetty julkaisu on korkeintaan 5 vuotta vanha. Sekä pehmeät taidot että DevOps ovat vailla yleisesti hyväksyttyä määritelmää. Tästä syystä kumpikin termi on määritelty tässä tutkimuksessa erikseen. Vaikka käytetyt mää- ritelmät ovat varsin geneerisiä, tulee tämä asia huomioida tuloksia tarkasteltaessa. Koska pehmeät taidot ovat myös konteksti sidonnaisia, tulee myös tässä tutkimuksessa määri- telty konteksti ottaa huomioon. 57 Lähteet Sosiaali- ja terveysministeriö. (2016). Digitalisaatio terveyden ja hyvinvoinnin tukena. Sosiaa li- ja terveysministeriön digitalisaatiolinjaukset 2025. Noudettu 27.1.2021 osoitteesta https://julkaisut.valtioneuvosto.fi/bitstream/han- dle/10024/75526/JUL2016-5-hallinnonalan-ditalisaation-linjaukset- 2025.pdf?sequence=1 Koch, T. & Windsperger, J. (1. Toukokuuta 2017). Seeing through the network: Competi- tive advantage in the digital economy. J Org Design 6, 6 (2017). DOI: https://doi.org/10.1186/s41469-017-0016-z DevOps Research & Assestment. (2019). Accelerate: state of DevOps 2019. Noudettu 30.1.2021 osoitteesta https://cloud.google.com/devops/state-of-devops/ Amazon Web Services. (2021). What is DevOps. Noudettu 31.1.2021 osoitteesta https://aws.amazon.com/devops/what-is-devops/ Global Industry Analysts, Inc. (2020). DevOps - Global Market Trajectory & Analytics. Noudettu 31.1.2021 osoitteesta https://www.researchandmarkets.com/re- ports/4804823/devops-global-market-trajectory-and-analytics Bishop, C. (2019) The Need For Soft Skills Training Grows As Automation Transforms The Workplace, Forbes, Noudettu 17.4.2021 osoitteesta: https://www.for- bes.com/sites/forbeshumanresourcescouncil/2019/04/25/the-need-for-soft- skills-training-grows-as-automation-transforms-the-workplace/ Dean, S.A., East, J.I. (2019) International Journal of Applied Management and Technology 2019, Volume 18, Issue 1, Pages 17–32 DOI:10.5590/IJAMT.2019.18.1.02 58 Forsgren, N., Humble, J. & Kim, G. (2018) Accelerate - Building and Scaling High Perfor- ming Technology Organisations. IT Revolution ISBN: 978-1942788331 DevOps Research & Assestment. (2021) Explore DORA's research program. Noudettu 31.1.2021 osoitteesta https://www.devops-research.com/research.html Ravichandran, A., Taylor, K. & Waterhouse, P. (2016) DevOps Foundations. In: DevOps for Digital Leaders. Apress, Berkeley, CA. DOI: https://doi.org/10.1007/978-1-4842- 1842-6_3 Sharma, S. (2017) The DevOps Adoption Playbook: A Guide to Adopting DevOps in a Multi-Speed IT Enterprise, ISBN: 978-1-119-30874-4 Tutkimuseettinen neuvottelukunta (2020) Hyvä tieteellinen käytäntöä (HTK), Noudettu 17.4.2021 osoitteesta: https://tenk.fi/fi/tiedevilppi/hyva-tieteellinen-kaytanto- htk Figalist, I., Biesdorf, A., Brand, C., Feld, .S & Kiermeier, M., (2019) Supporting the DevOps Feedback Loop using Unsupervised Machine Learning, 2019 IEEE International Symposium on INnovations in Intelligent SysTems and Applications (INISTA), Sofia, Bulgaria, 2019, pp. 1-6, DOI: 10.1109/INISTA.2019.8778283. Okoli, C. & Schabram, K. (2010). A Guide to Conducting a Systematic Literature Review of Information Systems Research. Sprouts: Working Papers on Information Sys- tems, 10(26) Noudettu 7.2.2021 osoitteesta https://www.academia.edu/down- load/3250666/OkoliSchabram2010SproutsLitReviewGuide.pdf Heckman, J. & Kautz, T. (2012). Hard evidence on soft skills. Labour Economics, Volume 19, Issue 4 2012, S.451-464, ISSN 0927-5371, DOI: https://doi.org/10.1016/j.la- beco.2012.05.014 59 Jabbari, .R, Ali .N & Petersen, .K, Tanveer.B (2016). What is DevOps? A Systematic Map- ping Study on Definitions and Practices. The Scientific Workshop XP2016, DOI: https://doi.org/10.1145/2962695.2962707 Davis, J. & Daniels, R. (2019) Collaborating in DevOps Culture. GitHub. Noudettu 7.2.2021 osoitteesta: https://resources.github.com/downloads/CollaboratingDevOpsCul- ture.pdf Dyck, .A, Penners, .R & Lichter, .H (2015). Towards Definitions for Release Engineering and DevOps. Release Engineering (RELENG), 2015 IEEE/ACM 3rd International Workshop on, vol., no., pp.3,3, 19-19 May 2015, DOI: https://doi.org/10.1109/RELENG.2015.10 Davis, .J & Daniels, .R. (2016) Effective DevOps. O’Reilly Media, ISBN: 9781491926307 Lippman, .L, Ryberg, .R, Carney, .R & Moore, .A (2015). Workfoce connections: Key ”soft skills” that foster youth workforce success: towards consensus across field. Child trends. Child Trends Publication 2015‐24, Noudettu 21.2.2021 osoitteesta: http://www.childtrends.org/wp-content/uploads/2015/06/2015-24WFCSoftS- kills1.pdf Schulz, .B. (2008). The importance of soft skills: Education beyond academic knowledge. Nawa Journal of Communication, 2(1), 146-154. Noudettu 21.2.2021 osoitteesta: http://ir.nust.na/handle/10628/39 Cimatti, .B. (2016). Definition, development, assessment of soft skills and their role for the quality of organizations and enterprises. International Journal for Quality Re- search. 10. 97-130. DOI: http://dx.doi.org/10.18421/IJQR10.01-05 60 Bancino, .R & Zevalkink, .C. (2007). Soft Skills: The New Curriculum for Hard-Core Tech- nical Professionals. Techniques: Connecting Education and Careers. 82. Noudettu 21.2.2021 osoitteesta: https://www.researchgate.net/publica- tion/234603133_Soft_Skills_The_New_Curriculum_for_Hard-Core_Techni- cal_Professionals Ahmed, F., Capretz, L. F., Salah, .B & Campbell, .P. (2013). Soft Skills and Software Deve- lopment: A Reflection from the Software Industry. International Journal of Infor- mation Processing and Management, 4(3):171-191, 2013. DOI: https://ar- xiv.org/abs/1507.06873 Ahmed, F., Capretz, L. F. & Campbell, .P. (2012) Evaluating the Demand for Soft Skills in Software Development, IT Professional, vol. 14, no. 1, 44-49, 2012, DOI: https://doi.org/10.1109/MITP.2012.7 Salminen, A. (2011). Mikä kirjallisuuskatsaus?: Johdatus kirjallisuuskatsauksen tyyppei- hin ja hallintotieteellisiin sovelluksiin. Vaasan Yliopisto. Opetusjulkaisuja 62 Jul- kisjohtaminen 4. Noudettu 7.3.2021 osoitteesta: https://osuva.uwasa.fi/bitstream/handle/10024/7961/isbn_978-952-476-349- 3.pdf?sequence=1 Schryen, G. (2015) "Writing Qualitative IS Literature Reviews—Guidelines for Synthesis, Interpretation, and Guidance of Research," Communications of the Association for Information Systems: Vol. 37, Article 12. DOI: https://doi.org/10.17705/1CAIS.03712 Babb, J., Nørbjerg, J., Yates, D.J .& Waguespack, L.J., (2017) The Empire Strikes Back: The end of Agile as we know it? .Selected Papers of the IRIS, Issue Nr 8 (2017) Nou- dettu 22.2.2021 osoitteesta: https://aisel.aisnet.org/iris2017/8 61 Florea, R. & Stray, V. (2020) A Qualitative Study of the Background, Skill Acquisition, and Learning Preferences of Software Testers. In Proceedings of the Evaluation and Assessment in Software Engineering (EASE '20). Association for Computing Machinery DOI:https://doi.org/10.1145/3383219.3383252 Forbrig, P. (2018). BizDevOps and the Role of S-BPMProceedings of the 10th International Conference on Subject-Oriented Business Process Management. Association for Computing Machinery, New York, NY, USA, Article 1, 1–8. DOI:https://doi.org/10.1145/3178248.3178250 Ghantous, G.B. & Gill, A. (2017) DevOps: Concepts, Practices, Tools, Benefits and Chal- lenges. PACIS 2017 Proceedings. 96. Noudettu 22.2.2021 osoitteesta: http://ai- sel.aisnet.org/pacis2017/96 Kuusinen, K. & Albertsen, S. (2019) Industry-academy collaboration in teaching DevOps and continuous delivery to software engineering students: towards improved in- dustrial relevance in higher education. Proceedings of the 41st International Confe-rence on Software Engineering: Software Engineering Education and Trai- ning IEEE Press, 23–27. DOI:https://doi.org/10.1109/ICSE-SEET.2019.00011 Gall, M., Pigni, F. (2018) Leveraging DevOps for mission critical software. Noudettu 22.2.2021 osoitteesta: https://aisel.aisnet.org/amcis2018/ITProjMgmt/Presen- tations/2/ Masombuka, .T & Mnkandla, E. (2018) A DevOps collaboration culture acceptance mo- del. In Proceedings of the Annual Conference of the South African Institute of Computer Scientists and Information Technologists (SAICSIT '18). Association for Computing Machinery, New York, NY, USA, 279–285. DOI:https://doi.org/10.1145/3278681.3278714 62 Pang, C., Hindle, A.,& Barbosa, D. (2020) Understanding devops education with grounded theory. In Proceedings of the ACM/IEEE 42nd International Conference on Soft- ware Engineering: Software Engineering Education and Training (ICSE-SEET '20). Asso-ciation for Computing Machinery, New York, NY, USA, 107–118. DOI:https://doi.org/10.1145/3377814.3381711 Saltz, J., Sutherland , A. (2020) SKI: A New Agile Framework that supports DevOps, Con- tinuous Delivery, and Lean Hypothesis Testing, Proceedings of the 53rd Hawaii In- ternational Conference on System Sciences. Noudettu 22.2.2021 osoitteesta: https://aisel.aisnet.org/hicss-53/st/agile_development/4/ Shropshire, J. & Sweeney, B. (2017) On Devops and Workforce Morale. SAIS 2017 Pro- ceedings. 12. Noudettu 22.2.2021 osoitteesta: https://aisel.ais- net.org/sais2017/12 Silva, M., Faustino, J., Pereira, R., & Mira Da Silva, M. (2018). Productivity Gains of De- vOps Adoption in an IT Team: A Case Study., Designing Digitalization (ISD2018 Pro-ceedings) Noudettu 22.2.2021 osoitteesta: http://aisel.ais- net.org/isd2014/proceedings2018/ISDevelopment/8 Topi, H. ja Spurrier, G. (2019) Invited Paper: A Generalized, Enterprise-Level Systems De- velopment Process Framework for Systems Analysis and Design Education, Jour- nal of Information Systems Education: Vol. 30 : Iss. 4 , 253-265. Noudettu 22.2.2021 osoitteesta: https://aisel.aisnet.org/jise/vol30/iss4/6 Stray, V., Moe, N. B., Aasheim, A. (2019). Dependency Management in Large-Scale Agile: A Case Study of DevOps Teams. Proceedings of the 52nd Hawaii International Con-ference on System Sciences. Noudettu 22.2.2021 osoitteesta: https://ai- sel.aisnet.org/hicss-52/st/agile_development/8/ 63 van Belzen, M., Trienekens, J. & Kusters, R. (2019). Critical Success Factors of Conti-nuous Practices in a DevOps Context. In A. Siarheyeva, C. Barry, M. Lang, H. Linger, & C. Schneider (Eds.), Information Systems Development: Information Systems Bey- ond 2020 (ISD2019 Proceedings). Toulon, France: ISEN Yncréa Méditerranée. Nou- dettu 22.2.2021 osoitteesta: https://aisel.aisnet.org/isd2014/procee- dings2019/ISDMethodologies/6/ Wiedemann , A., Wiesche, M. & Krcmar, H. (2019) Integrating Develoment and Operati- ons in Cross-Functional Teams - Toward a DevOps Competency Model. Procee- dings of the 2019 on Computers and People Research Conference. Association for Computing Machinery, New York, NY, USA, 14–19. DOI:https://doi.org/10.1145/3322385.3322400 Wiedemann, A. & Wiesche, M. (2018) "ARE YOU READY FOR DEVOPS? REQUIRED SKILL SET FOR DEVOPS TEAMS". Research Papers. 123. Noudettu 22.2.2021 osoitteesta: https://aisel.aisnet.org/ecis2018_rp/123 Wiedemann, A. (2017) A New Form of Collaboration in IT Teams - Exploring the DevOps Phenomenon. PACIS 2017 Proceedings. 82. Noudettu 22.2.2021 osoitteesta: https://aisel.aisnet.org/pacis2017/82 Wiedemann, A. (2018). IT Governance Mechanisms for DevOps Teams - How Incumbent Companies Achieve Competitive Advantages. Noudettu 22.2.2021 osoitteesta: https://aisel.aisnet.org/hicss-51/os/it_governance/7/ Wiedemann, M. Wiesche, H. Gewald, H. Krcmar. (2019) Implementing the Planning Pro- cess within DevOps Teams to Achieve Continuous Innovation. Noudettu 22.2.2021 osoitteesta: https://aisel.aisnet.org/hicss-52/st/agile_development/9/ Tuomi, J. & Sarajärvi, A. (2002). Laadullinen tutkimus ja sisällönanalyysi. Helsinki: Tammi.