Scrum-kehitys HY:ssä

1 Scrum-tiimin kokoonpano ja roolit

Scrum-tiimi muodostetaan Scrum Guiden mukaisesti. Se siis koostuu seuraavista rooleista:  

• Yksi tuoteomistaja
• Yksi Scrum Master
• Kehittäjiä

Scrum-tiimi on itseohjautuva, monitaitoinen ja vailla riippuvuuksia tiimin ulkopuolisiin henkilöihin. Jos projektissa vaaditaan HY:n toimintaympäristön erityisosaamista (esim. tietoturva, integraatiot, sovellusarkkitehtuuri) tai erityispanostusta vaikkapa testaukseen tai formaaliin dokumentointiin, työhön osallistuvat arkkitehdit, testaajat, tekniset kirjoittajat ym. roolit nimetään ja resursoidaan osaksi kehitystiimiä.

1.1 Tuoteomistaja

Tuoteomistaja tulee HY:stä ja edustaa yleensä tilaavaa yksikköä. Tuoteomistaja saattaa toimia samalla tilaajan projektipäällikkönä tms. rinnakkaisessa roolissa ko. projektissa.

HY sitoutuu valmentamaan tuoteomistajansa ketterään ohjelmistokehitykseen ja scrum-prosessiin, jotta Scrum-tiimi kokonaisuudessaan voi toimia ketterästi. HY:n tietotekniikkakeskus tarjoaa tuoteomistajille taustatukea työskentelyyn.

HY sitoutuu myös tuoteomistajan riittävään resursointiin ja saatavilla oloon koko kehitystyön ajaksi, jotta Scrum-tiimillä on onnistumisen edellytykset.

 Terminologiaa: HY:llä on projekteissa myös usein erillinen projektin/palvelun tms. omistajan rooli. Nämä kaksi (omistaja ja tuoteomistaja) tarkoittavat eri asiaa. Tyypillisesti omistajalla viitataan esim. tilaavan yksikön päällikköön tai palveluvastaavaan, joka on vastuussa palvelusta tai kyvykkyydestä, johon sovelluskehitystä tehdään. Tyypillisesti tuoteomistaja (PO) on tilaavan yksikön substanssiasiantuntija (esim. järjestelmän pääkäyttäjä), jolla ei ole projektin ulkopuolella budjettivastuuta tms. Tuoteomistaja osallistuu Scrum-tiimiin ja vastaa siinä roolissa päivittäisen kehitystyön organisoinnista ja priorisoinnista. Palvelun omistaja ei osallistu Scrum-tiimiin mutta osallistuu ohjausryhmätyöskentelyyn ja vastaa tuotevisiosta ym. suurista linjoista. Omistaja toimii myös rajapintana projektin ulkopuoliseen organisaatioon, mm. varmistaa projektin riittävät resurssit perinteisessä vuosikello-budjetoinnin maailmassa. 

1.2 Scrum Master

Scrum Master tulee joko HY:n sisältä tai ulkoiselta toimittajalta, sen mukaan miten projektikohtaisesti sovitaan. Scrum Master voidaan nimetä myös kehitystiimin sisältä, kunhan projektissa tiedostetaan ja hyväksytään, että Scrum Masterin tehtävien menestyksekäs hoito vaatii jopa puolipäiväistä työskentelyä (per projekti). Kehittäjien muodostaessa isomman poolin ja osallistuessa useampiin projekteihin voi olla järkevää organisoida useammalle projektille yksi yhteinen, (lähes) päätoiminen Scrum Master.

Scrum Masterin tulee osata työnsä edellyttämät tiedot ja taidot CSM/PSM-sertifioinnin määrittelemällä vaatimustasolla. Sertifikaatilla sinänsä ei ketterissä periaatteissa ole itseisarvoa, mutta HY edellyttää sen mukaista osaamista. 

Ulkoisia toimittajia käyttävissä projekteissa voidaan sopia toimittajan Scrum Masterin hoitavan fasilitointitehtäviensä lisäksi myös projektipäällikkötyyppisiä toimia, kuten ohjausryhmätyöskentelyä, tuntilistojen toimittamista jne.

