Tämä HTML-versio Scrum Guidesta on suora portti marraskuun 2020 versiolle, joka on saatavilla Pdfheressä.

Scrum-oppaan tarkoitus

kehitimme Scrumin 1990-luvun alussa. kirjoitimme ensimmäisen version theScrum-oppaasta vuonna 2010 auttaaksemme ihmisiä ympäri maailmaa ymmärtämään Scrumia. Olemme kehittäneet oppaan siitä lähtien pienillä, toimivilla päivityksillä.Yhdessä seisomme sen takana.

Scrum-opas sisältää Scrumin määritelmän. Jokainen kehyksen osa palvelee tiettyä tarkoitusta, joka on välttämätön Scrumin kokonaisarvolle ja tuloksille. Scrumin ydinsuunnittelun tai ideoiden muuttaminen, elementtien jättäminen pois tai Scrumin sääntöjen noudattamatta, peittää ongelmia ja rajoittaa Scrumin hyötyjä, mahdollisesti jopa hyödyttömäksi.

Seuraamme Scrumin kasvavaa käyttöä alati kasvavassa monimutkaisessa maailmassa.Olemme nöyriä, kun Scrum on otettu käyttöön monilla aloilla, joilla on erittäin monimutkainen työ, ohjelmistotuotekehityksen lisäksi, jossa scrumilla on juurensa. Scrumin käytön levitessä Kehittäjät,tutkijat, analyytikot, tutkijat ja muut asiantuntijat tekevät työn. Käytämme Scrumissa sanaa ”Kehittäjät”ei sulkemaan pois, vaan yksinkertaistamaan. Jos saat arvoa Scrumista, ota itsesi mukaan.

Scrumia käytettäessä voidaan löytää, soveltaa ja toteuttaa malleja, prosesseja ja oivalluksia, jotka sopivat tässä dokumentissa kuvattuun viitekehykseen. Niiden kuvaus ylittää Scrum-oppaan tarkoituksen, koska ne ovat kontekstisensitiivisiä ja eroavat suuresti Scrum-käyttötarkoitusten välillä.Tällaiset Scrum-kehyksessä käytettävät taktiikat vaihtelevat suuresti ja niitä kuvaillaan muualla.

Scrum määritelmä

Scrum on kevyt kehys, joka auttaa ihmisiä, tiimejä ja organisaatioita tuottamaan arvoa mukautuvien ratkaisujen avulla monimutkaisiin ongelmiin.

pähkinänkuoressa Scrum vaatii Scrum Masterin vaalimaan ympäristöä:

1. tuoteomistaja tilaa monimutkaisen ongelman työn Tuotelokiin.

2. Scrum-tiimi muuttaa teoksen valinnan Arvonnousuksi sprintin aikana.

3. Scrum-tiimi sidosryhmineen tarkastaa tulokset ja sopeutuu seuraavaan sprinttiin.

toista

Scrum on yksinkertainen. Kokeile sitä sellaisenaan ja selvitä, auttavatko sen filosofia,teoria ja rakenne tavoitteiden saavuttamisessa ja arvon luomisessa. Scrumkehys on tarkoituksellisesti epätäydellinen, vain määrittelemällä osat, joita tarvitaan Scrum-teorian toteuttamiseen. Scrum perustuu sitä käyttävien ihmisten kollektiiviseen älykkyyteen. Sen sijaan, että ihmisille annetaantieteelliset ohjeet, Scrumin säännöt ohjaavat heidän suhteitaan ja interactions.

kehyksessä voidaan käyttää erilaisia prosesseja, tekniikoita ja menetelmiä. Scrum kiertää olemassa olevia käytäntöjä tai tekee niistä välttämättömiä. Scrum tekee näkyväksi nykyisen johtamisen, ympäristön ja työtekniikoiden suhteellisen tehokkuuden, jotta parannuksia voidaan tehdä.

Scrum-teoria

Scrum perustuu empirismiin ja lean-ajatteluun. Empirismi väittää, että tieto tulee kokemuksesta ja päätösten tekemisestä havaitun perusteella. Lean-ajattelu vähentää hävikkiä ja keskittyy olennaiseen.

