Scrum Commitment (sitoutuminen) Focus (keskittyminen)

Esitys aiheesta: "Scrum Commitment (sitoutuminen) Focus (keskittyminen)"— Esityksen transkriptio:

1 Scrum Commitment (sitoutuminen) Focus (keskittyminen)
Openness (läpinäkyvyys) Respect (kunnioitus) Courage (Rohkeus) HUOM. Muistiinpanojen terminologia on osin vanhentunut. Tärkeintä on huomata käaitteiden Scrum Team ja Development Team tämän hetkiset määrittelyt! Scrum yksi suosituimmista ketterän ohjelmistokehityksen viitekehyksistä/prosessimalleista. Jeff Sutherland ja Schwaber loivat Scrum prosessin vuonna 1993, Takeuchin ja Nonakan vuonna 1986 tekemän tutkimukseen perustuen. Scrum sopii erinomaisesti pieniin, yhden samassa tilassa toimivan tiimin alle puolen vuoden pituisiin projekteihin. Sopii myös suuriin, kompleksisiin Menetelmässä oletetaan, että yksittäinen henkilö keskittyy vain tähän projektiin. Sopii hyvin epämääräiset vaatimuksia, kommunikaation puutetta ja vääriä mittareita sisältävien projektien kehitysmenetelmiksi. Englanti suomi (selitystä) VANHAA SANASTOA (vuodelta 2011), tarkista uusin googlaamalla ”Scrum sanasto” Daily Scrum päivän Scrum Scrum Scrum Sprint sprint Sprint Goal sprintin tavoite Sprint Review Meeting sprintin katselmointi(kokous) Sprint Planning Meeting sprintin suunnittelu(kokous) Retrospective retrospektiivi (retropalaveri) Product Burndown Chart tuotteen edistymiskäyrä Sprint Burndown Chart sprintin edistymiskäyrä Sprint Backlog sprintin tehtävälista Release Backlog julkaisun kehitysjono Product Backlog tuotteen kehitysjono Task tehtävä Backlog Item kehitysjonon / tehtävälistan kohta ScrumMaster scrummaster Refactoring refactoring (uudelleenjärjestely) Product Owner tuoteomistaja User Story käyttäjätarina (tuotteen/julkaisun/sprintin kehitysjonon/tehtävälistan kohta (Item of Product/Release/Sprint Backlog), joka on sen verran selkeärajainen, että se pystytään pisteyttämään (vs. Epic)) Scrum Team scrumtiimi (PO+SM+kehitystiimi) Velocity vauhti Sprint Abort keskeytys Time-Box aikaraja Focus Factor nopeuskerroin (ehkä myös vauhtikerroin) Impediment Backlog esteluettelo Impediment este Artifact dokumentti(?) ("tuotos?") Stakeholder sidosryhmä (lähde: (Ingrement toimituserä) Muita termejä: Epic (eepos, epiikki; tuotteen kehitysjonon kohta (Item of Product Backlog), joka on epämääräinen tai suuri kooltaan) Product Visio, tuotteen visio Team, kehitystiimi Capacity (tiimin vauhti jossain määrätyssä sprintissä, huomioi sprintin aikaiset häiriötekijät kuten lomat, tiimiläisten muut työvelvoitteet, tietotekniikkaongelmat jne) Feature (ominaisuus; tuotteen tai julkaisun kehitysjonon kohta (Item of Product/Release Backlog), joka on selkeä ja pieni kooltaan)) Työkokous on voi tapaaminen, jossa sprintin tehtäviä toteutetaan esimerkiksi parityönä. Se voi olla myös sprintin aikana tapahtuva (kehitystiimin/scrummasterin kutsuma) kokous, jossa tarkennetaan sprintin tehtävälistaa (Sprint Backlog) tai vaikka poistetaan esteitä (Impediments) tuoteomistajan kanssa. Item (asiakohta kehitysjonossa tai tehtävälistassa. Esimerkiksi Epic, User Story, Feature, Task == Items) Lähteitä

2 Menetelmälliset periaatteet
Tuotoksena iteraation jälkeen julkaisukelpoinen ohjelma Pieninä palasina (inkrementaalinen) Kierros kierrokselta parempi (iteroiva) Tiivis kommunikaatio ja yhteistyö eri toimijoiden välillä Scrum vs. vaihejako (Youtube-video) Ohjelmistotuote luodaan pala kerrallaan lyhyissä iteraatioissa, ja asiakkaalle pyritään tuottamaan koko ajan arvoa ja niin aikaisin kuin vain suinkin mahdollista. Koska ohjelmisto rakennetaan pienissä pätkissä, tehdään myös kaikkia perinteisten menetelmien aktiviteetteja samanaikaisesti – testaus, suunnittelu ja toteutus tapahtuvat kaikki iteraation sisällä. Uudet moduulit integroidaan jatkuvasti ohjelmakokonaisuuteen.

3 Scrumin vaiheet Product Backlog Tuotteen kehitysjono Sprint Review
Definion of done Valmiin määritelmä Product Backlog Tuotteen kehitysjono Sprint Burndown Chart sprintin edistymiskäyrä Sprint Review Sprintin katselmointi Sprinttikatselmus Sprint Planning Meeting Sprintin suunnittelupalaveri Daily Scrum Päiväpalaveri Vision Visio Sprint Retrospective Sprintin retrospektiivi Sprint Goal Sprintin tavoite Sprint Backlog Sprintin kehitysjono tehtävälista päivä Increment Tuoteversio Toimituserä (asiakkaalle toimitettava kokonaisuus) voi olla inkrementti tai iteraatio Visio on tulevaisuudennäkymä, jonka avulla pyritään luomaan sidosryhmäläisille kuva siitä, millainen tietojärjestelmän tuottamat palvelut ja tuotteet ovat tulevaisuudessa. Visio on jotakin, jonka toimijat haluaa saavuttaa ja joka innostaa heitä. Tämän vuoksi hyvä visio on konkreettinen ja kaikkien helposti ymmärrettävä. Työssä ei ole merkitystä, suuntaa eikä ohjetta ilman visiota. (Kannisto, Salenius & Sigfrids 2005.) Kannisto, P., Salenius, B-M. & Sigfrids, C Johtamisen pakolliset kuviot. Helsinki: Talentum. Sprint (esim.2…4 vkoa) Scrum Team (= PO+SM+DT ) Scrumtiimi Product Owner Tuoteomistaja Scrum Master Scrummaster Development Team Kehitystiimi Chicken Lopetus

