Tipos de item de trabalho e fluxo de trabalho do modelo de processo do CMMI

As equipes usam os tipos de item de trabalho (WITs) fornecidos com o modelo de processo MSF for CMMI Process Improvement 2013 (CMMI) para planejar e acompanhar o andamento dos projetos de software. As equipes definem os requisitos para gerenciar a lista de pendências do trabalho e, usando o quadro kanban, acompanham o andamento atualizando o status dos requisitos.

Para obter informações sobre um portfólio de requisitos, os proprietários do produto podem mapear os requisitos dos recursos. Quando as equipes trabalham em iterações, elas definem tarefas vinculadas automaticamente aos requisitos.

Usando o Microsoft Test Manager e o TWA (Team Web Access), os testadores criam e executam casos de teste, além de definir bugs para acompanhar defeitos de código.

Para dar suporte aos processos CMMI adicionais, as equipes podem acompanhar solicitações de alteração, riscos, problemas e anotações feitas em reuniões de revisão.

Planejar um projeto definindo os requisitos e fazendo a estimativa do tamanho do esforço

Crie requisitos no painel de adição rápida da página da lista de pendências do produto. Como alternativa, você pode adicionar requisitos em massa usando o Excel ou o Project.

Posteriormente, você pode abrir cada requisito para fornecer mais detalhes e fazer uma estimativa de seu tamanho.

Os requisitos especificam as funções e os elementos do produto que as equipes precisam criar. Os proprietários do produto geralmente definem e empilham os requisitos de classificação na página da lista de pendências do produto. A equipe faz o escopo do tamanho do esforço para fornecer os itens de prioridade mais alta.

Ao definir o Tamanho para os requisitos, as equipes podem usar o recurso de previsão e os gráficos de velocidade para fazer a estimativa das iterações futuras ou dos esforços de trabalho. Capture informações essenciais usando os seguintes campos e guias. Para obter orientação adicional, consulte Planejar um projeto.

Campo/guia	Uso
Tamanho (veja a observação 1)	Faça a estimativa da quantidade de trabalho necessária para concluir um requisito usando qualquer unidade de medida que sua equipe preferir, como o tamanho da camiseta, os pontos da história ou o tempo. Os gráficos de velocidade e as ferramentas de previsão do Agile referenciam os valores nesse campo. Esse é um campo obrigatório para gerar o gráfico de velocidade.
Prioridade [Obrigatório] (2)	Uma classificação subjetiva do requisito, conforme ele se relaciona ao negócio. Os valores permitidos são: 1: o produto não pode ser enviado sem o item. 2: (padrão) o produto não pode ser enviado sem o item, mas não precisa ser resolvido imediatamente. 3: a implementação do item é opcional com base em recursos, tempo e risco.
Triagem [Obrigatório] (2)	Indica o tipo de decisão de triagem que está pendente para o item de trabalho. Use esse campo quando o item de trabalho estiver no estado proposto e especifique um dos seguintes valores: Pendente (padrão), Mais Informações, Informações Recebidas e Triados.
Bloqueado (2)	Indica se um membro da equipe é impedido de progredir na implementação de um requisito ou uma tarefa ou resolver um bug, uma solicitação de alteração ou um risco. Se um problema foi aberto para acompanhar um problema de bloqueio, você pode criar um link para o problema. Você pode especificar Sim ou Não.
Confirmado [Obrigatório] (2)	Indica se o requisito está confirmado no projeto ou não. Você pode especificar Sim ou Não (padrão).
Classificação de Pilha (1)	Usado para acompanhar a classificação relativa dos requisitos. A sequência de itens na página da lista de pendências do produto é determinada de acordo com o local onde você adicionou os itens ou moveu os itens na página. À medida que você arrasta itens, um processo em segundo plano atualiza esse campo que é atribuído a type="Order" no arquivo ProcessConfiguration.
(Requisito) Tipo [Obrigatório] (2)	O tipo de requisito a ser implementado. É possível especificar um dos seguintes valores: Objetos de Negócios Recurso (padrão) Funcional Interface Operacional Qualidade de Serviço Segurança Cenário Segurança
Descrição	Forneça detalhes suficientes para fazer a estimativa do trabalho necessário para implementar o requisito. Foque no público-alvo do requisito, no que os usuários desejam fazer e por quê. Não descreva como o requisito deve ser desenvolvido. Forneça detalhes suficientes para que sua equipe possa escrever tarefas e casos de teste para implementar o item. Em campos HTML, você pode adicionar rich text e imagens.
Análise (Avaliação de impacto)	O impacto para o cliente ao não implementar esse requisito. Você pode incluir detalhes do modelo Kano sobre se esse requisito está nas categorias de item surpresa, obrigatório ou óbvio. Você captura essas informações no campo HTML rich-text que corresponde à avaliação de impacto.
Outro	Os campos a seguir, localizados na guia Outro, não são obrigatórios. Integrado em: o número da compilação do produto que incorpora o requisito, a solicitação de alteração ou as correções de um bug. Teste de Aceitação do Usuário [Obrigatório] (2): o status de teste de aceitação do usuário. Aprovado Reprovado Não está pronto (padrão) Pronto Ignorado Informações Recebidas Especifique Não está pronto quando o requisito for Ativo e Pronto quando o requisito for Resolvido. Estimativa Original (3): a quantidade necessária de horas ou dias para concluir uma tarefa. Especialistas no Assunto: os nomes dos membros da equipe que estão familiarizados com a área do cliente que esse requisito representa. Data de Início, Data de Término (3): as datas de destino para quando o trabalho será iniciado ou concluído. Esses campos são preenchidos pelo Microsoft Project quando você o usa para agendamento.

