Fluxo de trabalho e tipos de item de trabalho do processo CMMI no Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
As equipes usam os WIT (tipos de item de trabalho) fornecidos com o processo de MSF (Microsoft Solutions Framework) para CMMI Process Improvement 2015 a fim de 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 seu quadro, 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 portal da Web ou o Microsoft Test Manager, os testadores podem criar e executar casos de teste e definir bugs para rastrear 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. Se você for novo no processo CMMI, examine a seção Planejar e acompanhar o trabalho com CMMI para começar.
Definir requisitos
Crie requisitos no painel de adição rápida da página da lista de pendências do produto. Posteriormente, você pode abrir cada requisito para fornecer mais detalhes e fazer uma estimativa de seu tamanho.
Ou você pode adicionar requisitos em massa usando um arquivo cvs.
Como alternativa, você pode adicionar requisitos usando o Excel ou o Microsoft Project.
Importante
A integração do Microsoft Project e o comando TFSFieldMapping não são suportados para:
- Visual Studio 2019 e Azure DevOps Office Integration 2019.
- Azure DevOps Server 2019 e versões posteriores, incluindo Azure DevOps Services.
O suporte completo para a integração do Microsoft Excel é mantido, permitindo a importação e atualização em massa de itens de trabalho. As alternativas para o Microsoft Project incluem:
- Planos de Entrega
- Extensões do Marketplace, como o Project Connect ou o gráfico GANTT.
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.
Use as diretrizes a seguir e as fornecidas para campos usados em comum em vários tipos de item de trabalho ao preencher o formulário. Para obter mais informações, confira Planejar um projeto.
Campo
Usage
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.
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.
Tipo de Requisito (Obrigatório)
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
A área de valor do cliente abordada pelo item épico, recurso, requisito ou lista de pendências. Os valores são:
- Arquitetura: serviços técnicos para implementar recursos de negócios que fornecem solução
- Negócios: serviços que atendem às necessidades de clientes ou stakeholders que fornecem diretamente o valor do cliente para dar suporte à empresa (padrão)
Estime a quantidade de trabalho necessária para concluir um requisito usando qualquer unidade de medida numérica que sua equipe preferir. Ao definir o Tamanho para os requisitos, as equipes podem usar os gráficos de velocidade de Agile e as ferramentas de previsão para fazer a estimativa das iterações futuras ou dos esforços de trabalho. O Diagrama de Fluxo Cumulativo faz referência aos valores neste campo. Para obter mais informações, confira o white paper Estimativa.
A quantidade estimada de trabalho para concluir uma tarefa. Normalmente, esse campo não muda depois de atribuído.
É possível especificar o trabalho em horas ou dias. Não há unidades de tempo inerentes associadas a esse campo.
As metas de datas para quando o trabalho será iniciado ou concluído.
Prioridade (Obrigatório)
Uma classificação subjetiva do requisito, conforme ele se relaciona ao negócio. 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 recurso é opcional com base em recursos, tempo e risco.
Triagem (Obrigatório)
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.
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)
Indica se o requisito está confirmado no projeto ou não. Você pode especificar Sim ou Não (padrão).
O número de build 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)
O status do teste de aceitação do usuário para um requisito. É possível especificar um dos seguintes valores:
- Passar
- Falha
- Não Pronto (padrão)
- Ready
- Ignorado
- Informações Recebidas
Especifique Não Pronto quando o requisito estiver no estado Ativo e especifique Pronto quando o requisito estiver no estado Resolvido.
Os nomes dos membros da equipe que estão familiarizados com a área de cliente que esse requisito representa.
Captura de comentários na seção Discussão
Use a seção Discussão para adicionar e revisar comentários feitos sobre o trabalho que está sendo executado.
A barra de ferramentas do editor de rich text aparece na área de entrada de texto quando você coloca o cursor em qualquer caixa de texto que suporte formatação de texto.
Observação
O campo de item de trabalho Discussão não existe. Para consultar itens de trabalho com comentários inseridos na área Discussão, será necessário filtrá-los no campo Histórico. O conteúdo completo do texto inserido na caixa de texto de Discussão é adicionado ao campo Histórico.
Mencionar alguém, um grupo, um item de trabalho ou uma solicitação de pull
Selecione um dos ícones a seguir para abrir um menu de entradas recentes onde você mencionou alguém, vinculou a um item de trabalho ou vinculou a uma solicitação de pull. Como alternativa, você pode abrir o mesmo menu digitando @, # ou !.
Insira um nome ou número para filtrar a lista de menus para corresponder à sua entrada. Selecione a entrada que você deseja adicionar. Para colocar um grupo na discussão, insira @ seguido do nome do grupo, como uma equipe ou um grupo de segurança.
Editar ou excluir um comentário
Para editar ou excluir qualquer um dos seus comentários de discussão, escolha 
Editar ou escolha o ícone de ações 
e escolha Excluir.
Observação
Editar e excluir comentários requer o Azure DevOps Server Atualização 1 de 2019 ou versão posterior.
Depois de atualizar o comentário, selecione Atualizar. Para excluir o comentário, confirme se você deseja excluí-lo. Uma trilha de auditoria completa de todos os comentários editados e excluídos é mantida na guia Histórico no formulário do item de trabalho.
Importante
Para Azure DevOps Server na infraestrutura, configure um servidor SMTP para que os membros da equipe recebam notificações.
Adicionar uma reação a um comentário
Adicione uma ou mais reações a um comentário escolhendo um ícone sorridente no canto superior direito de qualquer comentário. Ou escolha entre os ícones na parte inferior de um comentário ao lado de qualquer reação existente. Para remover sua reação, escolha a reação na parte inferior do seu comentário. A imagem a seguir mostra um exemplo da experiência de adicionar uma reação e a exibição de reações em um comentário.
Salvar um comentário sem salvar o item de trabalho
Observação
Esse recurso está disponível a partir do Azure DevOps Server 2022.1.
Se você só tiver permissões para adicionar à Discussão de um item de trabalho, poderá fazer isso salvando comentários. Essa permissão é controlada por nós de Caminho de Área e pela permissão Editar comentários de item de trabalho neste nó. Para obter mais informações, confira Definir permissões de acompanhamento de trabalho, Criar nós filho, modificar itens de trabalho em um caminho de iteração ou área.
Depois de salvar os comentários, você não precisará salvar o item de trabalho.
Observação
Quando você salva as alterações feitas no controle Discussão, somente o comentário é salvo. Nenhuma regra de item de trabalho definida para o tipo de item de trabalho é executada.
Acompanhar o progresso do trabalho
À medida que o trabalho progride, você altera o campo Estado para atualizar o status. Opcionalmente, você pode especificar um motivo. Os campos estado e motivo aparecem no formulário do item de trabalho na área de cabeçalho.
Mapear estados de fluxo de trabalho de CMMI
Esses diagramas mostram os principais estados de progressão e regressão dos WITs de requisito, bug e tarefa.
| Requisito | Bug | Tarefa |
|---|---|---|
 |
 |
 |
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.
Atualizar o status do trabalho com um quadro ou Taskboards
O Teams pode usar o quadro para atualizar o status dos requisitos e o quadro de tarefas de sprint para atualizar o status das tarefas. Arrastar itens para uma nova coluna de estado atualiza os campos Estado e Motivo.
Você pode personalizar o Board para dar suporte a mais raias ou colunas.
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 visualizar o escopo ao definir recursos e mapear requisitos para recursos.
Usando as listas de pendências do portfólio, você pode fazer uma pesquisa detalhada de uma lista de pendências para outra para ver o nível de detalhes que desejar. Além disso, você pode usar as listas de pendências do portfólio para ver um rollup do trabalho em andamento de várias equipes ao configurar uma hierarquia de equipes.
O item de trabalho de recurso contém campos semelhantes fornecidos para requisitos e inclui campos adicionais, como descreve a tabela a seguir.
Definir tarefas
Quando sua equipe gerencia seu trabalho em sprints, ela pode usar a página da lista de pendências de sprint para dividir o trabalho a ser feito em tarefas diferentes.
Nomeie a tarefa e faça uma estima 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 mais informações, confira Atividades de iteração.
Campo
Usage
Selecione o tipo de tarefa para implementar dos valores permitidos:
Ação corretiva
Ação de Mitigação
Planejado
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 mais informações, confira Implementar tarefas de desenvolvimento.
A quantidade estimada de trabalho para concluir uma tarefa. Normalmente, esse campo não muda depois de atribuído.
A quantidade de trabalho restante 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 Burndown de Sprint. 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.
A quantidade de trabalho gasto na implementação de uma tarefa.
Acompanhar o andamento do teste
Requisitos de teste
No portal da Web ou Test Manager, você pode criar casos de teste que vinculem automaticamente a um requisito ou bug. Ou você pode vincular um requisito a um caso de teste do 
(guia Links).
O caso de teste contém muitos 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, confira Consulta com base nos campos de integração de build e teste.
A guia (guia de links) 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 de Visão Geral de Requisitos.
Rastrear defeitos de código
Você pode criar bugs no portal da Web, Visual Studio, ou quando testar com o Test Manager.
Acompanhar solicitações de alteração, riscos, problemas e observações capturadas em reuniões de revisão
Juntamente com o requisito, recurso, tarefa e bug, você pode acompanhar as informações recomendadas pelo processo CMMI com o WITS a seguir.
- Alterar a solicitação para gerenciar as alterações propostas em qualquer produto de trabalho que esteja sob controle de alterações.
- Emitir 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.
- Risco para acompanhar a probabilidade e o grau de variação entre os resultados reais e desejados. Ao gerenciar riscos, você minimiza estrategicamente a variação entre o resultado desejado e o resultado real.
- Examine 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.
Você pode adicionar um problema do Widget do novo item de trabalho adicionado a um painel de equipe ou no menu Novo na página Consultas.
Os itens de trabalho adicionados por meio do widget são automaticamente definidos para a área padrão da sua equipe e os caminhos de iteração. Para alterar o contexto da equipe, confira Alternar contexto de equipe.
Definições para campos comuns de acompanhamento de trabalho
Os campos e guias a seguir aparecem na maioria dos itens de trabalho. Cada guia é usada para acompanhar informações específicas, como 
Histórico, Links ou 
Anexos. Essas três guias fornecem um histórico de alterações, exibição de itens de trabalho vinculados e a capacidade de exibir e anexar arquivos.
O único campo obrigatório para todos os tipos de item de trabalho é Título. Quando você salva um item de trabalho, o sistema atribui a ele uma ID exclusiva. O formulário realça o campo obrigatório em amarelo. Para obter informações sobre outros campos, confira Índice de campo de item de trabalho.
Observação
Campos adicionais podem ser necessários dependendo das personalizações feitas em seu processo e projeto.
Campo/guia
Usage
Digite uma descrição de 255 caracteres ou menos. Você pode alterar o título quando quiser.
Atribua o item de trabalho ao membro da equipe responsável pela execução do trabalho.
Quando o item de trabalho é criado, o Estado assume como padrão o primeiro estado no fluxo de trabalho. Conforme o trabalho progride, atualize-o para refletir o estado atual.
Use primeiro o padrão. Atualize-o quando você alterar o estado. Cada estado é associado a um motivo padrão.
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, confira Definir caminhos de área e atribuir a uma equipe.
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, confira Definir caminhos de iteração (sprints) e configurar iterações de equipe.
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.
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.
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.
Personalizar os tipos de item de trabalho
Para a maioria dos tipos de item de trabalho, você pode adicionar campos, alterar o fluxo de trabalho, adicionar regras personalizadas e adicionar páginas personalizadas ao formulário do item de trabalho. Você também pode adicionar tipos de item de trabalho personalizados. Para obter mais informações, consulte Personalizar um processo de herança.
Para a maioria dos tipos de item de trabalho, você pode adicionar campos, alterar o fluxo de trabalho, adicionar regras personalizadas e adicionar páginas personalizadas ao formulário do item de trabalho. Você também pode adicionar tipos de item de trabalho personalizados. Para obter mais informações, consulte Personalizar um processo de herança ou personalizar o modelo de processo XML local, dependendo do modelo de processo usado pelo seu projeto.
Artigos relacionados
- Criar um projeto
- Adicionar itens de trabalho para gerenciar um projeto
- Criar um backlog
- Gerenciar o acesso a recursos específicos
- Saiba mais sobre permissões padrão e níveis de acesso para o Azure Boards
Ordem de lista de pendências
O campo Stack Rank é usado para acompanhar a classificação relativa de requisitos, recursos ou épicos. No entanto, por padrão, ele não aparece no formulário do item de trabalho. A sequência de itens na página da lista de pendências é 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.
Esse campo não aparece no formulário do item de trabalho.