Projektiryhmä Tete Work-time Attendance Software. Henkilökohtainen SE harjoitus: loppuraportti

Transkriptio

1 Projektiryhmä Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: loppuraportti Pariohjelmointi Mika Lindroos

2 T Software Project/Tietojenkäsittelyopin ohjelmatyö 2(12) Muutosloki Versio Pvm Tekijä Kuvaus Mika Lindroos Ensimmäinen versio I1-vaiheesta Mika Lindroos Päivitetty versio I2-vaiheesta Mika Lindroos Loppuraportti I3-vaiheen jälkeen Mika Lindroos Oikoluettu loppuraportti valmis palautusta varten

3 T Software Project/Tietojenkäsittelyopin ohjelmatyö 3(12) Sisällysluettelo Johdanto Arvionti I1-vaiheesta Metriikat I1-vaiheesta Johtopäätöksiä I1-vaiheen metriikoista Arvionti I2-vaiheesta Metriikat I2-vaiheesta Johtopäätöksiä I2-vaiheen metriikoista Arviointi I3-vaiheesta Yhteenveto Johtopäätöksiä kyselyn tuloksista... 9 Loppusanat...11

4 T Software Project/Tietojenkäsittelyopin ohjelmatyö 4(12) Johdanto Tässä dokumentissa esittelen henkilökohtaisen SE harjoitukseni, pariohjelmoinnin, käyttöä projektimme aikana. Ensimmäiseksi esittelen arviot pariohjelmoinnin käytöstä jokaisen yksittäisen vaiheen kohdalla metriikoineen, minkä jälkeen esittelen koko projektin aikaisen pariohjelmoinnin käyttöä koskevan kyselytutkimukseni tulokset. Lopuksi kokoan saadut tulokset yhteen ja teen niistä joitakin johtopäätöksiä pariohjelmoinnin käytöstä tällaisen projektin yhteydessä. Vaihekohtaisten arviointien yhteydessä on hyvä huomata, että ne ovat tehty välittömästi kyseisen vaiheen jälkeen, joten ne sisältävät jonkin verran pohdintaa myös tulevien vaiheiden mahdollisista vaikeuksista pariohjelmoinnin kannalta. Jälkikäteen on varsin mielenkiintoista verrata myös oletusten ja toteutuneiden asioiden suhdetta toisiinsa. Samoin on valaisevaa nähdä missä kohdin oli tehty turhan optimistisia oletuksia ja mahdollisesti tämän pohjalta välttää tulevaisuudessa vastaavat ongelmat. 1. Arvionti I1-vaiheesta Käytimme pariohjelmointia I1-vaiheen alussa suunnitelman mukaan järjestelmällisesti, mutta vaiheen loppupuolella käytännön rajoitteiden takia jouduimme hieman poikkeamaan pariohjelmoinnin käytöstä. Suurin käytännön ongelma oli ilman muuta asiakkaan lupaaman testipalvelimen toimimattomuus, joka aiheutti sen, että kaikki kehitystyö oli käytännössä tehtävä ryhmäläisten omilla kotikoneilla tai muuta kautta käytössä olevalla palvelimella (esim. työpaikan kone). Kaikilla ei kuitenkaan ollut mahdollisuutta pystyttää omaa palvelinta etäkäytettäväksi, joten pariohjelmoidessa oli mentävä jomman kumman kotikoneelle ohjelmoimaan. Toinen pariohjelmoinnin käyttöä rajoittanut tekijä oli tämän vaiheen tiukka aikataulu, joka aiheutti ongelmia yhteisen ajan löytämiseksi parin jäsenten välillä. Näistä syistä johtuen pariohjelmointia ei käytetty suunnitellussa määrin, eikä saatuja tuloksia voida vielä missään nimessä pitää täysin totuudenmukaisina tai kattavina. I1-vaiheen alussa tuli esille myös muutamia rajoitteita pariohjelmoinnin suhteen. Tiiviin aikataulun vuoksi pariohjelmointikertoja joutui sopimaan varsin aikaisessa vaiheessa ja niinpä ainakin yhdelle parille kävi niin, että toteutusympäristö ei ollut vielä täydessä toimintakunnossa ohjelmointia aloitettaessa. Näin ollen parilta kului ylimääräistä aikaa ympäristön ongelmien selvittelyyn, mikä luonnollisesti näkyy pariohjelmoinnin tehokkuuden kärsimisessä; yhden ohjelmoijan sijasta kaksi ohjelmoijaa istui ratkomassa teknisiä ongelmia, pahimmillaan saamatta mitään merkittävää edistystä aikaan. Pariohjelmointi antoi I1-vaiheen aikana kuitenkin viitteitä myös tarjoamistaan hyödyistä. Kun teknisten ongelmien aiheuttamat harmit oli selvitetty, päästiin varsinaiseen pariohjelmointiin käsiksi ja tuottamaan varsinaista ohjelmakoodia. Näiden ohjelmointikertojen aikana tuli erityisesti pariohjelmoinnin oppimisvaikutus hyvin esille käytettäessä kokenut-kokematon ohjelmoijapareja. Näin ollen pariohjelmointia ei ole syytä tuomita vielä I1-vaiheen tulosten perusteella vaan sen käyttöä jatketaan mahdollisuuksien mukaan seuraavissa vaiheissa. I2-vaiheessa oleva joululoma aiheuttaa omat haasteensa pariohjelmoinnin käytölle, mutta vastaavasti testipalvelimen saaminen käyttöön jossain vaiheessa helpottaa osaltaan työskentelytilaongelmaa. 1.1 Metriikat I1-vaiheesta Taulukko 1. Pariohjelmoinnin käyttö ja järjestelmätestauksessa löydetyt bugit käyttötapauksittain (I1)

