Acerca de la personalización de procesos y de procesos heredados

  • Artículo

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

Para personalizar el sistema de seguimiento del trabajo, personaliza un proceso heredado a través de la interfaz de usuario administrativa de la organización. Todos los proyectos que usan un proceso heredado obtienen las personalizaciones realizadas en ese proceso. Por otro lado, configura las herramientas ágiles (trabajos pendientes, Sprints, paneles Kanban y Panel de tareas) para cada equipo.

Importante

Para personalizar un proyecto local o actualizar archivos de definición XML para admitir la personalización, consulte Modelo de proceso XML local. Este artículo solo se aplica a Azure DevOps Services y Azure DevOps Server 2019.

Hay una serie de personalizaciones que puede realizar. Los principales agregan tipos de elementos de trabajo personalizados (WIT) o modifican un WIT existente para agregar campos personalizados, modificar el diseño o cambiar el flujo de trabajo.

Nota:

Puede revisar los cambios realizados en un proceso heredado a través del registro de auditoría. Para más información, consulte Acceso, exportación y filtrado de registros de auditoría.

A continuación encontrará un índice para esas tareas que puede realizar para personalizar un proceso heredado. Algunas opciones de elementos heredados están bloqueadas y no se pueden personalizar.

Procesos heredados frente al sistema

Verá dos tipos de procesos:

  • locked icon Procesos del sistema :Agile, Basic, Scrum y CMMI, que están bloqueados para cambiarse.
  • inherited icon Procesos heredados, que se pueden personalizar y que heredan definiciones del proceso del sistema desde el que se crearon. Microsoft posee y actualiza periódicamente los procesos del sistema. Las actualizaciones realizadas en un proceso del sistema provocan automáticamente una actualización de los procesos heredados y sus procesos heredados secundarios. Novedades a los procesos se documentan en Notas de la versión de Azure DevOps Server.

Nota:

El proceso Básico está disponible con la Actualización 1 de Azure DevOps Server 2019 y versiones posteriores.

Además, todos los procesos se comparten. Es decir, uno o varios proyectos pueden usar un único proceso. En lugar de personalizar un solo proyecto, se personaliza un proceso. Los cambios realizados en el proceso actualizan automáticamente todos los proyectos que usan ese proceso. Una vez que haya creado un proceso heredado, puede personalizarlo, crear proyectos basados en él, realizar una copia de él y cambiar los proyectos existentes para usarlos.

Por ejemplo, como se muestra en la imagen siguiente, verá una lista de proyectos definidos para la organización fabrikam . La segunda columna muestra el proceso utilizado por cada proyecto. Para cambiar las personalizaciones del proyecto Fabrikam Fiber , debe modificar el proceso MyScrum (que hereda del proceso del sistema Scrum ). Los cambios realizados en el proceso myScrum también actualizan otros proyectos que usan ese proceso. Por otro lado, no puede personalizar el proyecto de prueba de consulta hasta que lo cambie a un proceso que herede de Agile.

Screenshot of Admin context, Organization settings, Project list and the process they use.

Restricciones de nombre de proceso

Los nombres de proceso deben ser únicos y 128 caracteres Unicode o menos. Además, los nombres no pueden contener los siguientes caracteres: .,;'`:~\/\*|?"&%$!+=()[]{}<>.

Para cambiar el nombre de un proceso, abra ... menú contextual del proceso y elija Editar.

Cambiar el proceso de referencia de un proyecto

Si desea cambiar el proceso que un proyecto usa de un proceso del sistema a otro, puede hacerlo. Para realizar estos cambios, debe crear un proceso heredado basado en el proceso al que desea cambiar. Por ejemplo, se proporcionan instrucciones para admitir los siguientes cambios:

Siguiendo las instrucciones proporcionadas en los artículos mencionados anteriormente, también puede realizar cambios adicionales, por ejemplo, de CMMI a Agile o Agile a CMMI.

Antes de realizar este cambio, se recomienda familiarizarse con el proceso al que va a cambiar. Los procesos del sistema se resumen en Acerca de los procesos y las plantillas de proceso.

Procedimientos recomendados al realizar cambios

Realizar cambios en un proceso heredado es sencillo y seguro. Sin embargo, siempre es recomendable probar esos cambios antes de aplicarlos a un proyecto activo. Seguir estos pasos le ayudará a mostrar cualquier efecto negativo que afecte a los cambios del proceso.

Objetos heredados frente a objetos personalizados

Cada proceso heredado que cree hereda hereda los WIT definidos en el proceso del sistema: Basic, Agile, Scrum o CMMI. Por ejemplo, el proceso de Agile proporciona errores, tareas, caso de usuario, característica, epopeya, problemas y WIT relacionados con pruebas.

Conceptual image of Agile process work item hierarchy.

