Ohjelmistoprojektien johtaminen ja ryhmädynamiikka

Transkriptio

1 Ohjelmistoprojektien johtaminen ja ryhmädynamiikka Harjoitus 3 Ryhmä JMJ Jouni Varis Johanna Joentausta Mikko Siukola

2 Johdanto... 1 Ohjelmistokehityksen historiaa... 1 Ketterä kehitys... 2 Scrumban... 2 Sosiaaliset representaatiot... 4 Yhteenveto... 6 Lähteet... 6

3 Johdanto Tämä kirjoitus käy läpi Fabian Fagerholmin vierailuluennon pohjalta ohjelmistotuotantokehityksen historiaa, ketterien menetelmien kehittymistä sekä sosiaalista representaatiota. Luennolla piti pohtia johtuuko ketterien menetelmien suosio sosiaalisista syistä, ja ovatko ne kehitetty pelkästään sosiaalipsykologian kannalta. Vastaus ei ole yksikäsitteinen. On selvää, että vesiputousmalli ei ole parhaalla mahdollisella tavalla toimiva, joten jo se yksistään on luonut tarpeen toimivammille menetelmille. Ketterien menetelmien kehittäminen on myös kiistatta tuonut kehittäjilleen rahaa kirjojen ja konsultaatioiden myötä, eikä tällaista taloudellista aspektia pidä bisnesmaailmassa vähätellä. Yhden mallin kehittäminen on mahdollistanut rinnakkaisten menetelmien luomisen ja nykyinen tilanne onkin, että yhden vesiputousmallin on korvannut useat eri ketterät menetelmät. Ketterien menetelmien käsite on tästä johtuen melko häilyvä. Ketterät menetelmät tarjoavat lähinnä erilaisia periaatteita, joita kukin voi soveltaa haluamallaan tavalla. Yritykset voivat usein markkinoida itseään ketterien menetelmien käyttäjänä, mutta esimerkiksi pelkän Scrumista tutun päiväpalaverin käyttäminen ei vielä tee projektista ketterää, jos muut käytännöt ovat kankeita ja hitaita, sekä sisältävät paljon arvoa tuottamatonta työtä. Ohjelmistokehityksen historiaa Ohjelmistotuotannon juuret yltävät aina 1940 luvulle asti. Vuonna 1968 otettiin käyttöön termi Software Engineering ja samoihin aikoihin koettiin ohjelmistokriisi. Kriisi johtui pitkälti ohjelmistokehitystä tukevien menetelmien puuttumisesta. Koska menetelmiä ei vielä ollut, omaksuttiin rautapuolen suunnittelumalli insinöörimaailmasta pienin muutoksin ohjelmistotuotantoon 1970-luvulla. Tämä malli tunnetaan vesiputousmallina. Mallin esitteli Winston W. Royce vuonna 1970, mutta ei itse suositellut kyseisen mallin käyttöä [1]. Hänen alkuperäinen ideansa oli, että järjestelmästä tehdään ensin prototyyppi ja lopullinen suunnittelu vasta prototyypin pohjalta. Vesiputousmalli perustuu eri vaiheisiin, jotka suoritetaan omassa järjestyksessään, eikä tarkoitus ole palata vaiheissa takaisin. Vesiputousmallissa sosiaalista vuorovaikutusta asiakkaan kanssa tehdään vain projektin alussa ja lopussa. Mallissa pyritään täydellisiin määrittelyihin ja suunnitelmiin heti projektin alussa, jotta vältyttäisiin jälkikäteen tehdyiltä muutoksilta. Tämä on kuitenkin huomattu ongelmalliseksi, koska täydellisen tarkka määrittely etukäteen on mahdotonta ja lopputulos voi jo valmistuessaan olla vanhentunut, sillä firmojen tarpeet muuttuvat, toisin kuin esimerkiksi tarve sillasta, jolla on vain yksi käyttötarkoitus. Tätä ongelmaa ratkaisemaan kehitettiin 2000-luvun alussa ketterän kehityksen periaatteet. 1

