Team Spider

Versio	Pvm	Tekijä	Kuvaus
2.00	17.6.2008	Pasi Pekkanen, Kari Niiranen, Vesa Pirilä, Roni Tammisalo, Nico Hiort af Ornäs, Ville Rantamaula	Läpikäynti yhdessä
1.98	16.6.2008	Pasi Pekkanen, Kari Niiranen, Vesa Pirilä, Roni Tammisalo, Nico Hiort af Ornäs, Ville Rantamaula	Käytetyt menetelmät
1.07	15.6.2008	Nico Hiort af Ornäs	Tilanneraportit, Käyttöliittymäprototyypit
1.06	15.6.2008	Nico Hiort af Ornäs	Oppimistulokset ja palaute
1.05	15.6.2008	Vesa Pirilä	Oppimistulokset, palaute, linkkejä laatudokumenttiin
1.04	13.6.2008	Nico Hiort af Ornäs	Johdanto ja projektin eteneminen
1.03	12.6.2008	Nico Hiort af Ornäs, Pasi Pekkanen	Sprinttien goalit
1.02	12.6.2008	Nico Hiort af Ornäs	Sprintin tehtävät ja niihin käytetyt tunnit
1.01	12.6.2008	Nico Hiort af Ornäs	Sprintien burndownit
1.00	10.6.2008	Nico Hiort af Ornäs	Viime ryhmän pohja

Sisällysluettelo

1. Johdanto

Asiakkaan tavoitteena oli lisätä Agilefant-ohjelmistoon uusi tuntikirjanpito-ominaisuus. Käyttäjän tulisi pystyä tämän ominaisuuden avulla kirjata ja saada raportteja käytetyistä tunneista. Tätä ominaisuutta lähdettiin toteuttamaan kuuden hengen ryhmällä.

Tämä projekti toteutettiin intensiivisenä ohjelmistoprojektikurssina aikavälillä 19.5.2008 - 18.6.2008.

2. Projektin eteneminen

Tämä projekti jaettiin useampiin eri sprintteihin seuraavasti:

Sprint	Aikaväli
Sprint 1 (Warm-up Sprint)	19.5.2008 - 23.5.2008
Sprint 2	26.5.2008 - 29.5.2008
Sprint 3	2.6.2008 - 6.6.2008
Sprint 4	9.6.2008 - 12.6.2008
Sprint 5	12.6.2008 - 16.6.2008

2.1 Sprint 1 (Warm-up Sprint)

Tämän sprintin tavoitteena oli tutustuttaa Spider ryhmä jäsenet toisiinsa, Agilefanttiin ja käytettyihin tekniikoihin.

Asiakas oli myös luonut ryhmälle listan warm-up tehtävistä, joita ryhmän piti sprintin aikana toteuttaa. Tehtävät eivät olleet kovinkaan vaativia, vaan sisältivät ennemmin pieniä korjauksia ja viilauksia.

Sprintin lopussa oli tarkoitus julkaista uusi versio ohjelmistosta, mutta tähän ryhmällä ei jäännyt aikaa. Julkaistus tehtiin heti seuraavan viikon maanantaina.

2.1.1 Sprintin tehtävät ja niihin käytetyt tunnit

Tehtävä	Tuntimäärä
WARM-UP, BUG: Invalid backlog item iteration selection	4h 30min
TIMEBOX, WARM-UP: Current date in burndown	10h 30min
WARM-UP: Projekti-sivun overhead-kentälle yksikkö	2h
WARM-UP: Loadin jatkokehitys: non-estimated BLI's näkyviin	5h
WARM-UP: Load taulukon nollat	10h
WARM-UP: Linkki pikkuburndownista näyttämään iso kuva	2h
WARM UP: Taskien tilan editonti esiin Backlog Item -sivulle	4h
WARM-UP: Backlog itemien massamuuttaminen iteration goal -sivulle	7h
WARM-UP: Backlog itemin statusbariin oma rivinsä (ts. värillinen palkki) itse backlog itemille	21h
WARM-UP, BUG: Iteraatio-sivun burndown näkymään, vaikka ei olisikaan backlog itemejä	1h
WARM-UP: New task » -linkki Backlog -sivulle	5h
WARM-UP: Portfolio-sivun sarakkeiden järjestys	3h
WARM-UP: Load-taulukko: overload-luvut punaiseksi	5h
Tuntimäärä yhteensä	80h

2.1.2 Sprintin palautukset

Katso Warmup Sprint Demo.

2.1.3 Sprintin burndown

2.2 Sprint 2

Toisen sprintin aikana oli tarkoitus aloittaa toteuttamaan itse tuntikirjanpito-ominaisuuksia ohjelmaan.

