Escolha um fluxo de processo ou um modelo de processo para trabalhar em Azure Boards

  • Artigo
  • 12 minutos para o fim da leitura

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019 | TFS 2018

Sempre que você criar um projeto, deverá escolher um processo ou modelo de processo com base no modelo de processo selecionado para sua organização ou coleção. Ao escolher um processo para seu projeto, é importante entender os seguintes termos:

  • Um modelo de processo refere-se ao modelo usado para dar suporte a projetos criados para uma organização (Azure DevOps Services) ou coleção de projetos (Azure DevOps Server). Há suporte apenas para um modelo de processo para um projeto por vez. Uma comparação dos três modelos de processo — Herança, XML local e XML hospedado — é fornecida em Personalizar o acompanhamento de trabalho.
  • Um processo define os blocos de construção do sistema de acompanhamento de itens de trabalho e dá suporte ao modelo de processo de herança para Azure Boards. Esse modelo dá suporte à personalização de projetos por meio de uma interface do usuário WYSIWYG.
  • Um modelo de processo define os blocos de construção do sistema de acompanhamento de itens de trabalho e outros subsistemas que você acessa por meio do Azure DevOps. Os modelos de processo são usados apenas com os modelos de processo XML hospedado e XML local. Você personaliza projetos modificando e importando arquivos de definição XML de modelo de processo.

Observação

Para obter diretrizes sobre como configurar e personalizar seu projeto e equipes para dar suporte às suas necessidades de negócios, examine Configuração e personalização de Azure Boards.

Para obter detalhes sobre como criar um projeto usando o processo de sua escolha, consulte Criar um projeto. Para saber mais sobre modelos de processo, confira Personalizar sua experiência de acompanhamento de trabalho.

Dica

Com Azure DevOps Server, você pode escolher entre usar o modelo de processo herdado ou o modelo de processo XML local. Para obter detalhes, consulte Personalizar sua experiência de acompanhamento de trabalho, Escolha o modelo de processo para sua coleção de projetos. Para acessar as versões mais recentes dos modelos de processos/processos padrão:

Dica

Para acessar as versões mais recentes dos modelos de processo padrão:

Os objetos de acompanhamento de trabalho contidos nos processos padrão e nos modelos de processo – Básico, Agile, CMMI e Scrum – são os mesmos e resumidos abaixo. O processo Básico está disponível no Azure DevOps Server 2019.1 e versões posteriores. Para simplificar, eles são chamados de "processo".

Dica

Para exibir e gerenciar modelos de processo herdados, consulte Gerenciar processos.

Escolher um processo Básico, Agile, Scrum e CMMI

Os processos padrão diferem principalmente nos WITs (tipos de item de trabalho) que eles fornecem para planejar e acompanhar o trabalho.

Básico é o mais leve e está em uma versão prévia seletiva. Scrum é o próximo mais leve. O Agile dá suporte a muitos termos de método Agile, e o CMMI, que significa Integração do Modelo de Maturidade de Capacidade, oferece mais suporte para processos formais e gerenciamento de alterações.

Observação

O processo Básico está disponível com Azure DevOps Server Atualização 1 de 2019 e versões posteriores.

Escolha o processo que fornece a melhor opção para sua equipe.

Basic

Escolha Básico quando sua equipe quiser o modelo mais simples que usa Problemas, Tarefas e Epics para acompanhar o trabalho.

As tarefas dão suporte ao acompanhamento do Trabalho Restante.

Tipos básicos de item de trabalho

Agile

Escolha Agile quando sua equipe usar métodos de planejamento Agile, incluindo Scrum, e acompanhe as atividades de desenvolvimento e teste separadamente. Esse processo funciona muito bem se você quiser acompanhar histórias de usuários e (opcionalmente) bugs no quadro Kanban ou acompanhar bugs e tarefas no quadro de tarefas.

Você pode saber mais sobre metodologias Agile na Agile Alliance.

As tarefas dão suporte ao acompanhamento da Estimativa Original, do Trabalho Restante e do Trabalho Concluído.

Tipos de item de trabalho Agile

Scrum

Escolha Scrum quando sua equipe praticar o Scrum. Esse processo funciona muito bem se você quiser acompanhar PBIs (itens de lista de pendências) do produto e bugs no quadro Kanban ou dividir PBIs e bugs em tarefas no quadro de tarefas.

Esse processo dá suporte à metodologia Scrum, conforme definido pela organização Scrum.

As tarefas dão suporte apenas ao acompanhamento do trabalho restante.

Tipos de item de trabalho scrum

CMMI

Escolha CMMI quando sua equipe seguir métodos de projeto mais formais que exigem uma estrutura para aprimoramento do processo e um registro auditável de decisões. Com esse processo, você pode acompanhar requisitos, solicitações de alteração, riscos e revisões.

