TFS – Customizando o Workflow de um Work Item

No TFS existe a opção de escolher qual o process template da metodologia que o projeto será gerenciado, atualmente existem os process templates para Scrum, MSF for CMMI e MSF for Agile. Os process templates fornecem ao projeto suporte as terminologias e definem vários elementos que determinada metodologia aborda.

É muito comum após um process template configurado surgir a necessidade de alguma modificação / adaptação, pois o processo da equipe pode ter alguma particularidade.

Nesse artigo usaremos o process template de Scrum para o exemplo. No Scrum existe o Conceito de Pronto que significa que um time Scrum define quais critérios são necessários para dar como pronta uma atividade. Com certeza para uma atividade ser considerada pronta é necessário que ela esteja testada. O workflow de uma atividade no process template Scrum vai de In Progress para Done, não existe o estado Testing.

Nesse artigo abordaremos como alterar o workflow de uma tarefa e incluir o estado Testing.

Esse artigo aborda o uso de:

Utilizando o TFS Power Tools para editar um Work Item

Após instalar o TFS Power Tools surgirá uma opção do menu Tools do Visual Studio chamado Process Editor

O Process Editor permite que seja editado um Work Item seja ele global ou de algum projeto específico.

No exemplo será editado o Work Item de Task onde será adicionado um novo campo de valor e também modificaremos o seu workflow para prever o novo estado de Testing.

O caminho a seguir é Work Item Types > Open WIT from Server

Surgirá uma janela de diálogo com os projetos disponíveis no TFS, será necessário expandir o projeto em questão e selecionar o tipo de Work Item a ser editado, selecione Task.

Modificando o Workflow de um Work Item no TFS

Na mesma tela Work Item Type clique na aba chamada Workflow

Abaixo está a ilustração do Workflow original para o Work Item de Task no Process Template Scrum 2.2:

A alteração que será executada será adicionar o novo estado Testing e alterar o fluxo de dos estados existentes, para isso serão necessária as ferramentas de design que estão disponíveis em Toolbox

Criando um Estado no Workflow

Arrastando um item da caixa State para o Workflow

Este é a caixa do novo estado, já foi renomeado para Testing e agora é necessário criar as transições, que são responsáveis por guiar o fluxo.

Para criar uma transição basta selecionar o item Transition Link na Toolbox clicar na caixa que a transição inicia e arrastar e soltar na caixa onde termina.

A transição de estado está feita, isso significa que quanto a tarefa estiver em estado Testing, será possível mudar para Done, agora é necessário realizar algumas configurações.

Com um duplo clique na caixa Transition abrirá uma janela de diálogo Workflow Transition.

Na aba Reasons cadastraremos um novo valor para quando o estado de Testing passar para Done.

Clicando em New para preencher o valor do Reason, que é a razão pelo qual a tarefa mudou de estado.

Note que no fluxo principal, a caixa Done requer a adição de um parâmetro o Closed Date, isso significa que é necessário passar essa informação para que haja transição de Testing para Done, a passagem desse valor é feita durante a transição através do item recurso Fields.

Pressione OK e retorne a janela de diálogo Workflow Transition, selecione a aba Fields e clique em New, o combo abaixo irá exibir diversas opções selecione ClosedDate.

Além de selecionar a referência do campo a ser passado é necessário configurar a regra de passagem, clique na aba Rules e selecione New, uma janela com uma lista exibirá todas as regras existentes, nesse caso a regra SERVERDEFAULT deve ser escolhida, pois trabalharemos com uma informação do servidor.

Como estamos trabalhando com um valor do tipo DateTime selecione no combo From a opção Clock, significa que iremos utilizar a data que está no servidor como referência.

Etapa concluída, o novo estado Testing está configurado e a transição para Done foi finalizada.

Note que exitem outras transições a serem feitas como por ex:

  • In Progress > Testing (Atividade finalizada e encaminhada para testes)
  • Testing > In Progress (Bugs encontrados, necessário trabalho adicional)

Basta seguir o mesmo processo para as demais transições.
Salve as alterações pelo Visual Studio e automaticamente o novo estado Testing estará publicado.

No próximo artigo gravarei um vídeo executando este processo e fornecendo mais detalhes de como modelar o Workflow de um Work Item.

Utilizem os comentários para dúvidas ou feedbacks.
Até a próxima 😉

6 ideias sobre “TFS – Customizando o Workflow de um Work Item

  1. Boa Tarde!

    Qual é a opção correta de registrar bugs de uma determinada task, dentro da própria task ou temos criar uma nova tesk de bug?

    obrigada!

    • Olá Liliane.

      Tudo depende do seu processo, se você não tiver um eu sugiro que crie um novo estado para suas tasks (Testing) e mova após o desenvolvimento para este estado, caso haja bugs (pegos em teste antes de produção) você pode utilizar a mesma task para reportar e controlar os feedbacks e mover o estado para (Commited “Desenvolvimento”) novamente.

      Caso o bug seja de uma feature em produção, sugiro que o reporte utilizando um work item de Bug.

      Ajudei?
      Obrigado por comentar, abraços.

  2. Bom dia Eduardo.
    Estou querendo mudar o nome do work item type Bug para Defect por exemplo.
    Isso seria possível? Renomear o Bug?
    Pois utilizo o conceito de Defeito, Melhoria e Consulta.
    E todos meus Defeitos foram cadastrados como Bug, mas hoje sinto a necessidade de criar bugs para tasks que não passaram no teste. Logo vai ficar confuso pois vou estar usando Bug para Defeito e Bug para bug no sistema.
    Obrigado!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *