T SEPA diary. Santtu Järvi (57729J), Matti Lehtomäki (55065D) 2. maaliskuuta 2008

Transkriptio

1 T Santtu Järvi (57729J), Matti Lehtomäki (55065D) 2. maaliskuuta

2 Sisältö 1 Johdanto 3 2 Käytännön toteutussuunnitelma Yleiskuvaus Tekniset tarkastelukohteet Tehokkaat ja tehottomat pariohjelmoinnin kohteet Erilaisten työpisteiden vaikutus tehokkuuteen Päätelaitteiden vaikutukset ja mahdolliset ongelmat Psykologiset tarkastelukohteet Ohjelmointivuoron pituus Taukojen määrä ja niiden pituus Palautteen määrän vaikutus Yleisen keskustelun määrä ja häiriötekijät Huumorin vaikutus Parien vaihtaminen ja mahdolliset ongelmatilanteet Havainnot ja muutokset Suunnitteluvaihe Toteutusvaihe Yleiskuva Muutokset toteutussuunnitelmaan Havainnot Toteutusvaihe Yleiskuva Muutokset toteutussuunnitelmaan Havainnot Yhteenveto /11

3 1 Johdanto Sovellusohjelmointi on tyypillisesti taito, jota tuskin kukaan pystyy soveltamaan ilman jatkuvaa virheiden tekemistä. Koska ihmiset ovat vain ihmisiä, inhimillisten virheiden todennäköisyys ohjelmoitaessa on sitä suurempi, mitä monimutkaisempia ja suurempia ongelmia pyritään ratkomaan ohjelmallisesti. Ihminen on tyypillisesti myös helposti taipuvainen soveltamaan heti ensimmäisenä mieleensä tullutta ratkaisua tiettyyn ongelmaan ajattelematta välttämättä sen kummemmin sen järkevyyttä. Toisaalta joku saattaa taas jäädä tunneiksi miettimään ongelmanratkaisua pääsemättä asiassa juurikaan eteenpäin. Usein ratkaisuvaihtoehtojen määrä jää vähäiseksi ja ongelmaa lähestytään vain yhdestä tai parista eri näkökulmasta. Myös tietotaito on ohjelmoitaessa valttia ja monesti lahjakkaan ohjelmoijan kyvykkyydestä ei ole muille ohjelmoijille muuta hyötyä kuin laadukas koodi, mikäli hän harrastaa ohjelmointia täysin itsenäisesti. Jokainen vähän tai hieman enemmänkin ohjelmoinut on varmasti kohdannut edellä mainittuja ongelmatilanteita ja miettinyt miten ne saisi ratkaistua. Yksi hyväksi todettu ja tehokas ratkaisu on hyödyntää ohjelmistoprojekteissa pariohjelmointia. Pariohjelmoinnilla tarkoitetaan lyhykäisyydessään kahden ihmisen tiivistä yhteistyötä ohjelmakoodin tuottamisessa saman näyttöpäätteen ääressä. Toinen ohjelmoijista toimii vuorollaan ajajana ja toinen vieressä navigaattorina. Ajajan tehtävänä on tuottaa koodia mahdollisimman tehokkaasti ja nopeasti kiinnittämättä enempää huomiota yksityiskohtiin. Navigaattorin tehtävänä taas on linjata suoritettavaa ohjelmointitehtävää ja tarkkailla aktiivisesti ajajan tuottamia koodirivejä virheitä etsien sekä antaa palautetta puutteista ohjelmakoodissa. Laurie Williams ja Robert Kessler ovat kiteyttäneet onnistuneesti pariohjelmoinnin mentaliteetin ja periaatteet artikkelissaan All I Really Need to Know about Pair Programming I Learned In Kindergarten [1]. Siinä on kuvattu erittäin selkeällä ja helposti omaksuttavalla tavalla pariohjelmointi psykologisesta näkökulmasta ja keskitytty käytännön ongelmiin, joita kahden ihmisen välisessä kanssakäymisessä saattaa ilmaantua ohjelmoinnin merkeissä. 2 Käytännön toteutussuunnitelma 2.1 Yleiskuvaus Useassa projektissa on tullut vastaan koodin sekavuus useamman ohjelmoijan työskennellessä saman koodin parissa yhtäaikaa. Projektin edetessä huomataankin usein, että jokainen ymmärtää vain oman alueensa, mikä tekee ohjelmoinnin koordinoinnista hyvin hankalaa. Tähän ongelmaan on jo aiemmin kokeiltu ratkaisua, jossa ohjelmoidaan yhdessä internet-puhelun mahdollistaman keskustelun tukemana. Vaikeimmissa kohdissa on tullut myös testattua muita etätyökaluja, joilla esimerkiksi jokainen ohjelmoija voi muokata samanaikaisesti tiedostoja, koska kaikki näkevät reaaliajassa toistenkin tekemät muokkaukset. Tulos näissä ohjelmointitesteissä on ollut hyvin positiivinen ja tämän takia pariohjelmointi kiinnostaa käytännössä hyvin paljon. Pariohjelmointia tullaan projektin aikana käyttämään jatkuvasti alkaen ensimmäisestä iteraatiosta. Koska pariohjelmointi vaatii kaksi ohjelmoijaa, keskitytään erityisesti asioihin, jotka olennaisesti vaikuttavat tehokkaan pariohjelmoinnin toteuttamiseen sekä teknisessä 3/11

