Tudjuk, hogy a hosszú távú tervezésnek (kiadás tervezésének) történeti pontokban kell lennie.
De a sprint tervezéséhez elkötelezettségnek kell lennie alapú.
A termékhátralék-elem / felhasználói történet feladatokra bontása és a feladatok megbecsülése, a csapat azt kérdezi maguktól, hogy vállalhatják-e a termékhátralék-elem szállítását, majd ismételjék, amíg meg nem telnek?
Három hetes sprint alatt mekkora legyen az egyes történetek egy ember számára?
Emellett azt is láttam, hogy egyes csapatok megszüntetik ezt a feladatalapú tervezést, és csak 2 napos történeteik vannak. ?
Szabványosítsam ezt a csapatom számára?
Tehát egy sprint előtt olyan novellákra bontom a történeteimet, amelyek megfelelnek ennek a szabványnak.
Kérem, tudassa velem erről a véleményét. És mi az általános gyakorlat?
Megjegyzések
- A Scrum útmutató megváltozott ” elkötelezettségről ” – ” előrejelzés “. A változás okáról itt olvashat.
- Ez a link hasznos lehet pm.stackexchange.com/questions/10119/ …
Válasz
TL; DR
Alapvetően a tervezési feltételezések teljes halmaza nem mozgékony. Felül kell vizsgálnia, hogyan tervezi az iterációkat, és hogy a csapata hogyan tervezi megbecsülni azt a munkát, amelyről azt gondolja, hogy befejezhető az aktuális iterációnál. Következik egy részletesebb elemzés.
Részletes elemzés
Tudjuk, hogy a hosszú távú tervezésnek (kiadástervezésnek) történeti pontokban kell lennie. [sic]
Nem. Az agilis kiadástervezés iterációk ban történik. Ezért a Scrum projektterv becsli az iterációk hozzávetőleges tartományát, amelyek szükségesek ahhoz, hogy elérjék a minimálisan életképes terméket, vagy kitöltsék a kezdeti termékhátralékot. Ez csak becslés, mivel az elmaradt tartalom az idő múlásával változik, és a becslések hossza és pontossága is változik a Bizonytalansági kúp mellett.
De a sprint tervezéséhez elkötelezettségen kell alapulnia.
Ismét nem. A sprint tervezés kapacitás-alapú . A nyomon követés egyetlen pontja (vagy a csapat átlagos sebességének kezdeti becslésének megalkotása a csapat fenntartható munkaképességének megtalálása az idő múlásával. Bár a csapatnak biztosnak kell lennie abban, hogy soha nem vállalja el túlzottan a Sprintben való munkát, csak azért, mert a sebességtartomány vagy az átlag azt mondja, hogy rendelkezésre kell állnia kapacitásnak, a csapat felelőssége a jelenlegi iteráció megtervezése a csapat összetételének, elérhetőségének figyelembe vételével. , és egyéb tényezők amelyek figyelembe veszik a jelenlegi Sprint t.
Ha azt mondják, hogy a Sprints “elkötelezettség-alapú”, akkor valószínűleg érzelmi zavaró tényezőként szolgál arra, hogy a csapatok elkötelezzék magukat több munka, mint kellene, mert természetesen a csapat tagjainak elkötelezettnek kell lenniük. Ez azonban “visszaélés; a való világban a csapatkapacitást általában csökkenteni kell, de ritkán kell felfújni a tervezés során. Ha a csapat elkötelezettséget vállalt, akkor szükség esetén további munkát lehet lehúzni a Termékhátralékból, de a vágási lehetőség szinte mindig politikailag tele van, és gyakran veszélyezteti a Sprint-célt. Tehát ne tedd ezt.
A kapacitás lehet egy viszonylag objektív mutató. Másrészt az elkötelezettség (hasonlóan a hazaszeretethez) csak akkor mérhető, ha te arra kérjük az embereket, hogy “hozzák meg a végső áldozatot”, ami mintegy ellentmond az agilis fenntarthatóság teljes előfeltételének. Soha ne kötelezzen el egy halálmenetre .
Három hetes sprintnél mekkora legyen az egyes történetek egy személy számára?
Ez megérdemel egy egész könyvet, amely tele van “nem” -vel. A történeteket soha nem méretezik ki és nem fogadják el az egyének. Az összes történetet egy olyan funkcionális csapat teljes, összehangolt erőforrásai alapján becsüljük meg, amelyek együtt dolgoznak az egyes történetek befejezéséhez. A történeteket elfogadják vagy elutasítják annak alapján, hogy:
- elengedhetetlenek a jelenlegi Sprint-célhoz.
- A becsült kapacitásba beleférnek elérhető az aktuális Sprinthez.
Egyetlen termék-lemaradási elem lehet bármi 0 sztori ponttól az egész Sprint maximális elérhetőségéig. Az INVEST kritériumoknak megfelelő jó történet azonban általában 0,5 és 2,0 nap közötti Sprint Backlog feladatokból áll. Ne feledje, hogy minél kisebb a feladat vagy a történet, annál pontosabb a becslés, így egy tucat 5 pontos történet (ha pontosan becsülik) általában megbízhatóbb, mint egyetlen 60 pontos történet. A csapat érettsége és becslésének pontossága azonban minden bizonnyal változhat.
Válasz
A felhasználói történetek nem egy csapattagra vonatkoznak
Több csapattagnak ugyanazon a felhasználón kell dolgoznia történet egyidejűleg. Ez nem követelmény, hanem ajánlás. A rögbi terminológia lényege, a scrum , ahol a csapat egységként a célvonal felé halad. A koncepciót raj nak hívják. Mindenki egy (vagy kevesebb) feladatra koncentrál egy adott pillanatban, elvégzi azt, és megoldja a következő munkát (ismétlés). Előnyök:
- Kevesebbet tart a_haladás_ elemben.
- Lehetővé teszi az egész sprint alatt elterjedt sprint elmaradt elemek befejezését, ahelyett, hogy mindent a sprint végéhez közel végeznének.
- A qa / teszt terhelés egyenletesen van elosztva a sprint időtartama alatt.
- Az egész csapat megszerzi a kód ismeretét és technikai javaslatokat adhat.
A csapatnak válasszon egy történetet, és bontsa le technikai feladatokra. Csak egy személy végezhet egy technikai feladatot, mert ebben az esetben egyértelmű a felelősség, ami segít a napi scrum találkozókon. Ideális esetben egy technikai feladatnak elég kicsinek kell lennie, így egy nap alatt elkészül.
A felhasználói történetek mérete
A Scrum nem határoz meg semmit a felhasználói történet ajánlott mérete. A történetnek azonban olyan méretűnek kell lennie, hogy egy sprint alatt befejezhető legyen. A “befejezés” azt jelenti, hogy ez magában foglalja a “Kész definíciót”.
A történetnek világosan meg kell értenie, és tartalmaznia kell kifejezett elfogadási kritériumokat , amelyeket ugyanazon a sprint alatt ellenőriznek. Normális esetben nehezebb kivasalni egy nagy történetet és megfogalmazni az összes elfogadási kritériumot, ezért egy történetnek kicsinek kell lennie, ahol elég jól becsülhető és tesztelhető.
A történetnek is elég nagynak kell lennie, így konkrét üzleti értéket nyújt az érdekelteknek.
Tehát a válasz sem túl kicsi, sem túl nagy . Gyakorlattal és tapasztalattal jobbá válik a felhasználói történetek megírása és megosztása. Inkább művészet, mint tudomány.
Válasz
A sprint tervezésének is történeti pontokban kell lennie. A folyamat megegyezik a hosszú távú tervezésével. Ellenőrizze sebességét és kapacitását (hányan lesznek a csapattagok, ünnepek stb. miatt), és feljön számmal.
Ha a 2. sprintet tervezi, akkor ellenőrizze a sebességét az 1. sprintben – például 10 pontot -, és 10 pont értékű felhasználói történetet ad az iterációs lemaradásába.
Ha a 3-as sprintet tervezi, akkor ellenőrizze az 1-es és 2-es közötti sebességi trendet, és megtalálja az összeget, amire elkötelezheti magát.
Ha az 1-es sprintet tervezi, annyit ad hozzá, megfelelőnek találod.
Próbáld meg nem látni, hogy egy ember hány pontot tud megtenni , mert a scrum a csapatokról, nem személyekről. Például egy junior kevesebbet tud csinálni, mint egy idősebb, de vajon az emberek, akik egymásnak segítenek, nem tudnak annyit leadni, mint “papíron”. Dolgozzon és számoljon csapatokkal , mert ennek több értelme van (és könnyebb is).
Megjegyzések
- Igen, Egyetértek veled, a korábbi sprintek összes történetpontjára hivatkozni kell, és ahogy te / CodeGnome mondta, a kapacitást is figyelembe kell venni. Valójában zavaros vagyok, hogy mennyire rövidnek kell lennie ” minden ” történetet, hogy párhuzamosan is tesztelhetők legyenek, mivel nincs külön tesztfázis.
- Emellett korábban utaltam rá: mountaingoatsoftware.com/blog/…
- @Roop, ahogy mások mondták, ” minden ” történetnek nem kell elég rövidnek lennie. Több csapattag fogja dolgozni, de a történetben szereplő feladatokat 0,5 napot 2 napig tartott