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

Můžete změnit pracovního postupu pro typ pracovní položky (ŽÁ) pro podporu obchodní a procesy týmu.Podpora wITs sledování všechny typy work─requirements, úkoly, kód defects─to podporu pomocí vývoje softwaru Team Foundation Server (TFS).

Pracovní postup určuje logické průběh a regresní práce, která provede členy týmu.Určuje také hodnoty, které se zobrazí v rozevírací nabídky pro pole Stav a důvod.

Pracovní postup pro produkt nevyřízené položky (šablonu procesu Scrum

Přehled výchozí stavy pracovního postupu v procesu výchozích šablon sady TFS poskytuje podporovány, naleznete v části Práce s artefakty týmových projektů, výběr šablony procesu.Informace o postupu, definice sestavení naleznete v tématu Přizpůsobení šablony procesu sestavení.

Pokyny k návrhu pracovního postupu

Když první určí, zda se státy a platný přechody mezi nimi definujete pracovního postupu.WORKFLOW Část definice ŽÁ Určuje platné stavy, přechody, důvody pro přechody a volitelné akce, které budou provedeny, když člen týmu změní stav pracovní položky.

Obecně platí lze přidružit každý stav roli člena týmu a úlohu, která ke zpracování pracovní položky před změnou stavu musí provádět osoby v dané roli.Přechody definují platnou progressions a regrese mezi stavy.Důvody identifikovat důvod člen týmu změní pracovní položku z jednoho stavu do druhého a automatizace odborné pomoci akce přechodu pracovních položek na místo v pracovním postupu.

Můžete například stav je nastaven na nový po otevření testerovi novou chybu, která je založena na výchozí šablona agilní procesu, Team Foundation Server poskytuje (TFS).Vývojář změní stav, který má Active při řešení této chyby a po opravě, vývojář změní svůj stav na Vyřešeno a nastaví hodnotu pole důvod k opraveno.Po ověření potíže se testera změní stav chybu, která uzavřeno a pole důvod se změní na ověřeno.Pokud testování zjištěno, že vývojář nebyly pevně této chyby, testera by způsobila změnu stavu chybu, která Active a zadejte důvod jako není pevně nebo Test se nezdařil.

Při návrhu nebo upravovat pracovní postup, vzít v úvahu podle následujících pokynů:

• Použití STATE elementu, který chcete definovat jedinečný stav pro každou roli člena týmu, který provede konkrétní akci pracovní položku.Další stavy definujete, Další přechody, které je nutné definovat.Bez ohledu na pořadí, ve kterém můžete definovat stavech, jsou uvedeny v abecedním pořadí v rozevírací nabídce pro stav pole.

  Když přidáte stavu typ pracovní položky, které se objeví na stránkách nevyřízených položek nebo tabuli v Team Web Access, je třeba také namapovat stav metastate.Další informace naleznete v tématu Referenční dokumentace elementu XML konfigurace procesu.

• Použití TRANSITION elementu, který chcete definovat přechodu pro každý platný průběh a regresní z jednoho stavu do druhého.

  Na co nejnižší úrovni je nutné definovat jeden přechod pro každý stav a přechod z null stavu do původního stavu.

  Můžete definovat pouze jeden přechod z nepřiřazené (null) do původního stavu.Pokud uložíte novou pracovní položku, je přiřazen automaticky do původního stavu.

  Když člen týmu změní stav pracovní položky, že změna aktivuje přechod a akce, které mají být provedeny pro vybraný stav a přechod definujete.Uživatelé mohou určit pouze ty státy, které jsou platné podle přechody, které definujete pro aktuální stav.Kromě toho ACTION element, který je podřízeným prvkem z TRANSITION, můžete změnit stav pracovní položky.

• Pro každý přechod definujete pomocí výchozí důvod, proč DEFAULTREASON elementu.Můžete zadat libovolný počet volitelné důvodů, jak chcete pomocí REASON elementu.Tyto hodnoty se zobrazí v rozevírací nabídce důvod pole.

• Můžete zadat pravidla, které budou použity při pracovní položka změně stavu, když přechází, nebo když uživatel vybere zvláštní důvod.Mnoho z těchto pravidel doplňují pravidla podmíněného, které můžete použít při definování pole v FIELDS v oddílu WORKITEMTYPE definice.Další informace naleznete v tématu aktualizovat pole během pracovní postup změny dále v tomto tématu.

• Názvy, které můžete přiřadit stavů a důvodů, proč jsou malá a velká písmena.

  Rozevírací nabídky pro pole Stav a důvod v editoru formuláře nebo dotazu pracovní položky zobrazit hodnoty přiřazené v WORKFLOW část typ pracovní položky.

Příklad diagramu a kódu pracovního postupu

Následující příklad kódu ukazuje WORKFLOW pro definici chybu ŽÁ šablonu agilní procesu.Tento příklad definuje tří stavů a pěti přechody.STATE Prvky určují stavy aktivní, Vyřešeno a uzavřeno.Všechny možné kombinace pro průběh a regresní přechody jsou definovány pro tří stavů, s výjimkou jednoho.Přechod z uzavřeno Vyřešeno není definován.Členové týmu proto nemůže vyřešit pracovní položka tohoto typu, pokud byla pracovní položka je uzavřen.

V tomto příkladu není uveden všechny elementy pro DEFAULTREASON, REASON, ACTION, a FIELD.

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

Diagram stavu pracovního postupu příklad – agilní chybu ŽÁ

Zjistit počet a typy stavů

Můžete určit počet a typy platný stavy na základě počtu různé logické stavy, ve kterých chcete pracovních položek tohoto typu neexistuje.Také pokud členové týmu různé provádět různé akce, pak můžete definovat stavu na základě člen role.Každý stav odpovídá akce v pracovní položce a přesunete jej na další stav, musí provést člen týmu.Pro každý stav a je třeba definovat konkrétní akce členy týmu, kteří mají povoleno provádět tyto akce.

Následující tabulka obsahuje příklad ze čtyř stavů, které jsou definovány můžete sledovat průběh funkce a platný uživatelů, kteří musí uvedeného činnostem:

[!POZNÁMKA]

Všechny stavy jsou 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 zadat.

Definovat přechody

Můžete řídit stavy do a z který tým členy můžete změnit pracovní položku, pokud definujete v platném stavu progressions a regrese.Pokud není definován přechod z jednoho stavu do jiného státu, členové týmu nelze změnit pracovní položku určitého typu z určitém stavu do jiného konkrétní stavu.

V následující tabulce definuje platný přechody pro každý ze čtyř stavů, které byly popsány v tomto tématu, spolu s výchozí důvod pro každý.

Můžete omezit, kdo může provést přechod z jednoho stavu do druhého pomocí pro a není atributy TRANSITION elementu.Následující příklad ukazuje, testeři lze znovu otevřít chybu ale nelze vývojáři.

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

Zadejte důvody

Když člen týmu změní stav pole, můžete tento uživatel zachovat výchozí důvod pro tento přechod nebo zadejte jiný důvod, je-li definovat další možnosti.Je třeba použít DEFAULTREASON elementu, který chcete určit pouze jeden výchozí důvod.Další důvodů, proč byste měli zadat pouze v případě, že pomáhají týmu sledovat nebo do ní odesílat data.

Vývojář můžete zadat například jeden z následujících důvodů při překladu chybu: pevnou (výchozí), odloženo, duplicitní, jako navržený tak, nelze reprodukovat nebo zastaralé.Každý z důvodu určuje konkrétní akci pro testování provádět s ohledem na této chyby.

[!POZNÁMKA]

Všechny důvodů, proč jsou v abecedním pořadí v seznamu ve formuláři práce pro pracovní položky určitého typu, bez ohledu na pořadí, ve kterém určíte REASON elementy.

Následující příklad ukazuje prvky, které definují důvodů, proč může člen týmu vyřešte 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>

Zadejte akce

Obecně platí, členové týmu změnu stavu pracovní položky tak, že určíte jinou hodnotu pro stav pole a potom ukládání pracovní položku.Však také můžete zadat ACTION element, který automaticky změní stav pracovní položky, když dojde k tento přechod.Následující příklad ukazuje, můžete určit, že chybu pracovní položky se má vyřešit automaticky pokud jsou přidružena k souborům s vývojářem do správy verzí:

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

Můžete použít ACTION element k automatické změně stavu pracovních položek určitého typu, jakmile dojde k událostem jinde ve správě životního cyklu aplikací společnosti Microsoft ve službě Visual Studio nebo mimo Visual Studio – správa životního cyklu aplikací (například z nástroj, který sleduje volání).Další informace naleznete v tématu Automatizace přiřazení polí na základě stavu, přechodu nebo důvodu.

Aktualizovat pole během pracovní postup změny

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

• Přiřadit pravidlo pro pole v rámci STATE Pokud má pravidlo použít pro všechny přechody a důvody pro zadání tohoto stavu.

• Přiřadit pravidlo pro pole v rámci TRANSITION Pokud má pravidlo použít pro tento přechod a všechny důvody k provedení tento přechod.

• Přiřadit pravidlo pro pole v rámci DEFAULTREASON nebo REASON Pokud chcete, aby pravidla, která bude použita pouze pro konkrétní z tohoto důvodu.

Pokud pole by měl obsahovat vždy stejnou hodnotu, můžete definovat pravidla v části FIELD element, který definuje tohoto pole.Další informace o použití pravidel, naleznete v části Použití pravidla pro pole pracovní položky.

Pokuste se minimalizovat počet podmínky, které definujete pro jakýkoli typ pracovní položky.S podmíněného pravidla, která přidáte zvýšíte složitost proces ověření, který probíhá při každém, aby člen týmu uloží pracovní položku.Komplexní pravidlo nastaví může zvýšit dobu, po kterou je třeba uložit pracovní položku.

Následující příklady ukazují některé z pravidel, které se použijí pro systémová pole v šabloně procesu pro MSF agilní Software Development 2013.

Změnit hodnotu pole při změně stavu

Při hodnotě stavu pole pracovní položka je nastavena na hodnotu aktivní a pracovní položka je uložen, hodnoty aktivován podle a přiřazeno pole jsou automaticky nastavena na název aktuálního uživatele.Tento uživatel musí být členem skupiny Team Foundation Server skupina platný uživatelů.Hodnota aktivován datum pole je také nastavena automaticky.Následující příklad ukazuje elementy, které vynuťte 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>

Vymaže hodnotu pole při změně hodnoty jiné pole

Pokud hodnota stav pro pracovní položku je nastaveno na aktivní a je uložen s pracovní položkou, pole Datum uzavřeno a Uzavřeno jsou automaticky nastavena na hodnotu null a nahradil Pokud použijete jen pro čtení EMPTY elementu, 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>

Je třeba definovat pole na základě obsahu jiné pole

Při hodnota stav pole pro pracovní položky se změní na Vyřešeno a pracovní položka je uložen, hodnota vyřešen důvod je nastaveno na hodnotu, která uživatel zadal v důvod pole.Následující příklad ukazuje elementy, které vynuťte toto pravidlo:

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

Dotazy a odpovědi

D: je nástroj, chcete-li změnit pracovního postupu nebo chcete-li zobrazit diagramy stavu pracovních postupů?

O: Ano.Můžete změnit pracovní postup nebo zobrazení diagramu stavu pracovního postupu, který definujete pomocí editoru procesu jako nástroj power Visual Studio.Další informace získáte na následující stránce na webu společnosti Microsoft: Team Foundation Server výkonné nástroje.

D: kde můžete získat přehled elementů XML definice ŽÁ?

O: Viz Referenční dokumentace všech elementů XML WITD.