Ändra arbetsflödet för en typ av arbetsobjekt

  • Artikel

Azure DevOps Server 2022 – Azure DevOps Server 2019

Du kan ändra arbetsflödet för en arbetsobjektstyp (WIT) för att stödja dina affärs- och teamprocesser. WIT stöder spårning av alla typer av arbete – krav, uppgifter, kodfel – för att stödja programvaruutveckling.

Arbetsflödet bestämmer den logiska utvecklingen och regressionen av det arbete som teammedlemmarna ska utföra. Den anger också de värden som visas i de nedrullningsbara menyerna för fälten Tillstånd och Orsak. Mer information finns i Om processer och processmallar.

Arbetsflöde för produktpost för kvarvarande uppgifter (Scrum-processmall)

Arbetsflöde för produktloggobjekt, Scrum-process

Kommentar

I den här artikeln beskrivs hur du anpassar ett arbetsflödestillstånd. Om du i stället vill ändra tillståndet som tilldelats till ett specifikt arbetsobjekt kan du läsa någon av följande artiklar: Kanban-anslagstavlan, Spåra pågående arbete eller Aktivitetstavla, Uppdatera aktivitetsstatus. Du kan också utföra en massuppdatering av tillståndet för många arbetsobjekt.

Information om arbetsflöden för byggpipelines finns i Komma igång med CI/CD.

Uppdatera XML-definitionen för en arbetsobjektstyp

Observera följande om du är nybörjare på WIT-anpassning:

  • Om du vill anpassa alla aspekter av en arbetsobjektstyp måste du uppdatera dess XML-definition. XML-definitionen beskrivs i referensen för alla WITD XML-element
  • Om du anpassar webbformuläret som använder den nya arbetsobjektsupplevelsen vill du referera till elementen WebLayout och Control
  • Om du anpassar ett klientformulär för användning med Visual Studio ska du referera till XML-elementreferensen för layout
  • Följ sekvensen med steg som beskrivs i Anpassa webbformuläret för spårning av arbetsobjekt.

Följ dessa två steg för att anpassa arbetsflödet:

  1. Ändra avsnittet i WORKFLOW WIT-definitionen enligt beskrivningen i det här avsnittet.

  2. Ändra processkonfigurationen för att mappa nya arbetsflödestillstånd till metatillstånd.

    Det andra steget krävs när du ändrar arbetsflödet för en WIT som visas på en agil verktygssida. Dessa WITs tillhör antingen kategorierna Krav eller Uppgift. Mer information om tillståndskategorier finns i Arbetsflödestillstånd och tillståndskategorier.

Riktlinjer för arbetsflödesdesign

Du definierar arbetsflödet genom att först identifiera tillstånden och de giltiga övergångarna mellan dem. Avsnittet WORKFLOW i WIT-definitionen anger giltiga tillstånd, övergångar, orsaker till övergångarna och valfria åtgärder som ska utföras när en gruppmedlem ändrar tillståndet för ett arbetsobjekt.

I allmänhet associerar du varje stat med en gruppmedlemsroll och en uppgift som en person i den rollen måste utföra för att bearbeta arbetsobjektet innan dess tillstånd ändras. Övergångar definierar giltiga förlopp och regressioner mellan tillstånd. Orsaker identifierar varför en gruppmedlem ändrar ett arbetsobjekt från ett tillstånd till ett annat, och åtgärder stöder automatisering av övergången av ett arbetsobjekt vid en tidpunkt i arbetsflödet.

Tillståndet är till exempel inställt på Nytt när en testare öppnar en ny bugg som baseras på standardprocessen agil. Utvecklaren ändrar tillståndet till Aktiv när felet åtgärdas, och när det har åtgärdats ändrar utvecklaren sitt tillstånd till Löst och anger värdet för fältet Orsak till Åtgärdat. När du har verifierat korrigeringen ändrar testaren tillståndet för felet till Stängd och fältet Orsak ändras till Verifierad. Om testaren fastslog att utvecklaren inte hade åtgärdat felet skulle testaren ändra tillståndet för buggen till Aktiv och ange orsaken som Inte åtgärdad eller Testet misslyckades.

