Tiedämme, että pitkän aikavälin suunnittelun (julkaisun suunnittelu) tulisi olla tarinapisteissä.
Mutta sprinttisuunnittelussa sen tulisi olla sitoutumista perustuva.
Tuotetietokannan / käyttäjäkertomuksen jakaminen tehtäviksi ja tehtävien arvioiminen, tiimi kysyy itseltään, voivatko he sitoutua toimittamaan tuotetukikohdan ja toistamaan sitten, kunnes ne ovat täynnä?
Kuinka suuri jokaisen tarinan pitäisi olla kolmen viikon sprintissä ihmiselle?
Olen myös nähnyt, että jotkut joukkueet lopettavat tämän tehtävään perustuvan suunnittelun ja että heillä on vain 2 päivän pituisia tarinoita ?
Pitäisikö minun standardoida tämä joukkueelleni?
Joten ennen sprinttiä eritän tarinani niin lyhyiksi tarinoiksi, että ne sopivat tähän standardiin.
Ole hyvä, kerro minulle näkemyksesi tästä. Ja mikä on yleinen käytäntö?
Kommentit
- Scrum Guide muuttui ” sitoutuminen ” – ” ennuste ”. Voit lukea muutoksen syyn täältä.
- Tästä linkistä voi olla hyötyä pm.stackexchange.com/questions/10119/ …
vastaus
TL; DR
Periaatteessa koko suunnitteluolettamuksesi ei ole ketterä. Sinun on tarkasteltava uudelleen, miten suunnittelet iteraatioita ja miten tiimisi aikoo arvioida työn, jonka sen mielestä voidaan suorittaa nykyiselle iteraatiolle. Seuraavassa on yksityiskohtaisempi analyysi.
Yksityiskohtainen analyysi
Tiedämme, että pitkän aikavälin suunnittelun (julkaisun suunnittelu) tulisi olla tarinapisteissä. [sic]
Ei. Ketterä julkaisusuunnittelu on tehty iteraatioissa . Siksi Scrum-projektisuunnitelma arvioi likimääräisen iterointialueen, joka tarvitaan elinkelpoisen vähimmäistuotteen saavuttamiseksi tai alkuperäisen tuotekannan täyttämiseksi. Tämä on vain arvio, koska tilauskannan sisältö muuttuu ajan myötä, ja myös estimaattien pituus ja tarkkuus muuttuvat yhdessä epävarmuuskartion kanssa.
Mutta sprintin suunnittelussa sen on oltava sitoutumispohjainen.
Jälleen, ei. Sprintin suunnittelu on kapasiteettiin perustuva . Ainoa seurantapiste (tai luodaan alustava arvio ryhmän) keskimääräisestä nopeudesta on löytää tiimin kestävä työkyky ajan myötä. Vaikka joukkueen on oltava varma siitä, että hän ei koskaan sitoutu liikaa työskentelemään Sprintissä vain siksi, että nopeusalue tai keskiarvo sanoo, että kapasiteettia pitäisi olla käytettävissä, joukkueen vastuulla on suunnitella nykyinen iteraatio ottamalla joukkueen kokoonpano, saatavuus ja muut tekijät jotka vaikuttavat nykyiseen Sprintiin huomioon.
Sanomista, että Sprintit ovat ”sitoutumispohjaisia”, käytetään todennäköisesti tunnepohjanaan saadakseen joukkueet sitoutumaan enemmän työtä kuin heidän pitäisi, koska tietysti tiimin jäsenten on oltava ”sitoutuneita”. Se on kuitenkin väärinkäyttöä; reaalimaailmassa joukkueiden kapasiteettia tulisi yleensä vähentää, mutta harvoin sitä tulee lisätä suunnittelun aikana. Jos joukkue on sitoutunut liian vähän, lisätyö voidaan irrottaa tarvittaessa tuotekehityksestä, mutta leikkaaminen on melkein aina poliittisesti täynnä ja asettaa Sprint-tavoitteen usein vaaraan. Joten älä tee niin.
Kapasiteetti voi olla suhteellisen objektiivinen mittari. Toisaalta sitoutumista (aivan kuten isänmaallisuus) ei voida mitata, ellet sinä Pyydämme ihmisiä ”tekemään lopullisen uhrin”, joka on tavallaan antiteettinen koko ketterän kestävyyden lähtökohdalle. Älä koskaan sitoutu kuolemanmatkaan .
Kuinka suuri jokaisen tarinan tulisi olla kolmen viikon sprintissä jokaiselle?
Tämä ansaitsee kokonaisen kirjan, joka on täynnä ”ei”. Tarinat eivät koskaan ole yksilöllisiä eikä niitä hyväksytä. Kaikki tarinat arvioidaan yhdessä toimivan monialaisen tiimin täydellisten, koordinoitujen resurssien perusteella. em> jokaisen tarinan täydentämiseksi. Tarinat hyväksytään tai hylätään sen perusteella, onko:
- ne ovat välttämättömiä nykyisen Sprint-tavoitteen kannalta.
- Ne sopivat arvioituun kapasiteettiin. saatavana nykyiselle Sprintille.
Yksi yksittäinen tuotevirtakohde voi olla mikä tahansa uudelleen 0 tarinapisteestä koko Sprintin käytettävissä olevaan enimmäismäärään saakka. Hyvä juttu, joka täyttää INVEST-kriteerit , koostuu kuitenkin yleensä noin 0,5 – 2,0 päivän pituisista Sprint Backlog -tehtävistä. Muista, että mitä pienempi tehtävä tai tarina, sitä tarkempi arvio yleensä on, joten kymmenkunta 5-pisteistä tarinaa (kun se on arvioitu tarkasti) ovat yleensä luotettavampia kuin yksi 60-pisteinen tarina. Joukkueesi kypsyys ja arviointitarkkuus voivat kuitenkin vaihdella.
vastaus
Käyttäjätarinat eivät ole tiimin jäseniä kohti
Usean tiimin jäsenen tulisi työskennellä saman käyttäjän kanssa tarina samaan aikaan. Tämä ei ole vaatimus vaan suositus. Rugby-terminologian ydin scrum , jossa joukkue menee kohti maaliviivaa yhtenä yksikkönä. Käsite on nimeltään parvi . Kaikki keskittyvät yhteen (tai useampaan) tehtävään tiettynä ajankohtana, suorittavat sen ja käsittelevät seuraavan työn (toista). Edut:
- Se pitää etenemisen_kohteet vähemmän.
- Se antaa mahdollisuuden suorittaa sprinttijälkikohteet, jotka ovat levinneet koko sprinttiin, sen sijaan että kaikki suoritettaisiin lähelle sprintin loppua.
- Pidä qa / testauskuormitus tasaisesti koko sprintin keston ajan.
- Koko tiimi saa kooditiedot ja voi antaa teknisiä ehdotuksia.
Tiimin tulisi valitse tarina ja jaa se teknisiin tehtäviin. Vain yhden henkilön tulisi työskennellä yhden teknisen tehtävän parissa, koska vastuu on selvä tässä tapauksessa, mikä auttaa päivittäisissä kokoustilaisuuksissa. Ihannetapauksessa yhden teknisen tehtävän tulisi olla riittävän pieni, jotta se valmistuu päivän aikana.
Käyttäjätarinoiden koko
Scrum ei määritä mitään käyttäjän tarinan suositeltu koko. Tarinan tulisi kuitenkin olla kooltaan sellainen, että se voidaan suorittaa yhden sprintin aikana. ”Suoritus” tarkoittaa, että se kattaa ”Valmis määritelmän”.
Tarinan tulee olla selvästi ymmärrettävä ja siinä on oltava selkeät hyväksymisehdot , jotka tarkistetaan saman sprintin aikana. Normaalisti on vaikeampi silittää iso juttu ja täsmentää kaikki hyväksymiskriteerit, joten tarinan tulisi olla pieni, jos se voidaan arvioida riittävän hyvin ja testata.
Tarinan tulisi olla myös riittävän suuri, jotta se tuottaa konkreettista liiketoiminta-arvoa sidosryhmille.
Joten vastaus on ei liian pieni eikä liian suuri . Harjoittelun ja kokemuksen avulla saat parempia kirjoittamalla ja jakamalla käyttäjien tarinoita. Se on enemmän taidetta kuin tiedettä.
Vastaus
Sprintin suunnittelun tulisi olla myös tarinapisteissä. Prosessi on sama kuin pitkän aikavälin suunnittelussa. Tarkistat nopeutesi ja kapasiteettisi (kuinka moni tiimin jäsenistä on läsnä esimerkiksi lomien vuoksi) ja tulet ylös numerolla.
Jos suunnittelet sprinttiä 2, tarkista nopeutesi sprintissä 1 – esimerkiksi 10 pistettä – ja lisäät 10 pisteen arvoisia käyttäjäkertomuksia iteraatiotasi.
Jos suunnittelet sprinttiä 3, tarkista nopeuden trendi sprintistä 1: een 2 ja löydät summan, johon voit sitoutua.
Jos suunnittelet sprinttiä 1, lisäät niin paljon kuin haluat mielestäsi sopiva.
Yritä olla katsomatta, kuinka monta pistettä henkilö voi tehdä , koska scrum on joukkueista, ei henkilöistä. Esimerkiksi juniori voi tehdä vähemmän kuin vanhempi, mutta voivatko ihmiset, jotka auttavat toisiaan, eivät pysty toimittamaan yhtä paljon kuin ”paperilla”. Työskentele ja laske joukkueiden kanssa , koska sillä on järkevämpää (ja se on helpompaa).
Kommentit
- Kyllä, Hyväksyn sinut, aiempien sprinttien yhteenlaskettuihin tarinoihin viitataan, ja kuten sinä / CodeGnome sanoit, myös kapasiteetti on otettava huomioon. Itse asiassa olen hämmentynyt siitä, kuinka lyhyen pitäisi olla > jokainen ” tarina, jotta se voidaan testata rinnakkain, koska erillistä testivaihetta ei ole.
- Olen myös aiemmin viitannut seuraavaan: mountaingoatsoftware.com/blog/…
- @Roop, kuten muutkin sanoivat, ” jokaisen ” tarinan ei tarvitse olla riittävän lyhyt. Sitä työskentelevät useat tiimin jäsenet, mutta tarinan sisällä olevien tehtävien tulee olla pidettiin 0,5 päivästä 2 päivään