La sección de seguimiento de trabajo y métricas en el examen AZ-400 pregunta cómo diseñas flujos de trabajo y mides el rendimiento del equipo. Qué tipo de work item va en qué nivel de Azure Boards, cómo se conecta GitHub Issues con el mundo de Azure DevOps, y qué dicen realmente las cuatro métricas DORA: estas son las preguntas que vale la pena entender a fondo, no solo memorizar.
Jerarquía de Work Items: ¿Hasta dónde se desglosa el trabajo?
Imagina la construcción de un edificio de apartamentos. Todo el complejo es el proyecto, cada edificio es una función importante, cada planta es una capacidad orientada al usuario, y cada habitación individual es una tarea que alguien necesita completar. Azure Boards organiza el trabajo exactamente de esa manera.
En la cima está el , un gran bloque de trabajo que abarca múltiples equipos y trimestres. Debajo está el , que representa una capacidad entregable. Un es lo que un equipo puede completar dentro de un sprint: la unidad mínima de valor de negocio que puede mantenerse por sí sola. Por debajo están los elementos para el trabajo individual del desarrollador y los elementos para los defectos.
Los nombres exactos dependen de la plantilla de proceso que elijas. La plantilla usa User Stories. La plantilla llama al mismo concepto Product Backlog Item (PBI). La plantilla es la única que incluye de serie Change Request, Requirement, Risk y Review como tipos de work item nativos, lo que la convierte en la opción correcta para organizaciones bajo ISO 9001 o con requisitos formales de auditoría. La plantilla lo simplifica con solo Issue y Task, ideal para equipos pequeños que están empezando.
Cuando una pregunta del examen menciona "autonomía del equipo y seguimiento de sprints", piensa en la plantilla Agile y los User Stories. Cuando dice "cumplimiento normativo y gestión formal de cambios", CMMI es la respuesta.
Boards, Backlogs y Sprints: Tres Vistas, Una Sola Realidad
Imagina la cocina de un restaurante en hora punta. El chef principal necesita ver todos los pedidos a la vez (el backlog), los cocineros de línea necesitan saber qué plato están preparando ahora mismo (el board), y el gerente necesita ver cuántos platos se sirvieron esta noche respecto a los planificados (métricas de sprint). Azure Boards da a cada persona exactamente esa vista.
La vista es tu muro Kanban. Los work items son tarjetas que se mueven por columnas que representan transiciones de estado. Puedes aplicar límites WIP (Work in Progress) a cada columna, lo que evita que demasiados elementos estén "en progreso" simultáneamente y obliga al equipo a terminar antes de comenzar trabajo nuevo.
La vista es una lista priorizada de todo lo que el equipo planea hacer. El Product Owner organiza los elementos según la prioridad de negocio. El Sprint Backlog reduce esto al trabajo comprometido del sprint actual.
Las permiten filtrar work items por condiciones personalizadas. Guardar una consulta como da a cada desarrollador una lista de tareas personal con un solo clic. Los resultados de las consultas también se pueden anclar directamente como widgets en un dashboard, haciendo que una consulta bien diseñada sea la base de cualquier dashboard útil.
El flujo de estados en el proceso Agile es . Código fusionado pero QA pendiente = . Todo validado y aprobado = . Solo los elementos se cuentan en la velocidad del sprint.
GitHub Issues y el Puente ABLos desarrolladores viven en GitHub. Su código está allí, sus pull requests están allí, y sus conversaciones sobre los cambios también ocurren allí. Obligar a los desarrolladores a cambiar a un sistema separado cada vez que quieren registrar una tarea introduce fricción que ralentiza a todo el equipo.
GitHub Issues mantiene el seguimiento del trabajo en el mismo entorno que el código. GitHub Projects añade una capa Kanban encima, ofreciendo vistas de Board, Tabla y Roadmap sobre esos issues. Para equipos completamente en GitHub, esta es una elección natural.
Para organizaciones que usan tanto Azure DevOps como GitHub, la mención es el puente. Cuando un desarrollador escribe en un mensaje de commit o en el cuerpo de un pull request, Azure Boards crea automáticamente un enlace en el work item 1234. Cuando ese PR se fusiona en la rama predeterminada, el estado del work item se actualiza automáticamente a . En la dirección opuesta, Azure Boards muestra el PR vinculado directamente en la página de detalles del work item.
Esta trazabilidad bidireccional es lo que el examen llama "trazabilidad de extremo a extremo": cualquier incidente de producción puede rastrearse hasta el PR que lo introdujo, el User Story y el Feature correspondientes.
Los equipos centrados en GitHub se benefician de la integración código-issues de GitHub Issues. Las organizaciones que ya usan Azure DevOps obtienen mayor jerarquía, consultas más ricas y mejores reportes de cumplimiento con Azure Boards.
Las Cuatro Métricas DORA: Salud en Números
Un médico no adivina si un paciente está sano. Revisa la presión arterial, el ritmo cardíaco y la temperatura: mediciones objetivas que cuentan una historia coherente. Las métricas DORA hacen lo mismo para un equipo DevOps. Convierten "creemos que estamos mejorando" en números que pueden rastrearse, compararse y mejorar.
mide con qué frecuencia el equipo despliega en producción. Los equipos Elite despliegan varias veces al día. Un equipo que despliega una vez al mes está en el nivel Low. Mayor frecuencia significa lanzamientos más pequeños y seguros.
es el tiempo desde un commit de código hasta que ese código está en producción. Esto mide todo el pipeline: desde escribir el código hasta construir, probar, revisar y desplegar. Tiempos de entrega más cortos significan que el equipo entrega valor más rápido y recibe retroalimentación antes.
mide cuánto tiempo lleva recuperarse de un incidente en producción. Los equipos Elite restauran el servicio en menos de una hora. Un MTTR alto a menudo apunta a mala observabilidad o falta de capacidad de rollback automatizado.
es el porcentaje de despliegues que causan incidentes, rollbacks o hotfixes. Un equipo que despliega diez veces al día con un 30% de tasa de fallos está empeorando las cosas, no mejorándolas. Aquí siempre es mejor un valor más bajo.
Pensar en estos en pares ayuda. y juntos miden la velocidad: qué tan rápido se mueve el equipo. y juntos miden la estabilidad: con qué fiabilidad opera el equipo. El rendimiento Elite de DevOps es alta velocidad y alta estabilidad al mismo tiempo.
!Las 4 métricas de DORA
Diseño de Dashboards: Haciendo los Números Visibles
Los datos que nadie puede ver no impulsan decisiones. Un buen dashboard es como el panel de instrumentos de un coche: muestra los números críticos de un vistazo para que el conductor pueda reaccionar antes de que algo vaya mal.
Los Azure DevOps Dashboards son basados en widgets. Arrastra widgets de Deployment Frequency, Lead Time, gráficos de resultados de consultas y gráficos de burndown a un lienzo para construir un tablero de estado del equipo. Dado que los widgets de consulta se obtienen directamente de las consultas guardadas, una consulta bien escrita produce automáticamente un dashboard bien poblado.
Los permisos son importantes aquí para el examen. Los pueden crear dashboards y gestionar widgets. Los miembros del equipo en el grupo pueden ver los dashboards pero no pueden añadir ni reorganizar widgets. Los usuarios con nivel de acceso enfrentan restricciones adicionales en ciertos tipos de widgets.
Para los equipos nativos de GitHub, GitHub Insights proporciona métricas de desarrollo a nivel de repositorio: tiempo de ciclo de pull requests, tiempo de respuesta de revisión y actividad de colaboradores. Mientras que los Azure DevOps Dashboards ofrecen una vista de toda la organización en múltiples proyectos, GitHub Insights se centra en el flujo de trabajo de desarrollo dentro de un repositorio individual. Ambos pueden aportar datos a un dashboard de métricas DORA a nivel ejecutivo cuando se integran correctamente.
Resumen para el Examen
"Seguimiento de sprint a nivel de equipo, unidad mínima de valor de negocio" -- User Story de la plantilla Agile
"Auditorías regulatorias, seguimiento formal de Change Request y Risk" -- Plantilla CMMI
"Vista que soporta límites WIP" -- Board (Kanban)
"Estado de work item contabilizado en la velocidad del sprint" -- Closed
"Commit de GitHub o cuerpo de PR → work item de Azure Boards vinculado automáticamente" -- mención AB#<id> (ej. fixes AB#1234)
"Tiempo desde el commit de código hasta producción" -- Lead Time for Changes
"Tiempo promedio de recuperación ante un incidente en producción" -- MTTR (Mean Time to Restore)
"Porcentaje de despliegues que causan rollbacks o incidentes" -- Change Failure Rate
"Con qué frecuencia el equipo despliega en producción" -- Deployment Frequency
"Permiso requerido para crear o gestionar widgets de dashboard" -- Project Administrators
"Tiempo de ciclo de PR y métricas de colaboradores a nivel de repositorio" -- GitHub Insights
Par de velocidad DORA = Deployment Frequency + Lead Time | Par de estabilidad DORA = MTTR + Change Failure Rate