Observações:

1. Para alterar a atribuição de campo, consulte Configurar e personalizar ferramentas de planejamento do Agile para um projeto de equipe.

2. Para alterar a seleção do menu, consulte Personalizar uma lista de opções.

3. É possível especificar o trabalho em horas ou dias. Não há unidades de tempo inerentes associadas a esse campo.

   Se você usar o Microsoft Project para atribuir recursos e controlar uma agenda, poderá atualizar esses campos usando o Project.

Acompanhar o andamento

As equipes podem usar o bloco Kanban para acompanhar o andamento dos requisitos e o painel de tarefas sprint para acompanhar o andamento das tarefas. Arrastar itens para uma nova coluna de estado atualiza os campos Estado e Motivo do fluxo de trabalho.

Você pode personalizar o bloco Kanban para oferecer suporte a pistas ou colunas adicionais. Ou, você pode personalizar o fluxo de trabalho para os WITs de tarefa e requisito, que alterarão os títulos padrão das colunas.

Esta é uma progressão típica de fluxo de trabalho para um requisito:

• O proprietário do produto cria um requisito no estado Proposto com o motivo padrão, Novo requisito.

• O proprietário do produto atualiza o status para Ativo quando começa a trabalhar para implementá-lo.

• A equipe atualiza o status para Resolvido quando termina o desenvolvimento de código e os testes do sistema são concluídos com êxito.

• Por fim, a equipe ou o proprietário do produto move o requisito para Fechado quando o proprietário do produto concorda que ele foi implementado de acordo com os critérios de aceitação e que passou em todos os testes de validação.

Mapear requisitos para recursos

Ao gerenciar um pacote de produtos ou de experiências do usuário, você talvez queira exibir o escopo e o andamento do trabalho no portfólio do produto. Você pode fazer isso definindo recursos e mapeando requisitos para recursos.

Na página Lista de pendências de recursos, você pode adicionar recursos rapidamente, da mesma maneira que adicionou requisitos.

O item de trabalho de recurso contém campos semelhantes fornecidos para requisitos e inclui campos adicionais, como descreve a tabela a seguir.

A guia Requisitos captura os links para os requisitos mapeados.

