Scrum Commitment sitoutuminen Focus keskittyminen Openness lpinkyvyys Respect

Scrum Commitment (sitoutuminen) Focus (keskittyminen) Openness (läpinäkyvyys) Respect (kunnioitus) Courage (Rohkeus)

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)

Scrumin vaiheet Definion of done Valmiin määritelmä Product Backlog Tuotteen kehitysjono Vision Visio Sprint Burndown Chart sprintin edistymiskäyrä Sprint Planning Meeting Sprintin suunnittelupalaveri Daily Scrum Päiväpalaveri Sprint Goal Sprintin tavoite Sprint Review Sprintin katselmointi Sprinttikatselmus Sprint Retrospective Sprintin retrospektiivi Sprint Backlog Sprintin kehitysjono päivä tehtävälista Sprint (esim. 2… 4 vkoa) Increment Tuoteversio Scrum Team (= PO+SM+DT ) Scrumtiimi Chicken Product Owner Tuoteomistaja Scrum Master Scrummaster Development Team Kehitystiimi Lopetus

• Scrum Team, scrumtiimi Roolit – 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-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? )

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 4 x 3 x 5=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. 2 h/Sprint-viikko

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.

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

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)

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

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

…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 150 x 100 kokoiselle kortille – Id, käyttäjätarina, (kirjoittaja), pvm, (tarinapisteet) • Käyttäjätarinat kootaan Product Backlogiin jatkojalostusta varten

Sprint Backlog, sprintin kehitysjono, esimerkkejä Sprint Backlogin (SBL) kohtia (Item) nimitetään myös tehtäviksi (Task). Vähennä tehtäviä Pyydä lisää PO: lta käyttäjätarinoita Tuotteen kehitysjonon (PBL) kohta (Item) pilkotaan pieniksi (max. työpäivän pituisiksi) tehtäviksi (Task). Ei- pilkotut User stories Kuvio. Sprint Backlog (SBL) seinätauluna (mukana edistymiskäyrä) US # T# Tehtävä pt #1 . 1 käyttöliittymö 2 Done TJ, RR #1 . 2 määrittelykuv astoon 3 Ongoing RR #1 . 3 testaus 8 Ongoing RR #2 . 1 DB-koodaus 3 #2 . 2 Suunnitteluku vaston päivit. 1 Ongoing Kuvio. Sprint Backlog (SBL) Excel-tauluna Tila Tekijät RR Merkitse myös sprintin Scrum. Master ja Goal Huom. US-korttiin merkitään myös Scrumtiimin kanssa sovittu (Definition-of Done) Video. Seinätaulu-SBL: n käyttö ks, muistiinpanot 13

Task Tehtäväkortti, esimerkki (mukaellen Anne Valsta) User story ID _____ Task ID ____ Sprintti _____ Tehtävä Pisteet_________________________________________ Menetelmät ________________________________________ Do. D ____________________ Huom. ____________________ Tekijä _______ Valmis _______ Toteutunut työmäärä ______pt/h 28. 8. 2010 ict 2 tn 007 - Anne Valsta 14

Burndown Chart edistymiskäyrä Julkaisun edistymiskäyrä velocity 20 pt/sprint sum_pt 106 pt sprints 6 sprint est(pt) real(pt) 0 velocity kokemuksesta edellisistä sprinteistä sum/release valittujen käyttäjätarinoiden tarinapisteet yhteensä roundup(sum_pt/velocity) capasity 106 1 86 95 2 66 64 3 46 45 4 26 28 5 6 120 100 80 60 est(pt) 6 40 real(pt) -14 20 0 -20 1 2 3 4 5 6 7 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? ”.

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.

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

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