Esse processo dá suporte a atividades formais de gerenciamento de alterações. As tarefas dão suporte ao acompanhamento da Estimativa Original, do Trabalho Restante e do Trabalho Concluído.

Tipos de item de trabalho CMMI

Se você precisar de mais de dois ou três níveis de lista de pendências, poderá adicionar mais com base no modelo de processo usado:

Principais distinções entre os processos padrão

Os processos padrão são projetados para atender às necessidades da maioria das equipes. Se sua equipe tiver necessidades incomuns e se conectar a um servidor local, você poderá personalizar um processo e, em seguida, criar o projeto. Ou você pode criar um projeto a partir de um processo e, em seguida, personalizar o projeto.

A tabela a seguir resume as principais distinções entre os WITs e os estados usados pelos quatro processos padrão.

Área de acompanhamento

Basic

Agile

Scrum

CMMI

Estados de fluxo de trabalho

  • To Do
  • Fazendo
  • Concluído
  • Novo
  • Ativo
  • Resolvido
  • Fechado
  • Removido
  • Novo
  • Aprovado
  • Confirmado
  • Concluído
  • Removido
  • Proposto
  • Ativo
  • Resolvido
  • Fechado

Planejamento de produto (consulte a observação 1)

  • Problema
  • História de usuário
  • Bug (opcional)
  • Item da lista de pendências do produto
  • Bug (opcional)
  • Requisito
  • Bug (opcional)

Listas de pendências de portfólio (2)

  • Épico
  • Épico
  • Recurso
  • Épico
  • Recurso
  • Épico
  • Recurso

Planejamento de tarefas e sprint (3)

  • Tarefa
  • Tarefa
  • Bug (opcional)
  • Tarefa
  • Bug (opcional)
  • Tarefa
  • Bug (opcional)

Gerenciamento de lista de pendências de bugs (1)

  • Problema
  • Bug
  • Bug
  • Bug

Gerenciamento de problemas e riscos

  • Problema
  • Problema
  • Impedimento
  • Problema
  • Risco
  • Revisão

Observação

  1. Você pode adicionar esses WITs da lista de pendências do produto ou da placa Kanban. A lista de pendências do produto mostra uma única exibição da lista de pendências atual do trabalho que pode ser reordada e agrupada dinamicamente. Os proprietários de produtos podem priorizar rapidamente o trabalho e estruturar dependências e relações.
    Além disso, cada equipe pode configurar como deseja que os bugs apareçam em suas listas de pendências e quadros.
  2. Com listas de pendências do portfólio, é possível definir uma hierarquia de listas de pendências para entender o escopo do trabalho através de várias equipes e ver como é feito o rollup desse trabalho em iniciativas mais amplas. Cada equipe pode configurar quais listas de pendências de portfólio aparecem para uso.
  3. Você pode definir tarefas da lista de pendências de sprint e do quadro de tarefas. Com o planejamento de capacidade, as equipes podem determinar rapidamente se estão acima ou abaixo da capacidade de um sprint.

Estados, transições e motivos do fluxo de trabalho

Os estados de fluxo de trabalho dão suporte ao acompanhamento do status do trabalho à medida que ele passa de um novo estado para um estado fechado ou concluído. Cada fluxo de trabalho consiste em um conjunto de estados, as transições válidas entre os estados e os motivos para fazer a transição do item de trabalho para o estado selecionado.

Importante

Para Azure DevOps Services e Azure DevOps Server 2019, as transições de fluxo de trabalho padrão dão suporte a qualquer estado para qualquer transição de estado. Você pode personalizar esses fluxos de trabalho para restringir algumas transições. Confira Personalizar objetos de acompanhamento de trabalho para dar suporte aos processos da sua equipe.

Além disso, você pode exibir as transições de fluxo de trabalho com suporte para cada tipo de item de trabalho instalando a extensão State Model Visualization Markeplace. Essa extensão adiciona um novo hub em Placas rotuladas Visualizador de Estado. Nessa página, você pode escolher um tipo de item de trabalho e exibir o modelo de estado do fluxo de trabalho.

Os diagramas a seguir mostram a progressão de encaminhamento típica desses WITs usados para rastrear defeitos de trabalho e código para os três processos padrão. Eles também mostram algumas das regressões para estados anteriores e transições para estados removidos. Cada imagem mostra apenas o motivo padrão associado à transição.

História de usuário

Estados de fluxo de trabalho de história do usuário, processo Agile

Recurso

Estados de fluxo de trabalho de recurso, processo Agile

Épico

Estados de fluxo de trabalho épico, processo Agile

Bug