Field	Uso
Valor Comercial	Especifique um número que capture o valor relativo de um recurso comparado a outros recursos. Quanto maior for o número, maior será o valor comercial.
Data de Destino	Especifique a data até a qual o recurso deverá ser implementado.

Na página da lista de pendências com o Mapeamento ativado, você pode arrastar requisitos para o recurso que eles implementam.

Esse mapeamento cria os links pai-filho de recurso para requisitos, o que é capturado na guia Requisitos.

Usando as listas de pendências do portfólio, você pode fazer uma pesquisa detalhada de uma lista de pendências para outra para exibir o nível de detalhes que desejar. Além disso, você pode usar as listas de pendências do portfólio para exibir um rollup do trabalho em andamento de várias equipes ao configurar uma hierarquia de equipes.

Definir as tarefas necessárias para implementar requisitos e controlar a capacidade e o burndown da equipe

Quando sua equipe gerencia seu trabalho em uma série de iterações, ela pode usar a página da lista de pendências para dividir o trabalho a ser feito em tarefas diferentes.

Nomeie a tarefa e faça uma estimativa do trabalho que será necessário.

Quando as equipes fazem a estimativa do trabalho, elas definem tarefas e fazem a estimativa das horas ou dias para concluir as tarefas. As equipes preveem o trabalho e definem as tarefas no início de uma iteração, e cada membro da equipe realiza um subconjunto dessas tarefas. As tarefas podem incluir desenvolvimento, testes e outros tipos de trabalho. Por exemplo, um desenvolvedor pode definir tarefas para implementar requisitos, e um testador pode definir tarefas para escrever e executar casos de teste. Ao vincular tarefas a requisitos e bugs, eles veem o progresso realizado nesses itens. Para obter orientação adicional, consulte Atividades de iteração.

Field	Uso
Tipo de tarefa (veja a observação 1)	Selecione o tipo de tarefa para implementar dos valores permitidos: Ação Corretiva Ação de Mitigação Planejado
Disciplina (1)	Selecione a disciplina que representa essa tarefa quando sua equipe fizer a estimativa da capacidade do sprint por atividade. Análise Desenvolvimento Teste Educação do Usuário Experiência do Usuário Esse campo também é usado para calcular a capacidade por disciplina. Ele é atribuído a type="Activity" no arquivo de ProcessConfiguration. (2) Para obter orientação adicional, consulte Implementar tarefas de desenvolvimento.
Estimativa Original (3)	A quantidade estimada de trabalho para concluir uma tarefa. Normalmente, esse campo não muda depois de atribuído.
Trabalho Restante (3)	Indica quantas horas ou dias de trabalho restam para concluir uma tarefa. Conforme o trabalho progride, atualize esse campo. Usado para calcular gráficos de capacidade, o gráfico de burndown de sprint e o relatório Relatório de Burndown e Taxa de Gravação. Se você dividir uma tarefa em subtarefas, especifique horas somente para as subtarefas. Você pode especificar o trabalho em qualquer unidade de medida que sua equipe escolher.
Trabalho Concluído (3)	A quantidade de trabalho gasto na implementação de uma tarefa.

Observações:

1. Para alterar a seleção do menu, consulte Personalizar uma lista de opções.

2. Para alterar a atribuição de campo, consulte Configurar e personalizar ferramentas de planejamento do Agile para um projeto de equipe.

3. É possível especificar o trabalho em horas ou dias. Não há unidades de tempo inerentes associadas a esse campo.

   Se você usar o Microsoft Project para atribuir recursos e controlar uma agenda, poderá atualizar esses campos usando o Project.

Acompanhar o andamento do teste nas histórias de usuário e capturar defeitos de código

Requisitos de teste

No Test Manager ou no TWA, você pode criar casos de teste que vinculem automaticamente a um requisito ou bug.

O caso de teste contém vários campos, muitos dos quais são automatizados e integrados com o Test Manager e o processo de compilação. Para obter uma descrição de cada campo, consulte Referência de campos de integração de compilação e teste.

