De werkstroom voor een werkitemtype wijzigen

Azure DevOps Server | Azure DevOps Server 2022

Wijzig de werkstroom voor een werkitemtype (WIT) om uw bedrijfsprocessen en teamprocessen te ondersteunen. WITs biedt ondersteuning voor het bijhouden van alle soorten werk( vereisten, taken, codefouten) ter ondersteuning van softwareontwikkeling.

De werkstroom bepaalt de logische voortgang en regressie van het werk dat teamleden uitvoeren. Ook worden de waarden opgegeven die worden weergegeven in de vervolgkeuzelijsten voor de velden Status en Reden. Zie Voor meer informatie over processen en processjablonen.

Werkstroom voor productachterstanditem (Scrum-processjabloon)

De XML-definitie voor een werkitemtype bijwerken

Houd rekening met het volgende als u geen kennis hebt van WIT-aanpassing:

• Als u elk aspect van een type werkitem wilt aanpassen, werkt u de XML-definitie bij. Zie de naslaginformatie over alle WITD XML-elementen voor meer informatie.
• Zie de elementen WebLayout en Control als u het webformulier wijzigt dat gebruikmaakt van de nieuwe werkervaring.
• Als u een clientformulier aanpast voor gebruik met Visual Studio, raadpleegt u de referentie voor het XML-element indeling.
• Volg de volgorde van de stappen die worden beschreven in het webformulier Voor het bijhouden van werkitems aanpassen.

Volg deze twee stappen om de werkstroom aan te passen:

1. Wijzig de WORKFLOW sectie van de WIT-definitie zoals beschreven in dit onderwerp.

2. Wijzig de procesconfiguratie om nieuwe werkstroomstatussen toe te wijzen aan metastaten.

   Deze tweede stap is vereist wanneer u de werkstroom wijzigt voor een WIT die wordt weergegeven op een Agile-hulpprogrammapagina. Deze WIT's behoren tot de categorieën Vereiste of Taak. Zie Werkstroomstatussen en statuscategorieën voor meer informatie over statuscategorieën.

Richtlijnen voor werkstroomontwerp

Definieer de werkstroom door eerst de statussen en de geldige overgangen tussen de statussen te identificeren. De WORKFLOW sectie van de WIT-definitie geeft de geldige statussen, overgangen, redenen voor de overgangen en optionele acties op die worden uitgevoerd wanneer een teamlid de status van een werkitem wijzigt.

In het algemeen koppelt u elke status aan een teamlidrol en een taak die een persoon in die rol moet uitvoeren om het werkitem te verwerken voordat u de status wijzigt. Overgangen definiëren de geldige voortgangen en regressies tussen statussen. Redenen waarom een teamlid een werkitem wijzigt van de ene status naar de andere, en acties ondersteunen automatisering van de overgang van een werkitem op een punt in de werkstroom.

Stel bijvoorbeeld de status in op Nieuw wanneer een tester een nieuwe fout opent die is gebaseerd op het standaard Agile-proces. De ontwikkelaar wijzigt de status Actief bij het oplossen van de fout en zodra deze is opgelost, wijzigt de ontwikkelaar de status in Opgelost en stelt de waarde van het veld Reden in op Vast. Nadat de fix is gecontroleerd, verandert de tester de status van de fout in Gesloten en verandert het veld Reden in Geverifieerd. Als de tester heeft vastgesteld dat de ontwikkelaar de fout niet heeft opgelost, wijzigt de tester de status van de fout in Actief en geeft de reden aan als Niet opgelost of Test mislukt.

Houd rekening met de volgende richtlijnen wanneer u een werkstroom ontwerpt of wijzigt:

• Gebruik het STATE element om een unieke status te definiëren voor elke teamlidrol die een specifieke actie op een werkitem uitvoert. Hoe meer statussen u definieert, hoe meer overgangen u moet definiëren. Ongeacht de volgorde waarin u de statussen definieert, worden deze weergegeven in alfanumerieke volgorde in de vervolgkeuzelijst voor het veld Staat .

  Als u een status toevoegt aan een werkitemtype dat wordt weergegeven op de achterstands- of bordpagina's in de webportal, moet u de status ook toewijzen aan een statuscategorie. Zie Werkstroomstatussen en statuscategorieën voor meer informatie.

• Gebruik het TRANSITION element om een overgang te definiëren voor elke geldige voortgang en regressie van de ene toestand naar de andere.

  Definieer minimaal één overgang voor elke status en de overgang van de null-status naar de oorspronkelijke status.

  U kunt slechts één overgang definiëren van niet-toegewezen (null) naar de beginstatus. Wanneer u een nieuw werkitem opslaat, wordt dit automatisch toegewezen aan de beginstatus.

  Wanneer een teamlid de status van een werkitem wijzigt, activeert die wijziging de overgang en de acties die u definieert om te worden uitgevoerd voor de geselecteerde status en de overgang. Gebruikers kunnen alleen statussen opgeven die geldig zijn op basis van de overgangen die u definieert voor de huidige status. Daarnaast kan een ACTION-element, dat een onderliggend element is van TRANSITION, de status van een werkitem wijzigen.

• Definieer voor elke overgang een standaardreden met behulp van het DEFAULTREASON element. U kunt zoveel optionele redenen definiëren als u wilt met behulp van het REASON element. Deze waarden worden weergegeven in de vervolgkeuzelijst van het veld Reden .

• U kunt regels opgeven die van toepassing zijn wanneer het werkitem de status wijzigt, wanneer het overgaat of wanneer een gebruiker een specifieke reden selecteert. Veel van deze regels vormen een aanvulling op de voorwaardelijke regels die u kunt toepassen wanneer u de velden in de FIELDS sectie onder de WORKITEMTYPE definitie definieert. Zie Velden bijwerken tijdens een werkstroomwijziging verderop in dit onderwerp voor meer informatie.

• De namen die u aan staten en redenen geeft, zijn niet hoofdlettergevoelig.

  In de vervolgkeuzelijsten voor de velden Status en Reden in het werkitemformulier of de queryeditor worden de waarden weergegeven die zijn toegewezen in de WORKFLOW sectie van het werkitemtype.

Voorbeeld van werkstroomdiagram en code

In het volgende codevoorbeeld ziet u de WORKFLOW definitie voor bug-WIT voor de Agile-processjabloon. In dit voorbeeld worden drie statussen en vijf overgangen gedefinieerd. De STATE elementen geven de status Actief, Opgelost en Gesloten op. Alle mogelijke combinaties voor voortgangs- en regressieovergangen worden gedefinieerd voor de drie toestanden, behalve één. De overgang van Gesloten naar Opgelost is niet gedefinieerd. Daarom kunnen teamleden een werkitem van dit type niet oplossen als het werkitem is gesloten.

In dit voorbeeld worden niet alle elementen voor DEFAULTREASON, REASON, ACTION en FIELD.

Voorbeeld van werkstroomstatusdiagram - Agile Bug WIT

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

Het aantal en typen statussen bepalen

Bepaal het aantal en de typen geldige statussen op basis van het aantal afzonderlijke logische statussen waarin u de werkitems van dat type wilt laten bestaan. Als verschillende teamleden verschillende acties uitvoeren, kunt u ook overwegen om een status te definiëren op basis van een lidrol. Elke status komt overeen met een actie die een teamlid moet uitvoeren op het werkitem om het naar de volgende status te verplaatsen. Definieer voor elke status de specifieke acties en de teamleden die deze acties mogen uitvoeren.

De volgende tabel bevat een voorbeeld van vier statussen waarmee de voortgang van een functie wordt bijgehouden en de geldige gebruikers die de aangegeven acties moeten uitvoeren:

Overgangen definiëren

U bepaalt de statussen van en van waaruit teamleden een werkitem kunnen wijzigen door de geldige statusvoortgangen en regressies te definiëren. Als u geen overgang van de ene status naar een andere status definieert, kunnen teamleden een werkitem van een bepaald type niet wijzigen van een bepaalde status in een andere bepaalde status.

In de volgende tabel worden de geldige overgangen gedefinieerd voor elk van de vier statussen die eerder in dit onderwerp zijn beschreven, samen met de standaardreden voor elke status.

U kunt beperken wie een overgang van de ene status naar de andere mag maken met behulp van de voor - en niet kenmerken van het TRANSITION element. Zoals in het volgende voorbeeld wordt weergegeven, kunnen testers een fout opnieuw openen, maar ontwikkelaars dat niet.

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

Geef de redenen op

Wanneer een teamlid het veld Staat wijzigt, kunnen ze de standaardreden voor die overgang behouden of een andere reden opgeven als u aanvullende opties definieert. Gebruik het DEFAULTREASON element om één en slechts één standaardreden op te geven. Voeg alleen extra redenen toe als ze het team helpen bij het bijhouden of rapporteren van gegevens.

