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 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 Samuel Korpi Päivitetty 2. iteraation kokemusten pohjalta Kari Ylihärsilä Samuel Korpi Lisätty loppuyhteenveto ja pohdiskelua toisesta toteutusiteraatiosta. Lisätty 2. toteutusiteraation lopussa teetetyn palautekyselyn tulokset ja pohdintaa niistä Kari Ylihärsilä Lisätty koodikatselmointiosuus kakkositeraation osalta.

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 viikoittaisista Coding Camp -tilaisuuksista Koodikatselmointi Toteutusiteraatio 1 - Yhteenveto Toteutusiteraatio Kokemuksia viikoittaisista Coding Camp -tilaisuuksista Havaitut ongelmat Koodikatselmointi Toteutusiteraatio 2 - Yhteenveto Yhteenveto Viitteet Liite 1: Toteutusiteraation 1 (I1) web-kyselyn tulokset piirakkakaavioina Liite 2: Toteutusiteraation 2 (I2) web-kyselyn tulokset piirakkakaavioina... 23

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/23

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 osaalueeseensa. 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/23

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 kirjoittaja 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 tilaisuuden jälkeen. Koko projektin osalta laatutarkastelua tehdään keskitetysti, ja koskapa itsenäinen työskentely on kuitenkin projektissamme vallitsevana työskentely- 6/23

7 muotona, 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/23

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 mahdollisimman paljon toteutusta aikaiseksi, jotta mahdollisim- 8/23

9 mat 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. 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. 9/23

10 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 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. Li- 10/23

11 sä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 /23

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 tonkiminen 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/23

13 3.2.4 Toteutusiteraatio 1 - 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 2 Coding camp tilaisuudet jatkuivat iteraation aikana viikoittaisina tapahtumina. Ajaksi valittiin klo keskiviikkoisin. Paikkana aluksi ohjelmatyöluokka T-talolla, myöhemmin eräs Maarintalon ryhmätyöluokista (syy selostettu kohdasta Havaitut ongelmat ). Tilaisuuksien palaveriosuuden agenda 2. toteutusiteraation aikana muotoutui seuraavanlaiseksi: 1. Yleiset asiat ja ohjeistukset (pääarkkitehti) 2. Työn edistyminen (kunkin kehittäjän kohdalla, idea lainattu Scrum-prosessista [2]) Mitä on tehty edellisen tilaisuuden jälkeen? Onko kohdattu ongelmia? Mitä tehtävä seuraavaan tilaisuuteen mennessä? 3. Muut ajankohtaiset asiat/ajatukset (kaikki paikallaolijat) Kokemuksia viikoittaisista Coding Camp -tilaisuuksista Iteraation lopussa ryhmän jäseniä pyydettiin täyttämään palautekysely webissä, samaan tapaan kuin ensimmäisen toteutusiteraationkin lopussa. Kyselyn paino oli toisella toteutusiteraatiolla, mutta kokemuksia myös koko projektin ajalta pyrittiin selvittämään. Kyselyn neljän monivalintakysymyksen tulokset löytyvät piirakkakaavioina liitteestä 2. Näitä tuloksia käsitellään seuraavassa. Listaamme myös joitakin sanallisessa palautteessa esiin nousseita seikkoja. Monivalintakysymykset: 1. Coding Camp -käytännön hyödyllisyys? 2. Tilaisuuksien rakenne 2. iteraation aikana? 3. Millaisiksi koit 2. iteraation Coding Campit verrattuna 1. iteraation vastaaviin? 4. Miten vertailisit Maarintalossa käyttämäämme tilaa T-talon ohjelmatyöluokan kanssa? Tuloksissa on huomattavissa selkeästi positiivinen sävy. Käytäntö todettiin hyödylliseksi valtaosa piti käytäntöä jopa erittäin hyödyllisenä. Tilaisuuksien rakenne (formaalius) oli valtaosan mielestä kohdallaan. Viimeinen kysymys nosti T-talon ohjelma- 13/23