1.3 Kehitystiimi

Kehitystiimiin voidaan nimetä kehittäjiä sekä HY:ltä (tyypillisesti Tietotekniikkakeskuksesta) että ulkoiselta toimittajalta. Kehitystiimi voi siis koostua pelkästään HY:n tai toimittajan edustajista tai muodostua sekatiimiksi. Jako sovitaan projektikohtaisesti.

Tyypillisiä tilanteita, joissa käytetään HY:n ja toimittajan sekatiimejä, ovat esim.

• ”DevOps”: HY haluaa ottaa kehitettävän tietojärjestelmän haltuunsa ylläpitoa/operointia ja jatkokehitystä varten, eikä siten halua ulkoistaa järjestelmän osaamista täysin
• ”Asiantuntija”: projektissa vaaditaan HY:n toimintaympäristön erityisosaamista (esim. integraatiot, sovellusarkkitehtuuri, palvelinympäristö, substanssiosaaminen) ja/tai projektin tuotokset vaativat erityistä katselmointia, jolloin tiimiä vahvistetaan esim. HY:n sovellusarkkitehdillä tai teknisellä asiantuntijalla
• ”Lisäkädet”: HY vahvistaa väliaikaisesti omaa kehitystiimiään toimittajan tarjoamilla lisäresursseilla

Kehitystiimin jäsenten resursointi voi olla projekti- ja tilannekohtaisesti koko- tai osapäiväistä tai esim. arkkitehtien osalta tilapäistä/konsultoivaa.

2 Scrum-ohjelmistokehityksen toteutusmalli

Sprintin (iteraation, työpaketin) määritelmä on Scrum-oppaan mukainen (s.7–8). Sprintin kesto on oletusarvoisesti 2 viikkoa.

Scrumin tapahtumat 
Scrumin tapahtumista on jäljempänä esitetty HY:n käytännöt omissa aliluvuissaan.

Scrumin tuotokset (artefaktit)
Tuotteen kehitysjono, sprintin kehitysjono ja inkrementti ("tuoteversio") ymmärretään Scrum-oppaan (s. 10–12) mukaisesti.

Muut tuotokset: Tuoteomistaja, HY:n arkkitehti tms. taho voi vaatia, että tietyt osat järjestelmästä suunnitellaan ja dokumentoidaan formaalisti. Tällaiset vaatimukset voivat edellyttää projektilta myös muita kuin tässä mainittuja tuotoksia (esim. suunnittelu- ja muita dokumentteja).

3 Julkaisusuunnittelu (release planning, roadmap planning)

Julkaisulla ymmärretään tässä yhden tai useamman inkrementin (tuoteversion, increment) muodostamaa kokonaisuutta, joka voidaan viedä tuotantokäyttöön kerralla. Kehitysjonon jaottelua tällaisiksi julkaisuiksi kutsutaan julkaisusuunnitteluksi.

Julkaisusuunnittelu pitää sisällään myös tuotteen kehitysjonon luomisen projektin alussa.

Joskus sprintissä syntyvän yksittäisen tuoteversion julkaisulla ei ole riittävästi arvoa tuoteomistajalle ja tämä päättää jäädä odottamaan seuraavaa, täydellisempää tuoteversiota. Joskus tuoteversion julkaisua voidaan joutua lykkäämään ympäröivän maailman huomioimiseksi, esim. jos tuotteeseen integroidut muut järjestelmät eivät ole valmiita tuoteversion aiheuttamiin muutoksiin. Nämä tilanteet huomioidaan osana julkaisusuunnittelua.

Tuoteversion julkaisujen suunnitteluun Scrum-oppaassa ei (juurikaan) oteta kantaa. Julkaisusuunnittelu ei pohjimmiltaan eroa tuotteen kehitysjonon työstöstä, mutta tapahtuu korkeammalla abstraktiotasolla ja etupainotteisemmin. HY:ssä noudatetaan seuraavia julkaisusuunnittelun käytäntöjä.