5 T Software Project/Tietojenkäsittelyopin ohjelmatyö 5(12) Use case Pariohjelmoinnin kokonaistyötunnit Yksinohjelmoinnin kokonaistyötunnit Pariohjelmointisuhde (pariohjelmoidut tunnit/kokonaistunnit) Bugeja (Blocker / Critical / Major / Minor / Trivial) UC 1.1 Log in % 2 (0/0/0/2/0) UC 1.2 Log out UC 2.1 Report hours for a work category UC 3.1 View reported hours UC 4.1 Add user UC 4.4 View user list UC 5.1 Add work category (0/0/0/1/0) % 9 (0/0/2/7/0) % 2 (0/0/0/2/0) % 3 (0/0/0/3/0) (0/0/0/0/1) (0/0/0/1/1) Johtopäätöksiä I1-vaiheen metriikoista Ylläolevassa taulukossa esitetyt luvut eivät ole täysin vedenpitäviä, koska teknisten ongelmien ratkomiseen käytettyä aikaa on osittain kirjattu käyttötapausten toteutuksen alle. Lisäksi Log out-käyttötapauksen tunteja ei ole kirjattu ollenkaan kyseisen käyttötapauksen alle, vaikka kyseinen toiminnallisuus onkin toteutettu. Näiden tuntien voidaan olettaa olevan muiden käyttötapausten alla olevien tuntien yhteydessä. Kaksi viimeistä käyttötapausta toteutettiin alkuperäisen suunnitelman lisäksi, joten niille ei ollut Trapolissa omaa Task-kenttäänsä. Näihin käytettyjen tuntien sijainnista tuntikirjanpidossa ei ole tarkkaa tietoa. Vielä yksi huomioitava seikka luvuista on se, että pariohjelmointia on käytetty pääsääntöisesti käyttötapausten ensimmäistä versiota tehtäessä kun taas havaittujen ongelmien paikkaukset on tehty pääsääntöisesti ohjelmoimalla yksin. I1-vaiheen tulosten pohjalta on turha tehdä kovinkaan pitkälle meneviä johtopäätöksiä. Eräs silmiinpistävä asia luvuista voidaan kuitenkin havaita. Ainoat havaitut minor-luokitusta vakavammat viat ja lukumäärältään suurin vikamäärä havaittiin kokonaistyömäärältään suurimmassa käyttötapauksessa UC 2.1. Tässä käyttötapauksessa myös pariohjelmoinnin käyttösuhde oli matalampi kuin kahdessa muussa käyttötapauksessa UC 1.1 ja UC 4.1. Vastaesimerkkinä voidaan kuitenkin esittää käyttötapaus UC 3.1, jossa saatiin hyviä tuloksia täysin ilman pariohjelmointia. Kuten sanottu on näistä tuloksista kuitenkin liian aikaista tehdä vedenpitäviä johtopäätöksiä ja pariohjelmointi näyttänee todelliset ominaisuutensa vasta tulevissa vaiheissa.

