SEPA Päiväkirja Coding Camp T Ohjelmistotuotannon erikoiskurssi (pakollinen osa kurssia T korvauskäytäntö)

Transkriptio

1 SEPA Päiväkirja Coding Camp T Ohjelmistotuotannon erikoiskurssi (pakollinen osa kurssia T korvauskäytäntö) Kari Ylihärsilä 55619H Samuel Korpi 54993J

2 Muutoshistoria TEAMDC-SEPA-CodingCamp v.1.4. ( ) Versio Pvm Tekijä Kuvaus Kari Ylihärsilä Tehtävän kuvaus ja ensimmäinen versio dokumentista Samuel Korpi Samuel Korpi Samuel Korpi Samuel Korpi / Kari Ylihärsilä Käyttöönottosuunnitelma lisätty (kohta 2.). Päivitetty muutenkin sisältöä. Tarkennuksia käyttöönottosuunnitelmaan (kohta 2.) mentorin kommenttien pohjalta. Samalla selkeytetty rakennetta. Ensimmäisen Coding Camp tilaisuuden pohjalta kerättyä yhteenvetoa. Päivitetty I1:sen kokemuksien perusteella, muokattu palautukseen sopivaksi Samuel Korpi Siistitty. Lisätty sivunumeroinnit ja ylä-/alaotsakkeet Kari Ylihärsilä Koodikatselmointi; koodin metriikoita lisätty ja pohdiskeltu Samuel Korpi Lisätty iteraation lopussa teetetyn webbikyselyn tulokset kappaleeseen (Toteutustiteraatio 1 Yhteenveto). Muutenkin siistitty palautusta varten.

3 Sisällysluettelo 1 Johdanto Menetelmän soveltaminen projektissa Suunnittelu Coding Camp -tilaisuuden kulku Tuloksien kerääminen Tuloksien analysointi Kokemuksia ja mahdolliset muutokset PP-iteraatio Toteustusiteraatio Coding Camp I (to klo 14:30-18:00 T-talon ohjelmatyöluokassa) Kokemuksia viikottaisista Coding Camp -tilaisuuksista Koodikatselmointi Yhteenveto Toteustusiteraatio Yhteenveto Viitteet A. Liite 1: Toteutusiteraation 1 (I1) web-kyselyn tulokset piirakkakaavioina... 15

4 1 Johdanto Coding Campilla tarkoitamme käytäntöä, jossa vähintään kerran kussakin iteraatiossa järjestetään etukäteen suunniteltu työskentelysessio, jolloin vähintään ryhmämme kehittäjät tekevät töitä projektin eteen yhdessä, samassa paikassa ja samaan aikaan. Tutkimme eri näkökulmista keskitetyn työskentelytavan tuottavuutta verrattuna hajautettuun työhön, jossa useimmat ryhmän jäsenet tekevät asioita eri paikoissa eri aikaan. Hajautetun työn etuja ovat keskittyminen tehtävään sekä tehokas ajankäyttö siltä osin, kuin tekijälle on oma tehtävä täysin selvä. Keskitetyn työn etuja taas ovat tehokas tiedon siirtyminen kokemusten kautta sekä parempi ongelmanratkaisu, kun kaikkien taitoja saadaan hyödynnettyä samaan aikaan. Tutkimme "Coding Camp"-käytännön tuottavuutta ainakin seuraavista näkökulmista: Ryhmän tuottavuus työtunteihin nähden, tuotetun koodin / tuotosten laatu (virheettömyys), tiedon siirtyminen ryhmän sisällä sekä työskentelytapojen nautittavuus. Valitettavasti tässä esitetystä työskentelytavasta ei ole tehty siinä määrin tutkimuksia, että kunnollisia viitteitä kirjallisuudesta voisi tässä esittää. Olemmekin kiinnostuneita näkemään, minkälaisiin tuloksiin käytäntö oman projektimme piirissä johtaa. 4/16

