Změna pracovního postupu pro typ pracovní položky

Azure DevOps Server | Azure DevOps Server 2022

Změňte pracovní postup pro typ pracovní položky (WIT) tak, aby podporoval obchodní a týmové procesy. Technologie WIT podporují sledování všech typů práce – požadavků, úkolů, vad kódu – pro podporu vývoje softwaru.

Pracovní postup určuje logický průběh a regresi práce, kterou členové týmu provádějí. Určuje také hodnoty, které se zobrazí v rozevíracích nabídkách polí Stát a Důvod. Další informace naleznete v tématu O procesech a šablonách procesů.

Pracovní postup pro položku backlogu produktu (šablona procesu Scrum)

Pracovní postup položky backlogu produktu, proces Scrum

Poznámka:

Tento článek popisuje, jak přizpůsobit stav pracovního postupu. Pokud chcete změnit stav přiřazený ke konkrétní pracovní položce, přečtěte si jeden z následujících článků: Panel, Sledování probíhající práce nebo Panel úkolů, Aktualizovat stav úkolu. Můžete také provést hromadnou aktualizaci stavu pro mnoho pracovních položek.

Informace o pracovních postupech build pipeline najdete v tématu Začínáme s CI/CD.

Aktualizace definice XML pro typ pracovní položky

Pokud s přizpůsobením wit začínáte, mějte na paměti následující:

Pokud chcete pracovní postup přizpůsobit, postupujte takto:

  1. WORKFLOW Upravte oddíl definice DEFINICE WIT, jak je popsáno v tomto tématu.

  2. Upravte konfiguraci procesu tak, aby mapovala nové stavy pracovního postupu na metastavy.

    Tento druhý krok je vyžadován, když změníte pracovní postup pro typ pracovního položky, který se zobrazuje na stránce agilního nástroje. Tyto WITs patří do kategorií Požadavek nebo Úkol. Další informace o kategoriích stavů naleznete v tématu Stavy pracovního postupu a kategorie stavů.

Pokyny pro návrh pracovního postupu

Pracovní postup definujte tak, že nejprve identifikujete stavy a platné přechody mezi nimi. Část WORKFLOW definice typu pracovní položky (WIT) specifikuje platné stavy, přechody, důvody pro přechody a volitelné akce, které se spustí, když člen týmu změní stav položky.

Obecně platí, že přidružte každý stav k roli člena týmu a k úkolu, který musí osoba v této roli provést, aby před změnou stavu pracovní položky zpracovávala pracovní položku. Přechody definují platné progrese a regrese mezi stavy. Důvody identifikují, proč člen týmu změní pracovní položku z jednoho stavu na jiný a akce podporují automatizaci přechodu pracovní položky v okamžiku pracovního postupu.

Pokud například tester otevře novou chybu založenou na výchozím agilním procesu, nastavte stav na Nový. Vývojář změní stav na Aktivní při opravě chyby a jakmile ji opraví, vývojář změní stav na Vyřešeno a nastaví hodnotu pole Důvod na Opraveno. Po ověření opravy tester změní stav chyby na Uzavřeno a pole Důvod se změní na Ověřeno. Pokud tester zjistil, že vývojář chybu neopravil, tester změní stav chyby na Aktivní a určí důvod, který není opravený nebo test selhal.