6 T Software Project/Tietojenkäsittelyopin ohjelmatyö 6(12) 2. Arvionti I2-vaiheesta I2-vaihetta voidaan pitää varsin menestyksekkäänä pariohjelmoinnin näkökulmasta. Asiakkaan lupaama testipalvelin saatiin vihdoin käyttöön iteraation alkupuolella ja tämä helpotti olennaisesti pariohjelmoinnin käyttöä, koska parit pystyivät työskentelemään myös koululta käsin. Iteraation alkuun sijoittunut joululoma aiheutti sen, että iteraation alussa työskentely oli varsin yksilöpainotteista ja jokainen teki töitä lähinnä silloin kun itsellä oli lomalla sopivasti aikaa. Tästä syystä suurin osa iteraation työmäärästä sijoittui kaikenkaikkiaan muutamalle tammikuun viikolle. Joululoman jälkeen tammikuun alusta alkanut työskentely sisälsi runsaasti varsinaista ohjelmiston toteutusta, toisin kuin vielä I1-vaiheessa, jossa oli melko paljon myös muuta vaadittua tehtävää. I2-vaiheessa toteutetaan merkittävä osa ohjelmiston toiminnallisuudesta ja niinpä tämä vaihe on ehkä paras tilaisuus eri ohjelmointimenetelmien väliseen vertailuun. Tämän vaiheen kuluessa käytettiin runsaasti sekä pari- että yksinohjelmointia, joten sikälikin tulosten pitäisi antaa jonkinlaista osviittaa eri menetelmien hyödyistä ja haitoista. Havaittavaa on, että suurin osa ohjelmoinnista oli edelleen yksinohjelmointia, mutta pariohjelmoinnin määrää voidaan pitää suhteellisen hyvänä kun otetaan huomioon, että joululoma vei lähes puolet iteraatiosta. Aivan kaikki ryhmäläiset, eivät kuitenkaan vieläkään omaa riittävästi kokemusta molemmista menetelmistä ja siksi päätin tehdä kyselyn pariohjelmointikokemuksista vasta seuraavan iteraation lopussa. Näin ollen tämän iteraation tulokset keskittyvät edelleen lähinnä pariohjelmoinnin teknisiin vaikutuksiin lopputulokseen, eikä esim. oppimisvaikutusta pystytä mittaamaan mitenkään objektiivisesti. Omalta osaltani voin kuitenkin sanoa jo sen verran, että pariohjelmointi näytti todelliset kyntensä tässä iteraatiossa kun päästiin eroon sitä haitanneista teknisistä ongelmista. Tein I1-vaiheessa melko vähän varsinaista ohjelmointityötä ja jos olisin joutunut tutustumaan yksin järjestelmään olisi siihen kulunut hyvin merkittävä määrä tehokasta työaikaa. Nyt pääsin sen sijaan tutuksi järjestelmän kanssa parini opastuksella ja sain runsaasti onnistumisen iloa saadessani toteutettua toiminnallisuutta järjestelmään. Iteraation loppupuolella olin oppinut järjestelmästä jo niin paljon, että kykenin itsenäisestikin toteuttamaan lisää toiminnallisuutta ja sikäli pariohjelmoinnin voidaan katsoa auttaneen merkittävästi oppimistavoitteiden saavuttamisessa. Hieman samansuuntaisia kokemuksia olen kuullut myös muiden kanssa keskustellessani, mutta näistä enemmän sitten ensi iteraation jälkeen virallisten kyselytulosten muodossa. Vielä viimeinen tämän iteraation työskentelystä huomioitava seikka, on muuttunut tilastointitapa toteutetun toiminnallisuuden osalta. Iteraatiossa toteutettavan toiminnallisuuden määrä oli sen verran suuri, että use case-pohjainen tilastointi ei olisi ollut enää järkevää. Niinpä ryhmä siirtyi tuntikirjanpidossa toiminnallisten kokonaisuuksien mukaiseen kirjaukseen ja tätä samaa kirjaustapaa käytän myös omassa raportissani. Tästä saavutetaan myös se hyöty, että järjestelmämme rakenteesta johtuen löydetyt bugit on huomattavasti helpompi ja luotettavampi kohdistaa toiminnallisuusalueisiin, eikä suoraan yksittäisiin käyttötapauksiin (tosin testiraportissa bugit on kohdistettu käyttötapauksiin tarkemman fokuksen saamiseksi). Näin ollen seuraavassa luvussa esitetyt pari-/yksinohjelmoinnin työmäärät ja löydetyt bugit ovat entistä tarkempia ja vertailukelpoisempia keskenään. 2.1 Metriikat I2-vaiheesta Taulukko 2. Pariohjelmoinnin käyttö ja järjestelmätestauksessa löydetyt bugit toiminnallisuusalueittain (I2) Toiminnallisu usalue Pariohjelmoinnin kokonaistyötunnit Yksinohjelmoinnin kokonaistyötunnit Pariohjelmointisuhde (pariohjelmoidut tunnit/kokonaistunnit) Bugeja (Blocker / Critical / Major / Minor / Trivial)

