Personalizar a experiência de acompanhamento de trabalho

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Ao planejar e acompanhar seu projeto, considere configurar recursos ou personalizar sua experiência para se alinhar aos requisitos de acompanhamento da sua equipe. A abordagem para personalizar projetos, que afeta todas as equipes, depende do modelo de processo que você usa.

Este artigo fornece uma visão geral das personalizações disponíveis e como elas variam entre os três modelos de processo. Para obter diretrizes específicas sobre personalizações para dar suporte a decisões de negócios, consulte Configurar e personalizar os Quadros do Azure. Para obter mais informações, consulte O que é Azure Boards? e Sobre itens de trabalho.

Noções básicas sobre os níveis de personalização

Você pode personalizar o acompanhamento de trabalho nos seguintes níveis:

Impacto e escopo de personalização

Entender o escopo de cada nível de personalização ajuda você a tomar decisões informadas:

Recursos compartilhados no nível do projeto

Cada projeto fornece muitos recursos compartilhados que dão suporte a todas as equipes dentro do projeto. Você configura esses recursos por meio da interface do usuário ou do contexto de administrador do portal da Web.

Principais recursos compartilhados

Os seguintes recursos compartilhados formam a base do acompanhamento de trabalho em seu projeto:

• Caminhos de área: organizar itens de trabalho por área de recurso ou responsabilidade de equipe
• Caminhos de iteração: definir sprints e versões para planejamento e acompanhamento
• Consultas compartilhadas: criar consultas reutilizáveis que todos os membros da equipe podem acessar
• Marcas de item de trabalho: adicionar metadados para categorização e filtragem
• Grupos de segurança: gerenciar permissões de acesso em todo o projeto

Para obter mais informações, consulte os seguintes artigos:

• Sobre caminhos de área e iteração
• Definir caminhos de área
• Alterar a lista de opções para um caminho de iteração
• Criar e editar consultas
• Adicionar marcas a itens de trabalho

Práticas recomendadas para recursos compartilhados

• Planejar caminhos de área antecipadamente: desenhe a estrutura de caminhos de área para refletir a propriedade da equipe e a organização do produto
• Estabelecer cadência de iteração: configurar comprimentos de sprint consistentes e agendamentos de lançamento
• Criar estrutura de pastas: organizar consultas compartilhadas em pastas para obter melhor capacidade de descoberta
• Usar marcas descritivas: estabelecer convenções de marcação para metadados consistentes
• Examinar permissões regularmente: garantir os níveis de acesso apropriados para todos os membros da equipe

Seletor de pessoas e campos de identidade

O recurso seletor de pessoas dá suporte a campos de identidade em todo o Azure DevOps:

• O campo Atribuído a e outros campos Identidade usam o recurso selecionador de pessoas.
• Ativação: quando você escolhe o campo Atribuído a dentro de um formulário de item de trabalho, o seletor de pessoas é ativado automaticamente.
• Seleção do usuário: para selecionar um usuário, comece a inserir seu nome e pesquisar até encontrar uma correspondência.
• Seleções recentes: os usuários selecionados anteriormente aparecem automaticamente na lista para acesso rápido.
• Integração de diretório: para organizações que usam a ID do Microsoft Entra ou o Active Directory, os seletores de pessoas permitem pesquisar todos os usuários e grupos adicionados ao diretório (não apenas os adicionados a um projeto específico).
• Limitação de escopo: Para limitar o escopo das identidades disponíveis para seleção aos usuários do projeto, use o grupo Usuários de Escopo do Projeto.
• Restrições personalizadas: as regras personalizadas podem restringir ainda mais os valores disponíveis para campos de identidade em um item de trabalho.

Configuração do campo de identidade

Você pode configurar campos de identidade de várias maneiras:

• Usuários com escopo no projeto: Restringir a seleção de identidade somente aos membros do projeto
• Regras personalizadas: implementar regras de negócios que restringem valores de campo
• Restrições baseadas em grupo: usar grupos do Azure AD para controlar identidades disponíveis
• Permissões em nível de campo: definir quem pode modificar campos de identidade

Para obter mais informações, consulte os seguintes artigos:

• Adicione usuários ou grupos do Active Directory / Microsoft Entra a um grupo de segurança interno.

Seu projeto define os tipos de item de trabalho (WITs) disponíveis para acompanhar o trabalho e configura ferramentas Agile. Ele especifica histórias de usuários, tarefas, bugs e os campos de dados usados para capturar informações. Os objetos personalizados são compartilhados entre as equipes dentro do projeto.

Comparação de modelo de processo

A tabela a seguir resume as diferenças entre os três modelos de processo com suporte. Para obter definições dos principais objetos de acompanhamento de trabalho, consulte Glossário ágil. Para obter links para artigos de personalização, consulte Índice de referência rápida para configurações de Azure Boards.

Diretrizes de seleção do modelo de processo

Escolha seu modelo de processo com base nas necessidades da sua organização:

