Alterar o fluxo de trabalho de um tipo de item de trabalho

  • Artigo

Azure DevOps Server 2022 – Azure DevOps Server 2019

Você pode alterar o fluxo de trabalho de um tipo de item de trabalho (WIT) para dar suporte aos processos de negócios e de equipe. Os WITs oferecem suporte ao rastreamento de todos os tipos de trabalho — requisitos, tarefas, defeitos de código — para dar suporte ao desenvolvimento de software.

O fluxo de trabalho determina a progressão lógica e a regressão do trabalho que os membros da equipe executarão. Ele também especifica os valores que aparecem nos menus suspensos para os campos Estado e Motivo. Para obter mais informações, confira Sobre processos e modelos de processo.

Fluxo de trabalho para item Product Backlog (modelo de processo Scrum)

Fluxo de trabalho de item de lista de pendências Produto, processo do Scrum

Observação

Este artigo descreve como personalizar um estado de fluxo de trabalho. Se, em vez disso, você quiser alterar o estado atribuído a um item de trabalho específico, consulte um dos seguintes artigos: Quadro Kanban, Controlar trabalho em andamento ou Quadro de tarefas, Atualizar status da tarefa. Você também pode executar uma atualização em massa do estado para muitos itens de trabalho.

Para obter informações sobre fluxos de trabalho de pipeline de compilação, consulte Introdução ao CI/CD.

Atualizar a definição XML para um tipo de item de trabalho

Se você é novo na personalização do WIT, observe o seguinte:

  • Para personalizar qualquer aspecto de um tipo de item de trabalho, você deve atualizar sua definição XML. A definição XML é descrita em Todos os elementos XML WITD referência
  • Se você estiver personalizando o formulário da Web que usa a nova experiência de item de trabalho, convém fazer referência aos elementos WebLayout e Control
  • Se você estiver personalizando um formulário de cliente para uso com o Visual Studio, convém fazer referência ao elemento XML de layout
  • Siga a sequência de etapas descritas em Personalizar o formulário da Web de controle de item de trabalho.

Para personalizar o fluxo de trabalho, execute estas duas etapas:

  1. Modifique a WORKFLOW seção da definição de WIT conforme descrito neste tópico.

  2. Modifique a configuração do processo para mapear novos estados de fluxo de trabalho para metaestados.

    Essa segunda etapa é necessária quando você altera o fluxo de trabalho de um WIT que aparece em uma página de ferramenta Agile. Esses WITs pertencem às categorias Requisito ou Tarefa. Para saber mais sobre categorias de estado, confira Estados de fluxo de trabalho e categorias de estado.

Diretrizes de design de fluxo de trabalho

Você define o fluxo de trabalho identificando primeiro os estados e as transições válidas entre eles. A WORKFLOW seção da definição de WIT especifica os estados válidos, transições, motivos para as transições e ações opcionais que serão executadas quando um membro da equipe alterar o estado de um item de trabalho.

Em geral, você associa cada estado a uma função de membro da equipe e a uma tarefa que uma pessoa nessa função deve executar para processar o item de trabalho antes de alterar seu estado. As transições definem as progressões e regressões válidas entre estados. Os motivos identificam por que um membro da equipe altera um item de trabalho de um estado para outro e as ações oferecem suporte à automação da transição de um item de trabalho em um ponto do fluxo de trabalho.

Por exemplo, o Estado é definido como Novo quando um testador abre um novo bug baseado no processo Agile padrão. O desenvolvedor altera o estado para Ativo ao corrigir o bug e, uma vez corrigido, o desenvolvedor altera seu estado para Resolvido e define o valor do campo Motivo como Corrigido. Depois de verificar a correção, o testador altera o estado do bug para Fechado e o campo Motivo muda para Verificado. Se o testador determinasse que o desenvolvedor não havia corrigido o bug, ele alteraria o estado do bug para Ativo e especificaria o Motivo como Não Corrigido ou Falha no Teste.