7 T Software Project/Tietojenkäsittelyopin ohjelmatyö 7(12) Check in related functionality % 2 (0/0/0/0/2) Framework - 1,5 0 % 0 (0/0/0/0/0) User related functionality Work category related functionality Work time item related functionality 24,5 28,5 46 % 6 (0/0/1/4/1) 27 41,5 39 % 6 (0/0/4/2/0) 9 63,5 12 % 5 (0/0/4/1/0) Johtopäätöksiä I2-vaiheen metriikoista Ylläolevan taulukon sisältämissä luvuissa on jonkin verran tulkinnanvaraisuutta, koska osa ohjelmoijista näytti kirjanneen myös bugien korjaukset tiettyjen toiminnallisuusalueiden alle kun taas osa oli kirjannut ne erikseen suunnittelemattoman ohjelmoinnin alle. Siitä johtuen osa taulukon sisältämistä työtunneista saattaa olla jo bugikorjauksia varsinaisen kehitystyön sijasta ja siten saattaa olla vaikuttanut toiminnallisuusalueen kokonaistyömäärään suurentavasti. Näiden tapausten seulominen käsin kaikkien tuntikirjausten joukosta olisi kuitenkin ollut Trapolin nykyiset ominaisuudet huomioon ottaen niin työlästä, että käytännön pakosta ne hyväksytään tulosta epätarkentavina tekijöinä. Toinen huomioitava seikka tämän iteraation tuloksissa on huomattavasti suuremmat kokonaistyömäärät kuin I1-iteraatiossa. Tästä johtuen myös löydettyjen bugien määrät ovat luonnollisesti suurempia, koska on varsin luonnollista, että suurempia kokonaisuuksia tehdessään ohjelmoijat tekevät myös enemmän virheitä. Lisäksi testaajina toimivat jonkin verran eri henkilöt kuin I1-iteraatiossa ja tämä näyttäisi osaltaan vaikuttaneen erityisesti bugien vakavuusasteen tulkintoihin. Tämän iteraation testaajat tulkitsivat vakavuusasteita jonkin verran kevyemmin kuin I1-iteraation testaajat ja niinpä vakavammiksi luokiteltuja bugeja on enemmän kuin I1-iteraatiossa. Tämäkään tulkintaero ei ole kuitenkaan mikään ongelma, kunhan sen vain muistaa huomioida tuloksia analysoidessaan. Suuremmista työmääristä huolimatta ei tässäkään iteraatiossa saatu selkeää ja täysin objektiivista näyttöä pariohjelmoinnin eduista suhteessa yksinohjelmointiin. Framework-toiminnallisuudesta ei saada mitään järkevää tulosta, koska työmäärä oli ainoastaan 1,5 tuntia ja myös kokonaan yksin ohjelmoitu Check intoiminnallisuus on huono vertailukohta varsin yksinkertaisen rakenteensa takia. Niinpä keskeisimmiksi mittareiksi nousevat kolme suurinta toiminnallisuusaluetta, jotka sisältävät työtä n tuntia ja pariohjelmoinnin käyttöaste oli prosenttia. Bugeja analysoitaessa huomataan kuitenkin, että jokaiseen niistä on tullut lähes sama määrä bugeja ja myös bugien vakavuusasteet ovat hyvin lähellä toisiaan. Näin ollen ei voida millään tasolla sanoa pariohjelmointia sen paremmaksi tai huonommaksi kuin yksinohjelmointi. Eräs näkökohta on toki siinä, että pariohjelmoinnissa kuluu kahdelta ohjelmoijalta sama työmäärä kuin muuten menisi vain yhdeltä, mutta tätä ei voida objektiivisesti mitata käytössä olevien tietojen avulla. Näyttäisikin siltä, että tällainen yhden ryhmän sisäinen ja vain yhden projektin (vieläpä suhteellisen pieni projekti) mittainen tutkimus pariohjelmoinnin hyödyistä ei tuota mitään tieteellisesti hyväksyttävää todistusaineistoa. Tutkin vielä I3-iteraation aikana, jos silloin tulisi ilmi jotain yllättäviä tuloksia. Tässä

