Sdílet prostřednictvím


Vytváření a správa produktu Nevyřízené položky

Podle Mitch Lacey.Vlastník, Mitch Lacey & Associates, Inc., konzultační společnost se specializací na zavádění účelných vylepšení a vylepšení typu scrum.

Leden 2012

V tomto článku Mitch Lacey vysvětluje význam produktového backlogu, popisuje, co dělá dobrý backlog a poskytuje některé doporučené postupy pro vytváření a udržování vašeho backlogu.

Platí pro

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

V tomto článku:

  • Úvod

  • Rezervní položky produktu

    • Články uživatele

    • Odhadování

    • Stanovení priority

  • Aktivní rezervní produktové položky

    • Rozvíjení
  • Závěr

Rezervní položky produktu představují seznam všech funkcí potřebných k dokončení projektu.Kvalitní rezervní položka produktu je základem každého správně fungujícího agilního týmu a má následující vlastnosti:

  • Je prioritou zajistit, aby tým nejprve provedl sestavení nejdůležitějších funkcí.

  • Tým odhaduje, že vlastníkovi produktu poskytne srozumitelné informace a umožní mu zodpovědět dotazy, například „Kdy budou tyto příběhy hotové?“

  • Zahrnuje všechny práce nezbytné pro dokončení projektu.

  • Jedná se o aktivní dokument, který se neustále mění a vyvíjí dle aktuálního reálného stavu projektu.

Kvalitní rezervní položka produktu automaticky nezaručuje i kvalitní software.Nedostatek nevyřízených položek často ústí v neúplný software, který nesplňuje požadavky zákazníků a zúčastněných stran.

Správa produktového backlogu je zaměstnání na plný úvazek.Jednoduché techniky, které pomáhají změnit neschůdný a časově náročný proces na interaktivní, opakující se proces, který účinně zapojí členy týmu, zákazníky i zúčastněné strany.Je proto nezbytné se naučit solidní techniky, které napomáhají při sestavování, určování priority a udržování vašeho produktového backlogu.

Rezervní položky produktu

Nevyřízené položky produktu jsou uspořádány, hlavní seznam životních funkcí a funkce potřebné k dokončení projektu.Produkt backlogs běžně obsahují příběhy uživatelů požadavky (e.g. požadavky), chyby úlohy výzkumu (hroty) a technická vylepšení.Tyto položky jsou odhadovány v abstraktních jednotkách, které jsou často nazývány body příběhu.

Rezervní položky produktu zahrnují veškerou práci, kterou bude třeba v rámci projektu později provést.Jako takové neobsahují pouze nové funkce produktu, ale také opravy chyb a výzkum – vše, co bude týmu spotřebovávat čas.Veškerá práce týmu musí pocházet z nevyřízených položek produktu: jedná se o vstupní dveře k projektu.Pokud nevyřízené položky obsahují všechny práce, vlastník produktu, týmu a řídicí pracovník mají lepší obrázek o tom, kolik práce zbývá, což snižuje počet překvapení v poslední minutě.

Na začátku každého projektu je nepravděpodobné, že budete mít hezký seznam jasných a dobře definovaných nevyřízených položek produktů připravených k provedení odhadu a stanovení priorit.Místo toho budete pravděpodobně mít hromádku story poznámkových karet a možná jednu nebo dvě funkční specifikace.Jako vlastník produktu musíte tento nepořádek nějakým způsobem uspořádat, aby tým mohl začít odhadovat nevyřízené položky.

Hh765980.collapse_all(cs-cz,VS.110).gifČlánky uživatele

Prvním krokem je převést všechny nápady a poznámky do příběhu uživatele, který vyjadřuje funkce požadované koncovým uživatelem (co má software dělat), ale nikoli podrobnosti implementace (jak vytvořit software, který splňuje tyto požadavky).Nadpis příběhu každého uživatele by měl být ve formátu „Jako <uživatel> chci <funkci>, takže <řešení>. "

Příklad textu karty

Tak jako samotný produktový backlog se bude každý příběh uživatele během času vyvíjet.V průběhu projektu bude váš tým upřednostňovat a odhadovat tyto úkoly, přidávat k nim podrobné informace a dělit je na menší úkoly, nebo je úplně odstraní.Ty, které byly přidány do sprintů, jsou implementovány a dodány zákazníkům.

Další informace o článcích uživatelů naleznete v částech Vytvoření nebo přidání do nevyřízených položek produktu a Scénář Nevyřízené položky zboží pomocí aplikace PowerPoint.

Po převedení všech nápadů a poznámek na články uživatele je čas provést odhad a stanovení priorit.

Hh765980.collapse_all(cs-cz,VS.110).gifOdhadování

Odhad je z podstaty nepřesný.Časem však můžete vytvářet relativně přesnější odhady, postupy a zlepšovat účast celého týmu. Prvním krokem je shromáždění týmu pro odhadnutí nevyřízených položek produktů.Když tým odhadne každý článek, jsou mu dány odhady relativní velikosti s abstraktní jednotkou měření, která se nazývá bod článku.

