Uma requisição muito freqüente que ocorre durante a customização de um processo dentro do TFS é “gostaria de definir quem pode fazer o que”, ou de uma forma mais específica “gostaria que apenas usuários de um determinado grupo pudessem criar ou mudar status de uma atividade”. Isso normalmente é realizado com a customização de Work Items, customização Workflows e criação de subgrupos dentro do Team Project.

Para demostrar como realizar essa atividade, vamos imaginar o seguinte cenário: Temos um Team Project que foi criado utilizando o template MSF for Agile Software Development 4.2. Esse projeto é composto por Desenvolvedores e Testers e temos que implantar o requisito de que apenas testers podem abrir bugs, apenas desenvolvedores podem corrigi-los e apenas os testers podem fechá-los. Ok! É um requisito um pouco estranho, mas ilustra bem o que precisamos neste momento. Vamos lá então:

1. Definir os grupos e organizar as pessoas dentro do Projeto

Utilizando o Power Tools do VSTS 2008 esse processo fica bastante simples. Basta você acessar o Team Explorer, clicar com o botão direito em Team Members, depois em New Subteam e digitar o nome do grupo que você deseja criar. Uma vez que o grupo esteja criado, basta você adicionar os usuários que desejar dentro do grupo clicando com o botão direito no grupo e em seguida em Add Team Member.

Para seguirmos o cenário proposto vamos criar dois grupos chamados Developers e Testers e adicionarmos alguns usuários dentro deles. A estrutura deve ficar parecida com a imagem 1:

Team Explorer com Power Tools 
Imagem 1 – Team Explorer

2. Customizando o Work Item

Agora que temos o time organizado dentro dos grupos, o próximo passo é editar o WIT (Work Item Type) Bug e definirmos as permissões para cada grupo. Para isso acesse o menu Tools -> Process Editor -> Work Item Types -> Open WIT from server. Você verá a janela Select Work Item Type (imagem 2)  e então selecione o WIT que vamos editar, no caso o Bug, e clique em Ok.

Select WIT 
Imagem 2 – Janela Select Work Item Type

Após clicarmos em Ok, será aberto dentro do Visual Studio o WIT Bug com todas as suas definições, campos, layouts e o workflow, que é exatamente o que nos interessa neste momento.

A imagem será parecida com a imagem 3 e nela podemos ver que temos 3 estados, sendo eles: Active, Resolved e Closed. Como os próprios nomes sugerem, o Active é o estado inicial (apenas Testers), o Resolved é o estado indicando que o Bug foi resolvido (apenas Developers) e o Closed indica que o houve uma verificação da resolução e ela foi aceita passando assim para fechado (apenas Testers)

workflow padrao
Imagem 3 : Workflow do WIT Bug do MSF for Agile

Agora que revisamos as regras e identificamos em quais estados vamos aplicá-las, vamos ver o procedimento para executar isso.

  1. Duplo clique em Active para abrir a janela Workflow State Field Rules
  2. Clique no botão New para abrir a janela Field Reference
  3. No campo RefName digite System.AssignedTo
  4. Mova para a aba Rule e clique em New
  5. Selecione ALLOWEDVALUES na janela Select a rule type
  6. Clique em New na janela ALLOWEDVALUES
  7. Digite [Project]\Testers no campo List Item:

Simples não? 🙂

Customização Processo
Imagem 4: Janelas do Process Template Editor 

Na verdade, toda essa seqüência de telas é apenas para gerar o XML abaixo que será adicionado no WIT. Como eu não gosto muito de sofrer, eu prefiro utilizar o Process Template Editor.

<State value="Active">
  <FIELDS>
    <FIELD refname="System.AssignedTo">
      <ALLOWEDVALUES>
        <LISTITEM value="[Project]\Testers" />
      </ALLOWEDVALUES>
    </FIELD>
  </FIELDS>
</State>

Agora que já definimos a regra para o status Active, é só executar o mesmo procedimento para os outros status apenas tomando cuidado para o grupo que daremos acesso e depois clicar em Save.

Pronto, a customização do WIT termina aí. O próximo passo é testarmos o Work Item para ver como ficou a nossa alteração.

3. Testando a Customização do Work Item

Essa é a etapa mais simples. Vamos criar um Work Item do tipo Bug e se a regra estiver correta, apenas os testers estarão disponíveis no campo Assigned To.

Teste status Active
Imagem 5 : Teste do WIT Bug com status Active

E alterando o State para Resolved, o campo Assigned To deve mostrar apenas os membros do grupo Developers.

Teste status Resolved
Imagem 6 : Teste do WIT Bug com status Resolved

Bom pessoal, é isso! Na época do TFS 2005 quando ainda não tínhamos o Power Tools realmente era difícil customizar o processo. Hoje, com toda a definição de campos, layout e workflow de forma visual, realmente ficou mais fácil, mas ainda assim é um trabalho que requer muito cuidado e muita paciência.

Agora que você já sabe como funciona a customização de processos do TFS (pelo menos parte dela) sente-se com os responsáveis pelo processo de sua empresa, customize o TFS de forma que ele ajuste-se perfeitamente as suas necessidades e use todo o potencial que a ferramenta lhe oferece.

Abraços e até a próxima.
André Dias

André Dias

André Dias é sócio-fundador da Lambda3, Visual Studio ALM Ranger & MVP e Professional Scrum Developer Trainer pela Scrum.Org. É graduado em Ciência da Computação pela Unip, atua na área de desenvolvimento de softwares a mais de 13 anos e nos últimos anos tem se dedicado as práticas de ALM (Application Lifecycle Management) e de Agilidade. Foi consultor de ALM da Microsoft Brasil, morou na Irlanda onde trabalhou em projetos para o governo Irlandês. No Brasil atuou em dezenas de projetos, muitos deles para o governo e para grandes instituições financeiras. Tem participação ativa na comunidade através da realização de palestras, organização de eventos, seu blog e seu twitter em @AndreDiasBR