Partilhar via

Acerca da personalização do processo e processos herdados

  • Artigo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Para personalizar o sistema de controle de trabalho, você personaliza um processo herdado por meio da interface administrativa do usuário para a organização. Todos os projetos que usam um processo herdado recebem as personalizações feitas nesse processo. Por outro lado, você configura suas ferramentas Agile — Backlogs, Sprints, quadros e Taskboards — para cada equipe.

Importante

Para personalizar um projeto local ou atualizar arquivos de definição XML para oferecer suporte à personalização, consulte Modelo de processo XML local. Este artigo aplica-se apenas aos Serviços de DevOps do Azure e ao Azure DevOps Server 2019.

Há uma série de personalizações que você pode fazer. Os principais são adicionar tipos de item de trabalho personalizados (WITs) ou modificar um WIT existente para adicionar campos personalizados, modificar o layout ou alterar o fluxo de trabalho.

Nota

Revise as alterações feitas em um processo herdado por meio do log de auditoria. Para obter mais informações, consulte Acesso, exportação e filtro de logs de auditoria.

Abaixo, você encontrará um índice para as tarefas que você pode executar para personalizar um processo herdado. Algumas opções de elementos herdados estão bloqueadas e não podem ser personalizadas.

Sistema versus processos herdados

Você verá dois tipos de processos:

  • ícone bloqueado Processos do sistema — Agile, Basic, Scrum e CMMI — que estão impedidos de serem alterados.
  • ícone herdado Processos herdados, que podem ser personalizados e que herdam definições do processo do sistema a partir do qual foram criados. Os processos do sistema são de propriedade e atualizados periodicamente pela Microsoft. Todas as atualizações feitas em um processo do sistema causam automaticamente uma atualização para seus processos herdados e seus processos herdados filhos. As atualizações dos processos estão documentadas nas Notas de Versão do Servidor de DevOps do Azure.

Nota

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

Além disso, todos os processos são compartilhados. Ou seja, um ou mais projetos podem utilizar um único processo. Em vez de personalizar um único projeto, você personaliza um processo. As alterações feitas no processo atualizam automaticamente todos os projetos que usam esse processo. Depois de criar um processo herdado, você pode personalizá-lo, criar projetos com base nele, fazer uma cópia dele e alterar projetos existentes para usá-lo.

Por exemplo, conforme mostrado na imagem a seguir, você verá uma lista de projetos definidos para a organização fabrikam . A segunda coluna mostra o processo utilizado por cada projeto. Para alterar as personalizações do projeto Fabrikam Fibra , você precisa modificar o processo MyScrum (que herda do processo do sistema Scrum ). Quaisquer alterações feitas no processo MyScrum também atualizam outros projetos que usam esse processo. Você não pode personalizar o projeto de teste Query, por outro lado, até alterá-lo para um processo que herda do Agile.

Captura de ecrã do contexto do administrador, das definições da organização, da lista de projetos e do processo que utilizam.

Restrições de nome de processo

Os nomes de processo devem ser exclusivos e 128 caracteres Unicode ou menos. Além disso, os nomes não podem conter os seguintes caracteres: .,;'`:~\/\*|?"&%$!+=()[]{}<>.

Para renomear um processo, abra o botão ... menu de contexto para o processo e escolha Editar.

Alterar o processo de referência de um projeto

Se você quiser alternar o processo que um projeto usa de um processo de sistema para outro, você pode fazer isso. Para fazer essas alterações, você deve criar um processo herdado com base no processo para o qual deseja alternar. Por exemplo, são fornecidas instruções para suportar as seguintes alterações:

Seguindo as orientações fornecidas nos artigos listados acima, você também pode fazer alterações adicionais, por exemplo, de CMMI para Agile ou Agile para CMMI.

Antes de fazer essa alteração, recomendamos que você se familiarize com o processo para o qual está mudando. Os processos do sistema são resumidos em Sobre processos e modelos de processo.