5 2 Menetelmän soveltaminen projektissa Alkuperäinen suunnitelma oli soveltaa menetelmää vähintään työpäivän verran kussakin iteraatiossa. Koska esimerkiksi I1-iteraatio on kuitenkin ajallisesti melko pitkä, päätettiin se ryhmän toimesta jakaa kahteen osaan. Coding camp sijoittui luontevasti kumpaankin iteraation puoliskoon, ja samalla päätettiin hieman lyhentää yhden session pituutta n. puolikkaaseen työpäivään (3-4 h). Myös sessioon osallistuvien henkilöiden määrää päätettiin rajoittaa käsittämään lähinnä ryhmän kehittäjäporukka. Tällä pyritään paremmin kohdentamaan menetelmä varsinaiseen koodaustyöhön, palaverit yms. ovat asia sinänsä ja kuuluvat omaan osa-alueeseensa. 2.1 Suunnittelu Jotta työskentelysessiosta saataisiin mahdollisimman suuri hyöty irti, on se suunniteltava tarkoin etukäteen. Pari käytännön asiaa pohjustavat muuta suunnittelua: mahdollisimman hyvin kaikille sopivan ajan sekä sopivan työympäristön valinta. Ei ole paljon hyötyä pitää koko tilaisuutta, mikäli puolet kehittäjistä ei pääse paikalle. Työympäristö taas vaikuttaa osaltaan menetelmän toimivuuteen, ja yleisestikin työtehoon ja tuloksiin. Kurssin tiimoilta helppo valinta työympäristön suhteen on ohjelmatyöluokka, koskapa tarpeelliset kehitysohjelmistot löytyvät kyseisen luokan työasemilta valmiina. Tosin mikäli kaikilta löytyy omat kannettavat, voi jokin tavallinen ryhmätyötila ajaa saman asian. Seuraavassa alkuperäinen suunnitelma Coding Camp-päivien agendasta: Ajan ja paikan ollessa selvillä, on tilaisuuden agenda tärkein. Tämä on projektiryhmän pääarkkitehdin (Kari) vastuulla, ja sisältää mm. seuraavassa listassa esitettyjä seikkoja. Coding Camp agenda on oltava esillä esim. ryhmän kotisivuilla tai wikissä tilaisuutta edeltävänä päivänä klo. 16:00 mennessä, jotta sitä ehditään vielä kommentoida. Pääarkkitehti tiedottaa asiasta tilaisuuteen osallistujia sähköpostitse. 1. Tilaisuuden rakenne (aikataulu) suurpiirteisesti esitettynä. Alkuun lyhyt (n. 15 min) alkupalaveri, jossa käydään pikaisesti läpi projektin senhetkinen tilanne ja kerrataan vielä kullekin henkilölle jaetut tehtävät. Tämän jälkeen n. 3 tuntia vapaata työskentelyä (pari taukoa kannattaa pitää, ihan omaan tahtiin). Loppuaika tilaisuudesta kerrataan mitä saatiin aikaiseksi ja pohditaan miten koodaustyö etenee tästä eteenpäin. 2. Mahdolliset ongelmakohdat, joita tilaisuudessa tullaan koko kehitysporukalla käsittelemään. Kaikkien tilaisuuteen osallistuvien tulisi pohtia etukäteen sellaisia kysymyksiä, joita voisi olla kannattavaa pohtia koko kehitysporukalla. Nämä kysymykset lähetetään pääarkkitehdille kaksi päivää ennen tilaisuutta klo 20:00 mennessä, jotta ne ehtisivät agendaan. 3. Kullekin tilaisuuteen osallistujalle tehtäväkuvaus. Kunkin iteraation alussa jaetaan tehtävät (vastuualueet) kehittäjien kesken. Myös coding campissa on tarkoitus työskennellä omien vastuualueidensa parissa. On kuitenkin hyvä ennakkoon päättää yksi tarkemmin määritelty tehtävä, jonka pitäisi olla sopivan kokoinen tilaisuudessa suoritettavaksi. Mikäli jollekin vastuualueelle on määrätty kaksi tai useampi vastuullinen henkilö, voi tilaisuutta varten määritellä tehtäviä myös pareittain. Pariohjelmointi on suotavaa. Tehtäväkuvaukset tulee lähettää pääarkkitehdille samoin kuin kohdan 2 kysymykset, kaksi päivää ennen tilaisuutta klo 20:00 mennessä. 5/16