• Vastuu: Tuoteomistaja
• Osallistujat:
  • Asiakkaan projektipäällikkö ja/tai tuoteomistaja
  • Toimittajan projektipäällikkö ja Scrum Master
  • Laatupäällikkö, testaajat ja sidosryhmät kutsuttaessa
• Ajankohta ja kesto: Kokoontuu vähintään kerran kuukaudessa (kehitystyön aikana), enintään 4 tuntia kerrallaan
• Lopputulos: Priorisoitu kehitysjono ryhmiteltynä alustavasti julkaisuihin

Sisältö:

• Tuoteomistaja kertoo keskeiset kriteerit priorisoinnille sekä toiminnallisuuden että kalenteriaikojen kannalta.
• Käyttötapausten, vaatimusten (myös ei-toiminnalliset) ja korjausten priorisointi
• Hankkeen vaiheiden välisen synkronoinnin ja ulkoisten järjestelmien integroinnin huomioon ottaminen priorisoinnissa
• Tekniset henkilöt ottavat kantaa esitettyyn toteutusjärjestykseen; tekniset seikat saattavat vaikuttaa toteutusjärjestykseen
• Kehitysjonon kohdille tehdään karkea työmääräarviointi esim. "T-paitakoko"-asteikolla: XS, S, M, L, XL
• Kehitysjono priorisoidaan, tavoitteena tuoteomistajan näkemys toivottavasta toteutusjärjestyksestä

4 Kehitysjonon jalostaminen (backlog refining)

Kehitysjonon jalostamisessa eli työstössä noudatetaan Scrum-opasta (s. 11). Scrum-tiimi jalostaa vaatimusmäärittelyä kollaboratiivisesti: täsmentää ja lohkoo käyttäjätarinoita, tekee karkeita työmääräarvioita ja tunnistaa riskejä, esteitä ja selvitystarpeita.

Houkutuksena on usein jättää perkaaminen pelkästään tuoteomistajan ja Scrum Masterin vastuulle ja antaa kehittäjien keskittyä ”oikeaan työhön”, mutta tähän ei saa langeta, sillä se loisi keinotekoista kulttuurista kuilua ”määrittelijöiden” ja ”toteuttajien” välille. Tämä huonontaisi kommunikaatiota ja heikentäisi onnistumisen mahdollisuuksia.

• Työpanos: 5–10 % koko sprintin työpanoksesta
• Ajoitus: Riittävästi ennen seuraavan sprintin suunnittelukokousta. Jos tuoteomistaja ei ole 100-prosenttisesti kehitystiimin käytettävissä, sovitaan työstötilaisuuksille säännöllinen aika, jotta tilaisuudet eivät jää pitämättä.
• Lopputulos: Työstettyjen käyttäjätarinoiden osalta sprinttisuunnitteluun valmis tuotteen kehitysjono

Tavoitteet:

• Antaa tiimille tilaisuuden orientoitua tulevaan sprinttiin ja poistaa potentiaalisia esteitä jo ennen varsinaista suunnittelutilaisuutta
• Pakottaa myös tuoteomistajan valmistautumaan huolella sprintin suunnitteluun
• Sprintin suunnittelutilaisuus on tehokkaampi ja fokusoituu oikeisiin asioihin
• Minimoi tiedonsiirron (hand-off) aiheuttaman hukan; vaatimusmäärittelyä ei ojenneta kehittäjille vaan he ovat mukana luomassa sitä

 Työstön mahduttaminen osaksi sprinttiä on osoittautunut vaativaksi. Monet kehittäjät kokevat stressiä työn sirpaleisuudesta ja haluavat välttää flow'n katkaisevia "ylimääräisiä" palavereita. Selkeyttävän jalostamistyön ja varsinaisen toteutustyön tasapainottaminen on kuitenkin tärkeää, sillä ilman etupainotteista työstöä myös se "varsinainen" toteustyö sakkaa ennen pitkää. Kannustamme tuoteomistajaa ja Scrum Masteria rakentamaan sprinttityöhön riittävästi aikaa työstölle, mutta mahdollisimman vähän kehittäjien keskittymistä katkoen ja 5-10% suhteellista osuutta noudattaen.

5 Sprintin suunnittelu (sprint planning)