Scrum käyttää iteratiivista, inkrementaalista lähestymistapaa optimoidakseen ennustettavuuden ja kontrolloidakseen riskejä. Scrum työllistää ihmisryhmiä, joilla on yhdessä kaikki taidot ja asiantuntemus tehdä työtä ja jakaa tai hankkia tarvittavat taidot.

Scrum yhdistää neljä muodollista tapahtumaa tarkastus-ja mukautustapahtumaan sisältyvässä lajissa, sprintissä. Nämä tapahtumat toimivat, koska ne toteuttavat empiiriset Scrum-pilarit läpinäkyvyydestä, tarkastuksesta ja sopeutumisesta.

avoimuus

emergentin prosessin ja työn tulee näkyä sekä työtä tekeville että työtä vastaanottaville. Scrumilla tärkeät päätökset perustuvat sen kolmen formaaliartifikaatin koettuun tilaan. Artefaktit, joiden läpinäkyvyys on vähäistä, voivat johtaa arvoa alentaviin ja riskejä lisääviin päätöksiin.

läpinäkyvyys mahdollistaa tarkastuksen. Tarkastus ilman avoimuutta onjohtavaa ja tuhlailevaa.

tarkastus

Scrum-artefakteja ja edistymistä kohti sovittuja tavoitteita on seurattava usein ja uutterasti mahdollisten ei-toivottujen vaarojen tai ongelmien havaitsemiseksi. Apuna tarkastuksessa Scrum tarjoaa kadenssia viiden tapahtumansa muodossa.

tarkastus mahdollistaa sopeutumisen. Tarkastusta ilman mukautusta pidetään turhana. Scrum-tapahtumat on suunniteltu herättämään muutosta.

Mukauttaminen

Jos jokin prosessin osa poikkeaa hyväksyttävien rajojen ulkopuolella tai jos tuloksena olevaa tuotetta ei voida hyväksyä, on sovellettava prosessia tai valmistettavia materiaaleja mukautettava. Säätö on tehtävä mahdollisimman pian mahdollisten poikkeamien minimoimiseksi.

sopeutuminen vaikeutuu, kun mukana olevat ihmiset eivät ole kyvykkäitä tai omatoimisia. Scrum-ryhmän odotetaan mukauttavan momentit oppii mitään uutta tarkastuksella.

Scrum-arvot

Scrumin onnistunut käyttö riippuu siitä, että ihmiset tulevat taitavammiksi viiden arvon elämisessä:

sitoutuminen, keskittyminen, avoimuus, Kunnioitus ja rohkeus

Scrum-tiimi sitoutuu saavuttamaan tavoitteensa ja tukemaan toisiaan. He keskittyvät ensisijaisesti Pyrinnön työhön, jotta nämä tavoitteet voidaan saavuttaa parhaalla mahdollisella tavalla. Scrum-tiimi ja sen sidosryhmät ovat avoimia työstä ja haasteista. Scrum-tiimin jäsenet kunnioittavat toisiaan kyvykkäinä, itsenäisinä ihmisinä, ja sellaisina he pitävät ihmisiä, joiden kanssa he työskentelevät. Scrum-Joukkueenjäsenillä on rohkeutta tehdä oikein, työstää vaikeita ongelmia.

nämä arvot antavat suuntaa Scrum-tiimille heidän työnsä,toimintansa ja käyttäytymisensä suhteen. Tehdyillä päätöksillä, toteutetuilla toimenpiteillä ja Scrumin käyttötavoilla pitäisi vahvistaa näitä arvoja, ei vähentää niitä tai heikentää niitä. Scrum – tiimin jäsenet oppivat ja tutkivat arvoja, kun he työskentelevät Scrum-tapahtumien ja-esineiden parissa. Kun nämä arvot ovat Scrum-tiimin ja heidän työtovereidensa ruumiillistuma, avoimuuden, tarkastamisen ja sopeutumisen empiiriset pilarit tulevat elämää rakentavaan luottamukseen.

Scrum Team

