Projektin loppuraportti. Dokumentti: loppuraportti.doc Päiväys: Projekti : AgileElephant

Transkriptio

1 AgilElephant Loppuraportti Tekijä: Juha Kaarlas Omistaja: ElectricSeven Aihe: AgilElephant-loppuraportti Sivu 1 of 20

2 Muutoshistoria Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision tekijä Aloitettu Juha Kaarlas Lisää sisältöä Juha Kaarlas Sisältöä jäsennelty paremmin Juha Kaarlas Poistettu roinaa Juha Kaarlas Lisätty tarinaa koodikatselmoinnista Juha Kaarlas Hyväksyjät Tämä dokumentti vaatii seuraavien henkilöiden hyväksymiset Nimi ElectricSeven Tehtävä Kommentointi Katselmoinnit Tämä dokumentti vaatii seuraavien henkilöiden katselmoinnin Nimi Tehtävä Jakelu Tämä dokumentti jaetaan seuraaville henkilöille Nimi Projektiryhmä Kurssi Tehtävä Tiedoksi Arviointi Aihe: AgilElephant-loppuraportti Sivu 2 of 20

3 Sisällysluettelo 1. Johdanto Viittaukset Projektin kulku Projektin suunnittelu ( ) Implementaatio 1 ( ) Implementaatio 2 ( ) Viimeistely ja toimitus ( ) Tulokset Projektin tavoitteiden saavuttaminen Tavoite 1: Hyvä pohja SEMS-työkalulle Tavoite 2: Cycles of Control-idean toteutuminen Tavoite 3: Laadunvarmistuksen näkökulma Tavoite 4: Edistymisen seuranta Tavoite 5: Helposti jatkokehitettävä* Tavoite 6: Stabiilius Tavoite 7: Riittävä suorituskyky* Tavoite 8: Helposti laajennettava Tavoite 9: Raporttien luonti Tavoite 10: Käytettävyys* Mielipide laadusta Projekti numeroina Ohjelmiston koko Laajuuden analyysi Laatumetriikat Käytetyt resurssit Aika Infrastruktuuri Käytännöt ja työkalut Iteratiivinen prosessi Staattiset metodit Automaattiset yksikkötestit Automaattiset buildit Eri seurantamediat Virheiden seuranta Heuristinen arviointi...17 Aihe: AgilElephant-loppuraportti Sivu 3 of 20

4 5.1.8 Koodin katselmointi Oppiminen Kurssipalaute Tulevaa työtä Parannusehdotuksia Avoimet bugit...20 Aihe: AgilElephant-loppuraportti Sivu 4 of 20

5 1. Johdanto AgilElephant-projektin tarkoituksena oli kehittää iteratiiviseen ohjelmistokehitykseen sopiva, erityisesti SEMS-mallin 1 mukainen projektinhallintatyökalu noin 10 hengen tiimeille. Vaikka SEMS-prosessimalli olikin hyvin määritelty oli projekti silti osin prototyyppikehitystä, koska vastaavaa järjestelmää (erityisesti pitempien aikavälien hallinta) ei varsinaisesti ollut olemassa. Tästä johtuen aiheen vaatimien käsitteiden hahmottaminen oli haastavaa. Suhteellisen moni käsite selkiytyi projektin edetessä ja viimeistään siinä vaiheessa kun asia oli saatu esitettyä käyttöliittymässä tai sen prototyypissä. Lopputuloksena on melko hyvä alku SEMS-mallin mukaisen ohjelmistokehityksen hallintaan. Uskostamme järjestelmään kertoo se, että käytimme sitä itse projektin viimeisessä vaiheessa ja kokemukset olivat mieluisia. 1.1 Viittaukset [1] SEMS: Aihe: AgilElephant-loppuraportti Sivu 5 of 20

6 2. Projektin kulku Ajallisesti projekti koostui neljästä iteraatiosta: Projektin suunnittelu (PP), Implementaatio 1 (I1), Implementaatio 2 (I2), Viimeistely ja toimitus (FD). Jokaisen iteraation kulku on tiivistetty omiin kappaleisiinsa. 2.1 Projektin suunnittelu ( ) Ensimmäisen iteraation tavoitteina olivat projektin määrittely ja organisointi alustavan projektisuunnitelman kirjoittaminen alustavat vaatimusmäärittelyt ja tärkeimmät käyttötapaukset SEPA-aiheiden valinta teknologia-alustan valinta teknologiademo Vaikka alussa olikin haparointia saimme tavoitteet täytetyksi ja projektin käyntiin. Asiakkaalta saatu palaute PP-iteraation suhteen sisälsi tärkeän kommentin yhteydenpidon tärkeydestä. Opittiin myös tehtävien määrittämisen tärkeydestä; ensimmäinen tehtäväsuunnitelma oli laadittu melko korkealla tasolla. Tehtävien seuranta muodostui hivenen ongelmalliseksi. Tämä ratkaistiin muuttamalla käytäntöjä seuraavaan iteraatioon. Projektin tuntibudjetista (1330h) tässä iteraatiossa kului noin 26%. 2.2 Implementaatio 1 ( ) Toisen iteraation tavoitteina olivat ns. Cycles of Control-viitekehyksen suunnittelu ja implementointi HTML-prototyyppi arkkitehtuurin suunnittelu ja dokumentointi testauksen suunnittelu Iteraation suurin ongelma ja tärkein opetus oli työtuntien ja tehtävien kasautuminen loppupäähän noin deadlinea edeltävälle viikolle. Tästä johtuen jäimme hieman tuntitavoitteestamme. Demoa silmällä pitäen tilanne ehti näyttää melko huolestuttavaltakin, mutta lopulta saimme pidettyä loistavan demon ja asiakas vaikutti erittäin tyytyväiseltä. Projektin tuntibudjetista tässä iteraatiossa kului noin 20%. 2.3 Implementaatio 2 ( ) Viimeisen varsinaisen toteutus-iteraation tavoitteina olivat erinäiset järjestelmän ominaisuudet kuten ajankäyttöön liittyvä toiminnallisuus burndown-kuvaaja tehtävälistojen laadinta ja muokkaus Aihe: AgilElephant-loppuraportti Sivu 6 of 20