Práticas recomendadas ao fazer alterações

Fazer alterações em um processo herdado é simples e seguro. No entanto, é sempre uma prática recomendada testar essas alterações antes de aplicá-las a um projeto ativo. Seguir estes passos irá ajudá-lo a revelar quaisquer efeitos negativos que as alterações do seu processo possam ter.

Objetos herdados versus objetos personalizados

Cada processo herdado que você cria herda os WITs definidos no processo do sistema — Basic, Agile, Scrum ou CMMI. Por exemplo, o processo Agile fornece WITs relacionados a bugs, tarefas, histórias de usuários, recursos, épicos, problemas e testes.

Imagem conceitual da hierarquia de itens de trabalho do processo Agile.

Você pode adicionar campos e modificar o fluxo de trabalho e o formulário de item de trabalho para todos os WITs herdados exibidos na página Tipos de Item de Trabalho . Se você não quiser que os usuários criem um WIT, você pode desativá-lo. Além disso, você pode adicionar WITs personalizados.

Personalizações de campo

Os campos definidos no processo do sistema aparecem com um ícone herdado, indicando que você pode fazer modificações limitadas nele no processo herdado.

Os campos são definidos para todos os projetos e processos na organização. Isso significa que qualquer campo personalizado definido para um WIT em um processo pode ser adicionado a qualquer outro WIT definido para outro processo.

Tipo de campo

Suporte à personalização

Campos herdados

Campos personalizados

Controlo personalizado

Ao adicionar campos personalizados, observe os seguintes limites:

  • Um máximo de 64 campos pode ser definido para cada WIT
  • É possível definir um máximo de 512 campos por processo

Além disso, você pode adicionar um campo existente a outro WIT dentro do processo. Por exemplo, você pode adicionar a Data de Vencimento à história do usuário ou aos WITs de bugs.

O que não pode personalizar

  • Não é possível alterar o nome do campo ou o tipo de dados depois de defini-lo
  • Não é possível modificar a área cinza no formulário onde os campos Estado, Motivo, Caminho da Área e Caminho de iteração estão localizados
  • Não é possível importar ou definir uma lista global conforme suportado pelos modelos de processo XML hospedado e XML local. Para obter mais informações, consulte Definir listas globais.
  • Não é possível alterar o nome do campo ou o tipo de dados depois de defini-lo
  • Não é possível modificar a área cinza no formulário onde os campos Estado, Motivo, Caminho da Área e Caminho de iteração estão localizados
  • Com relação às listas de opções, atualmente não é possível executar estas operações:
    • Alterar a lista de opções de um campo herdado, como o campo Atividade ou Disciplina
    • Alterar a ordem da lista de opções, as listas de opções são exibidas em ordem alfabética
  • Não é possível modificar o texto de ajuda Descrição dos campos herdados
  • Importe ou defina uma lista global conforme suportado pelos modelos de processo XML hospedado e XML local. Para obter mais informações, consulte Definir listas globais.

Nota

Com o processo herdado, não é possível modificar as listas de opções de campos predefinidos, como Atividade, Status de automação, Disciplina, Prioridade, entre outros.

Listas de opções configuráveis

As listas de opções a seguir são configuradas para cada projeto e não personalizáveis por meio de um processo herdado.

As listas de opções associadas a campos de nome de pessoa, como Atribuído a e Alterado por, são gerenciadas com base nos usuários que você adiciona a um projeto ou equipe.

Posso renomear um campo ou alterar seu tipo de dados?

Renomear um campo ou alterar o tipo de dados não são ações suportadas. No entanto, você pode alterar o rótulo que aparece para um campo no formulário de item de trabalho na guia Layout. Ao selecionar o campo em uma consulta, você precisa selecionar o nome do campo e não o rótulo do campo.

Posso eliminar ou restaurar um campo eliminado?