4 Ketterä kehitys Helmikuussa vuonna 2001 koettiin läpimurto ohjelmistokehityksessä, kun 17 ketterän kehityksen asiantuntijaa loivat julistuksen nimeltä Agile Manifesto [2]. Tällä haettiin vaihtoehtoisia lähtökohtia perinteiseen lineaariseen ohjelmistokehitykseen. Nämä asiantuntijat paljastivat omia parempia tapojaan kehittää ohjelmistoja ja jakoivat nämä tiedot myös muille. Tarkoituksena oli, että muutkin pystyisivät rakentamaan parempia ohjelmistoja. He päätyivät seuraaviin ohjelmistokehityksen parannuksiin: yksilöt ja vuorovaikutukset mieluummin kuin prosessit ja työkalut, toimiva ohjelmisto mieluummin kuin kokonaisvaltainen dokumentaatio, asiakasyhteistyö mieluummin kuin sopimusneuvottelut ja muutoksiin reagoiminen mieluummin kuin suunnitelman noudattaminen. Vuorovaikutus yksilöiden välillä helpottaa tiedonkulkua. Toimiva ohjelmisto antaa tietoa siitä, kuinka nopeasti tuloksia saadaan aikaiseksi, koska toteutetun työn määrästä voidaan arvioida paljonko tarvitaan mahdollisesti lisää aikaa, että loputkin toiminnot on toteutettu. Toimivasta ohjelmistosta saadaan myös nopeaa palautetta, jonka pohjalta voidaan tehdä muutoksia. Vuorovaikutukseen on erilaisia tapoja. Asiakkaan kanssa voidaan pitää säännöllisesti palaveri, esimerkiksi viikon tai kahden jälkeen, tai järjestää tapaaminen vain silloin, kun on aidosti jotain uutta esiteltävää. Vesiputousmenetelmästä tutun dokumentoinnin laajuuden korvaa jatkuvasti tapahtuva vuorovaikutus asiakkaan kanssa. Asiakasyhteistyö tarkoittaa, että asiakas ja muut sidosryhmät ovat vahvasti mukana kehityksessä. Pelkkien sopimusten tekeminen ei siis riitä, jos halutaan yrittää rakentaa hyvää ohjelmistoa. Suunnitelmat yleensä vanhentuvat nopeasti. Tällöin ei kannata keskittyä alkuperäisiin suunnitelmiin, vaan on tärkeää mieluummin keskittyä tarvittaviin muutoksiin. Ketterät menetelmät rohkaisevatkin olevaan avoimia muutoksille. Scrumban Scrumban on ketterään ohjelmistokehitykseen kehitetty menetelmä, joka pohjautuu Scrumja Kanban-menetelmiin, joiden lisäksi mukana on Lean-ajattelua [4]. Scrumista sovelletaan yleensä ainakin päivittäisiä kokouksia ja muita käytäntöjä, joita tiimi haluaa käyttää. Kanbanmenetelmästä käytetään työvaiheiden hallinnointiin ja seurantaan tarkoitettua Kanbantaulua. Lean-menetelmistä sovelletaan sen tärkeintä periaatetta, hukan minimointia eli arvoa tuottamatonta työtä. Scrumissa päivittäiset palaverit koostuvat jokapäiväisistä maksimissaan 15 minuutin mittaisista kokouksista, joissa jokainen käy läpi mitä on tehnyt viimeisen kokouksen jälkeen, ja mitä aikoo tehdä ennen seuraavaa kokousta. Scrumbanissa päivittäiset kokoukset pidetään Scrum-masterin ohjaamana Kanban-taulun ääressä ja kokous koskee taulun sisältöä. Tarkoituksena on jakaa tietoa, ei ratkaista esimerkiksi teknisiä ongelmia. Myös Scrum-tyylinen päiväkokous voidaan halutessaan pitää. 2

5 Scrumbanissa käytettävä Kanban-taulu koostuu sarakkeista ja korteista. Sarakkeet kuvastavat työvaihetta ja kortit itse työtehtäviä. Yksinkertaisimmillaan sarakkeita on kolme, jotka ovat esimerkiksi: aloittamattomat tehtävät, työn alla olevat tehtävät, valmiit tehtävät. Tarvittaessa voidaan lisätä sarakkeita lisää, joita voisivat olla esimerkiksi: määrittelyssä, suunnittelussa, testauksessa, testattu ja niin edelleen. Yksinkertainen Kanban-taulu on kuvattu kuvassa 1. Kuva 1. Yksinkertainen Kanban-taulu [4] Maksimimäärä työn alla olevia työtehtäviä on rajoitettu, kuten Kanbanissa (Work In Progress). Voidaan esimerkiksi määritellä, että jokaisella henkilöllä voi olla maksimissaan kaksi samanaikaista työtehtävää työn alla ja koko tiimillä maksimissaan tietty määrä. Myös kussakin tilassa olevaa työmäärää voidaan rajoittaa. Uuden työtehtävän saa aloittaa vasta kun edellinen vaihe on valmis. Työtehtävien laajuudet tulee selvittää tiimin sisällä. Jos työtehtävien tekemiseen kuluu paljon aikaa, työn alla olevien tehtävien määrä kasvaa. Tällöin esimerkiksi testaus joutuu odottamaan toteutukselta lisää testattavaa. Tehtävien laajuuksien asettaminen ei ole välttämättä helppo tehtävä, ja siihen tarvitaan paljon kokemusta. Pakkaantuvat kortit kuitenkin paljastavat hyvin eri tehtävistä johtuvat pullonkaulat ja ongelmat. Scrum-menetelmä perustuu usein noin kahden viikon iteraatioihin [5]. Iteraatioiden ja niissä suoritettavien tehtävien suunnittelemiseen kuluu usein paljon aikaa, joka voi olla usein vain enemmänkin hukkaa, eli arvoa tuottamatonta työtä. Kanbanissa ja Scrumbanissa ohitetaan iteraatioiden suunnittelu. Tehtäviä otetaan backlogilta sitä mukaa, kun tehtäviä valmistuu. Tietyissä vaiheessa, kun esimerkiksi kokonaisuuksia on valmiina, voidaan tehdä julkaisuja. Näin työn virtaus eli flow säilyy jatkuvasti. Alla oleva kuva 2 kuvaa Kanban-menetelmässä tapahtuvaa työn virtausta. 3

