Projektinhallinta SCRUM-menetelmällä

Miten se toimii?

Käytännössä tämä tarkoittaa sitä, että koko prosessia optimoidaan ja mukautetaan jatkuvasti asiakkaan tarpeisiin. joukkue ja tuote koko työn keston ajan projekti. Vastuu hallinnoinnista tuotekehitys jakautuu tuoteomistajan (PO) ja suunnitteluryhmän kesken. PO on henkilö, joka on vastuussa tuotekehityksen suuntaan liittyvien päätösten tekemisestä, ja hänellä on kokonaisvaltainen "visio" siitä, mitä tuotteesta on tarkoitus tulla. Tehtävien hallinta perustuu Kanban-tauluun (yhdessä sprintti toiminnallisuus, jota kutsutaan SCRUM-tauluksi). Kukin prosessin osallistuja voi lisätä tehtäviä backlogiin, mutta OP on vastuussa prioriteettien asettamisesta. Projektiryhmän tehtävänä on "muuntaa" PO:n ideat konkreettisiksi tehtäviksi ja suunnitella niiden toteuttaminen.

Syklin kulku

Prosessi jaetaan iteraatioihin (sprintteihin). Yhden noin 2 viikkoa kestävän sprintin aikana projektiryhmä toteuttaa ja testaa aiemmin suunnitellun toiminnallisuuden osan.

Sprintti alkaa "suunnittelulla", jossa tiimi keskustelee ja valmistelee tehtäviä, jotka PO on aiemmin hoitanut ja asettanut backlogin yläosaan. Tämän jälkeen arvioidaan näiden tehtävien vaikeusaste, ja niille annetaan pisteitä vaikeusasteen mukaan. Kun tiimin kokoonpano ja työskentelyolosuhteet ovat suhteellisen vakiot, kussakin sprintissä suoritettujen pisteiden määrä on toistettavissa ja mahdollistaa tulevan työn suunnittelun. Suunnittelukokouksen päätteeksi valitaan tehtävät, joiden kokonaispistemäärä on suoritettava yhden sprintin aikana, ja uusi sprintti alkaa.

Sprintin keskivaiheilla tapahtuu grooming. Tämä on kokous, jossa OP esittelee tiimille lisää odotuksia ja ideoita, ja projektiryhmä analysoi niitä, pilkkoo ne pienempiin tehtäviin ja esittää OP:lle mahdollisia ehdotuksia. Tulevia tehtäviä suunnitellessaan OP konsultoi analyytikkoja, käyttäjiä, UX- ja graafisia suunnittelijoita. Lisäanalyysit (markkinat tutkimus ja tietojenkäsittelytiede) tarvitaan usein tässä vaiheessa. Vasta kun PO on analysoinut ja muotoillut niin sanotun käyttäjätarinan, hän julkaisee nämä tarinat backlogissa. Käyttäjätarinan tulisi sisältää tietoa siitä, mitä OP odottaa tietystä tehtävästä tai tehtäväryhmästä ja millä kriteereillä tunnistetaan, onko tehtävä suoritettu.

Sprintin aikana pidetään päivittäin niin sanottuja "Daily standup -palavereja". Näissä kokouksissa kukin kehittäjä kertoo muulle tiimille, mitä hän on tehnyt viimeisen päivän aikana, ja mahdollisesti kertoo mahdollisista ongelmista tai esteistä, jotka haittaavat hänen jatkotyöskentelyään. Tämän nykytilanteen vaihdon ansiosta eri tehtävien välisiin mahdollisiin ristiriitoihin voidaan tarttua paljon nopeammin ja välttää tilanne, jossa kehittäjä juuttuu johonkin ongelmaan eikä pääse etenemään siinä. Päivittäisen tilannekatsauksen oletuksena on olla mahdollisimman lyhyt, mutta täyttää samalla tehtävänsä. Kokouksen pysyvä kaava kannustaa tiimiä pitämään kokouksen lyhyenä.

Sprintin aikana tehtäviä siirretään SCRUM-taululla niiden nykyisen tilan mukaan. Sarakkeiden valinta vastaa yleensä yritysten tai tiimin työjärjestelmää ja liittyy versionhallintajärjestelmään ja julkaisutiheyteen. Meillä se on seuraava:

• To do - tehtävät, jotka odottavat suorittamista
• Käynnissä - käynnissä olevat tehtävät
• Koodi review - tehtävät, jotka odottavat toisen kehittäjän tarkistusta.
• Valmisteltu - kehittäjät ovat tarkistaneet ja hyväksyneet tehtävät
• Vaiheistettu - tehtävät, jotka sijaitsevat vaiheistettuun instanssiin ja odottavat PO-hyväksyntää.
• Hyväksytty - PO:n hyväksymät tehtävät
• Valmis - valmiit tehtävät sijaitsevat tuotantoinstanssissa

Sprintin jälkeen järjestetään jälkikäteisarviointi. Tämä on työn optimointiin tarkoitettu kokous. Koko tiimi keskustelee siitä, mikä on mennyt hyvin viime sprintissä ja mitä on parannettava. Viittaamme usein myös edelliseen retrospektiiviin ja tarkistamme, olemmeko pystyneet toteuttamaan kaikki työn parantamiseen tähtäävät ideat. Retrospektiivissä käsiteltävät ongelmat voivat olla mitä tahansa kehitystyökaluista, paineiden kautta, tehtävien vaikeudesta ja kommunikaatio-ongelmista (sekä kehittäjien ja tiimin että PO:n välillä).

SCRUM masterin tehtävät

SCRUM-prosessin asianmukaisesta toteuttamisesta vastaa SCRUM-mestari. Tämä on usein tiimin käsittämättömin rooli. SCRUM-mestarilla ei ole päätösvaltaa. Päätökset tekevät tiimi ja PO yhdessä, kun taas SCRUM-mestarin rooli on poistaa esteet prosessin asianmukaiselta kululta.

SCRUM-mestarin tehtäviin kuuluvat seuraavat:

• SCRUM-kokousten pitäminen, mukaan lukien suunnittelu, grooming, päivittäinen standup-kokous ja retrospektiivinen kokous.
• Varmistetaan, että tiimi hoitaa säännöllisesti SCRUM-taulun tehtäviä ja että PO priorisoi ne.
• Toimii linkkinä tiimin ja PO:n välillä; näin ollen SCRUM-mestarilla on usein vaikea tehtävä kääntää ohjelmoijien kieli liiketoimintakielelle ja päinvastoin. Tämä johtuu siitä, että yrityksessämme SCRUM-mestari on kehittäjä, siis tekninen henkilö. SCRUM-mestarin työn yleiset puitteet eivät edellytä tätä.
• Estää tiimiä poikkeamasta aiheesta ja valvoa esityslistaa kokouksissa.
• Huolehtiminen tiimin ilmapiiristä - lähinnä kokouksissa.
• Ristiriitojen ratkaiseminen, jos niitä ilmenee.

Lue myös:

• Codestin hyvät käytännöt ohjelmistojen rakentamiseen. Lähestymistapamme asiakaspolkuun
• Codestin hyvät käytännöt ohjelmistojen rakentamiseen: GitFlow
• Codestin hyvät käytännöt ohjelmistojen rakentamiseen. Miten toteutamme vaatimusanalyysin?