Informace o přizpůsobení procesů a zděděných procesech

  • Článek

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Pokud chcete přizpůsobit systém sledování práce, přizpůsobíte zděděný proces prostřednictvím uživatelského rozhraní pro správu organizace. Všechny projekty, které používají zděděný proces, získají přizpůsobení provedené v daném procesu. Na druhou stranu nakonfigurujete své agilní nástroje – backlogy, sprinty, panely Kanbanu a Taskboard – pro každý tým.

Důležité

Pokud chcete přizpůsobit místní projekt nebo aktualizovat definiční soubory XML tak, aby podporovaly přizpůsobení, podívejte se na místní model procesu XML. Tento článek se týká jenom Azure DevOps Services a Azure DevOps Serveru 2019.

Existuje celá řada přizpůsobení, která můžete provést. Primárními typy pracovních položek jsou přidání vlastních typů pracovních položek (WIT) nebo úprava existující pracovní položky pro přidání vlastních polí, úpravou rozložení nebo změnou pracovního postupu.

Poznámka:

Změny zděděné procesy můžete zkontrolovat prostřednictvím protokolu auditu. Další informace najdete v tématu Access, export a filtrování protokolů auditu.

Níže najdete index těchto úloh, které můžete provést při přizpůsobení zděděného procesu. Některé možnosti zděděných prvků jsou uzamčené a nelze je přizpůsobit.

Systém versus zděděné procesy

Uvidíte dva typy procesů:

  • locked icon Systémové procesy – Agilní, Základní, Scrum a CMMI – které se zamknou od změny.
  • inherited icon Zděděné procesy, které můžete přizpůsobit a které dědí definice ze systémového procesu, ze kterého byly vytvořeny. Systémové procesy vlastní a pravidelně aktualizují Microsoft. Všechny aktualizace provedené v systémovém procesu automaticky způsobí aktualizaci zděděných procesů a podřízených procesů. Aktualizace ke procesům jsou zdokumentované v Poznámky k verzi pro Azure DevOps Server

Poznámka:

Základní proces je k dispozici s Azure DevOps Serverem 2019 Update 1 a novějšími verzemi.

Kromě toho jsou sdílené všechny procesy. To znamená, že jeden nebo více projektů může použít jeden proces. Místo přizpůsobení jednoho projektu přizpůsobíte proces. Změny provedené v procesu automaticky aktualizují všechny projekty, které tento proces používají. Jakmile vytvoříte zděděný proces, můžete ho přizpůsobit, vytvořit na něm projekty, vytvořit jeho kopii a změnit existující projekty tak, aby ho používaly.

Například jak je znázorněno na následujícím obrázku, zobrazí se seznam projektů definovaných pro organizaci fabrikam . Druhý sloupec zobrazuje proces používaný jednotlivými projekty. Pokud chcete změnit přizpůsobení projektu Fabrikam Fiber, musíte upravit proces MyScrum (který dědí z procesu systému Scrum). Všechny změny provedené v procesu MyScrum také aktualizují další projekty, které tento proces používají. Na druhou stranu nemůžete přizpůsobit projekt testu dotazu, dokud ho nezměníte na proces, který dědí z agilního procesu.

Screenshot of Admin context, Organization settings, Project list and the process they use.

Omezení názvů procesů

Názvy procesů musí být jedinečné a 128 znaků Unicode nebo méně. Názvy také nemohou obsahovat následující znaky: .,;'`:~\/\*|?"&%$!+=()[]{}<>.

Chcete-li přejmenovat proces, otevřete ... místní nabídka pro proces a zvolte Upravit.

Změna referenčního procesu projektu

Pokud chcete přepnout proces, který projekt používá z jednoho systémového procesu na jiný, můžete to udělat. Chcete-li provést tyto změny, musíte vytvořit zděděný proces na základě procesu, na který chcete přepnout. Pokyny jsou například k dispozici pro podporu následujících změn:

Podle pokynů uvedených v výše uvedených článcích můžete také provádět další změny, například z CMMI na Agilní nebo Agilní do CMMI.

Před provedením této změny doporučujeme seznámit se s procesem, na který se měníte. Systémové procesy jsou shrnuty v části O procesech a šablonách procesů.

Osvědčené postupy při provádění změn

Provádění změn zděděného procesu je jednoduché a bezpečné. Před použitím těchto změn na aktivní projekt je ale vždy osvědčeným postupem tyto změny otestovat. Následující kroky vám pomůžou zobrazit případné negativní vlivy na změny procesu.