8 T Software Project/Tietojenkäsittelyopin ohjelmatyö 8(12) vaiheessa näyttää kuitenkin siltä, että tietoa pariohjelmoinnin hyödyllisyydestä saadaan parhaiten ensi iteraation lopussa tehtävän kyselytutkimuksen avulla. Vaikka kyseessä ovatkin ryhmäläisten subjektiiviset mielipiteet, antaa tämä varmasti osviittaa siitä kuinka hyödylliseksi pariohjelmointi koetaan ja ennen kaikkea tällä hetkellä pariohjelmoinnin keskeisimmältä edulta vaikuttavasta oppimishyödystä. 3. Arviointi I3-vaiheesta I3-vaiheessa ei kyetty alkuperäisistä suunnitelmista poiketen enää käyttämään pariohjelmointia muutaman keskeisen syyn takia. Ensimmäinen suuri muutos oli kalenteriajassa todella tiukka toteutusaikataulu uudelle toiminnallisuudelle. Tämä johtui lähinnä siitä, että I3-vaiheessa tehtiin ryhmien välinen peer-testaus ja tästä syystä toiminnallisuuden piti olla toteutettuna hyvin nopeasti vaiheen alussa. Kun tämän yhdisti ryhmäläisten varsin tiiviseen aikatauluun muiden kiireiden osalta, oli tuloksena se, että jokainen teki ohjelmointityötä silloin kuin sattui ehtimään, eikä yhteisiä pariohjelmointiaikoja onnistuttu sopimaan. Tästä syystä vastaavaa vertailua kuin edellisissä vaiheissa pariohjelmoinnin ja perinteisen ohjelmoinnin välillä ei ole tehty. En pidä tätä kuitenkaan suurenakaan miinuksena, koska edellisissä vaiheissa on jo käynyt ilmi, ettei pariohjelmoinnista saada absoluuttisen tarkkaa mittaustietoa tämän laajuisessa projektissa kuitenkaan. Sen sijaan kuten jo edellisen vaiheen lopussa epälin, antoi tämän vaiheen lopussa tekemäni kyselytutkimus hyvinkin paljon mielenkiintoista lisätietoa pariohjelmoinnin käytöstä projektin aikana. Vaikka kyseessä eivät olekaan tieteellisesti pätevät todisteet, ovat ryhmäläisten omat käsitykset ja suhtautuminen pariohjelmointiin hyvin keskeisessä asemassa arvioitaessa pariohjelmoinnin käyttöä. Varsinkin tämän suuruusluokan projektissa on ryhmän sisäisellä toiminnalla hyvin suuri merkitys projektin onnistumisen kannalta. Mutta tästä kyselystä ja sen tuloksista enemmän seuraavassa luvussa. Projektin viimeisessä vaiheessa (DE) pariohjelmointia ei enää käytetä, koska koko vaihe keskittyy aikaisemman toiminnallisuuden hiomiseen ja virheiden korjaamiseen. Koska uutta toiminnallisuutta ei varsinaisesti enää toteuteta, ei myöskään pariohjelmointia tulla käyttämään kuin korkeintaan satunnaisten virheiden metsästämiseksi. Tämä on kuitenkin luonteeltaan niin erityyppistä työtä kuin varsinainen toiminnallisuuden toteutus, ettei sitä voida verrata tämän tutkimuksen käsittelemään pariohjelmointiin. 4. Yhteenveto Tässä luvussa esitellään lyhyesti I3-vaiheen lopussa tekemäni kyselytutkimuksen tulokset ja käydään läpi niiden pohjalta projektin alussa oletettuja pariohjelmoinnin hyötyjä ja haittoja. Kyselyssä esitin yhdeksän kysymystä pariohjelmointia koskien ja lisäksi kolme taustakysymystä. Pariohjelmointia koskevissa kysymyksissä pyysin vastaukset käyttäen asteikkoa 1=täysin eri mieltä, 2=osittain eri mieltä, 3=en osaa sanoa, 4=osittain samaa mieltä tai 5=täysin samaa mieltä. Lisäksi ryhmäläisillä oli mahdollisuus antaa jokaisessa kohdassa vapaamuotoista palautetta. Jokainen ryhmäläinen vastasi kyselyyn ajoissa, joten kyselyn otos on seitsemän henkilöä ja kattaa siten täydellisesti projektiryhmämme mielipiteet. Kysymykset ja vastausten keskiarvot sekä keskihajonnat on esitetty alla taulukossa 3. Taulukko 3. Kyselyn tulokset Kysymys Vastausten keskiarvo (1=täysin eri mieltä, 2=osittain eri mieltä, 3=en osaa sanoa, 4=osittain samaa mieltä, 5=täysin samaa mieltä) Vastausten keskihajonta 1. Pariohjelmointi on miellyttävämpää kuin yksin ohjelmoiminen?