7 editoitavien näkymien ja filtterien toteuttaminen käyttäjien, tehtävien, projektien yms. poistamisen suunnittelu ja speksaus Iteraation tuntisuunnittelu onnistui melko hyvin ja saimme paljon asioita tehdyksi ja testatuksi. I2:n osuus tuntibudjetista oli noin 32%. 2.4 Viimeistely ja toimitus ( ) Viimeisen iteraation tavoitteena oli järjestelmän stabilointi ja toimitus sisältäen paljon bugikorjauksia ja dokumentointia. Lisäksi asiakas esitti yllättävän suuren määrän muutospyyntöjä joiden täyttämisessä onnistuimme kohtuullisen hyvin. Iteraation suunnittelu oli varmastikin koko projektin helpoin, sillä tehtävät oli helppo pilkkoa tarpeeksi pieniksi kokonaisuuksiksi ja työlistalla oli valmiiksi paljon selviä tehtäviä. Esim. Bugzillan bugien muuttaminen korjaustehtäviksi oli hyvin suoraviivaista. Samalla projektin seuranta helpottui osin, koska käytimme omaa järjestelmäämme. Iteraatioon käytetyt tunnit olivat noin 22%:a koko tuntibudjetista. Tätä raporttia kirjoitettaessa näyttää siltä, että alkuperäinen 1330 tunnin budjetti alittuu hieman. Arvioitu lopullinen tuntimäärä on noin 1260 h. Aihe: AgilElephant-loppuraportti Sivu 7 of 20

8 3. Tulokset Kaikenkaikkiaan projektia voidaan luonnehtia erittäin onnistuneeksi. Projekti onnistuttiin toteuttamaan hämmästyttävän suoraviivaisesti ja siksi myös tehokkaasti. Kerran toteutettuihin ominaisuuksiin koskettiin vain hyvin vähän. Asiakas ei muuttanut vaatimuksia juuri lainkaan ja salli toimintojen toteuttamsien järkevässä järjestyksessä. Projektissa ei jouduttu kertaakaan iteroimaan pahasti ja vain hyvin vähän työtä meni hukkaan. Tämän takia monet aitojen kaupallisten projektien ongelmat jäivät meiltä kokematta. Kun huomioidaan, että projekti toimi hajautetussa ympäristössä (niin ajallisesti kuin maantieteellisesti) ja kaikki projektiin osallistuvat henkilöt olivat osa-aikaisia niin onnistumisen edellytykset olivat enimmäkseen oma-aloitteisissa ja osaavissa tekijöissä. 3.1 Projektin tavoitteiden saavuttaminen Taulukossa 1 on listattu projektin alkuperäiset tavoitteet ja niiden statukset. Tavoiteanalyysiä lukiessa kannattaa kiinnittää huomiota tähdellä merkittyihin tavoitteisiin. Tavoitteita ei varsinaisesti muutettu projektin aikana vaan prioriteetit muuttuivat hieman. Erityisesti tavoitetta 10 (käytettävyys) korostettiin projektin loppuvaiheessa sikäli kun se liittyi tavoitteisiin 1 ja 2. Tavoite Verifiointikriteeri Saavutettu 1. Hyvä pohja SEMS-mallin mukaiselle projektinhallintatyökalulle. 2. Tehtävälistat Cycles of Control-viitekehyksen mukaisesti 3. Laadunvarmistuksen näkökulman esittäminen 4. Edistymisen seuranta 5. Helposti jatkokehitettävä, laadukas 6. Stabiilius 7. Riittävä suorituskyky 8. Helposti laajennettava 9. Raporttien luonti 10. Käytettävyys Taulukko 1: Tavoitteiden saavuttaminen Asiakkaan priorisoimat vaatimukset on toteutettu. Järjestelmä sisältää tehtävälistat eri aikajänteille. Järjestelmä sisältää laatutehtäviin liittyviä ominaisuuksia, esim. laadun tarkistuslistat ohjelmointitehtäville. Järjestelmä tarjoaa menetelmän arvioida ja päivittää tehtävien edistämistä ja seurata ajankäyttöä esim. burndown -graafilla. Järjestelmän arkkitehtuuri ja dokumentaatio tukevat jatkokehitystä. Järjestelmä ei saa hukata tai korruptoida tietoa eikä kaatua hyväksymistestauksessa. Suorituskyvyn on oltava riittävä noin 10 käyttäjän ryhmälle, eli muutamalle yhtäaikaiselle käyttäjälle. Arkkitehtuurin on tuettava laajennettavuutta; jatkokehitykselle tarjotaan ulkoiset rajapinnat. Järjestelmä sisältää tarpeeksi tietoa erilaisten raporttien generointiin (esim. käytetyt tunnit). Käyttöliittymän kehityksessä on käytetty heuristista arviointia. Eri käyttäjille näytetään kerralla vain olennaisimmat asiat. Asiakkaan hyväksyntä. Kyllä Kyllä Ei Kyllä Kyllä* Kyllä Kyllä* Kyllä Kyllä Kyllä* Aihe: AgilElephant-loppuraportti Sivu 8 of 20