4 että psykologisessa mielessä. 2.2 Tekniset tarkastelukohteet Tehokkaat ja tehottomat pariohjelmoinnin kohteet Koodin kommentointi ja täysin triviaalit muokkaukset eivät voi mitenkään olla parhaita pariohjelmoinnin kohteita, joten nämä asiat sivuutetaan tekniikkaa testatessa. Olennainen asia pariohjelmoinnissa on löytää ohjelmoinnin osa-alueet, joissa tekniikan soveltaminen on järkevää. Tämän takia pyritäänkin järjestämään eri suuruisia ja vaikeusasteisia ohjelmointitehtäviä, jotta pariohjelmoinnin todellinen hyötyalue tulisi esiin Erilaisten työpisteiden vaikutus tehokkuuteen Pariohjelmoinnissa on erittäin tärkeää, että työpiste olisi mahdollisimman ergonominen. On tärkeää huomioida, että vuoron vaihtaminen tapahtuu näppärästi vain näppäimistöä ja hiirtä liikuttamalla. Mikäli jokaisen vuoron vaihdon yhteydessä tuoleja ruvetaan siirtelemään, tähän kuluu turhaa aikaa ja vaivaa varsinkin mikäli vuoron pituus on lyhyt. Erilaisten työtuolien lisäksi myös erimuotoisia pöytiä tullaan kokeilemaan niiden aikaansaamien vaikutusten esiintuomiseksi Päätelaitteiden vaikutukset ja mahdolliset ongelmat Kun kaksi ihmistä tuijottaa yhtä näyttöpäätettä samanaikaisesti, näyttöpäätteen laatu ja katselukulmat ovat erityisen tärkeässä asemassa. Eri tekniikalla toteuttuja ja erikokoisia näyttöpäätteitä tullaankin kokeilemaan mahdollisuuksien mukaan. 2.3 Psykologiset tarkastelukohteet Ohjelmointivuoron pituus Koska aikaisempaa kokemusta varsinaisesta pariohjelmoinnista ei juurikaan ole, tullaan sitä testaamaan erilaisilla aikajaksoilla. Jokaisella viikolla pyritään testaamaan eri mittaisia vuoroja ajajan ja navigaattorin rooleissa. Aluksi testaan ainakin 15, 30 ja 45 minuutin mittaisia jaksoja, ja tämän jälkeen pyritään vielä hakemaan hienosäätöä kaikista parhaimman jakson pituuden löytämiseksi. Yleisesti parhaimmaksi vuoron pituudeksi on todettu noin puoli tuntia, jota pidetään lahtökohtaisena parhaana arvona Taukojen määrä ja niiden pituus Tauot ovat olennainen osa kaikkea työtä ja varsinkin tiivistä yhteistyötä tehdessä niiden merkitys varmasti korostuu. Tämän takia onkin mielenkiintoista kokeilla, kuinka yhteistyö sujuu pitämättä tuskin yhtään taukoa. Toisaalta on varsin mielekästä kokeilla myös usein toistuvia parin minuutin mittaisia taukoja työskentelytehokkuuden kannalta. 4/11