Ensimmäinen ominaisuus oli toteuttaa asetusjärjestelmä, josta tuntikirjanpito-ominaisuus olisi asetettavissa päälle ja pois. Tämän jälkeen aloitettiin toteuttamaan ominaisuutta, jonka avulla käyttäjä pystyisi kirjaamaan tunteja Backlog itemeille. Lopuksi toteutettiin ominaisuus, joka näyttää Backlog itemeille kirjattujen tuntien summan.

Ryhmän oli alunperin myös tarkoitus käyttää Agilefanttia omaan tuntikirjanpitoon sprintin päätyttyä. Tähän oltaisiin pystytty mikäli oltaisiin haluttu. Päätettiin kumminkin viedä sprintti kokonaisuudessaan loppuun Google Docsin-tuntikirjanpitodokkarin avulla. Edellisten sprinttien tunnit siirrettiin Agilefantiin heti seuraavan sprintin maanantaina. Ryhmä olisi muutenkin pystynyt tämän tekemään vasta sprintin julkaisun jälkeen, joten katsottiin parhaaksi tehdä tämä mielummin heti seuraavan viikon maanantaina.

2.2.1 Sprintin tehtävät ja niihin käytetyt tunnit

Tehtävä	Tuntimäärä
S2-R03 SETTINGS: Asetusmallin luominen	1h 30min
S2-R08 Merkattujen tuntien talletus	15h
S2-R07 Speksaus + mallin luonti tuntikirjanpitodatalle	6h 15min
TIMEBOX: Raportoinnin suunnittelu	0h
TIMEBOX: Uudelleenkohdistamisen suunnittelu	0h
S2-R05 Tuntien kirjaus ja listaus BLI:lle (käyttöliittymäsuunnittelu)	5h
S2-R06 Tuntien kirjaus ja listaus BLI:lle BLI-sivulla (käyttöliittymien toteuttaminen)	19h
S2-R09 Summa BLi listaan tuntientryistä	16h
S2-R04 SETTINGS: uuden tabin tekeminen (UI)	11h 45min
S2-R01 SETTINGS: Asetusarvojen tallettaminen kantaan ja haku kannasta	9h
S2-R02 SETTINGS: Tuntikirjanpitoasetus settings-järjestelmään	12h 45min
S2-R10 Käyttöliittymän määrittely BLI-listauksiin uuden tuntientryn syöttämiseen BLI:lle	2h
TIMEBOX: Backlogeille kirjaamisen suunnittelu	0h
Release	2h 30min
Tuntimäärä yhteensä	100h 45min

2.2.2 Sprintin palautukset

Katso Sprint 2 Demo.

2.2.3 Sprintin burndown

2.3 Sprint 3

Kolmannen sprintin alussa siirrettiin kaikki tunnit Google Docsista Agilefanttiin. Kaikki ryhmän jäsenet alkoivat tämän jälkeen käyttämään Agilefanttia tuntikirjanpitoon. Tässä vaiheessa Agilefantissa oli tarpeeksi ominaisuuksia henkilökohtaisten tuntisummien saamiseen.

Tämä sprintti keskittyi eniten viime sprintin viimeistelyyn ja tuntikirjanpitoon liittyvien toimintojen lisäämiseen olemassa oleviin näkymiin.

Tässä sprintissä toteutettiin myös monia käyttöliittymäprotoja. Nämä löytyvät sivulta Protot.

2.3.1 Sprintin tehtävät ja niihin käytetyt tunnit

Tehtävä	Tuntimäärä
S3-R16: Valittavien käyttäjien sorttaus tuntien syötössä	9h
S3-R15: Tuntien kirjaus BLI-listoista	12h
S3-R17: Kirjattujen tuntien summa iteration goal näkymään	2h
S3-R18: Iteration goaleihin liittyvien tuntien summat näkyviin	3h 45min
S3-R03: PROTO: Projekti-näkymään suoraan kirjatut tunnit, lapsille kirjatut tunnit ja niiden summa	3h 30min
S3-R36: BUG: BLI poistamaan sille kirjatut tunnit BLI:n poiston yhteydessä	3h 30min
S3-R25: TIMEBOX: Tuntikirjauksen editoinnin parantelu	5h
S3-R27: Tuntikirjausten poiston ajaxifiointi	0h
S3-R35: BUG: BLI Save & Close välittömästi Hour entryn tekemisen jälkeen	5h
S3-R32: USABILITY: Käyttäjän kokonaistuntimäärän näyttäminen kirjauksen helpottamiseksi	9h 55min
S3-R29: Tuntikirjaukseen liittyvien tekstien viilausta	2h
S3-R37: BUG: Kellonajan minuutit näytetään tietyissä tapauksissa hassusti BLI-näkymässä	1h
S3-R04: PROTO: Käyttöliittymäproto Timesheets-näkymästä	4h
S3-R33: Ryhmän tunnit siiretty Google Docsista Fanttiin	1h 50min
Timesheets-tabin luonti + timesheets sivu(Pelkkä UI)	2h
Funktionaalisuus: Raportointi käyttäjien perusteella	2h
PROTO: Tekemislistaus raporttinäkymään	7h 45min
Jarnon 3.5. illalla spostilla antamat viilaukset.	1h 15min
BUG: editIteration- sivulla ei voi poistaa BLI:ta jolle on kirjattu tunteja.	1h 15min
BUG: BLI:n editointi mahdollistaa negatiiviset estimaatit	30min
Tuntimäärä yhteensä	77h 15min