9 T Software Project/Tietojenkäsittelyopin ohjelmatyö 9(12) ohjelmoiminen? 2. Pariohjelmoinnista oli hyötyä asioiden oppimiseni kannalta? 3. Uskon tuottaneeni parempilaatuista koodia ohjelmoidessani parin kanssa? 4. Kaveri kommentoimassa virheitäni häiritsi ohjelmointiani? 5. Pariohjelmointi oli hitaampaa kuin perinteinen ohjelmointi (verrattuna siihen että pari työskentelisi erikseen)? 6. Kykenin ratkaisemaan ongelmatilanteita nopeammin pariohjelmointia käyttäessäni? 7. Pariohjelmoinnin käyttö paransi ryhmähenkeä/auttoi tutustumaan ryhmäläisiin? 8. Uskon että pariohjelmoinnin käytöstä oli projektille hyötyä? 9. Pariohjelmoinnin käytöstä oli itselleni hyötyä? Taustakysymykset a. Ohjelmointiin käyttämäni kokonaistyömäärä oli noin...? (tunneissa) b. Tästä ajasta pariohjelmointia oli noin...? (tunneissa) c. Olen käyttänyt pariohjelmointia aiemmin...? (en koskaan/satunnaisesti/säännöllisesti) lähes kaikki satunnaisesti, kukaan ei säännöllisesti 4.1 Johtopäätöksiä kyselyn tuloksista Kyselyllä saadut tulokset tukivat varsin hyvin projektin alussa tehtyjä oletuksia pariohjelmoinnin vaikutuksesta. Tulokset noudattivat myös varsin pitkälti omia oletuksiani siitä, millaisia vastaukset tulisivat olemaan. Muutaman mielenkiintoisen havainnon tuloksista voi kuitenkin tehdä, varsinkin jos otetaan vielä huomioon vähän ulkopuolista tietoa kyselyyn vastanneista henkilöistä. Tällä tarkoitan lähinnä sitä, että kyselyssä ei suoraan otettu kantaa vastaajan aiempaan ohjelmointikokemukseen, mutta projektin aikana