Sprintin suunnittelussa noudatetaan Scrum-opasta (s. 8–9). Suunnittelupalaverissa tuotteen työstetystä kehitysjonosta poimitaan sprintin työlistalle ne alkiot, jotka kehitystiimi ennustaa ehtivänsä kehittää sprintin aikana ja suunnitellaan niiden toteutus. Lisäksi noudatetaan seuraavia käytäntöjä.

• Ajoitus ja kesto: Aina uuden sprintin aloituksen yhteydessä (noin 2 viikon välein, enintään 4 tuntia 2 viikon sprintille)
• Alkuehdot:
  • Tuotteen kehitysjono on priorisoitu ja työstetty sprinttikelpoiseksi
  • Koko tiimi (myös tuoteomistaja!) on käytettävissä sprinttiin
• Näkyvyys: Kaikki sprintin aikana tehtävä työ pitää saada näkyväksi. Näkymätöntä ”kammiokoodausta” tai ”pöytälaatikkotehtäviä” ei pidä olla. Ensisijainen keino näkyvyyden luomiseksi on seinätaulu (task board) ja sillä näytettävät tehtävät (”taskit”).
  
  Seinätaululla mallinnetaan mm. seuraavat:
  • varsinaiset sprintin työlistasta ilmenevät toteutustehtävät
  • käyttöliittymäsuunnittelu
  • tekniset suunnittelutehtävät (rajapinnat, tietomalli, jne.)
  • selvitystehtävät (esim. ”tutki soveltuuko työkalu X”)
  • dokumentointitehtävät
  • erityiset katselmointi- ja testaustehtävät
     

Ks. tarkemmat task boardia koskevat ohjeet luku 6.1Seinätaulu (task board).

• Työmääräarviot: Tehtävistä tehdään korkeintaan työpäivän kokoisia. Tehtävien työmäärä arvioidaan systemaattisesti esim. planning poker –menetelmällä. Työmäärät karkealla jaottelulla esim. 0, ½, 1, 2, 4, 8 h.
• Erityiset tehtävät:
  Tehtäviin merkitään selkeästi, jos ne vaativat erityishuomiota:
  • Erityisen kriittiset/riskialttiit tehtävät, jotka on testattava poikkeuksellisen huolellisesti (esim. sovelluksen keskeiset päättelysäännöt, vaativat integraatiot) => tehtäviin liitetään riittävät speksit (esim. testitapaukset) tai tehdään testistä erillinen tehtävä
  • Monimutkaiset, useampaa silmäparia vaativat tehtävät, jotka pitää toteuttaa ja/tai katselmoida parikoodauksena
  • Erityisen kattavaa käyttöliittymäsuunnittelua vaativat tehtävät
  • Tiimin ulkopuolisista tahoista riippuvat tehtävät, jotka vievät runsaasti kalenteriaikaa tai joiden blokkautuminen on riski => toteutetaan ensimmäisinä
• Lopputulokset:
  • Sprintin priorisoitu tehtävälista
  • Sprintillä on nimetty tavoite (”teema”, sprint goal) auttamaan tiimiä fokusoitumisessa
  • Kehitystiimi sitoutuu suorittamaan sprintin
  • Kehitystiimi osaa selittää kuinka aikoo työskennellä saavuttaakseen sprintin tavoitteen
  • Sprintin alku- ja päättymispäivämäärät on sovittu

6 Sprintin aikana työskentely

Sprintin aikaisesta toiminnasta ei ole annettu kaiken kattavia ohjeita Scrum-oppaassa, mutta oleellisia kohtia ovat Sprintti (s. 7), Päivittäispalaveri (s. 9) sekä Sprintin kehitysjono (s. 11). Tiimi noudattaa lisäksi seuraavia parhaita käytäntöjä.

