Partilhar via

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

  • Artigo

Azure DevOps Server 2022 - Azure DevOps Server 2019

Você pode alterar o fluxo de trabalho para um tipo de item de trabalho (WIT) para dar suporte aos processos de negócios e de equipe. Os WITs suportam o 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, consulte Sobre processos e modelos de processo.

Workflow para Product Backlog Item (modelo de processo Scrum)

Fluxo de trabalho de itens da lista de pendências do produto, processo Scrum

Nota

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, Acompanhar 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 WIT, observe o seguinte:

  • Para personalizar qualquer aspeto 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 à referência do elemento Layout XML
  • Siga a sequência de etapas descrita em Personalizar o formulário da Web de acompanhamento de item de trabalho.

Para personalizar o fluxo de trabalho, siga 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 do fluxo de trabalho para metaestados.

    Esta segunda etapa é necessária quando você altera o fluxo de trabalho para um WIT que aparece em uma página de ferramenta Agile. Esses WITs pertencem às categorias Requisito ou Tarefa. Para obter mais informações sobre categorias de estado, consulte 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 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 dão 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 Razão 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, o testador 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 em que você define os estados, eles são listados em ordem alfanumérica no menu suspenso para o campo Estado .

    Se você adicionar um estado a um tipo de item de trabalho que aparece nas páginas da lista de pendências ou do quadro no portal da Web, também deverá mapear o estado para uma categoria de estado. Para obter mais informações, consulte Estados e categorias de estado do fluxo de trabalho.

  • Use o TRANSITION elemento para definir uma transição para cada progressão válida e regressão 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 dispara 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 apenas 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 quiser 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 para os campos Estado e Razão no formulário de item de trabalho ou no editor de consultas exibem os WORKFLOW valores atribuídos na 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 para DEFAULTREASON, REASON, ACTION, e FIELD.

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

Estados de fluxo de trabalho de bugs, modelo de processo ágil

<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 acompanhar o progresso de um recurso e os usuários válidos que devem executar as ações indicadas:

Estado Utilizador válido Action to perform
Proposto Gestor de projeto Qualquer pessoa pode criar um item de trabalho de recurso. No entanto, apenas 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.
Ativos Líder de desenvolvimento O líder de desenvolvimento supervisiona o desenvolvimento do recurso. Quando o recurso é concluído, o lead de desenvolvimento altera o status do item de trabalho do recurso para Revisão.
Rever Gestor de projeto O gerente de projeto analisa o recurso que a equipe implementou e altera o status do item de trabalho para Fechado se a implementação for satisfatória.
Fechadas Gestor 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órios.

Nota

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 em que você os especificar.

Definir transições

Você controla os estados de e para os 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 determinado tipo de um determinado estado 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 o estado Motivo padrão
Proposto Ativo (progressão) Aprovado para desenvolvimento
Fechado (progressão) Não aprovado
Ativos Revisão (progressão) Critérios de aceitação cumpridos
Rever Fechado (progressão) Funcionalidade completa
Ativo (regressão) Não cumpre os requisitos
Fechadas Proposta (regressão) Reconsiderar para aprovação
Ativo (regressão) Fechado por engano

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>

Especificar 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 rastrear 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.

Nota

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 rastreia chamadas). Para obter mais informações, consulte AÇÃO.

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

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

  • 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 sob DEFAULTREASON ou REASON quando quiser que as regras se apliquem apenas por esse motivo específico.

    Se um campo deve conter sempre o mesmo valor, você define a regra sob o FIELD elemento que define esse campo. Para obter mais informações sobre o uso de regras, consulte Avaliação de regras e 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 para o MSF Agile Software Development.

Alterar o valor de um campo quando o estado é 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 automaticamente definidos 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 elemento , como mostra o EMPTY 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 muda para Resolvido e o item de trabalho é salvo, o valor do campo Motivo Resolvido é definido como o valor especificado pelo usuário 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 de ferramentas

Você pode oferecer suporte aos usuários para visualizar o fluxo de trabalho instalando a extensão State Model Visualization do Visual Studio Marketplace.