Plánování sprintu

Článek
06/10/2015

Podle Mitch Lacey.Vlastník, Mitch Lacey & partnerů, Inc, konzultaci potvrdit specializovanými v agilní a scrum adoptions a vylepšení.

Leden 2012.

Plánování sprintů se nemusí být náročné.Často je zábavu a čas pro celou Scrum týmu k vytváření camaraderie podle pracovních společně, abyste odpověděli na otázku "Co můžete jsme potvrzovat?" V tomto článku autoři poskytují příklady a strategie pro uchování plánování sprintů specializovaný a efektivní a podrobností možná řešení běžných problémů týmy dojít při plánování Sprint zahrnuje.

Platí pro

Správa životního cyklu aplikací; Team Foundation Server

V tomto článku:

Úvod
Prognózy versus potvrzení
Co je to plánování Sprintů?
Jak ji můžeme zvládnout?
Běžné problémy
- Scénář: Týmu nelze zapsat na všechny články, které požádal, vlastníka produktu.
- Scénář: Vlastníka produktu nepochází připravené.
- Scénář: Část 1 překračuje jeho timebox.
- Scénář: Část 2 překračuje jeho timebox.
- Scénář: Vlastníka produktu není k dispozici.
- Scénář: Tým nemá akceptační kritéria, které potřebuje.
- Scénář: Vlastníka produktu neví, co provést znamená.
- Scénář: Vlastník ScrumMaster nebo produkt je odhad/ovlivňující odhadne/práci týmu.

Není plánujeme.Jsme Scrum, proto jsme provést.

Mohu poslechněte si to vždy.Osoby myslíte, že Scrum a agilní střední č plánování, žádné odhadování, žádné schůzky ne cokoli!To nebylo PRAVDA je však.Plánujeme na různých úrovních v projektu aplikace agilní: denního plánu nebo denně rychlá schůzka, Týdenní plány (nevyřízených položek sprintu nebo iteraci), verze plán (nevyřízených položek produktu) a potenciálně Další.

Podíváme se zaměřují na plánování Sprint zahrnuje.

Prognózy versus potvrzení

V léta 2011, Ken Schwaber a Jan Sutherland revidované jejich Scrum průvodce.V něm jejich odebrat jeden dlouho zavedených chování znám Scrum, což je úsilí, které týmu provede vlastníka produktu a zákazníky.Byl nahrazen závazek prognózy.Říká se, že mohou týmy prognózy svou práci, ale není potvrdit.

Při jejich logiku rozumím, nechci závazku z následujících důvodů:

Potvrzení na jinou hodnotu převádí týmu na různých si než jen prognózy.Pokud prognózy týmu je mlčky předpokládaných, že neodpovídající vše, co že se uživatel napsal, že by mohla činí je přijatelné chování.Při týmy mohou učit se od jejich prognózy, případně s menším odchylku odhad najít, který týmy prognózy trvá déle snížit odchylku ve srovnání s týmy, které potvrzení.
Prognózy, nebo odhad, je vhodný pro nevyřízených položek produktu.Při týmy přesunout článků z nevyřízených položek produktu sprintu nevyřízené položky a jejich rozdělení, jejich však přidat další úroveň podrobností, nalezení malé podrobnosti, které mohly položit "může společnost Microsoft k potvrzení změn to?” Prognózy spouští riziko přejde do stavu v opožděné týmu místo toho říct "je třeba prognózy, je v pořádku Pokud jsme přijít o některé věcí, společnost Microsoft může obrázek ji ven později."

A v poznámce světlejší, představte si, pokud je uživatel napsal wife, oba, partnera "Mohu prognózy, že jsme budete společně se pro deset let" versus "Mohu potvrdit sám vám" – Ano, který budete přenášeny po dobře.

Díky tomu je Scrum o Internetová brána.Navrhuji zkusit přístup závazku a prognózy přístup.Toto je vše, co učení, nikoli o jaké slova používat, takže je inteligentní, oba vyzkoušet a používat co je nejvhodnější pro vás, váš tým a vaši společnost.

Co je plánování Sprintů?

