Microsoft AZ-400: Planificación ágil y gestión del trabajo — Guía de estudio

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Forma parte de la Microsoft DevOps Engineer Expert AZ-400 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

La planificación ágil y la gestión del trabajo en Azure DevOps se centran en un modelo de datos claro, prácticas disciplinadas de flujo e iteración, y visibilidad entre equipos. Azure Boards proporciona una jerarquía robusta de tipos de elementos de trabajo y configuraciones flexibles por equipo, mientras que GitHub Projects ofrece una planificación moderna, impulsada por la automatización y estrechamente integrada con Issues y Pull Requests. La adopción efectiva depende de definiciones rigurosas (Definition of Done, criterios de aceptación), estimación consistente (story points y dimensionamiento relativo) e información procesable (consultas, planes de entrega y métricas que incluyen DORA). Las siguientes secciones detallan cómo diseñar, implementar y operar estas prácticas a escala.

Modelo de datos de Azure Boards, plantillas de proceso y configuración de equipos

Los tipos de elementos de trabajo y su jerarquía forman la columna vertebral de la planificación. En el proceso Agile predeterminado, la jerarquía del portafolio es Epic > Feature > User Story, con Task y Bug como elementos a nivel de ejecución. Los vínculos de tipo “hijo” (Child) capturan la descomposición (User Story → Task) y los Bugs pueden gestionarse en el mismo nivel de backlog que las User Stories o clasificarse de forma independiente según la política del equipo. Los tipos de vínculo son esenciales:

• Parent/Child: captura la jerarquía de descomposición e impulsa la acumulación (rollup) del progreso y el esfuerzo.
• Predecessor/Successor: expresa relaciones de programación y dependencia entre elementos de trabajo; estas aparecen en los Delivery Plans como líneas de dependencia.
• Related/Duplicate/Blocked by: modela relaciones no jerárquicas e impedimentos.
• Vínculos de artefactos (Artifact links): conecta los elementos de trabajo con el código (commits, branches, PRs), compilaciones (builds) y lanzamientos (releases), permitiendo una trazabilidad de extremo a extremo.

Las plantillas de proceso de Azure DevOps definen los estados, los campos y la nomenclatura de los WIT (Work Item Types):

• Agile: el elemento a nivel de requisito es la User Story; los equipos que se mueven rápidamente suelen elegir esta opción.
• Scrum: el elemento a nivel de requisito es el Product Backlog Item (PBI); los sprints y los artefactos de Scrum son de primera clase y los Bugs se pueden configurar para que se comporten como los PBIs.
• CMMI: el elemento a nivel de requisito es Requirement e incluye WITs para Change Request, Risk y Review; elija esta opción cuando deba realizar un seguimiento de los riesgos y las revisiones formales.
• Procesos personalizados (heredados): en Azure DevOps Services, extienda un proceso del sistema mediante herencia (Inheritance) para agregar WITs, estados, reglas y campos personalizados, preservando al mismo tiempo la compatibilidad del servicio. Use categorías para colocar un WIT personalizado en el nivel de backlog correcto. Evite la personalización excesiva que fractura los informes; estandarice campos como Story Points y Remaining Work.

Los equipos son particiones ligeras que se configuran a través de:

• Area paths: delimitan la propiedad y el filtrado del backlog; los equipos seleccionan una o más rutas de área (y opcionalmente incluyen áreas secundarias) para definir “su” trabajo.
• Iteration paths: representan la cadencia de lanzamientos y los sprints; un equipo elige las iteraciones predeterminadas y actuales para la planificación.
• Backlogs y tableros de equipo: cada equipo elige qué niveles de portafolio (Epic, Feature) mostrar, los estilos de las tarjetas y los mapeos de columnas por equipo sin afectar a otros equipos.
• Paneles de equipo (Team dashboards): organice la visibilidad compartida utilizando widgets para Velocity, Burndown/Burnup, Cumulative Flow Diagram (CFD), gráficos de Lead/Cycle Time y vistas de Analytics personalizadas.

Entrega basada en flujo con Kanban y gobernanza

Kanban en Azure Boards modela el flujo continuo desde el compromiso hasta la finalización. Configure las columnas para que se correspondan con los estados del flujo de trabajo y, opcionalmente, divida los estados críticos en subcolumnas Doing/Done para mejorar el recuento del rendimiento (throughput) y reducir las colas ocultas. Establezca límites explícitos de WIP (Work In Progress) por columna y por carril (swimlane); hágalos cumplir operacionalmente: superar un límite desencadena una conversación de mejora en lugar de un crecimiento silencioso del backlog. Utilice carriles dedicados (por ejemplo, Expedite) para separar visualmente los elementos de alta prioridad y establecer un WIP más estricto para ese carril.

La Definition of Done (DoD) afianza la calidad y la previsibilidad; codifíquela como políticas del tablero, campos obligatorios o listas de verificación en transiciones específicas, y vinculación de pruebas de aceptación. Por ejemplo, exija un vínculo de tipo “Probado por” (Tested By) a un Test Case aprobado antes de mover a “Hecho” (Done), y capture los pasos de verificación del despliegue al mover a “Lanzado” (Released).

Utilice la analítica para gestionar la salud del flujo:

• El Cumulative Flow Diagram valida el equilibrio del WIP y detecta cuellos de botella cuando las bandas se expanden.
• El Lead Time mide el tiempo transcurrido desde la creación hasta la finalización; el Cycle Time se centra en el tiempo desde que se entra en estado “Activo” (Active) hasta la finalización.
• El widget del gráfico de Cycle Time informa el tiempo transcurrido después de que un elemento de trabajo pasa a estado “Activo” (Active), lo que se alinea con el análisis de cuellos de botella.
• Los gráficos de rendimiento (Throughput) rastrean los elementos completados por período de tiempo; supervise la estabilidad y la tendencia.

Planificación de la iteración, refinamiento del backlog y pronóstico basado en la velocidad

La planificación del sprint convierte la prioridad en un compromiso con un plazo determinado (timeboxed). El sprint backlog enumera los PBIs o User Stories incorporados a la iteración, desglosados en Tasks con el Remaining Work en horas. Utilice Sprint Capacity para modelar la disponibilidad de las personas:

• Capacidad por persona en horas/día por actividad (Development, Testing, UX).
• Días libres individuales y del equipo para reflejar festivos y vacaciones.
• Equilibrio de carga a nivel de actividad asociando tareas a actividades y revisando la capacidad frente al trabajo planificado.

La Velocity resume los story points entregados por sprint. Utilice el gráfico de Velocity para establecer una banda estable; evite la “inflación de puntos”. En los product backlogs, habilite Forecasting para proyectar cuántas iteraciones futuras se necesitarán para completar (burn down) el backlog a la velocidad media histórica del equipo (basada en varios sprints recientes) y la duración de la iteración. Mantenga la honestidad del pronóstico excluyendo el trabajo parcialmente completado y manteniendo un DoD estricto.

El refinamiento del backlog impone claridad y dimensionamiento relativo:

• Criterios de aceptación: registre declaraciones claras y comprobables en el campo Acceptance Criteria del elemento de trabajo; prefiera el formato Given-When-Then para reducir la ambigüedad y acelerar el diseño de pruebas.
• Story points: estime la complejidad y la incertidumbre relativas a nivel de requisito; no convierta los puntos en horas—las tareas llevan el Remaining Work.
• Estimación relativa (Planning Poker): utilice una línea de base compartida y una secuencia (Fibonacci o Fibonacci modificada) para converger rápidamente. Los equipos pueden usar extensiones del Marketplace para ejecutar Planning Poker dentro de Azure Boards, escribiendo las estimaciones en los campos Story Points/Effort para obtener informes consistentes.

Los bugs deben ser clasificados (triaged) y tratados como requisitos (estimados con puntos y planificados en el backlog) o gestionados como tareas dentro del sprint; elija una política por equipo para mantener la velocity consistente.

Planificación entre equipos, consultas, informes, GitHub Projects y métricas de DevOps

Los programas grandes requieren visibilidad entre equipos y repositorios:

• Planes de entrega: cree cronogramas multiequipo filtrados por rutas de área/iteración. Visualice el trabajo por iteración con líneas de dependencia (desde vínculos de Predecesor/Sucesor) y marcadores para hitos (fechas de lanzamiento, compromisos externos). Muestre el progreso acumulado en Features y Epics y exponga campos personalizados (p. ej., Riesgo) para las revisiones de gobernanza.
• Consultas e informes: cree consultas de lista plana para responder “qué elementos coinciden con estos filtros”, de árbol de elementos de trabajo para navegar la jerarquía con acumulados, y de vínculos directos para analizar un salto de vínculo (p. ej., Feature → Historias o Bug → commits). Guarde y comparta consultas, agregue gráficos (circular, de barras, de tendencia) y ánclelos a los paneles. Para informes de nivel analítico, utilice el servicio Azure DevOps Analytics y OData con Power BI para producir gráficos de burndown de portafolio, mapas de calor de riesgo de dependencias y visualizaciones DORA. Los informes integrados incluyen Velocidad, Burndown/Burnup, CFD, Tiempo de entrega, Tiempo de ciclo y uso de la Capacidad del sprint.

GitHub Projects integra la planificación con Issues y PR:

• Tableros de proyecto: cree vistas de Kanban o de tabla a nivel de organización o repositorio, defina campos personalizados (Estado, Iteración, Prioridad) y filtre por equipo.
• Reglas de automatización: configure flujos de trabajo integrados para establecer el Estado cuando un Issue o PR se abre, se fusiona o se cierra; archive automáticamente los elementos terminados; asigne o etiquete en función de los cambios en los campos; y mueva elementos entre vistas. Combine con GitHub Actions para automatizaciones avanzadas.
• Integración de Issues y PR: los Issues y PR son elementos de primera clase en Projects. Use palabras clave en las descripciones de los PR (Fixes #123) para vincular y cerrar Issues automáticamente. El estado y los revisores son visibles en el tablero, lo que permite la trazabilidad del código al plan.

Las métricas de DevOps deben conectar el código, el despliegue y los resultados:

• Métricas DORA:
  • Frecuencia de despliegue: cuente los despliegues en producción por día/semana; obtenga la fuente de los eventos de lanzamiento de la canalización.
  • Plazo de entrega para los cambios: mida desde el commit del código (o la fusión del PR) hasta el despliegue en producción; asegúrese de que las canalizaciones emitan marcas de tiempo de despliegue y las correlacionen con los commits.
  • Tasa de fallos en los cambios: proporción de despliegues en producción que resultan en un incidente que afecta al cliente o en una reversión; integre con etiquetas de gestión de incidentes y resultados de la canalización.
  • Tiempo medio de restauración (MTTR): tiempo transcurrido desde el inicio del incidente hasta la restauración del servicio; obtenga los datos de las alertas de monitoreo y los tiempos de cierre de incidentes. Correlacione DORA con los análisis del tablero (Tiempo de entrega/Tiempo de ciclo) para detectar si la restricción está en la planificación o en la entrega. Use paneles para presentar ambos conjuntos de métricas a la misma audiencia para la mejora continua.

Escenario de problema práctico

La división de Publicidad de Microsoft está alineando a ocho equipos multifuncionales que entregan una plataforma compartida de gestión de campañas. La base de código está en GitHub; la organización necesita compromisos trimestrales fiables, visibilidad clara de las dependencias y métricas de flujo y DORA procesables sin añadir una proliferación de herramientas.

1. Elija el proceso Agile de Azure DevOps y configure los equipos

• Por qué: Agile proporciona la jerarquía Épica > Característica > Historia de usuario que equilibra la simplicidad con los acumulados de portafolio. Cree ocho equipos, cada uno con su propia ruta de área y rutas de iteración actuales/futuras, lo que permite autonomía en los tableros y paneles mientras se conservan los informes a nivel de organización.

2. Defina la gobernanza de Kanban y la configuración del tablero

• Por qué: el flujo continuo entre sprints reduce el tiempo de espera. Configure columnas asignadas a estados con divisiones de En curso/Hecho para En progreso y Revisión de código. Establezca límites WIP por columna y agregue un carril de aceleración con un WIP más bajo. Agregue políticas de tablero que establezcan la Definición de Hecho (pruebas unitarias superadas, PR aprobado, lista de verificación de despliegue completada) para controlar el paso a Hecho.

3. Implemente el refinamiento del backlog y la disciplina de estimación

• Por qué: los compromisos predecibles requieren dimensionamiento y claridad consistentes. Capture los criterios de aceptación usando Given-When-Then en las Historias de usuario. Estandarice los Puntos de historia mediante Planning Poker (Fibonacci 1–13) usando una extensión de Azure Boards, y mantenga las estimaciones de tareas en horas de Trabajo restante para respaldar la Capacidad del sprint.

4. Planifique los sprints con pronósticos basados en la capacidad y la velocidad

• Por qué: la planificación de la capacidad reduce el exceso de compromisos. Ingrese las capacidades individuales por actividad y días libres. Use el gráfico de Velocidad de los últimos seis sprints para establecer un objetivo de sprint realista. Habilite la Previsión del backlog para proyectar cuántos sprints se necesitan para alcanzar los objetivos trimestrales de las Épicas, alineando las expectativas de las partes interesadas.

5. Establezca Planes de entrega para la visibilidad entre equipos

• Por qué: las dependencias y los hitos deben ser visibles en una única cronología. Cree un Plan de entrega que incluya a los ocho equipos y los niveles de portafolio. Agregue marcadores de hitos para las fechas de lanzamiento trimestrales y los eventos de mercado. Use vínculos de Predecesor/Sucesor para mostrar las líneas de dependencia y sacar a la luz el riesgo donde los elementos abarcan varias iteraciones.

6. Integre GitHub Projects para vistas de ejecución centradas en el repositorio

• Por qué: los desarrolladores viven en GitHub; Projects mantiene el contexto de ejecución cerca del código. Cree un GitHub Project a nivel de organización con vistas de tablero y tabla. Agregue reglas de automatización para establecer el Estado en En progreso al abrir un PR, en Hecho al fusionar un PR, y para autoarchivar los Issues cerrados. Use “Fixes #<id>” en los PR para cerrar los Issues vinculados y reflejar el estado de vuelta en el tablero.

7. Vincule el código y el trabajo para la trazabilidad

• Por qué: la trazabilidad de extremo a extremo permite informes y auditorías precisos. Exija que se haga referencia al ID del elemento de trabajo de Azure Boards en los mensajes de commit y las descripciones de PR; use vínculos de artefactos en los elementos de trabajo para que los Planes de entrega y los análisis puedan acumular el progreso a partir de la actividad del código.

8. Instrumente las métricas de flujo y DORA en los paneles

• Por qué: las métricas compartidas y automatizadas impulsan la mejora. En los paneles de equipo, ancle los gráficos de CFD, Tiempo de entrega y Tiempo de ciclo para gestionar el flujo. En un panel de programa, presente la Velocidad, el resumen del Plan de entrega y las métricas DORA: calcule la frecuencia de despliegue y el plazo de entrega utilizando los eventos de despliegue de la canalización de las fases de producción; derive la tasa de fallos en los cambios y el MTTR etiquetando incidentes y correlacionándolos con los despliegues. Esta vista unificada resalta si las restricciones están en la planificación (tiempo de entrega/ciclo del tablero) o en la entrega (DORA).

Este enfoque equilibra la autonomía del equipo (tableros, capacidad y paneles específicos del equipo) con la gobernanza del programa (Planes de entrega, dependencias e hitos). Azure Boards proporciona planificación y análisis jerárquicos, GitHub Projects agiliza el seguimiento diario de los desarrolladores con automatización vinculada a Issues y PR, y las métricas DORA conectan la planificación con los resultados operativos para lograr compromisos creíbles y basados en datos.

← Gestión de paquetes y gestión de artefactos · Todos los dominios

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Microsoft →