Sdílet prostřednictvím


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:

Diagram znázorňující typy agilních pracovních položek

  • 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.

Cíle a klíčové výsledky jako další backlogy portfolia

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í.

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í.

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.

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

  • 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)
  • 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:

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.

Snímek obrazovky s cestami oblastí a přiřazeními týmu

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ů.

Snímek obrazovky s backlogem, pruhy průběhu zobrazující souhrn podle pracovních položek

Plány doručení podporují souhrnná zobrazení námětů, funkcí a dalších vlastních backlogů portfolia.

Snímek obrazovky zobrazující souhrnné zobrazení průběhu plánů doručení se čtyřmi scénáři

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.

Snímek obrazovky s cestami iterace seskupenými

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 WorkOriginal EstimateCompleted 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 Workbyla 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.

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

Stavy pracovních postupů uživatelského scénáře, 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:

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ů.

Další kroky