14 työluokan selvästi paremmaksi kuin Maarintalon luokan. Suurin hajonta löytyi kolmannen kysymyksen tuloksista, eli olivatko 2. iteraation tilaisuudet hyödyllisempiä kuin 1. iteraation vastaavat. Tavoite olisi tietenkin ollut, että 2. iteraation tilaisuudet olisi todettu hyödyllisemmiksi näin kehitystä olisi selkeästi tapahtunut oikeaan suuntaan. Kuitenkin peräti 6 vastaajista piti 1. iteraation tilaisuuksia joko yhtä hyödyllisinä tai peräti parempina. Siispä parantamisen varaa vielä jäi. Kyselylomakkeen avoimia kysymyksiä käydään läpi seuraavassa. Listatut seikat on koostettu kyselyn tuloksista. Paikoin saattaa esiintyä joitain ristiriitaisuuksiakin, esim. siitä miten oikein kannattaisi koneet sijoitella coding camp tilassa. Tässä tulee hyviin esiin se, että mielipiteitä on erilaisia. Kannattaakin ennen Coding Camp käytännön aloittamista keskustella tiimin kanssa käytännön järjestelyistä, jotta päästäisiin kaikkien kannalta mahdollisimman toimivaan ratkaisuun Coding Camp tilaisuuksien erot eri iteraatioissa Coding Camp tilaisuuksia ei aloitettu heti ensimmäisen iteraation alussa ja ensimmäinen iteraatio meni aikalailla käytännön opetteluun Toisessa iteraatiossa coding campit olisivat olleet paljon ensimmäistä iteraatiota hyödyllisempiä jos ohjelmatyöluokan kanssa ei olisi ollut niin paljon ongelmia 2. iteraatiossa käytetty Coding Campin ja SCRUMin yhdistelmä osoittautui toimivaksi Toisen iteraation tilaisuuksissa oli enemmän yleistä ja formaalia keskustelua, mikä kasvatti tunnetta siitä, että kaikki ovat paremmin perillä kehityksen tilasta Toisessa iteraatiossa oli enemmän tekemisen meininkiä ja päästiin kiinni varsinaiseen näkyvään toteutukseen Toisessa iteraatiossa oltiin ehkä tietyllä tavalla myös enemmän kiinni omissa hommissamme, eikä coding campinkään aikana ryhmätyöskentelyä tullut aina kovin paljoa harjoitettua Kommentteja Maarintalon luokka vs. T-talon ohjelmatyöluokka Ohjelmatyöluokka ja maarin luokka eivät olleet kovin viihtyisiä T-talon luokassa enemmän Eclipse koneita Maarintalon luokassa koneet olivat nopeampia ja näytöt laadukkaampia Maarintalolla sekä Windows-, että Linux-koneita oli tarjolla Maarintalon luokan suurin miinus on Together Architectin puuttuminen (tarvittiin mm. staattisessa analyysissä) ja tuoreen Eclipse-version puuttuminen Windows-koneista (esti käytännössä Windows-koneiden käyttämisen ohjelmointiin) Tilana hevosenkenkä on mielestäni parempi kuin ohjelmatyöluokassa oleva pulpetisto avoimen tiedon siirtymisen kannalta Maarintalon luokassa koneet olivat hankalasti luokan seinille aseteltuina. Niinpä, jos piti kysyä kaverilta jotain, saattoi joutua rullailemaan luokan päästä päähän Maarilta puuttui printteri luokasta Luokissa pyöri muutakin porukkaa Ihanteellinen tila Coding Camp:in järjestämiseen Koneiden pitää olla riittävän hyviä (tehokkaita) ja verkon toimiva Sekä Linux- ja Windows-koneita käytössä Tarvittavat ohjelmistot 14/23

