Compartilhar via

Projetando o fluxo de trabalho.

  • Artigo

Projetar o fluxo de trabalho para um tipo de item de trabalho oferecer suporte a seus processos de negócios e equipe. O fluxo de trabalho determina a progressão lógica das tarefas que serão executadas e por quem. Você pode definir o fluxo de trabalho identificando primeiro os estados e as transições válidas entre eles. O WORKFLOW seção da definição do tipo de item de trabalho define o válido dos Estados, 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. Para obter mais informações sobre definições de tipo, consulte Todas as referências de elementos XML de WITD.

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

Por exemplo, o estado é definido como Active quando um testador abre um novo bug que é baseado no modelo de processo para o Microsoft Solutions Framework (MSF) para 5.0 de desenvolvimento de Software ágil. Após corrigir o bug, o desenvolvedor altera o estado resolvido e define o valor do campo razão como fixo. Depois de verificar a correção, o testador altera o estado do bug para fechado e deixa o valor do campo razão como fixo. Se o testador determinado que o desenvolvedor não tinha corrigido o bug, o testador mudaria o estado do bug para Active e especifique o motivo, como resolução negado ou falha no teste.

ObservaçãoObservação

Você pode criar e modificar as definições de tipos de item de trabalho e outros objetos controlar os itens de trabalho usando o Editor de processo, uma ferramenta de alimentação para Visual Studio. Essa ferramenta não é suportada. Para obter mais informações, consulte a seguinte página no site da Microsoft: Team Foundation Server Power Tools em abril de 2010.

Neste tópico

  • Diretrizes de Design de fluxo de trabalho

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

  • Determinando o número e tipos de estados

  • Definindo as transições

    • Especificando os motivos

    • Especificar ações

  • Atualizando um campo quando o estado alterado

    • Definir um campo quando o estado alterado

    • O valor de um campo de compensação

    • Definir 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 criar ou modificar um fluxo de trabalho, considere as seguintes diretrizes:

  • Usando o STATE elemento, você definir um estado exclusivo para cada função de membro da 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, estão listados em ordem alfanumérica na estado lista.

  • Usando o TRANSITION elemento, você define uma transição para cada progressão válido e uma 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.

  • Para cada transição, você deve definir um motivo padrão usando o DEFAULTREASON elemento. Você pode definir tantas razões opcionais, conforme desejado, usando o REASON elemento.

  • Você pode definir a transição de apenas um de não atribuído (nulo) para o estado inicial. Quando você salva 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 a alteração dispara a transição e as ações que definem a ser realizada para o estado selecionado e a transição. Os usuários podem especificar somente os estados são válidos com base em que as 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.

  • Você pode definir regras condicional para qualquer campo que será aplicado quando o item de trabalho muda de estado, quando ele passa ou quando um usuário seleciona um motivo específico. Muitas dessas regras complementam as regras condicionais que você pode aplicar ao definir os campos de FIELDS seção sob o WORKITEMTYPE definição. Para obter mais informações, consulte Atualização campos quando uma alteração de estado posteriormente neste tópico.

  • Você deve tentar minimizar o número de condições que você define para qualquer um tipo de item de trabalho. Com cada regra condicional que você adicionar, você pode aumentar a complexidade do processo de validação que ocorre a cada 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 nomes que você atribui a estados e motivos diferenciam maiúsculas de minúsculas.

Voltar ao topo

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

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

O exemplo não lista os elementos de 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

Diagrama de estados de caso de usuário

Determinando o número e tipos de estados

Determine 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 a diferentes membros da equipe executam ações diferentes, em seguida, você pode 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 são definidos para controlar o andamento 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

Proposta

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 um 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 fechá-lo.

Active

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 do 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 para fechado se a implementação for satisfatória.

Fechado

Gerente de projeto

Não espera-se que nenhuma ação adicional ocorre em itens de trabalho que estão fechados. Esses itens permanecem no banco de dados para fins de arquivamento e emissão de relatórios.
ObservaçãoObservação

Todos os estados são exibidos em ordem alfabética na lista no formulário para um item de trabalho de um tipo específico, independentemente da seqüência em que você especificar.

Voltar ao topo

Definindo as transições

Você controla os estados e para qual equipe os membros podem alterar um item de trabalho se você definir a progressions de estado válido e regressões. 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 particular.

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

Estado

A transição de estado

Motivo do padrão

Proposta

Ativo (progressão)