Puede agregar campos y modificar el formulario de flujo de trabajo y elemento de trabajo para todos los WIT heredados que se muestran en la página Tipos de elementos de trabajo. Si no desea que los usuarios creen un WIT, puede deshabilitarlo. Además, puede agregar WIT personalizados.

Personalizaciones de campos

Los campos definidos en el proceso del sistema aparecen con un icono heredado, lo que indica que puede realizar modificaciones limitadas en él en el proceso heredado.

Los campos se definen para todos los proyectos y procesos de la organización. Esto significa que cualquier campo personalizado que haya definido para un WIT en un proceso se puede agregar a cualquier otro wiT definido para otro proceso.

Tipo de campo

Asistencia para la personalización

Campos heredados

Campos personalizados

Control personalizado

Al agregar campos personalizados, tenga en cuenta los límites siguientes:

  • Se pueden definir hasta 64 campos para cada tipo de elemento de trabajo.
  • Se pueden definir hasta 512 campos por proceso.

Además, puede agregar un campo existente a otro WIT dentro del proceso. Por ejemplo, puede agregar la fecha de vencimiento al caso del usuario o a los WIT de errores.

Lo que no se puede personalizar

  • No se puede cambiar el nombre del campo ni el tipo de datos una vez que lo haya definido.
  • No se puede modificar el área gris en el formulario donde se encuentran los campos Estado, Motivo, Ruta de área y ruta de acceso de iteración.
  • No se puede importar ni definir una lista global como compatible con los modelos de proceso XML hospedado y XML local. Para más información, consulte Definición de listas globales.
  • No se puede cambiar el nombre del campo ni el tipo de datos una vez que lo haya definido.
  • No se puede modificar el área gris en el formulario donde se encuentran los campos Estado, Motivo, Ruta de área y ruta de acceso de iteración.
  • En lo que respecta a las listas de selección, actualmente no puede realizar estas operaciones:
    • Cambiar la lista de selección de un campo heredado, como el campo Actividad o Disciplina
    • Cambiar el orden de la lista de selección, las listas de selección se muestran en orden alfabético
  • No se puede modificar el texto de ayuda descripción de los campos heredados.
  • Importe o defina una lista global compatible con los modelos de proceso XML hospedado y XML local. Para más información, consulte Definición de listas globales.

Nota:

Con el proceso heredado, no se pueden modificar las listas de selección de campos predefinidos, como Actividad, Estado de automatización, Disciplina, Prioridad, además de otros.

Listas de selección configurables

Las siguientes listas de selección están configuradas para cada proyecto y no se pueden personalizar a través de un proceso heredado.

Las listas de selección asociadas a campos de nombre de persona, como Asignado a y Modificado por, se administran en función de los usuarios que agregue a un proyecto o equipo.

¿Puedo cambiar el nombre de un campo o cambiar su tipo de datos?

El cambio de nombre de un campo o el cambio del tipo de datos no son acciones admitidas. 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 seleccionar el nombre del campo y no la etiqueta de campo.

¿Puedo eliminar o restaurar un campo eliminado?

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, es posible que desee ocultar o quitar el campo de un formulario de elemento de trabajo. Para obtener más información, consulte Agregar y administrar campos, Mostrar, ocultar o quitar un campo.

¿Qué es un campo? ¿Cómo se usan los campos?

Cada tipo de elemento de trabajo está asociado a más de 31 campos del sistema y a otros tantos más específicos. Los elementos de trabajo se usan para planear y realizar un seguimiento del proyecto.

Cada campo admite el seguimiento de un fragmento de información sobre el trabajo que se va a realizar. Los valores que se asignan a un campo se almacenan en el almacén de datos de seguimiento del trabajo, en el que se pueden crear consultas para determinar el estado y las tendencias.

Para obtener descripciones y uso de cada campo definido para los procesos principales del sistema ( Procesos del sistema Scrum, Agile y CMMI), consulte Índice de campo de 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 se encuentran dentro de estas directrices:

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

Dado que todos los campos se definen para la organización, no se puede agregar un campo personalizado con el mismo nombre de campo que ya existe en la organización o se agregó a un WIT en otro proceso heredado.

Nota:

Al cambiar un proyecto para usar un proceso heredado, puede encontrar que una o varias herramientas ágiles o elementos de trabajo aparezcan en un estado no válido. Por ejemplo:

  • Si hace necesario un campo, los elementos de trabajo con ese campo sin definir muestran un mensaje de error. Deberá resolver los errores para realizar cambios adicionales y guardar el elemento de trabajo.
  • Si agrega o quita u oculta los estados de flujo de trabajo de un WIT que aparece en el panel Kanban, deberá actualizar las configuraciones de columna de la placa Kanban para todos los equipos definidos en el proyecto.

