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

Alterar o fluxo de trabalho para um tipo de item de trabalho (WIT) para dar suporte a processos de negócios e equipe. WITs controle todos os tipos de work─requirements, tarefas, código defects─to suporte usando o software development Team Foundation Server (TFS).

O fluxo de trabalho determina a progressão lógica e regressão de trabalho que executará os membros da equipe. Ela também especifica os valores que aparecem nos menus suspensos para os campos de estado e o motivo.

Fluxo de trabalho para o Item de lista de pendências de produto (modelo de processo Scrum

Para obter uma visão geral dos Estados do fluxo de trabalho padrão com suporte em modelos de processo padrão TFS fornece, consulte Trabalhar com artefatos de projeto de equipe, escolher um modelo de processo. Para obter informações sobre o fluxo de trabalho de definição de compilação, consulte Personalizar seu modelo de processo de compilação.

Diretrizes de design de fluxo de trabalho

Você pode definir o fluxo de trabalho ao identificar primeiro os estados e as transições válidas entre eles. O 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 altera o estado de um item de trabalho.

Em geral, você associa cada estado de uma função de membro da equipe e uma tarefa que uma pessoa em que a função deve executar para processar o item de trabalho antes de alterar seu estado. Transições definem os progressions válidos e perdas entre estados. Motivos identificam por que um membro da equipe altera um item de trabalho de um estado para outro e ações oferecer suporte à automação da transição de um item de trabalho em um ponto no fluxo de trabalho.

Por exemplo, o estado é definido como novo quando um testador abre um novo bug que é baseado no modelo de processo do Agile padrão que Team Foundation Server (TFS) fornece. O desenvolvedor altera o estado do ativos ao corrigir o bug e depois de corrigidos, o desenvolvedor altera o estado resolvido e define o valor do campo motivo para fixo. Depois de verificar a correção, o testador altera o estado do bug para fechado e o campo de motivo alterado para Verified. Se o testador determinado que o desenvolvedor não tive corrigido o bug, o testador alterava o estado do bug para ativos e especifique o motivo como não corrigido ou falha no teste.

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

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

  Se você adicionar um estado a um tipo de item de trabalho que aparece nas páginas de lista de pendências ou placa em Team Web Access, você também deve mapear o estado para um metaestado. Consulte Referência de elemento XML da configuração de processo.

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

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

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

  Quando um membro da equipe altera o estado de um item de trabalho que alteração dispara a transição e as ações que definem a ser executada 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 definidas 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 tantas razões opcionais conforme desejado, usando o REASON elemento. Esses valores são exibidos no menu suspenso do motivo campo.

• Você pode especificar regras que serão aplicadas quando o item de trabalho muda de estado, quando ele passa, ou quando um usuário seleciona um motivo específico. Muitas destas regras complementam as regras condicionais que você pode aplicar ao definir os campos a FIELDS seção sob o 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 que você atribui a estados e motivos diferenciam maiúsculas de minúsculas.

  Os menus suspensos para os campos de estado e o motivo dentro do editor de formulário ou consulta de item do trabalho exibem os valores atribuídos no WORKFLOW seção do tipo de item de trabalho.

Exemplo de diagrama e o código do fluxo de trabalho

O seguinte exemplo de código mostra o WORKFLOW para a definição de WIT Bug para o modelo de processo do Agile. Este exemplo define três estados e transições de cinco. O STATE especificam os estados Active, Resolved e fechadas. Todas as combinações possíveis de regressão e progressão transições são definidas para os três estados, exceto um. A transição de Closed 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 é fechado.

Este exemplo não lista todos 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"> <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>

Diagrama de estado do fluxo de trabalho de exemplo – WIT Bug do Agile

Determinar o número e tipos de estados

Determinar o número e tipos de estados válidos com base no número de estados lógicos distintos no qual você deseja que os itens de trabalho desse tipo existir. Além disso, se diferentes membros da equipe executam ações diferentes, você pode considerar definir um estado com base em uma função de membro. Cada estado corresponde a uma ação que um membro da equipe deve realizar 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 são definidos para acompanhar 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 do recurso. No entanto, somente os gerentes de projeto podem aprovar ou desaprovar o item de trabalho. Se o gerente de projeto aprovar um recurso, o gerente de projeto altera o status do item de trabalho para ativo; Caso contrário, um membro da equipe fecha.
Ativo	Líder de desenvolvimento	O líder de desenvolvimento supervisiona o desenvolvimento do recurso. Quando o recurso for concluído, o líder de desenvolvimento altera o status do item de trabalho de recurso para revisão.
Revisão	Gerente de projeto	O gerente de projeto examina o recurso que a equipe implementado e altera o status do item de trabalho fechado se a implementação é satisfatória.
Fechado	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 geração de relatórios.

Dica

Todos os estados aparecem em ordem alfabética na lista na forma de um item de trabalho de um tipo específico, independentemente da seqüência em que você especificar.

Definir transições

Você controla os estados de e para qual equipe os membros podem alterar um item de trabalho se você definir os progressions estado válido e perdas. Se você não definir uma transição de um estado para outro estado, os membros da equipe não podem alterar um item de trabalho de um tipo específico 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 que foram descritos neste tópico, junto com o motivo padrão para cada um.

Estado	Passa para o estado	Motivo padrão
Proposto	Ativo (progresso)	Aprovado para desenvolvimento
	Fechado (progresso)	Não aprovado
Ativo	Revisão (progresso)	Critérios de aceitação atendidos
Revisão	Fechado (progresso)	Recurso concluído
	Ativo (regressão)	Não atende aos requisitos
Fechado	Proposta (regressão)	Reconsidere para aprovação
	Ativo (regressão)	Fechado com erro

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

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

Especificar os motivos

Quando um membro da equipe altera o campo State, que o usuário pode reter o motivo para essa transição padrão ou especificar uma razão diferente se você definir opções adicionais. Você deve usar o DEFAULTREASON elemento para especificar apenas um motivo padrão. Você deve especificar razões adicionais somente se elas ajudam a equipe controlar ou dados de relatório.

Por exemplo, um desenvolvedor pode especificar um dos seguintes motivos quando eles resolvem um bug: fixa (padrão), adiada, duplicado, como projetado, não é possível reproduzir ou obsoleto. Cada motivo Especifica uma ação específica para o testador executar com relação o erros.

Dica

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 a REASON elementos.

O exemplo a seguir mostra os elementos que definem os motivos 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>

Especifique ações

Em geral, os membros da equipe alteram o estado de um item de trabalho, especificando um valor diferente para o estado campo e, em seguida, salvar o item de trabalho. No entanto, você também pode definir um ACTION elemento que altera o estado de um item de trabalho automaticamente 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 ocorrem eventos em outro lugar no Microsoft Visual Studio Application Lifecycle Management ou fora de Visual Studio Application Lifecycle Management (por exemplo, de uma ferramenta que rastreia chamadas). Para obter mais informações, consulte Automatizar atribuições de campo com base em estado, transição ou motivo.

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

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

• Atribuir uma regra de campo em STATE quando deseja que a regra seja aplicada para todas as transições e motivos para esse estado.

• Atribuir uma regra de campo em TRANSITION quando deseja que a regra seja aplicada para essa transição e todos os motivos para fazer essa transição.

• Atribuir uma regra de campo em DEFAULTREASON ou REASON quando desejar que as regras para aplicar apenas por esse motivo específico.

Se um campo sempre deve conter o mesmo valor, você define a regra sob o FIELD elemento que define esse campo. Para saber mais sobre o uso de regra, consulte Aplicar uma regra a um campo do item de trabalho.

Você deve tentar minimizar o número de condições que você definir para qualquer tipo de item de trabalho. Com cada regra condicional que você adicionar, é possível aumentar a complexidade do processo de validação que ocorre toda vez que um membro da equipe salva um item de trabalho. Conjuntos de regras complexas podem aumentar o tempo necessário para salvar o item de trabalho.

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

Altere o valor de um campo quando o estado é alterado

Quando o valor da estado para um item de trabalho é definido como ativo e o item de trabalho é salvo, os valores da ativado por e atribuído a campos são definidos automaticamente para o nome do usuário atual. Esse usuário deve ser um membro do Team Foundation Server grupo de usuários válidos. O valor da Data ativado campo 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 alterado

Quando o valor da estado para um item de trabalho é definido como ativo e o item de trabalho é salvo, os campos Data de fechamento e Closed By são definidos automaticamente como null e fez 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 da estado campo para um item de trabalho é alterado para resolvido e o item de trabalho é salvo, o valor da motivo resolvido campo é definido como o valor que o usuário especificado no motivo campo. 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>

Perguntas e respostas

P: existe uma ferramenta para alterar o fluxo de trabalho ou para exibir diagramas de estado de fluxo de trabalho?

R: Sim. Você pode alterar o fluxo de trabalho ou exibir um diagrama de estado do fluxo de trabalho que você está definindo usando o Process Editor, uma poderosa ferramenta para Visual Studio. Para obter mais informações, consulte a seguinte página no site da Microsoft: Team Foundation Server Power Tools.

P: onde posso obter uma visão geral dos elementos XML de definição de WIT?

R: Consulte Todas as referências de elementos XML WITD.