Tässä dokumentissa kuvataan Wohtu-projektin jäsenten kokemuksia projektista.
Projektissa sovellettiin Team Software Process (TSP) -mallia. TSP:n käytöstä ei koettu olleen suuremmin hyötyä, joskaan haittaakaan. Tosin TSP:n mukaista dataa kerättiin aika minimaalisesti projektin aikana. Projektin alussa laatupäällikkö perehtyi TSP:hen ja keräsi muilta dataa, mutta ryhmää oli vaikea motivoida ja sitouttaa TSP:n käyttöön. Lisäksi TSP:n koettiin soveltuvan huonosti käytetyn ohjelmistotuotantoprosessimallin, Extreme Programmingin kanssa, koska TSP:n luonne on selkeästi kurinalaisempi.
TSP:tä olisi saattanut olla helpompaa käyttää, jos kaikki projektin jäsenet olisivat tienneet TSP:stä enemmän ennen projektin alkua. Tämä olisi myös saattanut helpottaa projektilaisten motivoitumista datan keräämisesn. Lisäksi ohjaajan kanssa olisi ehkä kannattanut käydä tarkasti läpi projektin laatusuunnitelma ja ohjaajan seurata datan keräämistä säännöllisesti esim. sovituin raportein.
XP:n mukaista pariohjelmointia ei voitu järjestää siitä käytännön syystä, että kaikilla projektin jäsenillä oli erilaiset työskentelyajat.
Kaikki projektin jäsenet kokivat XP:n käytön hyväksi ratkaisuksi. Positiivista oli mm. se, ettei tarvinnut tehdä mitään, mikä tuntui turhalta. Lisäksi monet projektin jäsenet olivat etukäteen halunneet päästä kokeilemaan XP:tä. Toisaalta, koska kaikki projektin jäsenet eivät tienneet tarpeeksi XP:stä, saattoi vaikuttaa siihen, ettei kaikkia XP:n hyviä puolia ollut mahdollista saada esiin.
XP:n ja TSP:n sovittaminen aiheutti projektin suunnitteluvaiheessa päänvaivaa. Sovittaminen oli myös vaikea toteuttaa ja käytännössä XP:n käyttö häiritsi TSP:n käyttöa ja päinvastoin.
TSP:n hengen mukaisesti projekti toteutettiin kahdessa syklissä, mikä koettiin yleisesti hyväksi ratkaisuksi.
Kahden syklin käyttö tarjosi sopivan tarkistuspisteen keskellä projektia. Lisäksi se rohkaisi saamaan jotain toimivaa aikaiseksi jo aikaisessa vaiheessa. Jälkimmäisessä syklissä voitiin myös hyödyntää ensimmäisen syklin kokemuksia.
Sykleistä olisi saattanut olla enemmän hyötyä, jos projekti olisi ollut pitempi. Toinen sykli jäi liian lyhyeksi, eikä ollut yhtä hallittu, kuin ensimmäinen sykli.
Projekti kokoontui säännöllisesti 1-2 kertaa viikossa. Kokoontumisissa pidettiin tilannekatsaus ja sovittiin seuraavista tehtävistä. Lisäksi saatettiin suunnitella yhdessä. Projekti piti yhteyttä myös säännöllisesti sähköpostilla.
Kokoontumisten määrän ja sisällön koettiin olleen sopivia. Esityslistojen ja pöytäkirjojen käyttö toi kokouksiin tarpeellista järjestelmällisyyttä ja tehokkuutta. Koodausta olisi kenties kannattanut tehdä samassa paikassa, jotta apua olisi ollut saatavissa heti esim. ympäristöongelmiin. Kommunikointi kokousten välillä sähköpostilla toimi hyvin.
Joskus pöytäkirjoihin saatettiin kirjata tehtäviä tehtäväksi, mutta niille ei kirjattu tekijää. Tämä koettiin huonoksi, koska ilman vastuuhenkilöä ei tehtävä tullut tehdyksi. Tämän takia kaikille tehtäville pyrittiinkin heti sopimaan tekijä.
Projektin toteutunut työmäärä jakautui projektin vaiheittain ja henkilöittäin seuraavasti:
| Ryhmän jäsen | Ennen syklejä | 1. sykli | 2. sykli | Postmortem | Yht. |
| Projektipäällikkö/ohjelmistopäällikkö, Petteri Kamppuri | 27 | 44,5 | 38 | 0,5 | 110 |
| Suunnittelupäällikkö/laatu- ja prosessipäällikkö, Anna Kolehmainen | 25 | 68,5 | 33 | 5 | 131,5 |
| Ohjelmistopäällikkö/suunnittelupäällikkö, Panu Kangas | 47 | 61,5 | 30 | 1,5 | 140 |
| Laatu- ja prosessipäällikkö/tukipalvelupäällikkö, Justus Karekallas | 35 | 64,5 | 38 | 3 | 140,5 |
| Tukipalvelupäällikkö/projektipäällikkö, Harri Nevanlinna | 30 | 44,5 | 17 | 0 | 91,5 |
| Yht. | 164 | 283,5 | 156 | 10 | 613,5 |
Projektin kokonaistyömääräksi tuli n. 613 tuntia. Projektin varsinainen työ tehtiin viikoilla 4 - 19, ja näin ollen projektin tehokas kesto oli 16 viikkoa. Projektin aikana keskimääräinen työmäärä/henkilö/viikko oli 7,7 tuntia. Työajan jakautumisesta sykleittäin nähdään, että ensimmäiseen sykliin panostettiin työmäärällisesti selvästi enemmän. Tosin toiseen syklin aikana oli myös lomia, kuten pääsiäinen ja vappu.
Työmäärä jakautui henkilöiden kesken kohtuullisen tasaisesti ottaen huomioon, että jotkut projektin jäsenet saattoivat työskennellä muita tuottavammin esimerkiksi vankemman ohjelmointikokemuksen ansiosta.
Jokaisella projektin jäsenellä oli TSP:n mukainen rooli projektin alusta lähtien. Rooleja vaihdettiin syklien vaihtuessa. Roolit olivat: projektipäällikkö, prosessi- ja laatupäällikkö, suunnittelupäällikkö, tukipalvelupäällikkö ja ohjelmistopäällikkö.
Roolit tarjosivat valmiin työnjaon heti projektin alusta lähtien. Kaikille tärkeimmille tehtäville oli vastuuhenkilöt ja se auttoi, että ne tehtävät tuli myös tehtyä.
Roolien vaihtamisesta koettiin olleen enemmän haittaa kuin hyötyä. Toinen sykli oli sen verran lyhyempi, että harva ehti sisäistää rooliaan kunnolla ja lisäksi joidenkin roolien, esim. suunnittelupäällikön ja tukipalvelupäällikön, tehtävät painottuvat niin selkeästi projektin alkuun, ettei projektin lopussa roolilla ollut enää paljoa vastuuta eikä siten mahdollisuutta varsinaisesti toimia roolissa. Oppimisen kannalta roolien kierrättäminen kuitenkin koettiin hyväksi asiaksi.
Projekti sai toimia varsin itsenäisesti: ainoastaan projektipäällikkö raportoi viikottain projektin etenemisestä kurssin ohjaajalle
Itsenäinen työskentely koettiin motivoivaksi, koska projektilaisten kykyyn toimia itsenäisesti yhdessä luotettiin. Toisaalta valvonnan puutteen koettiin haitanneen motivaatiota, koska kenellekään ei ollut pakko jatkuvasti esitellä edistymistä. Tehokkaampi valvonta olisi varmasti ainakin kannustanut TSP:n kurinalaisempaan käyttöön.
Projektipäällikkö koki tapaamisensa ohjaajan kanssa hyödylliseksi. Ohjaaja antoi mm. tarpeellista tietoa siitä, mikä kurssilla on tärkeää.
Projekti sai tehtäväksen projektinhallintajärjestelmän, mutta tehtävän rajauksen sai projekti tehdä itse. Projektissa päätettiin tehdä ensimmäisessä syklissä järjestelmän ydintoiminnallisuus ja jätettiin lopuista järjestelmän osista päättäminen toisen syklin alkuun.
Tehtävänanto oli sopivan kokoinen, koska sen sai itse rajata. Tehtävä oli myös sen luonteinen, että rajaus oli helppoa ja siihen oli helppo "liimata" lisää ominaisuuksia. Laajuudessa oli se vaara, että projekti olisi saatanut haukata itselleen liian ison kakun, mutta onneksi rajaus osattiin tehdä järkevästi; se oli projektilaisten mielestä sekä tarpeeksi haastava että sopivan kokoinen.
Projekti päätti dokumentoida ensisijaisesti omaan käyttöään varten. Tämän lisäksi soviittiin tehtäväksi ylläpitoa ja jatkokehitystä palveleva dokumentti. Dokumentteja tuotettiin loppujen lopuksi yllättävän paljon sekä kappale- että sivumäärällisesti.
Kaikki projektilaiset kokivat hyväksi sen, ettei turhaan dokumentointiin mennyt aikaa. Monilla oli tästä huonoja kokemuksia esim. Ohtu-projektista. Projektia varten dokumenteja koettin olleen pääsääntöisesti tarpeeksi. Ehkä määrittelyvaiheessa olisi esim. korkean tason luokkakaaviosta olla hyötyä esim. käsitteiden kirkastumisen apuna ja se olisi saattanut vähentää tietokantaan tulleita, tosin vähäisiä muutoksia. Myös osa oli sitä mieltä, että jatkokehitystä varten ei välttämättä dokumentointia ole tarpeeksi. Toisaalta Javadocit ovat hyvin kattavat.
Projektissa käytettiin mm. seuraavia välineitä: CVS, Tomcat, Servletit, JDBC, PostgreSQL ja eri Java-kehittimet. Kehitysympäristönä oli TKTL:n Linux-palvelimet ja omat henkilökohtaiset työasemat etäyhteyden kautta.
Käytetyt välineet koettiin hyviksi. Niiden käyttöönottoon taas meni osalta projektin jäseniltä kohtuuttomasti aikaa, koska aiempaa kokemusta moisista ei ollut. Muiden projektilaisten ohjeista oli paljon apua.
Laitoksen ympäristö jarrutti työntekoa. Esimerkiksi kaikille saatavilla olevan demo-ympäristön pystyssä pitäminen vaati sen käynnistämistä kymmenen tunnin välein.
Yleisesti ottaen projektilaiset olivat tyytyväisiä projektiin. TSP:n osuus jäi odotettua vähemmälle, mutta projektilaiset pitivät tärkeänä, että toimivan sovelluksen tuottaminen varmistettiin.
Tulevissa kurssin toteutuksissa olisi varmasti hyödyllistä perehdyttää kaikki projektilaiset TSP:hen kunnolla. Lisäksi laatusuunnitelman tekemistä kannattaisi ehkä ohjata enemmän ja sen noudattamisesta pitäisi huolehtia.
XP:n käyttöä TSP:n kanssa projekti ei suosittele.