Scrumin perusyksikkö on pieni ryhmä ihmisiä, Scrum-joukkue.Scrum-tiimi koostuu yhdestä Scrum Masterista, yhdestä Tuoteomistajasta ja kehittäjistä. Scrum-joukkueessa ei ole aliryhmiä tai hierarchies.It on yhtenäinen yksikkö ammattilaisia keskittynyt yhteen tavoitteeseen kerrallaan, Tuotteen tavoite.

Scrum-joukkueet ovat poikkitoiminnallisia, eli Jäsenillä on kaikki arvokisat, joita tarvitaan jokaisen sprintin tuottamiseen. He ovat myös itsejohtavia, eli he päättävät sisäisesti, kuka tekee mitä, milloin ja miten.

Scrum-joukkue on riittävän pieni pysyäkseen ketteränä ja riittävän suuri täydentämään merkittävää työtä sprintissä, tyypillisesti 10 tai vähemmän people.In olemme huomanneet, että pienemmät tiimit kommunikoivat paremmin ja ovat tuottavampia. Jos Scrum-tiimit kasvavat liian suuriksi, niiden tulisi harkita järjestäytymistä useiksi yhtenäisiksi Scrum-Tiimeiksi, joista jokainen keskittyy samaan tuotteeseen. Siksi niillä pitäisi olla sama Tuotteen tavoite,Tuotekanta ja tuotteen omistaja.

Scrum-tiimi vastaa kaikesta tuotteeseen liittyvästä toiminnasta sidosryhmien yhteistyöstä, todentamisesta, kunnossapidosta, käytöstä,kokeiluista, tutkimuksesta ja kehityksestä sekä kaikesta muusta, mitä mahdollisesti tarvitaan. Ne ovat jäsennelty ja valtuutettu organisaatiojohtaa omaa työtään. Työskentely sprinteissä kestävällä vauhdilla parantaa Scrum-tiimin keskittymistä ja johdonmukaisuutta.

koko Scrum-tiimi on vastuussa arvokkaan, hyödyllisen lisäyksen luomisesta jokaisella Sprintillä. Scrum määrittelee Scrum-tiimissä kolme erityistä tiliä: Kehittäjät, tuotteen omistaja ja ScrumMaster.

Developers

Developers ovat Scrum-tiimin ihmisiä, jotka ovat sitoutuneet luomaan jokaisen sprintin käyttökelpoisen lisäyksen minkä tahansa osa-alueen.

kehittäjien tarvitsemat erityistaidot ovat usein laaja-alaisia ja tahdonvoimaisia työn saralla. Kehittäjät voivat kuitenkin aina:

• luoda suunnitelman Sprinttihiihdolle, Sprinttihiihdolle;

valaa laatua noudattamalla Done-määritelmää;

• mukauttavat suunnitelmaansa joka päivä kohti Sprinttitavoitetta; ja,

• pitävät toisiaan vastuullisina ammattilaisina.

Product Owner

tuotteen omistaja on vastuussa Scrum-tiimin työn tuloksena syntyvän tuotteen arvon maksimoinnista. Se, miten tämä tapahtuu, voi vaihdella suuresti organisaatioissa, Scrum-tiimeissä ja yksilöissä.

tuotteen omistaja on myös vastuussa tuotteiden tehokkaasta Takalogmanagementista, johon kuuluu:

• Tuotteen tavoitteen kehittäminen ja yksiselitteinen tiedottaminen;

• tuotteiden Takalokerokohtien luominen ja selkeä viestiminen;

tilaamassa Tuotekannatusta; ja

• varmistamassa, että Tuotekanta on läpinäkyvä, näkyvä ja ymmärrettävä.

tuotteen omistaja voi tehdä edellä mainitun työn tai siirtää vastuun muille. Siitä huolimatta tuotteen omistaja on edelleen tilitettävissä.

menestyäkseen koko organisaation on kunnioitettava päätöksiään. Nämä päätökset näkyvät tuotekannan sisällössä ja tilauksessa sekä tulostuskatselmuksen tarkastettavana lisäyksenä.

tuotteen omistaja on yksi henkilö, ei komitea. Tuotteen omistaja voi edustaa monien sidosryhmien tarpeita Tuotekannassa. Ne, jotka haluavat muuttaa Tuotekantaa, voivat tehdä sen yrittämällä vakuuttaa tuotteen omistajan.

