Project group Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: etenemisraportti Pariohjelmointi Mika Lindroos
T-76.115 Software project 2(6) Muutosloki Versio Pvm Tekijä Kuvaus 1.0 28.11.2003 Mika Lindroos Ensimmäinen versio I1-vaiheesta 2.0 8.2.2004 Mika Lindroos Päivitetty versio I2-vaiheesta
T-76.115 Software project 3(6) 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 hankitun palvelimen kautta. Kaikilla ei kuitenkaan ollut mahdollista 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 myös esille muutamia rajoitteita pariohjelmoinnin suhteen. Tiiviin aikataulun vuoksi pariohjelmointi-kertoja 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) Use case Pariohjelmoinnin Yksinohjelmoinnin Pariohjelmointisuhde (pariohjelmoidut tunnit/kokonaistunnit) Bugeja (Blocker / Critical / Major / Minor / Trivial) UC 1.1 Log in 12 0 100 % 2 (0/0/0/2/0) UC 1.2 Log out UC 2.1 Report hours for a work category - - - 1 (0/0/0/1/0) 14 7.5 65 % 9 (0/0/2/7/0) UC 3.1 View 0 15.5 0 % 2 (0/0/0/2/0)
T-76.115 Software project 4(6) reported hours UC 4.1 Add user UC 4.4 View user list UC 5.1 Add work category 9 0 100 % 3 (0/0/0/3/0) - - - 1 (0/0/0/0/1) - - - 2 (0/0/0/1/1) 1.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 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. 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 kuin 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ä iteraatio on ehkä paras tilaisuus eri ohjelmointimenetelmien väliseen vertailuun. Tämän iteraation 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
T-76.115 Software project 5(6) 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 Yksinohjelmoinnin Pariohjelmointisuhde (pariohjelmoidut tunnit/kokonaistunnit) Bugeja (Blocker / Critical / Major / Minor / Trivial) Check in related - 36 0 % 2 (0/0/0/0/2) Framework - 1,5 0 % 0 (0/0/0/0/0) User related Work category related Work time item related 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)
T-76.115 Software project 6(6) 2.1.1. 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 vain luonnollista, että suurempia kokonaisuuksia tehtäessä ohjelmoijat tekevät myös enemmän virheitä. Lisäksi testaajina toimi 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ä keskeisimmäksi mittareiksi nousevat kolme suurinta toiminnallisuusaluetta, jotka sisältävät työtä n. 50-70 tuntia ja pariohjelmoinnin käyttöaste oli 12-46 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 tuottaisi mitään tieteellisesti hyväksyttävää todistusaineistoa. Tutkin vielä I3-iteraation aikana, jos silloin tulisi ilmi jotain yllättäviä tuloksia. Tässä vaiheessa näyttää kuitenkin siltä, että parhainta tietoa pariohjelmoinnin hyödyllisyydestä saataisiin ensi iteraation lopussa tehtävän kyselytutkimuksen avulla. Vaikka kyseessä onkin 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ä.