Aprovados para desenvolvimento

Fechada (progressão)

Não aprovado

Active

Revisão (progressão)

Critérios de aceitação atendidos

Revisão

Fechada (progressão)

Recurso concluído

Ativo (regressão)

Não atende aos requisitos

Fechado

Proposta (regressão)

Reconsidere para aprovação

Ativo (regressão)

Fechado em 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 a TRANSITION elemento. Como mostra o exemplo a seguir, testadores podem reabrir um bug, mas os desenvolvedores não podem.

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

Voltar ao topo

Especificando os motivos

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

Por exemplo, um desenvolvedor pode especificar-um dos seguintes motivos quando eles resolvem um bug: Fixo (padrão), adiada, duplicar, conforme projetado, não pode reproduzir ou obsoletos. Cada razão Especifica uma ação específica para o testador executar com relação a bug.

ObservaçãoObservaçã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 seqüência em que você especificar o REASON elementos.

O exemplo a seguir mostra os elementos que definem os motivos por que um membro da equipe poderá 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>

Voltar ao topo

Especificar ações

Em geral, os membros da equipe alterar o estado de um item de trabalho especificando um valor diferente para o estado campo e então salvar o item de trabalho. No entanto, você também pode definir um ACTION elemento altera automaticamente o estado de um item de trabalho ocorre a transição. Como mostra o exemplo a seguir, você pode especificar que os itens de trabalho bug devem ser resolvidos automaticamente se eles estão 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 ocorrerem eventos em outro lugar no Microsoft Visual Studio Application Lifecycle Management ou fora de Visual Studio Application Lifecycle Management (por exemplo, a partir de uma ferramenta que rastreia chamadas). Para obter mais informações, consulte Automatizando as atribuições de campo com base no estado, transição ou motivo.

Voltar ao topo

Atualizando um campo.

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

  • Atribuir uma regra de campo em STATE quando desejar que a regra seja aplicada para todas as transições para e razões para a inserção de estado.

  • Atribuir uma regra de campo em TRANSITION Quando você deseja que a regra se aplique essa transição e todas as razões para fazer a transição.

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

Se um campo sempre deve conter o mesmo valor, você definir a regra sob o FIELD elemento que define o campo. Para obter mais informações, consulte Definindo as condições em um campo de Item de trabalho.

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

  • Alterar o valor de um campo, quando o estado alterado

  • Limpando o valor de um campo quando o valor de outro campo alterado

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

Voltar ao topo

Alterar o valor de um campo, quando o estado alterado

Quando o valor da estado campo para um item de trabalho estiver 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 membro da Team Foundation Server grupo de usuários válidos. O valor do Data ativado campo também será 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>

Voltar ao topo

Limpando o valor de um campo quando o valor de outro campo alterado

Quando o valor da estado campo para um item de trabalho é definido como ativa e o item de trabalho é salvo, os campos Data fechada e Closed By são definidos automaticamente nulo e feitas somente leitura se você usar o EMPTY elemento, como o exemplo a seguir mostra.

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

Voltar ao topo

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

Quando o valor da estado para um item de trabalho é alterado para resolvido e o item de trabalho é salvo, o valor de campo a Resolvido motivo 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>

Voltar ao topo

Exibindo o diagrama de estado de fluxo de trabalho

Você pode exibir a definição de fluxo de trabalho de qualquer tipo de item de trabalho, se você usar Team Web Access para abrir o diagrama de estado para qualquer item de trabalho do tipo. Para obter mais informações, consulte Gerenciando o trabalho em equipe Web Access.

Dica

Você também pode exibir o diagrama de estado do fluxo de trabalho que você está definindo usando o Editor de processo, uma ferramenta de alimentação para Visual Studio. Essa ferramenta não é suportada. Para obter mais informações, consulte a seguinte página no site da Microsoft: Team Foundation Server Power Tools em abril de 2010.

Voltar ao topo

Consulte também

Outros recursos

Definir e personalizar o fluxo de trabalho do trabalho Item

Histórico de alterações

Date

History

Motivo

Janeiro de 2011

Movida a tabela de WORKFLOW elementos para um novo tópico, Todas as referências de elementos XML do fluxo de trabalho.

Aprimoramento de informações.

Julho de 2010

Completamente reescrita para fornecer mais informações, exemplos e um resumo de todos os WORKFLOW elementos e atributos.

Aprimoramento de informações.