Innovaatioprojekti: Prosessin hallinta

Viestintä

Asiakkaan kanssa on syytä sopia viestintäkanava (mm. sähköpostiosoitteet, puhelinnumerot). Koulun puolesta on tarjolla Flowdock. Flowdock-tyyppinen ryhmäviestintätyökalu on sähköpostia parempi väline, sillä kaikki viestit ovat milloin tahansa selattavissa.

Myös ryhmän sisäiseen käyttöön (asiakas ei jäsenenä) voi olla hyvä perustaa erillinen viestintäkanava.

Poissaoloista pitää ilmoittaa muulle ryhmälle.

Scrumin ominaisuus- ja tehtävälistojen ylläpito

Innovaatioprojekteissa ei tehdä projektisuunnitelmaa, ellei asiakas sitä vaadi. Projektisuunnitelman sijaan prosessia hallitaan ylläpitämällä Scrumin kuuluvia ominaisuus-, kehittämis- ja tehtävälistoja (backlogs). Tähän käytetään Trello-nimistä pilvipalvelua. Trello löytyy osoitteesta https://www.trello.com.

Trelloon kirjautuminen kannattaa tehdä käyttämällä Googlen autentikointia ja kirjautumalla Metropolian sähköpostiosoitteella (muotoa user@metropolia.fi). Käyttäjä ohjataan tällöin Metropolian omalle sivustolle salasanan syöttämistä varten.

Trellossa laaditaan yleensä yksi taulu (board) per projekti. Tauluun lisätään tehtävälistat (sarakkeet). Käyttäjätarinoista johdetaan konkreettiset tehtävät, joiden koko voidaan arvioida tunteina. Tehtävät näkyvät taulun sarakkeissa olevina kortteina.

Tehtävälistat - eli Trellossa näkyvät sarakkeet - voi määritellä itse. Esimerkiksi seuraavat listat (vasemmalta oikealle) muodostavat yleensä toimivan kokonaisuuden:

• Project Backlog – Koko projektissa tekemättömät tehtävät käyttäjätarinoina määriteltyinä.
• Current Sprint – Meneillään olevalle sprintille suunnitteilla olevat tehtävät.
• To-Do – Tehtävät, jotka ovat valmiita aloitettaviksi.
• In Progress – Työn alla olevat tehtävät.
• QA – Valmiit tarkistusta ja hyväksyntää odottavat tehtävät.
• Done – Valmiit ja hyväksytyiksi todetut tehtävät

Aluksi kaikki tehtävät näkyvät vasemman laidan backlogissa. Projektin kuluessa tehtävät "valuvat" vasemmasta laidasta oikeaan laitaan.

Käyttäjätarinana esitetystä Project Backlogissa olevasta kortista voi tehdä useampia tehtäväkortteja siinä vaiheessa, kun käyttäjätarina siirretään Current Sprint -sarakkeeseen. Tässä voi hyödyntää värikoodausta (esim. sininen väri = käyttäjätarina, keltainen väri = tehtävä).

Ennen sprinttiä

Sprintin suunnittelu (Sprint planning meeting):

Uuden sprintin aluksi pidetään aina sprintin suunnittelupalaveri (palaverille varataan oma tehtävä, johon työtunnit kirjataan). Palaverissa valitaan käyttäjätarinat, jotka aiotaan toteuttaa sprintissä. Mukaan otettuihin käyttäjätarinoihin tulee liittää hyväksymiskriteerit. Kun tarinat on valittu ja hyväksymiskriteerit sovittu, asiakas poistuu palaverista.

Ryhmä jatkaa jakamalla käyttäjätarinat työtehtäviksi, ja arvioi kuhunkin tehtävään tarvittavan tuntimäärän (original estimate).

Sprintin suunnittelun tarkastuslistana voi käyttää seuraavaa listaa:

• Sprintille suunnitellut tehtävät näkyvät Trellossa Current Sprint -sarakkeessa tehtäväkortteina.
• Project Backlogista on otettu prioriteettijärjestyksessä sopiva määrä tarinoita tehtäväksi seuraavaan sprinttiin ja niistä on luotu tehtäväkortit.
• Sprinttiin otettuihin tarinoihin on liitetty hyväksymiskriteerit.
• Sprinttiin kuuluvat tarinat on pilkottu riittävän pieniksi tehtäviksi ja tehtävillä on työmääräarvio.

Sprintin aikana