5 2.3.3 Palautteen määrän vaikutus Palautteen antaminen on hyvin olennainen osa pariohjelmointia. Liian nopeasti annettu palaute saattaa ruveta ärsyttämään toista ja toisaalta taas hitaasti reagoiva navigaattori saattaa aiheuttaa sekaannusta ajajan ohjelmoidessa, mikäli hän raportoi esimerkiksi ajajan tekemästä kirjoitusvirheestä turhan myöhään. Kirjoittamaton sääntö sanoo, että navigaattorin tulisi puuttua koodirivin sisältöön vasta kun ajaja on painanut rivinvaihtoa. Tätä sääntöä tullaan ehdottomasti testaamaan myös käytännössä. Kaiken kaikkiaan palautteen annon nopeutta ja määrää tullaankin testaamaan ääripäästä toiseen pyrkien löytämään optimaalinen taso Yleisen keskustelun määrä ja häiriötekijät Koska pariohjelmointi on tiivistä yhteistyötä, on sitä käytännössä mahdoton toteuttaa olemalla hiljaa. Tämän takia tullaan kiinnittämään huomiota muiden samassa huoneessa olevien ohjelmoijien antamaan palautteeseen keskustelun ja kommentoinnin häiritsevyydestä. Yleisesti ottaen tullaan myös kiinnittämään huomiota siihen, kuinka suuri vaikutus on navigaattorin pysymisellä asiassa ajajan ohjelmoidessa. On mielenkiintoista nähdä kuinka helposti ajajan ote koodinkirjoittamiseen herpaantuu, jos navigaattori ei kommentoi loogisesti ajajan työskentelyä tai hyppii ajatuksissaan epäloogisesti paikasta toiseen Huumorin vaikutus Huumorilla on melkoinen merkitys hyvän ilmapiirin luomisessa. Tämän takia tullaan pitämään ohjelmointipäiviä, jolloin lähes kaikki ohjelmointiin liittyvät asiat pyritään esittämään pilke silmäkulmassa ja sitten taas testataan myös toista ääripäätä, jolloin asiat esitetään vakavasti ja asiallisesti. Erilaisella huumorin määrällä voi olla yllättävä vaikutus ohjelmoinnin tehokkuuteen Parien vaihtaminen ja mahdolliset ongelmatilanteet Pariohjelmointia aiotaan testata aluksi vain yhdellä parilla, mutta myöhemmin mahdollisesti useammalla, mikäli vain muiden ohjelmoijien aikataulu tämän sallii. Parien vaihto tuo varmasti mukanaan psykologisia seikkoja, joita vain yhden ja saman parin työskennellessä ei välttämättä tule esiin. Jokainen ihminen on yksilö ja onkin täysin mahdollista, että henkilökemiat eivät kohtaa ollenkaan. 3 Havainnot ja muutokset 3.1 Suunnitteluvaihe Projektin suunnitteluvaiheessa pariohjelmointia ei voitu luonnollisesti soveltaa, koska ohjelmointityötä tehdään vasta toteutusvaiheissa. 3.2 Toteutusvaihe Yleiskuva Ensimmäisessä toteutusvaihessa tarkoituksena oli rakentaa viestipohjainen taustajärjestelmä käyttäen Python-ohjelmointikieltä. Python ei kielenä ollut kovin 5/11