Scrum Master

Scrum Master on vastuussa Scrumin perustamisesta theScrum-oppaan määritelmän mukaisesti. He tekevät tämän auttamalla kaikkia ymmärtämään Scrumin teoriaa ja käytäntöä, sekä Scrumin tiimissä että organisaatiossa.

Scrum-mestari on vastuussa Scrum-tiimin tehokkuudesta. He tekevät tämän antamalla Scrum-tiimille mahdollisuuden parantaa käytäntöjään.

Scrum-mestarit ovat todellisia johtajia, jotka palvelevat Scrum-tiimiä ja suurorganisaatiota.

Scrum-mestari palvelee Scrum-tiimiä useilla tavoilla, mm.:

• valmentaa tiimin jäseniä itsehallinnassa ja risteytystoiminnallisuudessa;

auttaa Scrum-tiimiä keskittymään Suuriarvoisten lisäyksien luomiseen, jotka täyttävät Done-määritelmän;

aiheuttaen Scrum-tiimin etenemisen esteiden poistamisen;ja,

• p> varmistaa, että kaikki Scrum-tapahtumat tapahtuvat ja ovat positiivisia, tuottavia ja pysyvät aikalaatikon sisällä.

Scrum Master palvelee Tuotteen omistajaa monin tavoin, mukaan lukien:

• auttaa löytämään tekniikoita tehokkaaseen Tuotetavoitteen määrittelyyn ja tuotekannan hallintaan;

auttaa Scrum-tiimiä ymmärtämään selkeiden ja tiiviiden Tuotekatkosten tarpeen;

• auttaa luomaan empiiristä tuotesuunnittelua kompleksisen ympäristön tarpeisiin; ja,

  li>

• helpottaa sidosryhmien yhteistyötä tarpeen mukaan.

Scrum-mestari palvelee organisaatiota monin tavoin, mm.:

johtaa, kouluttaa ja valmentaa organisaatiota sen Scrumadoptiossa;

suunnittelee ja neuvoo Scrum-toteutuksia organisaatiossa;

• auttaa työntekijöitä ja sidosryhmiä ymmärtämään ja toteuttamaan empiiristä lähestymistapaa monimutkaiseen työhön; ja

• poistamalla esteitä sidosryhmien ja Scrum-tiimien väliltä.

Scrum Events

sprintti on Kontinen kaikissa muissa tapahtumissa. Jokainen tapahtuma Scrumissa on muodollinen mahdollisuus tarkastaa ja mukauttaa Scrum-esineitä. Nämä tapahtumat on suunniteltu erityisesti tarvittavan avoimuuden mahdollistamiseksi. Jos tapahtumia ei toteuteta määrätyllä tavalla, menetetäänhuomautus-ja sopeutumismahdollisuudet. Tapahtumia käytetään Scrumissa luomaan säännöllisyyttä ja minimoimaan kokousten tarve, jota ei ole määritelty Scrumissa.

optimaalisesti kaikki tapahtumat pidetään samaan aikaan ja paikassa monimutkaisuuden vähentämiseksi.

sprintti

sprintit ovat Scrumin sykettä, jossa ideat muuttuvat arvoksi.

ne ovat enintään kuukauden pituisia tapahtumia johdonmukaisuuden luomiseksi.Uusi sprintti alkaa heti edellisen sprintin päätyttyä.

kaikki Tuotetavoitteen saavuttamiseksi tarvittava työ, mukaan lukien Sprinttisuunnittelu, Daily Scrums, Sprint Review ja Sprint Retrospective, tapahtuu sprinteissä.

sprintin aikana:

• ei tehdä muutoksia, jotka vaarantaisivat Sprinttitavoitteen;

laatu ei heikkene;

Tuotekantaa tarkennetaan tarpeen mukaan, ja

• soveltamisalaa voidaan tarkentaa ja neuvotella uudelleen tuotteen omistajan kanssa sitä mukaa kuin saadaan tietää.

