Personalización de la experiencia de seguimiento del trabajo

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

A medida que planee y realice un seguimiento del proyecto, considere la posibilidad de configurar características o personalizar su experiencia para alinearse con los requisitos de seguimiento del equipo. El enfoque para personalizar proyectos, que afecta a todos los equipos, depende del modelo de proceso que use.

En este artículo se proporciona información general sobre las personalizaciones disponibles y cómo varían en los tres modelos de proceso. Para obtener instrucciones específicas sobre las personalizaciones para admitir decisiones empresariales, consulte Configuración y personalización de Azure Boards. Para más información, consulte ¿Qué es Azure Boards? y Acerca de los elementos de trabajo.

Descripción de los niveles de personalización

Puede personalizar el seguimiento del trabajo en los siguientes niveles:

• Recursos compartidos de nivel de proyecto: defina rutas de acceso de área e iteración que los equipos seleccionen para configurar sus trabajos pendientes y paneles. Las consultas compartidas y las etiquetas de elementos de trabajo son otros objetos que una vez definidos se pueden compartir en el proyecto.
• Recursos o herramientas del equipo: cada equipo puede configurar sus herramientas específicas, como trabajos pendientes, paneles y paneles. Para obtener más información, consulte Acerca de los equipos y las herramientas de Agile.
• Permisos de proyecto y de nivel de objeto: administre el acceso a las herramientas de seguimiento del trabajo, que incluyen la configuración de permisos para objetos y el proyecto y la asignación de usuarios o grupos a niveles de acceso específicos.
• Personalización de procesos de nivel de organización: personalice los campos, los tipos de elementos de trabajo y los trabajos pendientes y los paneles disponibles para todos los equipos.

Ámbito de personalización e impacto

Comprender el ámbito de cada nivel de personalización le ayuda a tomar decisiones fundamentadas:

Nivel de personalización	Ámbito	Impacto	Examples
Nivel de proyecto	Todos los equipos del proyecto	Afecta a las configuraciones del equipo	Rutas de área, rutas de iteración, consultas compartidas
Nivel de equipo	Equipos individuales	Configuración específica del equipo	Columnas de trabajo pendiente, carriles de baño de placa, capacidad
Nivel de permiso	Acceso de usuario o grupo	Visibilidad de características de controles	Permisos de consulta, acceso a la ruta de área
Nivel de proceso	Organización o recopilación	Todos los proyectos que usan el proceso	Campos personalizados, tipos de elementos de trabajo, flujos de trabajo

Recursos compartidos de nivel de proyecto

Cada proyecto proporciona muchos recursos compartidos que admiten todos los equipos del proyecto. Estas características se configuran a través de la interfaz de usuario o el contexto de administración del portal web.

Recursos compartidos principales

Los siguientes recursos compartidos forman la base del seguimiento del trabajo en el proyecto:

• Rutas de acceso de área: Organizar elementos de trabajo por área de características o responsabilidad del equipo
• Rutas de iteración: Definir sprints y lanzamientos para planear y realizar el seguimiento
• Consultas compartidas: cree consultas reutilizables a las que todos los miembros del equipo puedan acceder
• Etiquetas de elemento de trabajo: agregar metadatos para categorización y filtrado
• Grupos de seguridad: administración de permisos de acceso en el proyecto

Vea los siguientes artículos para más información:

• Acerca de las rutas de acceso de área e iteración
• Establecer rutas de acceso de área
• Cambiar la lista de selección de una ruta de acceso de iteración
• Creación y edición de consultas
• Agregar etiquetas a elementos de trabajo

Procedimientos recomendados para recursos compartidos

• Planifique las rutas de área temprano: diseñe la estructura de la ruta de área para reflejar la propiedad del equipo y la organización del producto
• Establecer la cadencia de iteración: configurar longitudes de sprint coherentes y programaciones de versión
• Crear estructura de carpetas: organizar consultas compartidas en carpetas para mejorar la detectabilidad
• Usar etiquetas descriptivas: establecer convenciones de etiquetado para metadatos coherentes
• Revisión periódica de los permisos: asegúrese de que los niveles de acceso adecuados para todos los miembros del equipo