2.3.2 Sprintin palautukset

Katso Sprint 3 Demo.

2.3.3 Sprintin burndown

2.4 Sprint 4

Neljännen sprintin aikana saatin valmiiksi raportointiominaisuus. Tässä sprintissä tehtiin myös kurssin vaatimat testi caset.

2.4.1 Sprintin tehtävät ja niihin käytetyt tunnit

Tehtävä	Tuntimäärä
S3-R14: BLI:den järjestäminen käytettyjen tuntien perusteella BL sivuille	4h 30min
TIMEBOX: Tuntikirjausjärjestelmään liittyvän koodin refaktorointi	5h 50min
S3-R20: HE toiminnallisuus Backlog tietoiseksi	8h 45min
S3-R05: UI: Tuntien syöttö, editointi ja listaus projektille	7h 30min
S3-R31: BL poistamaan sille kirjatut tunni BL:n poiston yhteydessä	4h 15min
BUG: Kursori ei vaihdu, kun vie hour reportingin sulkemisnapin päälle	10min
BUG: Epäkelvon job entryn syöttö BLI-listan ensimmäiselle BLI:lle "State"-sarakkeesta.	2h
Log effort -näkymä valittamaan jos käyttäjää ei ole valittu	1h 10min
Uusi datepicker job entry dialogiin	6h
change-linkki takaisin näkyviin BLI-listoihin	10min
Timesheets: Valitut BL:t hierarkisesti ilman tuntidataa	16h
Timesheets: Tuntidata hierarkiseen näkymään ilman user/date filtteröintiä	3h 15min
Timesheets: User/date filtteröinti	8h 38min
Timesheet UI	5h
Timesheets: Proto	7h 15min
Vesan Tomcat hajosi	3h 30min
REFACTOR: BLI Spent effort JSP sivuissa kysymään effort suoraan BLI modelilta	3h
Tuntikirjauksessa päivämäärn ja kellonajan tarkistus	2h
Tuntimäärä yhteensä	88h

2.4.2 Sprintin palautukset

Katso Sprint 4 Demo (Loppudemo).

2.4.3 Sprintin burndown

3. Tulosten arviointi

3.1 Tavoitteiden arviointi

Tavoite	Tarkistuskriteeri	Arviointi
1. Helppokäyttöisyys	On-off ominaisuus Ei lisää klutteria Ei turhaa sälää Voidaan käyttää ominaisuutta nykyisiltä sivuilta	Helppokäyttöisyyten ollaan annettu erityistä huomiota. Käyttöliittymäprototyyppejä on hiotty asiakkaan avustuksella. Kaikkia ominaisuuksia voi käyttää nykyisiltä sivuilta paitse tuntiraportointiominaisuutta, jonka toteuttaminen omalle sivulle koettiin järkeväksi.
2. Tuntien kirjaaminen	Tärkeimmät kohteet joihin tunteja pystyy kirjata ovat projektit ja backlog itemit Tunnit kirjataan käsin Tuntikirjauksen entry sisältää: Päivän Ajan Kommentin Tekemisen tyypin Erinlaisia lippuja Laskutettava tunti	Tuntien kirjaamisen toteutettiin perustoiminnallisuus, joka ei sisältänyt tekemisen tyyppejä ja erinlaisia lippuja kirjauksille. Nämä ominaisuudet skoupattiin pois asiakkaan toiveesta.
3. Tuntiraportointi	Mahdollista saada raportti: Projektista Backlog itemistä Iteraatiosta (monia muita)	Tuntiraportteja voi saada tuotteista, projekteista ja iteraatioista. Raportit sisältävät backlog itemeihin ja projekteihin kirjatut tunnit.
4. Tunteja pystyy siirtämään		Ominaisuutta ei toteutettu. Asiakas uudelleenpriorisoi tavoitteet ja tästä syystä ominaisuus skoupattiin pois.
5. Tarpeeksi hyvä raportointi	Raportti mahdollista saada tietylle ajanjaksolle Raportti mahdollista saada tietystä ryhmästä/tiimistä	Tuntiraportit pystyy saamaan tietystä ajanjaksosta, ryhmästä ja backlogista.

3.2 Sprint goalien arviointi

Jokaisen sprintin demotilaisuudessa arvioitiin sprintin tuloksia. Tämä tehtiin niin, että jokainen ryhmän jäsen ja asiakkaan edustaja sai äänestää jokaista sprintin goalia seuraavalla asteikolla:

Asteikko	Selite
	Thumbs up! Sprintin goali saavutettu.
	Peukalo vaakatasossa. Tietty osa sprintin goalista saavutettu, tiettyä osaa ei saavutettu. Äänestäjällä ei ole tarpeeksi tietoa äänestääkseen suuntaan tai toiseen.
	Thumbs down! Sprintin goalia ei saavutettu.

2.2.1 Sprint 1 (Warm-up Sprint)

Sprint Goal	Arvio	Arvioinnin kommentti
Warm-ups released		Kaikki toiminnallisuus tehtiin mutta release jäi tekemättä.
Quality		Uusia bugeja löytyi demossa.
Team Spirit		Liika hapuili ja tiedonpuute vaikutti hieman negatiivisesti mielialaan.

3.2.1 Sprint 2

Sprint Goal	Arvio	Arvioinnin58min kommentti
Asetusjärjestelmä on käytettävissä ja tuntikirjanpito asetettavissa päälle		Toiminnallisuus toteutettiin. Ainoa puute oli tyylitys.
Käyttäjä voi kätevästi kirjata tunteja Backlog Item -näkymästä		Perustoiminnallisuus toteutettiin.
Backlog item -listaukset näyttävät itemeille yhteensä kirjatut tunnit		Suurin osa toiminnallisuudesta toteutettiin pientä puutetta lukuunottamatta.
Spider -ryhmä pystyy käyttämään ja myös käyttää pe 30.5. julkaistavaa Agilefantia hoitamaan tallentamaan kurssin vaatimusten mukaiset tuntikirjaustiedot		Oltaisiin pystytty käyttämään mikäli tarve sitä olisi vaatinut.

3.2.1 Sprint 3

Sprint Goal	Arvio	Arvioinnin kommentti
Ryhmä käyttää Fanttia tuntikirjanpitoon		Kaikki tunnit siirrettiin Google Docsista fanttiin.
Sprint 2:n uudet toiminnallisuudet on viimeistelty		Toiminnallisuudet viimeisteltiin.
Käyttäjä voi kätevästi kirjata tunteja Backlog Itemejä listaavista näkymistä		Toiminnallisuus toteutettu. Laaja kirjausikkuna jätettiin pois pienen bugin takia.
Jo olemassa oleviin näkymiin on lisätty oleelliset reporting -asiat		Kaikki vaaditut asiat toteutettiin.
Timesheets -näkymän suunnittelu		Proto saatiin tehtyä. Seuraavalla viikolla viimeisteltiin.

3.2.1 Sprint 4

Sprint Goal	Arvio	Arvioinnin kommentti
Olemassaolevan toiminnallisuuden hiomista & viimeistelyä
Timesheets
Tuntien kirjaus projektille
Sekalaiset

3.3 Laadun arviointi

Laatu on arvioitu laaturaportissa.

3.4 Auki olevat bugit

Päivitetty lista avonaisista bugeista löytyy Agilefantista.

3.5 Projektin haastavuus

Suurimman haasteen projektin alussa tuotti valmis melko laajahko järjestelmä, joka sisälsi useita eri tekniikoita, joista kellään ryhmän jäsenistä ei ollut aikasempaa kokemusta. Tämän johdosta ryhmän jäsenillä kului paljon aikaa kyseisten tekniikoiden opetteluun, joka verotti osaltaan projektissa saavutettuja tuloksia.

Projektin loppupuolella asiakas ei ollut enään kokoajan tavoitettavissa, joka tuotti haasteita vaatimusten hankinnassa ja toteutettujen ominaisuuksien hyväksynnässä.

4. Metriikat

4.1 Käytetyt tunnit

Tarkempaa statistiikkaa käytetyistä työtunneista löytyy Google Docsista ja Fantista.

	PP	PP	I1	I1	I2	I2
Henkilö	Pre-Project	Warm-up Sprint 1	Sprint 2	Sprint 3	Sprint 4	Stabilization	SEPA	Yhteensä
Nico Hiort af Ornäs	10	38	34	28	22	17		149
Vesa Pirilä	13	37	14	21	32	27	x	144
Pasi Pekkanen	12	33	41	45	22	15		168
Roni Tammisalo	3	30	35	35	26	18		147
Kari Niiranen	5	29	35	25	28	22		144
Ville Rantamaula	4	41	45	28	25	13		156
Yhteensä	47	208	204	182	155	112	-	908

4.1.1 Vertailu koodaukseen ja muuhun työhön liittyvistä työtunneista

Koodaus sisältää kaikki ne tunnit, jotka on merkitty taskien/backlog itemien alle. Näin olleen koodaus ei esimerkiksi sisällä ET mindmappien toteutusta. Muu työ sisältää kaikkiin muihin merkatut tunnit.

4.2 Laatumetriikat

Laatumetriikat löytyvät laaturaportista.

5. Menetelmät ja työkalut