6 2.2 Coding Camp -tilaisuuden kulku Varsinainen coding camp etenee edellä kuvatun agendan mukaisesti. Tilaisuuden lopussa kerätään vielä kommentteja tilaisuuden hyödyllisyydestä. Parannusehdotuksia otetaan luonnollisesti myös vastaan. Koska Coding Camp päätettiin ensimmäisen tilaisuuden jälkeen muuttaa viikoittaiseksi tapahtumaksi, on tilaisuuksien suunnittelussa joustettu. Tarkempaa tietoa luvussa Tuloksien kerääminen Johdanto-osiossa on mainittu, että coding camp työskentelytavan hyödyllisyyttä tullaan tutkimaan mm. seuraavista näkökohdista: Ryhmän tuottavuus työtunteihin nähden, tuotetun koodin / tuotosten laatu (virheettömyys), tiedon siirtyminen ryhmän sisällä sekä työskentelytapojen nautittavuus. Seuraavassa listassa on käsitelty kutakin näkökulmaa erikseen kiinnittäen huomiota erityisesti mahdollisiin metriikoihin, joita tulosten keräämisessä voidaan hyödyntää. Ensin kuitenkin määritellään termi tuottavuus, joka on oleellinen sopivien metriikoiden valintaa silmälläpitäen. Termi: Tuottavuus Määritelmä: Ohjelmoinnin yhteydessä tuottavuudesta puhuttaessa usein viitataan ns. LOC:iin (Lines of code) eli koodirivien määrään. LOC on helppo mitattava, mutta valitettavan epävarma kun vertaillaan tuloksia. Saman toiminnallisuuden kun voi useimmiten toteuttaa hyvinkin erimittaisilla koodinpätkillä, jopa koodin kokonaismäärää tiputtamalla riippuen siitä millaisia ratkaisuja ohjelmoija on sattunut tekemään. Tärkeää on, että lopputuloksena syntyvä koodi on selkeätä (puhdasta), yksinkertaista, oikeata ja hyvin dokumentoitua (kommentoitua). Asiaa on käsitelty tarkemmin mm. artikkelissa [1]. Kyseisen artikkelin tekijä päätyy lopuksi seuraavaan määritelmään (vapaasti kääntäen): Tuottavuus on kykyä ratkaista asiakkaan ongelmat (täyttää asiakkaan vaatimukset) nopeasti ( Ability to solve customer problems quickly. ). 1. Ryhmän tuottavuus työtunteihin nähden. Coding Camp tilaisuudessa työtuntien määrä on tarkkaan rajattu. Selvitettäväksi jää käytettävissä olevan ajan puitteissa saavutettu tuottavuus. Ongelmana tässä on se, että tuottavuutta on hyvin hankala lähteä mittaamaan, kuten edellä esitetyn määritelmän pohjalta voidaan päätellä. Tuotetun koodin määrä (LOC) yhdessä seuraavana listassa mainitun laatu/virheettömyys-näkökulman kanssa on yksi mittari. Lisäksi on pohdittava aikaa, jonka yksittäinen kehittäjä käyttää muun ryhmän kanssa kommunikointiin (listassa kolmantena). Myös ohjelmakehitykseen liittyvien oivallusten (miten asiat voisi tehdä helpommin/vähemmällä koodilla) esiintyminen tulisi kirjata. Tuloksien yhdistelemiseen ja analysointiin on varattava aikaa. 2. Tuotetun koodin / tuotosten laatu (virheettömyys). Koodissa esiintyvien bugien määrä. Bugeja kirjattaessa merkataan löytyikö bugi coding camp:ssa tuotetussa koodissa vai ei, milloin bugi löydettiin, ja miten helposti bugi oli korjattavissa (oliko coding camp:lla vaikutusta asiaan). Laatumetriikoita ovat myös koodin selkeys, yksinkertaisuus ja kommentointi. Coding camp:ssa tuotettu koodi tulisi näiden osalta käydä läpi mahdollisimman pian itse 6/16