• Alkuehto: Sprintin suunnittelupalaverin lopputulokset ovat käytettävissä.
• Työrauha: Ainoastaan kriittiset bugit otetaan kesken suorituksen käsittelyyn, muut havainnot menevät työlistalle; tiimin jäseniä ei kutsuta palavereihin, jotka eivät edistä työn alla olevan sprintin valmistumista / seuraavan sprintin esivalmistelua.
• Tuoteomistajan läsnäolo: Ensisijaisesti tuoteomistaja ja kehittäjät työskentelevät samoissa tiloissa täyspäiväisest Mikäli tuoteomistaja ei ole 100-prosenttisesti paikalla tai ei voi työskennellä samoissa tiloissa, on scrumtiimin sovittava aikataulut tuoteomistajan läsnäololle. Minimivaatimus tuoteomistajalle on, että hän on läsnä ainakin 2–3 päivänä viikossa kysymyksiin vastaamista, kehitysjonon työstöä ym. varten. ToDo: Uusi normaali, hybridityö & etätyö!
• Oman tehtävän merkkaus: Työskentelyn läpinäkyvyyden edistämiseksi jokainen merkkaa työn alle ottamansa tehtävät (fyysisellä seinätaululla esim. nimilapulla, sähköisellä taululla vastaavalla toiminnolla).
• Esteiden merkkaus: Esteet voidaan kirjata erilliselle Esteiden poisto –työlistalle, tai niistä voidaan tehdä erilliset tehtävät, ja/tai kiinnittää estyneisiin tehtäviin erillinen ESTE-markkeri. Tässäkin oleellisempaa on läpinäkyvyys kuin toteutusdetaljit; tiimissä kaikkien on voitava koko ajan nähdä, missä esteiden suhteen mennään.  ToDo: Aika detaljitasoista ohjeistusta →  ehkä erilliseen HowTo-niksidokumenttiin?
• Päivittäispalaveri: Tiimi tarkastelee työnsä edistymistä kohti sprintin tavoitetta ja sprintin tehtävälistan toteutumista. Päivittäispalaveri järjestetään Scrum Guiden (s. 9) mukaisesti päivittäin, tiimin valitsemana ajankohtana (2–15 minuuttia).
• Esteiden poisto: Päiväpalavereissa ei pysähdytä ratkaisemaan ongelmia tai speksaamaan, vaan scrummaster kirjaa esiin nousseet asiat ja varmistaa niiden etenemisen.
• Mittareiden päivitys: Valmiiksi tulleiden tehtävien osuus visualisoidaan päivittäin jäljellä olevan työn kuvaajaan (burn-down chart) (ks. luku 6).   ToDo: Kuinka moni tätä nytkään on noudattanut? Kuollut kirjain?
  
  Yksi laadun mittari on, kuinka suuri osa toteutustehtävistä menee läpi testauksesta (kehitystiimin sisäinen ja hyväksymistestaus) vs. palautuu takaisin korjattavaksi. Korjauksiin käytetty työaika ei näy suoraan jäljellä olevan työn kuvaajassa, joten tiimin on tehtävä tähän käytetty aika näkyväksi muulla tavoin. Suositus on, että tämä aika merkitään ko. kuvaajaan erillisenä pylväänä/käyränä tms.
• Lopputulos: Sprintti on suoritettu ja valmis katselmoitavaksi.

7 Sprinttikatselmus (sprint review)

Sprintin lopussa pidetään sprinttikatselmus, jossa tarkastellaan kehitetty tuoteversio ja sopeutetaan tarvittaessa tuotteen kehitysjonoa. Katselmus järjestetään Scrum Guiden (s. 10) mukaisesti. Katselmuksessa keskeinen käsite on “valmiin määritelmä” (Definition of Done), ks. luku 4.10.

• Ajoitus ja kesto: Aina sprintin lopussa (eli noin 2 viikon välein, enintään 2 tuntia 2 viikon sprintille)
• Lopputulos: On tunnistettu ”valmiit” ja ”ei-valmiit” osat kehitysjonosta, ja tuotettu sen pohjalta tuotteen tarkistettu kehitysjono.

8 Sprintin retrospektiivi (sprint retrospective)

Retrospektiivissä scrumtiimi tarkastelee työskentelyään ja suunnittelee parannuksia ohjelmistonkehitysprosessiinsa. Retrospektiivi järjestetään Scrum-oppaan (s. 10) mukaisesti.