5.1 Käytetyt menetelmät ja työkalut

Laadun näkökulmasta menetelmiä ja työkaluja on arvioitu laaturaportista löytyvässä taulukossa.

5.1.1 Iteratiivinen ohjelmistokehitys

5.1.1.1 Kurssin prosessi

Kurssiin liittyvät mentordemot toimivat muuten hyvin, paitsi toisen vaiheen mentordemo, johon asiakas ei päässyt mukaan. Asiakkaan palaute laaturaportista olisi ollut arvokas.

5.1.1.2 Intensiivinen aikataulu

Projektin intensiivinen aikataulu (noin 6,5 tuntia / päivä) teki kurssista hieman haastavamman mitä ohjelmistoprojektikurssi tavallisesti on.

Jokainen ryhmän jäsen kuluttaa tunteja joka päivä saman verran. Tästä syystä on pakko suunnitella sprintit niin, että jokaiselle löytyy jotain tekemistä joka päivä. Se, että kaikille oli jotain tekemistä varmistettiin päivittäisten Scrum-kokouksien ja Sprint planning-kokousten avulla. Tätä varten oltaisiin voitu myös suunnitella Gantt-kaavioita, joista näkyisi sprintin ja projektin "critical path". Tälläisen tekemiseen ei kumminkaan nähty tarvetta. Loppupeleissä kaikille löytyi jotain tekemistä joka päivä.

Aikataulun intensiivisyys toi myös hieman haasteita. Tavallisessa ohjelmistokehitysprojektissa asioita pystyi pyörittelemään päässä pari päivää. Meidän tapauksessa tiettyihin ongelmiin piti löytää ratkaisut paljon pienemmällä aikavälillä.

Hukkaan menneitä tunteja kertyi verraten vähän ottaen huomioon kurssin intensiivisen aikataulun ja asiakkaan kiireet.

5.1.1.3 Kehitys yhteisessä tilassa

Yhteinen kehitystila todettiin erittäin toimivaksi. Yhteinen tila edesauttoi kommunikaatiota. Suurten monitorien aiheuttamat näkyvyyshaitat koettiin negatiivisiksi.

5.1.1.4 Scrum

Sprint-planning toimi erinomaisesti. Päivittäiset scrum-tapaamiset koettiin ehkä hieman turhiksi, koska kehitystä tehtiin muutenkin kokoajan yhdessä.

Agilefant oli erittäin hyödyllinen iteraation tilan seurannassa ja tehtävien jakamisessa.

5.1.1.5 Vaatimustenhankinnan jaksotus

Asiakkaan kiireistä johtuen suunnitellusta vaatimustenhankinnan jaksotuksesta jouduttiin joustamaan. Sprintissä toteutettavat ominaisuudet saatiin kuitenkin hankittua asiakkaalta sprint planningiin mennessä. Tämä kuitenkin hankaloitti seuraavan sprintin ennakkosuunnittelua melko paljon.

5.1.1.6 Laatukäytäntöjen jaksotus

Prosessin hioutuessa laatukäytännöt alkoivat toimimaan paremmin. Sprint 2 aikataulutus petti melko pahasti ja tästä syystä aiottuun jaksotukseen ei päästy, mutta sprinteissä 3 ja 4 tutkiva testaus saatiin hyvään vauhtiin jo ennen feature freezeä. Sprint 2 jälkeen oli myös ylivoimaisesti eniten tuntemattomia ongelmia, jotka vähenivät laatukäytäntöjen hioutuessa kohdilleen. Sprint 2 lopputulos saattoi kärsiä laatupäällikön poissaolosta.

5.1.2 Iteraatiosuunnittelu

Sprint goalien esittelyä ei koettu kovin hyödylliseksi sprint planningissä. Sprintin työmäärän pilkkominen ja sprintin valmistelu jäi kohtalaisen ohueksi ennen sprintin alkua ja tämä hankaloitti tehtävien esittelyä ryhmälle jonkin verran. Tehtävien pilkkominen backlog itemeiksi perustui pitkälti ScrumMasterin mielipiteeseen.

Planning poker todettiin hyödylliseksi käytännöksi sprint planningissä ja sitä jatkettiin läpi projektin.

5.1.3 Dokumentointi

Dokumentointityökaluna käytettiin asiakkaan tarjoamaa wikiä, Atlassian Confluence. Osaan dokumenteista pystyimme käyttämään edellisten fanttiryhmien dokumentteja pohjana. Tämä auttoi hyvin paljon ja teki dokumentoinnista helpompaa.

Dokumentit, jotka koostuivat taulukoista toteutettiin Google Docsin Spreadsheettien avulla. Näitä olivat esimerkiksi tuntikirjanpito ja Test Cases.

