Ricardo Serradas

Olá,

Há alguns dias atrás passei por uma série de situações curiosas, com algumas diferentes customizações de um template de processo MSF for CMMi 5.0 do TFS para um time de desenvolvimento, situações essas que são relativamente simples, mas achei que caberiam bem em alguns posts sobre como realizar cada etapa. Minha proposta então é expor o problema e depois, numa série de posts, mostrar como é possível implementar tudo isso. Vamos lá.

- Há a necessidade de customizar o template do work item do tipo Task, com 3 campos que compunham o andamento de cada etapa da atividade. Algo parecido com o seguinte:

Tarefa  1
Análise e documentação (peso: 40%):	[Dropdown com os valores possíveis]
Desenvolvimento (peso: 30%):	[Dropdown com os valores possíveis]
Testes (peso: 30%):	[Dropdown com os valores possíveis]

 Então, os campos “Original estimate”, “Remaining work” e “Completed work” seriam inutilizados a pedido da própria gestão.

- O próximo passo é criar um campo abaixo que mostrasse o andamento geral da atividade, uma porcentagem consolidada, levando em consideração os pesos de cada etapa. Exemplo, se:

Análise e documentação:	100%
Desenvolvimento:	50%
Testes:	0%

 Logo, o andamento geral da atividade é 55%, porque ((100*40)+(50*30)+(0*30))/100 = 55, certo?

Porém, como fazer isso apenas com as regras de campos de work items do TFS? Bingo! Não é possível. Para conseguirmos isso, precisamos criar um controle customizado para nossos work items com essa inteligência embutida.

- Depois disso, sabemos que esses work items serão mapeados para um cronograma no MS Project. A necessidade do gestor é que esse campo com o andamento geral da atividade fosse refletido no campo “% Complete” do cronograma.

- Por fim, é interessante conseguirmos elaborar relatórios a partir desses novos dados. Vamos então criar um novo tipo de Report e publicá-lo na área de relatórios do Team Project.

Vamos resolver esses “puzzles”?

Parte 1: Criar campos customizados para o formulário de work item

Antes de tudo, precisamos ter um um Team Project configurado com MSF for CMMi 5.0 para podermos trabalhar. Recomendo fortemente que crie um Team Project exclusivo para exercícios como esse.

Existem duas formas para customizar um tipo de work item: editando suas definições via XML ou usando o Process Editor integrado no Visual Studio, módulo contido no Team Foundation Power Tools, que pode ser obtido neste link. Mesmo que queira mexer direto no XML, é muito importante baixar e instalar essa ferramenta para que possa ter fácil acesso ao XML definition do work item.

Depois de instalado, vamos primeiro dar uma olhada no XML definition do Work Item do tipo Task. Para isso, dentro do Visual Studio, siga os passos:

Menu Tools -> Process Editor -> Work Item Types -> Export WIT.

Uma janela como essa sera aberta:

Selecione o tipo “Task” do seu Team Project e clique em OK. Agora, você verá uma caixa de diálogo de “Salvar como”, pedindo para escolher o local para salvar o arquivo XML.

Depois de salvo, abra este arquivo com seu editor de textos preferido. Verás um arquivo de cerca de 550 linhas. Vamos falar rapidamente sobre algumas tags importantes desse arquivo:

WORKITEMTYPE – Raiz do tipo do work item. É onde, por exemplo, o nome do tipo do work item é definido.

FIELDS – Aqui são definidos os campos usados no formulário do work item. Aqui algumas propriedades são definidas, como nome do campo, tipo de dado e formato no relatório.

WORKFLOW – Neste trecho é definido o ciclo de vida do tipo de work item. Transições entre estados, campos a serem preenchidos nelas, entre outras coisas são definidos aqui.

FORM – Aqui é definida a aparência do formulário do work item. Posições de campos, tamanho, label, agrupamento, etc.

Mas, há uma frase que acho muito valiosa que Ramon Durães costuma usar, que é “Não tem que ser difícil”. Seguindo essa linha, nós vamos basear nosso trabalho em cima do Process Editor do TF Power Tools.

Vamos então abrir o mesmo arquivo XML numa interface amigável dentro do Visual Studio. Para isso, siga esse caminho: Menu Tools -> Process Editor -> Work Item Types -> Open Work Items From File. Uma janela de abertura de arquivo vai aparecer, selecione o arquivo XML que visualizávamos no editor de texto. Verás então uma janela como essa:

As abas representam os nós daquele XML que falamos acima. Para executarmos a nossa primeira tarefa, precisamos seguir o seguinte roteiro nessa janela:

- Etapa 1: Criar a definição dos campos na aba “Fields” (seus nomes, tipos e descrição).

                Usando o botão “New”, a seguinte janela aparecerá:

Entendendo esse formulário:

Aba “Field Definition”

Name – Simplesmente o nome do campo, não interfere no funcionamento.

Type – Como o nome já diz, o tipo de dado que o campo vai suportar.

Reference Name – É através desse nome que ele será usado tanto no formulário quanto nos relatórios. Tem como padrão ter um nome semelhante ao namespace+nome de uma classe. No nosso exemplo usamos “BlogSamplesCMMi.Tracking.Analisys”.