4 Roolit Scrum Team, scrumtiimi Development Team, kehitystiimi
Development Team +Scrum Master+ Product Owner Development Team, kehitystiimi Toteuttaa itsellisesti valitsemansa tehtävät Itseorganisoituva ja itseohjautuva Ihannekoko 7+-2 henkilöä Yhteinen vastuu yksilönä, tiimin etu edelle ”omistaa” Sprint Backlogin Scrum Master Hallitsee Scrum-prosessin Puuttuu ajoissa esteisiin ja poistaa ne (24 h) Suojaa kehitystiimiläisiä ulkopuolisilta häiriöiltä Dokumetoi Scrum-prosessia (varmistaa, että Development Team ylläpitää) Ei varsinaista määräysvaltaa kehitystiimiläisiin itse projektin suhteen Product Owner, tuoteomistaja hallitsee tuotteen ja tuottavuuden (liiketoimintanäkökulman) Asiakkaan nimeämä ja edustaja Vastuussa projektin markkina-arvosta ”omistaa” Product Backlogin Päättää viimekädessä sprinttien ja projektin kohtalosta Scrum Team scrumtiimi (tuoteomistaja, scrummaster ja kehitystiimi) Development Team kehitystiimi Ks. Schwaber Development Team eli kehitystiimi (jossain vanhemmissa materiaaleissa käytetty myös käsitettä scrumtiimi) Development Team on eräänlainen "urakkaryhmä”, hyvin kurinalainen Tiimistä löytyy eri alan ammattilaisia, mutta ei rooleja. Jokainen tekee (valintansa mukaan) mitä tahansa, kunnes Sprint Backlogin Items (”Tasks”) on tehty. ei hierarkkinen määrittelee oman vauhtinsa (Velocity) yhteinen vastuu yksilönä toteuttaa sovitut tehtävät Itsenäisiä tiimejä (engl. Team), joiden ihanteellinen koko on noin 7 (plus/miinus 2) henkeä. Tiimi päättää yhdessä kunkin sprintin tavoitteet ja tehtävät, ja vastaa yhdessä siitä, että asetettuihin tavoitteisiin päästään. Tiimit ovat itseohjautuvia ja itseorganisoituvia, ja tiimillä on oikeus itse päättää millaisia työmenetelmiä tiimissä halutaan käyttää. Ryhmän toimintaa verrataan rugby-joukkueeseen, jossa koko ryhmä pyrkii etenemään yksikkönä, heittäen palloa eteen ja taakse. jäsenillä on usein erityistaitoja, kuten ohjelmointi, laadunvarmistus, liiketoiminta-analyysi, arkkitehtuuri, käytettävyyssuunnittelu tai "...kehitystiimin jäsenillä tulee olla kaikki vaadittava tieto, taito ja asenne tuotteen parantamiseen. Kehitystiimin suunnittelijoita, eivät sovi kehitystiimiin. Kaikkien tiimin jäsenten tulee sitoutua sprintin yhteiseen tavoitteeseen, vaikka se vaatisi uusien Nämä yhteiset taidot muuttavat vaatimukset julkaistavaksi tuotteeksi. Henkilöt, jotka kieltäytyvät ohjelmoimasta, koska ovat arkkitehteja tai tietokantasuunnittelu. Lopputuloksen kannalta tärkeimmät taidot ovat ne, joita kaikilla kehitystiimin jäsenillä on, eivät ne mitä heiltä puuttuu. taitojen oppimista tai vanhojen taitojen palauttamista mieleen." (Sutherland J Scrum, 8. Luettavissa Tiimit ovat erilaisiin tilanteisiin sopeutuvaisia, nopeita, itseorganisoituvia ja pysyvät lähes jatkuvassa iteratiivisessa ja inkrementaalisessa liikkeessä. Scrum Master ScrumMaster: varmistaa, että scrumtiimi toimii scrummaisesti ja on tuottoisa. Pitää tiimin liikkeessä. Scrum-mestarilla ei ole ryhmän jäseniin suoraa määräysvaltaa projektin suhteen. Hänen tehtävänsä koostuvat suurelta osin ryhmän työskentelyä haittaavien esteiden (Impediment) poistamisesta ja varmistaa, että ryhmä ylläpitää Scrum-tuotoksiaan (Artifact) ja projektin dokumentaatiota. "hallitsee Scrum-prosessin" Tehtävänä varmistaminen ja seuraaminen, että tiimin jokapäiväinen työskentely on tuottavaa ja sovittuja pelisääntöjä noudatetaan. Hän tarkkailee työn etenemistä, ja jos sprintin tavoitteiden saavuttaminen alkaa näyttää epävarmalta, hän tarttuu tarvittaviin toimiin tilanteen korjaamiseksi. Scrummaster myös suojaa tiimiä ulkomaailman hälyltä - esim. yllättäen saapuvilta työpyynnöiltä - ja tekee kaikkensa turvatakseen tiimilleen työrauhan. Tarkistaa, muuttaa, auttaa scrumtiiimiläisiä. Synkronoi töitä. Aukaisee työn tukoksia tuoteomistajalle sprintin aikana. Mieluummin ehkä enemmän pätevä ja arvostettu projektisihteeri kuin huono(?) projektipäällikkö. Product Owner "hallitsee tuotteen ja tuottavuuden" tekee liiketoimintapäätökset, esim. kokonaisnäkemys työstä Asiakkaan nimeämä Scrum-tiimin ulkorajapinnassa toimii Tuoteomistaja (engl. Product Owner). hyväkyy julkistettavat versiot ja lopputuotteen priorisoi, lisää, poistaa käyttäjätarinat, Hän toimii hankkeessa tuotteen asiakkaiden edustajana, ja hänen tehtäviinsä kuuluu mm. tuotteen vaatimusten määrittely sekä projektin julkaisujen sisällöstä päättäminen ja aikataulutus. Hänen työskentelymenetelmänsä, erityisesti sidosryhmäläisiin päin... Product owner priorisoi Product backlogin ja (tiimin toivomuksesta) myös Sprint Backlogin. Vastuussa projektin "Business-valuesta". Hänen tehtävänsä on huolehtia siitä, että projekti on kannattava (ROI), ja että tiimin työ keskittyy jokaisessa sprintissa niiden vaatimusten toteuttamiseen, jotka ovat hänen nähdäkseen tuotteen onnistumisen kannalta keskeisimpiä. Tuoteomistaja ohjaa sprintin alussa pidettävää suunnittelupalaveria ja hyväksyy edellisen sprintin tuotokset. Product Owner –rooli vaatii panostusta, sitoutumista, mutta myös luottamusta tiimiin. Possut ja Kanat (Pigs and chickens) Possut ovat sitoutuneita ja kanat ovat osallistuvia. Tilaisuus ST SM PO muut sidosryhmäläiset Eri ”seremonioissa” ja muissa scrumtilanteissa osallistujat jaetaan possuihin ja kanoihin: possut saavat puhua ja kanat yleensä vain kuunnella. SP2 SP1 DS pigs pigs (chicken) RS SR