Reglas personalizadas y reglas del sistema

Cada WIT(error, tarea, caso de usuario, etc.) tiene varias reglas del sistema ya definidas. Algunos son simples, como hacer que el campo Título sea necesario o establecer un valor predeterminado para el campo Área de valor. Además, varias reglas del sistema definen las acciones que se deben realizar cuando cambia un estado de flujo de trabajo.

Por ejemplo, existen varias reglas para copiar la identidad del usuario actual en las condiciones siguientes:

  • Cuando se modifica un elemento de trabajo, copie la identidad del usuario en el campo Cambiado por.
  • Cuando el estado del flujo de trabajo cambie a Cerrado o Listo, copie la identidad del usuario en el campo Cerrado por.

Importante

Las reglas del sistema predefinidas toman precedentes sobre cualquier regla personalizada que defina qué sobrescribiría.

Las reglas personalizadas proporcionan compatibilidad con una serie de casos de uso empresariales, lo que le permite ir más allá de establecer un valor predeterminado para un campo o hacer que sea necesario. Las reglas permiten borrar el valor de un campo, copiar un valor en un campo y aplicar valores en función de las dependencias entre los valores de los distintos campos.

Con una regla personalizada, puede definir una serie de acciones en función de condiciones específicas. Por ejemplo, puede aplicar una regla para admitir estos tipos de escenarios:

  • Cuando se define un valor para Prioridad, haga que El riesgo sea un campo obligatorio.
  • Cuando se realiza un cambio en el valor de Release, desactive el valor de "Hito".
  • Cuando se realizó 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 un caso de usuario, realice los siguientes campos necesarios: Prioridad, Riesgo y Esfuerzo.

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 la extensión de Marketplace de Power Automate o del agregador de TFS (servicio web). Consulte también Acumulación de trabajo y otros campos.

Para más información sobre cómo definir reglas personalizadas, consulte Reglas y evaluación de reglas.

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

Con una de las dos condiciones siguientes, puede hacer que los campos seleccionados sean necesarios para un usuario de un grupo de seguridad o que no sean miembros de un grupo de seguridad.

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

Por ejemplo, puede hacer que el campo Título o Estado Sea de solo lectura para seleccionar usuarios o grupos.

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

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

Personalizaciones de tipo de elemento de trabajo (WIT)

Estas son las opciones de personalización para las WIT heredadas y personalizadas.

Tipo de elemento de trabajo

Asistencia para la personalización

Tipos de elementos de trabajo heredados

Tipos de elementos de trabajo personalizados

Lo que no se puede personalizar

  • No se puede agregar ni quitar un WIT heredado a o desde un trabajo pendiente
  • 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 se puede quitar el nivel de cartera heredado del producto (pero puede cambiarles el nombre)
  • No se puede cambiar el nombre de un WIT personalizado.

Personalizaciones de formularios de elemento de trabajo

Puede realizar las siguientes personalizaciones en un formulario WIT.

Tipo de grupo o página

Asistencia para la personalización

Grupos heredados

Grupos personalizados

Páginas heredadas

Páginas personalizadas

Diseño y cambio de tamaño

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

Illustration of 3-column page layout for work item form.

Si solo agrega grupos y campos a las dos primeras columnas, el diseño refleja un diseño de dos columnas. Del mismo modo, si solo agrega grupos y campos a la primera columna, el diseño refleja un diseño de una columna.

El formulario web cambia de tamaño en función del ancho disponible y del número de columnas del diseño. En la mayoría de los exploradores web, cada columna dentro de una página se muestra dentro de su propia columna. A medida que el ancho de la pantalla disminuye, cada columna cambia de tamaño proporcionalmente de la siguiente manera:

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

Cuando el ancho de la pantalla no acomodará todas las columnas, las columnas aparecen apiladas dentro de la columna a la izquierda.

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 difieren en función del proceso del sistema (Agile, Basic, Scrum o CMMI), que ha elegido para crear el proceso personalizado.

Cada 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
  • Motivos predeterminados para cada transición de estado

Por ejemplo, el proceso Básico, Issue WIT se caracteriza por los tres Estados: Para hacer, Hacer y Listo, y las transiciones que se muestran en la imagen siguiente.

Basic Process, Issue work item type, workflow state model

Tipos de estado

Personalizaciones admitidas

Inherited icon Estados heredados

Estados personalizados

Los estados de flujo de trabajo deben cumplir las siguientes reglas

  • Debe definir al menos un estado para las categorías Estado propuesto o En curso .

    Nota:

    Antes de agregar un estado de flujo de trabajo, revise Estados de flujo de trabajo y categorías de estado para obtener información sobre cómo los estados de flujo de trabajo se asignan a las categorías de estado.

  • Debe definir al menos dos estados de flujo de trabajo.
  • Puede definir un máximo de 32 estados de flujo de trabajo por tipo de elemento de trabajo.