15 Koneita ei välttämättä tarvita, mikäli koko tiimillä on kannettavat - silloin vain sopivasti pöytätilaa ja nettiyhteys Kunnon tuolit ja muutenkin hyvä ergonomia Koneiden asettelu keskelle huonetta kahteen vastakkaiseen riviin voisi olla toimiva Koneet saisivat olla ainakin pareittain vierekkäin, jotta kaverin kanssa koodaaminen helpottuisi Hevosenkenkätila Tilan tulisi olla eristetty häiriötekijöistä Tilaa sekä palavereihin että ohjelmointiin myös tarvittavat välineet palaverien pitoon (fläppitaulu, mahd. projektori) Samassa rakennuksessa saisi olla toimiva kahviautomaatti (kunnon taukomahdollisuudet) Parannusehdotuksia Tietynasteinen formaalius olisi hyväksi jonkunlainen agenda ja mahd. pöytäkirja esim. wikiin, jolloin ne olisivat coding campiin osallistumattomienkin seurattavissa. Näin edistetään tiedon välittymistä, ja helpotetaan projektin etenemisen seurantaa Projektin loppuvaiheessa ryhmällämme oli wikissä ns. loppurutistus -lista, johon listatut tehtävät käytiin merkkaamassa tehdyksi sitä mukaa kun ne oli hoidettu tällaista käytäntöä voisi laajentaa koko projektin kattavaksi, ja siitä voisi olla myös hyötyä coding campien suunnittelussa. Eli listasta katsottaisiin, mihin tehtäviin coding campissa aikana tulisi keskittyä (priorisointi) Tilaisuudet tulisi järjestää niin, että kaikki kehittäjät pystyisivät olemaan alusta loppuun paikalla. Tämä helpottaisi mahdollisen formaalin keskustelun järjestämistä kerralla ja tekisi tilaisuudesta vähemmän katkonaisen. Meidän projektissamme aikataululliset tekijät tekivät tästä mahdotonta Aikataulu pitäisi sopia sillä tavalla joustavaksi, että ongelmatilanteissa tilaisuutta voitaisiin venyttää ja ongelma hoitaa porukalla alta pois Paikan valinta on oleellinen Varapaikka on hyvä olla tiedossa, ja muutenkin varasuunnitelmat kunnossa Olisi saattanut olla parempi, jos coding campin lopussakin arvioidaan töiden edistyminen eikä odoteta seuraavaan viikkoon. "Scrum" -palaveri olisi voinut olla siis sekä alussa että lopussa Muuta Minusta Coding Camp oli hyödyllinen toimintatapa: edisti kommunikointia, ongelmien ratkaisua jne. Se olisi mahdollistanut pariohjelmoinninkin ihan virallisesti. Sopiva välimuoto tiukasti aikataulutetun ja täysin vapaamuotoisen agendan olisi hyvä. Coding camp oli varmasti hyödyllisin ja projektin etenemisen kannalta tehokkain käytetyistä käytännöistä. Tietyn tyyppiseen kehitysympäristöön tottuneelle voi olla hankala siirtyä tekemään hommia coding camp-tilassa, jossa ei välttämättä aivan samoja mahdollisuuksia kuin esim. kotona. Tehokkuus voi tässä suhteessa hieman laskea, mutta toisaalta coding campin hyödyt kommunikaation ja ongelmien ratkomisen suhteen ovat kiistattomia. 15/23