Při návrhu nebo úpravě pracovního postupu zvažte následující pokyny:

  • STATE Tento prvek slouží k definování jedinečného stavu pro každou roli člena týmu, která provádí konkrétní akci na pracovní položce. Čím více stavů definujete, tím více přechodů musíte definovat. Bez ohledu na posloupnost, ve které definujete stavy, se v rozevírací nabídce pro pole Stát zobrazí v alfanumerickém pořadí.

    Pokud přidáte stav do typu pracovní položky, který se zobrazí na stránkách backlogu nebo panelu na webovém portálu, musíte také namapovat stav na kategorii stavu. Další informace naleznete v tématu Stavy pracovního postupu a kategorie stavů.

  • Pomocí elementu TRANSITION definujte přechod pro každý platný průběh a regresi z jednoho stavu do druhého.

    Minimálně definujte jeden přechod pro každý stav a přechod ze stavu null na počáteční stav.

    Můžete definovat pouze jeden přechod z nepřiřazené (null) do počátečního stavu. Když uložíte novou pracovní položku, proces ji automaticky přiřadí počátečnímu stavu.

    Když člen týmu změní stav pracovní položky, tato změna aktivuje přechod a akce, které definujete pro vybraný stav a přechod. Uživatelé mohou zadat pouze ty stavy, které jsou platné na základě přechodů, které definujete pro aktuální stav. Kromě toho může prvek, ACTION což je podřízený prvek TRANSITION, změnit stav pracovní položky.

  • Pro každý přechod definujte výchozí důvod pomocí elementu DEFAULTREASON . Pomocí elementu REASON můžete definovat libovolný počet volitelných důvodů. Tyto hodnoty se zobrazí v rozevírací nabídce pole Důvod .

  • Můžete zadat pravidla, která se použijí při změně stavu pracovní položky, při přechodu nebo když uživatel vybere konkrétní důvod. Mnohé z těchto pravidel doplňují podmíněná pravidla, která můžete použít při definování polí v FIELDS oddílu pod definicí WORKITEMTYPE . Další informace naleznete v tématu Aktualizace polí během změny pracovního postupu později v tomto tématu.

  • Názvy, které přiřadíte stavům a důvodům, jsou nezávislé na velikosti písmen.

    Rozevírací nabídky polí Stav a Důvod ve formuláři pracovní položky nebo editoru dotazů zobrazují hodnoty přiřazené v WORKFLOW oddílu typu pracovní položky.

Diagram pracovního postupu a příklad kódu

Následující příklad kódu ukazuje WORKFLOW definici chyby WIT pro šablonu agilního procesu. Tento příklad definuje tři stavy a pět přechodů. Prvky STATE určují aktivní, vyřešené a uzavřené stavy. Všechny možné kombinace pro přechody progrese a regrese jsou definovány pro tři stavy, s výjimkou jedné. Přechod z uzavřeno na Vyřešeno není definován. Členové týmu proto nemohou vyřešit pracovní položku tohoto typu, pokud je pracovní položka uzavřena.

Tento příklad neobsahuje seznam všech prvků pro DEFAULTREASON, REASON, ACTIONa FIELD.

Příklad diagramu stavu pracovního postupu – agilní WIT chyby

Stavy pracovního postupu pro chyby, agilní procesní šablona 

<WORKFLOW>
 <STATES>
    <STATE value="Active">
      <FIELDS> . . . </FIELDS>
    </STATE>
    <STATE value="Resolved">
     <FIELDS> . . . </FIELDS>
    </STATE>
    <STATE value="Closed">
     <FIELDS> . . . </FIELDS>
    </STATE>
 </STATES>
 <TRANSITIONS>
    <TRANSITION from="" to="Active">
       <REASONS>
          <REASON value="Build Failure" />
           <DEFAULTREASON value="New" />
       </REASONS>
       <FIELDS> . . . </FIELDS>
    </TRANSITION>
    <TRANSITION from="Active" to="Resolved">
     <ACTIONS> . . . </ACTIONS>
     <REASONS> . . . </REASONS>
    </TRANSITION>
    <TRANSITION from="Resolved" to="Active">
       <REASONS> . . . </REASONS>
    </TRANSITION>
    <TRANSITION from="Resolved" to="Closed">
       <REASONS>
          <DEFAULTREASON value="Verified" />
       </REASONS>
     <FIELDS> . . . </FIELDS>
    </TRANSITION>
    <TRANSITION from="Closed" to="Active">
       <REASONS>
          <REASON value="Reactivated" />
          <DEFAULTREASON value="Regression" />
       </REASONS>
     <FIELDS> . . . </FIELDS>
    </TRANSITION>
 </TRANSITIONS>
 </WORKFLOW>

Určení počtu a typů stavů

Rozhodněte počet a typy platných stavů na základě počtu jedinečných logických stavů, ve kterých chcete pracovní položky daného typu existovat. Pokud také různí členové týmu provádějí různé akce, zvažte definování stavu na základě členské role. Každý stav odpovídá akci, kterou musí člen týmu provést s pracovní položkou, aby ji přesunul do dalšího stavu. Pro každý stav definujte konkrétní akce a členy týmu, kteří mají povoleno provádět tyto akce.

Následující tabulka obsahuje příklad čtyř stavů, které sledují průběh funkce a platné uživatele, kteří musí provést uvedené akce:

Stát Platný uživatel Akce k provedení
Navrženo Vedoucí projektu Pracovní položku funkce může vytvořit kdokoli. Pracovní položku ale můžou schválit nebo zrušit pouze projektoví manažeři. Pokud projektový manažer schválí funkci, projektový manažer změní stav pracovní položky na Aktivní; jinak ho člen týmu zavře.
Aktivní Vedoucí vývoje Vedoucí vývoje dohlíží na vývoj funkce. Po dokončení funkcionality vedoucí vývoje změní stav této pracovní položky na Kontrola.
Přehled Vedoucí projektu Projektový manažer zkontroluje funkci, kterou tým implementoval, a změní stav pracovní položky na Uzavřeno, pokud je implementace uspokojivá.
Zavřeno Vedoucí projektu U pracovních položek, které jsou zavřené, se neočekává žádná další akce. Tyto položky zůstanou v databázi pro účely archivace a vytváření sestav.

Poznámka:

Všechny stavy se zobrazí v abecedním pořadí v seznamu ve formuláři pro pracovní položku určitého typu bez ohledu na pořadí, ve kterém je zadáte.

Definování přechodů

Určujete stavy, ze kterých členové týmu mohou změnit pracovní položku, definováním platných průběhů stavu a regresí. Pokud nedefinujete přechod z jednoho stavu do jiného stavu, nemůžou členové týmu změnit pracovní položku určitého typu z určitého stavu na jiný konkrétní stav.

Následující tabulka definuje platné přechody pro každý ze čtyř stavů, které byly popsány výše v tomto tématu, spolu s výchozím důvodem každého.

Stát Přechod na stav Výchozí důvod
Navrženo Aktivní (průběh) Schváleno pro vývoj
Uzavřeno (pokrok) Neschválili
Aktivní Kontrola (průběh) Splněná kritéria přijetí
Přehled Uzavřeno (pokrok) Funkce je dokončená.
Aktivní (regrese) Nesplňuje požadavky
Zavřeno Navrhované (regrese) Znovu zvážit schválení
Aktivní (regrese) Uzavřeno omylem

Můžete omezit, kdo může provést přechod z jednoho stavu do druhého pomocí atributu for a TRANSITION atributů prvku. Jak ukazuje následující příklad, testeři můžou znovu otevřít chybu, ale vývojáři nemůžou.

<TRANSITION from="Closed" to="Active"  
   for="[Project]\Testers"  
   not="[Project]\Developers">  
   . . .  
</TRANSITION>

Určení důvodů

Když člen týmu změní pole Stát, může ponechat výchozí důvod pro tento přechod nebo zadat jiný důvod, pokud definujete další možnosti. DEFAULTREASON Tento prvek použijte k určení jednoho a pouze jednoho výchozího důvodu. Přidejte další důvody jenom v případě, že týmu pomáhají sledovat nebo hlásit data.

Vývojář může například určit jeden z následujících důvodů při řešení chyby: Opraveno (výchozí), Odloženo, Duplicitní, Podle návrhu, Nepodařilo se reprodukovat nebo Zastaralé. Každý důvod určuje konkrétní akci, kterou má tester provést s ohledem na chybu.

Poznámka:

Všechny důvody se zobrazí v abecedním pořadí v seznamu v pracovním formuláři pro pracovní položky určitého typu bez ohledu na pořadí, ve kterém zadáte REASON prvky.

Následující příklad ukazuje prvky, které definují důvody, proč může člen týmu vyřešit chybu:

<TRANSITION from="Active" to="Resolved">  
      . . .  
      <REASONS>  
      <DEFAULTREASON value="Fixed"/>  
      <REASON value="Deferred"/>  
      <REASON value="Duplicate"/>  
      <REASON value="As Designed"/>  
      <REASON value="Unable to Reproduce"/>  
      <REASON value="Obsolete"/>  
      </REASONS>  
      . . .  
</TRANSITION>

Určení akcí

Obecně platí, že členové týmu mění stav pracovní položky zadáním jiné hodnoty pole Stát a uložením pracovní položky. Můžete ale také definovat ACTION prvek, který automaticky změní stav pracovní položky, když dojde k přechodu. Jak ukazuje následující příklad, můžete určit, že pracovní položky chyby by se měly vyřešit automaticky, pokud jsou přidružené k souborům, které vývojář zkontroluje ve správě verzí:

<TRANSITION from="Active" to="Resolved">  
      <ACTIONS>  
      <ACTION value="Microsoft.VSTS.Actions.Checkin"/>  
      </ACTIONS>  
. . .  
</TRANSITION>

Pomocí elementu ACTION můžete automaticky změnit stav pracovních položek určitého typu, pokud se události vyskytují jinde ve správě životního cyklu aplikací sady Microsoft Visual Studio nebo mimo správu životního cyklu aplikací sady Visual Studio (například z nástroje, který sleduje volání). Další informace naleznete v tématu AKCE.

Aktualizace pole během změny pracovního postupu

Můžete definovat pravidla, která aktualizují pole vždy, když dojde k následujícím událostem:

  • Přiřaďte pravidlo pole pod STATE, aby pravidlo platilo pro všechny přechody do tohoto stavu a důvody vstupu do něj.

  • Pravidlo pole TRANSITION přiřaďte tehdy, když chcete, aby pravidlo platilo pro daný přechod i pro všechny důvody jeho provedení.

  • Přiřaďte pravidlo pole pod DEFAULTREASON nebo REASON pokud chcete, aby pravidla platila pouze z tohoto konkrétního důvodu.

    Pokud by pole mělo vždy obsahovat stejnou hodnotu, definujte pravidlo pod prvkem FIELD , který toto pole definuje. Další informace o používání pravidel najdete v tématu Pravidla a vyhodnocení pravidel.

    Minimalizujte počet podmínek, které definujete pro libovolný typ pracovní položky. Každé podmíněné pravidlo zvyšuje složitost procesu ověřování, ke kterému dochází pokaždé, když člen týmu uloží pracovní položku. Složité sady pravidel můžou zvýšit dobu potřebnou k uložení pracovní položky.

    Následující příklady ukazují některá pravidla použitá pro systémová pole v šabloně procesu pro agilní vývoj softwaru MSF.

Změna hodnoty pole při změně stavu

Když nastavíte hodnotu pole Stát pro pracovní položku na Aktivní a uložíte pracovní položku, hodnoty polí Aktivováno a Přiřazeno automaticky nastaví na název aktuálního uživatele. Tento uživatel musí být členem skupiny Valid Users pro Team Foundation Server. Hodnota pole Aktivované datum je také nastavena automaticky. Následující příklad ukazuje prvky, které vynucuje toto pravidlo:

<STATE value="Active">  
<FIELDS>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">  
      <COPY from="currentuser"/>  
      <VALIDUSER/>  
      <REQUIRED/>  
      </FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">  
      <SERVERDEFAULT from="clock"/></FIELD>  
      <FIELD refname="System.AssignedTo">  
      <DEFAULT from="currentuser"/>  
      </FIELD>  
. . .  
</FIELDS>  
</STATE>

Vymazání hodnoty pole, když se hodnota jiného pole změní

Když nastavíte hodnotu pole Stav pro pracovní položku na Aktivní a uložíte pracovní položku, EMPTY element automaticky nastaví pole Datum uzavření a Uzavřel na hodnotu null a označí je jako pouze pro čtení, jak ukazuje následující příklad.

<STATE value="Active">  
      <FIELDS>  
. . .  
      <FIELD refname="Microsoft.VSTS.Common.ClosedDate"><EMPTY/></FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ClosedBy"><EMPTY/></FIELD>  
      </FIELDS>  
</STATE>

Definování pole na základě obsahu jiného pole

Když změníte hodnotu pole Stát pro pracovní položku na Vyřešeno a uložíte pracovní položku, hodnota pole Vyřešeno důvod je nastavena na hodnotu, kterou uživatel zadal v poli Důvod . Následující příklad ukazuje prvky, které vynucuje toto pravidlo:

<STATE value="Resolved">  
      <FIELDS>  
. . .  
      <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">  
         <COPY from="field" field="System.Reason"/>  
      </FIELD>  
      </FIELDS>  
</STATE>

Související obsah

Podpora nástrojů

Pokud chcete uživatelům pomoct vizualizovat pracovní postup, nainstalujte rozšíření Vizualizace stavového modelu z Webu Visual Studio Marketplace.

  • Last updated on