A guia Requisitos Testados lista todos os requisitos e bugs em um caso de teste. Usando vínculos, a equipe pode acompanhar o progresso feito nos testes de cada item e oferecer suporte às informações que aparecem no relatório Relatório Visão Geral de Requisitos (CMMI).

Rastrear defeitos de código

Você pode criar bugs no TWA, Visual Studio ou quando testar com o Test Manager. Para obter orientação adicional, consulte Rastrear bugs.

Campo/guia	Uso
Causa raiz	Selecione a causa do erro dos valores permitidos: Erro de Codificação Erro de Design Erro de Especificação Erro de Comunicação Unknown Para alterar a seleção do menu, consulte Personalizar uma lista de opções.
Passos a reproduzir	Capture informações suficientes para que os outros membros da equipe possam entender o impacto completo do problema, bem como saber se o bug foi corrigido. Isso inclui as ações executadas para localizar ou reproduzir o bug e o comportamento esperado. Descreva os critérios que a equipe deve usar para verificar se o defeito de código foi corrigido.
Gravidade	Selecione um dos valores permitidos que representam uma classificação subjetiva do impacto de um bug no projeto: 1 - Crítico 2 - Alto 3 - Médio 4 - Baixo Para alterar a seleção do menu, consulte Personalizar uma lista de opções.
Informações do Sistema Encontrado na Compilação Integrado na Compilação	Quando o Test Manager cria bugs, ele preenche automaticamente Informações do Sistema e Encontrado na Compilação com informações sobre o ambiente e a compilação de software onde o bug ocorreu. Para saber mais sobre como definir os ambientes de software, consulte Configurando máquinas de teste para executar testes ou coletar dados. Quando você resolver o erro, use Integrado na Compilação para indicar o nome da compilação que incorpora o código que corrige o bug. Para acessar um menu suspenso de todas as compilações que foram executadas, você pode atualizar as definições de FIELD para Encontrado na Compilação e Integrado na Compilação para fazer referência a uma lista global. A lista global é automaticamente atualizada com cada compilação executada. Para saber mais, consulte Campos que dão suporte à integração com teste, compilação e controle de versão. Para obter informações sobre como definir nomes de compilação, consulte Usar números de compilação para dar nomes significativos a compilações concluídas.

Acompanhar solicitações de alteração, riscos, problemas e observações capturadas em reuniões de revisão

Com as seguintes WITs, as equipes podem acompanhar as informações recomendadas pelo processo CMMI.

• Crie uma solicitação de alteração sempre que uma alteração for proposta para qualquer produto de trabalho que esteja sob o controle de alteração. Para obter diretrizes de uso adicionais, consulte Gerenciar alterações e Referência de campos de solicitação de alteração (CMMI).

  

  Na guia Análise, forneça os detalhes do impacto que a solicitação de alteração terá na arquitetura, na experiência do usuário, no teste, no design/desenvolvimento ou nas publicações técnicas.

• Crie um problema para acompanhar um evento ou uma situação que poderia bloquear o trabalho ou que esteja bloqueando o trabalho no produto. Problemas são diferentes de riscos, já que as equipes identificam problemas espontaneamente, geralmente durante reuniões diárias da equipe.

  

  Para obter orientação adicional, consulte Gerenciar problemas e Referência de campos de bugs, problemas e riscos (CMMI).

• Crie um risco para acompanhar um evento ou uma situação que poderia bloquear o trabalho ou que esteja bloqueando o trabalho no produto. Problemas são diferentes de riscos, já que as equipes identificam problemas espontaneamente, geralmente durante reuniões diárias da equipe.

  

  Para obter orientação adicional, consulte Gerenciar problemas e Referência de campos de bugs, problemas e riscos (CMMI).

• Crie uma revisão para documentar os resultados de uma revisão de design ou de código. Os membros da equipe podem capturar os detalhes de como o design ou o código atendem aos padrões em áreas de exatidão de nome, relevância do código, extensibilidade, complexidade do código, complexidade algorítmica e segurança do código.

  

  Para obter orientação adicional, consulte Implementar tarefas de desenvolvimento e Examinar a referência de campos de reunião (CMMI).