Modelo de processo de herança (recomendado)

• Melhor para: Equipes que desejam personalização intuitiva baseada na Web
• Vantagens: edição WYSIWYG, atualizações automáticas, manutenção fácil
• Use quando: É necessário personalizar de forma moderada, com mínima complexidade

Modelo de processo XML hospedado

• Melhor para: Organizações com requisitos de processo complexos
• Vantagens: controle de modelo de processo completo, personalização abrangente
• Use quando: Você precisa de personalização avançada do processo, mas deseja hospedar na nuvem

Modelo de processo XML interno

• Melhor para: implantações locais com requisitos de controle total
• Vantagens: flexibilidade de personalização completa, integração empresarial
• Use quando: Você precisa de controle máximo e executa a infraestrutura local

Observações:

1. Um processo determina os blocos de construção usados para rastrear o trabalho. Um modelo de processo especifica um conjunto relacionado a interdependentes de arquivos de definição XML que fornecem os blocos de construção e a configuração inicial para rastrear o trabalho e outras áreas funcionais.
2. A personalização de XML hospedado dá suporte à adição e atualização de listas globais com uma atualização de processo (sujeito a limites no tamanho máximo de cada lista). Para obter mais informações, consulte Limites de objeto de acompanhamento de trabalho.
3. O modelo de processo herdado não dá suporte à personalização dos seguintes recursos disponíveis com a personalização de modelos de processo. Em vez disso, você personaliza essas áreas no portal da Web projeto por projeto.
   • Caminhos de área e iteração
   • Consultas de item de trabalho
   • Grupos de segurança e permissões
   • Permissões e acesso a áreas funcionais, como controle de versão e compilação
   Ou você pode usar APIs REST.
   Ou você pode usar APIs REST ou a ferramenta de comando da CLI do Azure DevOps.
4. Use a API REST para importar e exportar modelos de processo.

Personalizar a experiência de teste

Vários tipos de item de trabalho dão suporte à experiência de teste no portal da Web, nas páginas de teste e no cliente do Test Manager.

Personalização do processo de herança

Para um processo herdado, você pode personalizar os seguintes tipos de item de trabalho como faria com qualquer outro tipo de item de trabalho:

• Plano de Teste: Organizar e gerenciar conjuntos de testes
• Test Suite: Casos de teste relacionados ao grupo
• Caso de teste: definir cenários de teste individuais

Personalização XML no local

Para um processo XML local, você pode personalizar todos os tipos de item de trabalho relacionados ao teste, incluindo:

• Plano de Teste: organização de teste de alto nível
• Test Suite: agrupamentos de casos de teste
• Caso de teste: definições de teste individuais
• Etapas Compartilhadas: Procedimentos de teste reutilizáveis
• Parâmetros compartilhados: dados de teste parametrizados

Testar relações de item de trabalho

O exemplo a seguir mostra as relações de link suportadas entre tipos de item de trabalho de teste.

Testar cenários de personalização

As personalizações comuns da experiência de teste incluem:

• Campos de teste personalizados: adicionar metadados de teste específicos da organização
• Estados de fluxo de trabalho de teste: definir estados de execução de teste personalizados
• Acompanhamento de resultados do teste: personalizar o relatório de resultados do teste
• Campos de integração: conectar testes com requisitos e defeitos

Personalizações menos comuns

Você só pode executar as seguintes personalizações ao trabalhar com os modelos de processo XML hospedado ou XML local. As personalizações feitas na configuração do processo se aplicam a todas as equipes em um projeto.

Limites de lista de pendências e placa (XML hospedado, XML local)

Para limitar o tempo de carregamento de exibição a parâmetros aceitáveis, o painel de tarefas é restrito a um máximo de 1.000 itens de trabalho. Para obter detalhes, consulte Referência de elemento XML de configuração de processo.

Você pode aumentar esse valor até um máximo de 1500 especificando um valor para o workItemCountLimit atributo do elemento TaskBacklog . Para obter detalhes, consulte Referência de elemento XML de configuração de processo.

<TaskBacklog category="Microsoft.TaskCategory" pluralName="Tasks" singularName="Task" workItemCountLimit="800" >
    . . .
</TaskBacklog>

Considerações de performance para limites de placas

Ao personalizar os limites da placa, considere:

• Impacto no tempo de carga: limites mais altos podem aumentar os tempos de carga da página
• Experiência do usuário: balancear a funcionalidade com o desempenho
• Limitações do navegador: alguns navegadores lidam com grandes conjuntos de dados de forma diferente
• Largura de banda de rede: considere os membros da equipe com conexões mais lentas

Alterar atribuições de campo (XML hospedado, XML local)

Você pode alterar os campos dos itens de trabalho que o sistema usa no cálculo de capacidade, gráficos de burndown, planejamento e velocidade. Qualquer alteração feita em uma das atribuições padrão deve corresponder a uma alteração feita no WIT usado para definir e capturar informações para esse valor.