Zděděné objekty versus vlastní objekty

Každý zděděný proces, který vytvoříte, dědí wiT definované v systémovém procesu – Základní, Agilní, Scrum nebo CMMI. Agilní proces například poskytuje chybu, úkol, uživatelský příběh, funkci, námět, problém a pracovní položky související s testováním.

Conceptual image of Agile process work item hierarchy.

Můžete přidat pole a upravit pracovní postup a formulář pracovní položky pro všechny zděděné pracovní položky, které se zobrazují na stránce Typy pracovních položek. Pokud nechcete, aby uživatelé vytvořili wit, můžete ho zakázat. Kromě toho můžete přidat vlastní wity.

Přizpůsobení polí

Pole definovaná v systémovém procesu se zobrazí s zděděnou ikonou , která indikuje, že v zděděném procesu můžete provádět omezené úpravy.

Pole jsou definována pro všechny projekty a procesy v organizaci. To znamená, že jakékoli vlastní pole, které jste definovali pro wiT v jednom procesu, je možné přidat do jakéhokoli jiného wit definovaného pro jiný proces.

Typ pole

Podpora přizpůsobení

Zděděná pole

Vlastní pole

Vlastní ovládací prvek

Při přidávání vlastníchpolích

  • Pro každou definici wi-fi je možné definovat maximálně 64 polí.
  • Pro každý proces lze definovat maximálně 512 polí.

Kromě toho můžete v rámci procesu přidat existující pole do jiného pole . Můžete například přidat termín splnění do scénáře uživatele nebo chyby s interními informacemi o chybách.

Co nemůžete přizpůsobit

  • Po definování názvu pole nebo datového typu nemůžete změnit jeho název ani datový typ.
  • Šedá oblast ve formuláři, kde jsou umístěna pole Stav, Důvod, Cesta k oblasti a cesta iterace, nemůžete změnit.
  • Globální seznam, který podporuje hostované modely XML a místní procesy XML, nemůžete importovat ani definovat. Další informace najdete v tématu Definování globálních seznamů.
  • Po definování názvu pole nebo datového typu nemůžete změnit jeho název ani datový typ.
  • Šedá oblast ve formuláři, kde jsou umístěna pole Stav, Důvod, Cesta k oblasti a cesta iterace, nemůžete změnit.
  • Pokud jde o rozevírací seznamy, v současné době nemůžete provádět tyto operace:
    • Změna rozevíracího seznamu zděděného pole, například pole Aktivita nebo Disciplína
    • Změna pořadí rozevíracího seznamu, zobrazení rozevíracích seznamů v abecedním pořadí
  • Nelze upravit text nápovědy Popis zděděných polí.
  • Importujte nebo definujte globální seznam podporovaný hostovanými modely XML a místními modely procesů XML. Další informace najdete v tématu Definování globálních seznamů.

Poznámka:

V případě zděděného procesu nemůžete změnit rozevírací seznamy předdefinovaných polí, jako je aktivita, stav automatizace, disciplína, priorita a další.

Konfigurovatelné rozevírací seznamy

Následující rozevírací seznamy jsou nakonfigurovány pro každý projekt a nelze je přizpůsobit prostřednictvím zděděného procesu.

Rozevírací seznamy přidružené k polím jmen osob, jako jsou Přiřazeno a Změněno podle, se spravují na základě uživatelů, které přidáte do projektu nebo týmu.

Můžu pole přejmenovat nebo změnit jeho datový typ?

Akce přejmenování pole nebo změna datového typu nejsou podporované. Můžete ale změnit popisek, který se zobrazí pro pole ve formuláři pracovní položky, na kartě Rozložení. Při výběru pole v dotazu musíte vybrat název pole, nikoli popisek pole.

Můžu odstranit nebo obnovit odstraněné pole?

Pole můžete odstranit a později ho obnovit. Odstraněním pole odstraníte všechna data spojená s tímto polem, včetně historických hodnot. Po odstranění můžete obnovit pouze pole a obnovit data pomocí rozhraní Fields – Update REST API.

Místo odstranění pole můžete místo toho chtít pole skrýt nebo odebrat z formuláře pracovní položky. Podrobnosti najdete v tématu Přidání a správa polí, Zobrazení, skrytí nebo odebrání pole.

Co je pole? Jak se používají názvy polí?

