Projektiryhmä Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: loppuraportti Projektin etenemisen seuranta ja kontrollointi Niilo Fredrikson
T-76.115 Tietojenkäsittelyopin ohjelmatyö 2(8) Muutosloki Versio Pvm Tekijä Kuvaus 1.0 29.11.2003 Niilo Fredrikson Eka versio 2.0 7.2.2004 Niilo Fredrikson Päivitetty kokemukset I2:n ajalta 3.0 5.3.2004 Niilo Fredrikson Päivitetty kokemukset I3:n ajalta 4.0 28.3.2004 Niilo Fredrikson Päivitetty koko projektin kokemukset ja loppuarvio (muutettu etenemisraportti loppuraportiksi) Muutosloki... 2 1 Arviointi I1-vaiheessa... 3 1.1 Menetelmän toteutus iteraation aikana... 3 1.2 Kokemukset ja johtopäätökset... 3 2 Arviointi I2-vaiheessa... 3 2.1 Menetelmän toteutus iteraation aikana... 4 2.2 Kokemukset ja johtopäätökset... 4 3 Arviointi I3-vaiheessa... 4 3.1 Menetelmän toteutus iteraation aikana... 4 3.2 Kokemukset ja johtopäätökset... 5 4 Loppuarvio... 5 4.1 Menetelmän toteutus... 5 4.2 Kokemukset ja johtopäätökset... 5 4.3 Loppuarvio... 6
T-76.115 Tietojenkäsittelyopin ohjelmatyö 3(8) 1 Arviointi I1-vaiheessa Menetelmää alettiin käyttämään I1-vaiheessa. Sen tuloksena saatiin Scrum burn down kaavio, joka luotiin (päivitettiin) kolme kertaa iteraation aikana. Projektipäällikkö pystyi sen avulla seuraamaan projektin etenemistä ja esittämään sen myös havainnollisessa muodossa sidosryhmille (mentor-tapaamisessa mentorille sekä projektikatselmuksessa katselmukseen osallistuville). 1.1 Menetelmän toteutus iteraation aikana Data, jonka pohjalta I1-vaiheen burn down kaaviot tehtiin: Päivämäärä Työtä jäljellä Työtä tehty Tehty+jäljellä Suunniteltu 30.10.2003 346 0 346 346 17.11.2003 171 188,5 359,5 346 25.11.2003 110 262,5 372,5 346 1.12.2003 0 365,5 365,5 346 Lopullinen kaavio löytyy I1-vaiheen etenemisraportista (redundanssin välttämiseksi ei kopioitu tähän). 1.2 Kokemukset ja johtopäätökset Menetelmän kannalta olennaista on jäljellä olevan työmäärän arviointi tehtäväkohtaisesti tuntiseurantajärjestelmässä. Tämä saatiin toimimaan yllättävänkin hyvin, tosin projektiryhmän jäseniä voitaisiin kenties kritisoida liian lineaarisesti ajattelusta tässä yhteydessä. Jäljellä olevat työmäärät arvioitiin hyvin usein kaavalla edellinen jäljellä oleva työmäärä miinus sen jälkeen tehty työ Iteraation aikana kävi ilmeiseksi, että menetelmän käyttämisestä oli hyötyä. Hyöty ei kuitenkaan välttämättä johtunut niinkään itse menetelmän sisällöstä, vaan siitä, että se pakotti ylipäätään seuraamaan projektin etenemistä ja esittämään sen suhteellisen järkevässä graafisessa muodossa. Jatkossa täytyy harkita, onko tarpeen kerätä tehtäväkohtaisia työtä jäljellä arvioita, vai voitaisiinko menetelmästä hyötyä samalla tavalla seuraamalla pelkästään toteutunutta työmäärää. Tätä arvioidaan seuraavan kerran I2-vaiheen lopussa, ellei projektin tilanne vaadi sitä aiemmin. 2 Arviointi I2-vaiheessa Menetelmää alettiin käyttämään I1-vaiheessa, ja käyttöä jatkettiin I2-vaiheessa. Käyttö ei poikennut paljoakaan I1-vaiheesta: sen tuloksena saatiin Scrum burn down kaavio, joka luotiin (päivitettiin) nyt vain muutaman kerran useammin kuin I1:n aikana. Projektipäällikkö pystyi sen avulla seuraamaan projektin etenemistä ja esittämään sen myös havainnollisessa muodossa sidosryhmille (mentor-tapaamisessa mentorille sekä projektikatselmuksessa katselmukseen osallistuville). Joululoman aiheuttama pitkä tauko varsinkin menetelmän käytöstä vastuussa olevan projektipäällikön työskentelyyn näkyi siinä, että kalenteriajassa mitattuna ensimmäinen kaavio saatiin tehtyä vasta iteraation puolivälissä. Työmäärässä mitattuna siinä vaiheessa oli kuitenkin tehty vasta neljäsosa työstä, joten siitä ei siinä mielessä ollut kovin suurta haittaa.
T-76.115 Tietojenkäsittelyopin ohjelmatyö 4(8) 2.1 Menetelmän toteutus iteraation aikana Data, jonka pohjalta I2-vaiheen burn down kaaviot tehtiin: Päivämäärä Työtä jäljellä Työtä tehty Tehty+jäljellä Suunniteltu 4.12.2003 432 0 432 432 16.1.2004 432 139 571 432 21.1.2004 218,5 214 432,5 432 26.1.2004 194,5 281 475,5 432 2.2.2004 107 377 484 432 8.2.2004 0 448 448 432 Lopullinen kaavio löytyy I2-vaiheen etenemisraportista (redundanssin välttämiseksi ei kopioitu tähän). 2.2 Kokemukset ja johtopäätökset Kuten aiemmin mainittu, menetelmän kannalta olennaista on jäljellä olevan työmäärän arviointi tehtäväkohtaisesti tuntiseurantajärjestelmässä. Tavoitteena oli saada arvioihin enemmän realismia eikä vain vähentää aina edellisestä arvioista sillä kertaa tehty työ ja siten saada uusi lineaarinen arvio. Projektipäällikön subjektiivinen arvio on, että tässä tavoitteessa ei edistytty. Toisaalta kaaviot ja niiden päivittäminen sinänsä tuntuvat siitä huolimatta hyödyllisiltä, joten ehkä arvioiden parantamiseen ei kannata uhrata turhaan ylenpalttisesti ajatusta, kun menetelmä muutenkin tuntuu hyödylliseltä. Edellisen iteraation päätteeksi kävi mielessä, onko tarpeen kerätä tehtäväkohtaisia työtä jäljellä arvioita, vai voitaisiinko menetelmästä hyötyä samalla tavalla seuraamalla pelkästään toteutunutta työmäärää. Tällä hetkellä tuntuu siltä, että never change a winning team ajatuksen mukaisesti tässä vaiheessa ei kannata tehdä muutoksia prosessiin. Ellei pakottavaa tarvetta tule aikaisemmin, menetelmän muutostarpeita arvioidaan seuraavan kerran I3-vaiheen lopussa. 3 Arviointi I3-vaiheessa Menetelmää alettiin käyttämään I1-vaiheessa, ja käyttöä jatkettiin sekä I2- että I3-vaiheissa. Käyttö ei I3:n aikanakaan poikennut paljoa aiemmasta: sen tuloksena saatiin Scrum burn down kaavio, jota päivitettiin nyt vain tasaisemmin kuin edellisen iteraation aikana. Projektipäällikkö pystyi sen avulla seuraamaan projektin etenemistä ja esittämään sen myös havainnollisessa muodossa sidosryhmille (asiakastapaamisessa asiakkaalle, mentor-tapaamisessa mentorille sekä projektikatselmuksessa katselmukseen osallistuville). 3.1 Menetelmän toteutus iteraation aikana Data, jonka pohjalta I3-vaiheen burn down kaaviot tehtiin:
T-76.115 Tietojenkäsittelyopin ohjelmatyö 5(8) Päivämäärä Työtä jäljellä Työtä tehty Tehty+jäljellä Suunniteltu 16.2.2004 250 0 250 250 26.2.2004 210 47 257 250 3.3.2004 149,5 90 239,5 250 8.3.2004 90,5 121 211,5 250 14.3.2004 0 209 209 250 Lopullinen kaavio löytyy I3-vaiheen etenemisraportista (redundanssin välttämiseksi ei kopioitu tähän). 3.2 Kokemukset ja johtopäätökset Menetelmää ei tulla käyttämään enää DE-vaiheessa. Toimitusiteraatio on sen verran lyhyt, että tähänastisiin kokemuksiin perustuen menetelmästä ei saisi merkittävää hyötyä. Aiemmissa iteraatioissa menetelmä on kuitenkin tuntunut hyödylliseltä. Ennen kaikkea se on pakottanut suhteellisen säännöllisin väliajoin seuraamaan projektiin käytettyä aikaa ja sitä kautta miettimään myös projektin tilannetta. 4 Loppuarvio 4.1 Menetelmän toteutus Menetelmää alettiin käyttämään I1-vaiheessa, ja käyttöä jatkettiin sekä I2- että I3-vaiheissa. Jokaisessa iteraatiossa sen tuloksena saatiin Scrum burn down kaavio. Projektipäällikkö pystyi sen avulla seuraamaan projektin etenemistä ja esittämään sen myös havainnollisessa muodossa sidosryhmille: asiakastapaamisessa asiakkaalle, mentor-tapaamisessa mentorille sekä projektikatselmuksessa katselmukseen osallistuville. Scrum burn down kaaviot perustuvat tehtyjen työtuntien ja jäljellä olevan työmäärän seuraamiseen. Sekä työtuntien seuraaminen että jäljellä olevan työmäärän arviointi tapahtui kurssilla käytössä olleella Trapolituntienseurantajärjestelmällä. 4.2 Kokemukset ja johtopäätökset Menetelmän käyttämisestä oli hyötyä. Kuten jo I1-vaiheen lopussa voitiin todeta, hyöty ei välttämättä johtunut niinkään itse menetelmän sisällöstä, vaan siitä, että se pakotti ylipäätään seuraamaan projektin etenemistä ja esittämään sen suhteellisen järkevässä graafisessa muodossa. Projektipäällikkö joutui menetelmän käytön takia säännöllisesti seuraamaan toteutuneita työtunteja Trapolituntienseurantajärjestelmässä, mitä välttämättä ei samassa laajuudessa muuten olisi tapahtunut. Jäljellä olevan työmäärän arvioinnissa huomattiin tiettyjä ongelmia. Ihmisillä näyttää olevan taipumusta arvioida jäljellä olevaa työmäärää melko lineaarisesti esimerkiksi jos alkuperäinen työmääräarvio on 100
T-76.115 Tietojenkäsittelyopin ohjelmatyö 6(8) tuntia ja tehdään 20 tuntia, arvioidaan lähes aina jäljellä olevaksi työmääräksi 80 tuntia sen enempää miettimättä arvion todenmukaisuutta. Tätä koitettiin I2-vaiheessa parantaa kehottamalla ryhmän jäseniä realististen arvioiden tekoon, mutta siinä ei kauhean hyvin onnistuttu. Se saattoi johtua siitä, että projektiryhmän jäsenille ei ollut mitään erityistä motivaatiota arvioiden parantamiseen. Huonoista arvioista kun ei oikein voi rangaista eikä hyvistä palkita, koska kyseessä on aina viime kädessä kunkin henkilön subjektiivinen arvio. 4.3 Loppuarvio Loppuarvio on syytä tehdä suhteessa alkuperäisiin suunnitelmiin ja tavoitteisiin. Alla olevaan taulukkoon on kerätty kaikki suunnitellut toimintatavat/tavoitteet (nähtävillä myös PPT-esityksessä) sekä niitä vastaava toteutuma: Suunniteltu toimintatapa/tavoite Käytetään SCRUM work burn down kaaviota (ja esitetään project reviewissä) Käytetään projektipäällikön havainnointia siinä laajuudessa kuin se on projektin erityisluonteen takia mahdollista Määritellään standardit tuntien raportointiin, joiden perusteella kaaviot voidaan pitää ajan tasalla Periaatteet tuntien kirjaamiseen: 1. Käytetään Trapolia 2. Kirjataan heti (samana päivänä) 3. Puolen tunnin kirjaustarkkuus 4. Jos ei tiedä mihin taskiin/work typeen, kirjaus unplannediin ja sähköpostia (projektipäällikkö ratkaisee) Periaatteet jäljellä olevan työmäärän merkintään 1. Kirjataan heti (samalla kun tunnit) 2. Tunnin kirjaustarkkuus 3. Arvioidaan koko taskin jäljellä oleva työmäärä (paras arvaus jos ei muuta) Menetelmää sovelletaan näillä näkymin jokaisessa vaiheessa Jokaisen vaiheen palautuksen yhteydessä projektipäällikkö arvioi, onko menetelmästä ollut hyötyä. Jos menetelmästä ei tunnu olevan lainkaan hyötyä, menetelmän käyttö keskeytetään alkaen seuraavasta iteraatiosta Toteutuma Toteutui suunnitellusti Toteutui suunnitellusti Toteutui suunnitellusti (tosin jäljellä olevan työmäärän arvioinnissa oli kohdassa 4.2 mainittuja ongelmia) Kohdat 1, 3 ja 4 toteutuivat suunnitellusti. Kohta 2 ei toteutunut projektipäällikkö joutui toistuvasti muistuttamaan tuntien pitämisestä ajan tasalla. Tämän ansiosta Trapolin tilanne oli kuitenkin läpi projektin varsin hyvin ajan tasalla. Toteutui suunnitellusti (tosin arvioiden laadussa oli kohdassa 4.2 mainittuja ongelmia) Menetelmää sovellettiin iteraatioissa I1-I3, mutta DE-vaiheessa menetelmään päätettiin olla käyttämättä, koska siitä ei nähty iteraation lyhyyden takia olevan juurikaan hyötyä. Tarkemmat perustelut luettavissa kohdassa 3.2. Muuten toteutui suunnitellusti.
T-76.115 Tietojenkäsittelyopin ohjelmatyö 7(8) Iteraation vaihtumisen yhteydessä täsmennetään tarvittaessa projektipäällikön kokemusten perusteella menetelmän käytöstä annettuja ohjeita Projektipäällikkö päivittää burn down kaavion jokaisen iteraation aikana vähintään kolme kertaa Kaavio esitetään ryhmän sisällä (tarvittaessa mentorille) ja se käydään läpi seuraavassa ryhmän status-palaverissa Mikäli tehty+jäljellä oleva työ kasvaa merkittävästi (yli 20%) isommaksi kuin suunniteltu työ, projektipäällikkö arvio työtehtävien työmäärät uudestaan ja sopii tarvittavista muutoksista asiakkaan kanssa Mikäli työtä jäljellä käyttäytyy täysin lineaarisesti, projektipäällikkö ohjeistaa ryhmää käyttämään työtä jäljellä -kenttää Trapolissa paremmin Suunnitellut hyödyt projektille: voidaan ryhtyä tarpeeksi ajoissa korjaaviin toimenpiteisiin tulee vähemmän yllätyksiä aikataulut pitävät paremmin Suunnitellut hyödyt itselle: kokemuksista voi olla hyötyä myös töissä tutustuu myös yleisesti hieman SCRUM:iin, ideoita myös muille projektinhallinnan alueille Mittarit: Menetelmää käytettäessä mittarit ovat selkeät: mitataan tehtäväkohtaista käytettyä työmäärää ja jäljellä oleva työmäärää (mittarit saadaan suoraan tuntiseurannasta) Kyselytutkimuksella (projektipäällikkö, ryhmä, mentor ja asiakas) voitaisiin kerätä dataa subjektiivisista arvioista, mutta kyselyn järjestäminen ei mahdu PSEA-tehtävien toteutuksen laajuuteen Menetelmän käyttöä seurataan erillisessä dokumentissa, jota päivitetään jokaisen iteraation lopussa, ja johon kirjataan menetelmän koettu hyöty kyseisen iteraation aikana (muiden kokemusten ja kommenttien Toteutui suunnitellusti Näistä suurimmaksi hyödyksi ilmeni toinen kohta eli se että tulee vähemmän yllätyksiä, kun menetelmä pakottaa seuraamaan tilannetta säännöllisesti. Tämä luonnollisesti myös auttaa pitämään aikataulut paremmin. Molemmat hyödyt tuntuvat edelleen relevanteilta Toteutui suunnitellusti
T-76.115 Tietojenkäsittelyopin ohjelmatyö 8(8) lisäksi) Mentor arvio dokumentin ja omien kokemustensa perusteella menetelmän hyötyä jokaisen iteraation lopussa ja ilmoittaa projektipäällikölle, mikäli pitää menetelmän keskeyttämistä järkevänä