6 tuttu kummallekaan, mutta parin päivän ohjelmoinnin jälkeen kieli alkoi sujua luontevasti ja mitään kovin monimutkaista Python-kielessä ei tullut vastaan. Pariohjelmointia ryhdyttiin soveltamaan heti kehitystyökalujen asennuksen jälkeen ja sitä käytettiin iteraation loppuun saakka. Kappaleeseen on koottu havaintoja ja kokemuksia pariohjelmoinnin soveltuvuudesta tehokkaalla ohjelmointikielellä toteutetun ohjelman luomiseen ilman olemassa olevaa pohjaa Muutokset toteutussuunnitelmaan Ainoa selkeä muutos toteutussuunnitelmaan ensimmäisessä toteutusvaihessa oli, että pariohjelmointia kokeiltiin myös erityistä tarkkaavaisuutta vaativan dokumentaation tuottamiseen. Tästä on kerrottu lisää kappalessa kohdassa Tehokkaat ja tehottomat pariohjelmoinnin kohteet Havainnot Tehokkaat ja tehottomat pariohjelmoinnin kohteet Pariohjelmoinnin huomattiin sopivan erityisen hyvin sellaiseen ohjelmointiin, jossa kaikki on suunniteltu alusta asti itse ja suunnitelma on selkeä. Alusta asti itse suunniteltu järjestelmä aikaansaa sen, että molemmilla on hyvä tietämys järjestelmästä ja sitä on mukava ohjelmoida pariohjelmoiden. Itse ohjelmointikielestä ei välttämättä molemmilla ole yhtä paljon tietämystä, mutta pariohjelmointi auttaa myös jakamaan tietoa. Erityisen hyvin pariohjelmointi sopii myös ohjelmointikieleen, jossa ei ole tyypitystä. Kun virheelliset metodikutsut huomataan tulkin toimesta ohjelmallisesti vasta ajettaessa ohjelmaa, on paljon tehokkaampaa, mikäli virheet pystytään pariohjelmoinnin avulla huomaamaan jo koodinkirjoitusvaiheessa. Tämä toimi hienosti. Toinen erittäin hyvä kohde pariohjelmoinnille on rekursiot ja for-lauseet. Näissä tulee helposti virheitä raja-arvojen kanssa, mikä pystytään valppaan navigaattorin avulla usein tehokkaasti estämään. Debuggaaminen on hieman kaksijakoinen kohde pariohjelmoitaessa. Mikäli sekä ajajalla että navigaattorilla on yhtä hyvä tuntemus järjestelmään, debuggaaminen on usein tehokkaampaa kahden silmäpärin voimin. Toisaalta taas vaikeasti paikannettaviin ongelmiin ja tuntemattoman järjestelmän debuggamiseen pariohjelmointi ei välttämättä ole tehokkain keino, koska ongelmien ratkominen saattaa tällöin viedä kohtuuttoman paljon aikaa johtuen koodin kääntämisestä. Tällöin on usein tehokkaampaa hajauttaa pari debuggaamaan ongelmaa kahdella eri koneella, kumpikin yrittäen ratkoa ongelmaa erilaisilla lähestymistavoilla. Alkuperäisestä suunnitelmasta poiketen pariohjelmointia sovellettiin myös tarkkuutta vaativaan dokumentointiin. Tarkemmin sanoen kohteena oli järjestelmässä kulkevien viestien dokumentointi, mikä vaati hyppimistä koodissa sekä leikkaa-liimaa operaatiota eri ikkunoiden välillä. Koska viestien dokumentaation tuli olla korrektia ja vastata täysin koodia, ylimääräinen silmäpari ei todellakaan ollut pahitteeksi dokumentaatiota kirjoitettaessa. Eli tämän tyyppiseen dokumentointiin pariohjelmointi soveltui varsin hyvin. Tehottomia kohteita pariohjemoinnille paljastui olevan lähinnä täysin triviaalien container-tyyppisten luokkien tekeminen, missä luokan rajapinta vain sisältää GetXXX() ja SetXXX() -tyyppisiä metodeita. Tähänkin tosin löytyi aivan projektin loppuvaiheessa kehitystyökalun puolelta automatisoitu ratkaisu, 6/11