5 Scrum-tapahtumat (Event)
Sprint Planning, sprintin suunnittelu Team, Scrum Master ja Product Owner tapaavat uusien User Storyjen työn alle ottamiseksi Daily Scrum, Päiväpalaveri Development Team ja Scrum Master tapaavat työn esteiden poistamiseksi Sprint Review, Sprintin katselmointi Team esittelee valmiit tuotokset Product Ownerille, joka antaa palautetta tuotoksesta Tarkistetaan, että Product backlog on ok Sprint Retrospective, sprintin retrospektiivi (Scrum) Team kehittelee prosessia (ja tuotetta?) Huomaa, että monet Product Ownerin ja osin myös Scrum Masterin toimet jäävät näiden taphtumien (Event) ulkopuolelle, esimerkiksi visiointi, Refining of Product Backlog tai esteiden poistaminen.

6 Sprint Planning, Sprintin suunnittelu
OSA 1 (Product Backlog tarkistetaan, kuuluisi kai Review-tapahtumaan) Product Owner esittelee päivitetyn Product Backlogin Sovitaan Sprintin päämäärä (Sprint Goal) Kehitystiimi päättää seuraavan sprintin kapasiteettinsa vauhtiinsa (Velocity) perustuen Valitaan seuraavan Sprintin toteutukset Product Backlogin Items (User Stories, Features, Epics) valintakriteerinä Product Ownerin määrittämä järjestys (Order) (liiketoiminnallinen arvo ja riskitaso) kehitystiimi tekee varsinaisen valinnan Suunnittelukokouksen alkuosaan osallistuvat ainakin Product Owner, Scrum Master ja kehitystiimi. Kanat eli esimerkiksi asiakas ja asiantuntijat (mm. nörttipomo) saavat osallistua. OSA 2 Kehitystiimi pisteyttää (0, ½, 1,2,3,5,8,13,20, 40,ääretön,?,kahvikuppi) valitsemansa käyttäjätarinat Scrum Plan Pokerilla Pilkotaan tuotteen kehitysjonosta (Product Backlog) valitut käyttäjätarinat (User Story) ym. kohdat (Item) sopiviksi sprintin kehitysjonon (Sprint Backlog) kohdiksi (Item) eli tehtäviksi (Task). Pilkkoessaan tuotteen kehitysjonon kohtia (PBL Items) SBL-Taskeiksi, pitää ottaa huomioon Scrumtiimin (PO+SM+DT) määrittelemä ”Valmiin” käsite (Definition of Done). Usein ohjelmistokehityksessä, käyttäjätarinan valmiiksi saattamiseen tarvitaan useita vaihejakomallin vaiheita. Jokainen sprintin tehtävälistan kohta tulisi pystyä tekemään saman työpäivän (työrupeama) aikana (yksilö/pari/ryhmätyönä). Tämä tarkoittaa, että tehtäviä (Tasks) pitää olla Sprint Backlogissa riittävästi, esim. 4 hengen tiimi, 3 viikon sprintti ja viikossa 5 työpäivää -> vähintään 4x3x5=60 Taskia. Kehitystiimi miettii menetelmät Kehitystiimi sitoutuu toteuttamaan näin muodostuneen Sprint Backlogin ja se ”lukitaan” Suunnittelukokouksen loppuosaan osallistuu ainakin Scrum Master ja Team. Product Owner tavoitettavissa Suunnittelukokouksella on Time-Box eli ennalta sovittu aikaraja, usein max. 2h/Sprint-viikko Päivitetty Sprintin suunnittelukokouksessa suunnitellaan alkava Sprint-jakso. Tuotteen sidosryhmäläiset ovat (ainakin puhelimitse) tavoitettavissa sprintin suunnittelukokouksen aikana. Tavoitteena on, että sen lopussa olisi julkaisukelpoinen versio tuotteen osasta. Tämä ei kuitenkaan ole Sprintin edellytys. Julkaistavaan tuotteen kehittämiseen voidaan hyvin käyttää useampi sprintti. Jokaisessa Sprintissä tulisi saada valmiiksi ainakin yksi tuotteen kehitysjonon (Product Backlog) asiakohta (Item). Ennen kokousta Product Owner on päivittänyt Product Backlogin. Sprintin suunnittelukokouksen alkuosa (OSA 1) Alkuosassa (max. 1tunti/vkon sprintille) mietitään mitä käyttäjätarinoita valitaan Ssprinttiin ja mikä on Sprint Goal eli sprintin tavoite (esim. “automatisoi asiakastilin muokkaaminen turvallisen transaktiopohjaisen väliohjelmiston kautta.”). Tuoteomistaja esittelee kehitystiimille tuotteen kehitysjonon korkeimmat prioriteetit, jonka jälkeen kehitystiimi ja tuoteomistaja miettivät yhdessä, mitä toiminnallisuutta tuotteen kehitysjonosta valitaan kehitettäväksi seuraavassa Sprintissä. Varsinaisen valinnan tekevät kehitystiimiläiset (eivät muut!) niistä tarinoista, joissa suuri prioriteetti. Sprintissä on tarkoitus tehdä vain niitä asioita, joilla on sillä hetkellä suurin merkitys projektin onnistumisen kannalta. Päätettävät asiat ovat: 1) Sen hetkinen kehitysjono, 2) tavoiteltava tuoteparannus, 3) kehitystiimin kapasiteetti ja kehitystiimin aiempi 4) Velocity eli vauhti. Alkuosaan osallistuvat ainakin Product Owner, Scrum Master ja Team. Muut sidosryhmäläiset ja asiantuntijat ovat tavoitettavissa. Sprintin suunnittelukokouksen loppuosa (OSA 2) (max. 1tunti/vkon sprintille) Kokouksen tarkoituksena on miettiä, miten suunnitellut käytännössä toteutetaan ja varmistetaan, että ne ehditään toteuttaa sovitussa ajassa, muodostetaan Sprint Backlog. Käyttäjätarinat pilkotaan Sprint Backlogiin Task-tehtäviksi niin, että periaatteessa tehtävä ehditään toteuttaa yhden työpäivän aikana. Karkeasti ottaen Sprint Backlogin tehtävien määrä pitäisi olla vähintään tiimin jäsenten lukumäärä Sprintin työpäivillä. Kehitystiimi arvioi pilkottujen käyttäjätarinoiden koon tarinapisteinä (Story Points) esimerkiksi Scrum Plan Poker –korttien avulla. Tarinapisteet kertovat, minkä kokoinen (työläs toteuttaa) kukin Task Teamin mielestä on. Alussa voi eri käyttäjätarinat laittaa suunnilleen suuruusjärjestykseen. Scrum Plan Poker (ks. Myös by Henri L ) Korttien arvoina on eri tarinapisteitä (esim. 0, ½, 1,2,3,5,8,13,20,40,100,?), mitä suurempi pistemäärä sen työläämpi, epämääräisempi ja epävarmempi tehtävä on. Kysymysmerkkiä voidaan käyttää siihen, että pelaaja ei hahmota tehtävän kokoa. Jokainen scrumtiimiläinen valitsee haluamansa pistemäärän ja kortit lyödään pöytään yhtäaikaisesti Jos annetut pistemäärät ovat suuria, kannattaa harkita tarinan edelleen pilkkomista tms. Jos pisteissä suurta hajontaa, erityisesti ääripään pisteet antaneet (mutta myös muut) perustelevat antamansa pisteet. Lyödään uudet pisteet pöytään. Tarinapistemäärästä pitäisi päästä yhteisymmärrykseen ennen kuin jatketaan. Saadut tarinapisteet siirretään Sprint Backlogiin Toteutuksen menetelmät mietitään. Sovitaan sprintin aikaiset työkokoukset (eri asia kuin Daily Scrum), ainakin alustavasti. Huomioita: Sprintin suunnittelu(kokous) kannattaa järjestää muulloin kuin maanantaisin ;-) Yleensä vain noin 60-70% sprintin tehtävälistasta suunnitellaan Sprintin suunnittelukokouksessa, erityisesti silloin, kun sprint on pitkä. Tällöin loput tehtävät jätetään suunniteltaviksi myöhemmin tai niille annetaan suuremmat tarinapisteet ja ne pilkotaan pienempiin tehtäviin myöhemmin sprintin aikana.

