Projektiryhmä Tete Work-time Attendance Software. Henkilökohtainen SE harjoitus: loppuraportti

Transkriptio

1 Projektiryhmä Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: loppuraportti Projektin etenemisen seuranta ja kontrollointi Niilo Fredrikson

2 T Tietojenkäsittelyopin ohjelmatyö 2(8) Muutosloki Versio Pvm Tekijä Kuvaus Niilo Fredrikson Eka versio Niilo Fredrikson Päivitetty kokemukset I2:n ajalta Niilo Fredrikson Päivitetty kokemukset I3:n ajalta Niilo Fredrikson Päivitetty koko projektin kokemukset ja loppuarvio (muutettu etenemisraportti loppuraportiksi) Muutosloki Arviointi I1-vaiheessa Menetelmän toteutus iteraation aikana Kokemukset ja johtopäätökset Arviointi I2-vaiheessa Menetelmän toteutus iteraation aikana Kokemukset ja johtopäätökset Arviointi I3-vaiheessa Menetelmän toteutus iteraation aikana Kokemukset ja johtopäätökset Loppuarvio Menetelmän toteutus Kokemukset ja johtopäätökset Loppuarvio... 6

3 T 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 ,5 359, ,5 372, ,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.

4 T 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 , , , , 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:

5 T Tietojenkäsittelyopin ohjelmatyö 5(8) Päivämäärä Työtä jäljellä Työtä tehty Tehty+jäljellä Suunniteltu , , , , 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

6 T 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.

7 T 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

8 T 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ä