7 tilaisuuden jälkeen. Koko projektin osalta laatutarkastelua tehdään keskitetysti, ja koskapa itsenäinen työskentely on kuitenkin projektissamme vallitsevana työskentelymuotona, voidaan keskitetyn laatutarkastelun tuloksia verrata myös coding camp tilaisuuksissa tuotetun koodin osalta saatuihin tuloksiin. 3. Tiedon siirtyminen ryhmän sisällä. Kukin kehittäjä omalta osaltaan arvioi coding camp:in hyödyllisyyttä tiedonkulussa. Alkuperäinen suunnitelma oli kirjata tilaisuudessa kommunikointiin käytetty aika ylös tehtäväkohtaisesti (eli mitä oltiin tekemässä, miksi tarvetta kommunikoinnille ja minkä verran aikaa siihen kului) ja arvioida, minkä verran aikaa olisi vaadittu vastaavan kommunikaatiotarpeen hoitamiseksi tilaisuuden ulkopuolella. Samaa suunniteltiin myös normaaliin itsenäiseen kehitystyöhön; Kun kehitystyössä tulee ongelmia niin kirjataan ylös ongelma, kommunikaatiotapa (sähköposti/puhelin/wiki/ ), käytetty aika jne. Ja pohditaan olisiko ryhmässä asia selvinnyt nopeammin. Kaikkea ei kuitenkaan kannata kirjata, omaa harkintaa käytettävä. Kommunikoinnin eritteleminen ja ylöskirjaaminen todettiin kuitenkin turhan raskaaksi ja huomiota olennaisesta asiasta poisvieväksi käytännöksi. Tämän takia kommunikaatiopistelokia ei pidettykään, vaan tiedon siirtymistä arvioitiin ryhmän sisäisesti, kysymällä mielipiteitä. 4. Työskentelytapojen nautittavuus. Selvitetään mielipidekyselyin. Tuloksia kerätään läpi koko projektin eri tilanteissa: varsinaisten coding camp tilaisuuksien aikana kunkin kehittäjän toimesta itsenäisesti: listan kohtiin 2 ja 3 liittyen, sopivat lomakkeet laaditaan tilaisuuksien lopussa palautteen yhteydessä: lähinnä listan kohtaan 4, eli kysellään osallistujien kommentteja ja otetaan mielipiteet talteen koodin läpikäyntinä tilaisuuksien jälkeen: listan kohtiin 1 ja 2, Samuel ja Kari eli tästä SEPAsta vastuussa olevat hoitavat kunkin ryhmän jäsenen toimesta tilaisuuksien ulkopuolella: listan kohtiin 2 ja 3, sopivat lomakkeet laaditaan Iteraation lopussa koostetun kyselyn kautta: sähköpostilla taikka weblomakkeella 2.4 Tuloksien analysointi Tuloksia kerätään hyvin eri tavoin ja useista lähteistä. Siispä tulosten yhdistämiseen ja analysointiin kuluu aikaa. Kummastakin iteraatiosta tehdään omat yhteenvetonsa, loppuun ehkä vielä vertaillaan tapahtuiko jotain havaittavaa kehittymistä menetelmän suhteen projektin aikana. 7/16