7 Daily Scrum, päiväpalaveri
Tavoitteena Kehitystiimiläisten keskinäinen tietoisuus Sprintin tilasta ja työskentelyn synkronointi Työnteon esteiden kertominen Max. 15 min. yleensä seisten Scrum Master kysyy tiimiläisiltä Mitä olet tehnyt edellisen Daily Scrum -kokouksen jälkeen? Mitä aiot tehdä seuraavaan Daily Scrum-kokoukseen mennessä? Mikä on hankaloittanut työtäsi (Impediment, este)? Scrum Master tekee pikapäätöksiä esteiden poistamiseksi Sovitaan tarvittavat tapaamiset (työkokoukset) Muut kuin kehitystiimiläiset ja Scrum Master saavat olla kanoina (äänettöminä osallistujina) mukana. DAILY SCRUM, Schwaber, 32 Chicken pigs, ks. Dia Roolit Ennen Daily Scrumia päivitetään Sprint Backlog ja Sprint Burndown Chart Päiväpalaverin tavoitteena on ryhmän keskinäinen tietoisuus toisten tekemisistä. Mahdollistaa nopean reagoinnin ongelmiin. Tarkoituksena ei ole raportoida Product Ownerille työn edistymisestä vaan synkronoida työskentely, löytää ajoissa pullonkaulat. Yleensä tuoteomistaja ei ole paikalla. Daily scrum on noin viidentoista minuutin (max) pituinen päivittäinen Scrum-kokous. Kokous on aina samaan aikaan ja samassa paikassa. Lisäksi osallistujat seisovat koko tapaamisen ajan. Kokouksissa (max. 2 min/kokous/hlö) kehitystiimin jäsenet vastaavat vuorollaan seuraaviin kysymyksiin: * Mitä olen tehnyt edellisen Scrum-kokouksen jälkeen? * Mitä aion tehdä seuraavaan Scrum-kokoukseen mennessä? * Mikä on hankaloittanut työtäni? -> IMPEDIMENT (esteet) BACKLOG, lista esteistä, jotka SM poistaa 24 tunnin kuluessa. Sovitaan lopuksi tarvittaessa muita tapaamisia (työkokoukset), joissa varsinaisesti ratkaistaan ongelmat tai työstetään projektia. Tarkistetaan, että Sprint Backlog ajan tasalla (mm. Burndown Chart). Lisäksi tarkistetaan, ettei kenelläkään ole kesken enempää kuin kaksi tehtävää (tämä sääntö tulee Kanban-viitekehyksestä, ei suoranaisena vaatimuksena Scrumissa, mutta auttaa tasaamaan työkuormaa) Vapaassa keskustelussa tulevaisuuspaja-menetelmällä priorisoidaan hankaloittavat tekijät a) ratkaistaan ne b) scrum-master ratkaisee ne ulkopuolisten kanssa. Kanat eivät saa puhua (Lue lisää Scrumin rooleista ”chickens and pigs” oppikirjasta. Ei ole tarkoitus raportoida itse tuotetta.

8 Sprint Review, sprintin katselmointi
Esitellään Product Ownerille, asiakkaalle/sidosryhmille työn tulokset Kaikki halukkaat saavat osallistua Vastataan yleisön kysymyksiin Keskitytään tuotteeseen Pyritään helpottamaan toimituserän käyttöönottoa Katselmoidaan vain valmiit (Done) tuotteen osat!! Kerrotaan Sprint Backlogin valmiusaste (mitkä kesken, mikä %) Mietitään jatkotoimenpiteet Tehdään pohjatyö seuraavalle sprintille Product Backlogin päivitystarve (erityisesti kanojen näkökulmasta, jotka nyt saavat poikkeuksellisesti puhua ;-) Arvioidaan tuotteen seuraava julkaisuaika Aikavaraus 1 tunti/vkon sprintti, on noin 2,5% ajasta. Ensisijaisena tarkoituksena on saada selville mitä kehitystiimi on saanut aikaan sovitusta ja antaa palautetta, jotta suunnitelmia (Product Backlog) voidaan kehittää. Sprint Review -tapahtumaan saavat osallistua kaikki asiakkaan sallimat, niin possut (pigs) kuin kanat (chickens). Tämän perusteella mietitään myös jatko, esim. projektin lopettaminen. (Product Owner päättää). Katselmuksessa kerrotaan, mitkä Sprint Backlogin tehtävistä valmiit, mitkä kesken. (Miten tuotteen sisältöön liittyvät ongelmat ratkaistiin?) Esitellään VALMIS työ ja vastataan kysymyksiin. Tutustutaan päivitettyyn tuotteen kehitysjonoon ja arvioidaan (tarkentunut arvio) loppujen sprinttien vauhti (Velocity) ja tuotteen julkaisuaika (tai oikeastaan se, mitä luultavasti saadaan julkaistavaksi varatussa ajassa). Huomaa; lopetuskokousta ei perjantaisin ;-)