10 T Software Project/Tietojenkäsittelyopin ohjelmatyö 10(12) ryhmäläisiin on tutustunut sen verran, että jonkinlainen käsitys myös siitä asiasta on muodostunut. Niinpä seuraavissa johtopäätöksissä on jonkin verran käytetty hyödyksi myös omia tietojani varsinaisen kyselyn ulkopuolelta. Ensimmäisen kysymyksen osalta tulokset olivat varsin pitkälti odotetun kaltaisia. Pariohjelmointi koettiin varsin miellyttäväksi verrattuna yksin ohjelmointiin, vaikka pari eriävääkin mielipidettä asiaan tuli. Huomionarvoista tämän kysymyksen vastauksissa oli lähinnä se, että pariohjelmoinnin miellyttävyys oli lähes suorassa suhteessa siihen, kuinka suuren osan ohjelmoinnistaan vastaaja oli tehnyt pariohjelmointina projektin aikana. Lisäksi oli selvästi havaittavissa, että ryhmän ennestään kokeneimmat ohjelmoijat eivät kokeneet pariohjelmointia yhtä positiivisena asiana kuin muut. Tämä on varsin luonnollista, koska uusi työtapa aiheuttaa aina sitä enemmän vastustusta mitä pidempään on tottunut toimimaan toisin. Kommenttina saatiin myös, että pariohjelmointi on kätevää hankalampien ongelmien ratkomiseen, mutta turhauttavaa apinakoodia kirjoitettaessa. Toisessa kysymyksessä mielipiteet hajaantuivat todella paljon. Tätä selittää kuitenkin ryhmäläisten erilainen osaamistausta, mistä syystä myös pariohjelmoinnin oppimisvaikutus vaihteli sen mukaisesti. Kokeneille ohjelmoijille pariohjelmoinnissa ei ollut niin paljon opittavia asioita kuin kokemattomammille ja erityisesti kokemattomammat ohjelmoijat arvostivat mahdollisuutta oppia asioita pariohjelmointia käytettäessä. Tosin myös siinä joukossa, joka ei kokenut pariohjelmoinnin varsinaisesti hyödyntäneen oppimistaan, tuli kommentti, jonka mukaan asioiden selittäminen toiselle ohjelmoijalle oli auttanut itseäkin ymmärtämään asian paremmin. Kolmannessa kysymyksessä mielipiteet keskittyivät hyvin pitkälle keskimmäiseen vaihtoehtoon. Vain yksi henkilö epäili tuottaneensa huonompilaatuista koodia ohjelmoidessaan pariohjelmointia, mutta suurin osa ei osannut sanoa asian suhteen mitään. Tämän kysymyksen suhteen edellisissä vaiheissa tehdyt varsinaiset mittaukset eivät antaneet myöskään tietoa asian todellisesta tilasta. Tämän kokeilun perusteella ei siis voida sanoa mitään lopullista siitä, tuottaako pariohjelmointi oikeasti parempaa koodia tämän kaltaisessa projektissa. Vastaavasti pariohjelmoinnin ei tutkimuksen valossa pitäisi ainakaan huonontaa koodin laatua, joten sen käyttöä kannattaa arvioida muiden tutkimuksessa esille tulleiden vaikutusten pohjalta. Neljännen kysymyksen suhteen vastaukset olivat varsin yksimielisiä. Kukaan ei myöntänyt parin kommentoinnin varsinaisesti häiritsevän ja useimmat kokivat sen ainoastaan hyödyllisenä, että koodiin mahdollisesti tulevat virheet huomataan ja voidaan korjata heti. Tähän osaltaan varmasti vaikutti ryhmässä vallinnut hyvä yhteishenki, jonka ansiosta kukaan ei kokenut pariohjelmointia ja parin kommentteja hyökkäävinä. Viidennessä kysymyksessä tuli jälleen melko paljon hajontaa vastauksissa. Selkeästi kuitenkin koettiin pariohjelmointi hitaammaksi kuin kahden ohjelmoijan toimiminen erikseen. Tämä pitää varsinkin tämän suuruisessa projektissa varmasti paikkansa, koska erityisesti pariohjelmoinnin opetteluvaiheessa aiemmat tutkimuksetkin ovat osoittaneet kuluvan selvästi enemmän aikaa. Laajemmassa projektissa kuitenkin olisi odotettavissa pariohjelmoinninkin tehostuminen oppimisvaiheen jälkeen. Tähän suuntaan tuli myös kommentteja kyselyssä, että pariohjelmoinnin teho oli kärsinyt kun totutteluun meni sen verran aikaa. Kuudennessa kysymyksessä vastaukset vaihtelivat aivan laidasta laitaan, vaikka vastausten keskiarvo asettuikin varsin tarkasti asteikon keskivaiheille. Selvästi oli havaittavissa, että kokeneemmat ohjelmoijat ratkaisevat ongelmat nopeammin yksin kun taas kokemattomammat ohjelmoijat hyötyvät voidessaan ratkoa ongelmia yhdessä parinsa kanssa. Seitsemännessä kysymyksessä tulos oli päivänselvä. Kukaan ei kokenut pariohjelmoinnin huonontaneen ryhmähenkeä vaan lähes yksimielisesti kaikki olivat sitä mieltä, että pariohjelmointi paransi ryhmähenkeä ja auttoi tutustumaan ryhmäläisiin. Tätä voidaan pitää erittäin merkittävänä saavutuksena, koska kuten aiemmin jo totesin on erityisesti tämän suuruusluokan projektissa hyvin tärkeää ryhmän yhteishenki ja yhdessä