• Jokainen ryhmän jäsen valitsee sprintin tehtävälistalta aina seuraavan tehtävän oma-aloitteisesti tehtäväkseen (eikä ota liikaa yhtäaikaisia tehtäviä).
• Jokainen ryhmän jäsen kirjaa tuntejaan työtehtäville ja ylläpitää jäljellä olevan työnmäärän arviota.
• Viikottain pidetään palaveri, jossa käydään kunkin työtilanne läpi: mitä kuin saanut tehtyä, mitä tekee seuraavaksi.

Sprintin jälkeen

• Sprintin demo (Sprint review)
  • Tilaisuuteen osallistuu Scrum-tiimi sekä tuoteomistajan mahdollisesti kutsumat sidosryhmien tärkeimmät edustajat. Kehitystiimi esittelee “valmiin” työn ja vastaa tuoteversioon liittyviin kysymyksiin; tuoteomistaja tunnistaa, mikä osa työstä on “valmista” ja mikä ei ole “valmista”
  • Tarkistetaan tuotteen vaatimuslista, joka sisältää todennäköiset tuotteen vaatimuslistan käyttäjätarinat seuraavalle sprintille.
• Sprintin retrospektiivi (Sprint retrospective valinnainen, pidetään aika-ajoin)
  • Tarkastellaan, kuinka työ on sujunut liittyen ihmisiin, yhteistyöhön, prosessiin ja työkaluihin
  • Yritetään tunnistaa asiat, jotka sujuivat hyvin ja määritellään tärkeimmät parannukset

Sprintin lopetuksen tarkastuslistana voi käyttää seuraavaa:

• Trellossa on pidetty kirjaa yksittäisiin työtehtäviin käytyistä tunneista
• koodi löytyy versionhallinnasta ja sprintin tulokset on varustettu tagilla "Sprintx", missä x on sprintin numero (git) tai tuotokset on kopioitu tags-haaraan hakemistoon "Sprintx" (subversion)
• koodi on kommentoitu ohjeiden mukaisesti
• testitapaukset uudelle koodille löytyvät versionhallinnasta
• testitapausten koodikin on kommentoitu ohjeiden mukaisesti
• staattisen analyysin työkalut on ajettu koodille Jenkinsissä (esim. SpotBugs, SonarLint)
• testiajojen trendi ja testien kattavuus löytyvät Jenkinsistä
• projektin dokumentteja on päivitetty ja nekin löytyvät versionhallinnasta

Valmis

Scrum-menetelmässä puhutaan "Definition of Done"-määritelmästä. Oppaassa selitetään "Kun tuotteen kehitysjonon kohdan tai tuoteversion sanotaan olevan “valmis”, kaikkien tulee ymmärtää mitä “valmis” tarkoittaa. Ryhmän jäsenillä tulee olla yhteinen ymmärrys siitä, mitä valmis työ tarkoittaa".

Innovaatioprojekteissa "valmis" käyttäjätarinalle:

• Koodattu ja refaktoroitu
• Testitapaukset käyttäjätarinoille ovat olemassa
• Testit ajettu ja menevät läpi onnistuneesti
• Dokumentoitu
• Help-tekstit kirjoitettu
• Koodi ja dokumentaatio viety versionhallintaan

Seuranta: Edistymiskäyrät

Edistymiskäyrät eivät ole Trellossa vakio-ominaisuutena. Niiden käyttöönotto edellyttää lisäosan (power-up) asentamista. Tässä yhteydessä voi käyttää Burndown for Trello -lisäosaa, joka tuottaa nimestään huolimatta sekä burndown- että burnup-käyriä.

Sprintin burndown-käyrän - tai projektin Burnup-käyrän - saaminen edellyttää tarinapisteiden (story points) käyttöä käyttäjätarinoiden työmäärän (monimutkaisuuden) arvioinnissa. Tarinapisteet ovat vain vertailuarvoja toisiinsa (niillä ei ole suuretta). Yleensä valitaan lähtökohdaksi jokin yksinkertainen käyttäjätarina ja annetaan sen pisteiksi esimerkiksi luku 10 tai 50. Tämän jälkeen verrataan muita käyttäjätarinoita tähän tarinaan, kumpi on vaikeampi tai monimutkaisempi toteuttaa. Jos lähtötarinalla on vaikka arvo 10 ja seuraava verrattava tuntuu hieman vaikeammalta, voidaan sille antaa vaikka arvo 13.

Tarinapisteiden ohella on määritettävä tarkastelun kohteena olevat päivämäärät.

Toimintatapa:

1. Asettakaa projektin tarinoille tarinapisteet mieluiten projektin alkaessa.
2. Kirjaa tekemäsi työtunnit päivittäin.
3. Kirjaa tehtyjä työtunteja vain tehtäville (tasks).