• Ajoitus ja kesto: Katselmuksen jälkeen, ennen seuraavaa sprintin suunnittelupalaveria (eli noin 2 viikon välein, enintään 1,5 tuntia 2 viikon sprintille)
• Parannusideat: Parannuksia pannaan toimeen iteratiivisesti ja vähitellen, kuten scrumtiimi muutenkin toimii. Retrospektiivin tuloksena syntyvistä parannusideoista tiimi poimii vain noin 1–3 akuuteinta ja sitoutuu niiden toteuttamiseen lähimpien sprinttien aikana. Tätä pidemmän ”kehitysideoiden kehitysjonon” ylläpitäminen on pitkälti ajanhukkaa.
  
  Päätettyjen ideoiden toteutumista tarkkaillaan seuraavan sprintin kaikissa vaiheissa: suunnittelupalaverissa, päiväpalavereissa, katselmuksessa, jne. Myös toteutumatta jääneet parannukset ovat syötettä seuraavalle retrospektiiville: mitkä syyt estivät parannuksen toteutumisen, ovatko olosuhteet muuttuneet jne.
• Mittareiden viritys: Yhtenä ulottuvuutena tiimin toiminnan tarkastelussa tutkaillaan käytössä olevia mittareita (esim. burn-down, erilaiset koodin mittarit kuten testikattavuus tai kompleksisuus jne.) ja viritetään niitä tarvittaessa.
• Lopputulos: On tunnistettu hyvin menneet ja parannusta kaipaavat asiat, sekä laadittu suppea, 1–3 kohdan suunnitelma parannusten toteuttamiseksi.
• Työmenetelmät: Tiimi valitsee työtavat itse. Suosituksia retrospektiivin työskentelytavoiksi ovat mm.
  • Nelikenttä (mikä meni hyvin, mitä parannettavaa, mitä opimme, mikä jäi epäselväksi)
  • Juurisyyanalyysi (root cause analysis, ”5 x miksi?”)
  • Kuusi ajatteluhattua (Six Thinking Hats, ks. esim. Wikipedia)
  • Appreciative Retrospective
  • ToDo: → Erillinen HowTo-artikkeli retrojen vetämisestä, tässä liikaa bloattia

9 Valmiin määritelmä (Definition of Done)

HY:llä ei ole standardoitua, koko organisaation kattavaa valmiin määritelmää, joten yleensä Scrum-tiimin tulee itse luoda tuotteelle sopiva valmiin määritelmä.

Valmiin määritelmä ymmärretään Scrum-oppaan (s. 12) mukaisesti ja Scrum-tiimin tulee osata selittää oma valmiin määritelmänsä. Prosessin eri vaiheisiin tarvitaan lisäksi erilaisia ”valmiin” määritelmiä, jotka Scrum-tiimin on sovittava ja noudatettava: 

• Kehitysjono valmisteltu (ready) sprintin suunnitteluun (”sprinttikelpoinen”)
• Tehtävä valmis (testattavaksi tai katselmoitavaksi)
• Sprintti valmis katselmoitavaksi
• Tuoteversio valmis julkaistavaksi

Scrum-oppaan (2016) mukaan ”Kun Scrum-tiimit kypsyvät, niiden “valmiin” määritelmä laajenee sisältämään tiukemmat kriteerit korkealle laadulle”. Kehitystiimin tulee käyttää n. 5–10 % työajastaan ”valmiin” määritelmän laajentamiseen asteittain. Käytännössä tämä työ pitää usein sisällään esim. testiautomaation tai jatkuvan integraation kehittämistä.

10 Poikkeustilanteita

Sprintin keskeyttäminen/peruuttaminen: tämä on harvinainen tilanne, joka on pudotettu pois Scrum Guidesta vuonna 2020 oppaasta liian ohjailevana. HY:llä ei ole erityistä käytäntöä keskeyttämiseen. Tiimin ja PO:n kannattaa tarvittaessa etsiä vihjeitä tällaiseen tilanteeseen saatavilla olevilta tahoilta, esim. mahdollisesti käytettävissä olevilta agile-valmentajilta, naapuritiimin kokeneemmilta scrum mastereilta tms.