Vähemmän epäviralliseen dokumentointiin käytettiin Post-It -viestilappuja. Näitä kiinnitettiin työhuoneen seinille ja ikkunoille. Post-It -viestilappuja käytettiin pääasiallisesti bugienhallintaan ja järjestelmän hahmottamiseen. Post-It -viestilaput olivat erittäin tehokkaita, koska kuka tahansa pystyi nopeasti lisäämään uusia lappuja ja katsoa vanhoja.

Ryhmän työhuoneesta löytyi myös yksi fläppitaulu ja whiteboard. Näitä käytettiin hyvin usein tietyn toiminnon hahmottamiseen ja suunnittelemiseen. Teknisesti haastavia algoritmeja suunniteltiin myös pienellä ryhmällä fläppitaulua käyttäen. 

5.1.4 Riskienhallinta

Riskienhallinta aloitettiin ensiksi niin, että projektipäällikkö teki listan mahdollisista riskeistä. Tämän jälkeen projektipäällikkö, Scrum master ja laatupäällikkö kävi tämän listan läpi yhdessä. Tässä läpikäynnissä käytiin läpi riskin sisältö, todennäköisyys, kriittisyys ja ohjaavat toimenpiteet. Kuka tahansa sai myös ehdottaa uutta riskiä ja tai ehdottaa riskin poistoa listalta.

Sen jälkeen kuin ensimmäinen versio riskinhallinnasta oltiin saatu valmiiksi annettiin asiakkalle mahdollisuus antaa riskienhallinnasta mielipiteensä. Tällöin asiakas päätti uudelleenpriorisoida yhtä riskiä.

Tämän jälkeen riskienhallintadokumenttia päivitettiin vain satunnaisesti silloin kuin siihen oli tarvetta. Olemme reagoineet esiintyneisiin ongelmiin mahdollisimman nopeasti ja yrittäneet keksiä niihin tehokkaat ratkaisut yhdessä ryhmänä.

Riskienhallinta oli hyvä asia opetusmielessä mutta itse projektin kulkuun se ei kovinkaan paljon vaikuttanut. 

5.1.5 Tuntikirjanpito

Projektin alussa käytettiin tuntikirjanpitoon Google Docsia. Toisen sprintin jälkeen alettiin käyttämään Agilefantin tuntikirjanpito-ominaisuutta.

Tuntien kirjaamisesta tuli paljon helpompaa, kun käytössä oli Agilefant. Agilefant oli jo muutenkin Backlogin hallintatyökaluna käytössä, joten oli loogista käyttää sitä myös tuntikirjanpitoon.

Tuntiraporttien saaminen oli aluksi Agilefantin avulla hieman vaikeata, koska tuntiraportointi-ominaisuus valmistui vasta projektin loppupuolella. Tarvittavat tuntisummat saatiin kumminkin järjestelmästä ulos, mutta tämä vaati hieman lisätyötä. Kaikkien ryhmien jäsenten piti itse käydä hakemassa sprintin tuntisumma ja raportoida tämä projektipäällikölle.

Tämän raportin sprinttien tehtävät ja niihin käytetyt tunnit on otettu suoraan Agilfantista. 

5.1.6 Kommunikaatio

Asiakaskommunikaatio
Kommunikaatio asiakkaan kanssa sujui projektin alussa hyvin. Projektin loppupuolella asiakas ei kumminkaan ollut aina tavoitettavissa, joka lisäsi projektin haasteita. Suurin osa kommunikoinnista asiakkaan kanssa hänen poissaollessaan hoitui puhelimitse ja sähköpostitse. Käyttöliittymäprotoja käytettiin uusien suunniteltujen ominaisuuksien demoamiseen.

Ryhmän sisäinen kommunikaatio
Työajan ulkopuolella IRC oli hyödyllinen kommunikaatioväline, mutta pääosa kommunikaatiosta tapahtui ryhmän yhteisessä työtilassa, joka koettiin erittäin luontevaksi vuorovaikutusmetodiksi.

5.1.7 Iteraatiodemot

Ryhmä sai palautetta tuotoksistaan ja kehitysideoita asiakkaan puolelta, joka oli ryhmän kannalta hyödyllistä. Demojen avulla saatiin myös välitettyä projektin edistyminen tehokkaasti suuremman joukon tietoon.

5.1.8 Bugiseuranta

Bugiseinä toimi hyvänä työkaluna tilannekuvan välittämiseen koko ryhmälle. Uudet ongelmaat saatiin myös tehokkaasti ryhmän tietouteen. Miinuksena menettelyssä oli asiakasinteraktion puute, varsinkin ajanjaksolla, jolloin asiakas ei ollut paikalla.

5.1.9 Versionhallinta

SVN toimi mallikkaasti.

5.1.9.1 Freeze Point

Ks. laatukäytäntöjen jaksotus.

5.1.10 Koodauskäytännöt

Koodauskäytäntöjen tarkkaa noudattamista ei katsottu toimivaksi käytännöksi.

5.1.11 Prosessin kehittäminen (Reflection Workshops)

