Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Serviços do Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
Azure Boards oferece vários processos para gerenciar itens de trabalho. Selecionar o processo certo ajuda a otimizar o fluxo de trabalho do projeto e configura sua equipe para o sucesso. Este artigo descreve os processos disponíveis no Azure Boards e ajuda você a escolher aquele que se ajusta ao seu projeto.
Ao criar um projeto, você escolhe um processo ou modelo de processo com base no modelo de processo no qual sua organização ou coleção foi criada. Antes de escolher um processo para seu projeto, entenda os seguintes termos.
| Term | Description |
|---|---|
| Modelo de processo | Refere-se ao modelo usado para dar suporte a projetos criados para uma organização ou coleção de projetos. Há suporte para apenas um modelo de processo para um projeto por vez. |
| Process | 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 um editor visual no portal da Web Azure DevOps. |
| 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ê pode personalizar projetos modificando e importando arquivos de definição XML de modelo de processo. |
Os tipos de processo padrão são Basic, Agile, Capability Maturity Model Integration (CMMI) e Scrum. Os objetos de acompanhamento de trabalho nos processos padrão e modelos de processo são os mesmos. Este artigo os resume.
Tip
Com o Servidor do Azure DevOps, você pode selecionar o modelo de processo herdado ou o modelo de processo XML local. Para obter mais informações, consulte Escolher o modelo de processo para sua coleção de projetos. Para acessar as versões mais recentes dos processos ou modelos de processo padrão:
Modelo de processo herdado: abra a página Processos. Para saber mais, confira Gerenciar processos.
Modelo de processo XML local:
- Instale ou atualize para a versão mais recente do Azure DevOps Server.
- Baixe o arquivo de modelo compactado usando o Gerenciador de Modelos de Processo. Use uma versão do Visual Studio no mesmo nível de versão do Azure DevOps Server. Você pode instalar a versão mais recente do Visual Studio Community gratuitamente.
- Acesse os modelos de processo padrão mais recentes instalados no Azure DevOps Server, por exemplo:
%programfiles%/Azure DevOps Server 2020/Tools/Deploy/ProcessTemplateManagerFiles/1033. Para obter descrições de cada arquivo e pasta, confira Visão geral dos arquivos de modelo de processo.
Processos padrão
Os processos padrão diferem principalmente nos tipos de item de trabalho que eles fornecem para o trabalho de planejamento e acompanhamento. Use o seguinte guia para escolher o processo que se ajusta à sua equipe:
- Escolha Básico para ter a experiência mais simples — acompanhe o trabalho como Épicos, Itens e Tarefas.
- Escolha Agile se sua equipe usa métodos Agile e você deseja acompanhar o User Stories com atividades de desenvolvimento e teste separadas.
- Escolha Scrum se sua equipe usa Scrum e acompanha itens do backlog do produto e bugs.
- Escolha CMMI se sua equipe precisar de gerenciamento formal de alterações, um registro auditável de decisões e acompanhamento de Requisitos, Solicitações de Alteração, Riscos e Revisões.
Escolher o processo certo
Se você não tiver certeza de qual processo se encaixa em sua equipe, use os seguintes cenários como ponto de partida:
Determinar o processo do projeto
Para localizar qual processo seu projeto usa:
- Entre em seu projeto de Azure DevOps.
- Selecione Configurações do projeto>Processo.
O nome do processo aparece na parte superior da página (por exemplo, Agile, Scrum, Basic ou CMMI).
Para obter mais informações, consulte Gerenciar projetos.
Escolher o processo certo
Se você não tiver certeza de qual processo se encaixa em sua equipe, use os seguintes cenários como ponto de partida:
| Scenario | Processo recomendado | Por que |
|---|---|---|
| É a sua primeira vez no Azure Boards ou você quer o rastreamento mais simples. | Basic | Três tipos de item de trabalho (Epic, Issue, Task) e um fluxo de trabalho simplesTo Do / Doing / Done. |
| Sua equipe pratica o Agile, acompanha as histórias do usuário e separa o desenvolvimento do trabalho de teste. | Agile | Histórias de usuário com rastreamento separado de bugs; status mais detalhados (New, Active, Resolved, Closed, Removed). |
| Sua equipe pratica o Scrum com sprints, itens de backlog do produto e impedimentos. | Scrum | Itens do Backlog do Produto e bugs no quadro; os estados Approved e Committed correspondem diretamente às cerimônias do Scrum. |
| Você trabalha em um ambiente regulamentado que requer controle de alteração formal, um registro auditável de decisões e controle de risco e revisão. | CMMI | Adiciona tipos de item de trabalho Requisito, Solicitação de Alteração, Risco e Revisão e dá suporte a atividades formais de gerenciamento de alterações. |
Important
Você não pode alterar o processo base de um projeto depois que o projeto é criado. Você pode personalizar um processo herdado para adicionar campos, estados e tipos de item de trabalho ou criar um novo projeto em um processo diferente e mover itens de trabalho entre projetos.
Note
Escolher ou personalizar um processo requer associação no grupo administradores de coleção Project. Para obter mais informações, consulte referência rápida de permissões padrão.
| Process | Hierarquia do item de trabalho |
|---|---|
|
Basic Escolha Básico quando sua equipe quiser o modelo mais simples que usa os tipos de item de trabalho Problema, Tarefa e Épico para acompanhar o trabalho. As tarefas dão suporte ao acompanhamento do Trabalho Restante. |
|
|
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 para rastrear Histórias de Usuários e, opcionalmente, bugs no quadro. Você também pode rastrear bugs e tarefas no quadro de tarefas. Para obter mais informações sobre metodologias ágeis, consulte a Agile Alliance. As tarefas dão suporte ao acompanhamento da Estimativa Original, do Trabalho Restante e do Trabalho Concluído. |
|
|
Scrum Escolha Scrum quando sua equipe praticar o Scrum. Esse processo funciona muito bem para acompanhar itens da lista de pendências do produto e bugs no quadro. Você também pode dividir itens e bugs da lista de pendências do produto em tarefas no quadro de tarefas. Esse processo dá suporte à metodologia Scrum, conforme definido pela organização Scrum. As tarefas dão suporte somente ao acompanhamento do trabalho restante. |
|
|
CMMI Escolha CMMI quando a equipe seguir métodos mais formais do projeto que exigem uma estrutura para aperfeiçoamento de processos e um registro auditável das 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. |
|
Se você precisar de mais de dois ou três níveis de lista de pendências, adicione mais com base no modelo de processo usado:
- Herança: personalize suas listas de pendências ou quadros para um processo
- XML hospedado ou XML local: Adicionar listas de pendências do portfólio
Principais distinções entre os processos padrão
Os processos padrão atendem às necessidades da maioria das equipes. Se sua equipe tiver necessidades incomuns e se conectar a um servidor local, personalize um processo e crie o projeto. Você também pode criar um projeto a partir de um processo e, em seguida, personalize o projeto.
A tabela a seguir resume as principais distinções entre os tipos de item de trabalho e os estados usados pelos quatro processos padrão.
| Área de rastreamento | Básico | Agile | Scrum | CMMI |
|---|---|---|---|---|
| Estados de fluxo de trabalho | - A fazer - Fazendo -Feito |
- Novo - Ativo - Resolvido(a) - Fechado -Removido |
- Novo -Aprovado - Confirmado -Feito -Removido |
- Proposto - Ativo - Resolvido(a) - Fechado |
| Planejamento do produto (consulte a Observação 1) | - Problema | – História do Usuário - Bug (opcional) |
- Item de backlog do produto - Bug (opcional) |
-Exigência - Bug (opcional) |
| Pendências de portfólio (consulte a Observação 2) | - Épico | - Épico -Recurso |
- Épico -Recurso |
- Épico -Recurso |
| Planejamento de tarefas e sprint (consulte a Observação 3) | -Tarefa | -Tarefa - Bug (opcional) |
-Tarefa - Bug (opcional) |
-Tarefa - Bug (opcional) |
| Gerenciamento do backlog de bugs (consulte a Nota 1) | - Problema | -Bug | -Bug | -Bug |
| Gerenciamento de problemas e riscos | - Problema | - Problema | -Impedimento | - Solicitação de alteração - Problema -Risco -Revisão |
Note
- Adicione itens de trabalho da lista de pendências de produtos ou do quadro. O backlog de produtos mostra uma exibição única do backlog atual do trabalho que você pode reordenar e agrupar dinamicamente. Os proprietários de produtos podem priorizar o trabalho e delinear dependências e relações. Cada equipe pode configurar como deseja que os bugs apareçam em suas listas de pendências e quadros.
- Defina uma hierarquia de pendências de portfólio para entender o escopo do trabalho em várias equipes e ver como esse trabalho se acumula em iniciativas mais amplas. Cada equipe configura quais listas de pendências de portfólio aparecem para seu uso.
- Defina tarefas a partir da lista de pendências sprint e do quadro de tarefas. Com o planejamento de capacidade, as equipes determinam se estão acima ou abaixo da capacidade de um sprint.
Estados, transições e motivos do fluxo de trabalho
Os estados do fluxo de trabalho dão suporte ao acompanhamento do status do trabalho à medida que ele passa de um estado New para um estado Closed ou Done. Cada fluxo de trabalho consiste em um conjunto de estados, as transições válidas entre estados e os motivos para fazer a transição do item de trabalho para o estado selecionado.
Important
Transições de fluxo de trabalho: Os fluxos de trabalho padrão em Azure DevOps dão suporte a transições de estado para qualquer estado. Você pode personalizar esses fluxos de trabalho para restringir transições específicas com base nos requisitos da sua equipe. Para obter mais informações, consulte Personalizar sua experiência de acompanhamento de trabalho.
Visualizando fluxos de trabalho: Para exibir as transições de fluxo de trabalho com suporte para cada tipo de item de trabalho, instale a extensão do State Model Visualization Marketplace. Essa extensão adiciona um hub do Visualizador de Estado em Quadros, onde você pode selecionar um tipo de item de trabalho e exibir seu modelo de estado de fluxo de trabalho completo.
Os diagramas a seguir mostram a progressão típica dos tipos de item de trabalho usados para rastrear defeitos de trabalho e código nos 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 do usuário
Feature
Epic
Bug
Task
A maioria dos tipos de item de trabalho usados pelas ferramentas Agile, que aparecem em listas de pendências e quadros, dão suporte a transições qualquer para qualquer. Atualize o status de um item de trabalho usando a placa ou o quadro de tarefas. Arraste um item de trabalho para a coluna de estado correspondente.
Altere o fluxo de trabalho para oferecer suporte a outros estados, transições e motivos. Para obter mais informações, consulte Personalizar sua experiência de acompanhamento de trabalho.
Como os estados Removido, Fechado e Concluído se comportam em backlogs
Quando você altera o estado de um item de trabalho para Removed, Closed ou Done, o sistema responde da seguinte maneira:
-
ClosedouDone: os itens de trabalho nesse estado não aparecem em páginas de backlog ou backlog de portfólio, mas aparecem nas páginas de backlog de sprint, quadro e quadro de tarefas. Quando você altera o modo de exibição de backlog do portfólio para Mostrar os itens de backlog, por exemplo, para exibir os recursos ao lado dos itens de backlog do produto, itens de trabalho também são exibidos nos estadosClosedeDone. -
Removed: os itens de trabalho nesse estado não aparecem em nenhuma lista de pendências ou quadro.
Note
O fluxo de trabalho padrão do CMMI não inclui um estado Removed. Para tirar um item de trabalho CMMI do controle ativo, defina seu estado Closed e escolha um motivo apropriado (por exemplo, Adiado ou Rejeitado). Você pode personalizar um processo herdado para adicionar um Removed estado se sua equipe precisar de um.
Seu projeto mantém itens de trabalho enquanto o projeto estiver ativo. Mesmo se você definir os itens de trabalho como Closed, Done ou Removed, o armazenamento de dados manterá um registro. Você pode usar esse registro para criar consultas ou relatórios.
Note
- As listas de pendências e placas ocultam itens de trabalho concluídos ou fechados quando a Data Alterada tiver mais de 183 dias (cerca de seis meses).
- Localize itens ocultos executando uma consulta.
- Exiba um item novamente em um backlog ou quadro fazendo uma pequena alteração para atualizar sua Data de alteração.
Note
- Listas de pendências e placas ocultam itens de trabalho concluídos ou fechados quando a data alterada for maior que um ano.
- Localize itens ocultos executando uma consulta.
- Exiba um item novamente em um backlog ou quadro fazendo uma pequena alteração para atualizar sua Data de alteração.
Se você precisar excluir permanentemente os itens de trabalho, confira Remover ou excluir itens de trabalho.
Tipos de item de trabalho adicionados a todos os processos
Os tipos de item de trabalho a seguir são adicionados a todos os processos, exceto o processo Básico.
Sua equipe pode criar e trabalhar com esses tipos usando a ferramenta correspondente. Esses tipos de item de trabalho permanecem no esquema para compatibilidade histórica. Microsoft Gerenciador de Testes e a experiência do Team Explorer My Work são ferramentas herdadas que são substituídas em grande parte pelo portal da Web.
| Tool | Tipos de item de trabalho |
|---|---|
| Microsoft Test Manager (herdado) |
Test Plan, Test Suite, , Test Case Shared StepsShared Parameters |
| Solicitar comentários |
Feedback Request, Feedback Response |
| Meu Trabalho (do Team Explorer, legado), Revisão de Código |
Code Review Request, Code Review Response |
Você não pode criar manualmente itens de trabalho a partir dessas definições de tipo. Eles são adicionados à Hidden Types categoria. Tipos de item de trabalho adicionados à categoria Hidden Types não aparecem nos menus que criam itens de trabalho.
WIT (Tipos de item de trabalho) que dão suporte à experiência de teste
Os tipos de link mostrados na imagem a seguir conectam tipos de item de trabalho que dão suporte à experiência de teste e funcionam com o Gerenciador de Testes e o portal da Web.
No portal da Web ou Microsoft Gerenciador de Testes, você pode exibir quais casos de teste são definidos para um conjunto de testes e exibir quais conjuntos de testes são definidos para um plano de teste. Porém, esses objetos não estão conectados uns aos outros por meio de tipos de link. Personalize esses tipos de item de trabalho como faria com qualquer outro tipo de item de trabalho. Para obter mais informações, consulte Personalizar sua experiência de acompanhamento de trabalho.
Se você alterar o fluxo de trabalho do plano de teste e do conjunto de testes, talvez seja necessário atualizar a configuração do processo, conforme descrito neste artigo. Para obter definições de cada campo de teste, consulte Criar uma consulta com base nos campos de integração de build e teste.