Agilní plánování vydání: pojďme to rozebrat!

parafrází známého konceptu v projektovém řízení by se dalo říci: „plánování je nepostradatelné ,ale plány jsou zbytečné. Proto zkontrolujte a přizpůsobte se.“

tradiční plány jsou řízeny daty-s největší pravděpodobností je primárním hnacím faktorem Datum ukončení. V tradičním řízení projektů shromažďujete požadavky od svých zúčastněných stran, vytváříte rozsah projektu a rozdělujete Projekt na zvládnutelné práce. To zase vytváří strukturu rozdělení práce (WBS). Dále se nejnižší úroveň WBS, tj. pracovní balíčky, dále rozloží na aktivity. Aktivity jsou pak spojeny se závislostmi a zdroje jsou odhadovány a aplikovány na aktivity k vytvoření koncového plánu projektu. Tento plán je poté sledován a kontrolován pomocí plánu řízení harmonogramu, který je obvykle pomocným plánem konsolidovaného plánu řízení projektu.

ale kolikrát se stalo, že to, co jste plánovali a co se skutečně stalo na zemi, se shodovalo? Odpověď už znáte! Úvodní nabídka znamená, že plánování je nezbytné, ale očekávat, že se můžeme přesně řídit plánem, není moudré. Pokud existují vysoké požadavky na požadavky a vysoká nejistota v technologii nebo platformě, PMs obvykle chodí s adaptivními (nebo agilními) životními cykly.

ve skutečnosti čtvrtá hodnota v agilním manifestu říká: „reagovat na změnu oproti plánu.“Agile je řízen změnou a s největší pravděpodobností budou tyto změny poháněny zákazníky. To vede k konceptu nazvanému Agile Release Planning.

plánování vydání je na rozdíl od tradičního plánování, kde je kompletní plán považován předem, podrobně rozpracován a může být změněn pouze formálními požadavky na změnu. Plán vydání lze mnohokrát aktualizovat na základě zpětné vazby z předchozích iterací.

protože adaptivní životní cykly jsou Inkrementální povahy, organizace se mohou uvolnit na konci každé iterace. Mohou se také rozhodnout uvolnit po několika iteracích nebo dokonce nepřetržitě. To vyžaduje dlouhodobější plánování,ale může být účinně usnadněno využitím techniky plánování vydání, který byl nově představen v 6. vydání průvodce PMBOK.

pro začínající profesionály v řízení projektů (PMP) a certifikované spolupracovníky v řízení projektů (CAPM) je agilní plánování vydání klíčovým konceptem , který je třeba znát. PMBOK Guide 6. vydání zavedlo agilní úvahy pro každou oblast znalostí. To je také užitečné pro začínající agilní certifikované odborníky (ACP).

jak se do toho dostáváme více, podívejme se nejprve na to, jak jsou plány vydání vyvíjeny na vysoké úrovni.

od vize k plánu k uvolnění plánů

v agilních projektech začíná práce s vizí produktu. Vize se pak promítá do plánu produktu. Plán obsahuje funkce, které mají být vyvinuty po určitou dobu. Můžete také říci, že plán představuje rozsah produktu, který je dodáván v různých verzích. To vede k plánům vydání a je znázorněno na obrázku níže.

Plán a Produktový Backlog

Jedna složka ve výše uvedeném pořadí je výrobek, plán, a pochopit, výrobek, plán, nejprve musíme pochopit, produktový backlog. V agilních přístupech jsou všechny požadavky – požadavky projektu i požadavky na produkt – součástí Product backlog (PB). Každá položka v produktu backlog se nazývá položka produktu backlog (nebo PBI). Kromě funkcí (požadavků) může být položkou nevyřízeného produktu požadavek na změnu, závada, chyba, problém nebo dokonce konkrétní technická práce.