Reflection workshopeilla pystyttiin arvioimaan käytettyjä menetelmiä, kokeilemaan uusia menetelmiä, parantamaan käytettyjä proseduureja ja poistamaan .

5.1.12 Vaatimustenhallinta

Agilefant ja Scrum auttoivat vaatimustenhallinnassa.

5.1.13 Käyttöliittymäprototyypit

Käyttöliittymäprototyypit toimivat erittäin tehokkaana ratkaisuna vaatimustenmäärittelyyn.

Suurin osa suunnitelluista käyttöliittymäprototyypeistä tehtiin ns. HTML-protoina. Tällöin halutusta käyttöliittymästä koodattiin staattinen HTML-versio. Mikäli asiakas hyväksyi prototyypin, pystyivät kehittäjät helposti käyttämään prototyypin koodia itse ohjelman koodaamiseen.

Eräs ongelma staattisten HTML-versioitten kanssa oli se, että ohjelman generoima HTML-koodi oli erittäin huonosti jäsennelty. Ohjelman generoimat HTML-sivut olivat yleensä pituudeltaan noin 10000 riviä, vaikka saman olisi saannut helposti mahtumaan 1000 riviin. Tähän ongelmaan auttoivat editorit, jotka pystyivät jäsentämään koodia uudelleen.

Käyttöliittymäprototyyppien suunnitelu onnistui siltä osalta hyvin, että yhtäkään prototyyppiä ei pitänyt hylätä sen takia, että oltiin väärinymmärretty asiakkaan vaatimukset. Timesheets-prototyyppiä täytyi tosin iteroida 8 kertaa, se oli erittäin iso käyttöliittymäprototyyppi.

5.1.13 Tilanneraportit

Mentorille ja ajoittain myös asiakkaalle lähetettiin sähköpostitse tilanneraportteja. Nämä sisälsivät päivityksiä ryhmän aikaansannoksista.

Kaikki lähetetyt tilanneraportit löytyvät sivulta Tilanneraportit.

Tilanneraporttien tarkotuksena oli pitää ryhmän mentori ajantasalla tapahtuneista asioista. Raportit eivät niinkään auttaneet itse ryhmää työnteoassa, mutta auttoi enemmänkin mentoria arvioimaan projektin menestystä.

6. Oppiarvo

Koko ryhmä sai arvokasta kokemusta tiimityöskentelystä yhteisessä työtilassa.

6.1 Henkilökohtainen oppiarvo

Henkilö	Henkilökohtaiset kiinnostuksen aiheet / tavoitteet	Saavutuksien arviointi
Nico Hiort af Ornäs	Oppia soveltamaan ketteriä menetelmiä Tiimityöskentely oikean projektin parissa Exploratiivinen testaus Käyttöliittymien suunnittelu ja toteutus Ajax	Pääsin ainakin kerran kokeilemaan kaikkia henkilökohtaisia kiinnostuksen aiheitani projektin aikana. Oli erittäin opettavaista päästä kokeilemaan käytettyjä prosesseja oikeassa työympäristössä. Agilefant ohjelmaan tutustuminen oli myös erittäin arvokas kokemus.
Vesa Pirilä	Scrum, projektinohjaus, testaus, laaduntakaamismenetelmät, arkkitehtuuri	Suurimmat opit tulivat Scrumin panemisessa käytäntöön, kokonaisuuksien pilkkomisessa toteuttamiskelpoisiin osiin ja työmäärän arvioimisessa. Kurssi oli opettavainen kokonaisuus ja se on olennainen DI:n valmistamisessa työelämään. Se antaa valmiudet kyseenalaistaa ja kehittää työnantajan käytäntöjä, mikä on erittäin tärkeää työelämässä.
Pasi Pekkanen	Käytettävyyssuunnittelu ja -testaus, arkkitehtuurisuunnittelu, automaattinen integraatiotestaus, scrum, AJAX	Scrum, käytäntöjen jatkuva arviointi ja kehittäminen, vaatimusten hankinta ja jakaminen tehtäviksi. Ryhmän toiminnan arviointi ja kehittäminen. Lukuisia ohjelmointitekniikoita, kuten J2EE, Sprint, Xwork ja Hibernate. Työskentely todellisena ketteränä tiiminä.
Roni Tammisalo	Scrum, J2EE, Spring, Hibernate	Scrum tuli hyvin kurssin aikana tutuksi. Tutuistuin myös J2EE:n, Springiin ja Hibernateen, joista eniten keskityin opiskelemaan Hibernatea. Sain myös parempaa tuntumaa testaamisesta.
Kari Niiranen	Scrum, J2EE, testaus, Spring, Hibernate	Kurssin aikana sai hyvin tuntuman scrumiin. Lisäksi tutustuin J2EE:n, Springiin ja Hibernateen. Sain myös paremman ymmärryksen testausmenetelmien toimimisesta toistensa tukena.
Ville Rantamaula	Saada tuntumaa ketterien menetelmien käytöstä, testauksen soveltamista KM:iin sekä vaatimusten keräämisestä ja hallinnasta.	Tuntumaa tuli scrumiin sekä testauksesta. Vaatimusten kerääminen ja hallinta jäi olemattomaksi osaltani.