Por exemplo, se você alterar o refname atribuído a type="Activity" , deverá incluir o mesmo campo na definição de WIT atribuída à Categoria de Tarefa que captura as informações da atividade. Para obter detalhes, consulte Referência de elemento XML de configuração de processo.

Ferramentas que usam atribuições de campo

Os campos atribuídos são usados pelas seguintes ferramentas:

Práticas recomendadas de atribuição de campo

• Manter a consistência: garantir que as atribuições de campo correspondam às definições de tipo de item de trabalho
• Alterações de teste: valide se as ferramentas funcionam corretamente após reatribuções de campo
• Personalizações de documento: registrar alterações de atribuição de campo para referência futura
• Considere o impacto: entenda como as alterações afetam os dados e relatórios existentes

Gerenciar o acesso a ferramentas de rastreamento de trabalho

Você gerencia o acesso a recursos específicos por meio de configurações de permissão. Quando você adiciona contas de usuário à sua equipe, elas são adicionadas automaticamente ao grupo de Colaboradores. Em seguida, eles têm acesso à maioria dos recursos necessários para contribuir com código, acompanhamento de trabalho, builds e testes. No entanto, o grupo Colaboradores não permite que os usuários criem consultas compartilhadas ou adicionem caminhos de área ou iteração. Você precisa conceder essas permissões separadamente.

Estrutura de permissão padrão

O sistema de permissões opera com estes princípios:

• Acesso padrão: novos membros da equipe ingressam automaticamente no grupo Colaborador
• Permissões principais: o grupo Colaborador fornece acesso à maioria dos recursos necessários para o trabalho de desenvolvimento
• Permissões adicionais: alguns recursos exigem concessões de permissão separadas
• Acesso administrativo: os administradores do projeto têm controle total sobre as permissões

Limitações do grupo de colaboradores

O grupo Colaborador não permite automaticamente que os usuários:

• Criar consultas compartilhadas: requer permissões de consulta adicionais
• Adicionar caminhos de área ou iteração: requer permissões administrativas no nível do projeto
• Modificar configurações de segurança: requer acesso administrativo
• Definir configurações de equipe: requer a função de administrador de equipe

Abordagem de gerenciamento de permissões

Para gerenciar efetivamente as permissões:

1. Comece com os padrões: use grupos internos como base
2. Conceder permissões específicas: adicionar permissões para necessidades específicas
3. Usar grupos de segurança: aproveite os grupos do Azure AD para facilitar o gerenciamento
4. Revisões regulares: auditando periodicamente as permissões para adequação
5. Decisões de documento: manter registros de concessões de permissão e lógica

Para obter uma visão geral simplificada das permissões padrão comuns e atribuições de acesso, consulte Permissões e acesso.

Se você não estiver familiarizado com o gerenciamento de permissões, explore Introdução a permissões, acesso e grupos de segurança, herança de permissão e grupos de segurança.

Áreas de permissão específicas

Para gerenciar o acesso a recursos específicos, consulte os seguintes artigos:

Mais opções de personalização

Além dos recursos de personalização internos, considere estas opções adicionais para estender a funcionalidade do Azure DevOps:

Extensões do Marketplace

• Procurar soluções: confira as extensões do Marketplace para ver se há uma ferramenta disponível para suas finalidades
• Categorias populares: procure extensões no acompanhamento de trabalho, relatórios e gerenciamento de projetos
• Contribuições da comunidade: aproveite as soluções desenvolvidas pela comunidade do Azure DevOps

Opções de desenvolvimento personalizadas

• Compilar extensões: Desenvolva sua própria extensão para necessidades organizacionais específicas
• Ferramentas de integração: criar integrações personalizadas usando APIs REST
• Ganchos de serviço: determinar se um gancho de serviço atende às suas necessidades de automação

Cativação da comunidade

• Solicitações de recurso: adicionar uma solicitação de recurso à nossa página da Comunidade de Desenvolvedores
• Comentários do usuário: Compartilhe suas experiências e sugestões com a equipe de produtos
• Práticas recomendadas: aprenda com as abordagens de personalização de outras organizações

Planejando sua estratégia de personalização

Antes de implementar personalizações, considere:

1. Requisitos de negócios: defina claramente o que você deseja alcançar
2. Avaliação de impacto: entenda como as alterações afetam os fluxos de trabalho existentes
3. Sobrecarga de manutenção: considere o custo de longo prazo de manutenção de personalizações
4. Soluções alternativas: avaliar se os recursos existentes atendem às suas necessidades
5. Caminho de migração: Planejar atualizações e migrações futuras

Próximas etapas

Artigos relacionados

• Índice de campos de item de trabalho
• Ferramenta de linha de comando witAdmin
• Gerenciar modelos de processo
• Visão geral dos modelos de processo
• Acompanhamento de trabalho, processo e limites de projeto
• Índice de referência rápida para configurações do Azure Boards