När du utformar eller ändrar ett arbetsflöde bör du tänka på följande riktlinjer:

  • Använd elementet STATE för att definiera ett unikt tillstånd för varje gruppmedlemsroll som ska vidta en specifik åtgärd för ett arbetsobjekt. Ju fler tillstånd du definierar, desto fler övergångar måste du definiera. Oavsett i vilken ordning du definierar tillstånden visas de i alfanumerisk ordning i den nedrullningsbara menyn för fältet Tillstånd .

    Om du lägger till ett tillstånd till en typ av arbetsobjekt som visas på kvarvarande eller brädsidor i webbportalen måste du också mappa tillståndet till en tillståndskategori. Mer information finns i Arbetsflödestillstånd och tillståndskategorier.

  • Använd -elementet TRANSITION för att definiera en övergång för varje giltig progression och regression från ett tillstånd till ett annat.

    Du måste minst definiera en övergång för varje tillstånd och övergången från null-tillståndet till det ursprungliga tillståndet.

    Du kan bara definiera en övergång från otilldelad (null) till det ursprungliga tillståndet. När du sparar ett nytt arbetsobjekt tilldelas det automatiskt till det ursprungliga tillståndet.

    När en gruppmedlem ändrar tillståndet för ett arbetsobjekt utlöser ändringen övergången och de åtgärder som du definierar som ska utföras för det valda tillståndet och övergången. Användare kan bara ange de tillstånd som är giltiga baserat på de övergångar som du definierar för det aktuella tillståndet. Dessutom kan ett ACTION element, som är ett underordnat element TRANSITIONi , ändra tillståndet för ett arbetsobjekt.

  • För varje övergång definierar du en standardorsak med hjälp av elementet DEFAULTREASON . Du kan definiera så många valfria orsaker som du vill med hjälp av elementet REASON . Dessa värden visas i den nedrullningsbara menyn i fältet Orsak .

  • Du kan ange regler som ska tillämpas när arbetsobjektet ändrar tillstånd, när det övergår eller när en användare väljer en specifik orsak. Många av dessa regler kompletterar de villkorsregler som du kan tillämpa när du definierar fälten FIELDS i avsnittet under WORKITEMTYPE definitionen. Mer information finns i Uppdatera fält under en arbetsflödesändring senare i det här avsnittet.

  • De namn som du tilldelar tillstånd och orsaker är skiftlägesokänsliga.

    De nedrullningsbara menyerna för fälten Tillstånd och Orsak i arbetsobjektsformuläret eller frågeredigeraren visar de värden som tilldelats i WORKFLOW avsnittet av arbetsobjekttypen.

Arbetsflödesdiagram och kodexempel

I följande kodexempel visas WORKFLOW för bug WIT-definitionen för den agila processmallen. Det här exemplet definierar tre tillstånd och fem övergångar. Elementen STATE anger tillstånden Aktiv, Löst och Stängd. Alla möjliga kombinationer för progressions- och regressionsövergångar definieras för de tre tillstånden, förutom ett. Övergången från Stängd till Löst har inte definierats. Gruppmedlemmar kan därför inte lösa ett arbetsobjekt av den här typen om arbetsobjektet stängs.

I det här exemplet visas inte alla element för DEFAULTREASON, REASON, ACTIONoch FIELD.

Exempel på arbetsflödestillståndsdiagram – Agile Bug WIT

Felarbetsflödestillstånd, agil processmall

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

Fastställa antal och typer av tillstånd

Du avgör antalet och typerna av giltiga tillstånd baserat på antalet distinkta logiska tillstånd där du vill att arbetsobjekten av den typen ska finnas. Om olika teammedlemmar utför olika åtgärder kan du också överväga att definiera ett tillstånd baserat på en medlemsroll. Varje tillstånd motsvarar en åtgärd som en gruppmedlem måste utföra på arbetsobjektet för att flytta den till nästa tillstånd. För varje tillstånd bör du definiera de specifika åtgärderna och de teammedlemmar som får utföra dessa åtgärder.

Följande tabell innehåller ett exempel på fyra tillstånd som har definierats för att spåra förloppet för en funktion och giltiga användare som måste utföra de angivna åtgärderna:

Tillstånd Giltig användare Action to perform
Föreslagen Projektledare Vem som helst kan skapa ett funktionsarbetsobjekt. Det är dock bara projektledare som kan godkänna eller ogilla arbetsobjektet. Om en projektledare godkänner en funktion ändrar projektledaren arbetsobjektets status till Aktiv. annars stänger en gruppmedlem den.
Aktiv Utvecklingsledare Utvecklingsledningen övervakar utvecklingen av funktionen. När funktionen är klar ändrar utvecklingsledningen statusen för funktionsarbetsobjektet till Granska.
Granskning Projektledare Projektledaren granskar funktionen som teamet implementerade och ändrar arbetsobjektets status till Stängd om implementeringen är tillfredsställande.
Stängda Projektledare Ingen ytterligare åtgärd förväntas utföras på arbetsobjekt som är stängda. Dessa objekt finns kvar i databasen i arkiverings- och rapporteringssyfte.

Kommentar

Alla tillstånd visas i alfabetisk ordning i listan i formuläret för ett arbetsobjekt av en viss typ, oavsett i vilken ordning du anger dem.

Definiera övergångar

Du styr tillstånden till och från vilka gruppmedlemmar kan ändra ett arbetsobjekt om du definierar giltiga tillståndsförlopp och regressioner. Om du inte definierar en övergång från ett tillstånd till ett annat tillstånd kan gruppmedlemmar inte ändra ett arbetsobjekt av en viss typ från ett visst tillstånd till ett annat visst tillstånd.

I följande tabell definieras giltiga övergångar för vart och ett av de fyra tillstånd som beskrevs tidigare i det här avsnittet, tillsammans med standardorsaken för var och en.