7 minkä hyödyntäminen heti alusta lähtien olisi säästänyt jonkin verran aikaa ja vaivaa, sekä poistanut ainoan selkeän miinuksen pariohjelmoinnin soveltuvuuslistalta ohjelmoitaessa Python-kielellä. Erilaisten työpisteiden vaikutus tehokkuuteen Työpisteillä huomattiin olevan enemmän vaikutusta kun aluperin kuviteltiinkaan. Aivan aluksi kokeiltiin nurkkatyöpistetta, joka oli kovera 90 asteen nurkka. Molemmat kokivat tämän varsin ahdistavaksi työasennoksi ja se hylättiin välittömästi. Seuraavaksi kokeiltiin toista ääripäätä, eli 90 asteen kuperaa nurkkaa. Se oli muuten melko toimiva, mutta asento ei tuntunut täysin luontevalta ja lisäksi päätä piti koko ajan kääntää näytön suuntaan korostetusti. Lisäksi näppäimistön siirtäminen toiselle ei ollut kovin helppoa vuoron vaihtuessa. Näin ollen parhaimmaksi testatuksi vaihtoehdoksi muodostui suora pöytä, jossa molemmat istuvat rinnakkain. Tällöin päätä ei juurikaan tarvinnut kääntää näytön suuntaan ja näppäimistön sai helposti liu utettua kaverille. Ideaalimaailmassa paras työpiste olisi kupera, noin 30 asteen kulma, jolloin voisi käytännössä katsoa kokoajan suoraan eteenpäin ja näppäimistön saisi silti siirrettyä pienellä vaivalla. Päätelaitteiden vaikutukset ja mahdolliset ongelmat Päätelaitteen vaikutus korostui heti ensimmäisenä testipäivänä. Kun pariohjelmoinnissa joutuu käyttämään 14 LCD näyttöä, se ei missän nimessä voi olla kovinkaan miellyttävää. Suurimmaksi ongelmaksi muodostui kehnot katselukulmat, jonka takia näyttöä joutui viemään kauemmaksi kuin olisi ollut miellyttävää. Tästä taas seurasi, että näytön tekstiä joutui kokoajan hieman tihrustamaan, eivätkä silmät saaneet levätä. Joka tapauksessa parhaaksi sijoituspaikaksi pienelle LCD-näytölle asettui noin 80 cm:n etäisyys silmistä suoraan edessä. Tällöin katselukulmat eivät juurikaan häirinneet ja teksti oli silti vielä luettavissa. Olisi ollut mielenkiintoista kokeilla myös isompaa päätelaitetta ja parempia katselukulmia, mutta tähän ei tarjoutunut mahdollisuutta. Ohjelmointivuoron pituus Kun pariohjelmointia lähdettiin soveltamaan, aluksi testattiin 30 minuutin pituista ohjelmointivuoroa. Tämä tuntui aluksi hyvältä, mutta viikon jälkeen puolen tunnin vuorot alkoivat venymään ja rupesivat osoittautumaan turhan pitkiksi. Tämän takia vuoron pituutta lyhennettiin ensin 20 minuuttiin ja sitten 15 minuuttiin, joka tuntui olevan paras vaihtoehto. Ongelmana oli kuitenkin se, että vaikka mielenkiinto säilyi pariohjelmoinnin kannalta tällä vuoronpituudella parhaana, suoritettava ohjelmointitehtävä tuntui hyvin usein jäävän kesken lyhyen vuoron takia. Ratkaisuna ongelmaan oli jyvittää ohjelmointitehtävät tarkemmin pienemmiksi kokonaisuuksiksi, minkä jälkeen lyhyt vuoroväli toimi erittäin hyvin. Myös aiemmin esiteltyyn erityistä tarkkaavaisuutta vaativaan dokumentointiin sovellettu pariohjelmointi toimi parhaiten juuri lyhyellä vuoronpituudella. Yksin tai pitkillä vuoroilla tehtynä dokumentointi olisi varmasti osoittautui varsin tylsäksi hommaksi, sillä pariohjelmoidenkin sen tekemiseen kului melkein kokonaisen työpäivän verran. 7/11