Můžeme podržte sprint, plánování schůzky plánovat co týmu bude sestavení v nadcházející sprint a jak týmu bude proměnit ve skutečnost.Přestože označujeme ji jako plánování sprintů meeting, skutečně se skládá ze dvou částí velmi odlišné.Část 1 se zaměřuje na co týmu je požadováno pro vytváření a má formu vlastníka produktu a týmu.Část 2 se zaměřuje na plány, jak týmu k sestavení požadovanou funkci.Ačkoli celý tým musí zúčastnit část 2, účasti vlastníka produktu je volitelné.Je-li z jakéhokoli důvodu, vlastníka produktu není Zúčastněte se část 2, vlastníka produktu by měl zůstat k dispozici pro dotazy.

V části 1 sprint schůzka k naplánování vlastníka produktu má možnost popisují požadované sada článků týmu.Toto je relace podrobné postupy na co část scénáře.Vlastníka produktu uvede scénáře, ukazuje, jak věci interakci a provede rozhraní.Kromě toho může přezkoumat infrastruktury či architektury položky.Cílem je vyplnit dostatek informací, aby bylo možné počítač, zjistit, jak vytvářet funkce kolektivní hlav členů týmu.Tým požádáni o zadání různé dotazy ke shromáždění informací jak schůzky - otázky:

"Jak se akceptační kritéria všech tyto úspěchy?"
"Zdrojů dat, si myslíte, že používáme?"
"By měl rozhraní vzhled na tuto komponentu?"

Během části 2 sprint plánování schůzky týmu změní jeho důraz na vytváření nevyřízených položek sprintu – seznam scénáře a úlohy potřebné k jejich dokončení během sprintu.K vytvoření nevyřízených položek, rozdělí týmu každý článek, který vlastníka produktu požádal o úrovni úkolu; Každá úloha je uveden hodinovou odhad.Na konci části 2 týmu rozhodne, které články můžete potvrzovat dokončení během sprintu.

Dohromady může dvou částí sprint schůzka k naplánování trvat ze dvou na 8 hodin.Obecné pravidlo použité je, aby každá část by měla trvat až hodinu pro každý jeden týden sprint délky.To znamená, pokud používám týdenního sprintech schůzky vede s celkovým počtem dvou hodin (jedna hodina, část 1 a jednu hodinu část 2).Je-li na druhé straně mohu v průběhu sprintů čtyř týdnů, bude trvat schůzky celkem 8 hodin (čtyři hodiny, část 1 a 4 hodiny pro část 2).

Jak ji můžeme zvládnout?

Dokud týmu opustí sprint plánování schůzky potvrzeny do dokončení seznam scénáře, týmu provedlo účel plánování sprintů.Získávání týmu k bodu domnívá, kde pohodlné, takže závazek, každého člena týmu však vyžaduje bit předem plánování a usnadnění.

Vlastníka produktu má jednu úlohu při plánování sprintů: pocházejí schůzky moci popisují sada požadované článků.Týmu cílem je pochopit scénáře z vlastníka produktu hlediska, chcete-li sdílet v vizi vlastníka produktu.ScrumMaster ujistěte, že je dostatek otázek a zaznamenávání všechny výsledné data, včetně akceptační kritéria, náčrtky a všechny předpoklady týmu.ScrumMaster také Nedovolte vlastníka produktu víte, že týmu může obsahovat další otázky po začne rozdělení otázek na úkoly.Přestože vlastníka produktu představuje scénáře, jejichž celkový počet položek bodu obecně odpovídá historické rychlosti týmu, týmu nakonec rozhodnout, zda lze, ve skutečnosti provést pro všechny články v daný sprint založené na co dozví během část 1 a 2 části sprint schůzka k naplánování.

Poté, co týmu má všechny informace získané z vlastníka produktu, musí rozdělení články na úkoly a vytvoření nevyřízených položek sprintu, která zachycuje všechny články, poznámky, akceptační kritéria, úkoly a odhadne pro konkrétní sprint.Když dochází k dispozici mnoho způsobů, jak to provést, mohu využívat následující metody, která využívá všech členů týmu nápady a přiřadí všem uživatelům hlasu v úloha rozložením.