Tillstånd Övergång till tillstånd Standardorsak
Föreslagen Aktiv (progression) Godkänd för utveckling
Stängd (progression) Inte godkänd
Aktiv Granskning (progression) Godkännandekriterierna är uppfyllda
Granskning Stängd (progression) Funktionen är klar
Aktiv (regression) Uppfyller inte kraven
Stängda Föreslagen (regression) Ompröva för godkännande
Aktiv (regression) Fel har stängts

Du kan begränsa vem som får göra en övergång från ett tillstånd till ett annat genom att använda elementets TRANSITION för- och inte attribut. Som följande exempel visar kan testare öppna en bugg igen, men det kan inte utvecklare.

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

Ange orsakerna

När en gruppmedlem ändrar fältet Stat kan användaren behålla standardorsaken till övergången eller ange en annan orsak om du definierar ytterligare alternativ. Du måste använda -elementet DEFAULTREASON för att ange en och endast en standardorsak. Du bör endast ange ytterligare orsaker om de hjälper teamet att spåra eller rapportera data.

En utvecklare kan till exempel ange någon av följande orsaker när de löser ett fel: Fast (standard), Uppskjuten, Duplicerad, Som utformad, Kan inte återskapa eller Föråldrad. Varje orsak anger en viss åtgärd som testaren ska utföra när det gäller felet.

Kommentar

Alla orsaker visas i alfabetisk ordning i listan i arbetsformuläret för arbetsobjekt av en viss typ, oavsett i vilken ordning du anger elementen REASON .

I följande exempel visas de element som definierar orsakerna till varför en medlem i teamet kan lösa ett fel:

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

Ange åtgärder

I allmänhet ändrar gruppmedlemmar tillståndet för ett arbetsobjekt genom att ange ett annat värde för fältet Tillstånd och sedan spara arbetsobjektet. Du kan dock också definiera ett ACTION element som automatiskt ändrar tillståndet för ett arbetsobjekt när övergången sker. Som följande exempel visar kan du ange att felarbetsobjekt ska lösas automatiskt om de är associerade med filer som en utvecklare checkar in i versionskontroll:

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

Du kan använda -elementet ACTION för att automatiskt ändra tillståndet för arbetsobjekt av en viss typ när händelser inträffar någon annanstans i Microsoft Visual Studio Application Lifecycle Management eller utanför Visual Studio Application Lifecycle Management (till exempel från ett verktyg som spårar anrop). Mer information finns i ÅTGÄRD.

Uppdatera ett fält under en arbetsflödesändring

Du kan definiera regler som uppdaterar fält när följande händelser inträffar:

  • Tilldela en fältregel under STATE när du vill att regeln ska gälla för alla övergångar till och orsaker till att ange det tillståndet.

  • Tilldela en fältregel under TRANSITION när du vill att regeln ska gälla för den övergången och alla orsaker till övergången.

  • Tilldela en fältregel under DEFAULTREASON eller REASON när du vill att reglerna endast ska gälla av den specifika anledningen.

    Om ett fält alltid ska innehålla samma värde definierar du regeln under elementet FIELD som definierar det fältet. Mer information om regelanvändning finns i Regel- och regelutvärdering.

    Du bör försöka minimera antalet villkor som du definierar för en viss typ av arbetsobjekt. Med varje villkorsregel som du lägger till ökar du komplexiteten i valideringsprocessen som inträffar varje gång en teammedlem sparar ett arbetsobjekt. Komplexa regeluppsättningar kan öka den tid som krävs för att spara arbetsobjektet.

    I följande exempel visas några av de regler som tillämpas på systemfält i processmallen för MSF Agile Software Development.

Ändra värdet för ett fält när tillståndet ändras

När värdet för fältet Tillstånd för ett arbetsobjekt har angetts till Aktiv och arbetsobjektet sparas, anges värdena för fälten Aktiverad av och Tilldelad till automatiskt till namnet på den aktuella användaren. Användaren måste vara medlem i gruppen Giltiga användare för Team Foundation Server. Värdet för fältet Aktiverat datum anges också automatiskt. I följande exempel visas de element som tillämpar den här regeln:

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

Rensa värdet för ett fält när värdet för ett annat fält ändras

När värdet för fältet Tillstånd för ett arbetsobjekt har angetts till Aktivt och arbetsobjektet sparas, anges fälten Stängt datum och Stängt av automatiskt till null och skrivskyddade om du använder elementet EMPTY , vilket visas i följande exempel.

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

Definiera ett fält baserat på innehållet i ett annat fält

När värdet för fältet Tillstånd för ett arbetsobjekt ändras till Löst och arbetsobjektet sparas, anges värdet för fältet Lös orsak till det värde som användaren angav i fältet Orsak . I följande exempel visas de element som tillämpar den här regeln:

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

Verktygsstöd

Du kan ge användarna stöd för att visualisera arbetsflödet genom att installera visualiseringstillägget för tillståndsmodell från Visual Studio Marketplace.