6 Kuva 2. Ideaali Kanban-menetelmän työnkulku [5]. Sosiaaliset representaatiot Sosiaaliset representaatiot ovat ryhmän tai yhteisön tapa jäsentää tietoa, joka on olennaista ryhmän jäsenyydelle. Sosiaalinen representaatio tavallaan tarjoaa yhteisölle oman kielen ja siten mahdollisuuden keskinäiseen interaktioon. Sosiaaliset representaatiot liittyvät myös arkitietoon ja tarjoavat välineitä tapahtumien tulkintaan. Tämä käsite on erityisen hyödyllinen silloin, kun halutaan kuvata ja selittää ryhmän toimintaa ilman arvoja ja asenteita, joita niitäkin usein käytetään ryhmien kuvaamiseen ja erottamiseen toisistaan. Termin keksijän Serge Moscovicin mukaan Sosiaaliset representaatiot sisältävät olettamuksen kahdesta perusprosessista: objektivoinnista ja ankkuroinnista [3]. Objekvointiprosessissa tuntemattomat ja abstraktit käsitteet liitetään osaksi arkirealiteettien joukkoa. Ankkuroinnissa taas uutta tietoa jäsennetään tavalla, joka aina liittää sen johonkin aiempaan: esimerkiksi yhteisö, joka kuulee jumalasta ensimmäistä kertaa, saattaa sosiaalisessa representaatiossaan rinnastaa sen isän käsitteeseen. Näin uudet asiat saadaan osaksi ryhmän yhteistä tietämystä. Vuoden 2001 Agile Manifesto oli yksi suoraviivainen esimerkki tietoisesta ankkuroinnista, mutta ankkurointia tapahtuu jatkuvasti myös epäsuorasti ja muun toiminnan sivutuotteena. Kun esimerkiksi ryhmän jäsen määrittelee puheessaan uuden käsitteen jollain tavalla ja muu ryhmä hyväksyy sen, tapahtuu samalla uuden tiedon ankkurointia vaikka se ei olisikaan ollut tapahtuneen kommunikoinnin varsinainen päämäärä. Voi ajatella, että ryhmän sosiaalisen representaation intuitiivinen tuntemus on välttämätöntä ryhmään kuulumiselle. Kyse on siitä, että ryhmän jäsen hallitsee kaiken sellaisen yleisen ryhmälle tarpeellisen metatiedon, jonka kaikki tietävät. Ryhmän ulkopuolisille tällainen tieto voi helposti jäädä selittämättömäksi. Kun yksilö liittyy ryhmään, tämä omaksuu aluksi välttämättömät osat ryhmän sosiaalisesta representaatiosta. Sosiaalinen representaatio on kuitenkin jatkuvasti elävä ja kehittyvä kokoelma tietoa, joten vähitellen ryhmän jäsen alkaa osaltaan itsekin rakentaa kyseistä 4

