Acerca de la personalización de procesos y de procesos heredados
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 y paneles) 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:
Revise los cambios realizados en un proceso heredado a través del registro de auditoría. Para obtener 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.
Nota:
Vea los siguientes artículos para más información:
Procesos heredados frente al sistema
Verá dos tipos de procesos:
- Procesos del sistema :Agile, Basic, Scrum y CMMI, que están bloqueados para cambiarse.
- 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. Las actualizaciones de los procesos se documentan en las 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.
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.
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
- Agregar un campo personalizado
- Agregar lista de selección (menú desplegable)
- Agregar nombre de persona/identidad
- Agregar un campo de texto enriquecido (HTML)
- Agregar un campo de casilla (booleano)
- Adición de un control personalizado
- Agregar reglas personalizadas a un campo
- Cambiar la etiqueta de campo
- Establecer las opciones requeridas o predeterminadas
- Mover el campo dentro del diseño
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 obtener más información, vea Definir 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 obtener más información, vea Definir 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 realizar la transición de un proyecto a un proceso heredado, es posible que encuentre herramientas ágiles o elementos de trabajo en un estado no válido según los ejemplos siguientes:
- Si designa un campo según sea necesario, los elementos de trabajo que carecen de ese campo muestran un mensaje de error. Para continuar con los cambios adicionales y guardar el elemento de trabajo, resuelva estos errores.
- Si agrega, quita u oculta estados de flujo de trabajo para un WIT que aparece en la placa, asegúrese de actualizar las configuraciones de columna de la placa para todos los equipos definidos en el proyecto. Además, 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 comparten entre equipos.
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 obtener más información, vea Crear nodos secundarios, modificar 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
- Agregar WIT personalizado
- Cambiar el color o la descripción
- Agregar o quitar campos personalizados
- Agregar o quitar grupos personalizados
- Agregar o quitar páginas personalizadas
- Agregar o quitar un control personalizado
- Agregar reglas personalizadas a un ingenio
- Agregar, editar o quitar un estado de flujo de trabajo
- Habilitar o deshabilitar
- Eliminar
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
- Cambiar etiquetas
- Agregar o quitar campos personalizados
- Show/hide fields (Mostrar u ocultar campos)
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.
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 varían en función del proceso del sistema seleccionado para crear el proceso personalizado. Las opciones son Agile, Basic, Scrum o Capability Maturity Model Integration (CMMI). Para obtener más información, consulte Estados de flujo de trabajo, transiciones y motivos.
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. Por ejemplo, el proceso básico problema WIT incluye tres estados: Para hacer, Hacer y Listo.
- Motivos predeterminados para cada transición de estado
Tipos de estado
Personalizaciones admitidas
Estados heredados
Estados personalizados
Los estados de flujo de trabajo deben cumplir las siguientes reglas
- Defina al menos un estado para las categorías Estado propuesto o En curso .
Nota:
Antes de agregar un estado de flujo de trabajo, 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 las categorías de estado.
- Defina al menos dos estados de flujo de trabajo.
- Defina un máximo de 32 estados de flujo de trabajo por tipo de elemento de trabajo.
Personalizaciones de flujo de trabajo no admitidas
- Oculte los estados heredados si no quiere que estén visibles (no puede cambiar su nombre, color o categoría).
- Asegúrese de que solo existe un estado en la categoría Estado completado . Agregar un estado personalizado a esta categoría quita u oculta cualquier otro estado.
- Mantenga el nombre de los estados personalizados tal como está; no se pueden cambiar.
- Use los motivos predeterminados para las transiciones de estado, como Movido a estado Evaluado y Movido fuera del estado Triaged; no se pueden especificar motivos personalizados.
- Acepte la ubicación predeterminada de los campos Estado y Motivo del formulario; no se puede cambiar su ubicación.
- Use los nombres de categoría de estado predeterminados; no se pueden personalizar.
- Oculte los estados heredados si no quiere que estén visibles (no puede cambiar su nombre, color o categoría).
- Asegúrese de que solo existe un estado en la categoría Estado completado ; el sistema no permite agregar cualquier estado personalizado a esta categoría.
- Mantenga el nombre de los estados personalizados tal como está; no se pueden cambiar.
- Acepte la secuencia natural de estados en la lista desplegable del formulario de elemento de trabajo; no puede cambiar su orden.
- Use los motivos predeterminados para las transiciones de estado, como Movido a estado Evaluado y Movido fuera del estado Triaged; no se pueden especificar motivos personalizados.
- Acepte la ubicación predeterminada de los campos Estado y Motivo del formulario; no se puede cambiar su ubicación.
- Permitir transiciones de cualquier estado a otro; no se pueden restringir las transiciones.
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
Personalizaciones no admitidas:
- Quitar un nivel de cartera heredado:
- Aunque no se puede quitar directamente un nivel de cartera heredado de un producto, tiene un par de opciones:
- Cambiar el nombre del nivel de cartera: puede cambiar el nombre del nivel de cartera heredado para adaptarse mejor a sus necesidades.
- Deshabilitar un WIT heredado: si el nivel de cartera heredado incluye WIT que no desea usar, puede deshabilitarlos. Esta acción impide que los equipos creen nuevos elementos de trabajo de esos tipos.
- Aunque no se puede quitar directamente un nivel de cartera heredado de un producto, tiene un par de opciones:
- Inserción de un nivel de trabajo pendiente:
- No se puede insertar un nuevo nivel de trabajo pendiente dentro del conjunto existente de trabajos pendientes definidos. Normalmente, los niveles de trabajo pendiente predefinidos son fijos (por ejemplo, Epopeyas, Características, Casos de usuario, Tareas) y no se pueden agregar personalizados entre sí.
- Reordenar los niveles de trabajo pendiente:
- Desafortunadamente, no se pueden reordenar los niveles de trabajo pendiente. Normalmente siguen una jerarquía predefinida y no se admite cambiar su orden.
- Agregar un WIT a varios niveles de trabajo pendiente:
- Cada WIT solo puede pertenecer a un nivel de trabajo pendiente. No se puede agregar un WIT a dos niveles de trabajo pendiente diferentes simultáneamente.
- Creación de un nivel de trabajo pendiente de tareas personalizado:
- Aunque no puede crear un nivel de trabajo pendiente específico de la tarea personalizada, todavía puede agregar WIT personalizados al trabajo pendiente de iteración. Por ejemplo, podría crear un WIT personalizado denominado "Mejora" o "Mantenimiento" y asociarlo con el trabajo pendiente de iteración.
- Administración de errores:
- El WIT de errores no pertenece a ningún nivel de trabajo pendiente específico de forma predeterminada. En su lugar, cada equipo puede decidir cómo quieren administrar errores. Puede elegir mostrar errores en trabajos pendientes y paneles o controlarlos por separado.
- Agregar o quitar un WIT heredado de un trabajo pendiente:
- No se puede agregar ni quitar directamente un WIT heredado a o desde un trabajo pendiente. Por ejemplo, no se admite agregar el WIT "Problema" al trabajo pendiente del producto.
- Sin embargo, puede:
- Cambiar el nombre del nivel de cartera: si el nivel de cartera heredado incluye WIT que no desea usar, considere la posibilidad de cambiar el nombre para adaptarlo mejor a sus necesidades.
- Deshabilitar un WIT heredado: si hay WIT heredados que desea excluir, puede deshabilitarlos. Esta acción impide que los equipos creen nuevos elementos de trabajo de esos tipos.
- Quitar un nivel de cartera heredado:
- Aunque no se puede quitar un nivel de cartera heredado de un producto, tiene un par de opciones:
- Cambie el nombre del nivel de cartera: asígnele un nombre más adecuado.
- Deshabilitar las WIT heredadas: impida que los equipos usen WIT heredados específicos.
- Aunque no se puede quitar un nivel de cartera heredado de un producto, tiene un par de opciones:
- Inserción de un nivel de trabajo pendiente:
- Desafortunadamente, no se puede insertar un nuevo nivel de trabajo pendiente dentro del conjunto existente de trabajos pendientes definidos. Los niveles de trabajo pendiente predefinidos permanecen fijos (por ejemplo, Epopeyas, Características, Casos de usuario, Tareas).
- Reordenar los niveles de trabajo pendiente:
- Los niveles de trabajo pendiente suelen seguir una jerarquía predefinida y no se admite cambiar su orden. No se pueden reordenar.
- Agregar un WIT a varios niveles de trabajo pendiente:
- Cada WIT (por ejemplo, Bug, Task, User Story) solo puede pertenecer a un nivel de trabajo pendiente. No se puede agregar un WIT a dos niveles de trabajo pendiente diferentes simultáneamente.
- Creación de un nivel de tarea personalizado:
- Aunque no puede crear un nivel de trabajo pendiente específico de la tarea personalizada, todavía puede agregar WIT personalizados al trabajo pendiente de iteración. Por ejemplo, cree un WIT personalizado denominado "Mejora" o "Mantenimiento" y asócielo al trabajo pendiente de iteración.
- Administración de errores:
- El WIT de errores no pertenece a ningún nivel de trabajo pendiente específico de forma predeterminada. En su lugar, cada equipo puede decidir cómo quieren administrar errores. Puede elegir mostrar errores en trabajos pendientes y paneles o controlarlos por separado.
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.
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.