8 Taukojen määrä ja niiden pituus Aluksi tauot jäivät varsin vähäisiksi ja ohjelmointia vain jatkettiin kunnes tuli ruokatunti tai päivä loppui. Tämä oli suuri virhe, sillä taukojen merkityksen huomattiinkin olevan varsin suuri. Pienen tauon (muutama minuutti) aina yhden tavoitteen valmistumisen jälkeen todettiin olevan paljon tehokkaampaa pitemmällä tähtäimellä. Yleisen keskustelun määrä ja häiriötekijät Selvä heikkous pariohjelmoinnissa on uupuminen, joka usein näyttää osuvan navigaattorin puolelle. Tämä tapahtuu varsinkin jos navigaattorilla ei ole yksinkertaisesti mitään lisättävää, tai ohjelmoitava alue on jo valmiiksi jo liian yksinkertaista. Pieni, muttei häiritsevä, keskustelu huomattiin hyvin toimivaksi estämään tätä. Navigaattorin, ja tarvittaessa myös ajajan, kannattaa yksinkertaisesti kommentoida koodia vaikka pelkästään huumorilla. Tämä herättää yleensä toisen ja pitää mielenkiinnon yllä molemmilla. Keskustelu tuo tietenkin myös huonot asiat, kuten aiheen vaihtuminen johonkin aivan toiseen. Monesti tuli huomattua, että ohjelmointi loppui ja keskustelun aihe olikin muuttunut harrastukseen liittyväksi. Pienissä määrin tämä ei tietenkään ole ongelma, mutta usein keskustelu venyi tarpeettoman pitkäksi. Pieni korjausidea tähän on pitää keskustelutuokio työhön liittymättömistä asioista ennen ohjelmoinnin aloittamista ja sitten yrittää parhaansa keskittyä pelkkään ohjelmointiin. Usein, pahasti kesken ohjelmoinnin, joku saattaa tulla kyselemään yksinkertaisia kysymyksiä liittyen ohjelmointiin tai muihin asioihin. Tämän jälkeen on luonnollisesti todella vaikea palautua vanhaan tilaan ja jatkaa ohjelmointia kuin mitään ei olisi tapahtunutkaan. Pariohjelmoinnissa huomattiin, että palautuminen olikin paljon helpompaa kuin yleensä. Jos ulkopuolista häirintää tapahtui, niin yleensä viimeistään navigaattori muisti mihin jäätiin. Toisaalta tilanteet, joissa toinen joutui siirtymään pois auttamaan muita, vaati että toinen jäi vain odottelemaan. Tällöin auttaminen maksoikin kahden henkilön työmäärän. Keskustelua tapahtui varsin paljon pariohjelmoinnin yhteydessä ja ulkopuolisilta kysyttiin, oliko se häiritsevää. Kukaan ei ainakaan myöntänyt sen olevan häiritsevää. Huumorin ja palautteen määrän vaikutus Huumorin tärkeys nousi hyvin esille tilanteissa, joissa navigaattori huomaa jatkuvasti toistuvat tai hyvin naurettavat pikkuvirheet. Tilanteesta, jossa navigaattori jatkuvasti nalkuttaa pienistä asioista, voi nopeasti tulla ärsyttäviä molemmille. Jos nämä huomautukset tuo esille pieninä humoristisina kommentteina, on ilmapiiri paljon vapaampaa ja tällöin myös työskentely hauskempaa. Parien vaihtaminen ja mahdolliset ongelmatilanteet Parien vaihtamistamahdollisuutta ei tullut. Jokaisella oli hyvin tarkasti määrätyt työalueet ja ylimääräistä aikaa ei muilta työryhmän jäseniltä löytynyt. Parien vaihtaminen olisi varmasti parantanut koodin laatua yleisesti, sillä jälkeenpäin huomasimme koodissa valtavia tyylipoikkeuksia, jotka olisi ollut hel- 8/11