Een ontwikkelaar kan bijvoorbeeld een van de volgende redenen opgeven wanneer ze een fout oplossen: Opgelost (standaard), Uitgesteld, Dupliceren, Zoals ontworpen, Kan niet reproduceren of Verouderd. Elke reden specificeert een bepaalde actie voor de tester die moet worden uitgevoerd met betrekking tot de fout.

In het volgende voorbeeld ziet u de elementen die bepalen waarom een lid van het team een fout kan oplossen:

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

Acties specificeren

In het algemeen wijzigen teamleden de status van een werkitem door een andere waarde op te geven voor het veld Staat en vervolgens het werkitem op te slaan. U kunt echter ook een ACTION element definiëren dat automatisch de status van een werkitem wijzigt wanneer deze overgang plaatsvindt. Zoals in het volgende voorbeeld wordt weergegeven, kunt u opgeven dat foutwerkitems automatisch moeten worden opgelost als ze zijn gekoppeld aan bestanden die een ontwikkelaar in versiebeheer controleert:

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

Gebruik het ACTION element om automatisch de status van werkitems van een bepaald type te wijzigen wanneer gebeurtenissen ergens anders plaatsvinden in Microsoft Visual Studio Application Lifecycle Management of buiten Visual Studio Application Lifecycle Management (bijvoorbeeld vanuit een hulpprogramma waarmee aanroepen worden bijgehouden). Zie ACTION voor meer informatie.

Een veld bijwerken tijdens een werkstroomwijziging

U kunt regels definiëren waarmee velden worden bijgewerkt wanneer de volgende gebeurtenissen plaatsvinden:

• Wijs een veldregel toe onder STATE wanneer u wilt dat de regel van toepassing is op alle overgangen naar en redenen voor het invoeren van die status.

• Wijs een veldregel toe onder TRANSITION wanneer u wilt dat de regel van toepassing is op die overgang en alle redenen voor het maken van die overgang.

• Wijs een veldregel toe onder DEFAULTREASON of REASON wanneer u wilt dat de regels alleen van toepassing zijn op die specifieke reden.

  Als een veld altijd dezelfde waarde moet bevatten, definieert u de regel onder het FIELD element dat dat veld definieert. Zie Regels en regelevaluatie voor meer informatie over het gebruik van regels.

  Minimaliseer het aantal voorwaarden dat u definieert voor elk type werkitem. Elke voorwaardelijke regel voegt complexiteit toe aan het validatieproces dat plaatsvindt telkens wanneer een teamlid een werkitem opslaat. Complexe regelsets kunnen de tijd verhogen die nodig is om het werkitem op te slaan.

  In de volgende voorbeelden ziet u enkele van de regels die worden toegepast op systeemvelden in de processjabloon voor MSF Agile Software Development.

De waarde van een veld wijzigen wanneer de status wordt gewijzigd

Wanneer u de waarde van het veld Status voor een werkitem instelt op Actief en het werkitem opslaat, worden de waarden van de velden Geactiveerd door en Toegewezen aan automatisch ingesteld op de naam van de huidige gebruiker. Deze gebruiker moet lid zijn van de groep Geldige gebruikers van Team Foundation Server. De waarde van het veld Geactiveerde datum wordt ook automatisch ingesteld. In het volgende voorbeeld ziet u de elementen die deze regel afdwingen:

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

De waarde van een veld wissen wanneer de waarde van een ander veld verandert

Wanneer u de waarde van het veld Status voor een werkitem instelt op Actief en het werkitem opslaat, stelt het EMPTY element automatisch de velden Gesloten datum en Gesloten door in op null en worden ze alleen-lezen, zoals in het volgende voorbeeld wordt weergegeven.

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

Een veld definiëren op basis van de inhoud van een ander veld

Wanneer u de waarde van het veld Staat voor een werkitem wijzigt in Opgelost en het werkitem opslaat, wordt de waarde van het veld Opgeloste reden ingesteld op de waarde die de gebruiker heeft opgegeven in het veld Reden . In het volgende voorbeeld ziet u de elementen die deze regel afdwingen:

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

Verwante inhoud

• Werkstroomstatussen en statuscategorieën
• Pas uw ervaring bij het bijhouden van werk aan
• Zoek op toewijzing, werkstroom of wijzigingen in het bord
• Het werkitemformulier ontwerpen
• Importeren, exporteren en beheren van typen werkitems

Ondersteuning voor hulpmiddelen

Installeer de extensie State Model Visualization vanuit Visual Studio Marketplace om uw gebruikers te helpen de werkstroom te visualiseren.