jak víme, v agilních projektech se požadavky neustále vyvíjejí a existují značné nejistoty/rizika. V důsledku toho obvykle upřednostňujeme PBI. Prioritní PBI jsou převzaty z horní části nevyřízených položek a doručeny zákazníkovi(zákazníkům). Položky s vysokou prioritou zůstávají na vrcholu nevyřízených položek a jsou jemnozrnné, zatímco položky s nízkou prioritou jsou na dně nevyřízených položek a hrubozrnné. Prioritizace položek v PB určuje úroveň podrobností pro danou položku v nevyřízených položkách produktu. To je znázorněno na následujícím obrázku.

pokud používáte agilní nástroje, jako je Microsoft Project, můžete produkt backlog rychle vyvinout. Příklad produktu backlog, nakreslený pomocí projektu MS, je uveden níže.

zde máme Product backlog zobrazující položky Product backlog (PBI) „vytvořit nového uživatele“, „přihlásit se do online obchodního systému“,“ převést akcie “ atd. Pokud byste chtěli přidat další položku nevyřízených položek, stačí kliknout na ikonu “ + „v příkazovém poli“ Nová úloha“.

položky nejvyšší úrovně v produktu backlog mohou být zapsány do uživatelských příběhů, které jsou odhadovány v příběhových bodech-relativní míra bez jednotky.

Teď přichází na produkt plán, můžete jednoduše říci, že je produktový backlog s časovou osou. Plán popisuje plánovaná budoucnost projektu (tj. plánovaných a/nebo navrhovaných produktů) nebo uvolnění témata, výpis vysoké úrovni funkčnost výrobku. Plán říká, jaké funkce nebo eposy (epos, jednoduše řečeno, je velký uživatelský příběh) budou dodány v každém vydání.

Plán vydání

plán produktu řídí plány vydání. Plán vydání dává plán vydání-každé vydání je obvykle tři až šest měsíců. Vydání obsahuje mnoho iterací – od Iterace 0 (iterace nula) na Iteraci N. Iterace 0 může být použit pro schválení projektu, nastavení prostředí pro projekt, počáteční přehled a design, diskuse, atd. Někteří agilní praktici používají iteraci-H (kalení iterace), což je poslední iterace na konci vydání k přípravě na doručení. Tato iterace může zahrnovat závěrečné pracovní položky, jako jsou školicí a marketingové materiály, závěrečné poznámky k vydání, instalační příručky, systémové / uživatelské příručky atd. To je znázorněno níže.

Jak je vidět, vydání plánu iterací – od „Iterace – 0“ až „Iterace – N.“ se můžete rozhodnout vydat po několika iterací a/nebo konečné verzi po poslední iteraci.

plán vydání představuje plán, jak má tým v úmyslu dosáhnout vize projektu v rámci cílů a omezení projektu. Pomáhá vlastníkovi produktu a celému týmu rozhodnout, kolik musí být vyvinuto a jak dlouho bude trvat, než budou mít uvolnitelný produkt. Vyjadřuje očekávání ohledně toho, co bude pravděpodobně vyvinuto a v jakém časovém rámci. Plán uvolnění může také sloužit jako vodítko, ke kterému může tým postupovat. Plán vydání může být aktualizován na konci iterace a odráží aktuální očekávání, která budou zahrnuta, takže mohou být dodána v následujících iteracích.

plánování vydání s produktem Backlog

Chcete-li lépe porozumět plánování vydání, můžete vizualizovat plány vydání pomocí produktu backlog.

již víme, že položky v produktu backlog jsou seřazeny nebo seřazeny podle jejich priority. Položky nejvyšší úrovně, které jsou jemně zrnité, budou připraveny ke spotřebě v další iteraci(pod okamžitým dalším vydáním). Prioritní nevyřízené položky s funkcemi a dalšími položkami jsou zobrazeny na levé straně obrázku níže.

V MS Project, si prostě musí vybrat, přetáhněte a umístěte nevyřízené položky a uspořádat je dle své potřeby na jejich priority. To je znázorněno na pravé straně obrázku výše. S ohledem na předchozí příklad ukazuje produktový backlog v MS Project, máme relativní pořadí: první „Přihlaste se do on-line systému obchodování,“ další „Vytvořit nového uživatele“, pak „Koupit akcie“, atd.