8 3 Kokemuksia ja mahdolliset muutokset 3.1 PP-iteraatio Coding Camp ei varsinaisesti kuulunut vielä projektin suunnitteluosuuteen. Saimme kuitenkin jonkin verran esimakua ja kokemuksia iteraation lopussa pitämästämme work shop -päivästä. Hyvinkin optimistisena alkutavoitteena tuolle päivälle oli jo päästä hieman varsinaisen työskentelyn, eli koodauksen, makuun (tai ainakin tutustua olemassa olevaan koodiin). Lopputuloksena syntyi kuitenkin lähinnä work shop -tyylinen suunnittelutilaisuus. Päivän mittaan tuli selkeäksi myös se, että kokonainen työpäivä on liian rankka coding campiakin ajatellen. 3.2 Toteustusiteraatio Coding Camp I (to klo 14:30-18:00 T-talon ohjelmatyöluokassa) Paikalla oli koko ryhmä Elinaa lukuun ottamatta. Tosin Aleksi joutui poistumaan n. klo 15:50 ja Santeri saapui vasta n. klo 16:05. Tilaisuus sujui kuitenkin melko hyvin suunnitelmien mukaan. Seuraavassa taulukossa on hieman listattu tilaisuuden satoa tiettyjen seikkojen osalta ( +/- -sarake määrittelee kunkin käsitellyn seikan onnistumista tilaisuudessa): +/- Kommentit Tilaisuuden hyödyllisyys + Tilaisuus oli selkeästi hyödyllinen kaikkien osallistujien mielestä Tiedon siirtyminen + Tieto siirtyy kasvotusten huomattavasti paremmin kuin esim. puhelimessa/sähköpostilla. Myös epäselviksi jääneet seikat yleensä selkiävät paremmin. Ongelmien ratkaisu + Selkeästi nopeampaa, kun useamman henkilön voimin selvitetään missä vika. Ryhmän tuottavuus + Edut tiedon siirtymisessä ja koko ryhmän taitojen käytettävissä olemisesta ongelmanratkaisussa sekä asioista päättämisessä huomattavasti parantavat tuottavuutta. Henkilökohtainen tuottavuus - Porukassa huomio saattaa välillä herpaantua omasta tehtävästä (joku kysyy jotain - sitä tulee pohdittua ja sitten kestää taas hiukan aikaa saada omista ajatuksistaan kiinni). Tuotetun koodin määrä - Edelliseen kohtaan viitaten oman huomion poukkoileminen asiasta toiseen vähentää luonnollisesti myös syntyvän koodin määrää. Toisaalta yksi tilaisuuden päätavoitteista onkin juuri ongelmakohdista selviäminen ja ehkäpä turhan koodin välttäminen toteutusideoita vaihtamalla, joten tuotetun koodin määrällä ei sinänsä ole merkitystä. Tuotetun koodin laatu - Koska tilaisuus on lyhyt, ei kommenttien kirjoittamiseen ja koodin putsaamiseen tule käytettyä paljoakaan aikaa. Järkevämpää onkin saada 8/16

9 mahdollisimman paljon toteutusta aikaiseksi, jotta mahdollisimmat ongelmakohdat tulisivat esiin ja niitä voitaisiin yhdessä katsoa. Koodia voi putsata hyvin itsenäisestikin. Kuitenkin kommentointi tulisi muistaa ainakin sillä tasolla, että vielä kotona ymmärtää mitä tuli tehneeksi. TODO-kommentteja olisi myös hyvä käyttää merkkaamaan kohtia, joissa töitä on vielä tehtävä. Mitään numeerisia arvoja (prosenttilukuja tms.) ei yhden tilaisuuden pohjalta vielä oikein voi antaa. Iteraation lopussa tutustutaan koodiin hieman tarkemmin. Tästä enemmän kappaleessa Koodikatselmointi. Muutosehdotuksia - Coding Camp-tilaisuuksia pidettäisiin säännöllisesti (viikoittain), viikkopalaverien yhteydessä taikka mikäli ei varsinaisesti palaverissa käsiteltävää asiaa niin jopa viikkopalaverin korvaavana - Kehittäjäporukan palaveriosuus voidaan yleensä sisällyttää coding camptilaisuuteen, sillä palaverissa käytävät asiat kuitenkin useimmiten ovat hyvin toteutuskeskeisiä - Tilaisuutta lyhennettäisiin vielä hieman n. 2-3 tuntiin. Paljoa kyseisessä ajassa ei välttämättä ehditä koodaamaan, mutta toisaalta ongelmatilanteissa päästään paremmin eteenpäin kun voi kaverin kanssa ja tarvittaessa koko porukallakin pohtia ratkaisua. - Manageriryhmänkään mukanaolo ei ole välttämättä haitta. Kuitenkin työskennellään pääasiassa pienemmissä ryhmissä. - Kaikkien kehittäjienkään ei ole välttämätöntä osallistua jokaiseen tilaisuuteen. Mikäli omalta osalta on selvää miten edetä, voi aivan hyvin jäädä kotiin koodaamaan. - Koska tilaisuuksia suunnitellaan pidettäväksi viikoittain, ei jokaiseen tilaisuuteen ole mitään järkeä lähteä koostamaan tarkkaa agendaa (työtunteja palaisi tilaisuuden suunnittelemiseen liikaa). Tarkkaan suunniteltuja tilaisuuksia pidettäisiin alkuperäisen suunnitelman mukaan 1-2 kpl iteraatiota kohden. Muissa tilaisuuksissa ohjelma hieman vapaampaa, ongelmia käsitellään sen mukaan mitä osallistujilla on mielessään. Alussa pidetään kuitenkin lyhyt tilannekatsaus. Lopun palautekeskustelu voidaan tarvittaessa lyhentää käsittämään ainoastaan lyhyt katsaus siihen mitä tilaisuudessa saatiin aikaan ja miten tästä edetään Kokemuksia viikoittaisista Coding Camp -tilaisuuksista Ensimmäisen tilaisuuden pohjalta esille tulleet muutosehdotukset otettiin pääosin käyttöön lopuissa Coding Camp tilaisuuksissa. Erot edellisen kappaleen muutosehdotuksiin ja lopulliseen toteutukseen on listattu lyhyesti alla: - Viikkopalaverit käytännössä korvattiin coding camp:illa. - Tilaisuuden kestoksi asettautui n. 3 h (tiistai aamuisin klo 9-12) - Käytännössä tilaisuudet osoittautuivat melko lailla epäformaaleiksi. Ihmiset saapuivat paikalle hieman eri aikoihin, joten mitään varsinaista keskitettyä tilannekatsausta oli hankala pitää. Palautekeskustelua lopussa ei myöskään normaalisti pidetty. 9/16