Mít ScrumMaster nebo zprostředkovatel meeting odečte svůj příběh a zeptejte, "Nemá všem uživatelům pochopit jeho?" Tým má jako právě stráví čas s diskuze o jeho vlastníka produktu.Pokud se někdo v týmu porozumět, věnovat některé znovu navštíví příběh, jakékoli potřebné otázek vlastníka produktu.
Dále máte každý člen týmu, stáhněte si vždy navrchu plocha.Položit jednotlivých členů týmu k zápisu jeden úkol na každém vždy navrchu a tyto ji uprostřed tabulky.
- Každý jako vždy navrchu je tossed do druhé tabulky, thrower ohlásil úlohu.Tak, že pokud je zapsán "aktualizovat uložená procedura", se říká nahlas.To je důležité, protože budou získáte nové nápady a způsobit ostatním říct, "Ano Oh a My nutné aktualizovat zdroj dat." AT, bodu, uživatel bude zapisovat na vždy navrchu "aktualizovat zdroj dat" rozpoznávání řeči a jeho výjimku uprostřed.Tato aktivita debaty skutečně funguje vyprázdnění limit všech souvisejících úloh.Není starosti duplicitní položky v současné době.Vyvolání limit všech úloh rychlé poznámky obvykle trvá asi pět až deset minut za příběh.
Pokud rychlé poznámky jsou všechny v tabulce, je čas seřadit.Vložit je všechny až na stěnu, krok zpět a hledat – velké množství rychlé poznámky!Začněte tím, že identifikující duplicity; žádné rychlé poznámky, který se zdá, že duplicitní se překrývají.Poté vyhledejte úlohy, které se zdá, že přejdete dohromady, protože jsou podobné nebo protože závisejí na sebe navzájem.Pokud dvě rychlé poznámky podobný vztah, seřaďte je ale posun, jak ukazuje následující příklad:

Je-li provést dvě úlohy souvisejí tak přesně tak, aby byly téměř identické, překrývají téměř zcela, jak je znázorněno níže:

Podle řazení rychlé poznámky, můžete týmu jatečné seznam úkolů a vizualizovat vztahy mezi ty, které zůstávají.
Pokud jsou řazeny úkoly, je čas pro odhad.Použít plánování poker techniky pro odhad úkolů s jedním rozdílem: čísla na kartách představují hodin namísto body.Mohu provést vzhledem k tomu, že lidé jsou obvykle získat příliš přestala zbytečně podrobností s ohledem na hodin, zejména ve velkých objemů úlohy.Je-li dobrý důvod pro jejich trepidation.Příliš často společnosti použít odhad jako stonek porazit týmu."Uživatel napsal, by byly třeba 8 hodin, a můžete trvání 12.Co je chybná?"nebo"jste uvedli by byly třeba 8 hodin a trvalo pouze 4.Můžete si odsazení vaše odhadne."

Stejným způsobem, že karty zachovali příběh bodu odhadne abstraktní, kartami pro odhad úkolů umožňuje mít svobodu, který je součástí sady pevnou čísel lze vybírat při vynuceného nakonec umožní výběr s členy týmu.Odstraní také vyhřívané diskuse o tom, zda by měl úloha odhadované na 6 hodin nebo 6.5 hodin nebo 7 hodin.

Bez ohledu závěrečný odhad, nezapomeňte, že odhad provádí týmu a je určena k použití týmem pouze na jim pomůže zvýšit jeho spolehlivosti a zjistit, zda ji lze provádět na práci, kterou vlastníka produktu položil pro založené na rychlosti.Úloha odhadne nejsou metriky a nesmí být použita jako taková.Nikdy použít odhadne jako zbraní proti týmu.
Teď, když jsou odhadovaných úkolů, týmu nutné rozhodnout, pokud má kapacitu pro více práce.Chcete-li to provést, bude nutné znát kapacity týmu celkový počet hodin, které týmu má k dispozici během sprintu.Určení kapacity je snadné, pokud máte plně vyhrazené týmu, ale získá těžší, pokud máte tým tvořen částečný uživatelů, kteří jsou rozděleny ve více projektech.Zeptejte se všem uživatelům poznamenejte si počet hodin, které každý může pracovat na projektu za den (nebo součet za sprintu).Přidáte všechna čísla společně se získat celkový počet hodin, která je k dispozici pro členy týmu.Předpokládejme, že kapacity týmu ověříte, že jím být 200 hodin.Pokud je součtem úlohy pro svůj příběh odhadovaná začala spotřebovávat 30 hodin, požádejte týmu, "Jsme rozpoznal více práce?" V této rané fázi odpověď je zřejmé Ano.