9 3.1.1 Tavoite 1: Hyvä pohja SEMS-työkalulle Koko projektin idea oli toteuttaa hyvä pohja SEMS-malliin sopivalle projektinhallintatyökalulle. Tavoitteen toteutuminen näkyy toteutetuista ominaisuuksista sekä järjestelmän tietomallista. Suunnittelussa otettiin huomioon monta käsitettä ja ominaisuutta, jotka eivät näy käyttöliittymässä. Tästä johtuen esim. tietokantamallissa on tauluja, jotka eivät ole käytössä. Em. seikat yhdessä johtivat projektin tärkeimmän tavoitteen toteutumiseen Tavoite 2: Cycles of Control-idean toteutuminen Tavoite saavutettiin, koska järjestelmä sisältää backlogin tuote-, release- ja iteraatiotasolla. Tehtäviä voi siirrellä eri backlogien välillä Tavoite 3: Laadunvarmistuksen näkökulma Tavoite ei toteutunut. Järjestelmään ideoitiin erilaisia laatutehtäviin liittyviä ominaisuuksia, mutta niiden toteuttamiseen ei jäänyt aikaa. Loppuvaiheessa myös asiakas priorisoi muita ominaisuuksia tämän edelle Tavoite 4: Edistymisen seuranta Tavoite saavutettiin, koska järjestelmä mahdollistaa tehtäväkohtaisen tuntien kirjaamisen ja seurannan sekä työmäärän tarkastelun korkeammalla tasolla (esim. burndown-kuvaaja, työmäärien summat henkilöittäin) Tavoite 5: Helposti jatkokehitettävä* Mielestämme arkkitehtuuri ja dokumentaatio tukee jatkokehitystä, jonka aloittamisen pitäisi olla helppoa. Tätä on kuitenkin erittäin vaikea arvioida itse. Olemme pyrkineet noudattamaan asiakkaan toiveita kaikessa jatkoon liittyvässä dokumentaatiossa ja pyrkineet sisällyttämään siihen mielestämme olennaisen informaation Tavoite 6: Stabiilius Yleisesti ottaen järjestelmä on erittäin stabiili ja asiakaskin totesi sen robustiksi. Ainoa tavoitteen täyttymiseen vaikuttava asia oli asiakkaan hyväksymistestauksessa kohtaama tapahtumien katoaminen release-backlogista. Virhettä ei saatu toistumaan ja se johtui todennäköisesti siitä, että käyttäjä poisti itsensä järjestelmästä ja loi sen jälkeen tehtäviä. Tutkimuksen perusteella kyseessä oli näkyvyysongelma eikä datan korruptoituminen tai katoaminen tietokannasta. Asia korjattiin potkaisemalla poistettu käyttäjä välittömästi pois järjestelmästä Tavoite 7: Riittävä suorituskyky* Järjestelmä ei missään vaiheessa tuntunut hitaalta ja se tukee todennäköisesti muutamaa yhtäaikaista käyttäjää erittäin hyvin. Käytettävissämme ei missään vaiheessa ollut yhtäaikaisesti kymmentä testaajaa, joten soveltuvuus sen kokoiselle tiimille on mutua. Omassa ryhmässämme meitä oli seitsemän, emmekä havainneet päivittäisessä käytössä ongelmia, jotka liittyisivät käyttäjien määrään. Aihe: AgilElephant-loppuraportti Sivu 9 of 20