Help Text – Texto que serve para tooltips, descriptions, etc.

Reportable – Se você pretende usar a informação desse campo em relatórios, é importante escolher um dos valores para esse campo. Os valores podem ser:

                None: Não será inserido no banco de dados relacional (não poderá ser usado em relatórios);

                Dimension: Use este tipo apenas para Integer, Double, String ou DateTime. Os dados nesse campo entram no banco de dados relacional e no cubo como um atributo de dimensão do Work Item para que os dados sejam usados para filtrar relatórios. Use-o para campos que têm uma lista de valores válidos. Work Item Type e State são bons exemplos de uso desta opção.

                Detail: Use esse tipo somente para Integer, Double, String ou DateTime. Os dados nesse campo entram no banco de dados relacional nas tabelas “Work Item History” e “Current Work Item”, mas não no cubo. Esta é uma boa escolha para campos de texto sem restrição, no entanto, você terá que usar a base relacional em vez do cubo. “Summary”, um campo String que contém uma breve descrição de um work item, é um bom exemplo de campo que deve ser do tipo Detail quando usado em relatórios.

                Measure: Use este tipo somente para campos Integer ou Double. São usados para propósitos estatísticos ou para medir certos aspectos do projeto. Cada campo desse tipo aparecer tanto no grupo de medidas “Current Work Item” quanto “Work Item History”. “Estimated Work” é um bom exemplo de campo do tipo Measure.

                Apesar do campo “Formula” existir nesse form com diversas opções, os campos desse tipo são sempre agregadas como Soma (Sum).

Vamos repetir o uso desse formulário para nossos 3 campos, que nomearei assim:

• BlogSampleCMMi.Tracking.Analysis
• BlogSampleCMMi.Tracking.Development
• BlogSampleCMMi.Tracking.Tests

Aba “Rules”

Nessa aba são definidas algumas propriedades do seu campo, como valor padrão, valores permitidos, validações. O que vamos configurar em todos esses campos são as seguintes regras:

REQUIRED – O campo não poderá ficar em branco;

ALLOWEDVALUES – Deixaremos esses campos serem preenchidos somente com os valores “0%”, “50%” e “100%”.

DEFAULT – Em um novo Work Item, é o valor inicial do campo. Vamos configurá-lo da seguinte forma:

                From: value

                Value: 0%

- Etapa 2: Inserí-los no formulário do work item, através da aba “Layout”.

Essa etapa, apesar de ter uma interface amigável, não é tão intuitiva quanto arrastar controles para um Windows Form, mas claro, é muito melhor do que fazer isso direto no XML. J

Para usarmos nosso campo, primeiro precisamos escolher onde vamos colocá-lo no nosso formulário. Eu escolhi criar uma nova aba, chamando-a de “Etapas” e lá eu coloco somente os meus campos, para não poluir outras áreas do formulário. Veja a tela de layout do Work Item Type:

Na árvore à esquerda, os elementos do formulário são organizados numa estrutura de árvore e, à direita, as propriedades do elemento selecionado.

Nessa árvore, existem alguns tipos de elemento. Vamos entendê-los já praticando.

Dentro do TabGroup, criaremos um novo elemento do tipo “TabPage”. Para isso, botão direito em cima do item TabGroup -> New Tab Page. Um novo item na árvore aparecerá. Do lado direito, uma das propriedades chama-se “Name”. Altere-a para “Etapas”.

Para que os controles não fiquem espalhados dentro da aba, criamos um elemento do tipo “Group” para inserir os controles dentro. Insira então um “Group” ao TabPage usando o menu de contexto já usado acima. Quando um Group é criado, um item do tipo Column é criado dentro dele automaticamente.

Agora já podemos inserir nossos controles dentro da aba. Para isso, use o “New Control” dentro do menu de contexto em cima do item “Column”. Um novo item aparecerá como filho da Column. Ao lado direito, algumas propriedades chave do controle precisam ser modificadas. Vamos à elas:

FieldName: É aqui que você deve encontrar a Reference Name do campo que quer inserir. Neste primeiro caso, procuramos por “BlogSampleCMMi.Tracking.Analysis”.

Label: O label para o campo no formulário. Vamos usar “Análise e documentação (peso: 40%):”

Fazemos isso para os nossos 3 campos. Você pode visualizar préviamente como está ficando seu formulário, através do botão “Preview Form”, mas já adianto que não funciona muito bem. Por algum motivo, o que ele mostra não é exatamente como vai ficar seu formulário. L

Depois de pronto, salvamos o arquivo. Precisamos agora importá-lo devolta para o TFS. Para isso, vá ao menu Tools -> Process Editor – > Work Item Types -> Import WIT. Em “File”, localize o arquivo que você editou e em “Project to Import to” selecione o Team Project para o qual a customização se aplicará. Clique então em OK. Aguarde até que a importação seja concluída.

É importante agora dar um refresh no seu Team Explorer para que os templates sejam recarregados. Após isso, abra o formulário de criação de nova task e já verá a nova aba e os campos dentro dela, assim:

Primeira etapa completa! Logo mais, o segundo post falando sobre a criação de controle customizado.

[]’s

Ricardo Serradas