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 | Spravujte sloupce | Zautomatizujte práci pomocí swimlanes | Nakonfigurujte svůj 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.
Úvahy
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í oblastních cest 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
- Ať už sledujete chyby jako požadavky, jako úkoly, anebo je úplně nepoužíváte
- Bez ohledu na to, jestli používáte úkoly ke sledování času a kapacity
- 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 portfoliové backlogy
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 (WITs), 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.
- Bugy 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řidat vlastní WITs a dokonce i 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 (WIT) používají ke sledování 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 úkoly závislými na dceřiných úkolech
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 pro kapacitu sprintu
- Sledování odhadované a zbývající práce: Tabule úkolů
- Sledujte burndown 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
- Sledování úbytku sprintu na základě odhadů požadavků: Úbytek sprintu
- Stav požadavku aktualizace: Panel Kanbanu
- Sledování závislostí napříč týmy a projekty: Plány doručení
Požadavky seskupené podle typů pracovních položek portfolia, jako jsou epiky 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: Seznamy úkolů 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í kalendáře všech funkcí týmu: Časová osa funkcí
- Zobrazení kalendářu konkrétní epické úlohy: Plán epické úlohy
- 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 viz část Co je Azure Boards, Sledování práce: sestavy v kontextu 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
- Burndown trend
- Plány doručení
- Časová osa funkcí
- Epický plán
- Plány portfolia (beta verze)
Cesty iterace, konfigurace projektu a týmové předplatné (projekt, tým)
- Backlogy>Plánování sprintů
- Sprinty>Backlogy sprintů
- Sprints>Kapacita sprintu
- Taskboard sprintů>
- Rychlost
- Burndown trend
- Plány doručení
- Časová osa funkcí
- Plán epických cílů
- Plány portfolia (beta verze)
Zobrazení chyb v backlogech a panelech (tým)
Vlastní typy pracovních položek, backlog produktu (proces)
Vlastní pracovní položky, úkolová tabule (proces)
- Desky Produktová deska
- Product backlog>Produktový backlog
- Nástroj mapování backlogů>
- Sprinty>Backlogy sprintů
- Taskboard sprintů>
- Rychlost
Vlastní WITs, Backlog portfolia (Proces)
Další zpoždění portfolia (proces)
- Panely>portfolia
- Nedodělky>Nedodělky portfolia
- Nástroj pro 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
- Nástenky>nástenky 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 seskupování pracovních položek jsou podle cesty oblasti a seskupení pod portfolio typu pracovní položky (WIT), jak bylo 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 oblastí:
- Dotazování a vytváření grafů pracovních položek podle 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í oblastních cest
Tip
Můžete definovat strukturu oblastních cest a přiřadit oblastní cesty týmům. Nebo můžete přidat tým a současně vytvořit cestu oblasti s názvem týmu. Pokud jsou týmy plně nezávislé, vytvořte jednoduchou sadu oblastních cest. Pokud ale chcete vytvořit hierarchii týmů, měli byste vytvořit stromovou hierarchii 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 oblastí a přiřazení týmu
Každý projekt má výchozí tým a výchozí oblast. 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 používat souhrn jak pro správu týmu, tak pro správu portfolia.
- 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.
- Zvolte pole
Node Name
jako možnost sloupce pro zobrazení listového uzlu v seznamu úkolů nebo na kartě nástěnky. 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 podle 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 rády sledují chyby jako úkoly prováděné v rámci plnění požadavku. Chyby se pak zobrazí na jejich nástěnce úkolů.
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 zjistíte, že tam, kde očekáváte chyby, je nevidíte, prohlédněte si jak backlogy a panely zobrazují hierarchické (vnořené) položky. Na Taskboardech sprintu se zobrazují pouze listové uzly vnořených položek.
Systémové WITs 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 konsolidací, 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. Položky potomků odpovídají všem podřízeným položkám v hierarchii. Do backlogu produktu nebo portfolia můžete přidat jeden nebo více souhrnných sloupců.
Tady zobrazujeme průběh u všech pracovních položek, které zobrazují indikátory průběhu pro nadřazené pracovní položky na základě procenta uzavřených potomků pracovních položek.
Plány doručení podporují souhrnná zobrazení epik, funkcionalit a dalších vlastních backlogů portfolia.
Iterační cesty, sprinty, vydání a verzování
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 mohou být buď plošným seznamem, nebo seskupeny pod milníky vydání, 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 tým není přihlášen k odběru nebo nevybral cestu iterace, tato cesta se v zobrazení nebo nástroji týmu nezobrazí.
Sledování času
Většina organizací, které se řídí procesy Scrum, používá časové odhady pro plánování kapacity Sprintu. Nástroje Azure Boards plně podporují sledování času pro tento účel. Použité hlavní pole je pole úkolu Remaining Work
, které je obvykle vynulováno 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 –Original Estimate
Completed Work
Remaining 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í z Marketplace pro podporu dalších potřeb sledování času.
Poznámka:
Pole Original Estimate
, Completed Work
, a Remaining Work
byla navržena tak, 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á.
Změny v procesech, které ovlivňují 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é narušení týmům, které podporují, ale následující změny ano.
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 použijete vlastní číselné pole, můžete ho využít pro souhrnné výpočty v backlogu. Také můžete toto vlastní pole 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 sestavy a řídicího panelu pro In-context Velocity
- In-context sestava úbytku sprintu a widget řídicího panelu
- Řídicí panel Burndown a Burnup widget
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í typy pracovních položek
Následující tabulka ukazuje efekty, když přidáte vlastní wit do konkrétní kategorie.
Úkol
Požadavek
Epic nebo funkce
- Podřízené pracovní položky nové pracovní položky se zobrazí v backlogu produktu.
- Pracovní položky založené na novém WIT se objeví v backlogech sprintu a na tabulích úkolů.
- Pracovní položky založené na novém typu pracovních položek se zobrazí v backlogu produktu a tabuli.
- Každý tým musí nakonfigurovat \board tak, aby podporoval novou wiT.
- Pracovní položky založené na nových typech pracovních položek (WIT) se zobrazují v odpovídajících backlogech portfolia a panelech.
- Každý tým musí nakonfigurovat \boards tak, aby podporoval novou WIT.
- Nové WITs se nemusí zobrazit na jednom nebo více 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řidejte vlastní stavy pracovního postupu k WIT: Tato možnost ovlivňuje všechny týmy a vyžaduje, aby aktualizovaly konfiguraci svého 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
Chcete-li 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 mít odpovídající oprávnění Vytvořit proces, Odstranit proces, Upravit procesnebo Odstranit pole z organizace nastavena 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, staňte se členem skupiny Správci projektu .
Nebo pokud chcete přidat, upravit a spravovat cesty oblastí nebo iterací pod konkrétním uzlem, musíte mít jedno nebo více z následujících oprávnění nastavených 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
Pokud chcete konfigurovat týmové nástroje, musíte být správcem týmu nebo členem skupiny Správci projektů.
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ů.