Criar o fluxo de trabalho

Você cria o fluxo de trabalho para um tipo de item de trabalho suporte negócio e seus processos de equipe.O fluxo de trabalho determina a progressão lógica de tarefas por que serão executadas e por quem.Você define o fluxo de trabalho primeiro identificando os estados válidos e as transições entre eles.A seção de WORKFLOW de definição para o tipo de item de trabalho define os estados válidos, transições, motivos para as transições, e as ações opcionais que serão executadas quando um membro da equipe altera o estado de um item de trabalho.Para obter mais informações sobre as definições de tipo, consulte Todas as referências de elementos XML WITD.

Geralmente, você associa cada estado com uma função de membro da equipe e 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 as regressões entre estados válidos.As razões identificam como um membro da equipe altera um item de trabalho de um estado para outro, e as ações oferecem suporte a automação de transição de um item de trabalho em um ponto no fluxo de trabalho.

Importante
Se você adicionar um estado para um tipo de item de trabalho que apareça em páginas de fallback ou em branco em Team Web Access, você também deve mapear o estado em um metastate.Consulte Personalizar a lista de pendências e as páginas do quadro usando a configuração do processo.

Por exemplo, o estado é definido como Novo quando um verificador abre um novo erro que é baseado no modelo agile padrão do processo que Team Foundation Server (TFS) fornece.O desenvolvedor altera o estado a Ativo para corrigir o erro, e corrigido uma vez, o desenvolvedor altera o estado a Resolvido e define o valor do campo da razão Fixo.Após ter verificado a correção, o testador alterar o estado de erro a Fechado e o campo de razão alterações a Verificado.Se o testador determinar que o desenvolvedor não tivesse corrigido o erro, o testador alteraria o estado de erro a Ativo e deve especificar a razão como Não corrigido ou Falha no teste.

Observação
Você pode criar e modificar as definições para tipos de itens de trabalho e outros objetos aos itens de trabalho de controlar usando o editor do processo, uma ferramenta avançada para Visual Studio.Essa ferramenta não é suportada.Para obter mais informações, consulte a seguinte página no site da Microsoft: Ferramentas poderosas do Team Foundation Server.

Neste tópico

• Diretrizes de design de fluxo de trabalho

• Diagrama de fluxo de trabalho e exemplo de código

• Determinando o número e tipos de estados

• Definindo as transições

  • Especificando as razões

  • Especificando ações

• Atualizando um campo quando as alterações de estado

  • Definindo um campo quando as alterações de estado

  • Limpar o valor de um campo

  • Definindo um campo com base no conteúdo de outro campo

• Exibindo o diagrama de estado de fluxo de trabalho

Diretrizes de design de fluxo de trabalho

Como você cria ou alterar um fluxo de trabalho, considere as seguintes diretrizes:

• Usando o elemento de STATE , você define um estado exclusivo para cada função de membro da equipe que terá uma ação específica em um item de trabalho.Mais estados que você define, mais transições você deve definir.Independentemente da sequência na qual você define os estados, são listados na ordem alfanumérico na lista de Estado .

• Usando o elemento de TRANSITION , você define uma transição para cada progressão válido e a regressão de um estado para outro.

• Pelo menos, você deve definir uma transição para cada estado, e a transição de estado nulo ao estado inicial.

• Para cada transição, você deve definir uma razão padrão usando o elemento de DEFAULTREASON .Você pode definir tantas motivos opcionais como você deseja usando o elemento de REASON .

• Os menus suspensos para os campos de estado e razão de dentro do item de trabalho forms ou consulte a exibição do editor os valores atribuiu na seção de WORKFLOW de tipo de item de trabalho.

• Você pode definir apenas uma transição de não atribuída (zero) ao estado inicial.Quando você salvar um item de trabalho, é alocado automaticamente ao estado inicial.

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

• Você pode definir regras condicionais a qualquer campo que seja aplicado quando o estado das alterações de item de trabalho, quando faz a transição, ou quando um usuário seleciona um motivo específico.Muitas dessas regras suplementam as regras condicionais que você pode aplicar quando você define os campos na seção de FIELDS na definição de WORKITEMTYPE .Para obter mais informações, consulte Atualizando campos quando alterações de estado posteriormente neste tópico.

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

• Nomes que você atribuir aos estados e as razões não diferenciam maiúsculas de minúsculas.

De volta ao topo

Diagrama de fluxo de trabalho e exemplo de código

A tabela a seguir mostra a seção de WORKFLOW de definição para um tipo de item de trabalho que controla defeitos de código, e o diagrama de estado de fluxo de trabalho que define.Este exemplo define três estados, seis transições, e nove motivos.Os elementos de STATE especificam os estados ativos, resolvidos, e fechados.Todas as combinações possíveis para as transições de andamento e regressão de são definidas para os três estados, exceto um.A transição de fechado em 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 é fechado.

Observação
O exemplo não lista os elementos para DEFAULTREASON, REASON, ACTION, e FIELD.