Definir campos e guias de itens de trabalho comuns

Os campos e guias a seguir aparecem na maioria dos formulários de item de trabalho. Cada guia é usada para acompanhar informações específicas, como Histórico, Links ou Anexos. Esses três campos fornecem um histórico de alterações, exibição de itens de trabalho vinculados e a capacidade de exibir e anexar arquivos, respectivamente.

O único campo obrigatório é Título. Quando o item de trabalho é salvo, o sistema atribui uma ID exclusiva a ele.

Campo/guia	Uso
Título (Obrigatório)	Digite uma descrição de 255 caracteres ou menos. Você pode alterar o título quando quiser.
Atribuído a	Atribua o item de trabalho ao membro da equipe responsável pela execução do trabalho. Dependendo do contexto em que você está trabalhando, o menu suspenso listará somente os membros da equipe ou os colaboradores para o projeto de equipe.
Estado	Use primeiro o valor padrão. Conforme o trabalho progride, atualize-o para refletir o estado atual. Para alterar a lista suspensa de estados, consulte Alterar o fluxo de trabalho de um tipo de item de trabalho.
Motivo	Use primeiro o padrão. Atualize-o quando você alterar o estado. Cada estado é associado a um motivo padrão. Para alterar a lista suspensa de motivos, consulte Alterar o fluxo de trabalho de um tipo de item de trabalho.
Área	Escolha o caminho de área associado ao produto ou à equipe, ou deixe em branco até ser atribuído durante uma reunião de planejamento. Para alterar a lista suspensa de áreas, consulte Adicionar e modificar área e caminhos de iteração.
Iteração	Escolha o sprint ou a iteração em que o trabalho deve ser concluído, ou deixe em branco e atribua posteriormente, durante uma reunião de planejamento. Para alterar a lista suspensa de iterações, consulte Adicionar e modificar área e caminhos de iteração.
Todos os Links	Adicione todos os tipos de links, como hiperlinks, conjuntos de alterações, arquivos de origem e assim por diante. Essa guia também lista todos os links definidos para o item de trabalho, mesmo aqueles definidos em outras guias de controle de links.
Anexos	Compartilhe informações mais detalhadas adicionando arquivos ao item de trabalho, como threads de email, documentos, imagens, arquivos de log ou outros tipos de arquivo.
Histórico	Examine a trilha de auditoria que o sistema captura e as informações adicionais da captura. Cada vez que o item de trabalho é atualizado, as informações são acrescentadas ao histórico. O histórico inclui a data da alteração, quem fez a alteração e os campos que foram modificados. Você também pode adicionar texto formatado ao campo do histórico.

Para pesquisar informações sobre outros campos, consulte Índice de campos de item de trabalho.

Começar a acompanhar o trabalho

Antes de começar a acompanhar o trabalho, você deve ter um projeto de equipe. Acesse aqui para criar um.

Para começar a acompanhar o trabalho, realize uma ou mais das tarefas a seguir:

• Para se familiarizar com as tarefas comuns do item de trabalho, consulte Começar usando itens de trabalho.

• Para criar uma lista de pendências, use o TWA. Consulte Criar sua lista de pendências.

• Para criar uma estrutura de detalhamento de trabalho, use Projeto ou Excel.

• Para saber qual cliente usar, consulte Escolher o cliente do Team Foundation para oferecer suporte às suas tarefas.

Perguntas e respostas

P: Estados de fluxo de trabalho quais oferece suporte CMMI?

R: esses diagramas mostram os estados de regressão e de progressão principais de recurso e tarefa, Bug e requisito. Para personalizar o fluxo de trabalho, vá aqui.

Recurso

Requisito

Bug

Tarefa

P: Como resolvo um bug como duplicata?

R: Defina o Estado como Removido e especifique o Motivo como Duplicata.

P: Como vinculo um bug existente do Test Runner?

R: Consulte Atualizar um bug existente com o Test Runner.