Pokyny k kumulativnímu toku, předstihu a cyklu
Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019
Pomocí kumulativních vývojových diagramů (CFD) můžete monitorovat tok práce prostřednictvím systému. Ze grafu je možné extrahovat dvě primární metriky, které se mají sledovat, čas cyklu a předstih. Pokud chcete nakonfigurovat nebo zobrazit grafy CFD, přečtěte si téma Konfigurace kumulativního vývojového diagramu.
Nebo můžete do řídicích panelů přidat řídicí grafy doby předstihu a cyklu času.
Ukázkové grafy a primární metriky
Cfd průběžného toku poskytuje graf, který nejvíce upřednostňuje týmy, které sledují štíhlý proces.
Řada týmů ale začala kombinovat štíhlé postupy se Scrumem nebo jinými metodologiemi, což znamená, že se procvičují v rámci iterace nebo sprintu. V této situaci diagram bere trochu jiný vzhled a poskytuje dva další a velmi cenné informace, jak je znázorněno v dalším grafu.
Průběžný tok
Pevné období, které se zde zobrazuje, je určené pro dokončený sprint.
Horní řádek představuje rozsah nastavený pro sprint. A vzhledem k tomu, že práce musí být dokončena do posledního dne sprintu, sklon uzavřeného stavu označuje, jestli je tým na cestě k dokončení sprintu. Nejjednodušší způsob, jak si toto zobrazení představit, je jako burnupový graf.
Data jsou vždy znázorněna prvním krokem v procesu jako vlevo nahoře a posledním krokem procesu jako vpravo dole.
Pevné období CFD pro dokončený sprint
Metriky grafu
Grafy CFD zobrazují počet pracovních položek seskupených podle stavu nebo sloupce v průběhu času. Ze grafu je možné extrahovat dvě primární metriky, které se mají sledovat, čas cyklu a předstih.
Metrika
Definice
Doba cyklu 1
Měří dobu potřebnou k pohybu mezi jedním procesem nebo stavem pracovního postupu. Výpočet je od začátku jednoho procesu až po začátek dalšího procesu.
Předstih 1
U procesu průběžného toku: Měří dobu, kterou trvá od okamžiku provedení požadavku (například přidání navrhovaného uživatelského scénáře), dokud se požadavek nedokončí (zavře).
Pro proces sprintu nebo pevného období: Měří čas od začátku práce na žádosti, dokud se práce nedokončí (tj. čas od aktivního do uzavřeného).
Probíhá práce
Měří množství práce nebo počet pracovních položek, které aktivně pracují.
Scope
Představuje množství práce potvrzené za dané časové období. Platí pouze pro procesy s pevným obdobím.
1 Widget CFD (Analytics) a předdefinovaný graf CFD (úložiště dat sledování práce) neposkytují diskrétní čísla pro předstih a čas cyklu. Widgety Doba předstihu a Doba cyklu však poskytují tato čísla.
Existuje dobře definovaná korelace mezi časem předstihu a cyklem a probíhající prací (WIP). Čím více WIP, tím delší doba cyklu, což také vede k delším časem předstihu. Opak je také pravdivý – čím méně WIP, tím kratší je cyklus a doba předstihu. Když se vývojový tým zaměřuje na méně položek, zkracuje cyklus a doby předstihu. Tato korelace je klíčovým důvodem, proč můžete a měli byste na panelu nastavit limity probíhající práce.
Počet pracovních položek označuje celkové množství práce v daném dni. V období s pevným obdobím CFD označuje změna rozsahu pro dané období. V průběžném toku CFD označuje celkové množství práce ve frontě a dokončeno pro daný den.
Rozložení práce do konkrétních sloupců panelu poskytuje zobrazení, kde probíhá práce. Toto zobrazení poskytuje přehled o tom, kde se práce hladce přesouvá, kde dochází k blokování a kde se vůbec nepracuje. Je obtížné dešifrovat tabulkové zobrazení dat, ale vizuální graf CFD poskytuje důkazy o tom, že se něco děje určitým způsobem.
Identifikace problémů, provedení vhodných akcí
CFD odpovídá na několik konkrétních otázek a na základě odpovědi, lze provést akce pro úpravu procesu pro pohyb v systému. Podívejme se na každou z těchto otázek.
Dokončí tým práci včas?
Tato otázka se vztahuje pouze na pevné období CFD. Získáte pochopení tím, že se podíváte na křivku (nebo průběh) práce v posledním sloupci desky.
V tomto scénáři může být vhodné zmenšit rozsah práce v iteraci, pokud je jasné, že se práce v stabilním tempu nedokončuje dostatečně rychle. Může to znamenat, že práce byla podceňována a měla by být zohledněna do dalšího plánování sprintů.
Mohou však existovat další důvody, které je možné určit zobrazením jiných dat v grafu.
Jak postupuje tok práce?
Pracuje tým stabilním tempem? Jedním ze způsobů, jak říct, je podívat se na mezery mezi různými sloupci v grafu. Jsou podobné nebo jednotné vzdálenosti od začátku do konce? Zobrazuje se sloupec jako plochý spojnicový za období několika dnů? Nebo se zdá, že je to "bulge"?
Mura, štíhlý termín pro ploché čáry a bulges, znamená nerovnoměrnost a označuje formu odpadu (Muda) v systému. Jakákoli nerovnoměrnost v systému způsobí, že se v CFD objeví bulfy.
Monitorování CFD pro ploché čáry a bulges podporuje klíčovou část procesu teorie omezení řízení projektů. Ochrana nejpomalejší oblasti systému se označuje jako proces buben-vyrovnávací lano a je součástí plánování práce.
Dva problémy se zobrazují vizuálně jako ploché čáry a jako bulgy.
Ploché čáry se zobrazí, když tým neaktualizuje svoji práci pravidelným tempem. Panel poskytuje nejrychlejší způsob, jak převést práci z jednoho sloupce na druhý.
Ploché čáry se můžou zobrazit také v případech, kdy práce napříč jedním nebo více procesy trvá déle, než je naplánováno. Ploché čáry se zobrazují napříč mnoha částmi systému, protože pokud má problémy pouze jedna část systému nebo dvě části systému, uvidíte vyprázdnění.
Ploché čáry
Při sestavování práce v jedné části systému dochází k bulgám a neprobíhá procesem.
Například k bulge může dojít, když testování trvá dlouhou dobu, zatímco vývoj trvá kratší dobu, což způsobuje, že práce se hromadí ve vývojovém stavu (bulges značí, že úspěšný krok má problém, ne nutně krok, ve kterém se bulge vyskytuje).
Boule
Jak vyřešíte problémy s tokem?
Problém nedostatku včasných aktualizací můžete vyřešit prostřednictvím:
- Denní stojany.
- Další pravidelné schůzky.
- Plánování e-mailu s připomenutím denního týmu
Systémové ploché problémy naznačují náročnější problém, i když tyto problémy jsou vzácné. Ploché čáry označují, že práce v systému byla zastavena. Základní příčiny můžou být:
- Blokování na úrovni celého procesu.
- Procesy trvá dlouho.
- Práce se mění na jiné příležitosti, které nejsou zachyceny na panelu.
Jedním z příkladů systémové ploché přímky může být funkce CFD. Práce na funkcích může trvat mnohem déle než práce na uživatelských příbězích, protože funkce se skládají z několika scénářů. V těchto situacích se buď očekává sklon (jako v příkladu výše), nebo je problém známý a tým už ho vyvolal jako problém. Pokud se jedná o známý problém, řešení problémů je mimo rozsah tohoto článku.
Týmy mohou proaktivně vyřešit problémy, které se zobrazují jako bulges CFD. V závislosti na tom, kde dochází k válení, se oprava může lišit. Předpokládejme například, že v procesu vývoje dochází k bulge. Bulge může nastat, protože spouštění testů trvá mnohem déle než psaní kódu. Testeři také můžou najít velký počet chyb. Když neustále přecházejí zpět na vývojáře, zdědí vývojáři rostoucí seznam aktivních prací.
Dvěma potenciálně snadnými způsoby řešení tohoto problému jsou: 1) Posun vývojářů z procesu vývoje na proces testování, dokud se nevyloučí, nebo 2) změnit pořadí práce tak, aby práce, kterou lze provést rychle, je propletena s prací, která trvá déle. Hledejte jednoduchá řešení pro odstranění bulgů.
Poznámka:
Vzhledem k tomu, že může dojít k mnoha různým scénářům, které způsobují nerovnoměrnou práci, je důležité provést skutečnou analýzu problému. CFD vám řekne, že došlo k problému a přibližně tam, kde je, ale musíte prozkoumat, abyste se dostali k původní příčině. Zde uvedené pokyny označují doporučené akce, které řeší konkrétní problémy, ale které se nemusí vztahovat na vaši situaci.
Změnil se obor?
Změny rozsahu se vztahují pouze na pevné období CFD. Horní čára grafu označuje rozsah práce. Sprint je předem načten s prací, která se má provést první den. Změny horního řádku označují, že byla přidána nebo odebrána práce.
K jednomu scénáři, kdy nemůžete sledovat změny rozsahu pomocí CFD, nastane, když se stejný počet pracovních položek přidá jako odebraný ve stejný den. Čára by nadále byla plochá. Porovnejte několik grafů s ostatními. Monitorujte konkrétní problémy. Pomocí zobrazení nebo konfigurace burndownu sprintu můžete monitorovat změny rozsahu.
Příliš mnoho WIP?
Můžete snadno sledovat , zda limity WIP byly překročeny z panelu. Můžete ho také monitorovat z CFD.
Velké množství WIP se obvykle zobrazuje jako svislá bulge. Čím delší je velké množství WIP, tím více se rozbalí, aby se stal oválným. Je to označení, že WIP negativně ovlivňuje cyklus a předstih.
Tady je dobré pravidlo pro probíhající práci. Na člena týmu by v daném okamžiku nemělo probíhat více než dvě položky. Hlavním důvodem dvou položek a přísnějších limitů je to, že realita často ruší jakýkoli proces vývoje softwaru.
Někdy získání informací od účastníka nějakou dobu trvá nebo získání potřebného softwaru trvá déle. Existuje několik důvodů, proč může dojít k zastavení práce. Druhá pracovní položka, která se má otočit, aby poskytovala nějaký prostor. Pokud jsou obě položky blokované, je čas zvýšit červený příznak, aby se něco odblokoval – ne jenom přepnout na jinou položku. Jakmile probíhá velký počet položek, bude mít osoba pracující na těchto položkách potíže s přepínáním kontextu. Je pravděpodobnější, že zapomenou na to, co dělali, a mohou nastat chyby.
Doba předstihu versus doba cyklu
Následující diagram znázorňuje, jak se doba předstihu liší od doby cyklu. Doba předstihu se vypočítá z vytvoření pracovní položky do zadání stavu Dokončeno. Doba cyklu se počítá od prvního zadání probíhající nebo vyřešené kategorie stavu k zadání kategorie Dokončeno.
Ilustrace doby předstihu a doby cyklu
Pokud pracovní položka přejde do stavu Dokončeno a pak se znovu aktivuje, jakýkoli čas navíc, který stráví v navrhovaném, probíhajícím nebo vyřešeném stavu, bude přispívat do doby vedoucího/cyklu, když přejde do kategorie Dokončeno již podruhé.
Pokud váš tým používá panel, budete chtít pochopit, jak se sloupce mapuje na stavy pracovního postupu. Další informace o konfiguraci panelu najdete v tématu Přidání sloupců.
Další informace o tom, jak systém používá kategorie stavů – Navrhované, Probíhá, Vyřešeno a Dokončeno – najdete v tématu Stavy pracovního postupu a kategorie stavů.
Plánování s využitím odhadu doby doručení na základě doby potenciálního zákazníka/cyklu
K odhadu doby doručení můžete použít průměrnou dobu předstihu a cyklus a směrodatné odchylky.
Při vytváření pracovní položky můžete k odhadu, kdy tým dokončí tuto pracovní položku, použít průměrnou dobu vedoucího týmu. Směrodatná odchylka vašeho týmu vám řekne variabilitu odhadu. Podobně můžete použít čas cyklu a jeho směrodatnou odchylku k odhadu dokončení pracovní položky po zahájení práce.
V následujícím grafu je průměrná doba cyklu osm dní. Směrodatná odchylka je +/- šest dnů. Pomocí těchto dat můžeme odhadnout, že tým dokončí budoucí uživatelské scénáře přibližně 2 až 14 dní po zahájení práce. Čím užší je směrodatná odchylka, tím předvídatelnější odhady.
Příklad widgetu Doba cyklu
Identifikace problémů s procesy
Projděte si řídicí graf týmu pro odlehlé hodnoty. Odlehlé hodnoty často představují základní problém s procesem. Například čekání na dokončení kontrol žádostí o přijetí změn příliš dlouho nebo rychlé řešení externí závislosti.
Jak vidíte v následujícím grafu, který ukazuje několik odlehlých hodnot, dokončení několika chyb trvalo déle, než je průměr týmu. Zkoumání, proč tyto chyby trvaly déle, můžou pomoct odhalit problémy s procesem. Řešení problémů s procesem může pomoct snížit směrodatnou odchylku vašeho týmu a zlepšit předvídatelnost vašeho týmu.
Příklad widgetu Doba cyklu zobrazující několik odlehlých hodnot
Můžete se také podívat, jak změny procesu ovlivňují dobu potenciálního zákazníka a cyklus. Například 15. května se tým snažil omezit WIP a řešit zastaralé chyby. Můžete vidět, že směrodatná odchylka se po tomto datu zúží a zobrazuje lepší předvídatelnost.