Compartir a través de

Personalización y herencia de procesos

Azure DevOps Services

Para adaptar el sistema de seguimiento del trabajo de Azure DevOps a las necesidades de su organización, puede personalizar un proceso heredado a través de la configuración de la organización. Todos los proyectos de una organización que usan el proceso heredado obtienen las personalizaciones que realice en ese proceso. Después, puede configurar listados de pendientes, sprints y tableros para cada equipo de proyecto.

Importante

Este artículo solo se aplica al modelo de proceso de herencia en Azure DevOps Services. Para personalizar proyectos locales o actualizar archivos de definición XML, consulte Modelo de proceso XML hospedado y Personalización de un proceso XML hospedado.

Puede realizar varias personalizaciones para los procesos heredados. Los más importantes son crear tipos de elementos de trabajo personalizados (WIT) o modificar los WIT existentes para agregar campos personalizados, modificar diseños o cambiar flujos de trabajo. Algunas opciones de elementos heredados están bloqueadas y no se pueden personalizar.

En este artículo se proporciona información general sobre las formas de personalizar los procesos heredados. Para obtener información sobre los límites de los números de campos, WIT, niveles de trabajo pendiente y otros objetos que puede personalizar, consulte Seguimiento de trabajos , procesos y límites del proyecto.

Nota:

Puede revisar los cambios realizados en un proceso heredado mediante el registro de auditoría y las características de auditoría. Para obtener más información, consulte Acceso, exportación y filtrado de registros de auditoría.

Procesos del sistema y heredados

Los procesos del sistemaAgile, Basic, Scrum y Capability Maturity Model Integration (CMMI) están bloqueados y los usuarios no pueden cambiarlos. Microsoft posee estos procesos del sistema y los actualiza periódicamente.

Los procesos heredados se personalizan de los procesos del sistema y heredan las definiciones del proceso del sistema en los que se basan. Las actualizaciones que Microsoft realiza en los procesos del sistema se actualizan automáticamente en los procesos heredados y sus procesos heredados secundarios.

Todos los proyectos de una organización pueden compartir todos sus procesos. Personaliza el proceso en lugar de personalizar los proyectos únicos.

Una vez creado un proceso heredado, puede personalizarlo, copiarlo, crear proyectos basados en él y cambiar los proyectos existentes para usarlos. Los cambios realizados en el proceso heredado actualizan automáticamente todos los proyectos de la organización que usan ese proceso.

En el ejemplo siguiente se muestra una lista de proyectos de la organización fabrikamprime y el proceso que usa cada proyecto. Para cambiar las personalizaciones del proyecto Fabrikam Fiber , modifique el proceso My Agile , que hereda del proceso del sistema Agile . Los cambios realizados en el proceso Mi agile también actualizan el proyecto Agile por diseño que usa ese proceso. Para personalizar los otros proyectos, tendría que cambiarlos para usar procesos heredados.

Captura de pantalla de los proyectos y los procesos que usan.

Cambiar el proceso de un proyecto existente

Puede cambiar el proceso que un proyecto usa de un proceso a otro. Para obtener más información e instrucciones, consulte los artículos siguientes:

Siguiendo las instrucciones generales de los artículos enumerados, puede realizar otros cambios, como de CMMI a Agile o Agile a CMMI. Antes de cambiar un proceso de proyecto, familiarícese con el proceso al que va a cambiar. Para más información, consulte Acerca de los procesos y las plantillas de proceso.

Al realizar la transición de un proyecto a un proceso diferente, es posible que algunas herramientas o elementos de trabajo existentes no sean válidos. Por ejemplo, los elementos de trabajo que carecen de un campo necesario en el nuevo proceso pueden mostrar errores. Para continuar con los cambios y guardar los elementos de trabajo, debe resolver estos errores. Si el cambio de proceso agrega, quita u oculta los estados de flujo de trabajo de un WIT que aparece en un panel, asegúrese de actualizar las configuraciones de columna de la placa para todos los equipos definidos en el proyecto.

Cambiar o renombrar un proceso heredado

Cambiar un proceso heredado es sencillo, pero es mejor probar los cambios antes de aplicarlos a un proyecto activo. Puede copiar un proceso y, primero, realizar los cambios en el proceso copiado para evitar que afecte a los proyectos existentes y para ayudarle a identificar los efectos negativos de los cambios del proceso.

Puede cambiar el nombre de un proceso heredado en Configuración de la organización seleccionando el icono Más acciones situado junto al nombre del proceso y seleccionando Editar.

Nombres de proceso

Los nombres de proceso tienen los siguientes requisitos:

  • Debe ser único en la organización.
  • Debe tener 128 caracteres Unicode o menos
  • No puede contener ninguno de los siguientes caracteres: .,;':~\/*|?"&%$!+=()[]{}<>