Každý typ pracovní položky je přidružený k 31 systémovým polím a několika dalším polím specifickým pro typ. Pracovní položky slouží k plánování a sledování projektu.

Každé pole podporuje sledování informací o práci, která se má provést. Hodnoty, které přiřadíte k poli, se ukládají v úložišti dat sledování práce, ve kterém můžete vytvářet dotazy k určení stavu a trendů.

Popisy a použití jednotlivých polí definovaných pro základní systémové procesy – Scrum, Agile a CMMI – viz index polí pracovních položek.

Názvy polí

Název pole pracovní položky jednoznačně identifikuje každé pole pracovní položky. Ujistěte se, že názvy polí spadají do těchto pokynů:

  • Názvy polí musí být jedinečné v rámci organizace nebo kolekce projektů.
  • Názvy polí musí mít 128 nebo méně znaků Unicode.
  • Názvy polí nesmí obsahovat žádné úvodní ani koncové mezery ani dvě nebo více po sobě jdoucích mezer.
  • Názvy polí musí obsahovat aspoň jeden abecední znak.
  • Názvy polí nemohou obsahovat následující znaky: .,;'`:~\/\*|?"&%$!+=()[]{}<>.

Vzhledem k tomu, že jsou všechna pole definovaná pro organizaci, nemůžete přidat vlastní pole se stejným názvem pole, které už v organizaci existuje, nebo bylo přidáno do wit v jiném zděděném procesu.

Poznámka:

Když změníte projekt tak, aby používal zděděný proces, můžete najít jeden nebo více agilních nástrojů nebo pracovních položek v neplatném stavu. Příklad:

  • Pokud je pole povinné, zobrazí se v pracovních položkách s tímto polem nedefinovaná chybová zpráva. Abyste mohli provést další změny a uložit pracovní položku, budete muset tyto chyby vyřešit.
  • Pokud přidáte nebo odeberete nebo skryjete stavy pracovních postupů zobrazené na panelu Kanbanu, budete muset aktualizovat konfigurace sloupců panelu Kanban pro všechny týmy definované v projektu.

Vlastní pravidla a systémová pravidla

Každá pracovní doba ( chyba, úkol, uživatelský příběh atd.) má již definovaná několik systémových pravidel. Některé jsou jednoduché, například nastavení pole Název jako povinné nebo nastavení výchozí hodnoty pro pole Oblast hodnot. Kromě toho řada systémových pravidel definuje akce, které se mají provést při změně stavu pracovního postupu.

Existuje například několik pravidel pro zkopírování aktuální identity uživatele za následujících podmínek:

  • Při změně pracovní položky zkopírujte identitu uživatele do pole Změněno podle.
  • Když se stav pracovního postupu změní na Uzavřeno nebo Hotovo, zkopírujte identitu uživatele do pole Uzavřeno.

Důležité

Předdefinovaná systémová pravidla přebírají předchůdci nad libovolným vlastním pravidlem, které by ho přepsalo.

Vlastní pravidla poskytují podporu pro řadu obchodních případů použití, což vám umožní překročit nastavení výchozí hodnoty pro pole nebo ho nastavit jako povinné. Pravidla umožňují vymazat hodnotu pole, zkopírovat hodnotu do pole a použít hodnoty založené na závislostech mezi hodnotami různých polí.

Pomocí vlastního pravidla můžete definovat řadu akcí na základě konkrétních podmínek. Můžete například použít pravidlo pro podporu těchto typů scénářů:

  • Pokud je pro prioritu definována hodnota, proveďte riziko v požadovaném poli.
  • Při změně hodnoty vydané verze zrušte zaškrtnutí políčka Milník.
  • Když došlo ke změně hodnoty Zbývající práce, proveďte dokončenou práci požadované pole.
  • Pokud je hodnota Approved (Schváleno) true (Pravda), proveďte schválení požadovaným polem.
  • Při vytváření uživatelského scénáře zadejte následující pole: Priorita, Riziko a Úsilí.

Tip

Vzorec nelze definovat pomocí pravidla. Můžete ale najít řešení, které vyhovuje vašim potřebám, s rozšířením Power Automate nebo agregátorem TFS (webová služba) Marketplace. Viz také souhrn práce a dalších polí.

Podrobnosti o definovánívlastníchch

Omezit úpravy vybraných polí pro vybrané skupiny uživatelů