Você pode excluir um campo e restaurá-lo posteriormente. A exclusão de um campo exclui todos os dados associados a esse campo, incluindo valores históricos. Uma vez excluído, você só pode restaurar o campo e recuperar os dados usando a API Fields - Update REST.

Em vez de excluir um campo, convém ocultar ou remover o campo de um formulário de item de trabalho. Para obter detalhes, consulte Adicionar e gerenciar campos, Mostrar, ocultar ou remover um campo.

O que é um campo? Como são utilizados os nomes dos campos?

Cada tipo de item de trabalho está associado a 31 campos do sistema e vários outros campos específicos do tipo. Você usa itens de trabalho para planejar e acompanhar seu projeto.

Cada campo suporta o rastreamento de uma informação sobre o trabalho a ser executado. Os valores atribuídos a um campo são armazenados no armazenamento de dados de acompanhamento de trabalho, que pode ser criado consultas para determinar o status e as tendências.

Para obter descrições e o uso de cada campo definido para os processos principais do sistema — processos do sistema Scrum, Agile e CMMI — consulte Índice de campo de item de trabalho.

Nomes de campo

Um nome de campo de item de trabalho identifica exclusivamente cada campo de item de trabalho. Certifique-se de que os nomes dos campos se enquadram nestas diretrizes:

  • Os nomes de campo devem ser exclusivos dentro da organização ou da coleção de projetos
  • Os nomes de campo devem ter 128 ou menos caracteres Unicode
  • Os nomes de campo não podem conter espaços à esquerda ou à direita, nem dois ou mais espaços consecutivos
  • Os nomes dos campos devem conter pelo menos um caractere alfabético
  • Os nomes de campo não podem conter os seguintes caracteres: .,;'`:~\/\*|?"&%$!+=()[]{}<>.

Como todos os campos são definidos para a organização, não é possível adicionar um campo personalizado com o mesmo nome de campo que já existe na organização ou que foi adicionado a um WIT em outro processo herdado.

Nota

Ao fazer a transição de um projeto para um processo herdado, você pode encontrar ferramentas Agile ou itens de trabalho em um estado inválido de acordo com os seguintes exemplos:

  • Se você designar um campo conforme necessário, os itens de trabalho sem esse campo exibirão uma mensagem de erro. Para continuar com mais alterações e salvar o item de trabalho, resolva esses erros.
  • Se você adicionar, remover ou ocultar estados de fluxo de trabalho para um WIT que aparece no quadro, certifique-se de atualizar as configurações de coluna do quadro para todas as equipes definidas no projeto. Além disso, considere manter a propriedade única dos itens de trabalho por caminho da área da equipe ou formalizar colunas com compartilhamento de estados personalizados entre as equipes.

Regras personalizadas e regras do sistema

Cada WIT — bug, tarefa, história de usuário, etc. — tem várias regras de sistema já definidas. Algumas são simples, como tornar o campo Título obrigatório ou definir um padrão para o campo Área de Valor. Além disso, várias regras do sistema definem ações a serem tomadas quando um estado de fluxo de trabalho é alterado.

Por exemplo, existem várias regras para copiar a identidade do usuário atual nas seguintes condições:

  • Quando um item de trabalho é modificado, copie a identidade do usuário para o campo Alterado por
  • Quando o estado do fluxo de trabalho mudar para Fechado ou Concluído, copie a identidade do usuário para o campo Fechado por.

Importante

As regras predefinidas do sistema têm precedente sobre qualquer regra personalizada que você definir que a substituiria.

As regras personalizadas fornecem suporte para vários casos de uso comercial, permitindo que você vá além de definir um valor padrão para um campo ou torná-lo necessário. As regras permitem limpar o valor de um campo, copiar um valor para um campo e aplicar valores com base em dependências entre valores de campos diferentes.