Objetos heredados y personalizados

Cada proceso heredado hereda los Tipos de Elementos de Trabajo (WIT) definidos en el proceso del sistema Básico, Agile, Scrum o CMMI subyacente. Por ejemplo, los procesos que heredan de Agile proporcionan errores, tareas, casos de usuario, características, epopeyas, problemas y WIT relacionados con pruebas.

Puede agregar campos y modificar el formulario de flujo de trabajo y elemento de trabajo para todos los WIT que se muestran en la página Tipos de elementos de trabajo de un proceso heredado. También puede agregar WIT personalizados.

Si no desea que los usuarios creen nuevos elementos de trabajo basados en un WIT de proceso heredado, puede deshabilitarlo seleccionando el icono Más acciones situado junto al nombre WIT en Configuración de la organización y seleccionando Deshabilitar en el menú contextual.

Campos de elementos de trabajo

En esta sección se describen los campos del elemento de trabajo.

Campos y referencias de campo

Los elementos de trabajo se usan para planear y realizar un seguimiento del proyecto. Cada tipo de elemento de trabajo está asociado a 31 campos del sistema y varios campos más específicos del tipo que proporcionan información de seguimiento sobre los elementos de trabajo. Los valores que asigna a un campo se almacenan en el almacén de datos de seguimiento de trabajo, que puede consultar para determinar el estado y las tendencias.

Para obtener descripciones y uso de cada campo definido para los procesos principales del sistema , Scrum, Agile y Capability Maturity Model Integration (CMMI), consulte Índice de campo del elemento de trabajo.

Nombres de campo

Un nombre de campo de elemento de trabajo identifica exclusivamente un campo de elemento de trabajo. Asegúrese de que los nombres de campo cumplen estos requisitos:

  • Debe ser único dentro de la organización o la colección de proyectos.
  • Debe tener 128 o menos caracteres Unicode.
  • Debe contener al menos un carácter alfabético
  • No puede contener espacios iniciales o finales, o dos o más espacios consecutivos
  • No puede contener ninguno de los siguientes caracteres: .,;':~\/*|?"&%$!+=()[]{}<>

Los nombres de campo y las definiciones se aplican a toda la organización. No se puede agregar un campo con un nombre de campo que ya exista en la organización o que otro proceso heredado haya agregado a un WIT.

Personalizaciones de campos

Los campos se definen para todos los proyectos y procesos de una organización. Los procesos heredados heredan los campos definidos en los procesos del sistema y puede realizar modificaciones limitadas en ellos. Puede crear y modificar campos personalizados en procesos heredados.

Puede agregar cualquier campo personalizado que defina para un WIT en un proceso a cualquier WIT definido para otro proceso. También puede agregar un campo existente a otro WIT dentro del mismo proceso. Por ejemplo, puede agregar fecha de vencimiento a los casos de usuario o bugs WITs.

Personalización de campos y controles

Los siguientes recursos describen cómo implementar varias personalizaciones para campos heredados, campos personalizados o controles personalizados.

Campos heredados

Campos personalizados

Control personalizado

Eliminar o restaurar campos eliminados

Puede eliminar un campo y restaurarlo más adelante. Al eliminar un campo, se eliminan todos los datos asociados a ese campo, incluidos los valores históricos. Una vez eliminado, solo puede restaurar el campo y recuperar los datos mediante la API REST Fields - Update .

En lugar de eliminar un campo, puede ocultar o quitar el campo de un formulario de elemento de trabajo. Para obtener más información, vea Mostrar, ocultar o quitar un campo.

Limitaciones

  • No puede cambiar un nombre de campo o un tipo de datos una vez que lo defina. Sin embargo, puede cambiar la etiqueta que aparece para un campo en el formulario de elemento de trabajo desde la pestaña Diseño . Al seleccionar el campo en una consulta, debe usar el nombre del campo y no la etiqueta de campo.
  • No se puede modificar el área gris del formulario que contiene los campos Estado, Motivo, Ruta de acceso del área e Iteración .
  • Las rutas de acceso de área y las listas de selección de rutas de acceso de iteración se configuran para cada proyecto y no se pueden personalizar a través de un proceso heredado.
  • Las listas de selección asociadas a campos de identidad de usuario, como Asignado a y Modificado por, se rellenan en función de los usuarios agregados al proyecto o equipo.
  • Se puede definir un máximo de 64 campos para cada WIT y se puede definir un máximo de 512 campos por proceso.
  • No se puede importar ni definir una lista global como compatible con los modelos de proceso XML hospedado y XML local.

Reglas personalizadas y reglas del sistema