10 Kokemuksia kerättiin iteraation lopussa teetetyllä web-kyselyllä, johon vastasi viisi ryhmämme seitsemästä jäsenestä. Seuraavassa käydään läpi kyselyn tuloksia piirakkakaavioiden avulla. Osallistumiskertoja Osallistumisprosentti on ollut varsin hyvä, valtaosa kyselyyn vastanneista oli paikalla kaikilla kerroilla. Coding Camp tilaisuuksia järjestettiin tässä iteraatiossa kappaleessa käsitellyn tilaisuuden lisäksi kolme kappaletta. 4 Tilaisuudet olivat hyödyllisiä 4 täysin samaa mieltä osittain samaa mieltä en osaa sanoa Yleisesti ottaen Coding Camp tilaisuudet on nähty positiivisina. Tosin hajontaa on huomattavissa, eli parannettavaa vielä löytyy. 2 osittain eri mieltä täysin eri mieltä Loput kaaviot löytyvät liitteestä 1. Valitettavasti osa tuloksista on puutteellisia (joitakin vastauksia jouduttiin hylkäämään) kyselylomakkeessa havaitun virheen johdosta. Kyselyssä oli myös muutama avoin kysymys, ja lisäksi mahdollisuus antaa omia kommenttejaan. Alla vielä koostettuna muutama seikka: - Tilaisuudet ovat selkeästi vähentäneet kommunikointiin tarvittavan ajan määrää, noin parilla tunnilla viikossa. Yksittäisissä tapauksissa aikaa on saattanut säästyä jopa yli viisi tuntia viikossa lähinnä tämä on pätenyt Vesan suhteen, joka pääosin on vetänyt pääarkkitehdin hommia ja näin joutunut kommunikoimaan paljon kaikkien kanssa. - Ryhmässä työskenneltäessä huomio saattaa herpaantua hetkeksi omasta työstä, jos joku esim. kysyy jotain. Toisaalta taas itsenäisesti kotona työskenneltäessä ympärillä on muita huomiota puoleensa vetäviä tekijöitä. Eli työskentelyteho onkin lähinnä siitä kiinni kuinka hyvin pystyy työhönsä keskittymään ympäristöstä huolimatta. Tämä luonnollisesti riippuu hyvin paljon henkilöstä joku koodaa mieluummin yksin ja joku toinen porukalla. Tämänkertaisessa kyselyssä ei tätä kysytty, mutta voisi olla mielenkiintoista selvittää tämä ryhmämme osalta. - Tilanteita, joissa ei vain tahdo päästä työssään eteenpäin, on hankala välttää. Joskus pitää odottaa että joku toinen saa hommansa valmiiksi ennen kuin pääsee itse jatkamaan. Tai sitten ei edes ole aivan täysin selvillä oma tehtävä on 10/16