Com uma regra personalizada, você pode definir várias ações com base em condições específicas. Por exemplo, você pode aplicar uma regra para dar suporte a esses tipos de cenários:

  • Quando um valor é definido para Prioridade, torne o Risco um campo obrigatório
  • Quando for feita uma alteração no valor de Release, limpe o valor de "Milestone"
  • Quando uma alteração for feita no valor de Trabalho Restante, torne Trabalho Concluído um campo obrigatório
  • Quando o valor de Aprovado for True, torne Aprovado por um campo obrigatório
  • Quando uma história de usuário for criada, torne obrigatórios os seguintes campos: Prioridade, Risco e Esforço

Gorjeta

Não é possível definir uma fórmula usando uma regra. No entanto, você pode encontrar uma solução que atenda às suas necessidades com a extensão Power Automate ou TFS Aggregator (Web Service) Marketplace. Consulte também Rollup de trabalho e outros campos.

Para obter detalhes sobre como definir regras personalizadas, consulte Avaliação de regras e regras.

Restringir a modificação de campos selecionados para grupos de usuários selecionados

Usando uma das duas condições a seguir, você pode selecionar campos obrigatórios para um usuário de um grupo de segurança ou que não seja membro de um grupo de segurança.

  • current user is a member of a group...
  • current user is not a member of a group...

Por exemplo, você pode tornar o campo Título ou Estado somente leitura para usuários ou grupos selecionados.

Restringir a modificação de itens de trabalho com base no Caminho da Área

Você pode impedir que os usuários modifiquem itens de trabalho selecionados definindo permissões em um caminho de área. Esta não é uma configuração de regra, mas uma configuração de permissão. Para obter mais informações, consulte Criar nós filho, modificar itens de trabalho em um caminho de área.

Personalizações do tipo de item de trabalho (WIT)

Aqui estão suas opções de personalização para WITs herdados e personalizados.

Tipo de item de trabalho

Suporte à personalização

Tipos de item de trabalho herdados

Tipos de item de trabalho personalizados

O que não pode personalizar

  • Não é possível adicionar ou remover um WIT herdado de ou para uma lista de pendências
  • Não é possível alterar a posição de um campo herdado no layout do formulário (no entanto, você pode ocultar o campo em uma área do formulário e adicioná-lo em outro lugar do formulário)
  • Não é possível remover o nível de portfólio herdado do produto (mas você pode renomeá-los)
  • Não é possível alterar o nome de um WIT personalizado.

Personalizações de formulário de item de trabalho

Você pode fazer as seguintes personalizações em um formulário WIT.

Tipo de grupo ou página

Suporte à personalização

Grupos herdados

Grupos personalizados

Páginas herdadas

Páginas personalizadas

Layout e redimensionamento

O layout do formulário da Web é organizado em três colunas, conforme mostrado na imagem abaixo.

Ilustração do layout de página de 3 colunas para o formulário de item de trabalho.

Se você adicionar apenas grupos e campos às duas primeiras colunas, o layout refletirá um layout de duas colunas. Da mesma forma, se você adicionar apenas grupos e campos à primeira coluna, o layout refletirá um layout de uma coluna.

O formulário da Web é redimensionado dependendo da largura disponível e do número de colunas no layout. Na largura máxima, na maioria dos navegadores da Web, cada coluna dentro de uma página é exibida dentro de sua própria coluna. À medida que a largura do ecrã diminui, cada coluna é redimensionada proporcionalmente da seguinte forma:

  • Para três colunas: 50%, 25% e 25%
  • Para duas colunas: 66% e 33%
  • Para uma coluna: 100%.

Quando a largura da exibição não acomoda todas as colunas, as colunas aparecem empilhadas dentro da coluna à esquerda.

Personalizações de fluxo de trabalho

Você pode personalizar o fluxo de trabalho de qualquer tipo de item de trabalho (WIT) ocultando estados herdados ou adicionando estados personalizados. Os estados herdados variam de acordo com o processo do sistema selecionado para criar o processo personalizado. As opções são Agile, Basic, Scrum ou Capability Maturity Model Integration (CMMI). Para obter mais informações, consulte Estados do fluxo de trabalho, transições e motivos.

