Konfigurace a přizpůsobení Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019
Azure Boards můžete nakonfigurovat a přizpůsobit mnoha způsoby, abyste mohli lépe spravovat portfolio, závislosti a monitorování. Doporučujeme úkoly popsané v tomto článku zejména pro správce, kteří zodpovídají za správu projektů s více týmy.
Rychlý přístup k běžným úkolům:
Přizpůsobte si karty | Správa sloupců | , které urychlují práci s plaveckou drahou | , nakonfigurujte backlog.
Poznámka:
Většina pokynů v tomto článku je platná pro cloudové i místní verze. Některé funkce zahrnuté v tomto článku, jako jsou například kumulativní, analytické a některé nástroje pro plánování portfolia, jsou ale v tuto chvíli dostupné jenom pro cloud.
Pokud teprve začínáte jako správce projektu, přečtěte si také článek Začínáme jako správce.
Důležité informace
Abyste mohli Azure Boards využívat na maximum, porozumíte tomu, jak vaše týmy používají své nástroje a funkce (například Scrum, Kanban a Scrumban) a jejich závislosti na konfiguracích a přizpůsobeních. Následující tabulka shrnuje primární položky, které byste měli zvážit při strukturování projektu.
Úroveň projektu
- Kolik týmů chcete definovat
- Strukturování cest oblastí pro podporu zobrazení správy portfolia
- Přizpůsobení polí
- Vlastní typy pracovních položek (WIT)
- Přizpůsobení backlogu portfolia
- Přizpůsobení pracovního postupu
Úroveň týmu
- Jak pomocí backlogu produktů naplánujete a upřednostníte svou práci
- Bez ohledu na to, jestli sledujete chyby jako požadavky nebo jako úkoly, nebo vůbec nepoužíváte chyby
- Bez ohledu na to, jestli ke sledování času a kapacity používáte úkoly
- Jak používat úrovně backlogu portfolia
- Jak informujete o horním řízení průběhu, stavu a rizik
Přizpůsobte si stavební bloky a nástroje pro sledování práce tak, aby podporovaly obchodní potřeby, a komunikujte s týmem pokyny k používání.
Typy pracovních položek a backlogy portfolia
Při vytváření projektu v Azure Boards nejprve vyberete proces. Každý proces (Agilní, Základní, Scrum a CMMI) podporuje hierarchii pracovních položek, včetně backlogů produktů a portfolia. Výchozí pracovní položky pro každý proces jsou uvedeny na odpovídajících kartách s backlogy v části Požadavky a úkoly v části Úkol.
Následující obrázek znázorňuje hierarchii pracovní položky backlogu agilního procesu:
- Uživatelské scénáře a úkoly slouží ke sledování práce.
- Chyby sledují vady kódu.
- Náměty a funkce slouží k seskupení práce ve větších scénářích.
Každý tým může nakonfigurovat způsob správy pracovních položek chyby na stejné úrovni jako pracovní položky uživatelského scénáře nebo úkolu. Použijte nastavení Práce s chybami. Další informace o použití těchto typů pracovních položek naleznete v tématu Agilní proces.
Na každé úrovni můžete přidávat vlastní wity a dokonce přidávat vlastní backlogy portfolia. Tady je například projekt, který do procesu Scrum přidal cíle a klíčové výsledky jako vlastní interní položky a odpovídající backlogy portfolia.
Možnosti sledování práce a doporučené využití
Týmy si můžou vybrat, které pracovní položky používají ke sledování své práce. Následující tabulka shrnuje hlavní možnosti, doporučené využití a podporované úlohy a nástroje.
Možnosti sledování práce
Podporované úlohy a nástroje
Pouze úkoly
Nedoporučuje se
V backlogu není žádný způsob, jak rychle zadávat nové úkoly, ani určovat prioritu backlogu úkolů. Také neexistuje podpora zobrazení kalendáře, zobrazení mezi týmy ani plánování portfolia.
Požadavky s podřízenými úkoly
Podporuje metody Scrum
Doporučuje se pro týmy, které sledují metody Scrum a chtějí sledovat čas spojený s prací.
- Rychlé definování a stanovení priority položek backlogu: Backlog produktu
- Prognózování sprintů s využitím týmové rychlosti: Prognóza
- Plánování sprintů: Nástroj pro plánování backlogu
- Plánování a sledování kapacity: Nástroj kapacity sprintu
- Sledování odhadované a zbývající práce: Taskboard
- Monitorování burndownu sprintu na základě zbývající práce, jako jsou hodiny nebo dny: Burndown sprintu
- Provádění denních scrumů, aktualizací a monitorování stavu úkolů: Panel úkolů sprintu
- Odhad práce: Definování bodů scénáře, úsilí nebo velikosti
- Zobrazení indikátorů průběhu, počtů nebo součtů souhrnů u úkolů: Souhrn
- Sledování závislostí napříč týmy a projekty: Plány doručení
Mnoho týmů začíná pomocí metod Scrum sledovat a plánovat svou práci pomocí nástrojů dostupných prostřednictvím centra Sprints. Nástroje Sprints podporují odhad a sledování zbývající práce a využití plánování kapacity. Pokud tyto nástroje neplánujete používat, je přidání podřízených úloh volitelné. Vývojáři je můžou přidat jako kontrolní seznam položek, které potřebují k dokončení uživatelského scénáře nebo požadavku backlogu.
Pouze požadavky, jako jsou uživatelské scénáře (Agilní), problémy (Základní), položky backlogu produktů (Scrum), požadavky (CMMI)
Podporuje metody Kanban a Scrumban.
Doporučeno pro týmy, které sledují metody Kanban nebo Scrumban, odhadují práci pomocí bodů scénáře, úsilí nebo velikosti a nesledují čas spojený s prací.
- Rychlé definování a stanovení priority položek backlogu: Backlog produktu
- Plánování sprintů: Nástroj pro plánování backlogu
- Odhad práce: Definování bodů scénáře, úsilí nebo velikosti
- Prognózování sprintů s využitím týmové rychlosti: Prognóza
- Monitorování burndownu sprintu na základě odhadů požadavků: Burndown sprintu
- Stav požadavku aktualizace: Panel Kanbanu
- Sledování závislostí napříč týmy a projekty: Plány doručení
Požadavky seskupené v rámci pracovních podmínek portfolia, jako jsou náměty a funkce
Podporuje zobrazení kalendáře, zobrazení napříč týmy a plánování portfolia.
Doporučeno pro organizace s několika týmy, které chtějí zobrazit souhrny a zobrazení kalendáře přidružené k více týmům, a využít výhod všech nástrojů pro plánování portfolia.
- Rychlé definování a stanovení priorit položek portfolia: Backlogy portfolia
- Rychlé definování podřízených uživatelských scénářů položek portfolia: Kontrolní seznamy portfolia
- Mapování pracovních položek na funkce a náměty: Nástroj mapování
- Zobrazení zobrazení kalendáře průběhu napříč týmy: Plány doručení
- Zobrazení zobrazení kalendáře všech funkcí týmu: Časová osa funkcí
- Zobrazení zobrazení kalendáře konkrétního námětu: Plán námětu
- Zobrazení indikátorů průběhu, počtů nebo součtů souhrnů u podřízených položek: Souhrn
- Sledování závislostí napříč týmy a projekty: Plány doručení
Možnosti konfigurace a přizpůsobení
Následující tabulka uvádí oblasti, které můžete nakonfigurovat a přizpůsobit, a nástroje ovlivněné těmito přizpůsobeními. Každou oblast můžete přizpůsobit na úrovni organizace, projektu nebo týmu, jak je uvedeno, nebo kombinaci dvou. Popis standardních nástrojů, analytických nástrojů a nástrojů pro plánování portfolia najdete v tématu Co je Azure Boards, sestavy v kontextu: Sledování práce a plány (agilní ve velkém měřítku).
Konfigurace nebo přizpůsobení
Standardní nástroje
Analytické nástroje
Nástroje pro plánování portfolia
Cesty oblastí, konfigurace projektu a týmová předplatná (Projekt, Tým)
- Panely>– všechny nástroje
- Backlogy>– Všechny nástroje
- Sprinty>– všechny nástroje
- Diagram kumulativního toku
- Rychlost
- Trend burndownu
- Delivery Plans
- Časová osa funkcí
- Plán námětu
- Plány portfolia (beta verze)
Cesty iterace, konfigurace projektu a týmové předplatné (projekt, tým)
- Plánování sprintů backlogů>
- Backlogy sprintů sprintů>
- Kapacita sprintů sprintů>
- Taskboard sprintů>
- Rychlost
- Trend burndownu
- Delivery Plans
- Časová osa funkcí
- Plán námětu
- Plány portfolia (beta verze)
Zobrazení chyb v backlogech a panelech (tým)
Vlastní wity, backlog produktu (proces)
Vlastní pracovní položky, taskboard (proces)
- Desky Produktová>deska
- Backlogs Product backlogs>
- Nástroj Mapování backlogů>
- Backlogy sprintů sprintů>
- Taskboard sprintů>
- Rychlost
Vlastní wity, backlog portfolia (proces)
Další backlogy portfolia (proces)
- Panely>portfolia
- Backlogy Portfolia backlogs>
- Nástroj Mapování backlogů>
- Rychlost
Vlastní pracovní postup (proces)
- Desky Produktová>deska
- Panely>portfolia
- Taskboard sprintů>
- Diagram kumulativního toku
Vlastní pole (proces)
- Desky Produktová>deska
- Panely>portfolia
Cesty oblastí, produktové týmy a správa portfolia
Pomocí cest oblastí můžete seskupit pracovní položky podle produktů, funkcí nebo obchodních oblastí a podporovat týmy zodpovědné za práci přiřazenou těmto oblastem. Můžete definovat hierarchickou sadu plošných cest nebo plochou sadu. Obvykle definujete hierarchickou sadu cest oblastí, která podporuje obchodní hierarchii, která chce sledovat průběh několika týmů.
Cesty oblastí a hierarchické seskupení
Dva hlavní způsoby seskupení pracovních položek jsou podle cesty oblasti a jejich nadřazení v rámci pracovní položky portfolia, jak je popsáno dříve v tomto článku. Oba se vzájemně nevylučují. Tady jsou jejich rozdíly:
- Cesty oblastí přiřazené týmu určují, které pracovní položky se zobrazují v týmovém zobrazení: backlog produktů, backlog portfolia, plány doručení nebo jiný nástroj pro plánování portfolia.
- Seskupení pracovních položek v rámci nadřazené funkce nebo námětu určují, jaká souhrnná zobrazení jsou podporovaná a jak se práce zobrazuje v nástroji pro plánování portfolia
Značky můžete také přiřadit pracovním položkám, abyste je seskupili pro účely dotazu a filtrování. Proto při strukturování týmů a projektů se ujistěte, že rozumíte tomu, jak tyto nástroje seskupování používáte k podpoře vašich obchodních potřeb. Vaše volby ovlivňují použití nástrojů pro plánování portfolia.
Nástroje závislé na cestě oblasti
Chcete-li provést následující úlohy, musíte definovat cesty oblasti:
- Dotazování a graf pracovních položek na základě cesty oblasti
- Přiřazení práce více než jednomu týmu
- Práce s týmy pro správu a funkce
- Filtrování backlogu, dotazu, panelu nebo plánu pomocí cest oblastí
Tip
Můžete definovat strukturu cest oblasti a přiřadit cesty k oblastem týmům. Nebo můžete přidat tým a vytvořit cestu k oblasti s názvem týmu v té době. Pokud jsou týmy plně nezávislé, vytvořte plochou sadu plošných cest. Pokud ale chcete vytvořit hierarchii týmů, budete chtít vytvořit stromovou hierarchii cest oblastí. Další informace najdete v tématu Konfigurace hierarchie týmů.
Pokud chcete použít následující nástroje, musí se týmy přihlásit k odběru cest oblastí:
Cesty k oblasti a přiřazení týmu
Každý projekt má výchozí tým a výchozí cestu k oblasti. V některých případech existuje jenom jeden tým, který plánuje a sleduje práci. S růstem organizací ale můžete přidat další týmy pro správu backlogu a sprintů.
Následující příklad ukazuje cesty oblastí a jejich přiřazení týmům, které podporují zobrazení správy portfolia pro týmy pro správu účtů a doručování služeb.
Další informace najdete v následujících článcích:
Doporučení:
- Zvažte, co musí horní správa vědět a jak je nejlépe podporovat.
- Zvažte, jak chcete pro týmovou správu i správu portfolia používat kumulativní aktualizace.
- Definování námětů a scénářů pro velké iniciativy, které k dokončení vezmou dva nebo více sprintů
- Vytvoření hierarchických cest oblastí pro podporu dílčích kategorií funkcí a oblastí produktů
- Definujte požadavky na práci, které lze provést v jednom sprintu, a lze je přiřadit jednomu jednotlivci.
- Definování úkolů pro sledování podrobnějších podrobností nebo sledování času stráveného prací
Tip
- Pracovní položku můžete přiřadit pouze jednomu jednotlivci. Při definování pracovních položek zvažte, kolik pracovních položek potřebujete a komu je přiřadit.
Node Name
Zvolte pole jako možnost sloupce a zobrazte uzel oblasti typu list v seznamu backlogu nebo kartě panelu. Další informace naleznete v tématu Přizpůsobení karet.- Nevytvádějte propojení nadřazenosti a podřízenosti mezi pracovními položkami stejného typu, jako je story-story, bug-bug, task-task.
Většina nástrojů Azure Boards podporuje filtrované zobrazení pracovních položek na základě cesty oblasti nebo cesty iterace. Můžete také použít další filtry založené na klíčových slovech, přiřazeních, wit a dalších možnostech.
Chyby jako požadavky nebo úkoly
Každý tým si může vybrat, jak chce spravovat chyby. Některé týmy chtějí sledovat chyby spolu s požadavky na backlog. Ostatní týmy chtějí sledovat chyby jako úkoly prováděné při podpoře požadavku. Chyby se pak zobrazí na svém panelu úloh.
Pokud používáte proces Scrum, je výchozím nastavením sledování chyb spolu s položkami backlogu produktu (PBI). Pokud pracujete v projektu na základě agilních procesů nebo procesů CMMI, chyby se v backlogu automaticky nezobrazí.
Zjistěte u svého týmu, jak chcete spravovat chyby. Potom odpovídajícím způsobem změňte nastavení týmu.
Tip
Po aktualizaci backlogu nebo panelu a tam, kde je očekáváte, nevidíte chyby, přečtěte si , jak backlogy a panely zobrazují hierarchické (vnořené) položky. Na panelech úkolů sprintu se zobrazují jenom uzly typu list s vnořenými položkami.
Systémové wity v backlogu
Pokud chcete sledovat problémy nebo překážky spolu s vašimi požadavky nebo v backlogu portfolia, přidejte je do vlastního zděděného procesu. Další informace najdete v tématu Přizpůsobení backlogů nebo panelů (proces dědičnosti).
Správa souhrnů, hierarchie a portfolia
Sloupce souhrnů umožňují zobrazit indikátory průběhu nebo součty číselných polí nebo následných položek v hierarchii. Následné položky odpovídají všem podřízeným položkám v hierarchii. Do produktového backlogu nebo backlogu portfolia můžete přidat jeden nebo více sloupců souhrnů.
Tady zobrazujeme průběh u všech pracovních položek, které zobrazují indikátory průběhu vzestupných pracovních položek na základě procenta uzavřených potomků.
Plány doručení podporují souhrnná zobrazení námětů, funkcí a dalších vlastních backlogů portfolia.
Cesty iterace – sprinty vydaných verzí a správy verzí
Cesty iterace podporují procesy Scrum a Scrumban, kde je práce přiřazena k nastavenému časovému období. Cesty iterace umožňují seskupit práci do sprintů, milníků nebo jiných období týkajících se událostí nebo času. Každá iterace nebo sprint odpovídá pravidelnému časovému intervalu, který se označuje jako tempo sprintu. Typická četnost sprintů jsou dva týdny, tři týdny nebo dlouhé měsíce. Další informace naleznete v tématu o oblastech a iteračních cestách.
Cesty iterace můžou být plochý seznam nebo seskupené pod milníky vydané verze, jak je znázorněno na následujícím obrázku.
I když cesty iterace nemají vliv na nástroje panelu, můžete použít cesty iterace jako filtr na panelech. Další informace najdete v tématu Filtrování panelu.
Definujte cesty iterace a přiřaďte je týmům, když chcete použít následující nástroje:
Tip
Pokud se tým nepřihlásil k odběru nebo vybral cestu iterace, cesta iterace se nezobrazí v zobrazení nebo nástroji týmu.
Sledování času
Většinaorganizacích Nástroje Azure Boards plně podporují dobu sledování pro tento účel. Použité hlavní pole je pole úkolu Remaining Work
, které obvykle vynuluje na konci sprintu.
Některé organizace ale vyžadují sledování času, aby podporovaly jiné účely, například pro fakturaci nebo udržování záznamů o přidělování času. Hodnoty času pro odhadovanou práci a dokončenou práci jsou zajímavé. Procesy Agile a CMMI poskytují tato pole –Remaining Work
Original Estimate
Completed Work
, – pro použití při sledování času. Můžete je použít pro tento účel. Azure Boards ale poskytuje omezenou nativní podporu pro sledování času. Místo toho zvažte použití rozšíření Marketplace pro podporu dalších požadavků na sledování času.
Poznámka:
Pole Original Estimate
, Completed Work
byla navržena tak, Remaining Work
aby podporovala integraci s Microsoft Projectem. Podpora integrace s Microsoft Projectem je pro Azure DevOps Server 2019 a novější verze, včetně cloudové služby, zastaralá.
Zpracování změn, které mají vliv na všechny týmy
Jakákoli změna procesu v projektu má vliv na všechny týmy v daném projektu. Mnoho změn nezpůsobuje velké přerušení týmů, které podporují, ale následující změny.
Vlastní pole
Když do wit přidáte vlastní pole, nebude to mít přímý vliv na žádný konkrétní nástroj. Místo toho se tato pole zobrazí v odpovídajících pracovních položkách. Pokud například zavádíte vlastní číselné pole, můžete ho využít pro souhrnné výpočty v backlogech. Toto vlastní pole můžete také použít s následujícími nástroji pro vytváření sestav. Takže i když efekt není specifický pro konkrétní nástroj, vylepšuje vaši schopnost přizpůsobit pracovní položky potřebám projektu.
- Widget pro sestavu a řídicí panel v kontextu
- Widget sestavy a řídicího panelu sprintu v kontextu
- Widget Burndown a Burnup řídicího panelu
Poznámka:
Všechna výchozí a vlastní pole se sdílí ve všech projektech v kolekci nebo organizaci. Existuje limit 1024 polí, která můžete definovat pro proces.
Vlastní wity
Následující tabulka ukazuje efekty, když přidáte vlastní wit do konkrétní kategorie.
Úkol
Požadavek
Námět nebo funkce
- Podřízené pracovní položky nové pracovní položky nové pracovní položky se zobrazí v backlogu produktu.
- Pracovní položky založené na nové pracovní položkách se zobrazí v backlogech sprintu a v panelech úkolů.
- Pracovní položky založené na nové pracovní položce se zobrazí v backlogu produktu a \board
- Každý tým musí nakonfigurovat \board tak, aby podporoval novou wiT.
- Pracovní položky založené na nové pracovní položkách se zobrazují v odpovídajících backlogech portfolia a panelech.
- Každý tým musí nakonfigurovat \boards tak, aby podporoval novou WIT.
- Nové nástroje pro plánování portfolia se nemusí zobrazovat na jednom nebo několika nástrojích pro plánování portfolia.
Vlastní pracovní postup
Každý proces podporuje výchozí pracovní postup. Tento pracovní postup definuje výchozí sloupce, které se zobrazují na panelech a v úkolových panelech sprintu.
Stavy pracovního postupu: Uživatelský scénář, agilní proces
Někdy týmy chtějí sledovat stav své práce, která přesahuje tyto výchozí stavy. Podpora je poskytována jedním z následujících způsobů:
- Přidání vlastních stavů pracovního postupu do pracovní položky: Tato možnost má vliv na všechny týmy a vyžaduje, aby aktualizovali konfiguraci panelu.
- Přidání sloupců na panel: Tato možnost má vliv jenom na tým, který sloupce přidá.
Stavy pracovního postupu i sloupce se zobrazí v diagramu kumulativního toku pro tým. Jednotlivci můžou zvolit, které sloupce se v grafu zobrazí. Další informace naleznete v tématu Kumulativní vývojový diagram.
Kdo může provádět změny?
Vzhledem k tomu, že nastavení na úrovni procesu, na úrovni projektu a na úrovni týmu může mít široký vliv, změny se omezují na uživatele s následujícími požadovanými oprávněními.
Změny na úrovni procesu
Pokud chcete vytvářet, upravovat nebo spravovat zděděné procesy a aplikovat je na projekty, musíte být členem skupiny Správci kolekce projektů. Nebo musíte mít odpovídající oprávnění Vytvořit proces, Odstranit proces, Upravit proces nebo Odstranit pole z organizace nastavené na Povolit. Viz Nastavení oprávnění a přístupu pro sledování práce, Přizpůsobení zděděného procesu.
Další informace najdete v následujících článcích:
Změny na úrovni projektu
Chcete-li přidat cesty oblasti nebo cesty iterace, musíte být členem skupiny Správci projektu.
Pokud chcete přidat, upravit a spravovat cesty oblasti nebo cesty iterace pod konkrétním uzlem, musíte mít jednu nebo více následujících oprávnění nastavená na Povolit:
- Vytvoření podřízených uzlů
- Odstranit tento uzel
- Upravit tento uzel
- Zobrazit oprávnění v tomto uzlu
Další informace najdete v následujících článcích:
- Definování cest oblastí a přiřazení týmu
- Definování iteračních cest (sprintů) a přiřazení iterací týmu
Změny na úrovni týmu
Abyste mohli konfigurovat týmové nástroje, musíte být správcem týmu nebo členem skupiny Project Administrators.
Správci týmu dělají následující operace:
- Přidání členů týmu
- Přihlášení k odběru oblastí a cest iterace
- Konfigurace backlogů a dalších běžných nastavení týmu
- Konfigurace panelů
- Správa týmových oznámení
Další informace o konfiguraci backlogů a panelů najdete v tématu Správa a konfigurace týmových nástrojů.