sprintit mahdollistavat ennustettavuuden varmistamalla, että tuotekehitys tarkastetaan ja mukautetaan vähintään joka kalenterikuukausi. Kun asprintin horisontti on liian pitkä, Sprinttitavoite voi muuttua pätemättömäksi, monimutkaisuus voi nousta ja riski kasvaa. Lyhyempiäpyrähdyksiä voidaan käyttää, jotta saadaan aikaan enemmän oppimissyklejä ja kustannus-jatehokkuusriski voidaan rajoittaa lyhyempään aikatauluun. Jokainen sprintti voidaan pitää lyhythankkeena.

edistymisen ennustamiseksi on olemassa erilaisia käytäntöjä, kuten loppuunpalamisia, loppuunpalamisia tai kumulatiivisia virtoja. Vaikka ne osoittautuvat hyödyllisiksi, ne eivät korvaa empirismin tärkeyttä. Monimutkaisissa ympäristöissä ei tiedetä, mitä tapahtuu. Vain sitä, mitä on jo tapahtunut, voidaan käyttää tulevaisuuteen suuntautuvaan päätöksentekoon.

sprintti voidaan perua, jos Sprinttitavoite vanhentuu. Vain tuotteen omistajalla on valtuudet perua sprintti.

Sprinttisuunnittelu

Sprinttisuunnittelu aloittaa Sprintin laatimalla sprinttiä varten tehtävän työn. Tuloksena oleva suunnitelma syntyy koko Scrum-tiimin yhteisellä työllä.

tuoteomistaja varmistaa, että osallistujat ovat valmiita keskustelemaan tärkeimmistä Tuotekannatuksista ja siitä, miten he kartoittavat Tuotetavoitteen. Scrum-tiimi voi myös kutsua muita ihmisiä osallistumaan Sprintplanningiin antamaan neuvoja.

Sprinttisuunnittelussa käsitellään seuraavia aiheita:

aihe yksi: miksi tämä sprintti on arvokas?

tuoteomistaja ehdottaa, miten tuote voisi nostaa arvoaan ja tehoaan nykyisessä pyrähdyksessä. Tämän jälkeen koko Scrum-tiimi tekee yhteistyötä Sprinttitavoitteen määrittelemiseksi, mikä viestii siitä, miksi sprintti on arvokas sidosryhmille. Sprinttitavoite on viimeisteltävä ennen sprintin suunnittelun päättymistä.

aihe kaksi: mitä tässä sprintissä voi tehdä?

keskustelemalla tuotteen omistajan kanssa kehittäjät valitsevat tuotekannatuksesta itemit, jotka sisällytetään nykyiseen sprinttiin. ScrumTeam voi tarkentaa näitä kohteita tämän prosessin aikana, mikä lisää ymmärrystä ja luottamusta.

sen valitseminen, kuinka paljon sprintissä voi valmistua, voi olla haastavaa.Mitä enemmän Kehittäjät kuitenkin tietävät aiemmasta suorituskyvystään, tulevasta kapasiteetistaan ja Done-määritelmästään, sitä enemmän he ovat Sprint-ennusteissaan.

aihe kolme: miten valittu työ tehdään?

jokaiselle valitulle Tuotekannatuskohteelle kehittäjät suunnittelevat tarvittavan työn luodakseen lisäyksen, joka täyttää Done-määritelmän. Tämä tapahtuu usein hajottamalla Tuotekannatuserät pienemmiksi yhden päivän tai vähemmän kestäviksi työeriksi. Se, miten tämä tehdään, on rakennuttajien yksinomaisessa harkinnassa. Kukaan muu ei kerro heille, miten Tuotekannatuseritelmät voidaan muuttaa Arvonalennuksiksi.

Sprinttitavoitetta, sprinttiin valittuja Tuotekannatuseriä, plustasuunnitelmaa niiden toimittamiseksi kutsutaan yhdessä Sprinttitavoitteeksi.

Sprinttisuunnittelu aikarastataan enintään kahdeksaksi tunniksi yhden kuukauden mittaiselle sprintille. Lyhyemmillä sprinteillä tapahtuma on yleensä lyhyempi.

päivittäinen Scrum

päivittäisen Scrumin tarkoituksena on tarkastaa Sprinttigaalan eteneminen ja mukauttaa Sprinttihakua tarpeen mukaan säätäen noususuunniteltua työtä.