9 Retrospective, Retrospektiivi
Analysoidaan ja kehitetään erityisesti prosessia Ks. muistiinpanot Sprintin edistymiskäyrän (Sprint Burndown Chart) analyysi Tarkennettu vauhti (Velocity) eli montako tarinapistettä tiimi pystyi tekemään Seuraavan sprintin vauhti (montako tarinapistettä tiimi lupaa) Product Backlogin päivittäminen (tiimin näkökulma) Mm. palautetaan kesken jääneet tehtävät (jäljellä olevine pisteineen) uudelleen tuotteen kehitysjonoon (ellei tätä jo tehty sprintin katselmoinnissa) Mukana Team, Scrum Master (ja Product Owner) 45 min/1 viikon sprintti Tämä on katsaus menneeseen ja oppiminen. Keskitytään prosessiin. Miten kehitystiimi on työskennellyt yhdessä, mitä apuvälineitä on käytetty, mitä teknistä osaamista hyödynnetty. Mitä hyviä käytänteitä on käytössä. Analysoidaan ongelmakohdat ja muutetaan käytänteitä. Mietitään scrumtiimin kokoonpano (esim. lomat), kokousjärjestelyt, sopivat työkalut, mitä käsitetään termillä valmis tuotos. Mietitään kommunikointimenetelmät ja prosessit, joilla tuotteen kehitysjonosta tuotetaan jotain “valmista”. Sprintin retrospektiivin loppuun mennessä scrumtiimin tulisi tunnistaa ja valita seuraavan sprintin aikana toteutettavat parannukset. Eli valmistautua seuraavan sprintin suunnittelukokoukseen. Keskeneräinen työ lisätään PB:hen kehitysjonon uudeksi kohdaksi: "Keskeneräiset työt". Esimerkiksi, jos 10 pisteen tehtävässä on 6 p. valmista ja 4 p. kesken, lisätään se 4 p. Ominaisuuksiin keskeneräiset työt. ”Keskeneräinen” kumuloituu sprintti kerrallaan. Tarvittaessa joudutaan julkaisuprojektin loppuun lisäämään ns. julkaisusprinttejä, jotta keskeneräiset saadaan valmiiksi. Sprintin edistymiskäyrän analysointi. Retrospektiivien päätökset kirjoitetaan ko. Sprintin milestone-infosivulle (siis dokumentoivat). Kokous vaatii turvallisen toimintaympäristön, jotta scrumtiimiläiset pystyvät aidosti kehittymään eivätkä joudu puolustuskannalle.