Selector de personas y campos de identidad

La característica selector de personas admite campos de identidad en Azure DevOps:

• El campo Asignado a y otros campos Identidad usan la función de selección de personas.
• Activación: al elegir el campo Asignado a dentro de un formulario de elemento de trabajo, el selector de personas se activa automáticamente.
• Selección de usuario: para seleccionar un usuario, empiece a escribir su nombre y busque hasta que encuentre una coincidencia.
• Selecciones recientes: los usuarios seleccionados anteriormente aparecen automáticamente en la lista para obtener acceso rápido.
• Integración de directorios: para las organizaciones que usan microsoft Entra ID o Active Directory, los selectores de personas permiten buscar todos los usuarios y grupos agregados al directorio (no solo los agregados a un proyecto específico).
• Limitación de ámbito: Para limitar el ámbito de las identidades disponibles a usuarios que pertenecen específicamente al proyecto, use el grupo Usuarios con ámbito de proyecto.
• Restricciones personalizadas: las reglas personalizadas pueden restringir aún más los valores disponibles para los campos Identity dentro de un elemento de trabajo.

Configuración del campo de identidad

Puede configurar campos de identidad de varias maneras:

• Usuarios con ámbito limitado al proyecto: Limitar la selección de identidad exclusivamente a los miembros del proyecto
• Reglas personalizadas: implementación de reglas de negocios que restringen los valores de campo
• Restricciones basadas en grupos: uso de grupos de Azure AD para controlar las identidades disponibles
• Permisos de nivel de campo: establecer quién puede modificar campos de identidad

Vea los siguientes artículos para más información:

• Agregue usuarios o grupos de Active Directory/Microsoft Entra a un grupo de seguridad integrado.

• Limitar la búsqueda de identidades.

Personalización de procesos de nivel de organización

El proyecto define los tipos de elementos de trabajo (WIT) disponibles para el seguimiento del trabajo y configura las herramientas de Agile. Especifica casos de usuario, tareas, errores y los campos de datos usados para capturar información. Los objetos personalizados se comparten entre los equipos del proyecto.

Nota:

El método que se usa para personalizar el seguimiento del trabajo depende del modelo de proceso al que se suscriba:

• Herencia: admite la personalización WYSIWYG, disponible para Azure DevOps Services, Azure DevOps Server 2019 y Azure DevOps Server 2020.
• XML hospedado: admite la personalización mediante la importación y exportación de plantillas de proceso, disponible para un número seleccionado de clientes de Azure DevOps Services que han optado por este modelo.
• XML local: admite la personalización a través de la importación y exportación de archivos de definición XML para objetos de seguimiento de trabajo y está disponible para todas las implementaciones locales.

Comparación del modelo de proceso

En la tabla siguiente se resumen las diferencias entre los tres modelos de proceso admitidos. Para obtener definiciones de los principales objetos de seguimiento de trabajo, consulte Glosario de Agile. Para obtener vínculos a artículos de personalización, consulte Índice de referencia rápido para la configuración de Azure Boards.

---

Característica

Herencia

XML hospedado

XML local

---

Edición de WYSIWYG

✔️

---

Crear procesos personalizados heredados, Heredar cambios en los procesos del sistema (Agile, Basic, Scrum, CMMI)

✔️

---

Creación de plantillas de proceso personalizadas (consulte la nota 1)

✔️

✔️

---

Los cambios de proceso actualizados se aplican automáticamente a todos los proyectos que hacen referencia al proceso.

✔️

✔️

---

Compatibilidad con la personalización de campos, tipos de elementos de trabajo, diseño de formulario, flujo de trabajo, reglas personalizadas, niveles de trabajo pendiente, controles personalizados, administración de pruebas

✔️

✔️

✔️

---

Compatibilidad con la personalización de tipos de vínculo, campos de equipo, flujo de trabajo global y configuración de procesos (consulte la nota 3)

✔️

---

Configuración inicial de rutas de acceso de área, rutas de acceso de iteración, consultas de elementos de trabajo, grupos de seguridad y permisos (consulte la nota 3)