9 posti korjattavissa pariohjelmoinnilla. Jokaisen oma osa-alue oli toisaalta niin erilainen, että parien vaihtaminen olisi varmasti hidastanut työtahtia suunnattomasti. Vaihtamismahdollisuutta päätettiin kuitenkin yrittää testata seuraavassa toteutusvaiheessa. 3.3 Toteutusvaihe Yleiskuva Toisessa toteutusvaiheessa Python-ohjelmointikieli jätettiin taakse ja vaihdettiin Java-kieleen. Javalla ryhdyttiin rakentamaan web-portaalia, joka hyödyntää ensimmäisessä toteutusvaiheessa luotua taustajärjestelmää. Lähtökohta ohjelmointiteknisessä mielessä oli varsin erilainen 1. toteutusvaiheeseen nähden, sillä kummallekin itse Java-kieli oli entuudestaan varsin tuttua, mutta portaalin toteuttaminen käyttäen noin kymmentä eri Javan päälle rakennettua teknologiaa rinnakkain oli täysin uutta. Lisäksi toteutusta ei rydytty tekemään täysin tyhjästä, vaan pohjana käytettiin AppFuse-ohjelmalla generoitua valmista websivustopohjaa, josta löytyi lähinnä tuki käyttäjien hallintaan. Pariohjelmoinnin kannalta lähtökohta oli mielenkiintoinen, sillä valmiiksi generoidun pohjan päälle ohjelmointi ei aina ole puhdasta ohjelmointia, vaan konfigurointia, josta kerrotaan kappaleessa lisää Muutokset toteutussuunnitelmaan Kiireinen aikataulu aiheutti muutoksen toiseen toteutusvaiheeseen niin, että pariohjelmointi jouduttiin jättämään puolessa välissä kokonaan pois. Näin pystyttiin tekemään periaatteessa enemmän tehtäviä samassa ajassa, tosin koodin laatu kyllä kärsi tästä jonkin verran Havainnot Parien vaihtaminen ja mahdolliset ongelmatilanteet Hieman ennen toisen toteutusvaiheen puolta väliä tarjoutui hetkeksi tilaisuus soveltaa pariohjelmointia css-tyylitiedostojen ohjelmoimiseen käyttäen eri paria kuin ensimmäisessä vaiheessa. Parin vaihto tuotti heti aluksi tietynlaisen mukavuuden tunteen häviämisen, koska pari ei entuudestaan tuntenut toisiansa kovin hyvin. Tämä aikaansai tietynlaisen epämiellyttävän paineen ohjelmointiin, koska toisen koodia ei uskaltanut tai viitsinyt kommentoida yhtä herkästi ja rennosti kuin ensimmäisessä toteutusvaiheessa. Tämä tunne tosin hävisi parin päivän jälkeen ja yhteistyö alkoi sujua paremmin. Muita merkittäviä huomioita parin vaihto ei saanut aikaan. Tehokkaat ja tehottomat pariohjelmoinnin kohteet Toisessa toteutusvaiheessa ohjelmoinnin luonne tosiaan muuttui täysin, koska uuteen teknologiaan ja järjestelmään tutustuminen vei aikansa. Pariohjelmointia pyrittiin aluksi soveltamaan samalla tavalla kuin ensimmäisessä toteutusvaiheessakin, mutta viikon jälkeen havaittiin ohjelmoinnin luonteen muuttuneen enemmänkin uuden opiskeluksi ja olemassa olevan järjestelmän konfiguroinniksi 9/11