10 Artifacts (tuotokset)
Scrum-dokumentit Elävät koko ajan, ei varsinaista historointia Tuotteen kehitysjono (Product Backlog) User Story –kortit/rivit (Item, kohta) (Julkaisun kehitysjono (Release Backlog) ) Sprintin kehitysjono (Sprint Backlog) Edistymiskäyrät (Burndown Chart) Jäljellä olevat käyttäjätarinat/tehtävät Esim. Product Burndown, Release Burndown Chart, Sprint Burndown Chart Välineet ja dokumentit (kesken) ERI Backlog-tyypit ovat samojen asioiden eri tasoja, tarkentuen Product – Release - Sprint. * Seuraavan sprintin kapasiteetti lasketaan edellisen sprintin lopetuspäivänä ja merkataan seuraavan milestonen kuvaukseen. * Sprint backlog ylläpidetään Tracessa milestonella, johon merkataan sprintin lopetuspäivä. * Product backlog ylläpidetään Product backlog -milestonessa. o User storyt (As a [user role], I want to [goal], so I can [reason].) * Tracessa suljettuun tikettiin laitetaan se changeset jossa korjaus on, ja päinvastoin changesetin viestiin laitetaan mihin tikettiin se liittyy. * Käytetään myös keltaisia muistilappuja huoneen seinällä ==========OMA DIA======= PRODUCT BACKLOG (10 % sprintin ajasta PB:n ylläpitoon, tehdään työtä myös ennen suunnittelukokouksen osaa 1, erityisesti korkeamman prioriteetin kohtia tarkistetaan) Backlog työlista on tuotteen/iteraation vaatimus/ominaisuusluettelo Product backlog: prioritized list of desired project outcomes/features Kuvaus, prioriteetti(markkina-arvosta ja riskistä) ja aika/kokoarvio. Kannattaa pitää product backlogin ja sprint backlogin kokoarviointien yksiköt EI-yhteismitallisina, siis erillään. Aika-arvioden antamisesta vastaa scrumtiimi PB-listaa tulee päivittää jatkuvasti ja ylläpitää Tuotteen työlista (engl. product backlog) sisältää kaikki sen hetkiset tuotteelle toteutettavaksi aiotut ominaisuudet käyttäjätarinoina (User story). Käyttäjätarina voi olla epiikka, joka on ominaisuus, jonka kokoa (työmäärää) ei pystytä arvioimaan. SCRUM vaatii valmiita ja toteutuskelpoisia vaatimuksia! Tai sitten kannattaa protoillen selvittää käyttötarinat. Tämä protoilu tehdään irrallaan sprinteistä! USER STORY voi olla 150x100 mm -kortilla, ja tarina kirjoitetaan käyttäjänäkökulmasta, jos vain mahdollista. Kuka tahansa saa lisätä käyttäjätarinoita, mutta Product owner päättää lopullisesti. PO lisää ja poistaa Käyttäjätarinoita projektin aikana. Tuotteen kehittymistä ohjaa markkina-arvo (business value), joten tarinat ilmestyvät ja häviävät niiden markkina-arvojen muuttuessa. Scrumissa tuotteen vaatimukset elävät kehityksen myötä. Työlistassa käyttäjätarinat on priorisoitu tuotteen omistajan toimesta. Listan alkupään (siis tärkeimpien ominaisuuksien) käyttäjätarinoiden työmäärät/koko/kustannukset (?) arvioidaan. Työlistojen hierarkia on yksiulotteinen (priorisointi). Moninkertaisen työn minimoimiseksi vain korkeimman prioriteetin kohdat tulee määritellä yksityiskohtaisesti. Tuotteen kehitysjonon kohdat, joita kehitystiimi toteuttaa seuraavissa sprinteissä, tulee hajottaa riittävän pieniksi ja tarkoiksi, jotta mikä tahansa kohdista ehditään täysin toteuttaa yhden sprintin aikana. Tärkeysnumero >100 ominaisuus aina ekaan versioon ominaisuus mielellään ekaan versioon ominaisuus tarvitaan jossain vaiheessa <25 ominaisuutta ei tarvitse toteuttaa Arvio työpäivinä

11 Product Backlog, tuotteen kehitysjono
Product Backlog on tuotteen sen hetkinen järjestetty (Ordered) ”vaatimuslista” monimutkaisuuspisteineen ”Vaatimukset” eli Product Backlogin kohdat (Item) voivat olla tuotteen ominaisuuksia (feature) käyttäjätarinoita (user story) teemoja (themes) epiikkeja (epic) eli suuria epämääräisiä toiveita , jotka protoiltava toteutuskelpoisiksi Ylläpidetään paljon sprintin ulkopuolella/rinnalla, siis työstetään (Refining, ex. Grooming) koko ajan 10% sprintin ajasta menee kehitysjonon työstöön Ennen Sprintin suunnittelukokousta PO järjestää (Order, ex. Prioritize) tuotteen kehitysjonon Product Owner (PO) omistaa Product Backlogin PRODUCT BACKLOG (10 % sprintin ajasta PB:n ylläpitoon, tehdään työtä myös ennen suunnittelukokouksen osaa 1, erityisesti korkeamman prioriteetin kohtia tarkistetaan) Backlog työlista on tuotteen/iteraation vaatimus/ominaisuusluettelo Product backlog: prioritized list of desired project outcomes/features Kuvaus, prioriteetti(markkina-arvosta ja riskistä) ja aika/kokoarvio. Kannattaa pitää product backlogin ja sprint backlogin kokoarviointien yksiköt EI-yhteismitallisina, siis erillään. Aika-arvioden antamisesta vastaa kehitystiimi PB-listaa tulee päivittää jatkuvasti ja ylläpitää Tuotteen kehitysjono (engl. product backlog) sisältää kaikki sen hetkiset tuotteelle toteutettavaksi aiotut ominaisuudet käyttäjätarinoina (User story). Käyttäjätarina voi olla epiikka, joka on ominaisuus, jonka kokoa/monimutkaisuutta (työmäärää) ei pystytä arvioimaan. SCRUM vaatii valmiita ja toteutuskelpoisia vaatimuksia Tai sitten kannattaa protoillen selvittää käyttötarinat. Tämä protoilu tehdään irrallaan sprinteistä! USER STORY voi olla 150x100 mm -kortilla, ja tarina kirjoitetaan käyttäjänäkökulmasta, jos vain mahdollista. Kuka tahansa saa lisätä käyttäjätarinoita, mutta Product owner päättää lopullisesti. PO lisää ja poistaa Käyttäjätarinoita projektin aikana. Tuotteen kehittymistä ohjaa markkina-arvo (business value), joten tarinat ilmestyvät ja häviävät niiden markkina-arvojen muuttuessa. Scrumissa tuotteen vaatimukset elävät kehityksen myötä. Työlistassa käyttäjätarinat on priorisoitu tuotteen omistajan toimesta. Listan alkupään (siis tärkeimpien ominaisuuksien) käyttäjätarinoiden työmäärät/koko/kustannukset (?) arvioidaan. Työlistojen hierarkia on yksiulotteinen (priorisointi). Moninkertaisen työn minimoimiseksi vain korkeimman prioriteetin kohdat tulee määritellä yksityiskohtaisesti. Tuotteen kehitysjonon kohdat, joita kehitystiimi toteuttaa seuraavissa sprinteissä, tulee hajottaa riittävän pieniksi ja tarkoiksi, jotta mikä tahansa kohdista ehditään täysin toteuttaa yhden sprintin aikana. Tärkeysnumero, esimerkiksi >100 ominaisuus aina ekaan versioon ominaisuus mielellään ekaan versioon ominaisuus tarvitaan jossain vaiheessa <25 ominaisuutta ei tarvitse toteuttaa Arvio koosta työpäivinäpisteinä