<WORKFLOW> <STATES>   <STATE value="Active">     <FIELDS> . . . </FIELDS>   </STATE>   <STATE value="Resolved">     <FIELDS> . . . </FIELDS>   </STATE>   <STATE value="Closed" /> </STATES> <TRANSITIONS>   <TRANSITION from="" to="Active">     <REASONS>       <DEFAULTREASON value="New" />     </REASONS>     <FIELDS> . . . </FIELDS>   </TRANSITION>   <TRANSITION from="Active" to="Resolved">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS>     < ACTIONS > . . . </ ACTIONS > </TRANSITION> <TRANSITION from="Resolved" to="Closed">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS>     < ACTIONS > . . . </ ACTIONS > </TRANSITION> <TRANSITION from="Resolved" to="Active">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS> </TRANSITION> <TRANSITION from="Active" to="Closed ">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS> </TRANSITION> <TRANSITION from="Closed" to="Active">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS> </TRANSITION> </TRANSITIONS> </WORKFLOW>

Diagrama de estado de fluxo de trabalho de exemplo

Determinando o número e tipos de estados

Você determina o número e tipos de estados válidos com base no número de estados lógicos distintos em que você deseja os itens de trabalho do tipo para existir.Além disso, se os membros da equipe diferentes executam ações diferentes, então você pode considerar definir um estado baseado 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 mover o estado a seguir.Para cada estado, você deve definir as ações específicas e os membros da equipe que são permitidos 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 deve executar as ações indicadas:

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 a você especificar.

De volta ao topo

Definindo as transições

Você controla aos estados e que os membros da equipe podem modificar um item de trabalho se você definir as progressões e as regressões válidos de estado.Se você não definir uma transição de um estado para outro estado, os membros da equipe não podem modificar 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álidos para cada um dos quatro estados que foram anteriormente descrito neste tópico, juntamente com a razão padrão para cada um.

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

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

De volta ao topo

Especificando as razões

Quando um membro da equipe altera o campo de estado, o usuário pode manter a razão padrão para essa transição ou especificar uma razão diferente se você definir opções adicionais.Você deve usar o elemento de DEFAULTREASON para especificar uma e somente uma motivos padrão.Você deve especificar motivos adicionais somente se ajudam a equipe a acompanhar ou relatar dados.

Por exemplo, um desenvolvedor pode especificar uma das seguintes razões determinam quando um erro: Fixo (padrão), adiado, duplicadas, como criada, não pode reproduzir, ou obsoleto.Cada razão especifica uma ação específica para que ele seja executado em relação ao erro.

Observação
Todas as razões 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 elementos de REASON .

O exemplo a seguir mostra os elementos que definem as razões por que 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>

De volta ao topo

Especificando ações

Geralmente, os membros da equipe alteram o estado de um item de trabalho especificando um valor diferente para o campo de Estado e em seguida salvando o item de trabalho.No entanto, você também pode definir um elemento de ACTION 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 são associados com os arquivos que um desenvolvedor verifica em controle de versão:

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

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

De volta ao topo

Atualizando um campo

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

• Atribuir uma regra de campo em STATE quando você desejar que a regra para aplicar para todas as transições motivos para entrar em um estado.

• Atribuir uma regra de campo em TRANSITION quando você desejar que a regra para aplicar para essa transição e todas as razões para fazer a transição.

• Atribuir uma regra de campo em DEFAULTREASON ou REASON quando você deseja as regras para aplicar somente para essa razão específica.

Se um campo sempre contém o mesmo valor, você define a regra no elemento de FIELD que define o campo.Para obter mais informações, consulte Definir condições em um campo de item de trabalho.

Os exemplos a seguir mostram algumas das regras aplicadas aos campos do sistema no modelo de processo para a programação de software agile v5.0 de MSF.

• Alterando o valor de um campo quando as alterações de estado

• Limpar o valor de um campo quando o valor de outro campo alterar

• Definindo um campo com base no conteúdo de outro campo

De volta ao topo

Alterando o valor de um campo quando as alterações de estado

Quando o valor do campo de Estado para um item de trabalho é definido como ativo e o item de trabalho é salvo, os valores dos campos de Ativado por e de Atribuído a são definidas automaticamente ao nome do usuário atual.Esse usuário deve ser um membro do grupo de usuários válidos de Team Foundation Server .O valor do campo Data ativada é definido também automaticamente.O exemplo a seguir mostra os elementos que garante 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>

De volta ao topo

Limpar o valor de um campo quando o valor de outro campo alterar

Quando o valor do campo de Estado para um item de trabalho é definido como ativo e o item de trabalho é salvo, a data fechado e fechado por campos é automaticamente definida como nula e feita somente leitura se você usar o elemento de EMPTY , 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>

De volta ao topo

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

Quando o valor do campo de Estado para um item de trabalho se altera ao resolvido e o item de trabalho é salvo, o valor do campo de Razão resolvida é definida para o valor que o usuário especificou no campo de Motivo .O exemplo a seguir mostra os elementos que garante essa regra:

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

De volta ao topo

Exibindo o diagrama de estado de fluxo de trabalho

Você pode exibir o diagrama de estado que você está definindo usando o editor do processo, uma ferramenta avançada de fluxo de trabalho para Visual Studio.Essa ferramenta não é suportada.Para obter mais informações, consulte a seguinte página no site da Microsoft: Ferramentas poderosas do Team Foundation Server.

De volta ao topo

Consulte também

Outros recursos

Definir e personalizar o fluxo de trabalho do item de trabalho