Cada WIT tiene varias reglas del sistema definidas, como requerir el campo Título o establecer un valor predeterminado para el campo Área de valor. Las reglas del sistema también definen las acciones que se deben realizar cuando cambia un estado de flujo de trabajo.

Por ejemplo, varias reglas copian la identidad del usuario actual en el campo Cambiado por cuando se modifica un elemento de trabajo o al campo Cerrado por cuando el estado del flujo de trabajo cambia a Cerrado o Listo. Las reglas del sistema predefinidas tienen prioridad sobre las reglas personalizadas que las sobrescribirían.

Las reglas personalizadas proporcionan compatibilidad con varios casos de uso empresariales, lo que le permite ir más allá de establecer un valor predeterminado para un campo o hacerlo necesario. Las reglas personalizadas permiten borrar el valor de un campo, copiar un valor en un campo o aplicar valores basados en dependencias entre valores de campo diferentes.

Con las reglas personalizadas, puede definir varias acciones en función de condiciones específicas. Por ejemplo, puede aplicar reglas para admitir los escenarios siguientes:

  • Cuando se define un valor para Priority, haga que El riesgo sea un campo obligatorio.
  • Cuando se realiza un cambio en el valor de Release, borre el valor de Hito.
  • Cuando se realiza un cambio en el valor de Trabajo restante, haga que Trabajo completado sea un campo obligatorio.
  • Cuando el valor de Aprobado es True, haga aprobado por un campo obligatorio.
  • Cuando se crea una historia de usuario, haga que los campos Prioridad, Riesgo y Esfuerzo sean obligatorios.

Para obtener más información sobre cómo definir reglas personalizadas, vea Agregar una regla a un tipo de elemento de trabajo (proceso de herencia).

Sugerencia

No se puede definir una fórmula mediante una regla. Sin embargo, puede encontrar una solución que se adapte a sus necesidades con Power Automate. Para obtener más información, consulte Consolidación de trabajo y otros campos.

Restringir la modificación de los campos de selección para grupos de usuarios seleccionados

Mediante el uso de las condiciones current user is a member of a group... o current user is not a member of a group..., puede requerir o configurar campos seleccionados para los usuarios que son miembros o no miembros de un grupo o grupo de seguridad. Por ejemplo, puede hacer que el campo Título o Estado sean de solo lectura para usuarios o grupos seleccionados.

Restricción de la modificación de elementos de trabajo en función de la ruta de acceso del área

Considere la posibilidad de mantener la propiedad única de los elementos de trabajo por ruta de acceso del área de equipo o formalizar columnas con estados personalizados que se comparten entre equipos.

Puede impedir que los usuarios modifiquen los elementos de trabajo seleccionados estableciendo permisos en una ruta de acceso de área. Esta configuración no es una regla, sino una configuración de permisos. Para obtener más información, consulte Crear nodos secundarios, en una ruta de iteración o área modificar elementos de trabajo.

Personalizaciones de tipo de elemento de trabajo

En los siguientes recursos se describen las opciones de personalización para las WIT heredadas y personalizadas.

Tipos de elementos de trabajo heredados

Tipos de elementos de trabajo personalizados

Cambiar el WIT predeterminado de un trabajo pendiente hace que el WIT aparezca de forma predeterminada en el panel de adición rápida. Por ejemplo, Historia Personalizada aparece de forma predeterminada en el siguiente panel de adición rápida para un backlog de producto.

Captura de pantalla del panel de adición rápida con un tipo de elemento de trabajo personalizado predeterminado.

Limitaciones

  • No se puede agregar ni quitar un WIT heredado a ni desde una lista de pendientes.
  • No se puede cambiar la posición de un campo heredado dentro del diseño del formulario. Sin embargo, puede ocultar el campo en un área del formulario y agregarlo en otro lugar del formulario.
  • No puede cambiar el nombre de un WIT personalizado una vez que lo defina.

Personalizaciones de formularios de elemento de trabajo

Puede realizar las siguientes personalizaciones en un formulario WIT:

Grupos heredados

Grupos personalizados

Páginas heredadas

Páginas personalizadas

Diseño y cambio de tamaño

El diseño del formulario web de un elemento de trabajo se organiza en tres columnas, como se muestra en la siguiente imagen.

Ilustración de un diseño de página en tres columnas para el formulario de un elemento de trabajo.

Si solo agrega grupos y campos a las dos primeras columnas, el diseño muestra dos columnas. Si solo agrega grupos y campos a la primera columna, el diseño muestra una columna.

El formulario web cambia de tamaño en función del ancho disponible y del número de columnas del diseño. Al ancho máximo, en la mayoría de los navegadores web, cada columna de una página se muestra en su propia columna. Cuando el ancho de la pantalla no admite todas las columnas, las columnas aparecen apiladas dentro de la columna a la izquierda.