11 esimerkiksi juuri saanut edellisen hommansa valmiiksi ja sitten on selvitettävä mihin tästä jatketaan. Coding Camp:ssa kuitenkin tällaisia tilanteita ei saisi tulla vastaan. - Coding Camp tilaisuudet tulisi pitää suunniteltuina, ainakin jollain tasolla. Vaikeaa on löytää sopiva tarkkuus suunnitelmille (agendalle). Suunnittelu vie aikaa. Lisäksi, koska kyseessä on työskentelytilaisuus ei palaveri ei mitään minuutintarkkaa agendaa ole järkevä tehdä. Ja millä mitataan tilaisuuden onnistumista? Kannattaisi ehkä antaa jonkinlainen tavoite kullekin tilaisuudelle, tavoite koko projektin kannalta ja sitten ehkä myös henkilökohtainen tavoite kullekin osallistujalle erikseen Koodikatselmointi Rajoitimme tuotetun koodin metriikoiden laskemisen Facade-paketin luokkiin, koska käyttöliittymä on suureksi osaksi automaattisesti työkaluin generoitua koodia. Lisäksi käyttöliittymän luokat peritään useasta Java-luokasta jo ennen käyttöönottoa, joka myös sotkisi metriikoita. Koodin metriikoita mitattiin Together Architect työkalulla, joka on myös projektin kehitystyökalu. Pyrimme Coding Campin aikana saamaan tehokkaasti ongelmat ratkaistua jolloin pääpaino ei ollut kommenttien siisteydellä. Tämä tehtiin jälkeenpäin, kukin omalla ajallaan. Koodia on katselmoitu ensimmäisen Coding Camp tilaisuuden (10.11.) ympäriltä, ja lisäksi iteraation lopussa. Alla merkittävimmät tulokset: LOC (Lines Of Code, koodirivien lkm): CR (Comment Ratio, kommentteja suhteessa koodiriveihin) NOO (Number of Operations, metodien lkm) PC (Package Cohesion, paketin koheesio) Allaolevat Kiwiat-käyrät antavat yleiskuvan kerätyistä metriikoista ja niiden suhteista raja-arvoihin. Kuva 1 Kiwiat-päivä ennen Coding Campia Kuva 2 Kiwiat-käyrä Coding Campin jälkeen /16

12 Kuva 3 Kiwiat-käyrä 1. Iteraation lopussa Comment Ratio-tunnusluvun laskutapaa emme ole selvittäneet, mutta mitä suurempi luku on sitä enemmän kommentteja suhteessa koodiin. Tuloksista voidaan tehdä mm. seuraavia johtopäätöksiä: Koodi on ollut melko raakiletta ja vähän kommentoitua aivan alussa. Iteraation palautuksen kohdalla kaikki koodi on kommentoitua, mikä myös näkyy tunnusluvussa. Keskivaiheilla sen sijaan käytimme Eclipsen kommenttiblokin generöintiä ja monissa kohdissa metodien kuvaukset olivat vielä tyhjät. Koodirivien määrä on tasaisessa kasvussa. Alussa kasvu on nopeinta kun tehdään runkoja toiminnallisuudelle ja myöhemmin hitaampaa, kun toiminnallisuuksia sovitetaan yhteen ja toimintaa varmistetaan. Sen sijaan uusia metodeja on ilmaantunut lopussa koodirivien määrän kasvuun suhteessa enemmän. Myöhemmässä vaiheessa Facade-pakettiin on kirjoitettu enemmän koodia joka kurkottaa vanhaan simulaattoriin lukemaan/asettamaan arvoja. Tämä näkyy lopussa paketin koheesion vähenemisenä siitä hyvästä, että paketin ulkopuolinen toiminnallisuus saadaan aikaan. NORM Number of Remote Methods, eli etämetodikutsujen määrä on ennen Coding camp-päivää ollut korkea, koska facade-luokka oli alun perin rakennettu käyttämään simulaattorin rakenteita koostumuksensa selvittämiseen omien sisäisten rakenteidensa sijasta. Monimutkaisten simulaattoritietorakenteiden tomkiminen näkyi myös luokkakohtaisten metodien monimutkaisuudessa (WMPC1, Weighted Methods per Class, painotettu syklomaattisuuden mukaan). RFC (Response Set for Class, omien ja perittyjen + kutsuttujen metodien määrä) on myös yllä olevasta syystä ensin pienentynyt Coding Campin jälkeen ja iteraation loppua kohti pikkuhiljaa kasvanut. Yhteenvetona koodikatselmoinnista todettakoon, että koodimme täyttää normit varsin hyvin. WMPC1, RFC ja NORM ylittyvät hieman johtuen koodin kytkennästä ulkopuoliseen simulaattoriin. Arvoja on kuitenkin myös rajalla, joten kehitystyössä kannattaa noudattaa huolellisuutta koodin järjestelyssä. 12/16

