Guía de flujo acumulativo, tiempo de ejecución y tiempo de ciclo
Azure DevOps Services | Azure DevOps Server 2022: Azure DevOps Server 2019 | TFS 2018
Los diagramas de flujo acumulativos (CFD) se usan para supervisar el flujo de trabajo a través de un sistema. Las dos métricas principales para realizar el seguimiento, el tiempo de ciclo y el tiempo de ejecución se pueden extraer del gráfico. Para configurar o ver gráficos de CFD, consulte Configurar un gráfico de flujo acumulativo.
O bien, puede agregar los gráficos de control plazo y tiempo de ciclo a los paneles.
Gráficos de ejemplo y métricas principales
El CFD de flujo continuo proporciona el gráfico más favorecida por los equipos que siguen un proceso magro.
Sin embargo, muchos equipos han empezado a combinar prácticas ajustadas con Scrum u otras metodologías, lo que significa que practican inclinarse dentro del intervalo de una iteración o sprint. En esta situación, el diagrama adopta un aspecto ligeramente diferente y proporciona dos elementos adicionales, y muy valiosos, de información como se muestra en el siguiente gráfico.
Flujo continuo
El CFD de período fijo que se muestra aquí es para un sprint completado.
La línea superior representa el ámbito establecido para el sprint. Y, dado que el trabajo debe completarse por el último día del sprint, la pendiente del estado Closed indica si un equipo está en camino para completar el sprint. La manera más fácil de pensar en esta vista es como un gráfico de evolución.
Los datos siempre se muestran con el primer paso del proceso como la parte superior izquierda y el último paso del proceso como la parte inferior derecha.
CFD de período fijo para un sprint completado
Métricas de gráfico
Los gráficos de CFD muestran el recuento de elementos de trabajo agrupados por columna state/Kanban a lo largo del tiempo. Las dos métricas principales para realizar el seguimiento, el tiempo de ciclo y el tiempo de ejecución se pueden extraer del gráfico.
Métrica
Definición
Tiempo de ciclo1
Mide el tiempo necesario para mover el trabajo a través de un único proceso o estado de flujo de trabajo. El cálculo es desde el inicio de un proceso hasta el inicio del siguiente proceso.
Plazo1
Para un proceso de flujo continuo: mide la cantidad de tiempo que se tarda desde el momento en que se realiza una solicitud (como agregar un caso de usuario propuesto) hasta que se complete esa solicitud (cerrada).
Para un proceso de sprint o período fijo: mide el tiempo desde el momento en que comienza el trabajo en una solicitud hasta que se completa el trabajo (es decir, el tiempo de Activo a Cerrado).
Trabajo en curso
Mide la cantidad de trabajo o el número de elementos de trabajo que se están trabajando activamente.
Ámbito
Representa la cantidad de trabajo confirmada durante el período de tiempo determinado. Solo se aplica a los procesos de período fijo.
1 El widget de CFD (Análisis) y el gráfico de CFD integrado (almacén de datos de seguimiento de trabajo) no proporcionan números discretos en tiempo de ejecución y tiempo de ciclo. Sin embargo, los widgets Plazo y Tiempo de ciclo proporcionan estos números.
Hay una correlación bien definida entre el tiempo de plazo y el tiempo de ciclo y el trabajo en curso (WIP). Cuanto mayor sea el tiempo de ciclo, más largo será el tiempo de ciclo, lo que también conduce a tiempos de entrega más largos. Lo contrario también es cierto: el menos WIP, cuanto más corto sea el ciclo y el tiempo de espera. Cuando el equipo de desarrollo se centra en menos elementos, reducen el ciclo y los plazos. Esta correlación es una razón clave por la que puede y debe establecer los límites de trabajo en curso en el panel Kanban.
El recuento de elementos de trabajo indica la cantidad total de trabajo en un día determinado. En un CFD de período fijo, un cambio en este recuento indica el cambio de ámbito durante un período determinado. En un CFD de flujo continuo, indica la cantidad total de trabajo en la cola y completada durante un día determinado.
La descomposición del trabajo en columnas específicas del panel Kanban proporciona una vista en la que el trabajo está en proceso. Esta vista proporciona información sobre dónde se mueve el trabajo sin problemas, donde hay bloqueos y dónde no se realiza ningún trabajo. Sin embargo, es difícil descifrar una vista tabular de los datos; sin embargo, el gráfico de CFD visual proporciona evidencia de que algo está sucediendo de una manera determinada.
Identificar problemas, tomar las medidas adecuadas
El CFD responde a varias preguntas específicas y, en función de la respuesta, se pueden realizar acciones para ajustar el proceso para mover el trabajo a través del sistema. Echemos un vistazo a cada una de esas preguntas aquí.
¿El equipo completará el trabajo a tiempo?
Esta pregunta solo se aplica a los CFD de período fijo. Para comprenderlo, examine la curva (o progresión) del trabajo en la última columna del panel Kanban.
En este escenario, puede ser adecuado reducir el ámbito de trabajo en la iteración si está claro que el trabajo, a un ritmo estable, no se completa lo suficientemente rápido. Puede indicar que el trabajo se ha subestimado y debe tenerse en cuenta en el siguiente planeamiento de sprints.
Sin embargo, puede haber otras razones que se pueden determinar examinando otros datos en el gráfico.
¿Cómo progresa el flujo de trabajo?
¿El equipo está completando el trabajo a un ritmo constante? Una manera de indicar es examinar el espaciado entre las distintas columnas del gráfico. ¿Son de una distancia similar o uniforme entre sí de principio a fin? ¿Parece una columna una línea plana durante un período de varios días? O bien, ¿parece "abulte"?
Mura, el término magro para líneas planas y probulaciones, significa desigualidad e indica una forma de residuos (Muda) en el sistema. Cualquier irregularidad en el sistema hará que aparezcan abultas en el CFD.
La supervisión del CFD para líneas planas y abultados admite una parte clave del proceso de gestión de proyectos teoría de restricciones. La protección del área más lenta del sistema se conoce como proceso de cuerda de búfer de tambor y forma parte de cómo se planea el trabajo.
Dos problemas se muestran visualmente como líneas planas y como abultas.
Las líneas planas aparecen cuando el equipo no actualiza su trabajo con una cadencia regular. La placa Kanban proporciona la forma más rápida de realizar la transición de un trabajo de una columna a otra.
Las líneas planas también pueden aparecer cuando el trabajo en uno o varios procesos tarda más de lo planeado. Las líneas planas aparecen en muchas partes del sistema porque si solo una parte del sistema o dos partes de un sistema tienen problemas, verá un abulto.
Líneas planas
Las cargas se producen cuando el trabajo se acumula en una parte del sistema y no se mueve a través de un proceso.
Por ejemplo, se puede producir un aumento cuando las pruebas tardan un largo período de tiempo mientras el desarrollo tarda un período de tiempo más corto, lo que hace que el trabajo se acumule en el estado de desarrollo (los aumentos indican que un paso correcto está teniendo un problema, no necesariamente el paso en el que se está produciendo el aumento).
Bombeos
¿Cómo se corrigen los problemas de flujo?
Puede resolver el problema de una falta de actualizaciones oportunas a través de:
- Diarios de pie.
- Otras reuniones periódicas.
- Programar un correo electrónico de recordatorio de equipo diario.
Los problemas sistémicos de línea plana indican un problema más difícil, aunque estos problemas son raros. Las líneas planas indican que el trabajo en todo el sistema se ha detenido. Las causas subyacentes pueden ser:
- Bloqueos de todo el proceso.
- Los procesos tardan mucho tiempo.
- Trabajo cambiando a otras oportunidades que no se capturan en la pizarra.
Un ejemplo de línea plana sistémica puede ocurrir con una característica CFD. El trabajo de características puede tardar mucho más que el trabajo en casos de usuario, ya que las características se componen de varias historias. En estas situaciones, se espera la pendiente (como en el ejemplo anterior) o el problema es bien conocido y ya lo está generando el equipo como un problema. Si se trata de un problema conocido, la resolución de problemas está fuera del ámbito de este artículo.
Los equipos pueden corregir de forma proactiva los problemas que aparecen como cargas de CFD. Dependiendo de dónde se produzca el abulte, la corrección puede ser diferente. Por ejemplo, supongamos que el aumento se produce en el proceso de desarrollo. Es posible que se produzca un problema porque la ejecución de pruebas tarda mucho más que escribir código. Los evaluadores también podrían encontrar un gran número de errores. Cuando realizan la transición continua del trabajo a los desarrolladores, los desarrolladores heredan una lista cada vez mayor de trabajo activo.
Dos formas potencialmente fáciles de resolver este problema son: 1) Cambiar a los desarrolladores del proceso de desarrollo al proceso de prueba hasta que se elimine la abulta o 2) cambiar el orden de trabajo de forma que el trabajo que se pueda realizar rápidamente se entrelaze con el trabajo que tarda más tiempo en realizarse. Busque soluciones sencillas para eliminar las abultas.
Nota
Dado que se pueden producir muchos escenarios diferentes que hacen que el trabajo continúe de forma desigual, es fundamental realizar un análisis real del problema. El CFD le dirá que hay un problema y aproximadamente dónde está, pero usted debe investigar para llegar a las causas principales. Las instrucciones que se proporcionan aquí indican las acciones recomendadas que resuelven problemas específicos, pero que pueden no aplicarse a su situación.
¿Cambió el ámbito?
Los cambios de ámbito solo se aplican a los CFD de período fijo. La línea superior del gráfico indica el ámbito de trabajo. Un sprint se carga previamente con el trabajo que se debe realizar en el primer día. Los cambios en la línea superior indican que se ha agregado o quitado el trabajo.
El escenario en el que no se puede realizar un seguimiento de los cambios de ámbito con un CFD se produce cuando se agrega el mismo número de elementos de trabajo que se quitan el mismo día. La línea seguirá siendo plana. Compare varios gráficos entre sí. Supervise los problemas específicos. Use View/configure sprint burndown para supervisar los cambios de ámbito.
¿Demasiado WIP?
Puede supervisar fácilmente si se han superado los límites de WIP desde la placa Kanban. También puede supervisarlo desde el CFD.
Normalmente, una gran cantidad de WIP aparece como un abulte vertical. Cuanto más tiempo haya una gran cantidad de WIP, más se expandirá la probula para convertirse en un óvalo. Es una indicación de que el WIP afecta negativamente al ciclo y al tiempo de espera.
Esta es una buena regla general para los trabajos en curso. No debe haber más de dos elementos en curso por miembro del equipo en un momento dado. La razón principal de dos elementos frente a los límites más estrictos es porque la realidad suele intruirse en cualquier proceso de desarrollo de software.
A veces, se tarda tiempo en obtener información de una parte interesada o se tarda más tiempo en adquirir el software necesario. Hay varias razones por las que se puede detener el trabajo. Tener un segundo elemento de trabajo para dinamizar para proporcionar algo de margen. Si ambos elementos están bloqueados, es el momento de generar una marca roja para desbloquear algo, no solo cambiar a otro elemento. En cuanto haya un gran número de elementos en curso, la persona que trabaja en esos elementos tendrá dificultades para cambiar el contexto. Es más probable que se olviden de lo que estaban haciendo, y pueden producirse errores.
Tiempo de ejecución frente al tiempo de ciclo
En el diagrama siguiente se muestra cómo difiere el tiempo de ejecución del tiempo del ciclo. El tiempo de espera se calcula a partir de la creación de elementos de trabajo para especificar un estado Completado. El tiempo del ciclo se calcula a partir de la primera entrada de una categoría de estado En curso o Resuelta para escribir una categoría de estado Completado.
Ilustración del tiempo de ejecución frente al tiempo de ciclo
Si un elemento de trabajo entra en un estado Completado y, a continuación, se reactiva, cualquier tiempo adicional que dedique en un estado Propuesto, En curso o Resuelto contribuirá a su tiempo de cliente potencial o ciclo cuando entre en una categoría de estado Completado por segunda vez.
Si el equipo usa el panel Kanban, querrá comprender cómo se asignan las columnas kanban a los estados de flujo de trabajo. Para obtener más información sobre cómo configurar la placa Kanban, vea Agregar columnas.
Para obtener más información sobre cómo el sistema usa las categorías de estado (propuestas, en curso, resueltas y completadas), consulte Estados de flujo de trabajo y categorías de estado.
Planear el uso de tiempos de entrega estimados en función de los tiempos de cliente potencial o ciclo
Puede usar el promedio de tiempos de plomo/ciclo y desviaciones estándar para calcular los tiempos de entrega.
Al crear un elemento de trabajo, puede usar el tiempo promedio de tiempo de ejecución de su equipo para calcular cuándo el equipo completará ese elemento de trabajo. La desviación estándar del equipo indica la variabilidad de la estimación. Del mismo modo, puede usar el tiempo del ciclo y su desviación estándar para calcular la finalización de un elemento de trabajo una vez que haya comenzado el trabajo.
En el gráfico siguiente, el tiempo medio del ciclo es de ocho días. La desviación estándar es +/- seis días. Con estos datos, podemos calcular que el equipo completará los casos futuros de usuario de entre 2 y 14 días después de comenzar el trabajo. Cuanto más estrecha sea la desviación estándar, más predecible será la estimación.
Widget De tiempo de ciclo de ejemplo
Identificación de problemas de proceso
Revise el gráfico de control del equipo para ver los valores atípicos. Los valores atípicos suelen representar un problema de proceso subyacente. Por ejemplo, esperar demasiado tiempo para completar las revisiones de solicitud de incorporación de cambios o no resolver rápidamente una dependencia externa.
Como puede ver en el gráfico siguiente, que muestra varios valores atípicos, varios errores tardaron más tiempo en completarse que el promedio del equipo. Investigar por qué estos errores tardaron más tiempo pueden ayudar a descubrir problemas de proceso. Solucionar los problemas del proceso puede ayudar a reducir la desviación estándar del equipo y mejorar la previsibilidad del equipo.
Widget De tiempo de ciclo de ejemplo que muestra varios valores atípicos
También puede ver cómo afectan los cambios de proceso al tiempo de cliente potencial y ciclo. Por ejemplo, el 15 de mayo, el equipo hizo un esfuerzo coordinado para limitar el WIP y solucionar errores obsoletos. Puede ver que la desviación estándar se limita después de esa fecha, mostrando una predicción mejorada.