16 Hyvä käytäntö, johon ei kuitenkaan kannata liian äkkinäisesti rynnätä. Aikaa voi mennä aika lailla hukkaan, mikäli kaikki eivät tiedä mitä oikein pitäisi tehdä Havaitut ongelmat Coding camp tilaisuuksien pitopaikaksi oli ensimmäisessä iteraatiossa valittu ohjelmatyöluokka T-talolta. Tätä käytäntöä päätettiin jatkaa, mutta luokan tietoliikenneyhteyksien katkeamisen takia jouduimme siirtämään tilaisuudet Maarintalon ryhmätyöluokkiin. Ongelmaksi edellä mainittu tilanne muodostui ensimmäisellä kerralla, jolla vika luokassa havaittiin. Meillä ei näet ollut valmiiksi pohdittuna vaihtoehtoista työskentelytilaa, ja tästä syystä tilaisuus tavallaan purkautui yhteisen palaveriosuuden jälkeen kaikkien lähtiessä omille teilleen. Menetimme siis työaikaa, koska tilaisuuteen oli valmistauduttu sillä oletuksella, että luokan laitteet toimivat ja pystymme työskentelemään. On siis ensiarvoisen tärkeää, että ennen työskentelytavan käyttöönottoa ei tyydytä suunnittelemaan ainoastaan normaalia tilaisuuden kulkua, vaan otetaan huomioon myös poikkeukselliset tilanteet. Tilaisuuden pitämiselle on hyvä ennakkoon varata myös vaihtoehtoinen paikka, mikäli edellä kuvatun kaltaisia tilanteita syntyy. Myös muuten kannattaa miettiä miten toimitaan tilanteissa, joissa normaalit työskentelymallit eivät syystä tai toisesta toimi. Esim. mitä tehdään, jos keskitettyyn koodiin (CVS tms.) ei päästä käsiksi palvelimen ongelmien takia (tällöin ei paikan vaihto auta)? Mahdollisuuksien mukaan tulisi tilanne selvittää jonkun ryhmän jäsenen toimesta hieman ennen varsinaista tilaisuutta. Kaikkia ongelmia ei tietenkään voi ennakoida, mutta jos esim. valitun paikan laitteissa/yhteyksissä on jotain vikaa muutama tunti ennen tilaisuutta, niin voidaan suosiolla pitää tilaisuus varapaikassa. Tiedotuksen voi hoitaa esim. tekstiviestein. Näin säästetään se aika, mikäli olisi kulunut alkuperäiseen paikkaan kerääntymiseen, ongelman havaitsemiseen, ja varapaikkaan siirtymiseen Koodikatselmointi Koska facade-paketin luokat eivät olleet kovin merkittävässä asemassa ohjelmoinnin kannalta vaan toteutus keskittyi enemmän käyttöliittymäohjelmointiin toisen toteutusiteraation aikana, on tälle kierrokselle otettu myös gui-paketti vertailuun mukaan. Kuten edellisessäkin koodikatselmoinnissa, mitattiin metriikoita Borlandin Together Architect -työkalulla. Katselmoitavat kooditilanteet ovat klo 8.00 ennen coding camppia ja seuraavana päivänä aamulla samaan aikaan. Tämä sen takia, että ei rajoiteta coding campia siihen mitä kolmessa tunnissa saadaan aikaan, vaan otetaan mukaan myös se mitä välittömästi jälkeenpäin tehdään, tilaisuudessa tehtyjen suunnitelmien ja yhteistyön pohjalta. Näiden lisäksi samat analyysit on ajettu ohjelmakoodille iteraation lopussa Gui-paketin luokat peritään jo java-apin sisäisesti useista eri luokista ja osa koodista on jigloo-työkalulla automaattisesti generoitua. Tästä johtuu se, että osassa tunnusluvuista ohjearvot ylittyvät tässä paketissa. Gui-paketin ja Facade-paketin laskelmat näytetään kummatkin erikseen. 16/23

17 Merkittävimmät lasketut tunnusluvut Facade-paketin osalta: 8.2. Ennen cc:ä 9.2. Jälkeen cc:n Iteraation lopussa. LOC (Lines Of Code, koodirivien lkm): CR (Comment Ratio, kommentteja suhteessa koodiriveihin) NOO (Number of Operations, metodien lkm) PC (Package Cohesion, paketin koheesio) Merkittävimmät lasketut tunnusluvut Gui-paketin osalta: 8.2. Ennen cc:ä 9.2. Jälkeen cc:n Iteraation lopussa. LOC (Lines Of Code, koodirivien lkm): CR (Comment Ratio, kommentteja suhteessa koodiriveihin) NOO (Number of Operations, metodien lkm) PC (Package Cohesion, paketin koheesio) Alla myös yleiskuvan koodista lasketuista tunnusluvuista näyttävät Kiwiat-käyrät. Kuva 4 Facade-paketti 8.2. ennen cc:tä Kuva 5 Gui-paketti 8.2. ennen cc:tä 17/23

