Conhecendo um Pouco mais sobre ALM – Post 13 de 100 – Fluxo de Processos – Dicas de Relacionamento de Work Items – MSF for CMMI

Olá Pessoal,

Resolvi escrever esse Post para tirar algumas dúvidas sobre relacionamento entre Work Items usados no Team Foundation Server em seu processo de Application Lifecycle Management.

Antes de mais nada, saliento que cada empresa, equipe e até os idealizadores de processos de desenvolvimento tem seu processo, e o que eu aprendi na minha curta carreira profissional é que a palavra “DEPENDE” é muuuuuita usada e que o objetivo desse post não é dizer o que é certo ou errado e sim ajudar nessa discussão e até jogar mais idéias de como pode funcionar seu processo.

Nesse post, o relacionamento está ligado ao fluxo base do Process Template do TFS chamado MSF para CMMI para Visual Studio ALM. E essas são perguntas que me fizeram e as respostas que eu dei para as mesmas.

image

Evolução de um Requirement (Requisito), como funciona.

Hoje uma evolução de um Requisito nos Relatórios do TFS (Reports – Project Management – Requirement Overview), basea-se nos pilares:

% Hours Completed, Hours Remaining, Test Points, Test Results e Bugs.

image

– Onde as horas são baseadas nas Tasks com vinculos “Child”, sendo que o calculo é feito a partir dessa tasks. Ou seja, se eu inserir 10 Tasks, com 02 horas de duração cada, significa que o requisito tem 20 horas para ser concluído;

– Onde a porcentagem de testes são baseados nos Casos de Testes vinculados ao Requisito como “Tested By”, e os Tests Points são a quantidade de “Ambientes ou Configurações” que um Caso de Teste possui. Então se você tiver um 02 Casos de Testes, com 02 Ambientes a serem testados, você possui 04 Pontos de Testes, e conforme os Casos de Testes forem sendo concluidos, seu percentual no requisito será preenchido, sendo com OK ou Failed;

– Quando você está executando um teste a partir do Test Runner e abrir um BUG, ele será vinculado automaticamente e aparecerá no seu relatório de requisitos depois de um periodo. Então se tivermos 02 ou 03 Bugs abertos, vinculados a Casos de Testes que estão vinculados ao Requisito, eles aparecerão no seu relatório corretamente;

De posse dessas importantes informações iniciais você conseguirá definir e responder as perguntas abaixo, conforme sua necessidade de processo.

Q-) Devo vincular uma Tarefa de Teste à um Requisito?

Depende do seu time, medição e necessidade.

Cenário A: Se você quiser medir apenas o desenvolvimento propriamente dito, sem contar com os ajustes depois, pois com certeza nos testes você irá encontrar BUGS e deverá corrigir, você deverá vincular apenas as tarefas de desenvolvimento. Assim, quando seu desenvolvimento concluir e marcar as horas no Work Item Task, no relatório, aparecerá como 100% concluido. Mas não necessariamente estará pronto, pois ainda faltará a parte de testes que estará “vazia”. Então em uma abordagem que entende que um Requisito deve ser medido apenas com as horas de desenvolvimento, e tudo depois é retrabalho, ou seja, não deve constar nas horas iniciais do requisito, todos as tarefas depois de desenvolvimento não devem ser vinculadas. Ou seja, Tarefa de Teste (que gera horas no TFS) não deve ser vinculada a esse requisito, bem como qualquer outro Work Item Task.

Cenário B: Já se sua abordagem quer saber quanto custa um requisito integralmente, incluindo tudo, você deverá vincular tudo, incluindo não só Task de Teste, mas também de Análise do Requisito, preparação de ambiente, Task Adicional para medir o BUG já que a mesma não possui horas (ou customizar o Work Item), e por aí vai.

Q) Deve haver vínculo entre a Task de Teste e o Bug?

Não precisa, pois no Test Runner você irá Vincular o BUG ao Test Case que por sua vez está associado ao Requisito, gerando então a rastreabilidade automática.

Q) Deve haver vínculo entre Bug e Requisito?

Não precisa, pois no Test Runner você irá Vincular o BUG ao Test Case que por sua vez está associado ao Requisito, gerando então a rastreabilidade automática.

Q) Deve haver vínculo entre Issue e Requisito?

Depende do seu time, medição e necessidade.

Cenário A: Se sua Issue é um start de trabalho que irá alterar um Requirement diretamente, sim.

Abordagem onde você deseja ter rastreabilidade do que foi feito para solucionar aquela Issue a nível de Requisito: Sim

Cenário B: Abordagem onde, independentemente de ter Issue ou não, será aberto uma nova Task para uma nova versão: Não, porém você precisa de alguma forma ter uma rastreamento e histórico na Issue da versão anterior para saber o que foi feito. Responder a perguntas como: – Nessa Issue aqui descoberta na versão 2.4, o que foi feito para solucionar essa questão?

Agradeço à Janete Costa que me ajuda muito nisso e faz eu quebrar a cabeça valendo com os cenários mais loucos possíveis.

Lembrando pessoal, que isso é apenas uma idéia, e cada empresa tem seu caminho e necessidades!

Uma abraço e até a próxima!

Alan Carlos

2 comentários sobre “Conhecendo um Pouco mais sobre ALM – Post 13 de 100 – Fluxo de Processos – Dicas de Relacionamento de Work Items – MSF for CMMI

  1. Olá, Alan!
    Show esse post!
    É muito legal poder utilizar ferramentas desse calibre (VS ALM) no dia a dia e em situações reais, como fazemos.
    A gente acaba adquirindo ainda mais conhecimento e podendo auxiliar à comunidade ALM, com experiências práticas.
    Quem vê este belo artigo redondinho não imagina quantas horas de conversa foram gastas e quantas vezes escrevemos e apagamos fluxos naquele seu quadro branco… hahaha
    Abraço!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s