✔️

✔️

---

Listas globales

Listas de selección

(véase la nota 2)

✔️

---

Usar az boards herramientas de línea de comandos para editar proyectos y equipos e información de lista

✔️

✔️

✔️

---

Usar las herramientaswitadmin línea de comandos para enumerar y exportar información del proceso

✔️

✔️

✔️

---

API REST (lectura)

✔️

✔️

✔️

---

API REST (escritura)

✔️

✔️

(véase la nota 5)

---

Guía de selección del modelo de proceso

Elija el modelo de proceso en función de las necesidades de su organización:

Modelo de proceso de herencia (recomendado)

• Mejor para: Equipos que quieren una personalización intuitiva basada en la web
• Ventajas: edición WYSIWYG, actualizaciones automáticas, mantenimiento sencillo
• Uso cuando: necesita una personalización moderada con una complejidad mínima

Modelo de proceso XML hospedado

• Mejor para: Organizaciones con requisitos de proceso complejos
• Ventajas: Control de plantilla de proceso completo, amplia personalización
• Uso cuando: necesita personalización avanzada de procesos, pero desea hospedar en la nube

Modelo de proceso XML local

• Mejor para: Implementaciones locales con requisitos de control total
• Ventajas: Flexibilidad de personalización completa, integración empresarial
• Uso cuando: necesita el control máximo y la ejecución de la infraestructura local

Notas:

1. Un proceso determina los bloques de creación usados para realizar un seguimiento del trabajo. Una plantilla de proceso especifica un conjunto interdependente de archivos de definición XML que proporcionan los bloques de creación y la configuración inicial para el seguimiento del trabajo y otras áreas funcionales.
2. La personalización xml hospedada admite la adición y actualización de listas globales con una actualización de procesos (sujeto a límites en el tamaño máximo de cada lista). Para obtener más información, consulte Límites de objetos de seguimiento de trabajo.
3. El modelo de proceso heredado no admite la personalización de las siguientes características disponibles con la personalización de plantillas de proceso. En su lugar, puede personalizar estas áreas dentro del portal web en un proyecto por proyecto.
   • Rutas de área y de iteración
   • Consultas de elementos de trabajo
   • Grupos de seguridad y permisos
   • Permisos y acceso a áreas funcionales, como el control de versiones y la compilación
   O bien, puede usar las API REST o la herramienta de comandos de la CLI de Azure DevOps.
4. Use la API REST para importar y exportar plantillas de proceso.

Personalización de la experiencia de prueba

Varios tipos de elementos de trabajo admiten la experiencia de prueba en las páginas de prueba del portal web y el cliente del Administrador de pruebas.

Personalización del proceso de herencia

Para un proceso heredado, puede personalizar los siguientes tipos de elementos de trabajo como haría con cualquier otro tipo de elemento de trabajo:

• Plan de pruebas: organizar y administrar conjuntos de pruebas
• Conjunto de pruebas: Agrupar casos de prueba relacionados
• Caso de prueba: definir escenarios de prueba individuales

Personalización de XML local

Para un proceso XML local, puede personalizar todos los tipos de elementos de trabajo relacionados con pruebas, incluidos:

• Plan de prueba: organización de pruebas de alto nivel
• Conjunto de pruebas: agrupaciones de casos de prueba
• Caso de prueba: definiciones de prueba individuales
• Pasos compartidos: procedimientos de prueba reutilizables
• Parámetros compartidos: datos de prueba con parámetros

Probar las relaciones de elementos de trabajo

En el ejemplo siguiente se muestran las relaciones de vínculo admitidas entre los tipos de elementos de trabajo de prueba:

Escenarios de personalización de pruebas

Entre las personalizaciones comunes de la experiencia de prueba se incluyen las siguientes:

• Campos de prueba personalizados: Agregar metadatos de prueba específicos de la organización
• Estados de prueba del flujo de trabajo: Definir estados de ejecución de prueba personalizados
• Seguimiento de resultados de pruebas: Personalización de informes de resultados de pruebas
• Campos de integración: Conexión de pruebas con requisitos y defectos

Personalizaciones menos comunes

Solo puede realizar las siguientes personalizaciones al trabajar con los modelos de proceso XML hospedado o XML local. Las personalizaciones realizadas para procesar la configuración se aplican a todos los equipos de un proyecto.

Límites de trabajos pendientes y de placa (XML hospedado, XML local)

Para limitar el tiempo de carga de visualización a parámetros aceptables, el panel de tareas está restringido a un máximo de 1000 elementos de trabajo. Para obtener más información, consulte Process configuration XML element reference (Referencia del elemento XML de configuración del proceso).

Puede aumentar este valor hasta un máximo de 1500 especificando un valor para el workItemCountLimit atributo del elemento TaskBacklog . Para obtener más información, consulte Process configuration XML element reference (Referencia del elemento XML de configuración del proceso).

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

Consideraciones de rendimiento para los límites de la placa

Al personalizar los límites del panel, tenga en cuenta lo siguiente:

• Impacto en el tiempo de carga: los límites más altos pueden aumentar los tiempos de carga de página.
• Experiencia del usuario: equilibrar la funcionalidad con el rendimiento
• Limitaciones del explorador: algunos exploradores controlan conjuntos de datos grandes de forma diferente
• Ancho de banda de red: tenga en cuenta a los miembros del equipo con conexiones más lentas.

Cambio de asignaciones de campo (XML hospedado, XML local)

Puede cambiar los campos de elemento de trabajo que usa el sistema para calcular la capacidad, los gráficos de agotamiento, la previsión y la velocidad. Cualquier cambio que realice en una de las asignaciones predeterminadas debe corresponder a un cambio realizado en el WIT usado para definir y capturar información para ese valor.

Por ejemplo, si cambia el refname asignado a type="Activity" , debe incluir el mismo campo en la definición de WIT asignada a la categoría de tarea que captura la información de actividad. Para obtener más información, consulte Process configuration XML element reference (Referencia del elemento XML de configuración del proceso).

Herramientas que usan asignaciones de campo

Las herramientas siguientes usan los campos que asigne:

Herramienta	Tipo de campo	Propósito
Panel de tareas, herramientas de capacidad, reducción de sprint	Trabajo restante	Seguimiento del cumplimiento del trabajo
Trabajos pendientes de productos y carteras	Prioridad de trabajo pendiente	Ordenar elementos de trabajo
Velocidad y previsión	Esfuerzo (se asigna a puntos de historia, esfuerzo o tamaño)	Estimación del tamaño del trabajo
Herramientas de capacidad	Actividad (actividad de tareas o disciplina)	Planeamiento de la capacidad del equipo

Prácticas recomendadas de asignación de campos

• Mantener la coherencia: asegúrese de que las asignaciones de campo coinciden con las definiciones de tipo de elemento de trabajo.
• Cambios de prueba: valide que las herramientas funcionan correctamente después de reasignaciones de campo
• Personalizaciones de documentos: registrar cambios en la asignación de campos para futuras referencias
• Considere el impacto: Comprender cómo afectan los cambios a los datos e informes existentes

Administración del acceso a las herramientas de seguimiento del trabajo

Puede administrar el acceso a características específicas mediante la configuración de permisos. Al agregar cuentas de usuario al equipo, se agregan automáticamente al grupo Colaborador. A continuación, tienen acceso a la mayoría de las características que necesitan para contribuir al código, el seguimiento del trabajo, las compilaciones y las pruebas. Sin embargo, el grupo Colaborador no permite a los usuarios crear consultas compartidas ni agregar rutas de acceso de área o iteración. Tiene que conceder estos permisos por separado.

Estructura de permisos predeterminada

El sistema de permisos funciona en estos principios:

• Acceso predeterminado: los nuevos miembros del equipo se unen automáticamente al grupo Colaborador .
• Permisos principales: el grupo Colaborador proporciona acceso a la mayoría de las características necesarias para el trabajo de desarrollo.
• Permisos adicionales: algunas características requieren concesiones de permisos independientes
• Acceso administrativo: los administradores del proyecto tienen control total sobre los permisos.