Ao projetar ou modificar um fluxo de trabalho, considere as seguintes diretrizes:

  • Use o elemento para definir um estado exclusivo para cada função de membro da STATE equipe que executará uma ação específica em um item de trabalho. Quanto mais estados você definir, mais transições você deve definir. Independentemente da sequência na qual você define os estados, eles são listados em ordem alfanumérica no menu suspenso do campo Estado .

    Se você adicionar um estado a um tipo de item de trabalho que aparece nas páginas de lista de pendências ou no quadro no portal da Web, também deverá mapear o estado para uma categoria de estado. Para saber mais, revise os estados e as categorias de estado do fluxo de trabalho.

  • Use o TRANSITION elemento para definir uma transição para cada progressão e regressão válidas de um estado para outro.

    No mínimo, você deve definir uma transição para cada estado e a transição do estado nulo para o estado inicial.

    Você pode definir apenas uma transição de não atribuído (nulo) para o estado inicial. Quando você salva um novo item de trabalho, ele é atribuído automaticamente ao estado inicial.

    Quando um membro da equipe altera o estado de um item de trabalho, essa alteração aciona a transição e as ações que você define para serem executadas para o estado selecionado e a transição. Os usuários podem especificar somente os estados que são válidos com base nas transições que você define para o estado atual. Além disso, um ACTION elemento, que é um elemento filho de TRANSITION, pode alterar o estado de um item de trabalho.

  • Para cada transição, você define um motivo padrão usando o DEFAULTREASON elemento . Você pode definir quantos motivos opcionais desejar usando o REASON elemento . Esses valores aparecem no menu suspenso do campo Motivo .

  • Você pode especificar regras que serão aplicadas quando o item de trabalho mudar de estado, quando ele fizer a transição ou quando um usuário selecionar um motivo específico. Muitas dessas regras complementam as regras condicionais que você pode aplicar ao definir os campos na FIELDS seção sob a WORKITEMTYPE definição. Para obter mais informações, consulte Atualizar campos durante uma alteração de fluxo de trabalho mais adiante neste tópico.

  • Os nomes atribuídos a estados e motivos não diferenciam maiúsculas de minúsculas.

    Os menus suspensos dos campos Estado e Motivo no formulário de item de trabalho ou no editor de consultas exibem os valores atribuídos na WORKFLOW seção do tipo de item de trabalho.

Diagrama de fluxo de trabalho e exemplo de código

O exemplo de código a seguir mostra a WORKFLOW definição de WIT de bug para o modelo de processo Agile. Este exemplo define três estados e cinco transições. Os STATE elementos especificam os estados Ativo, Resolvido e Fechado. Todas as combinações possíveis para transições de progressão e regressão são definidas para os três estados, exceto um. A transição de Fechado para Resolvido não está definida. Portanto, os membros da equipe não podem resolver um item de trabalho desse tipo se o item de trabalho estiver fechado.

Este exemplo não lista todos os elementos de DEFAULTREASON, REASON, ACTIONe FIELD.

Exemplo de diagrama de estado do fluxo de trabalho — Agile Bug WIT

Estados do fluxo de trabalho do bug, modelo de processo Agile

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

Determinar o número e os tipos de estados

Você determina o número e os tipos de estados válidos com base no número de estados lógicos distintos nos quais deseja que os itens de trabalho desse tipo existam. Além disso, se diferentes membros da equipe executarem ações diferentes, você poderá considerar a definição de um estado com base em uma função de membro. Cada estado corresponde a uma ação que um membro da equipe deve executar no item de trabalho para movê-lo para o próximo estado. Para cada estado, você deve definir as ações específicas e os membros da equipe que têm permissão para executar essas ações.

A tabela a seguir fornece um exemplo de quatro estados que são definidos para controlar o progresso de um recurso e os usuários válidos que devem executar as ações indicadas:

Estado Usuário válido Ação a ser executada
Proposto Gerente de projeto Qualquer pessoa pode criar um item de trabalho de recurso. No entanto, somente os gerentes de projeto podem aprovar ou reprovar o item de trabalho. Se um gerente de projeto aprovar um recurso, o gerente de projeto alterará o status do item de trabalho para Ativo; caso contrário, um membro da equipe o fecha.
Ativa Líder de desenvolvimento O líder de desenvolvimento supervisiona o desenvolvimento do recurso. Quando o recurso é concluído, o líder de desenvolvimento altera o status do item de trabalho do recurso para Revisão.
Revisão Gerente de projeto O gerente de projeto revisa o recurso que a equipe implementou e altera o status do item de trabalho para Fechado se a implementação for satisfatória.
Fechadas Gerente de projeto Nenhuma ação adicional deve ocorrer em itens de trabalho que estão fechados. Esses itens permanecem no banco de dados para fins de arquivamento e relatório.

Observação

Todos os estados aparecem em ordem alfabética na lista no formulário para um item de trabalho de um tipo específico, independentemente da sequência na qual você os especificar.

Definir transições

Você controla os estados para e a partir dos quais os membros da equipe podem alterar um item de trabalho se definir as progressões e regressões de estado válidas. Se você não definir uma transição de um estado para outro, os membros da equipe não poderão alterar um item de trabalho de um tipo específico de um estado específico para outro estado específico.

A tabela a seguir define as transições válidas para cada um dos quatro estados descritos anteriormente neste tópico, juntamente com o motivo padrão para cada um.

Estado Transição para estado Motivo padrão
Proposto Ativo (progressão) Aprovado para desenvolvimento
Fechado (progressão) Não aprovado
Ativa Revisão (progressão) Critérios de aceitação atendidos
Revisão Fechado (progressão) Recurso completo
Ativo (regressão) Não atende aos requisitos
Fechadas Proposta (regressão) Reconsiderar para aprovação
Ativo (regressão) Fechado por erro

