Guía de flujo acumulado, plazo y tiempo de ciclo
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Use diagramas de flujo acumulativos (CFD) 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 Configuración de un gráfico de flujo acumulativo.
O bien, puede agregar los gráficos de control tiempo de ejecución 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 lean.
Sin embargo, muchos equipos han empezado a combinar prácticas ajustadas con Scrum u otras metodologías, lo que significa que practica lean 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, como se muestra en el gráfico siguiente.
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 en el último día del sprint, la pendiente del estado Cerrado indica si un equipo está en pista para completar el sprint. La manera más fácil de pensar en esta vista es como un gráfico de agotamiento.
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 estado o columna 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 ciclo 1
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.
Tiempo de ejecución 1
Para un proceso de flujo continuo: mide la cantidad de tiempo que tarda cuando se realiza una solicitud (por ejemplo, agregar un caso de usuario propuesto) hasta que se complete (cerrado).
Para un proceso de sprint o período fijo: mide el tiempo desde 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 especificado. Solo se aplica a los procesos de período fijo.
1 El widget CFD (Análisis) y el gráfico 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 Tiempo de ejecución y Tiempo de ciclo proporcionan estos números.
Hay una correlación bien definida entre tiempo de cliente potencial/tiempo de ciclo y 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: menos WIP, cuanto menor sea el ciclo y el tiempo de espera. Cuando el equipo de desarrollo se centra en menos elementos, reducen el ciclo y los tiempos de entrega. Esta correlación es una razón clave por la que puede y debe establecer límites de trabajo en curso en el panel.
El recuento de elementos de trabajo indica la cantidad total de trabajo en un día determinado. En un período fijo CFD, un cambio en este recuento indica el cambio de ámbito durante un período determinado. En un flujo continuo CFD, indica la cantidad total de trabajo en la cola y completada durante un día determinado.
La descomposición del trabajo en columnas de placa específicas 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á ocurriendo de una manera determinada.
Identificar problemas, realizar acciones 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. Obtenga una comprensión examinando la curva (o progresión) del trabajo en la última columna del panel.
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 está completando 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 del gráfico.
¿Cómo avanza 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 parece "abulte"?
Mura, el término magro para líneas planas y abultes, significa desigualidad e indica una forma de residuos (Muda) en el sistema. Cualquier desigualdad 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 administració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 proporciona la forma más rápida de realizar la transición del 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á una abulción.
Líneas planas
Las bombillas 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 provoca que el trabajo se acumule en el estado de desarrollo (las abulciones indican que un paso correcto tiene 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:
- Stand-ups diarios.
- 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 poco frecuentes. 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.
- Trabaje 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 trabajar en casos de usuario porque 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.
Teams puede corregir de forma proactiva los problemas que aparecen como abulciones de CFD. Dependiendo de dónde se produzca la abulción, 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 creciente de trabajos activos.
Dos formas potencialmente fáciles de resolver este problema son: 1) Desplazar a los desarrolladores del proceso de desarrollo al proceso de prueba hasta que se elimina el abulte o 2) cambiar el orden de trabajo, de modo que el trabajo que se pueda realizar rápidamente se entrelaza con el trabajo que tarda más tiempo en hacerlo. Busque soluciones sencillas para eliminar los abultos.
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 indicará que hay un problema y aproximadamente dónde está, pero debe investigar para llegar a las causas principales. Las instrucciones proporcionadas aquí indican acciones recomendadas que resuelven problemas específicos, pero que pueden no aplicarse a su situación.
¿Ha cambiado 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. También puede supervisarlo desde el CFD.
Una gran cantidad de WIP normalmente se muestra como un abulto vertical. Cuanto más tiempo haya una gran cantidad de WIP, más se expandirá el aumento 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 cierto 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 que se produzcan 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 de 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 pase 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, querrá comprender cómo se asignan las columnas a los estados de flujo de trabajo. Para obtener más información sobre cómo configurar la placa, vea Agregar columnas.
Para obtener más información sobre cómo el sistema usa las categorías de estado( Propuesta, En curso, Resuelto y Completado), 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 tiempo de cliente potencial/ciclo y las desviaciones estándar para calcular los tiempos de entrega.
Al crear un elemento de trabajo, puede usar el 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 de 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á futuros casos de usuario de aproximadamente 2 a 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 Tiempo de ciclo de ejemplo
Identificación de problemas de proceso
Revise el gráfico de controles 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 solicitudes 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 los cambios de proceso afectan 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.