10 3.1.8 Tavoite 8: Helposti laajennettava Jatkokehitys ja laajennettavuus on huomioitu järjestelmän suunnittelussa. Jatkokehitystä varten on kirjoitettu omat dokumentit, joissa mm. kerrotaan miten uutta koodia lisätään. Järjestelmän koko logiikka on käytettävissä ulospäin näkyvästä RMI-rajapinnasta Tavoite 9: Raporttien luonti Järjestelmässä on tällä hetkellä katseltavissa kaksi raporttityyppiä: burndown-kuvaaja, sekä raportti tunneista valitulta aikaväliltä Tavoite 10: Käytettävyys* Tavoite voidaan katsoa saavutetuksi yleisellä tasolla. Käytettävyyssuunnittelu otettiin enimmäkseen huomioon logiikkaa suunnitellessa. Itse käyttöliittymälle suoritettiin heuristinen arviointi ja sen perusteella käytettävyydessä on vielä parantamisen varaan. Asiakas korosti tätä tavoitetta FD-vaiheessa, jolloin siihen reagoiminen oli hieman hankalaa. Saimme kuitenkin toteutettua suurimman osan ehdotetuista käytettävyysparannuksista. 3.2 Mielipide laadusta Laatu on hyvä. Löydetyistä virheistä valtaosa oli hakemalla haettuja virheitä (syötetään tietoisesti virheellisiä arvoja) sekä toteuttamattomia ominaisuuksia. Yksityiskohtaisempi erittely virheistä on esitetty kappaleessa 4.2. Oikeasti vakavia virheitä ei juuri löytynyt eikä mikään osio päässyt räjähtämään käsiin, kiitos rajapinnoitetun arkkitehtuurin. Javadocit ovat suhteellisen kattavat, mutta ne olisivat voineet vielä olla hieman tarkemmalla tasolla kuvatut. Lisää yksikkötestejä voisi myös olla tarpeellista kirjoittaa. Vaikka projekti ei ole täydellinen, väittäisimme silti että projekti on laadultaan keskimääräistä työelämän projektia parempi. Löydetyistä bugeista on käsitelty 95%. Avoimia vikoja on jäljellä kaksi kappaletta, ja niiden luokitukset ovat normal ja enhancement. Vertaisryhmän kommenttien ja oman testikäytön perusteella tuote soveltuu käyttötarkoitukseensa, mutta käytettävyydessä olisi vielä parantamisen varaa. Vertaisryhmän testaus oli mallikasta, ja testausraportti oli hyödyllinen. Ryhmä toimitti erillisen listan suorittamistaan testitapauksista, joiden perusteella oli helppo selvittää testauksen painoalueet ja lähestymistapa. Vaikka kaikki vertaisryhmän raportoimat asiat eivät olleetkaan aitoja virheitä olivat ne silti hyödyllisiä, koska niiden avulla saattoi hieman hahmottaa miten järjestelmää tuntematon käyttäjä ajattelee ja mitä oletuksia tämä tekee. AgilElephantin testauksessa pyrittiin käyttämään eri lähestymistapoja tavoitteena ketteryys ja tehokkuus. Käytettyjä testaustapoja olivat: funktionaalinen testaus o o o ryhmän itse testitapausten perusteella suorittama asiakkaan hyväksymistestaus vertaisryhmän suorittama testaus eksploratiivinen testaus automaattiset yksikkötestit järjestelmän käyttö päivittäisessä työssä Aihe: AgilElephant-loppuraportti Sivu 10 of 20

11 Näistä erityisesti vertaistestaus ja hyväksymistestaus yhdessä päivittäisen käytön yhteydessä auttoivat pienentämään omaa testauskuormaa FD-vaiheessa. Erilaisten testaustapojen käyttäminen toi mukavaa vaihtelua laadunvarmistukseen ja auttoi tältä osin motivaation säilyttämisessä. Järjestelmän ottaminen tuotantokäyttöön lisäsi varmuutta laadun tasosta. Aihe: AgilElephant-loppuraportti Sivu 11 of 20

12 4. Projekti numeroina 4.1 Ohjelmiston koko Kuvassa 1 on esitetty ohjelmiston kasvaminen ajan kuluessa. I1-vaiheen suuren rypistyksen jälkeen kasvu on ollut huomattavasti tasaisempaa. Kaiken kaikkiaan koodirivejä kertyi Testikoodin osuus on 1162 LOC eli noin 4,3% itse toiminnallisuudesta. Koodin jakautuminen eri moduuleiden kesken on esitetty kuvassa 2. Kuva 1: Projektin koodirivien kasvu lokakuusta 2004 maaliskuuhun Yhteensä LOC. Aihe: AgilElephant-loppuraportti Sivu 12 of 20