Odhady jsou důležité ze dvou důvodů:

  1. Pomáhají odpovědět na otázku „Když bude práce dokončena?“

  2. Pomáhají určit vlastníkovi produktu priority jednotlivých položek.

Odhady poskytují vlastníkovi produktu a týmu představu o nákladech určitého článku, což následně vlastníkovi produktu pomáhá stanovit vzájemné priority článků.Čím větší odhad položky, tím dražší bude její implementovat v času a prostředcích.Proto položka, která pravděpodobně měla vysokou prioritu na seznam přání vlastníka produktu může prioritou snížit, pokud jsou s ní spojené vysoké náklady.

Pro odhad práce v oblasti bodů příběhu může tým použít plánování Poker, velkou stěnu nebo ostatní techniky.Další informace o technikách odhadu a rychlé lekce a rychlé lekce o bodech příběhu naleznete zde: Odhad a Správa a odhadování nevyřízených položek.

Jakmile tým odhadl všechny články, je čas určit priority.

Hh765980.collapse_all(cs-cz,VS.110).gifStanovení priority

Pro nevyřízené položky všech produktů jsou stanoveny priority podle obchodní hodnoty a rizika.Vlastník produktu porovnává jednotlivé položky rezervních položek proti ostatním uživatelům ke zjištění jejich relativní priority.Provedete to tak, že vlastník produktu určí velikost jednotlivých položek, jejich obchodní hodnotu a související rizika.Položky jsou poté seřazeny v sestupném pořadí podle priority.Položky s nejvyšší prioritou se zobrazují v horní části seznamu nevyřízených položek a položky s nižší prioritou jsou umístěny v jeho dolní části.Týmy vyberou práci pro nadcházející sprint mezi položkami s nejvyšší prioritou, aby nejdůležitější položky byly dokončeny nejdříve.

Ne všechny položky v backlogu mají stejnou velikost.Některé lze dokončit v jednom sprintu, ale další jsou tak velké, že tým si není přesně jist postupem nebo jak dlouho bude trvat jejich implementace.To je OK.Když se položky přibližují k vrcholu nevyřízených položek, tým je bude zmenšovat a upřesňovat tak, aby všichni lépe chápali práci, kterou budou provádět v nadcházejících sprintech.

Stejně jako u odhadu může být stanovení priority pro počáteční nevyřízené položky produktu nesnadné.Jak efektivně rozložíte požadavky konkurenčních účastníky, když berete v úvahu konečný produkt, rizika a náklady?Luckily existuje několik technik, které usnadňují úlohu, včetně inovace hry a relativní důležitost.Viz Stanovení priority a Správa a odhadování nevyřízených položek s dalšími informacemi o těchto i jiných technikách.

Bez ohledu na vybranou techniku priorit musíte dodávat práci, která zajistí, aby tým vytvořil funkce, které poskytují nejvyšší obchodní hodnotu pro zúčastněné osoby a zákazníky.Pokud neřídíte prioritu práce, zvyšujete riziko, že doručíte příběhy uživatelů s nízkou prioritou namísto uživatelů s prioritou vyšší, a také riziko, že při změně zdrojů a termínů nebudete mít příběhy uživatelů hotové.

(Další informace o podstatě rezervních položek naleznete v částech Vytvoření nebo přidání do nevyřízených položek produktu a Agilní plánování a iterací).

Aktivní rezervní produktové položky

To co jsem doposud popsal se zaměřuje na přechod z ničeho k rezervním položkám produktu s odhadem a prioritami.Na rozdíl od požadavků dokumentu nejsou rezervní položky produktu vytvářeny na začátku projektu a poté odloženy na polici.Místo toho se produktový backlog vyvíjí tak, že se rozšiřuje a zužuje dle reálného stavu projektu.Některé rezervní položky produktů se stanou irelevantními a je třeba je odebrat.Ostatní se dostanou na povrch a je třeba je rozdělit na menší úkoly.Jakmile se objeví další požadavky, budou přidány nové příběhy uživatele, vytvořen jejich odhad a nastavena priorita.

Tým a zúčastněné osoby jsou začleněni v procesu vytváření a správy rezervních položek produktu, ale vlastník produktu má za ně mezní odpovědnost.Vlastník produktu musí zajistit, aby rezervní položky byly čisté, uspořádané a aktualizované tak, aby zákazníci i tým měli jasný obrázek o pracovní plánu pro uvolnění projektu.I poté, co se projekt rozjede, mají vlastníci produktu stále dostatek práce, aby zachovali nevyřízené položky produktu v odpovídající podobě:

  • Přidání a stanovení priority nových článků

  • Požádejte tým pro odhad nových článků a opakovaný odhad starých, které teď lépe chápou.

  • Týmová kontrola nadcházejících úloh uživatelů a jejich rozdělení podle potřeby

  • Schůzka se zákazníky a zúčastněnými stranami pro kontrolu a přidání požadavků