, Jak je uvedeno výše, vybral jsem a táhl funkce položku „Přihlášení do on-line obchodního systému“ a hodil ji před dříve funkce položku „Vytvořit nového uživatele.“Vybraná položka byla mírně šedá, když jsem ji táhl a upustil.

pomocí backlog můžete rozhodnout, která z položek backlog by měla být doručena v příštích verzích. Níže vidíme, že položky v příštím vydání (tj. Položky pro vydání 2 mohou být také upřednostňovány, ale vidíme, že položky pro vydání 3 nejsou upřednostňovány, protože se jedná o položky s nízkou prioritou.

můžete si představit toto plánování vydání s MS Project, stejně. Podívejte se na obrázek níže. Tam jsou PBI prokázáno, že být přijata v různých verzích. Pamatujete si, že vydání obsahuje iterace? V našem případě máme pro první vydání tři iterace a očekává se, že všechny položky budou dodány v těchto iteracích. Iterace se nazývá sprint v rámci Scrum, což je populární rámec používaný Agile PMs. Release 2 a Release 3), máme PBI, ale ještě jsme se nerozhodli o iteracích (nebo sprintech).

Iterační Plánování

Pokud jste postupovali, uvolnění plán se skládá z Opakování 0 Opakování N a můžeme rozhodnout o uvolnění na konci každých několik iterací nebo každé iteraci. Ale, co se stane v iteraci? Jednoduše řečeno, prostor pro sadu funkcí v iteraci je potvrzen na začátku iterace a doručen na konci iterace.

funkce, které jsou potvrzeny a přijaty pro iteraci, jsou rozděleny na úkoly (nebo činnosti) a odhadovány členy týmu v hodinách. Pořadí kroků od plánu produktu k plánu vydání k plánu iterace je znázorněno na obrázku níže.

Shrneme-li výše uvedený obrázek, budou to klíčové body:

  • výrobek je vize disky product roadmap
  • Produktového plánu disky uvolnit plány,
  • uvolnění plán bude mít iterací
  • Prvky, které jsou odhadovány v příběhu bodů, jsou vyvinuty v iteraci
  • Funkce jsou členěny na úkoly, které jsou odhadovány v hodinách

Pomocí MS Project 2016, můžete vytvořit plán pro uvolnění rychle. Vzhledem k našemu předchozímu příkladu nevyřízených položek máme pro první vydání tři iterace/sprinty (tj. Sprint 1, Sprint 2 a Sprint 3). Každý sprint má sadu funkcí, které mají být dodány. To je uvedeno níže v zobrazení“ plánovací deska sprintu“.

můžete také přejít dolů a zjistit, co se děje na úrovni iterace/sprintu, a zjistit, na kterých PBI se pracuje. MS Project to ukazuje v zobrazení“ aktuální Sprint Board“. Viz obrázek níže.

Pro Sprint 1, máme tři položky, které mají být dodány – „Přihlaste se do on-line systému obchodování,“ „Vytvořit nového uživatele“ a „Koupit akcie.“Procházejí třemi stavy pracovního postupu „další na řadě“, „probíhá“ a „Hotovo“.“Samozřejmě můžete přidat, odebrat nebo přizpůsobit tyto stavy pracovního postupu podle vaší potřeby.

Release Plan Vs. iterační plán

Pokud přijímáte zkoušku, musíte také znát rozdíly mezi plánem vydání a iteračním plánem. Jsou uvedeny v následující tabulce. Typicky, iterace jsou timeboxed po dobu dvou až čtyř týdnů. V některých případech, jako je XP (další agilní rámec), však iterace mohou trvat jeden týden.

Project Management body of Knowledge (PMBOK) Guide, 6th Edition, Project Management Institute (PMI)
Chci Být PMP: Prostý a Jednoduchý Způsob, jak Být PMP, 2. vydání, Satya Narayan Dash
Chci Být AKT: Prostý a Jednoduchý Způsob, jak Být AKT, Satya Narayan Dash
Microsoft Project 2016 Živé Lekce, podle Satya Narayan Dash
Agilní Praxe Průvodce, podle Project Management Institute (PMI)

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.

Previous post HFH Prince William County
Next post 2. Vzhled: Marker Kingpin 13