Cada fluxo de trabalho padrão para cada WIT define entre dois e quatro estados e especifica as seguintes operações de fluxo de trabalho:

  • Transições para frente e para trás entre cada estado. Por exemplo, o processo básico Issue WIT inclui três estados: Fazer, Fazer e Concluído.
  • Razões padrão para cada transição de estado

Tipos de estado

Personalizações suportadas

Estados herdados

Estados personalizados

Os estados do fluxo de trabalho devem estar em conformidade com as seguintes regras

  • Defina pelo menos um estado para as categorias Estado proposto ou Em andamento .

    Nota

    Antes de adicionar um estado de fluxo de trabalho, consulte Sobre estados de fluxo de trabalho em listas de pendências e quadros para saber como os estados do fluxo de trabalho são mapeados para categorias de estado.

  • Defina pelo menos dois Estados do fluxo de trabalho.
  • Defina um máximo de 32 Estados de fluxo de trabalho por tipo de item de trabalho.

Personalizações de fluxo de trabalho sem suporte

  • Oculte estados herdados se não quiser que eles fiquem visíveis (não é possível alterar o nome, a cor ou a categoria deles).
  • Verifique se existe apenas um estado na categoria Estado concluído . Adicionar um estado personalizado a esta categoria remove ou oculta qualquer outro estado.
  • Mantenha o nome dos estados personalizados como está; você não pode alterá-los.
  • Use motivos padrão para transições de estado, como Movido para o estado Triaged e Movido para fora do estado Triaged; não é possível especificar motivos personalizados.
  • Aceitar a localização predefinida dos campos Estado e Razão no formulário; não é possível alterar o posicionamento deles.
  • Use os nomes de categoria de estado padrão; não é possível personalizá-los.
  • Oculte estados herdados se não quiser que eles fiquem visíveis (não é possível alterar o nome, a cor ou a categoria deles).
  • Verifique se existe apenas um estado na categoria Estado concluído , o sistema não permite adicionar qualquer estado personalizado a essa categoria.
  • Mantenha o nome dos estados personalizados como está; você não pode alterá-los.
  • Aceitar a sequência natural de estados na lista suspensa no formulário de item de trabalho; você não pode alterar a ordem deles.
  • Use motivos padrão para transições de estado, como Movido para o estado Triaged e Movido para fora do estado Triaged; não é possível especificar motivos personalizados.
  • Aceitar a localização predefinida dos campos Estado e Razão no formulário; não é possível alterar o posicionamento deles.
  • Permitir transições de qualquer estado para outro; Não é possível restringir as transições.

Personalizações de backlog e board

Backlogs e quadros são ferramentas ágeis essenciais para criar e gerenciar o trabalho de uma equipe. Os registos de tarefas pendentes padrão (produto, iteração e portefólio) herdados dos processos do sistema são totalmente personalizáveis. Além disso, pode adicionar registos de tarefas pendentes de portefólios personalizados, até um total de cinco registos de tarefas pendentes de portefólios.

Tipos de lista de pendências

Suporte à personalização

Atrasos herdados

Listas de pendências de portfólio personalizadas

