Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Serviços de DevOps do Azure | Azure DevOps Server | Azure DevOps Server 2022
O Azure Boards oferece vários processos para gerir itens de trabalho. Selecionar o processo certo ajuda a otimizar o fluxo de trabalho do seu projeto e prepara a sua equipa para o sucesso. Este artigo descreve os processos disponíveis no Azure Boards e ajuda-o a escolher aquele que se adequa ao seu projeto.
Ao criar um projeto, escolhe-se um processo ou um modelo de processo com base no modelo de processo para o qual a sua organização ou coleção foi criada. Antes de escolher um processo para o seu projeto, você deve entender 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. Apenas um modelo de processo é suportado para um projeto de cada 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. Este modelo suporta a personalização de projetos através de um editor visual no portal web do Azure DevOps. |
| Modelo de processo | Define os blocos de construção do sistema de controle de item 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 controle de trabalho nos processos e modelos de processo padrão são os mesmos. Este artigo resume-as.
Tip
Com o Azure DevOps Server, 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 obter mais informações, consulte Gerenciar processos.
Modelo de processo XML nas instalações:
- Instale ou atualize para a versão mais recente do Azure DevOps Server.
- Descarregue o arquivo comprimido do modelo usando o Process Template Manager. Use uma versão do Visual Studio ao mesmo nível de versão do Azure DevOps Server. Você pode instalar a versão mais recente do Visual Studio Community gratuitamente.
- Aceda aos modelos de processos predefinidos 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, consulte Visão geral dos arquivos de modelo de processo.
Processos padrão
Os processos padrão diferem principalmente nos tipos de itens de trabalho que fornecem para planeamento e acompanhamento do trabalho. Utilize o seguinte guia para escolher o processo que se adequa à sua equipa:
- Escolha Básico para a experiência mais simples - acompanhe o trabalho em Épicos, Itens e Tarefas.
- Escolha Ágil se a sua equipa usar métodos Ágeis e quiser acompanhar as User Stories com atividades separadas de desenvolvimento e teste.
- Escolha Scrum se a sua equipa segue a metodologia Scrum e acompanha os itens do registo de tarefas pendentes do produto e os erros.
- Escolha o CMMI se a sua equipa precisar de gestão formal de mudanças, um registo auditável de decisões e acompanhamento de Requisitos, Pedidos de Mudança, Riscos e Revisões.
Escolha o processo certo
Se não tem a certeza de qual processo se adequa à sua equipa, use os seguintes cenários como ponto de partida:
Determine o processo do seu projeto
Para descobrir qual o processo que o seu projeto utiliza:
- Inicie sessão no seu projeto Azure DevOps.
- Selecione Project Settings>Process.
O nome do processo aparece no topo da página (por exemplo, Agile, Scrum, Basic ou CMMI).
Para mais informações, consulte Gerir projetos.
Escolha o processo certo
Se não tem a certeza de qual processo se adequa à sua equipa, use os seguintes cenários como ponto de partida:
| Scenario | Processo recomendado | Porquê |
|---|---|---|
| És novo no Azure Boards ou queres o acompanhamento mais leve. | Basic | Três tipos de itens de trabalho (Épico, Edição, Tarefa) e um fluxo de trabalho simplesTo Do / Doing / Done. |
| A sua equipa pratica Agile, acompanha as histórias de utilizador e separa o desenvolvimento do trabalho de teste. | Agile | Histórias de utilizador com rastreio de bugs separado; estados mais ricos (New, Active, Resolved, Closed, Removed). |
| A sua equipa pratica Scrum com sprints, itens de backlog de produto e impedimentos. | Scrum | Itens do backlog do produto e bugs no quadro; Approved e Committed e os estados correspondem diretamente às cerimónias do Scrum. |
| Trabalha num ambiente regulado que exige controlo formal de alterações, um registo auditável das decisões e acompanhamento de risco e revisão. | CMMI | Adiciona tipos de itens de Requisitos, Pedidos de Alteração, Risco e Revisão e apoia atividades formais de gestão de mudanças. |
Important
Não podes alterar o processo base de um projeto depois de o projeto estar criado. Pode personalizar um processo herdado para adicionar campos, estados e tipos de itens de trabalho, ou pode criar um novo projeto noutro processo e mover itens de trabalho entre projetos.
Note
Escolher ou personalizar um processo requer a pertença ao grupo Project Collection Administrators. Para obter mais informações, consulte Referência rápida de permissões padrão.
| Process | Hierarquia de itens 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 apoiam o acompanhamento do trabalho que ainda falta. |
|
|
Agile Escolha Agile quando sua equipe usa métodos de planejamento Agile, incluindo Scrum, e rastreia as atividades de desenvolvimento e teste separadamente. Esse processo funciona muito bem para rastrear Histórias de Usuário 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 Agile Alliance. As tarefas suportam o acompanhamento da Estimativa Original, do Trabalho Restante e do Trabalho Concluído. |
|
|
Scrum Escolha o Scrum quando sua equipe praticar o Scrum. Esse processo funciona muito bem para rastrear itens de lista de pendências de produtos e bugs na placa. Você também pode dividir itens da lista de pendências do produto e bugs em tarefas no quadro de tarefas. Este processo suporta a metodologia Scrum definida pela organização Scrum. As tarefas suportam apenas o acompanhamento do Trabalho Restante. |
|
|
CMMI Escolha o CMMI quando sua equipe seguir métodos de projeto mais formais que exigem uma estrutura para melhoria de processos e um registro auditável de decisões. Com esse processo, você pode acompanhar requisitos, solicitações de alteração, riscos e avaliações. Este processo suporta atividades formais de gestão da mudança. As tarefas suportam o 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 as suas listas de pendências ou quadros para um processo
- XML hospedado ou XML local: adicionar listas de pendências de portfólio
Principais distinções entre os processos por defeito
Os processos padrão satisfazem as necessidades da maioria das equipas. 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, personalizar 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 rastreio | Básico | Agile | Scrum | CMMI |
|---|---|---|---|---|
| Estados do fluxo de trabalho | - Fazer - A fazer - Feito |
- Nova - Ativo - Resolvido - Fechado - Removido |
- Nova - Aprovado - Comprometido - Feito - Removido |
- Proposto - Ativo - Resolvido - Fechado |
| Planeamento de produto (ver Nota 1) | - Questão | - História de usuário - Erro (opcional) |
- Item de backlog de produtos - Erro (opcional) |
- Requisito - Erro (opcional) |
| Atrasos de portfólio (ver Nota 2) | - Épico | - Épico - Funcionalidade |
- Épico - Funcionalidade |
- Épico - Funcionalidade |
| Planeamento de tarefas e sprints (ver Nota 3) | - Tarefa | - Tarefa - Erro (opcional) |
- Tarefa - Erro (opcional) |
- Tarefa - Erro (opcional) |
| Gestão do backlog de bugs (ver Nota 1) | - Questão | - Erro (Bug) | - Erro (Bug) | - Erro (Bug) |
| Gestão de questões e risco | - Questão | - Questão | - Impedimento | - Pedido de Alteração - Questão - Risco - Revisão |
Note
- Adicione itens de trabalho da lista de pendências ou do quadro do produto. O backlog de produto mostra uma única vista do backlog atual de trabalho que pode reordenar e agrupar dinamicamente. Os proprietários de produtos podem priorizar o trabalho e descrever dependências e relacionamentos. Cada equipe pode configurar como deseja que os bugs apareçam em suas listas de pendências e quadros.
- Defina uma hierarquia de listas 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 do sprint backlog e do taskboard. Com o planejamento de capacidade, as equipes podem determinar se estão acima ou abaixo da capacidade para um sprint.
Estados, transições e motivos do fluxo de trabalho
Os estados do fluxo de trabalho suportam o acompanhamento do status do trabalho à medida que ele se move de um New estado para um Closed ou um Done estado. Cada fluxo de trabalho consiste em um conjunto de estados, as transições válidas entre os estados e os motivos para a transição do item de trabalho para o estado selecionado.
Important
Transições de fluxo de trabalho: Os fluxos de trabalho padrão no Azure DevOps suportam transições de qualquer 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.
Visualizar fluxos de trabalho: Para exibir as transições de fluxo de trabalho suportadas para cada tipo de item de trabalho, instale a extensão State Model Visualization Marketplace. Esta extensão adiciona um hub do Visualizador de Estado em Painéis , onde você pode selecionar um tipo de item de trabalho e exibir seu modelo completo de estado do fluxo de trabalho.
Os diagramas seguintes mostram a progressão típica desses tipos de item de trabalho usados para rastrear defeitos de trabalho e de 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
Feature
Epic
Bug
Task
A maioria dos tipos de itens de trabalho utilizadas nas ferramentas Agile, que aparecem em listas de pendências e quadros, suporta transições entre quaisquer tipos. Atualize o status de um item de trabalho usando o quadro ou o quadro de tarefas. Arraste um item de trabalho para sua 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 Removidos, Fechados e Feitos se comportam em relação aos atrasos
Quando você altera o estado de um item de trabalho para Removed, Closedou Done, o sistema responde da seguinte maneira:
-
ClosedouDone: Os itens de trabalho neste estado não aparecem no backlog do portefólio nem nas páginas de backlog, mas aparecem nas páginas de backlog do sprint, no quadro e no quadro de tarefas. Quando altera a vista do backlog de portefólio para Mostrar itens do backlog — por exemplo, para ver funcionalidades a par dos itens do backlog do produto — também aparecem itens de trabalho nos estadosClosedeDone. -
Removed: Os itens de trabalho neste 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 Removed estado. Para retirar um item de trabalho CMMI do rastreio ativo, defina o seu estado para Closed e escolha uma razão apropriada (por exemplo, Diferido ou Rejeitado). Pode personalizar um processo herdado para adicionar um Removed estado, se a sua equipa precisar de o fazer.
Seu projeto mantém itens de trabalho enquanto o projeto estiver ativo. Mesmo se você definir itens de trabalho como Closed, Doneou Removed, o armazenamento de dados manterá um registro. Pode usar este registo para criar consultas ou relatórios.
Note
- Os backlogs e os quadros ocultam itens de trabalho concluídos ou encerrados quando a respetiva Data de Alteração tem mais de 183 dias (cerca de seis meses).
- Encontre itens ocultos executando uma consulta.
- Voltar a mostrar um item num backlog ou quadro ao efetuar uma pequena atualização para refrescar a Data de Alteração.
Note
- Os backlogs e os quadros ocultam os itens de trabalho concluídos ou encerrados quando a respetiva Data de Alteração tem mais de um ano.
- Encontre itens ocultos executando uma consulta.
- Voltar a mostrar um item num backlog ou quadro ao efetuar uma pequena atualização para refrescar a Data de Alteração.
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 seguintes tipos de item de trabalho 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. Estes tipos de itens de trabalho permanecem no esquema para compatibilidade histórica. O Microsoft Test Manager e o Team Explorer My Work Experience são ferramentas legadas que foram em grande parte substituídas pelo portal web.
| Tool | Tipos de item de trabalho |
|---|---|
| Microsoft Test Manager (legado) |
Test Plan, Test Suite, Test Case Shared Steps, Shared Parameters |
| Solicitar feedback |
Feedback Request, Feedback Response |
| Meu Trabalho (do Team Explorer, legado), Revisão de Código |
Code Review Request, Code Review Response |
Não podes criar manualmente itens de trabalho a partir destas definições de tipos. São adicionados à Hidden Types categoria. Os tipos de item de trabalho adicionados à Hidden Types categoria não aparecem nos menus que criam novos itens de trabalho.
Tipos de item de trabalho que suportam a experiência de teste
Os tipos de ligação mostrados na imagem seguinte ligam tipos de itens de trabalho que suportam a experiência de teste e funcionam com o Test Manager e o portal web.
No portal web ou no Microsoft Test Manager, pode ver quais os casos de teste definidos para um conjunto de testes e quais os conjuntos 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 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 alterar o fluxo de trabalho do plano de testes e do conjunto de testes, poderá ser 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 em campos de integração de compilação e teste.