7 representaatiota. Tämä ei tapahdu tietoisesti vaan automaattisesti ryhmän toimiessa yhdessä: tuttuun kehykseen liitetään lisää tietoa. Osaltaan nämä representaatiot myös selittävät sitä, miksi pitkään yhdessä ollut ryhmä saattaa toimia omalla alallaan todella tehokkaasti, vaikka ryhmän yksilöt eivät erillisinä olisi yhtään sen taitavampia kuin juuri kootun vertailuryhmän henkilöt. Johtaminen ja ongelmankäsittely Scrumban-menetelmässä jokaisella ryhmällä on valmentaja, jonka tehtävänä on saada ryhmä toimimaan mahdollisimman hyvin. Jokaisen ryhmän toiminnassa saattaa ilmetä ongelmia, jotka ryhmäongelmina ovat mallinnettavissa sosiaalipsykologian käsitteistön avulla. Ryhmällä on sosiaalipsykologian katsantokannalta useita johtajia. Nämä voidaan jaotella karkeasti toiminta- ja tunnejohtajiksi, joista ensinmainitut kulkevat edellä käytännön asioissa ja tekevät niihin liittyviä päätöksiä käytännössä, vaikka heillä ei esimerkiksi yrityksessä olisikaan mitään titteliä. Tällaisiksi johtajiksi valikoituu yleensä ryhmästä se, joka on osaavin tai muuten parhaiten perillä kulloinkin ratkottavana olevasta ongelmasta. Toisaalta tunnejohtajat vastaavat ryhmän ilmapiiristä ja mahdollisesti esimerkiksi siitä, että kaikkia ryhmän jäseniä kuullaan. On syytä huomata, että edellä mainitut johtajat eivät välttämättä ole missään virallisessa asemassa, eivätkä välttämättä edes tiedosta olevansa johtajia. Kuitenkin tällaisia ryhmän edelläkävijöitä löytyy ryhmistä usein, ja ne ovat tärkeitä ryhmän suoriutumiselle. Ohjelmistotuotantoryhmästä oikeasti vastuussa oleva henkilö, yleensä valmentaja, toimii tehokkaimmin mikäli keskittyy vaikuttamaan näiden epävirallisten toiminta- ja tunnejohtajien kautta. Tarkkailemalla heitä on mahdollista löytää ryhmää eri asioissa parhaiten edustava henkilö, jonka kautta koko ryhmän voi hyvin tavoittaa. Ryhmissä voi olla myös henkilöitä, jotka näkevät ryhmän toiminnassa ongelmia, mutta eivät koe olevansa siinä asemassa, että voisivat puuttua ongelmiin, jolloin he eivät sano mitään. Tämänkaltaisia tilanteita voi yrittää ratkoa esittämällä kysymyksiä ja johdattelemalla henkilöä oikeaan suuntaan. On tärkeää luoda ilmapiiri, jossa ketään ei arvostella tai syyllistetä. Muita ongelmia voi olla, että prosessin mukaan pitäisi sitoutua vain muutamaan asiaan kerrallaan, mutta tiimi ei noudata tätä. Kanban-taulua ei myöskään välttämättä pidetä ajan tasalla. Kaikkien tulee olla motivoituneita käyttämään ja päivittämään taulua, mutta vastuussa olevan henkilön tehtävä on pitää siitä huoli, että taulu pysyy reaaliajassa. Tiimin jäsenten motivaatiota taulua kohtaan voidaan parantaa esimerkiksi leikkimielisillä kilpailuilla, joissa kisataan kenen tiimillä on hienoin Kanban-taulu. 5

8 Yhteenveto Ketterät menetelmät syntyivät tarpeesta parantaa toisaalta ohjelmistoprosessien sisäistä tehokkuutta ja toisaalta ottaa enemmän huomioon asiakkaan todellisia tarpeita lisäämällä vuorovaikutusta. Ketterät menetelmät eivät ole saavuttaneet mitään päätepistettä, vaan ne kehittyvät jatkuvasti useaan eri suuntaan. Scrumban on yksi tuoreimmista ketterän kehityksen menetelmistä. Se yhdistää parhaiksi katsomiaan puolia Scrumista, Kanbanista sekä Lean-ajattelusta. Menetelmä pyrkii työn jatkuvaan virtaamiseen rajoittamalla yhdellä hetkellä työn alla olevien tehtävien lukumäärää. Menetelmä myös kuvaa ketterien menetelmien kehitystä yleisemmin: kehitys on rönsyilevää, ja uusia menetelmiä syntyy yhdistelemällä hyviksi todettuja puolia aiemmista menetelmistä. Koska ketterien menetelmien ytimessä on ihmisten välinen vuorovaikutus ja ohjelmistokehitystä tehdään lähes aina jonkinlaisissa ryhmissä, on luontevaa hakea apua sosiaalipsykologian kentältä. Sosiaalipsykologia tarjoaa työvälineitä erilaisten ryhmäongelmien, erityisesti ns. tunneongelmien, ratkaisuun. Johtaminen ketterissä projekteissa on usein käytännössä hajautettua. Ryhmistä löytyy erilaisia tilanne- ja tunnejohtajia, jotka voivat olla vetovastuussa eri tilanteissa. Näitä rooleja ei ole välttämättä tietoisesti otettu tai annettu, vaan ovat tulosta ryhmäläisten keskinäisistä kemioista ja vahvimmista osaamisalueista. Johtajaksi valikoituu yleensä sellainen henkilö, joka parhaiten ilmentää ryhmän toimintatapoja ja osaamista. Lähteet [1] Managing the development of large software systems [2] Highsmith J., Cockburn A., Agile software development: the business of innovation. Computer, vol. 34, no. 9, 2001, s tp=&arnumber=947100&isnumber=20507 [3] Helkama, Myllyniemi, Liebkind, Johdatus Sosiaalipsykologiaan, Oy Edita Ab, 2001 [4] [5] 6