päivittäinen Scrum on 15 minuutin mittainen tapahtuma Scrumteamin kehittäjille. Vähentää monimutkaisuutta, se pidetään samaan aikaan ja paikka Jokatyöpäivä Sprintin. Jos tuoteomistaja tai Scrum Master työstää aktiivisesti Sprint Backlogin kohteita, he osallistuvat kehittäjinä.

kehittäjät voivat valita minkä tahansa rakenteen ja tekniikan he haluavat,kunhan heidän päivittäinen Scruminsa keskittyy etenemiseen kohti Sprinttitavoitetta ja tuottaa toimivan suunnitelman seuraavaa työpäivää varten. Tämä luo keskittymistä ja parantaa itsehallintoa.

päivittäiset Scrumit parantavat viestintää, tunnistavat esteet, edistävät nopeaa päätöksentekoa ja näin poistavat muiden kokousten tarpeen.

Daily Scrum ei ole ainoa aika, jolloin kehittäjät saavat muuttaa suunnitelmaansa. He tapaavat usein koko päivän käydäkseen yksityiskohtaisempia keskusteluja Sprintin muiden töiden mukauttamisesta tai uudelleensuunnittelusta.

Sprinttikatselmus

Sprinttikatselmuksen tarkoituksena on tarkastaa Sprinttikatselmuksen tulos ja määrittää tulevat mukautukset. Scrum-tiimi esittelee työnsä tulokset keskeisille sidosryhmille, ja tuotetavoitteen saavuttamisessa tapahtuvasta edistymisestä keskustellaan.

tapahtuman aikana Scrumin tiimi ja sidosryhmät käyvät läpi, mitä sprintissä tapahtui ja mikä heidän ympäristössään on muuttunut.Näiden tietojen perusteella osallistujat pohtivat yhdessä, mitä seuraavaksi tehdään. Tuotekantaa voidaan myös mukauttaa vastaamaan uusia mahdollisuuksia. TheSprint Review on työistunto ja Scrum-tiimin tulisi välttää rajoittamasta sitä esitykseen.

Sprinttikatselmus on Sprintin toiseksi viimeinen osakilpailu, ja istimeboxia on ajettu korkeintaan neljä tuntia yhden kuukauden sprintissä. Shortersprinteillä tapahtuma on yleensä lyhyempi.

Sprinttiretrospektiivi

Sprinttiretrospektiivin tarkoituksena on suunnitella keinoja tasaisuuden ja tehokkuuden lisäämiseksi.

Scrum-tiimi tutkii, miten loppukiri sujui yksilöiden, vuorovaikutusten, prosessien, työkalujen ja niiden määritelmän suhteen. Tarkastetut elementit vaihtelevat usein työn toimialan mukaan. Heidät harhaan johtaneet väitteet tunnistetaan ja heidän alkuperänsä tutkitaan. TheScrum-tiimi keskustelee siitä, mikä sprintin aikana sujui hyvin, mitä ongelmia sillä oli ja miten nämä ongelmat ratkaistiin (tai jätettiin ratkaisematta).

Scrum-tiimi tunnistaa hyödyllisimmät muutokset, jotka parantavat sen tehokkuutta. Kaikkein vaikuttavimpiin parannuksiin puututaan mahdollisimman pian. Ne voidaan jopa lisätä Sprint Backlog for nextSprint.

sprintin retrospektiivi päättää Sprintin. Se aikaraja on enintään kolme tuntia yhden kuukauden sprintti. Lyhyemmillä sprinteillä eventti on yleensä lyhyempi.

Scrumin Artefaktit

Scrumin artefaktit edustavat työtä tai arvoa. Niiden tarkoituksena on maksimoida avaintietojen avoimuus. Näin ollen kaikilla niitä tarkastavilla on sama sopeutumisperusta.

jokainen artefakti sisältää sitoumuksen varmistaa, että se tarjoaa tietoa, joka lisää avoimuutta ja keskittymistä, joiden perusteella edistystä voidaan mitata:

• tuotekannan osalta se on tuotteen tavoite.

• Sprinttihiihdolle se on Sprinttitavoite.