13 3.2.4 Yhteenveto Kokonaisuutena Coding Camp on havaittu hyväksi ratkaisuksi, ja tulemme sitä jatkamaan myös toisen toteutusiteraation aikana. Mitä luultavimmin käytäntö tulee säilymään jokaviikkoisena. Tilaisuuksien sisältöä on kuitenkin pohdittava nykyistä paremmin; tilaisuuden avoimuus tulisi säilyttää, mutta jonkinlainen agenda ja tavoite olisi hyvä asettaa. Ensimmäisessä iteraatiossa ideana oli pitää yksi tai kaksi paremmin suunniteltua tilaisuutta, käytännössä agenda oli laadittu ainoastaan ensimmäiseen tilaisuuteen. Pohdimme asiaa vielä ennen seuraavan iteraation ensimmäistä coding camp:ia (menee tammikuulle), ja mietimme olisiko parempi pitää muutama hyvin suunniteltu tilaisuus, vai pyrkiä laatimaan agenda/tavoitteet koskettamaan pidempää jaksoa kerralla (kattamaan useamman tilaisuuden). 3.3 Toteutusiteraatio Yhteenveto 13/16

14 4 Viitteet [1] Connell, C. It s Not About Lines of Code. (viitattu ) 14/16

15 A. Liite 1: Toteutusiteraation 1 (I1) web-kyselyn tulokset piirakkakaavioina Sain tilaisuuksien aikana enemmän tehtyä kuin vastaavassa ajassa yksin 5 25 % 25 % täysin samaa mieltä osittain samaa mieltä en osaa sanoa osittain eri mieltä täysin eri mieltä Yllä olevaan kaavioon liittyen: Yksi tulos jätetty huomiotta lomakkeessa havaitun virheen johdosta. Ryhmä sai tilaisuuksissa enemmän aikaan (projekti eteni paremmin) kuin jos kukin olisi työskennellyt vastaavan ajan yksin 33 % 67 % täysin samaa mieltä osittain samaa mieltä en osaa sanoa osittain eri mieltä täysin eri mieltä Yllä sekä alla oleviin kaavioihin liittyen: Kaksi tulosta jätetty huomiotta lomakkeessa havaitun virheen johdosta. Tilaisuuksien pituus (n. 3 h) on sopiva 33 % 67 % täysin samaa mieltä osittain samaa mieltä en osaa sanoa osittain eri mieltä täysin eri mieltä 15/16

16 Sopivin rakenne Coding Camp -tilaisuudelle 2 Epäformaali 6 2 Erilliset palaveriosuudet, muuten epäformaali Yksityiskohtainen agenda Kommunikaatiosäästö / viikko 2 2 ei säästöä, 2h menetys 6 ei säästöä, 1h menetys ei säästöä/ei menetystä 1h säästö 2h säästö 3h säästö 4h säästö Jouduitko koskaan Coding Camp - tilaisuuksien aikana tilanteeseen, jossa tunsit olevasi tyhjänpanttina (asiat eivät edenneet, etkä pystynyt tekemään mitään)? Ovatko tilaisuudet olleet sisällöltään riittäviä? 4 Kyllä 4 6 Kyllä Ei 6 Ei 16/16