Delen via

De werkstroom voor een werkitemtype wijzigen

  • Artikel

Azure DevOps Server 2022 - Azure DevOps Server 2019

U kunt de werkstroom voor een werkitemtype (WIT) wijzigen om uw zakelijke 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 zullen 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)

Werkstroom voor productachterstanditems, Scrum-proces

Notitie

In dit artikel wordt beschreven hoe u een werkstroomstatus aanpast. Als u in plaats daarvan de status wilt wijzigen die is toegewezen aan een specifiek werkitem, raadpleegt u een van de volgende artikelen: Kanbanbord, Werk in uitvoering bijhouden of Taakbord, Taakstatus bijwerken. U kunt ook een bulkupdate van de status uitvoeren voor veel werkitems.

Zie Aan de slag met CI/CD voor informatie over werkstromen voor build-pijplijnen.

De XML-definitie voor een werkitemtype bijwerken

Als u geen kennis hebt van wit-aanpassing, moet u rekening houden met het volgende:

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

U definieert de werkstroom door eerst de statussen en de geldige overgangen ertussen 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.

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

De status is bijvoorbeeld ingesteld 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 had opgelost, zou de tester de status van de fout wijzigen in Actief en de reden opgeven als Niet opgelost of Test is 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. Bekijk 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.

    U moet minimaal één overgang definiëren 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, een onderliggend element, TRANSITIONde status van een werkitem wijzigen.

  • Voor elke overgang definieert u 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 worden toegepast 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 toewijst aan statussen en redenen, 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. Teamleden kunnen daarom geen werkitem van dit type oplossen als het werkitem is gesloten.

In dit voorbeeld worden niet alle elementen voor DEFAULTREASON, REASONen ACTIONFIELD.

Voorbeeld van werkstroomstatusdiagram - Agile Bug WIT

Foutwerkstroomstatussen, Agile-processjabloon

<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

U bepaalt het aantal en de typen geldige statussen op basis van het aantal afzonderlijke logische toestanden waarin u wilt dat de werkitems van dat type 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. Voor elke status moet u de specifieke acties en de teamleden definiëren die deze acties mogen uitvoeren.

De volgende tabel bevat een voorbeeld van vier statussen die zijn gedefinieerd om de voortgang van een functie bij te houden en de geldige gebruikers die de aangegeven acties moeten uitvoeren:

Staat Geldige gebruiker Action to perform
Voorgesteld Projectmanager Iedereen kan een functiewerkitem maken. Alleen projectmanagers kunnen het werkitem echter goedkeuren of afwijzen. Als een projectmanager een functie goedkeurt, wijzigt de projectmanager de status van het werkitem in Actief; anders sluit een teamlid het.
Actief Ontwikkelingsleider De ontwikkelingsleider houdt toezicht op de ontwikkeling van de functie. Wanneer de functie is voltooid, verandert de ontwikkelingsleider de status van het functiewerkitem in Controleren.
Beoordelen Projectmanager De projectmanager beoordeelt de functie die het team heeft geïmplementeerd en wijzigt de status van het werkitem in Gesloten als de implementatie bevredigend is.
Gesloten Projectmanager Er wordt verwacht dat er geen extra actie wordt uitgevoerd op werkitems die zijn gesloten. Deze items blijven in de database voor archiverings- en rapportagedoeleinden.

Notitie

Alle statussen worden in alfabetische volgorde weergegeven in de lijst op het formulier voor een werkitem van een bepaald type, ongeacht de volgorde waarin u deze opgeeft.

Overgangen definiëren

U bepaalt de statussen van en van waaruit teamleden een werkitem kunnen wijzigen als u de geldige statusvoortgangen en regressies definieert. Als u geen overgang van de ene status naar een andere status definieert, kunnen teamleden geen werkitem van een bepaald type 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.

Staat Overgang naar status Standaardreden
Voorgesteld Actief (voortgang) Goedgekeurd voor ontwikkeling
Gesloten (voortgang) Niet goedgekeurd
Actief Controleren (voortgang) Aan acceptatiecriteria is voldaan
Beoordelen Gesloten (voortgang) Functie voltooid
Actief (regressie) Voldoet niet aan de vereisten
Gesloten Voorgesteld (regressie) Herzien voor goedkeuring
Actief (regressie) Gesloten in fout

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

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

Geef de redenen op

Wanneer een teamlid het veld Staat wijzigt, kan die gebruiker de standaardreden voor die overgang behouden of een andere reden opgeven als u aanvullende opties definieert. U moet het DEFAULTREASON element gebruiken om één en slechts één standaardreden op te geven. U moet alleen aanvullende redenen opgeven 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.

Notitie

Alle redenen worden in alfabetische volgorde weergegeven in de lijst op het werkformulier voor werkitems van een bepaald type, ongeacht de volgorde waarin u de REASON elementen opgeeft.

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 opgeven

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>

U kunt het ACTION element gebruiken 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.

    Probeer het aantal voorwaarden dat u definieert voor elk type werkitem te minimaliseren. Met elke voorwaardelijke regel die u toevoegt, verhoogt u de complexiteit van het validatieproces dat plaatsvindt telkens wanneer een teamlid een werkitem opslaat. Complexe regelsets kunnen de tijd die nodig is om het werkitem op te slaan, verhogen.

    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 de waarde van het veld Status voor een werkitem is ingesteld op Actief en het werkitem wordt opgeslagen, 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 de waarde van het veld Status voor een werkitem is ingesteld op Actief en het werkitem wordt opgeslagen, worden de velden Gesloten en Gesloten door automatisch ingesteld op null en alleen-lezen als u het EMPTY element gebruikt, 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 de waarde van het veld Status voor een werkitem verandert in Opgelost en het werkitem wordt opgeslagen, 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>

Ondersteuning voor hulpprogramma's

U kunt uw gebruikers ondersteunen om de werkstroom te visualiseren door de extensie State Model Visualization te installeren vanuit Visual Studio Marketplace.