13 Kuva 2: Koodirivit moduuleittain Laajuuden analyysi Mielipiteet laajuudesta vaihtelivat laidasta laitaan. Kukaan ei varsinaisesti ollut työskennellyt aiemmin vastaavanlaisessa projektissa, joten vertailukohtia oli vaikea löytää. Alla muutama kommentti asiasta. Projekti ei sinänsä ollut hirveän laaja koodin puolesta tai teknisesti haastava. Lähinnä haastavuutta toi se, ettei asiakas itsekään (mikä on tietysti hyvin yleistä) tiennyt mitä haluaa. Lisäksi tietysti täysin hajautettu kehitys toi omia haasteitansa joista kuitenkin selvittiin kohtalaisen hyvin selkeällä tehtäväjaolla. Käpistelen työkseni hyvinkin laajaa (5-6M riviä) ohjelmistoa kanssa, mutta tällaisesta yksittäisestä projektista minulla ei ollut kokemusta. Projektipäällikön näkökulmasta laajuus oli ehkä keskitasoa ja hallittavuuden kannalta riittävän haasteellinen. Laajin projekti, jossa olen ollut mukana. Työmäärä yllätti. 4.2 Laatumetriikat Taulukossa 2 on eritelty raportoidut virheet vakavuusasteen ja statuksen suhteen. Kaikki raportoidut asiat eivät olleet virheitä. Osa oli puuttuvaa toiminnallisuutta ja osa väärinkäsityksiä. Tästä johtuen laskettaessa virheiden määrää per tuhat koodiriviä on virheille käytetty arvoa 36. Samalla virheiden ja koodimäärän suhteen laskemiseen on käytetty kokonaiskoodimäärästä alhaisempaa lukua 26683, joka on saatu poistamalle kokonaiskoodiriveistä esim. testikoodi, prototyyppikoodi ja SQL-lauseina oleva testidata. Aihe: AgilElephant-loppuraportti Sivu 13 of 20

14 New Resolved Yht. Enhancement Trivial Minor Normal Major Critical Blocker Yht Taulukko 2: Virheiden erittely Bugzillan luokituksella Bugeja per kloc: 1,35 (36 oikeaa bugia / olennaista riviä). Alhainen luku tukee käsitystämme laadusta. 4.3 Käytetyt resurssit Aika Projektiin käytetty aika jäi hieman alle tavoitteen (1330 h). Tämän ei silti koettu vaikuttavan toteutettujen ominaisuuksien määrään tai laatuun. Taulukossa 3 on eritelty tunnit henkilöittäin ja iteraatioittain. On huomattavaa, että FD-vaiheen summa kasvanee vielä ainakin 10:llä, koska edessä on projektikatselmus ja muuta valmisteltavaa. Taulukko 3: Projektin tunnit FD-vaiheen työmäärän kehittyminen on esitettu kuvassa 3. Kuva on otettu AgilElephant-järjestelmästä. Aihe: AgilElephant-loppuraportti Sivu 14 of 20

15 Kuva 3: FD-vaiheen burndown Infrastruktuuri Materiaalipuolella projektin käytössä oli pääasiallisesti kaksi palvelinta: CVS-palvelin ja CruiseControlpalvelin. Lisäksi käytettiin koko kurssille yhteisiä palvelimia eli Trapolia, Bugzillaa ja TikiWikiä. Vertais- ja hyväksymistestauksen aikana käytössä oli testipalvelin kyläverkosta. Resurssina voitaneen myös mainita sähköposti sillä sen osuus oli merkittävä: projektipäällikölle kertyi projektin aikana noin 560 projektiin liittyvää sähköpostiviestiä. Aihe: AgilElephant-loppuraportti Sivu 15 of 20

16 5. Käytännöt ja työkalut SEPA-päiväkirjojen yhteenvetojen linkittäminen tähän on hivenen hankalaa, mutta samat asiat käyvät ilmi alla olevista kommenteista. Kommentteihin liittyvä SEPA-dokumentti on kirjattu sulkeisiin Iteratiivinen prosessi Iteratiivinen prosessimalli oli varmasti ainoa järkevä tämänkaltaiselle projektille. Prosessi auttoi hallitsemaan projektissa tapahtuneita muutoksia ja parantamaan työtapoja sekä tehoa alkuvaikeuksien jälkeen. Samalla vaatimukset ja toivotut toiminnallisuudet kirkastuivat projektin edetessä, koska prosessi mahdollisti palautteen saamisen riittävän usein Staattiset metodit Itse SEPA-dokumentissa (SEPA_diary_PK_RI.doc) on pidempi yhteenveto, mutta lyhyesti voitaneen sanoa että staattiset metodit olivat (ajallisesti) varsin kevyitä ottaa käyttöön ja soveltaa, mutta ne eivät lopulta tarjonneet kovinkaan paljon hyötyä. Vaikka tulokset eivät olleet niin vahvoja kuin toivoimme, silti tämä yksittäinen projekti ei riitä todistamaan menetelmiä tarpeettomaksi, ja joka tapauksessa on järkevämpää "kokeilla kuin katua", sillä näiden analysointityökalujen asentamisesta ole koskaan haittaa. Tarkempaa analysointia löytyy SEPA:stamme Automaattiset yksikkötestit Yksikkötestit olivat mielenkiintoinen kokeilu (SEPA_diary_PK_HS.doc). Yksikkötestien kattavuus jäi kuitenkin siihen budjetoidulla ajankäytöllä valitettavan alhaiseksi. Testien tulosten seurantaan tulisi myös panostaa enemmän, jotta menetelmästä olisi enemmän hyötyä. CruiseControl-järjestelmän kanssa oli ongelmia testien ajon kanssa, Ant-skriptissä oli pitkän aikaa se ongelma, että juuri ennen testien ajoa ohjelma-paketti siirrettiin JBossin ajettavaksi, ja välillä osa testeistä ehdittiin ajaa samalla kun JBoss lataili uutta pakettia. Tämä aiheutti välillä vääriä hälytyksiä yksikkötesteissä. Automaattiset yksikkötestit ja koodin katselmoiminen eivät välttämättä sovi näin pieniin projekteihin. Automaattiset yksikkötestit olivat perusteltuja ainoastaan jatkokehityksen takia, me itse emme saaneet niistä riittävää hyötyä suhteessa työmäärään. Tästä on lisää laadunvarmistus-sepan viimeisessä kappaleessa Automaattiset buildit CruiseControl/Ant-yhdistelmä osoittautui erityisen hyödylliseksi ja monipuoliseksi seuranta- ja julkaisujärjestelmäksi. Kaiken kaikkiaan buildikone tuotti projektin aikana 396 buildia. Dokumentissa cruisecontrol.doc on kuvattu tarkemmin, mitä kaikkea automaattinen järjestelmämme teki. Automaattisia buildeja suositellaan ehdottomasti jokaiseen projektiin. Järjestelmän pystytys on kertaluontoinen kustannus ja vaikka ylläpitoa vaaditaan on siihen käytetty aika minimaalinen verrattuna hyötyyn. Ylläpitotyötä voidaan vähentää huomioimalla automaattiset buildit ant-skriptien teossa. Aihe: AgilElephant-loppuraportti Sivu 16 of 20