• kasvatukselle se on Done-sanan määritelmä.

näillä sitoumuksilla pyritään vahvistamaan empirismiä sekä Scrum-ryhmän ja sen sidosryhmien Scrum-arvoja.

Tuotekanta

Tuotekanta on emergentti, järjestetty luettelo siitä, mitä tarvitaan tuotteen parantamiseksi. Se on ainoa lähde, jonka tutkimusryhmä on tehnyt.

Tuotekannatuskohteet, jotka Scrum-tiimi voi tehdä onesprintissä, katsotaan valmiiksi Sprintin Suunnittelutapahtumassa. Ne saavat yleensä tällaisen avoimuuden jalostustoiminnan jälkeen.Tuote Backlog hienosäätö on teko hajottaa ja edelleen määrittelemällä Tuotteen Backlog erät pienemmiksi tarkempia Eriä. Tämä on jatkuva toiminta lisätä yksityiskohtia, kuten kuvaus, tilaus, ja koko. Attribuutit vaihtelevat usein työalueen mukaan.

rakennuttajat, jotka tekevät työn, ovat vastuussa työn teettämisestä. Tuotteen omistaja voi vaikuttaa kehittäjiin auttamalla heitä ymmärtämään ja valitsemaan kompromisseja.

sitoutuminen: Tuotetavoite

Tuotetavoite kuvaa tuotteen tulevaa tilaa, joka voi olla Scrumin tiimin tavoite varautua siihen. Tuotteen tavoite on tuotekannassa. Loput Tuotekannasta syntyy määrittelemään” mikä ” täyttää tuotteen tavoitteen.

tuote on arvoajoneuvo. Sillä on selkeä raja,tunnetut sidosryhmät, hyvin määritellyt käyttäjät tai asiakkaat. Tuote voisi olla palvelu, fyysinen tuote tai jotain abstraktimpaa.

Tuotetavoite on Scrum-tiimin pitkän aikavälin tavoite. Heidän on täytettävä (tai hylättävä) yksi tavoite, ennen kuin he ottavat seuraavan.

Sprinttikannatus

Sprinttikannatus koostuu Sprinttitavoitteesta (miksi), sprinttikisaan valituista Tuotekannatuseristä (mitä) sekä Toteutuskelpoisesta suunnitelmasta kasvun toteuttamiseksi (miten).

Sprinttikelaus on rakennuttajien tekemä ja toteuttama suunnitelma. Se on erittäin näkyvä, reaaliaikainen kuva työstä, jota kehittäjät aikovat suorittaa sprintin aikana saavuttaakseen Sprinttitavoitteen.Näin ollen Sprinttihistoriaa päivitetään koko Sprintin ajan, kuten opitaan. Sen on oltava riittävän yksityiskohtainen, jotta he voivat tarkastaa edistymisensä päivittäisessä taistelussa.

sitoutuminen: Sprinttitavoite

Sprinttitavoite on Sprintin ainoa tavoite. Vaikka tulostustavoite on kehittäjien sitoumus, se tarjoaa joustoa sen saavuttamiseksi tarvittavasta työstä. Sprint-tavoite luo myös johdonmukaisuutta ja keskittymistä, mikä kannustaa Scrum-tiimiä työskentelemään yhdessä erillisten aloitteiden sijaan.

Sprinttitavoite luodaan Sprintin Suunnittelutapahtuman aikana ja lisätään sen jälkeen Sprinttihakuun. Kun kehittäjät työskentelevät sprintin aikana, he pitävät Sprinttitavoitteen mielessä. Jos työ osoittautuu erilaiseksi kuin he odottivat, he neuvottelevat tuotteen omistajan kanssa Sprinttikannan laajuudesta Sprintin sisällä vaikuttamatta tulostavoitteeseen.

lisäys

lisäys on konkreettinen ponnahduslauta kohti Tuotetavoitetta. Jokainen lisäys on lisäosa kaikkiin aikaisempiin lisäyksiin,ja se todennetaan perusteellisesti varmistaen, että kaikki lisäykset toimivat yhdessä. Arvon tuottamiseksi korotuksen on oltava käyttökelpoinen.