Personalizações sem suporte:

  • Removendo um nível de portfólio herdado:
    • Embora não seja possível remover diretamente um nível de portfólio herdado de um produto, você tem algumas opções:
      • Renomeie o nível de portfólio: você pode renomear o nível de portfólio herdado para melhor atender às suas necessidades.
      • Desativar um WIT herdado: se o nível de portfólio herdado incluir WITs que você não deseja usar, você pode desativá-los. Essa ação impede que as equipes criem novos itens de trabalho desses tipos.
  • Inserindo um nível de lista de pendências:
    • Não é possível inserir um novo nível de lista de pendências dentro do conjunto existente de listas de pendências definidas. Os níveis de lista de pendências predefinidos geralmente são fixos (por exemplo, Épicos, Recursos, Histórias de usuário, Tarefas) e você não pode adicionar outros personalizados entre eles.
  • Reordenar os níveis da lista de pendências:
    • Infelizmente, não é possível reordenar os níveis da lista de pendências. Eles geralmente seguem uma hierarquia predefinida, e a alteração de sua ordem não é suportada.
  • Adicionando um WIT a vários níveis de lista de pendências:
    • Cada WIT só pode pertencer a um nível de lista de pendências. Não é possível adicionar um WIT a dois níveis diferentes de lista de pendências simultaneamente.
  • Criando um nível de lista de pendências de tarefas personalizadas:
    • Embora não seja possível criar um nível de lista de pendências personalizado específico da tarefa, você ainda pode adicionar WITs personalizados à lista de pendências de iteração. Por exemplo, você pode criar um WIT personalizado chamado "Aprimoramento" ou "Manutenção" e associá-lo à lista de pendências de iteração.
  • Gerenciando bugs:
  • Adicionando ou removendo um WIT herdado de uma lista de pendências:
    • Não é possível adicionar ou remover diretamente um WIT herdado de ou para uma lista de pendências. Por exemplo, adicionar o WIT "Problema" à lista de pendências do produto não é suportado.
    • No entanto, pode:
      • Renomeie o nível de portfólio: se o nível de portfólio herdado incluir WITs que você não deseja usar, considere renomeá-lo para melhor atender às suas necessidades.
      • Desativar um WIT herdado: se houver WITs herdados que você deseja excluir, você pode desativá-los. Essa ação impede que as equipes criem novos itens de trabalho desses tipos.
  • Removendo um nível de portfólio herdado:
    • Embora não seja possível remover um nível de portfólio herdado de um produto, você tem algumas opções:
      • Renomeie o nível do portfólio: dê-lhe um nome mais adequado.
      • Desativar WITs herdados: impeça que as equipes usem WITs herdados específicos.
  • Inserindo um nível de lista de pendências:
    • Infelizmente, não é possível inserir um novo nível de lista de pendências dentro do conjunto existente de listas de pendências definidas. Os níveis de lista de pendências predefinidos permanecem fixos (por exemplo, Épicos, Recursos, Histórias de usuários, Tarefas).
  • Reordenar os níveis da lista de pendências:
    • Os níveis de lista de pendências normalmente seguem uma hierarquia predefinida e não há suporte para alterar sua ordem. Não é possível reordená-los.
  • Adicionando um WIT a vários níveis de lista de pendências:
    • Cada WIT (por exemplo, Bug, Tarefa, User Story) só pode pertencer a um nível de lista de pendências. Não é possível adicionar um WIT a dois níveis diferentes de lista de pendências simultaneamente.
  • Criando um nível de tarefa personalizado:
    • Embora não seja possível criar um nível de lista de pendências personalizado específico da tarefa, você ainda pode adicionar WITs personalizados à lista de pendências de iteração. Por exemplo, crie um WIT personalizado chamado "Aprimoramento" ou "Manutenção" e associe-o à lista de pendências de iteração.
  • Gerenciando bugs:

Nota

Alguns recursos exigem a instalação da atualização do Azure DevOps Server 2020.1. Para obter mais informações, consulte Azure DevOps Server 2020 Update 1 RC1 Release Notes, Boards.

Quando você altera o WIT padrão para um nível de lista de pendências, isso faz com que esse WIT apareça por padrão no painel de adição rápida. Por exemplo, o Ticket do Cliente aparece por padrão no seguinte painel de adição rápida para a lista de pendências do produto.

Captura de tela da lista de pendências do produto, painel Adicionar rápido, exibe WIT padrão para um nível de lista de pendências

Limites de objetos

Para obter uma lista de limites colocados no número de campos, WITs, níveis de lista de pendências e outros objetos que você pode personalizar, consulte Limites de objetos de controle de trabalho.