Personalizaciones de flujo de trabajo no admitidas

  • No se puede modificar un estado heredado (no se puede cambiar su nombre, color o categoría), pero puede ocultarlo.
  • Solo puede tener un estado en la categoría Estado completado . Si agrega un estado personalizado a la categoría Completado, cualquier otro estado se quita o oculta.
  • No se puede cambiar el nombre de un estado personalizado.
  • No se puede especificar un motivo para un estado; en su lugar, los motivos predeterminados se definen, como Movido a evaluación de prioridades de estado, Movido fuera de la evaluación de prioridades de estado
  • No se puede cambiar la ubicación de los campos Estado y Motivo en el formulario
  • No se pueden personalizar los nombres de categoría de estado
  • No se puede modificar un estado heredado (no se puede cambiar su nombre, color o categoría), pero puede ocultarlo.
  • Solo puede tener un estado en la categoría Estado completado . El sistema no permite agregar cualquier estado personalizado a esta categoría.
  • No se puede cambiar el nombre de un estado personalizado.
  • No se puede cambiar el orden de los estados, los estados se muestran en su secuencia natural en función de su categoría de estado dentro de la lista desplegable de un formulario de elemento de trabajo.
  • No se puede especificar un motivo para un estado; en su lugar, los motivos predeterminados se definen, como Movido a evaluación de prioridades de estado, Movido fuera de la evaluación de prioridades de estado
  • No se puede cambiar la ubicación de los campos Estado y Motivo en el formulario
  • No se pueden restringir las transiciones, todas las transiciones se definen de cualquier estado a otro estado.

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. Los trabajos pendientes estándar (producto, iteración y cartera) heredados del proceso del sistema son totalmente personalizables. Además, puede agregar trabajos pendientes en cartera personalizados hasta un total de cinco trabajos pendientes en cartera.

Tipos de trabajos pendientes

Asistencia para la personalización

Trabajos pendientes heredados

Trabajos pendientes de cartera personalizados

Lo que no se puede personalizar

  • No puede quitar un nivel de cartera heredado del producto (pero puede cambiar el nombre del nivel de cartera y puede deshabilitar un tipo de elemento de trabajo heredado).
  • No se puede insertar un nivel de trabajo pendiente dentro del conjunto existente de trabajos pendientes definidos.
  • No se pueden reordenar los niveles de trabajo pendiente
  • No se puede agregar un tipo de elemento de trabajo a dos niveles de trabajo pendientes diferentes.
  • No se puede crear un nivel de trabajo pendiente de tarea personalizado, aunque puede agregar WIT personalizados al trabajo pendiente de iteración.
  • No se puede agregar el WIT de errores a ningún nivel de trabajo pendiente. En su lugar, el sistema permite a cada equipo decidir cómo quieren administrar errores. Para más información, consulte Mostrar errores en trabajos pendientes y paneles.
  • No se puede agregar ni quitar un WIT heredado a o desde un trabajo pendiente, por ejemplo, no se puede agregar issue WIT al trabajo pendiente del producto.
  • No puede quitar un nivel de cartera heredado del producto (pero puede cambiar el nombre del nivel de cartera y puede deshabilitar un tipo de elemento de trabajo heredado).
  • No se puede insertar un nivel de trabajo pendiente dentro del conjunto existente de trabajos pendientes definidos.
  • No se pueden reordenar los niveles de trabajo pendiente
  • No se puede agregar un tipo de elemento de trabajo a dos niveles de trabajo pendientes diferentes.
  • No se puede crear un nivel de tarea personalizado, aunque puede agregar tipos de elementos de trabajo personalizados al trabajo pendiente de iteración.
  • No se puede agregar el WIT de errores a ningún nivel de trabajo pendiente. En su lugar, el sistema permite a cada equipo decidir cómo quieren administrar errores. Para más información, consulte Mostrar errores en trabajos pendientes y paneles.

Nota:

Algunas características requieren la instalación de la actualización de Azure DevOps Server 2020.1. Para más información, consulte notas de la versión de Azure DevOps Server 2020 Update 1 RC1, Boards.

Al cambiar el WIT predeterminado para un nivel de trabajo pendiente, hace que WIT aparezca de forma predeterminada en el panel de adición rápida. Por ejemplo, customer Ticket aparece de forma predeterminada en el siguiente panel de adición rápida para el trabajo pendiente del producto.

Screenshot of Product backlog, Quick Add Panel, Displays Default WIT for a backlog level

Límites de objetos

Para obtener una lista de los límites colocados en el número de campos, WIT, niveles de trabajo pendiente y otros objetos que puede personalizar, consulte Límites de objetos de seguimiento de trabajos.