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:
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.
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)
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.
- Duplo clique em Active para abrir a janela Workflow State Field Rules
- Clique no botão New para abrir a janela Field Reference
- No campo RefName digite System.AssignedTo
- Mova para a aba Rule e clique em New
- Selecione ALLOWEDVALUES na janela Select a rule type
- Clique em New na janela ALLOWEDVALUES
- Digite [Project]\Testers no campo List Item:
Simples não? 🙂
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.
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.
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