17 5.1.5 Eri seurantamediat Seuranta ja projektinhallinta helpottuivat tasaisesti loppua kohden ja FD-vaiheessa kaikki sujui jo lähes rutiinilla. Tästä voitaneen vetää johtopäätös, että huomattavaa oppimista on tapahtunut. Kaiken kaikkiaan projekti ja SEPA (SEPA_diary_JK.doc) olivat arvokasta kokemusta ohjelmistoprojektin hallinnasta. Aktiviteettiraportointi kolmeen eri järjestelmään (Agile, Trapoli, Wiki) oli aika tuskallista. Sykäysraportointi pitäisi jotenkin integroida Agileen (yksi helppo tapa olisi integroida siihen Wiki tai vastaava). Trapoli käyttäminen oli takkuista, AgilElephant oli parempi. TikiWikin mahdollisia hyötyjä ei oikein osattu hahmottaa ja sen tärkeimmäksi rooliksi muodostui työraporttien ja kokousmuistiinpanojen säilyttäminen Virheiden seuranta Bugzilla toimii, mutta nyt kun useimmat käyttivät sitä ensimmäistä kertaa kunnolla niin sen käytettävyys osoittautui aika huonoksi. Käyttöliittymässä kaikki vaatii vähintään muutaman klikkauksen ja raportit ovat hankalia ja huonoja. Lisäksi paljon pientä valittamista, mm. sähköpostiosoitteen käyttäminen käyttäjätunnuksena on hidasta. Alhaisen kustannuksensa takia silti käyttökelpoinen järjestelmä Heuristinen arviointi Heuristinen arviointi (SEPA_diary_EM_PV.doc) onnistui sangen hyvin, saimme paljon arvokasta palautetta ja sitä myös käytettiin järjestelmän toiminnallisuuden ja käytettävyyden parantamiseen. Suurimmat ongelmat olivat lähinnä ensimmäisessä arviointitilaisuudessa arvioijien löytäminen ja toisessa tilaisuudessa tilaisuuden kesto (1 h), joka oli aivan liian lyhyt tämänkaltaiseen toimintaan, jotta maksimaalinen hyöty olisi ollut saatavissa. Ensimmäisissä arviointitilaisuuksissa 1 tunti oli aivan riittävä aika kun arvioitavana oli vain HTML proto, mutta toisessa tilaisuudessa se osoittautui liian lyhyeksi järjestelmän toiminnallisuuden kasvamisen myötä, kuten edellä onkin jo mainittu. Vastaisuuden varalle voimme lämpimästi suositella tämän kurssin tekijöille ja muillekin heuristisen arvioinnin käyttämistä järjestelmien toiminnallisuuden ja käytettävyyden parantamiseen Koodin katselmointi FD-vaiheessa suoritimme muutoksille koodikatselmointia. Käytännön hyödyistä on vaikea sanoa näin lyhyen kokemuksen perusteella mitään ehdotonta. Yhtäkään vakavaa virhettä ei katselmoinnissa löytynyt. Kaikkiaan pientä korjauksiin johtavaa huomautettavaa löytyi noin 20% tapauksissa. Seurauksena oli esim. pieni käytettävyysparannus. Suurin ongelma katselmoinnissa oli sen järkevä toteuttaminen hajanaiselle ryhmälle. Päädyimme siihen, että CVS:ään kommitoidut muutokset lähetetään katselmoitavaksi sopivimmalle henkilölle. Toisinaan sopivin henkilö oli se, jonka tiesi olevan paikalla. Katselmointipyynnössä kerrottiin muutoksen syy, luonne, ja muuttuneiden tiedostojen revisiot. Katselmointien tulokset kirjattiin CVS:ssä olevaan lokiin (tekstitiedosto). Vaikka muutosten katselmointi on melko hyödyllinen tapa erityisesti tuotteen stabilointivaiheessa emme välttämättä suosittelisi sitä näin pienelle ja etenkään näin hajautetulle projektille. Aihe: AgilElephant-loppuraportti Sivu 17 of 20

18 6. Oppiminen Alla on kunkin ryhmän jäsenen analyysi omasta oppimisesta. Rauli: Tämä projekti ei tarjonnut kovinkaan paljoa uutta. Koodausta on tullut tehtyä töiden ja oman firman puolesta yksin ja ryhmässä jo useamman vuoden ajan ja käytetyt tekniikat olivat pääosin tuttuja. Hibernate nyt oli sentään vähän uudempi tuttavuus, mutta siitäkään ei tämän työn puitteissa otettu kaikkea irti. Petri: Opin testauksen ongelmista, ja jonkin verran sivusta seuraamalla tuli huomattua projektinhallintaan liittyvistä ongelmia. Päätavoitteeni oli saada kokemusta suuressa ohjelmistoprojektissa työskentelystä käytännössä, ja tässä suhteessa tavoitteeni täyttyivät täydellisesti. Toinen tavoitteeni oli J2EE-tietämyksen parantaminen, mutta se ei sujunut aivan odotetulla tavalla. En voi väittää tietäväni esim. JBossin sisäisestä toiminnasta läheskään yhtä paljon kuin kurssin alussa odotin. Kaikki käytetyt tekniikat ovat kuitenkin projektin jälkeen jonkin verran tutumpia. Juha: Arvokkain oppi oli varmasti projektin suunnittelun ja seurannan toteutuminen käytännössä. Oppikirjojen teoriaosuudet jäivät tässä asiassa toissijaisiksi. Oma oppimistavoitteeni tuli todellakin saavutetuksi. Pasi: Kurssi tarjosin mielestäni erittäin hyvää kokemusta ohjelmistoprojektin koko syklin lävitsekäymiseen. Mielestäni opin paljon uusia asioita kurssilla. Tutustuin uusiin teknologioihin ja sovelsin niitä projektiin (jsp,hibernate,mysql). Porukan ollessa hajallaan, tuli kokeiltua hajautettua ohjelmistokehitystä. Myös kommunikaatio-ongelmien ratkaisua tuli harjoiteltua. Lisäksi tehtävän keston arviointitaidon sopeuttamisesta uusien teknologioiden pariin tuli arvokasta kokemusta. Heikki: Oma oppimiseni jäi aika tekniselle tasolle. Opin jotakin J2EE:stä ja siihen liittyvistä tekniikoista, mutta en usko, että tästä projektista saatu tieto on riittävän kattavaa suurempien järkestelmien suunnitteluun. Lisäksi opin vähän lisää testaukseen liittyvistä käytännön asioista sekä katselmointien ja yksikkötestauksen toteuttamisesta ja hyödyllisyydestä. Esa: Opin miten on mahdollista saada ohjelmistokehitys toimimaan ajallisesti ja maantieteellisesti hajautetussa ympäristössä (vaaditaan osaava ja oma-aloitteinen tekijäjoukko). Opin paljon myös eri Javatekniikoista (Servlet ja jsp), joiden kanssa en aikaisemmin ollut tekemissä juuri lainkaan. Myös ketteristä menetelmistä sain paljon kokemuksia, erityisesti tietysti SEMS:istä. Pauli: Minulla ei ollut aikaisempaa kokemusta työelämästä eikä näin laajasta projektista, joten kokemus oli varmasti hyödyllinen. Uuden oppiminen painottui lähinnä eri teknologioihin. Aihe: AgilElephant-loppuraportti Sivu 18 of 20