Estados de fluxo de trabalho de bug, processo Agile

Tarefa

Estados de fluxo de trabalho de tarefa, processo Agile

A maioria dos WITs usados pelas ferramentas Agile, que aparecem em listas de pendências e placas, dão suporte a transições de qualquer para qualquer. Você pode atualizar o status de um item de trabalho usando a placa Kanban ou o quadro de tarefas arrastando-o para a coluna de estado correspondente.

Você pode alterar o fluxo de trabalho para dar suporte a outros estados, transições e motivos. Para saber mais, confira Personalizar sua experiência de acompanhamento de trabalho.

Estados removidos, fechados e concluídos

Quando você altera o estado de um item de trabalho para Removido, Fechado ou Concluído, o sistema responde da seguinte maneira:

  • Fechado ou Concluído: os itens de trabalho nesse estado não aparecem nas páginas de lista de pendências e lista de pendências do portfólio. No entanto, eles aparecem nas páginas de lista de pendências de sprint, quadro Kanban e quadro de tarefas. Além disso, quando você altera a exibição de lista de pendências do portfólio para mostrar itens de lista de pendências, por exemplo, para exibir Recursos para Itens de Lista de Pendências do Produto, os itens de trabalho no estado fechado e concluído são exibidos.
  • Removido: os itens de trabalho nesse estado não aparecem em nenhuma lista de pendências ou quadro.

Os itens de trabalho são mantidos em um projeto, desde que o projeto esteja ativo. Mesmo se você defini-los como Fechado, Concluído ou Removido, um registro será mantido no armazenamento de dados. Você pode usar um registro para criar consultas ou relatórios.

Observação

Os itens de trabalho concluídos ou fechados não são exibidos nas listas de pendências e quadros depois que a Data Alterada for maior que 183 dias (cerca de meio ano). Você ainda pode listar esses itens usando uma consulta. Se você quiser que eles apareçam em uma lista de pendências ou quadros, você pode fazer uma pequena alteração neles, o que redefine o relógio.

Observação

Os itens de trabalho concluídos ou fechados não são exibidos nas listas de pendências e quadros depois que a Data Alterada for maior que um ano. Você ainda pode listar esses itens usando uma consulta. Se você quiser que eles apareçam em uma lista de pendências ou quadros, você pode fazer uma pequena alteração neles, o que redefine o relógio.

Se você precisar excluir permanentemente itens de trabalho, consulte Remover ou excluir itens de trabalho.

Tipos de item de trabalho adicionados a todos os processos

Os WITs a seguir são adicionados a todos os processos, exceto o processo Básico.

Tipos de item de trabalho usados por Test Plans, Gerenciadores de Testes da Microsoft, Meu Trabalho e Comentários

As equipes criam e trabalham com esses tipos usando a ferramenta correspondente:

  • Plano de Teste, Conjunto de Testes, Etapas Compartilhadas de Caso de Teste e Parâmetros Compartilhados: Microsoft Test Manager.
  • Solicitação de Feedback e Resposta de Feedback: Solicitar feedback.
  • Solicitação de Revisão do Código e Resposta de Revisão do Código: Meu Trabalho (do Team Explorer) e Solicitação de Revisão de Código.

Os itens de trabalho dessas definições de tipo não devem ser criados manualmente e, em seguida, adicionados à categoria Tipos Ocultos. Os tipos de item de trabalho adicionados à categoria Tipos Ocultos não aparecem nos menus que criam novos itens de trabalho.

WITs que dão suporte a experiência de teste

WITs que dão suporte à experiência de teste e trabalham com o Gerenciador de Testes e o portal da Web são vinculados usando os tipos de link mostrados na imagem a seguir.

Tipos de item de trabalho de gerenciamento de teste

No portal da Web ou no Gerenciador de Testes da Microsoft, você pode exibir quais casos de teste são definidos para um conjunto de testes. E você pode exibir quais conjuntos de testes são definidos para um plano de teste. No entanto, esses objetos não estão conectados uns aos outros por meio de tipos de link. Personalize esses WITs como faria com qualquer outro WIT. Consulte Personalizar objetos de acompanhamento de trabalho para dar suporte aos processos da sua equipe.

Se você alterar o fluxo de trabalho para o plano de teste e um conjunto de testes, talvez seja necessário atualizar a configuração do processo conforme descrito aqui. Para obter definições de cada campo de teste, consulte Consulta com base em campos de integração de build e teste.

Você pode personalizar um processo antes ou depois de criar um projeto que usa o processo. Os métodos usados dependem do modelo de processo que você usa. Para saber mais, confira Personalizar sua experiência de acompanhamento de trabalho.

Se você tiver mais perguntas, consulte a página de suporte do Azure DevOps.