A medida que el ancho de la pantalla disminuye, las columnas cambian el tamaño proporcionalmente de la siguiente manera:

  • Para tres columnas: 50 %, 25 % y 25 %
  • Para dos columnas: 66 % y 33 %
  • Para una columna: 100%

Personalizaciones de flujo de trabajo

Puede personalizar el flujo de trabajo de cualquier tipo de elemento de trabajo (WIT) ocultando estados heredados o agregando estados personalizados. Los estados heredados varían en función del proceso del sistema usado para crear el proceso personalizado: Agile, Basic, Scrum o Capability Maturity Model Integration (CMMI). Para obtener más información, consulte Estados de flujo de trabajo, transiciones y motivos.

El flujo de trabajo predeterminado para cada WIT define entre dos y cuatro estados y especifica las siguientes operaciones de flujo de trabajo:

  • Transiciones hacia delante y hacia atrás entre cada estado. Por ejemplo, el WIT del proceso básico Issue incluye tres estados: Por Hacer, En Progreso y Hecho.
  • Motivos predeterminados para cada transición de estado.

Los flujos de trabajo heredados y personalizados deben cumplir las siguientes reglas:

  • Defina al menos dos estados de flujo de trabajo.
  • Defina al menos un estado para las categorías de estado Propuesto o En Progreso.
  • Defina un máximo de 32 estados de flujo de trabajo por tipo de elemento de trabajo.

Nota:

Antes de agregar un estado de flujo de trabajo personalizado, consulte Acerca de los estados de flujo de trabajo en trabajos pendientes y paneles para obtener información sobre cómo los estados de flujo de trabajo se asignan a categorías.

Para obtener personalizaciones para los estados de flujo de trabajo heredados y personalizados, consulte los siguientes recursos:

Estados heredados

Estados personalizados

Limitaciones

  • No puede cambiar el nombre, el color o la categoría de estados heredados, pero puede ocultarlos si no quiere que estén visibles.
  • No se pueden cambiar los nombres de los estados personalizados una vez definidos.
  • No puede cambiar ni personalizar los nombres de categoría de estado predeterminados.
  • Solo puede existir un estado en la categoría Estado completado . Al agregar un estado personalizado a esta categoría, se quita u oculta cualquier otro estado de esa categoría.
  • No se pueden especificar motivos personalizados para las transiciones de estado. Utilice los motivos predeterminados, como Movido a estado Evaluado y Movido fuera del estado Triaged.
  • No se puede cambiar la ubicación de los campos Estado y Motivo en el formulario de elemento de trabajo.

Personalizaciones de trabajos pendientes y de placa

Los trabajos pendientes y los paneles son herramientas ágiles esenciales para crear y administrar el trabajo de un equipo. El producto estándar, las acumulaciones de iteraciones y de cartera heredadas de los procedimientos del sistema son totalmente personalizables. También puede agregar trabajos pendientes de cartera personalizados hasta un total de cinco trabajos pendientes de cartera.

Para obtener más información sobre cómo personalizar trabajos pendientes de cartera heredados y personalizados, consulte los siguientes recursos:

Trabajos pendientes heredados

Trabajos pendientes de cartera personalizados

Limitaciones

  • No se puede quitar un nivel de cartera heredado de un producto. Puede cambiar el nombre del nivel o deshabilitar las WIT para evitar que los equipos creen nuevos elementos de trabajo de esos tipos.
  • No se puede insertar un nuevo nivel de trabajo pendiente personalizado dentro del conjunto existente de trabajos pendientes definidos. Los niveles de trabajo pendiente predefinidos suelen ser fijos, por ejemplo, Épicas, Funcionalidades, Historias de usuario y Tareas.
  • No se pueden reordenar los niveles de trabajo pendiente. Normalmente siguen una jerarquía predefinida y no se admite cambiar el orden.
  • No se puede agregar un WIT a dos niveles de trabajo pendiente diferentes. Cada WIT solo puede pertenecer a un nivel de trabajo pendiente.
  • No se puede crear un nivel de backlog personalizado específico para tareas, pero todavía puede agregar WITs personalizados al backlog de iteración. Por ejemplo, podría crear un WIT personalizado denominado Mejora o Mantenimiento y asociarlo con el trabajo pendiente de iteración.
  • El WIT de errores no pertenece a ningún nivel de trabajo pendiente específico de forma predeterminada. Cada equipo puede decidir cómo quiere administrar errores. Puede elegir mostrar errores en trabajos pendientes y paneles o controlarlos por separado. Para obtener más información, consulte Mostrar errores en trabajos pendientes.

Contenido relacionado

  • Last updated on