Vzhledem k tomu, že máte další kapacitu k vyplnění, přejít na další příběh a opakováním kroků 1 až pět.

(Informace o tom, jak provést tento úkol pomocí serveru Team Foundation Server naleznete v tématu Spolupráce [přesměrováno].)

V určitém okamžiku budete mít obtížné čas odpověď na otázku, "Jsme rozpoznal více práce?" Toto je vzhledem k tomu, že se blíží kapacity vašeho týmu.Při práci pomocí tohoto procesu, zvažte, že nechcete vyplnit sprint na kapacitu.Pokud je skla vyplnit vody až po okraj, je velmi pravděpodobně přepadového.Stejné platí pro sprintů.Je-li odhadovaný počet hodin používat všechny dostupné čas a nové úlohy je identifikován později v sprintu, bude přepadového věci.Je třeba ponechat prostor pro vznikajícího úlohy.

Při posuzování sprint úsilí, pomáhá vzít v úvahu následného data z uplynulých sprintů.Je týmu konzistentně s přenést více práce?Možná týmu může k potvrzení změn ve více při plánování sprintu.Je konzistentně nelze dokončit všechny pracovní Sprint zahrnuje týmu?Týmu mohou vyžadovat provedení větším omezením s své závazky v oblasti, dokud určila hlavní příčinu nekompletní sprintů.

Jeden ze způsobů umístí na otázku "jak úplných k zaplnění vaše sklo" číslo je vzít v úvahu nárůst velikosti plánu.Nárůst velikosti plán opatření, jak skutečné hodiny stráví porovnání na počáteční odhadne.Předpokládejme například, že náš tým má kapacitu k dispozici 200 hodin.Potvrdí které považuje za bude 190 hodin, podle odhadne týmu.Na konci sprintu týmu vypočítá, že tyto úspěchy obsažené v hodnotě 240 skutečné hodiny práce, výsledkem nárůst velikosti plán 20 %.

Tým, který vyhledá tuto nesrovnalost by měla věnovat nějakou dobu během zpětnou zkoumáte důvody:

Jsou příliš mnoho úkolů probíhá zjištěny během provádění, které nebyly určeny při plánování?
Vychází z jeho aktuálního už podcenění jeho úkolů týmu?
Overestimate týmu jeho kapacitu?
A tak dále.

Týmu by měl také vzít v úvahu jeho nárůst velikosti plánu během příštího sprintu schůzka k naplánování při určování, zda lze zapsat do textu.Přechod zpět náš příklad, je-li týmu stále odhadne o objemu 200 hodin, by měl týmu odečíst 20 % mimo nahoru pro kompenzaci na základě historických dat nárůst velikosti "očekávaný" plánu.Jinými slovy, pro alespoň tato sprintů, aby zabránil polití, v případě, že tým získá 160 hodin, ji by měla samotného deklarovat na kapacitu.

Vzhledem k tomu nárůst velikosti plánu je jedním ze způsobů vyčíslit jak úplná sprint by měla být.Realizovat však, že cílem je přesně odpovídat kapacita není.Místo toho je chcete, aby tým jistotu, že v zápisu do odpovídající počet scénáře – číslo, které nabízení týmu bez nadměrného zatížení ji.Nárůst velikosti plán slouží pouze k určení přibližně jak úplná příštího sprintu by měla být, pokud všechny dalších faktorů zůstávají stejné.

