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

  • Článek

Azure DevOps Server 2022 – Azure DevOps Server 2019

Pracovní postup pro typ pracovní položky (WIT) můžete změnit 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 budou členové týmu provádět. 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 místo toho chcete změnit stav přiřazený ke konkrétní pracovní položce, podívejte se na jeden z následujících článků: Panel Kanban, 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 kanálu buildu najdete v tématu Začínáme s CI/CD.

Aktualizace definice XML pro typ pracovní položky

Pokud s přizpůsobením technologie 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 mapovat nové stavy pracovního postupu na metastate.

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

Pokyny pro návrh pracovního postupu

Pracovní postup definujete tak, že nejprve identifikujete stavy a platné přechody mezi nimi. Oddíl WORKFLOW definice pracovní položky určuje platné stavy, přechody, důvody přechodů a volitelné akce, které budou provedeny, když člen týmu změní stav pracovní položky.

Obecně platí, že každý stav přidružíte k roli člena týmu a k úkolu, který musí osoba v této roli provést, aby pracovní položku před změnou stavu zpracovávala. 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.

Například Stav je nastaven na Nový , když tester otevře novou chybu, která je založená na výchozím agilním procesu. 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 by změnil stav chyby na Aktivní a určil důvod jako neopravěný 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á provede 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, jsou uvedeny v alfanumerickém pořadí v rozevírací nabídce pro pole Stát .

    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 najdete v kategoriích stavů a stavů pracovního postupu.

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

    Minimálně musíte definovat 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, automaticky se přiřadí k 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 definujete 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 k stavům a důvodům, nerozlišují velká a malá písmena.

    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í definice chyby

Stavy pracovních postupů chyb, šablona agilního procesu

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

Určíte počet a typy platných stavů na základě počtu jedinečných logických stavů, ve kterých chcete, aby pracovní položky daného typu existovaly. Pokud také různí členové týmu provádějí různé akce, můžete zvážit 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 byste měli definovat 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é jsou definovány ke sledování průběhu funkce a platných uživatelů, kteří musí provést uvedené akce:

Stav Platný uživatel Action to perform
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í funkce vedoucí vývoje změní stav pracovní položky funkce na zkontrolovat.
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 generování 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ů

Pokud definujete platné průběhy a regrese stavu, můžete určit stavy, na které členové týmu můžou pracovní položku změnit. Pokud nedefinujete přechod z jednoho stavu do jiného, členové týmu nemohou 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.

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

Můžete omezit, kdo může provést přechod z jednoho stavu do druhého pomocí atributu TRANSITION for a nikoli 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 tento uživatel zachovat výchozí důvod tohoto přechodu nebo zadat jiný důvod, pokud definujete další možnosti. Prvek je nutné použít DEFAULTREASON k určení jednoho a pouze jednoho výchozího důvodu. Měli byste zadat 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í), Deferred, Duplicate, As Designed, Cannot 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>

Zadání 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 do správy verzí:

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

Tento ACTION prvek můžete použít k automatické změně stavu 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, STATE podle kterého má pravidlo platit pro všechny přechody a důvody pro zadání tohoto stavu.

  • Pravidlo pole TRANSITION přiřaďte, pokud chcete, aby pravidlo platilo pro tento přechod, a všechny důvody pro provedení tohoto přechodu.

  • 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, definujete pravidlo pod FIELD elementem, který toto pole definuje. Další informace o používání pravidel najdete v tématu Pravidla a vyhodnocení pravidel.

    Měli byste se pokusit minimalizovat počet podmínek, které definujete pro libovolný typ pracovní položky. U každého podmíněného pravidla, které přidáte, zvýšíte složitost procesu ověřování, ke kterému dochází při každém uložení pracovní položky členem týmu. Komplexní 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

Pokud je hodnota pole Stát pro pracovní položku nastavena na Hodnotu Aktivní a pracovní položka je uložena, hodnoty polí Aktivováno a Přiřazeno jsou automaticky nastaveny 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í

Pokud je hodnota pole Stát pro pracovní položku nastavena na Aktivní a pracovní položka je uložena, pole Uzavřeno datum a Uzavřeno podle jsou automaticky nastaveny na hodnotu null a jsou nastaveny jen pro čtení, pokud použijete EMPTY prvek, 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ž se hodnota pole Stát pro pracovní položku změní na Vyřešeno a pracovní položka je uložena, 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>

Podpora nástrojů

Podporu uživatelů k vizualizaci pracovního postupu můžete provést instalací rozšíření Vizualizace stavového modelu z webu Visual Studio Marketplace.