Pomocí jedné z následujících dvou podmínek můžete vybrat pole požadovaná pro uživatele skupiny zabezpečení nebo pro uživatele, kteří nejsou členem skupiny zabezpečení.

  • current user is a member of a group...
  • current user is not a member of a group...

Můžete například nastavit pole Název nebo Stát jen pro čtení pro vybrané uživatele nebo skupiny.

Omezení úprav pracovních položek na základě cesty oblasti

Uživatelům můžete zakázat úpravu vybraných pracovních položek nastavením oprávnění v cestě oblasti. Toto není nastavení pravidla, ale nastavení oprávnění. Další informace najdete v tématu Vytváření podřízených uzlů a úpravy pracovních položek v cestě k oblasti.

Přizpůsobení typu pracovní položky (WIT)

Tady jsou možnosti přizpůsobení pro zděděné a vlastní wity.

Typ pracovní položky

Podpora přizpůsobení

Zděděné typy pracovních položek

Vlastní typy pracovních položek

Co nemůžete přizpůsobit

  • Zděděnou wit do nebo z backlogu nemůžete přidat ani odebrat.
  • Umístění zděděného pole v rozložení formuláře nemůžete změnit (pole však můžete skrýt v jedné oblasti formuláře a přidat ho jinam ve formuláři).
  • Z produktu nemůžete odebrat zděděnou úroveň portfolia (ale můžete je přejmenovat).
  • Nemůžete změnit název vlastní wit.

Přizpůsobení formuláře pracovní položky

Následující úpravy můžete provést ve formuláři WIT.

Typ skupiny nebo stránky

Podpora přizpůsobení

Zděděné skupiny

Vlastní skupiny

Zděděné stránky

Vlastní stránky

Rozložení a změna velikosti

Rozložení webového formuláře je uspořádané do tří sloupců, jak je znázorněno na následujícím obrázku.

Illustration of 3-column page layout for work item form.

Pokud do prvních dvou sloupců přidáte jenom skupiny a pole, rozložení bude odrážet rozložení se dvěma sloupci. Podobně platí, že pokud do prvního sloupce přidáte jenom skupiny a pole, bude rozložení odrážet rozložení s jedním sloupcem.

Webový formulář změní velikost v závislosti na dostupné šířce a počtu sloupců v rozložení. Ve většiněwebových Při poklesu šířky zobrazení se každý sloupec mění úměrně následujícím způsobem:

  • Pro tři sloupce: 50 %, 25 % a 25 %
  • Pro dva sloupce: 66 % a 33 %
  • Pro jeden sloupec: 100 %.

Pokud šířka zobrazení nebude obsahovat všechny sloupce, zobrazí se sloupce skládané do sloupce vlevo.

Přizpůsobení pracovního postupu

Pracovní postup libovolného typu pracovní položky (WIT) můžete přizpůsobit skrytím zděděných stavů nebo přidáním vlastních stavů. Zděděné stavy se liší v závislosti na systémovém procesu – Agilní, Základní, Scrum nebo CMMI– jste zvolili, ze kterého chcete vytvořit vlastní proces.

Každý výchozí pracovní postup pro jednotlivé pracovní položky definuje mezi dvěma a čtyřmi stavy a určuje následující operace pracovního postupu:

  • Přechody vpřed a dozadu mezi jednotlivými stavy
  • Výchozí důvody pro každý přechod stavu

Například základní proces, problém WIT je charakterizován třemi státy – To Do, Doing a Done – a přechody znázorněné na následujícím obrázku.

Basic Process, Issue work item type, workflow state model

Typy stavů

Podporovaná přizpůsobení

Inherited icon Zděděné stavy

Vlastní stavy

Stavy pracovního postupu musí odpovídat následujícím pravidlům.

  • Musíte definovat alespoň jeden stav pro kategorie navrhovaného nebo probíhajícího stavu.

    Poznámka:

    Před přidáním stavu pracovního postupu zkontrolujte stavy a kategorie stavů pracovního postupu a zjistěte, jak se stavy pracovního postupu mapuje na kategorie stavů.

  • Musíte definovat aspoň dva stavy pracovního postupu.
  • Pro každý typ pracovní položky můžete definovat maximálně 32 stavů pracovního postupu.