11 T Software Project/Tietojenkäsittelyopin ohjelmatyö 11(12) tekemisen meininki. Periaatteessa projektin vaatiman ohjelmoinnin olisi voinut tehdä aivan hyvin jokainen yksin kotoaan käsin ohjelmoiden, mutta kyselyn vastauksissa tuli selvästi ilmi, että yhdessä työskentely on myös hyvä keino samalla tutustua muihin ryhmäläisiin. Erityisesti tällaisen projektin yhteydessä, jossa ryhmän jäsenet ovat entuudestaan melko tuntemattomia toisilleen, on tärkeää saada ryhmä yhtenäiseksi tutustumalla mahdollisimman pian ryhmän muihin jäseniin. Vakiintuneessa työporukassa tätä ei voida pitää niin merkittävänä tekijänä, mutta erityisesti tällaisen kouluprojektin yhteydessä voidaan tämän perusteella suositella pariohjelmoinnin käyttöä ainakin jossain määrin ja erityisesti projektin alkuvaiheessa. Myös kahdeksannessa kysymyksessä vastaukset olivat hyvin yksimielisiä. Pariohjelmoinnin käyttö koettiin hyvin yksimielisesti hyödylliseksi projektille. Suurinta hyötyä pariohjelmoinnista oli ennen kaikkea ryhmäläisten erilaisen kokemustaustan takia. Kokemattomammille ohjelmoijille pariohjelmointi tarjosi mahdollisuuden päästä sisään toteutettavaan järjestelmään, minkä yksin opettelussa olisi ollut todella suuri työ. Tämän ansiosta ryhmäläiset kykenivät tuottamaan mielekästä toiminnallisuutta järjestelmään hyvin nopean oppimisvaiheen jälkeen. Yhdeksännessä kysymyksessä mielipiteissä oli jonkin verran hajontaa, mutta kaikki vastaukset keskittyivät keskimmäisiin vastausvaihtoehtoihin. Oli hyvin mielenkiintoista havaita, että kaikki uskoivat kyllä projektin hyötyneen pariohjelmoinnin käytöstä, mutta sen sijaan siitä ei oltu yhtään niin varmoja, että pariohjelmointi olisi hyödyttänyt vastaajaa henkilökohtaisesti. Varsinaista yleispätevää selitystä ei tälle ilmiölle vastausten perusteella löytynyt, mutta positiivisena koettiin asioiden oppimisen helpottumien pariohjelmoinnin yhteydessä ja negatiivisena taas työskentelyn hidastuminen. Yhteenvetona taustakysymyksistä voi todeta lähinnä, että ryhmäläisten ohjelmointiin käyttämien työtuntien määrä vaihteli todella voimakkaasti vastaajan mukaan. Samoin pariohjelmoinnin käyttö vaihteli melko voimakkaasti sekä suhteellisina (verrattuna kokonaistyömäärään) että absoluuttisina tunteina. Kukaan ryhmäläisistä ei ollut käyttänyt aiemmin pariohjelmointia säännöllisesti, mutta useimmat olivat kuitenkin kokeilleet sitä jonkin aikaisemman projektin yhteydessä. Suurta korrelaatiota taustakysymysten ja muiden vastausten välillä ei ollut nähtävissä vaan ainut suurempi yksittäinen vaikuttava seikka näytti olevan ohjelmoijan aikaisemman ohjelmointikokemuksen määrä. Loppusanat Vaikka tämän tutkimuksen puitteissa en saanutkaan vedenpitäviä mitattuja tuloksia pariohjelmoinnin tuloksista, pidän silti tutkimusta varsin menestyksekkäänä kokonaisuutena. Erityisesti lopussa tekemäni kysely toi ilmi kiinnostavia seikkoja pariohjelmoinnin käytöstä, joita varmasti kannattaa miettiä tulevienkin projektien yhteydessä. Kokonaisuudessaan pariohjelmoinnin käyttö koettiin varsin miellyttäväksi ja projektin kannalta hyödylliseksi, vaikka sen tehokkuutta hieman epäiltiinkin. Oma mielipiteeni ja käsitykseni vastausten pohjalta on, että pariohjelmointia kannattaa ehdottomasti käyttää jossain määrin tämän tyyppisissä projekteissa. Lähtökohtana oli entuudestaan toisilleen suhteellisen tuntematon joukko ryhmäläisiä, joiden osaamistausta lisäksi vaihteli varsin paljon. Pariohjelmointi auttoi kuitenkin kokemattomampiakin ryhmäläisiä tutustumaan sekä toteutettavaan järjestelmään että uusin käytettäviin tekniikoihin. Samalla pariohjelmointi tarjosi loistavan tilaisuuden tutustua muihin ryhmäläisiin ja paransi siten yhteishenkeä, joka puolestaan on merkittävä tekijä työn mielekkyyden ja sitä kautta työskentelyn tehokkuuden parantajana. Pariohjelmointia ei kuitenkaan tarvitse noudattaa ja käyttää orjallisesti, vaan sitä on syytä soveltaa tilanteen mukaan. Omien kokemusteni perusteella pariohjelmointia kannattaa käyttää projektin alkuvaiheessa ryhmäläisten tutustuttamisessa järjestelmään ja toisiinsa. Tämän jälkeen pariohjelmointia kannattaa käyttää ennakkoon ajateltuna vaikeampien kokonaisuuksien toteuttamisessa, jolloin pari voi yhdessä miettiä tarvittavia ratkaisuja. Sen sijaan suoraviivaisessa ohjelmoinnissa pariohjelmointi ei ole tehokkaimmillaan. Samoin pariohjelmointia voi käyttää tarpeen mukaan siten, että jos useampi ryhmäläinen työskentelee

12 T Software Project/Tietojenkäsittelyopin ohjelmatyö 12(12) samoissa tiloissa, voi pyytää toisen väliaikaisesti auttamaan jonkin vaikeamman ongelman ratkaisemisessa. Usein auttaa jo se kun selittää toiselle mistä ongelmassa on kyse ja ainakin neljä silmää löytää ongelman nopeammin kuin kaksi. Kaiken kaikkiaan siis varsin positiiviset kokemukset jäivät pariohjelmoinnista, kunhan sitä soveltaa projektin ehdoilla eikä orjallisesti noudattaen.