Limitaciones del grupo de colaboradores

El grupo Colaborador no permite automáticamente a los usuarios:

• Crear consultas compartidas: requiere permisos de consulta adicionales
• Agregar rutas de acceso de área o iteración: requiere permisos administrativos de nivel de proyecto
• Modificación de la configuración de seguridad: requiere acceso administrativo
• Configuración de la configuración del equipo: requiere el rol de administrador del equipo

Enfoque de administración de permisos

Para administrar de forma eficaz los permisos:

1. Comience con los valores predeterminados: use grupos integrados como base.
2. Conceder permisos específicos: agregar permisos para necesidades específicas
3. Uso de grupos de seguridad: Aproveche los grupos de Azure AD para facilitar la administración.
4. Revisiones periódicas: auditar periódicamente los permisos de idoneidad
5. Documentar decisiones: Mantener registros de otorgamiento de permisos y sus justificantes

Para obtener información general simplificada sobre los permisos predeterminados comunes y las asignaciones de acceso, consulte Permisos y acceso.

Si no está familiarizado con la administración de permisos, explore Introducción a los permisos, el acceso y los grupos de seguridad, herencia de permisos y grupos de seguridad.

Áreas de permisos específicas

Para administrar el acceso a características específicas, consulte los siguientes artículos:

---

Administración del acceso

• Acerca de los niveles de acceso
• Incorporación de miembros del equipo (Azure DevOps Services)
• Cambio de los niveles de acceso (implementaciones locales)
• Agregar miembros del equipo (implementaciones locales)

Permisos

• Permisos de ruta de acceso de área
• Permisos de procesamiento
• Permisos de consulta y carpeta de elementos de trabajo
• Permisos del panel
• Permisos del plan de entrega
• Etiquetado de permisos
• Permisos de prueba

Recursos compartidos

• Alertas
• Rutas de acceso
• Rutas de acceso de iteración
• Consultas
• Etiquetas

---

Más opciones de personalización

Además de las características de personalización integradas, tenga en cuenta estas opciones adicionales para ampliar la funcionalidad de Azure DevOps:

Extensiones de Marketplace

• Examinar soluciones: revise Extensiones de Marketplace para ver si hay herramientas disponibles que se ajusten a sus necesidades.
• Categorías populares: busque extensiones en el seguimiento del trabajo, los informes y la administración de proyectos.
• Contribuciones de la comunidad: beneficiarse de las soluciones desarrolladas por la comunidad de Azure DevOps

Opciones de desarrollo personalizado

• Crear extensiones: desarrolle su propia extensión para necesidades organizativas específicas.
• Herramientas de integración: creación de integraciones personalizadas mediante las API REST
• Enlaces de servicio: determine si un enlace de servicio satisface sus necesidades de automatización.

Participación de la comunidad

• Solicitudes de características: agregar una solicitud de característica a nuestra página De la Comunidad de desarrolladores
• Comentarios del usuario: comparta sus experiencias y sugerencias con el equipo del producto.
• Procedimientos recomendados: Información sobre los enfoques de personalización de otras organizaciones

Planificación de la estrategia de personalización

Antes de implementar las personalizaciones, tenga en cuenta lo siguiente:

1. Requisitos empresariales: defina claramente lo que desea lograr
2. Evaluación del impacto: comprender cómo afectan los cambios a los flujos de trabajo existentes
3. Sobrecarga de mantenimiento: considere el costo a largo plazo de mantener las personalizaciones.
4. Soluciones alternativas: evaluar si las características existentes satisfacen sus necesidades
5. Ruta de migración: planear futuras actualizaciones y migraciones

Pasos siguientes

Configuración y personalización de Azure Boards

Artículos relacionados

• Índice de campo de elemento de trabajo
• herramienta de línea de comandos witAdmin
• Administración de plantillas de proceso
• Introducción a las plantillas de proceso
• Seguimiento del trabajo, proceso y límites del proyecto
• Índice de referencia rápido para la configuración de Azure Boards