12 …User Story, käyttäjätarina
"Käyttäjänä haluan toiminnallisuuden xxx, koska saavutamme sillä hyödyn zzz." ”As a [role], I want to [goal/feature/…], so I can [reason].” Vastaa kysymyksiin: Kuka haluaa mitä ja miksi tämä asia on tärkeä. Usein kirjoitetaan 150x100 kokoiselle kortille Id, käyttäjätarina, (kirjoittaja), pvm, (tarinapisteet) Käyttäjätarinat kootaan Product Backlogiin jatkojalostusta varten KÄYTTÄJÄTARINAssa on dokumentoitu asiakkaan haluamat ominaisuudet (vaatimukset) eri käyttäjäryhmien näkökulmista. KÄYTTÄJÄTARINA on muotoa kuka haluaa, mitä haluaa, miksi haluaa. (Käyttäjätarinan poistuessa, voi poistamisesta tehdä käyttäjätarina. Näin hoidettaisiin historiallinen jäljitettävyys, jota ei ortodoksisessa scrummista kylläkään arvosteta.) Product Owner omistaa kehitysjonon, jossa käyttäjätarinat ja niistä johdetut ominaisuudet ovat, mutta tiimiläiset konsultoivat. Eli käyttäjätarinan kautta tiimiläiset pyrkivät ymmärtämään asiakkaan todelliset tarpeet ja muuntamaan ne halutuiksi kohdiksi (Item) Sprint Backlogin. USER STORY voi olla 150x100 mm -kortilla, ja tarina kirjoitetaan käyttäjän näkökulmasta, jos vain mahdollista.

13 Sprint Backlog, sprintin kehitysjono, esimerkkejä
Vähennä tehtäviä Pyydä lisää PO:lta käyttäjätarinoita Kuvio. Sprint Backlog (SBL) seinätauluna (mukana edistymiskäyrä) Sprint Backlogin (SBL) kohtia (Item) nimitetään myös tehtäviksi (Task). Tuotteen kehitysjonon (PBL) kohta (Item) pilkotaan pieniksi (max. työpäivän pituisiksi) tehtäviksi (Task). Ei- pilkotut User stories US# T# Tehtävä pt Tila Tekijät #1 .1 käyttöliittymö 2 Done TJ, RR .2 määrittelykuvastoon 3 Ongoing RR .3 testaus 8 #2 DB-koodaus Suunnittelukuvaston päivit. 1 Merkitse myös sprintin ScrumMaster ja Goal Huom. US-korttiin merkitään myös Scrumtiimin kanssa sovittu (Definition-of Done) Videosta poiketen toteutuksessamme pyritään välttämään tehtävien (Task) turhaan omimista. Kehitystiimin (Development Team) jäsen voisi varata tehtäviä esimerkiksi puoleksi viikoksi. Työtuntien sijasta voidaan tehtävät arvioida myös tehtäväpisteinä (Task Point). Tehtäväpisteet ovat tällöin tarinapisteiden (Story Point) murto-osia. Koska kehitystiimi omistaa Sprint Backlogin, vain sillä (ja Scrum Masterilla) on oikeus koskea tai muuttaa tehtävälistaa sprintin aikana. Usein tämä kuitenkin tehdään tuoteomistajan kanssa vuorovaikutuksessa, sillä koko scrumtiimin (siis myös tuoteomistajan) on oltava yhtä mieltä eri käyttäjätarinoiden (User Story) valmiin määrittelystä (Definition of Done). Video. Seinätaulu-SBL:n käyttö ks, muistiinpanot Kuvio. Sprint Backlog (SBL) Excel-tauluna

14 Task Tehtäväkortti, esimerkki (mukaellen Anne Valsta)
User story ID _____ Task ID ____ Sprintti _____ Tehtävä Pisteet__________ ______________________________________________ Menetelmät ____________________________________ ________________________________________ ________________________________________ DoD _______________________________________ Huom. ________________________________________ Tekijä ______________ Valmis _____________ Toteutunut työmäärä ______pt/h Sprint Backlog (sprintin tehtävälista) voi koostua myös kasasta Tehtäväkortteja ict2tn007 - Anne Valsta

15 Burndown Chart edistymiskäyrä
Julkaisun edistymiskäyrä velocity 20 pt/sprint kokemuksesta edellisistä sprinteistä sum_pt 106 pt sum/release valittujen käyttäjätarinoiden tarinapisteet yhteensä sprints 6 roundup(sum_pt/velocity) sprint est(pt) real(pt) capasity 1 86 95 2 66 64 3 46 45 4 26 28 5 -14 Sprint Burndown Chart Release Burndown Chart Product Burndown Chart tuotteen edistymiskäyrä "Mikäli kehitystiimi havaitsee sitoutuneensa toimittamaan liian paljon, se keskustelee tuoteomistajan kanssa poistaakseen tai keventääkseen sprinttiin valittuja vaatimuksia. Jos taas kehitystiimillä on ylimääräistä aikaa, se valitsee tuoteomistajan kanssa tuotteen kehitysjonosta lisää toteutettavaa." (Sutherland J Scrum, 10. Luettavissa Tuotteen edistymiskäyränä voidaan käyttää pylväsdiagrammia, jossa alun perin mukana olleet käyttäjätarinoiden pisteiden summa on positiivisena pylväänä ja uudet käyttäjätarinat lisätään sprintin kohdalle negatiivisena pylväänä. Näin on helpompi hahmottaa aito edistyminen, katso kuva muistiinpanonäkymässä. Create a basic Burndown Chart in Excel –youtube Pystyakselina voidaan käyttää pokeripisteitä (ja/tai työtunteja ) Katso myös ”Is this your burn down chart?” .

16 Kehitystiimin vauhti (Velocity)
Product Backlogista kehitystiimi valitsee seuraavaan sprinttiin suurin piirtein saman tarinapistemäärän kuin ehtivät tehdä edellisessä sprintissä. Tulevan sprintin vauhtia laskettaessa otetaan huomioon kehitystiimin mahdolliset sitoutumisen vaihtelut (lomat, tiimiläisten muut työt, atk-ongelmat jne.) Tätä pistemäärää per sprintti kutsutaan kehitystiimin vauhdiksi (Velocity) eli tarinapistettä per sprintti. Schwaber K. The enterprise and scrum s.39 Vauhti on joukkueen kyky muuttaa vaatimukset toimituseräksi määrätyssä ajassa. Yleensä vauhti kasvaa vähitellen, parempien kehitystyökalujen, käytäntöjen ja paremman tiimityöskentelyn myötä. Focus Factor on jonkinlainen toleranssikerroin eli tyhjäkäyntikerroin… Jos mitään erityistä ei odotettavissa kertoimena käytetään 0,7. Esimerkki: Tarinapiste on jotain yhden miestyöpäivän verran Sprintin pituus on 2 viikkoa Scumtiimissä 6 henkilöä Työpäivässä on käytettävissä noin 7 tuntia Focus factor on kokemuksellisesti tälle tiimille 0,7 Sprintin vauhti (Velocity) olisi tällöin tälle scrmtiimille ~0,7*2vko*5pt/hlövko*6 hlö/tiimi=42pt/tiimi

17 (0. Sprint) Ns. pikasprintti, jossa ”harjoitellaan”
Pikasprintin avulla saadaan myös tietoa kehitystiimin vauhdiksi (Velocity) Ohjelmistotuotannon pikasprintti, esim. 1) tiistaina lopetus (sprint rewiev ja retro) ja uuden sprintin aloitus (suunnittelu osa1 ja osa2) 2) ke armotonta puserrusta 3) to armotonta puserrusta

18 Aloita! luo visio (jokainen kirjoittaa oman visionsa tuotteesta, pareittain jne)-> visio jätetään luokan seinälle kirjoita käyttäjätarinat -> PBL-seinälle tai Exceliin priorisoi käyttäjätarinat markkina-arvon ja riskitason mukaan (Product owner eli tuoteomistaja) määritä tarinan koko (pisteytä) täydennä/uudelleenjärjestä PBL-seinää/Exceliä luo tarvittaessa RB (julkaisun kehitysjono) suunnittele sprintin SBL (alussa ehkä nollasprintti ja lyhyitä sprinttejä seinätauluna) aloita sprintti Joka sprintin tavoite # Toimita säännöllisesti jotain # Varmista, että toimitat korkeimman prioriteetin asiat (ja siis sopeudut nopeasti muutoksiin) # Pyri parempaan jokaisessa iteraatiossa/julkaisussa

19 (Testausvetoinen scrum)
Yksikkötestit Versiotestit Käyttäjätarinoiden hyväksymistestit Automatisoidut testit Testien dokumentointi Ei tässä toteutuksessa Testivetoisessa ohjelmistokehityksessä, sovituilla testeillä määritellään ohjelman toimivuus. Testit tehdään yksikkötesteistä - versiotesteihin ja käyttäjätarinoiden hyväksymistesteihin. Automaattiset testit! ja niiden dokumentointi? Test

20 (Vaatimusten jäljitettävyys)
Ei kuulu Scrum-ajatteluun (Ei tämän toteutuksen tenttivaatimuksena) JÄLJITETTÄVYYS (traceable) "Vaatimusten" Haluttujen ominaisuuksien jäljitettävyys. Monesti Scrumissa hylätty, koska tuotos katsotaan tärkeämmäksi kuin syy-historia. Voidaan halutessa historioida backlogien eri versioina, vaikkapa valokuuvamalla kunkin päivän työlista. Myös testivetoisen ohjelmistokehityksen avulla saattaa syntyä jäljitettävyyttä palveleva dokumentointi. Todellisuudessa dokumentointi tulee pitää riittävän vähäisenä. Backlogien yksiselitteinen priorisointityyli hävittää hierarkisen vaatimusmäärittelyn jäljitettävyyden. Siksi ehkä olisi hyvä pilkottaessa alkuperäinen Product-backlogin käyttäjätarina olisi jäljitettävissä. Dean Leffingwell ehdottaa käyttäjätarina hierarkiaksi: invest themes - epics - features - stories - tasks. Tällöin siis iteraatioiden työlista koostuisi tarinoista, jotka pilkotaan konkreettisijksi tehtäviksi. Schwaberin mallissa puolestaan on useita priorisoituja työlistoja. Jokaiselle työlistalle on oma tiiminsä.

21 LIITE. Vaihejakomalli liittyy Scrum-käsitteeseen Definition-of-Done eli jokaisen User Story pilkotaan ainakin näiden vaiheiden mukaisiksi Taskeiksi (Ns. vesiputousmalli) Esitutkimus, nykytilanteen kartoitus, projektin tarve, kannattavuusvertailut, korvaavat kehitysehdotukset Määrittely ja kuvaus toiminnan kuvaus tietosisältö rajapinnat(käyttäjät) vaatimukset toiminnalle Arkkitehtuuri infrastruktuuri tietovarastot Tietoliikenne suojaukset, varmistukset Tekninen suunnittelu määrittelyn tarkennus ohjelmiston suunnittelu Tekninen toteutus hankinnat ohjelmointi dokumentointi Testaus Koulutus Käyttöönotto kertarysäyksellä Ylläpito Poisto Ks. Pohjonen 2002, 40