Když jsou všechny články odhadovaná nebo všechny čas je využívána scénáře, vraťte se na vlastníka produktu a podělte se o nevyřízených položek sprintu, který má potvrzené týmu k poskytování.Nyní spustí sprintu – tak začít pracovat.

Běžné problémy

V mé letech konzultaci s týmy na jejich přijmout Scrum uloží se mnohé stejné problémy, které neumožňují, plánování sprintů úspěšné.Přestože plánování sprintů zdá přehledné, jsou obvykle potíže se čtením týmy, které jsou právě Začínáme s Scrum.Mnoho z těchto problémů a jeho možných řešeních jsou podrobně popsány v této části.

Scénář: Týmu nelze zapsat na všechny články, které požádal, vlastníka produktu.

By měl očekávat k tomu docházelo příležitostně.Jak dlouho týmu můžete zálohovat úsilí s daty z kroků 4 a 5 dříve v tomto tématu, vlastníka produktu by měla být splněna.Budete chtít sledovat a ujistěte se, že této chyby a potvrzení není výsledek nadměrné odsazení nebo velké úlohy.ScrumMaster by měl challenge co zdát přehnaně konzervativní odhadne, abyste měli jistotu, že jsou přesné.Vlastníka produktu by měl otázka jakákoli úloha, která má odhad dvou číslic.Jakákoli úloha, která je odhadovaná trvá déle než dvou pracovních dnů by měl být rozdělený na menší úkoly a znovu odhadovaná.To platí pro všechny projekty, ale je obzvláště troubling pro týmy spuštěna sprintech týdenního nebo dvou týdnů.

Scénář: Vlastníka produktu nepochází připravené.

Jedna hodnota Scrum je dodržování.Je disrespectful pochází z schůzky připraven.Co je týmu pro případ, vlastníka produktu se zobrazí bez informací týmu tak potřebuje?I když jednu možnost je k odložení schůzky, dokud není připravena vlastníka produktu, tak učiníte podporuje pouze ke stejnému chování – zabránit.Další možností je chcete-li zrušit sprintu.Ačkoli toto mohou fungovat, je extreme.

Najít nejlepší řešení být dva skládání.První, nevyřízených položek produktu by měl jako v nějaká pořadí podle priority, takže pokud vlastníka produktu není zaškrtnuta možnost konkrétní sadu scénáře, týmu a vlastníka produktu lze pouze diskutovat o články v pořadí podle priority až do bodu, pokud se domníváte, budou na nebo nad kapacitu.Tým potom se můžete rozhodnout na přesné úsilí během část 2 schůzky, jako obvykle.

Po skončení schůzky by měly fungovat ScrumMaster pochopit, proč nebylo připraveno vlastníka produktu.Byla-li tento problém nedostatek zapojení, informací ScrumMaster softwarovou vlastníka produktu na významu návštěvy meeting připravit s sada článků.Je-li, aby byl vlastníka produktu na druhé straně byl problém nelze připravit pravděpodobně vzhledem k tomu, abychom vám pomohli s výmazu dat se nezdařilo týmu, by měl pomoci ScrumMaster k řešení těchto potíží se také.

Scénář: Část 1 překračuje jeho timebox.

Jinou hodnotou je aktivní.Pokud je spuštěn část 1 schůzky, je symptomatických rozporu se soustředí.Někdy vlastníka produktu nezaostřená z důvodu nedostatku přípravu, stanovení priorit nebo pokusu o vysvětlují příliš mnoho scénáře.Další čas nedostatek fokus může pocházet z týmu jeho zdržení "jaké" rozhovory s podrobnosti "jak."

ScrumMaster by měl pomoci přesunout objekty podle insisting, že v tabulce vlastníka produktu jakékoli scénáře, které nemůže být vysvětleny plně a aby byl týmu podrobné implementace diskuse limit část 1.Jeden jednoduchý oprava pro účely diskuse o nezaostřená je použití stopky nebo časovače.

Scénář: Část 2 překračuje jeho timebox.

Znovu fokus.Máte-li tým, který pojednává nadměrném někdy s disciplíny omezit diskuse je vše, co je nutný k přenesení schůzky zpět v řádku.Přenést časovače a udržovat konverzace minuta nebo mezi odhadne úloh.Cílem je přesnost není 100 % přesnost.

