Em meus trabalhos de implementação do TFS e VSTS em empresas, sempre precisamos discutir sobre como organizar a ferramenta para refletir a organização da empresa. Neste momento, conversamos sobre os conceitos de Team Project Collection, Team Project, Area Path e Iteration Path. Hoje vamos dar uma luz sobre todos estes nomes e acabar de vez com essa bagunça toda!

Team Project Collection

Imagine o TPC como uma instância do TFS. Uma nova base de dados, novos IDs para os WorkItems e nenhuma relação possível facilmente entre TPCs diferentes. Nós não interagimos diretamente com a TPC, mas sim com os Team Projects que fazem parte dele. No VSTS não temos, ao menos por enquanto, este conceito de TPC, mas podemos fazer uma relação com a sua Visual Studio Team Services Account, onde cada uma delas seria uma Team Project Collection.

Team Project

O conceito de TPC, discutido anteriormente, não de difícil entendimento e acabamos não perdendo muito tempo ali: Temos apenas uma Collection e todos ficam satisfeitos com esta decisão, que trará maior facilidade de administração e confundirá menos os usuários. Agora, quando falamos de um Team Project, a forma de implantação virá de acordo com a visão que você quer ter de sua empresa.

Aqui precisamos levar em conta uma grande diferença entre o TFS e o VSTS: Os Relatórios do Reporting Services. Cada Template de Projeto (Team Project Template – Agile, CMMI, Scrum), tem uma série de relatórios padrão que tratam sobre WorkItems, andamento de Sprints, testes e trazem outras métricas que são importantes tanto para as equipes, quanto para os níveis gerenciais. O mais importante é que, por padrão, os relatórios tratam de um único Team Project. Além disto, a troca de WorkItems entre diferentes Team Projects, não é algo trivial até a versão 2017 (podendo ser feito via ferramentas externas), apesar de poder ser feito no VSTS facilmente. Dado estes fatos, muitos advogam pelo conceito do One Team Project como modelo de organização do TFS, onde temos apenas um Team Project que agrupa todos os Workitems, de todas as equipes. Eu, particularmente, gosto de pensar que o TP é algo que gera valor para a empresa. Vamos à alguns exemplos:

• Se sou uma empresa de produtos ou uma consultoria, cada cliente ou produto podem ser um Team Project, isto devido ao isolamento que cada uma destas equipes tem: se imaginarmos que somos a Valve e o desenvolvimento do Half Life 3 não estiver indo bem (?), isto não impacta em nada no desenvolvimento e os resultados do produto Steam.
• Se sou um departamento dentro de uma empresa, e tenho que fazer um reporting de dados de todo o departamento de TI para a área financeira, PMOs, ou qualquer outra, talvez iremos precisar de relatórios que englobem todos os projetos e iniciativas dentro daquela unidade. Então, ao menos com os recursos que temos hoje na ferramenta, precisará colocar todos os seus projetos dentro de um mesmo Team Project e, para manter tudo organizado, você irá utilizar os campos Area Path e Iteration Path

Area Path

É um campo hierárquico que servirá para classificar seus workitems. Gosto de dizer, que são os sistemas e módulos dos sistemas que você cuida, é o “onde”. Se sua área de TI faz parte de um banco, o campo Area Path poderá ser configurado como:

• TI
  • Canais de Atendimento
    • Internet Banking
    • Caixa
    • ATM

Iteration Path

Também um campo hierárquico, tem como característica principal ter uma relação com datas de início e fim. Assim, você poderia colocar suas gerências e seus “times” e deixar que cada equipe decida como irá dividir suas sprints. Você poderia ter algo como:

• TI
  • Clientes
    • Canais de Relacionamento
      • Sprint 1
      • Sprint 2
    • CRM
      • Sprint 1

Team

Agora, tendo configurado os campos Area e Iteração, você precisa criar um novo Team. O Team é a cola entre os campos Area Path e Iteration Path. Ou seja, uma equipe chamada “ABC” pode cuidar de módulos de “Internet Banking” e “ATM” e estar vinculada ao “Departamento de relacionamento com o cliente”. É importante notar que um Team tem um Product Backlog, Sprint Backlog, um Dashboard e outras funcionalidades que interessam àquele grupo de pessoas que estão envolvidos com aqueles sistemas/módulos em um determinado período de tempo. Note que um time, não necessariamente, é um Projeto, isto porque o mesmo grupo de pessoas pode atuar em diferentes projetos e, se a visualização e planejamento daquele grupo de pessoas for independente do planejamento do projeto, ou se aquele grupo de pessoas está participando de mais de um projeto ou fazem atividades de sustentação e de evolução dos sistemas que eles cuidam, é importante que eles façam parte de somente um Team, para poderem ter uma visão unificada de sua capacidade de trabalho e planejamento para cada sprint.

Tags

Não há muitos mistérios, mas tags podem trazer um nível de classificação maior para os seus workitems. Um exemplo de utilização pode ser a versão do sistema em que se planeja que determinado workitem seja entregue ou o projeto que aquele workitem faz parte.

No final das contas…

Não entrei em detalhes sobre como fazer tais configurações pois gostaria de passar os conceitos que gosto de usar para este assunto no TFS/VSTS. Caso haja interesse, posso fazer um post detalhando como efetuar as configurações necessárias no TFS/VSTS para alcançar os melhores resultados para cada tipo de empresa. De qualquer forma, espero que este post ajude a tirar melhor proveito das possibilidades da ferramenta. Se tiverem outras ideias, sintam-se livre para continuar o papo nos comentários. E fiquem de olho nas novas funcionalidades que chegam a todo instante no VSTS/TFS e podem modificar estas estratégias de organização.

Gerson Dias