Sprintin sisällä voi syntyä useita lisäyksiä. Summat esitetään Sprint Review ’ ssä, mikä tukee empirismiä.Korotus voidaan kuitenkin toimittaa sidosryhmille ennen Sprintin päättymistä. Sprinttikatselmusta ei tulisi koskaan pitää porttina arvon alentamiseen.

työtä ei voida pitää osana korotusta, ellei se täytä tehdyn määritelmää.

sitoumus: Done: n määritelmä

Done: n määritelmä on muodollinen kuvaus siitä, missä vaiheessa kasvu on, kun se täyttää tuotteelta vaadittavat laatumittarit.

sillä hetkellä, kun Tuotekannatuserä täyttää Done: n määritelmän, syntyy lisäys.

Done-määritelmän avulla luodaan avoimuutta antamalla kaikille avoin käsitys siitä, mitä työtä osana lisäystä on tehty. Jos tuote Backlog tuote ei täytä ofDone määritelmä, sitä ei voida julkaista tai edes esitellä Sprint Review.Sen sijaan se palaa Tuotekantaan tulevaa harkintaa varten.

Jos Done-määritelmä on osa organisaation standardeja, kaikkien Scrum-ryhmien on noudatettava sitä vähintään. Jos se ei ole organisaatiostandardi, Scrum-tiimin on luotava tuotteelle sopiva määritelmä.

kehittäjien on noudatettava Done-sanan määritelmää. Jos Useita Scrum-tiimejä työskentelee yhdessä tuotteen parissa, niiden on yleensä määriteltävä ja noudatettava samaa Done-määritelmää.

End Note

Scrum on ilmainen ja tarjotaan tässä oppaassa. Scrum-viitekehys, kuten tässä kuvaillaan, on muuttumaton. Vaikka toteutetaan vain osia Scrum onmahdollista, tulos ei ole Scrum. Scrum on olemassa vain kokonaisuudessaan andfunctions sekä kontti muita tekniikoita, menetelmiä, andpractices.

tunnustukset

ihmiset

tuhansista ihmisistä, jotka ovat osallistuneet Scrumin tekoon, meidän pitäisi yhdistää ne, jotka olivat alussa instrumentaaleja: Jeff Sutherland työskenteli Jeff McKennan ja John Scumniotalesin kanssa, ja Ken Schwaber työskenteli Mike Smithin ja Chris Martinin kanssa, ja he kaikki työskentelivät yhdessä. Monet muut antoivat panoksensa seuraavina vuosina, ja ilman heidän apuaan Scrum ei olisi jalostunut nykyisenlaiseksi.

Scrum Guide History

Ken Schwaber ja Jeff Sutherland esittivät Scrumin ensimmäisen kerran Oopslakonferenssissa vuonna 1995. Se dokumentoi olennaisesti Ken andjeffin edellisinä vuosina saamaa oppia ja julkisti Scrumin ensimmäisen muodollisen määritelmän.

Scrum Guide dokumentoi Scrum as developed, evolved, and considered for 30-plus years by Jeff Sutherland and Ken Schwaber. Muut lähteet tarjoavat Scrum Frameworkia täydentäviä säiliöitä, prosesseja ja oivalluksia.Ne voivat lisätä tuottavuutta, arvoa, luovuutta ja tulosten tuottamaa tyydytystä.

Scrumin koko historia on kuvattu muualla. Kunnioittaaksemme ensimmäisiä paikkoja, joissa sitä kokeiltiin ja todistettiin, tunnistamme Individual Inc., Newspage, Fidelity Investments, ja IDX (nyt GE Medical).

© 2020 Ken Schwaber ja Jeff Sutherland tämä julkaisu on lisensoitu Creative Commons-yhtiön AttributionShare-Alike-lisenssillä, saatavilla osoitteessa://creativecommons.org/licenses/by-sa/4.0/legalcode ja myös tiivistelmämuodossa osoitteessa://creativecommons.org/licenses/by-sa/4.0/. Käyttämällä tätä ScrumGuide, ymmärrät ja hyväksyt, että olet lukenut ja suostut olemaan sidottu ehdot Attribution Share-Alike lisenssin CreativeCommons.