Další čas nedostatek fokus během část 2 je symptomatických rozporu výmazu dat během provádění sprint nevyřízených položek produktu.Mazání dat je čas, kdy můžete týmu podívejte se na budoucí scénáře a pracovat s vlastníka produktu, chcete-li přidat článků nebo špičky Připnutí dolů návrh směrech nebo adresování architektura dotazy.Bez pravidelné produktu výmazu dat nevyřízených položek, plánování sprintů nevyřízené položky se změní na nepraktické a bolestivé.

Scénář: Vlastníka produktu není k dispozici.

Pokud vlastníka produktu nemohou zúčastnit schůzky z jakéhokoli důvodu a nebyl určen proxy server, fungovat jako, pokud vlastníka produktu dodán schůzky připraven.Pracovní prostřednictvím nejlepších položek a potvrdit nejlepší, které můžete provádět následující akce.Můžete mít tendenci Chcete-li změnit čas schůzky skutečnost zohlednit vlastníka produktu plánu.Si.Posunutí čas schůzky přizpůsobí potřeba jedné na náklady m.Není vhodné ji.

Scénář: Tým nemá akceptační kritéria, které potřebuje.

Mohu vždy poradit týmy požádejte vlastníka produktu během část 1, "jak se akceptační kritéria pro tuto?" nebo "Co potřebujeme krocích k získání můžete přijmout práci?" Pokud to chybí v části 2, když týmu je určení úkolů, bude se tým nemá žádné nápady jak získat příběh zavřete.Pokud tým má uhodnout, založené na co slyšeli v části 1 týmu spouští riziko vlastníka produktu na konci sprintu rozhodování, zda není dokončena textu.Požádejte o akceptační kritéria z nabídky start pro každý text.ScrumMasters – turistická třída své vlastníky produktu k poskytování tato data.

Scénář: Vlastníka produktu neví, co provést znamená.

Stejně jako týmu chce akceptační kritéria, vlastníka produktu si zaslouží aktuální popis jaké týmu se rozumí "textu je Hotovo." Tento seznam Hotovo výrazně účtován, aktuální a vždy k dispozici pro vlastníka produktu.Seznam aplikace zastaralá Hotovo je obtížné plán, protože není k dispozici žádné společné porozumění provést bude vypadat takto.Být jisti, který aktualizaci Hotovo seznamu je součástí každé kontrolní sprint nebo následného.

Scénář: Vlastník ScrumMaster nebo produkt je odhad/ovlivňující odhadne/práci týmu.

Vlastníka produktu je uvítací v části 2 schůzky, ale vlastníka produktu role v části 2 by měla být omezeny na vyjasnění požadavek nebo adresování konkrétní dotaz.Vlastníka produktu by měl nikdy zasahovat do diskuse týmu jak implementovat svůj příběh a nemá žádné říci ve odhad úkolu.Vlastníka produktu vyžaduje, aby důvěřoval týmu pro práci.

Je-li vlastníka produktu mimo tyto pokyny, by měl ScrumMaster turistická třída vlastníka produktu k vhodnější roli.Pokud vlastníka produktu odmítne přijmout více pasivní roli, ScrumMaster má oprávnění k požádejte vlastníka produktu opustit.

Plánování sprintů se nemusí být náročné.Často je zábavu a čas pro celou Scrum týmu k vytváření camaraderie podle pracovních společně, abyste odpověděli na otázku "Co můžete jsme potvrzovat?" Mějte na paměti, pokud zjistíte, že schůzek spustit dlouhý, kořenové způsobují problémy s jsou pravděpodobně příčinou to.Pokud jste ScrumMaster, zůstane meeting zaměřena tím, že zajistí, že vlastníka produktu a týmu pravidelnému nevyřízených položek produktu.Nápověda vlastníka produktu přijde připravit tím, že příběh akceptační kritéria připraven před zahájením schůzky.Na závěr zachovali vlastníka produktu a týmu zaměřena na úlohy po ruce – určení, co se můžete k potvrzení změn ve sprintu.