10 XML-tiedostojen avulla. Itse koodirivejä tuotettiin toisen toteutusvaiheen alussa todella vähän ja pariohjelmointi ei soveltunut tällaiseen kovinkaan hyvin. Hyvänä puolena pariohjelmointi toki toi tällaisissa olosuhteissa tiedon siirtymisen parin välillä, mutta tehokkuus oli hukassa. Lisäksi huonosti tunnetun järjestelmän debuggaaminen ei osoittautunut missään tapauksessa hyväksi kohteeksi pariohjelmoinnille varsinkin, kun järjestelmän kääntäminen ja käynnistäminen vei joka kerta minuutin verran. Pariohjelmointi ei myöskään soveltunut kovin hyvin css-tyylitiedostojen luomiseen ja muokkaamiseen, koska homma on enemmän muuta yksi arvo ja testaa -tyyppistä ohjelmointia kuin varsinaista koodin tuottamista. Yleisen keskustelun määrä ja häiriötekijät Kiireisemmässä ympäristössä häiriötekijöiden vaikutusten huomattiin tulevan paljon vahvemmin esille. Pariohjelmointi keskeytyi jatkuvasti kysymyksiin ja muuhun avuntarpeeseen. Tästä huomattiin nopeasti, että jatkuva keskeytys pariohjelmoinnissa tuhoaa koko tekniikan täysin. Vaikka pariohjelmointi tekee palautumisen helpommaksi, on se hyvin vaikeaa tilanteissa, joissa vuorotellen toinen joutuu työskentelemään aivan erilaisen ongelman parissa. Tähän on hyvin vaikea mitään ratkaisua suoraan keksiä, sillä tietenkin eteen tulleet ongelmat myös estävät muiden työskentelyä. Jos parien vaihtamista olisi pystytty harrastamaan kunnolla ja tieto olisi kiertänyt aina parien vaihtuessa, olisi häiriötekijöiden määrä varmasti ollut pienempi. 3.4 Yhteenveto Oikein hiottuna pariohjelmointi on varmasti loistava työväline, mutta se vaatii juuri oikeanlaisen työryhmän. Ryhmän olisi hyvä omata samanlainen huumorintaju ja tulla hyvin toimeen toistensa kanssa. Jos ryhmässä on edes yksi, joka ei vain tule toimeen muun ryhmän kanssa, voi se tuhota koko prosessin suoraan. Hyvän ryhmän lisäksi vaaditaan tietenkin pitkää harjoittelua. Seuraavassa on listattuna oleellisimmat havaitut plussat ja miinukset liittyen pariohjelmointiin: + Miellyttävämpää kuin yksin ohjelmoiminen + Koodi huomattavasti parempaa ja huolellisempaa + Soveltuu tarkkuutta vaativaan työhön + Oppiminen ja tiedon jakaminen + Tutustuminen toiseen - Hitaampaa - Parin pitää tulla toimeen keskenään - Ei toimi triviaaleissa ja paljon konfigurointia sisältävissä tehtävissä - Molempien tulee olla samaan aikaan motivoituneita, toisen huono päivä saattaa pilata kaiken - Hankalasti korjattavat ongelmat latistavat tunnelman 10/11

11 Viitteet [1] Williams Laurie A., Kessler Robert R. All I Really Need to Know about Pair Programming I Learned In Kindergarten, Viitattu Saatavissa: borgida/old/275/pairpgming.pdf. [2] Williams, Laurie, Robert Kessler. Pair Programming Illuminated Addison- Wesley, /11