Você pode restringir quem tem permissão para fazer uma transição de um estado para outro usando os atributos for e not do TRANSITION elemento. Como mostra o exemplo a seguir, os testadores podem reabrir um bug, mas os desenvolvedores não.

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

Especifique os motivos

Quando um membro da equipe altera o campo Estado, esse usuário pode manter o motivo padrão para essa transição ou especificar um motivo diferente se você definir opções adicionais. Você deve usar o DEFAULTREASON elemento para especificar um e apenas um motivo padrão. Você deve especificar motivos adicionais somente se eles ajudarem a equipe a controlar ou relatar dados.

Por exemplo, um desenvolvedor pode especificar um dos seguintes motivos ao resolver um bug: Corrigido (padrão), Adiado, Duplicado, Conforme projetado, Não é possível reproduzir ou Obsoleto. Cada motivo especifica uma ação específica para o testador executar em relação ao bug.

Observação

Todos os motivos aparecem em ordem alfabética na lista no formulário de trabalho para itens de trabalho de um tipo específico, independentemente da sequência na qual você especifica os REASON elementos.

O exemplo a seguir mostra os elementos que definem os motivos pelos quais um membro da equipe pode resolver um bug:

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

Especificar ações

Em geral, os membros da equipe alteram o estado de um item de trabalho especificando um valor diferente para o campo Estado e, em seguida, salvando o item de trabalho. No entanto, você também pode definir um ACTION elemento que altera automaticamente o estado de um item de trabalho quando essa transição ocorre. Como mostra o exemplo a seguir, você pode especificar que os itens de trabalho de bug devem ser resolvidos automaticamente se estiverem associados a arquivos que um desenvolvedor verifica no controle de versão:

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

Você pode usar o ACTION elemento para alterar automaticamente o estado dos itens de trabalho de um tipo específico quando os eventos ocorrem em outro lugar no Microsoft Visual Studio Application Lifecycle Management ou fora do Visual Studio Application Lifecycle Management (por exemplo, de uma ferramenta que controla chamadas). Para obter mais informações, consulte ACTION.

Atualizar um campo durante uma alteração de fluxo de trabalho

Você pode definir regras que atualizam campos sempre que os seguintes eventos ocorrem:

  • Atribua uma regra de campo em STATE quando você deseja que a regra se aplique a todas as transições e motivos para entrar nesse estado.

  • Atribua uma regra de campo em TRANSITION quando você deseja que a regra se aplique a essa transição e todos os motivos para fazer essa transição.

  • Atribua uma regra de campo em DEFAULTREASON ou REASON quando desejar que as regras se apliquem somente por esse motivo específico.

    Se um campo deve sempre conter o mesmo valor, você define a regra sob o FIELD elemento que define esse campo. Para saber mais sobre o uso de regras, consulte Regras e avaliação de regras.

    Você deve tentar minimizar o número de condições definidas para qualquer tipo de item de trabalho. Com cada regra condicional adicionada, você aumenta a complexidade do processo de validação que ocorre sempre que um membro da equipe salva um item de trabalho. Conjuntos de regras complexos podem aumentar o tempo necessário para salvar o item de trabalho.

    Os exemplos a seguir mostram algumas das regras aplicadas aos campos do sistema no modelo de processo do MSF Agile Software Development.

Alterar o valor de um campo quando o estado for alterado

Quando o valor do campo Estado de um item de trabalho é definido como Ativo e o item de trabalho é salvo, os valores dos campos Ativado por e Atribuído a são definidos automaticamente como o nome do usuário atual. Esse usuário deve ser um membro do grupo Usuários válidos do Team Foundation Server. O valor do campo Data de Ativação também é definido automaticamente. O exemplo a seguir mostra os elementos que impõem essa regra:

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

Limpar o valor de um campo quando o valor de outro campo for alterado

Quando o valor do campo Estado de um item de trabalho é definido como Ativo e o item de trabalho é salvo, os campos Data Fechada e Fechado por são automaticamente definidos como nulos e tornados somente leitura se você usar o EMPTY elemento , como mostra o exemplo a seguir.

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

Definir um campo com base no conteúdo de outro campo

Quando o valor do campo Estado de um item de trabalho é alterado para Resolvido e o item de trabalho é salvo, o valor do campo Motivo Resolvido é definido como o valor que o usuário especificou no campo Motivo. O exemplo a seguir mostra os elementos que impõem essa regra:

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

Suporte a ferramentas

Você pode oferecer suporte aos usuários para visualizar o fluxo de trabalho instalando a extensão de Visualização de Modelo de Estado do Visual Studio Marketplace.