18 Kuva 6 Facade-paketti 9.2. jälkeen cc:n Kuva 7 Gui-paketti 9.2. jälkeen cc:n Kuva 8Facade-paketti iteraation lopussa Kuva 9 Gui-paketti24.2. iteraation lopussa Huomioita lasketuista metriikoista: Koodi rupeaa olemaan jo sen verran kypsää, että rivien määrä ei paisu läheskään samaan tahtiin ensimmäisen toteutusiteraation kanssa. Sen sijaan keskitytään tekemään toiminnallisuudet halutun laisiksi ja panostamaan laadunvarmistukseen ja käytettävyyteen. Varsinaiset käyttöliittymän suuret luokat on tehty, nyt viilataan toiminnallisuutta haluttuun kuntoon. Gui-paketin metodit ovat huomattavasti lisääntyneet. Näiden yksityisistä metodeista on joitakin ilman kommentteja. Comment ration lasku selittynee tällä. Gui-paketin laajeneminen kiwiat-käyrällä johtunee mm. siitä, että käyttöliittymäpaketin sisälle on tehty hieman syvemmin facade-paketin tietoja käsittelevää toiminnallisuutta. 18/23

19 3.3.4 Toteutusiteraatio 2 - Yhteenveto Tilaisuuksien sisältö on muotoutunut dynaamisesti tilanteen myötä - kaikilla on koko ajan ollut mielekästä tekemistä. Tilaisuudet ovat olleet myös hyviä hetkiä reflektointiin ja edellisen tehtävän ollessa loppumassa seuraavan tehtävän antamiseen tiimin läsnä ollessa, konkreettisella tavalla. Tässä iteraatiossa otettiin mukaan myös Scrum-prosessista [2] poimittu palaverikäytäntö, jossa reflektoitiin nykytilannetta: Mitä olet tehnyt, onko ollut ongelmia ja mitä aiot tehdä seuraavaan coding campiin mennessä? Tämä on antanut hyvän kokonaiskuvan tilanteen etenemisestä projektissa. 3.4 Yhteenveto Coding Camp on osoittautunut hyväksi ratkaisuksi jonka ansiosta tietoa saadaan tehokkaasti kulkemaan tilaisuuksissa ja ongelmia ratkaistua kaikkien asiasta tietävien tietämyksen ollessa kerralla käytössä. Pienenä haittapuolena tilaisuuden luonne ohjaa välillä tekemään montaa hommaa samaan aikaan ihmisten kysellessä toisiltaan asioita. Kaiken kaikkiaan ryhmän tuottavuus on tehokkaasti kasvanut samalla kun henkilökohtainen tuottavuus on toisten apuna olemisen ansiosta vähän laskenut. Sen sijaan tilaisuuksissa voidaan kaikille näyttää kädestä pitäen suunta ja asiat, joita halutaan tehtävän. Tämän arvo on varsin suuri, kun asiat on voitu selvittää konkreettisesti abstraktien sähköpostikuvausten sijaan. Kaiken kaikkiaan havaitsimme coding camp -käytännön hyväksi ratkaisuksi, jota mitä todennäköisimmin käyttäisimme myös tulevaisuudessa. 19/23

20 4 Viitteet [1] Connell, C. It s Not About Lines of Code. (viitattu ) [2] Advanced Development Methods, Inc. What is Scrum? (viitattu ) 20/23

21 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ä 21/23

22 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 22/23

23 Liite 2: Toteutusiteraation 2 (I2) web-kyselyn tulokset piirakkakaavioina Vastaajina näissä kysymyksissä oli viisi ryhmämme seitsemästä jäsenestä. Coding Camp -käytännön hyödyllisyys Erittäin hyödyllinen Hyödyllinen Tilaisuuksien rakenne 2 Sopiva 4 6 En osaa sanoa Ei kovinkaan hyödyllinen Täysin hyödytön 8 Ei tarpeeksi formaali Liian formaali Tilavertailu 2. iteraation Coding Camp:ien yleisarvio 2 Maarintalon luokka oli parempi Kumpikin yhtä hyviä 2 4 Hyödyllisemmiksi kuin 1. iteraatiossa Yhtä hyödyllisiksi 8 T-talon luokka oli parempi 4 Hyödyttömämmiksi kuin 1. iteraatiossa 23/23