Nepodporovaná přizpůsobení pracovního postupu

  • Zděděný stav nemůžete změnit (nemůžete změnit jeho název, barvu nebo kategorii), ale můžete ho skrýt.
  • V kategorii Dokončeno můžete mít pouze jeden stav. Pokud do kategorie Dokončeno přidáte vlastní stav, odebere se nebo skryje jakýkoli jiný stav.
  • Nemůžete změnit název vlastního stavu.
  • Místo toho není možné zadat důvod pro stav. Místo toho jsou definovány výchozí důvody, jako je například Přesun do stavu Třídění, Přesunuto ze stavu Určení priorit podle dostupnosti.
  • Umístění polí Stát a Důvod ve formuláři nelze změnit.
  • Nemůžete přizpůsobit názvy kategorií států
  • Zděděný stav nemůžete změnit (nemůžete změnit jeho název, barvu nebo kategorii), ale můžete ho skrýt.
  • V kategorii Dokončeno můžete mít pouze jeden stav. Systém zakáže přidání libovolného vlastního stavu do této kategorie.
  • Nemůžete změnit název vlastního stavu.
  • Pořadí stavů nemůžete změnit, stavy jsou uvedeny v přirozené sekvenci na základě jejich kategorie stavu v rozevíracím seznamu formuláře pracovní položky.
  • Místo toho není možné zadat důvod pro stav. Místo toho jsou definovány výchozí důvody, jako je například Přesun do stavu Třídění, Přesunuto ze stavu Určení priorit podle dostupnosti.
  • Umístění polí Stát a Důvod ve formuláři nelze změnit.
  • Přechody nemůžete omezit, všechny přechody jsou definovány z libovolného stavu do jiného stavu.

Přizpůsobení backlogu a panelu

Backlogy a panely jsou základní agilní nástroje pro vytváření a správu práce pro tým. Standardní backlogy – produkt, iterace a portfolio – zděděné ze systémového procesu jsou plně přizpůsobitelné. Kromě toho můžete přidat vlastní backlogy portfolia pro celkem pět backlogů portfolia.

Typy backlogu

Podpora přizpůsobení

Zděděné backlogy

Vlastní backlogy portfolia

Co nemůžete přizpůsobit

  • Z produktu nemůžete odebrat zděděnou úroveň portfolia (můžete ale přejmenovat úroveň portfolia a zakázat zděděný typ pracovní položky).
  • V existující sadě definovaných backlogů nejde vložit úroveň backlogu.
  • Nemůžete změnit pořadí úrovní backlogu.
  • Typ pracovní položky nejde přidat do dvou různých úrovní backlogu.
  • Nemůžete vytvořit vlastní úroveň backlogu úlohy, i když do backlogu iterace můžete přidat vlastní pracovní položky.
  • K žádné úrovni backlogu nemůžete přidat wit chyby . Místo toho systém umožňuje každému týmu rozhodnout, jak chtějí spravovat chyby. Další informace najdete v tématu Zobrazení chyb v backlogech a panelech.
  • Zděděné WIT nemůžete přidat ani odebrat z backlogu, například nemůžete přidat interní informace o problému do backlogu produktu.
  • Z produktu nemůžete odebrat zděděnou úroveň portfolia (můžete ale přejmenovat úroveň portfolia a zakázat zděděný typ pracovní položky).
  • V existující sadě definovaných backlogů nejde vložit úroveň backlogu.
  • Nemůžete změnit pořadí úrovní backlogu.
  • Typ pracovní položky nejde přidat do dvou různých úrovní backlogu.
  • Nemůžete vytvořit vlastní úroveň úlohy, i když do backlogu iterace můžete přidat vlastní typy pracovních položek.
  • K žádné úrovni backlogu nemůžete přidat wit chyby . Místo toho systém umožňuje každému týmu rozhodnout, jak chtějí spravovat chyby. Další informace najdete v tématu Zobrazení chyb v backlogech a panelech.

Poznámka:

Některé funkce vyžadují instalaci aktualizace Azure DevOps Serveru 2020.1. Další informace najdete v tématu Poznámky k verzi pro Azure DevOps Server 2020 Update 1 RC1, Boards.

Když změníte výchozí wit pro úroveň backlogu, způsobí, že se funkce WIT zobrazí ve výchozím nastavení na panelu rychlého přidání. Například lístek zákazníka se ve výchozím nastavení zobrazí na následujícím panelu rychlého přidání pro backlog produktu.

Screenshot of Product backlog, Quick Add Panel, Displays Default WIT for a backlog level

Limity objektů

Seznam omezení nastavených na počet polí, pracovní položky, úrovně backlogu a další objekty, které můžete přizpůsobit, najdete v tématu Omezení objektů sledování práce.