«Vamos a montar un gráfico de tiempo de ciclo» suele convertirse en un pequeño proyecto por sí solo. Azure DevOps no dibuja uno de forma predeterminada, así que el siguiente paso habitual es conectar Power BI al feed OData de Analytics o a una vista de Analytics, crear un informe y encontrar dónde alojarlo y compartirlo, además de un puesto de Power BI Pro para cualquiera que necesite abrirlo. Es un camino perfectamente válido cuando ya usas Power BI para otros informes, o necesitas combinar datos de Azure DevOps con cifras de otro sitio. Pero es mucha configuración si lo único que querías era ver cuánto tarda el trabajo de tu equipo.
Lo que realmente necesita un gráfico de tiempo de ciclo
Simplificándolo, una vista de tiempo de ciclo útil necesita cuatro cosas: una marca de tiempo de inicio y fin para cada elemento, basada en la propia asignación de etapas del flujo de trabajo de tu equipo (no una suposición genérica de lo que significa «en curso»); una separación por tipo de trabajo, porque un error y una función de varias semanas no deberían aparecer en la misma línea; una idea de la dispersión, no solo un promedio, una mediana y un percentil más alto, para que un único elemento muy lento no pueda arrastrar la cifra principal sin que se note; y una forma de saber si es honesta cuando la muestra es pequeña. Nada de eso requiere una herramienta de BI de propósito general. Requiere leer el historial de elementos de trabajo que Azure DevOps ya tiene y hacer el mismo cálculo, de forma coherente, cada vez que abres la pantalla.
La vista de Tiempo de ciclo
Eso es justo lo que hace la vista de Tiempo de ciclo de Agile Gauge: un punto por cada elemento entregado en los últimos seis sprints, separado en trabajo planificado, errores y exploración, con líneas de referencia de la mediana y el percentil 85. Cuando un grupo no tiene suficientes elementos entregados para que esas líneas tengan sentido, simplemente no se dibujan, en lugar de extrapolarlas silenciosamente a partir de tres datos y presentarlas como si significaran algo.
Cada punto es un elemento de trabajo real
Un diagrama de dispersión que no puede responder «¿cuál era ese elemento?» no sirve de mucho en una conversación real. Haz clic en cualquier punto, en cualquier fila de la tabla junto al gráfico, o en cualquiera de las líneas de percentil, y se abre un panel de elementos compartido que muestra exactamente qué elementos de trabajo hay detrás, incluido el recorrido real de cada uno por las etapas asignadas de tu equipo: dónde estuvo y durante cuánto tiempo. La tabla junto al gráfico existe por el mismo motivo: no hay forma accesible de recorrer un diagrama de dispersión solo con el teclado, así que la tabla no es una cortesía, es la respuesta a la misma pregunta que plantea el gráfico.
Por qué una mediana y un percentil 85, y no un solo promedio
Un único promedio de tiempo de ciclo oculta justo lo que más vale la pena saber: cuán consistente es realmente el equipo. Dos equipos pueden tener el mismo promedio y estar en situaciones completamente distintas: uno termina casi todo en una banda estrecha, el otro termina la mayoría de los elementos rápido pero arrastra unos pocos durante semanas. La mediana te dice cómo es un elemento típico; el percentil 85 te dice con qué debes contar para planificar los elementos que no salen bien. Ninguna de las dos líneas se dibuja hasta que hay suficiente trabajo entregado en ese grupo para respaldarla: un equipo con tres errores entregados en esta ventana verá los puntos y la tabla, pero no una línea de percentil inventada a partir de tres datos y presentada como si fuera una medición estable.
Leer el sprint, no solo los puntos
Encima del gráfico, una franja de lectura muestra las mismas cifras con su variación respecto a la ventana anterior, además de una línea de confianza que dice claramente cuánto se puede confiar en los números actuales dado el tamaño de la muestra que hay detrás. Los filtros de grupo y de ventana acotan la vista a un tipo de trabajo concreto o a un tramo distinto de sprints; cambiar el filtro de grupo a «Errores» por sí solo, por ejemplo, responde a «¿nuestros errores son realmente más rápidos que nuestras funciones, o solo lo parece?» sin que nadie tenga que recurrir a una hoja de cálculo. Hay un botón de exportar a CSV para el momento en que alguien realmente quiera entregarle los números en bruto a otra persona, incluido, si es a donde llegas, un informe de Power BI propio.
Dónde esto no sustituye a Power BI
Esta vista no pretende ser una herramienta de informes de propósito general, y no debería serlo. Si necesitas combinar datos de Azure DevOps con cifras de otros sistemas, crear informes multiproyecto totalmente personalizados, o ya tienes una presencia de Power BI de la que depende tu organización, el camino nativo de Analytics y Power BI sigue siendo la opción correcta: es exactamente para lo que está pensado. Para lo que sirve la vista de Tiempo de ciclo de Agile Gauge es para la petición mucho más habitual: «mostrar el tiempo de ciclo de nuestro propio equipo, ahora mismo, sin que nadie tenga que montar un proyecto de informes para conseguirlo».
Cómo llegar
No hay ninguna conexión OData que configurar ni ningún informe que construir antes de ver algo. En cuanto la asignación de etapas del flujo de trabajo de tu equipo está definida en Configuración, un paso único del que depende cada vista del hub, Tiempo de ciclo lee tus últimos seis sprints y dibuja el gráfico. Si aún no has tocado Configuración, la pantalla te lo dice claramente en lugar de suponer una asignación y mostrarte números basados en una suposición.
Agile Gauge lee directamente de tu propia organización de Azure DevOps: nada se copia a un servidor que nosotros operemos. Empieza una prueba de 14 días, con todas las funciones, sin tarjeta.