7. Kurssin palaute

Nimi	Hyvää kurssissa	Huonoa kurssissa	Parannusehdotukset
Nico Hiort af Ornäs	Hyvä ja rento asiakas, joka ymmärsi softakehityksen tarpeet. Saatin paljon apua asiakkaalta sekä itse ohjelmistoon että kurssiin liittyvissä asioissa. Hyvä, että asiakas pystyi tarjoamaan tilat sekä laitteistot kurssin suorittamiseen. Oli erittäin opettavaista päästä kokeilemaan käytettyjä prosesseja oikeassa työympäristössä. Hyvä, että dokumentoinnin määrää pystyttiin karsimaan. Kokonaisuutena kiinnostava projekti ja kurssi.	Kurssin kotisivuilla voisi kurssin ohjeistus olla hieman selvempää. Ajoittain oli vähän hankalaa löytää tietoa sivuilta.	Toivottavasti kurssi tullaan järjestämään tulevaisuudessa myös intensiivisenä.
Vesa Pirilä	Antaa kokonaisnäkemystä ohjelmistoprojekteista. Päästää opiskelijat tehtäviin, joihin he eivät vielä oikeassa yrityksessä pääsisi, mutta ei kuitenkaan jätä heitä täysin omilleen vaan tarjoaa mentorin tuen. Intensiivinen kurssi tarjosi hyvin haasteita ja mahdollisti kurssin suorittamisen siten, ettei se häirinnyt muuta opiskelua. Suosittelen ehdottomasti intensiivikurssin tarjoamista myöhemminkin.	Ainakin intensiivikurssilla dokumenttien kirjoitukseen ja muuhun kurssityöhön käytettiin lähes puolet kurssin tuntimäärästä. Vaikka osa dokumentaatiosta auttaa oppimista ja antaa kuvaa projektin kulusta mentorille ja asiakkaalle, vieläkin suurempi osa olisi voitu hoitaa suullisesti. Oma mentorimme jousti tässä kiitettävästi, mutta varsinkin jäykemmän mentorin tapauksessa dokumentaation määrä on valtava. Myös erilaisten jäykkien menetelmien kokeilussa agiilin prosessin päällä on valtavasti overheadia ja saavutettavat edut ovat rajalliset.	Trimmataan dokumentaatiovaatimuksia vielä hieman ja jätetään jotkut menetelmät kokeilematta, jos niitä ei oikeasti prosessin mukaan tarvittaisi.
Pasi Pekkanen	Mahdollisuus toimia intensiivisesti samassa huoneessa todellisena kehitystiiminä ja olla tuhlaamatta aikaa jonninjoutaviin asioihin. Joustava asiakas, joka antoi tiimin toimiaa rauhassa, mutta oli useimmiten tavoitettavissa ja vastaamassa kysymyksiin.	Kohtalaisen paljon dokumentaatiota, joka ei hyödytä asiakasta lainakaan, mutta kulutti silti merkittävästi tiimin resursseja.	Otetaan asiakkaan näkökulma ekstensiivisen dokumentaation, kuten projektisuunnitelma, tuottamisessa enemmän huomioon ja mietitään mitä lisäarvoa dokumentti tuo asiakkaalle. Yritetään välttyä dokumentaatiota dokumentaation takia -tilanteelta.
Roni Tammisalo	Kiinnostunut asiakas. Yhteinen työtila ja tiimityöskentely.	Alku hidas ja vaivalloinen fantin opiskelun takia. Asiakkaan katoaminen.	Ei kommenttia.
Kari Niiranen	Yhteisessä työtilassa työskentely yhtenä tiiminä tuki kommunikaatiota vähentäen samalla sekaannuksia työnjaon suhteen.	Alussa järjestelmän hahmottaminen vaati aikaa, jotta pystyi tekemään jotakin.	Jo olemassa olevaa ohjelmaa jatkokehitettäessä olisi hyvä, jos joku perehdyttäisi ryhmän kunnolla nykyiseen järjestelmän toimintaan.
Ville Rantamaula	Nopea liikkeellesaattaminen. Yhteinen työtila edesauttoi oleellisesti ryhmän kommunikointia. Intensiivinen toteutus sopii hyvin tälle kurssille.	(R|S)ekoilu projektin alussa - fanttin kokonaiskuvan hahmottaminen tuntui turhauttavalta.	Kurssilla valmista projektia (kuten Fantti) käytettäessä, kannattaisi ryhmä perehdyttää valmiina annettuun työstettävään projektiin paremmin.