19 7. Kurssipalaute Tähän lukuun on koottu projektiryhmän jäsenten kommentteja kurssista. Fiksattu tuntimäärä kurssin suorittamiselle ei ole juurikaan minun mieleeni olevan järjestelmä. Tietysti tällaisella kurssilla on vaikea käyttää mitään muuta järjestelmää, mutta noin periaatteessa se harmittaa. Käytin tähän kurssiin todennäköisesti enemmän aikaa kuin koko vuoden muihin kursseihin yhteensä ja opin hyvin paljon vähemmän kuin vaikka salausjärjestelmät-kurssiin käytetyssä 15 tunnissa. Kurssin ohjeistus ja etenkin vaadittujen palautettavien dokumenttien kuvaus oli hajautettu liian monen sivun alle, kokonaiskuvaa oli vaikea hahmottaa kurssin alussa. Jo itse ohjeistuksen lukemiseen kului useita tunteja projektin ensimmäisellä viikolla. Annettujen ohjeiden tiukkuus ja vaadittujen dokumenttien määrä ei oikein heijasta ketterien menetelmien periaatteita. SEPA-tehtävän merkitys jäi projektin kannalta vähäiseksi. Välillä tarvittavaa tietoa oli hankala löytää kurssisivuilta. Työmäärä tuntui paljon suuremmalta kuin mitä tunnit todellisuudessa olivat. 10+ tuntia projektille viikossa muiden opintojen ja töiden päälle oli paikoin hyvinkin kuluttavaa. Kurssi oli yksi käytännöllisimmistä kursseista koko TKK:n opiskeluhistoriassani. Kurssi todellakin vastaa oikeasti viittä ovaria joten välillä kurssin käyminen tuntui suhteellisen rankalta. Tuntiraportointijärjestelmä trapoli ei ollut aina mieleinen käyttää. Sen sijaan valmiina toimivat twiki ja bugzilla olivat hyvä homma kurssin tarjonnassa. Kurssi olisi voinut olla lyhyempi (esim. 3 ov) ja projektin koko joko vähän pienempi samalla ryhmäkoolla tai sama isommalla ryhmäkoolla. Näin suuren työmäärän käyttämisestä per henkilö ei ole mielestäni enää merkittävää hyötyä, siis suhteessa työmäärään. I2-vaiheesta en katso oppineeni yhtään mitään. Opittujen asioiden määrä per opintoviikko tai per työtunti oli huomattavasti pienempi kuin tietotekniikan kursseilla keskimäärin. Käytännön järjestelyt sujuivat erittäin hyvin, mikä on poikkeuksellista. Kiitos siitä. Muuten ihan kelpo kurssi, opastus ja ohjeet olivat riittävät, mutta koko SEPA -hässäkkä vaikutti vähintäänkin päälleliimatulta. Aihe: AgilElephant-loppuraportti Sivu 19 of 20

20 8. Tulevaa työtä 8.1 Parannusehdotuksia Järjestelmästä jäi puuttumaan monia projektinhallintajärjestelmälle keskeisiä ominaisuuksia kuten tuki versioille, komponenteille, sähköposti-ilmoitusjärjestelmälle ja käyttöoikeuksien hallinnalle. Myös käyttäjän toivoma laadunvarmistuksen näkökulma ei tullut juurikaan otettua huomioon ja tehtävien linkitystäkään ei ehditty tekemään. Lisäksi käyttöliittymä vaatisi tietysti kasvojenkohotusta jos jonkun haluaisi oikeasti käyttävän järjestelmää. Noiden tekemisessä riittää varmasti hyvinkin hommaa toiselle samanlaiselle kurssille. Iteraatiosivulla backlog itemien järjestäminen eri sarakkeiden mukaan olisi kannattava käytettävyysparannus. Samoin yksittäisen henkilön tehtävien listaaminen esim. iteraationäkymästä olisi kätevää projektipäällikölle. Tuntiraporttisivulla yksittäisten tuntirivien linkitys tehtäviin olisi ehdottoman hyödyllistä, koska nyt ko. raportista näkyy vain kuka on tehnyt työtä ja kuinka paljon. Kommenttisarake ei ole kovin informatiivinen ilman tietoa tehtävästä. Muita hyödyllisiä ominaisuuksia: Gantt-kuvaajat resurssien ja aikaiteraatioiden hallintaan&visualisointiin. Itemien parempi linkittäminen ja jakaminen pienempiin osiin pitäisi mahdollistaa. Itemien upload file-dialogin avulla. Sorttaustoiminnot listoihin. Uusien näkymien/filtterointi mahdollisuuksien tekeminen (esim. haluttaessa vain keskeneräiset itemit näkyviin iteraatiotasolla tms). Järjestelmän konfigurointi- ja administrointimahdollisuudet. Usealle henkilölle kuuluva tehtävä pitäisi olla mahdollinen. Myös laskutustietoja ja liitetiedostoja pitäisi lisäillä järjestelmään. Sykäysraportointi (siis tekstimuodossa, esim. blog-tyylillä) olisi hyvä lisä hajautetuille projekteille Graafisen portfolionäkymän zoomaus (tällä hetkellä pitkät aikavälit venyttävät sivun hyvin leveäksi) 8.2 Avoimet bugit Taulukossa 2 on listattu järjestelmän avoimet bugit suoraan Bugzillasta. ID Sev Pri Status 15 nor P2 NEW 44 enh P2 NEW Summary Tuotetta releasesta poistettaessa itemit jäävät release backlogiin. Ainakin keskeneräisten itemien pitäisi siirtyä product backlogiin. Jos saman releasen iteraatioiden välissä on taukoa, ei tämä näy (esim. valkeana pätkänä) portfolionäkymän graafisessa esityksessä. Taulukko 4: Avoimet bugit Aihe: AgilElephant-loppuraportti Sivu 20 of 20