Každý uživatel může kdykoli přidávat položky mezi nevyřízené položky produktu, ale pouze vlastník produktu může stanovit priority.Vlastník produktu je také jediný, kdo příběhu můžete přiřadit prioritu.Všichni ostatní členové týmu a zúčastněné strany ponechají při přidávání textu prioritu prázdnou, a to i v případě použití elektronického nástroje, který je k zadání informace vyzve.

Po přidání příběhu provede vlastník produktu předběžné posouzení jeho priorit, založených na jeho znalostech.Probere příběh s jeho tvůrcem, aby ho lépe pochopil a následně mohl odpovídat otázkám týmu.V předem určené době během každého sprintu se vlastník produktu setká s týmem, aby prodiskutovali nové články a společně provedli jejich odhad, aby mohl přesněji stanovit jejich priority vzhledem k ostatním článkům v nevyřízených položkách.Tento proces se nazývá pečetění záložních položek.

Hh765980.collapse_all(cs-cz,VS.110).gifRozvíjení

Péči o rezervní položky produktu, jak bylo uvedeno dříve, je třeba provádět pravidelně.

Ve Scrum by měl tým strávit 5 % - 15 % svého času každý sprint přípravou.Tým musí porozumět blížícím se událostem a změnám, aby si mohli rozdělit všechny velké příběhy, kterým vzrůstá priorita, odhadnout rozsah veškerých vytvořených příběhů a provést některé vznikající návrhy a plánování nadcházejících příběhu.Chcete-li zajistit, aby k tomu docházelo, je třeba, aby vlastník produktu a tým během každého sprintu plánovali schůzky a vyčlenili nějaký čas během sprintu k začlenění rezervních položek společně.Další informace o plánování sprintu naleznete v částech Tisk hmotností plánování a Plánování iterace.

Během dvoutýdenního sprintu rád pořádám tuto schůzi v druhém týdnu.To dává vlastníkovi produktu dostatek času na smysluplné konverzace se zákazníky a zúčastněnými stranami, pochopit změny v jejich podniku a vyjasnit si příběhy uživatelů a příběhy, které jsou nové nebo mají vzrůstající prioritu.Je také logické během sprintu začít předvídat nadcházející sprinty.Můžete se rozhodnout, kdy chcete pozdržet setkání.Důležité je získat dostatek času během sprintu na dokončení činností údržby.

Během typické ošetřující schůze vlastník produktu představuje, co je nového, co se změnilo, a svůj plán pro dalších několik sprintů.Kromě odhadu nových články a rozdělení těch, které musí být dokončeny brzy, se tým během této schůzky věnuje kontrole aktuální architektury systému a plánování nebo návrhu nadcházejících funkcí.Během tohoto procesu se odhady článků často mění a dochází ke vzniku nových článků, když jsou větší články rozděleny do menších článků.

Tento proces se zdá být jednoduchý, ale může představovat tak trochu boj.Aby mohly věci fungovat hladce, vlastník produktu musí být připraven odpovědět na otázky.Konflikty mohou nastat například tehdy, pokud vlastník produkt plánuje dokončení článku v dalším sprintu, ale nemůže poskytnout jasné informace, které tým potřebuje k provedení dobrého odhadu.Pokud se tak stane během schůzek plánování běhů, měl by ScrumMaster vysvětlit majiteli produktu, jaké informace by měl od zákazníků a zúčastněných stran týmu přinášet.

Na konci každého setkání péče by měl vlastník produktu zveřejnit změny zúčastněným stranám a zákazníkům, aby všichni věděli, co je nového, co se chystá a jaký je aktualizovaný plán publikování.

Kvalitní rezervní položka produktu pomáhá zajistit, aby vytvářený software obsahoval nejdůležitější funkce podle konverzace se zákazníky a zúčastněnými stranami a podle definice v úlohách uživatelů.K vytvoření a udržení dobrého backlogu produktů se musíte aktivně zapojit do pravidelné komunikace se skupinou zúčastněných osob/zákazníků a týmem - každý sprint.

Vytváření kvalitních nevyřízených položek nezajišťuje kvalitní systém, ale nepřítomnost kvalitních nevyřízených položek téměř vždy vede k tomu, že máte systém, který neprovádí to, o co vás zákazníci požádali.Jinými slovy, nezachování aktuálnosti backlogu téměř vždy způsobí selhání projektu.

Vlastník produktu je zaměstnání na plný úvazek a jeho odpovědností jsou rezervní položky.Převezměte tuto roli vážně.Udržujte produktový backlog v dobrém stavu – vaši zákazníci vám poděkují.

Viz také

Koncepty

Začínáme pracovat v týmu

Agilní plánování a iterací

Žádost a názory účastníky procesu pomocí týmový Web Access

Sledování práce a správa pracovního postupu

Další zdroje

Získat nastavení a spuštění instalace jednoho serveru [kurzu]

Pokyny k procesům a šablony procesů pro Team Foundation Server