Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Puede usar diagramas de flujo acumulativos (CFD) para supervisar el flujo de trabajo a través de un sistema. El tiempo de ciclo y el tiempo de espera son las dos métricas principales que se usan para el seguimiento. Puede extraer estas métricas de un CFD.
En este artículo se muestra cómo puede usar CFD, tiempos de ciclo y tiempos de entrega para identificar problemas en el proceso de trabajo y ayudarle a mover el trabajo a través del sistema.
- Para configurar o ver un CFD, consulte Visualización y configuración de un diagrama de flujo acumulativo.
- Para agregar un gráfico de control de plazo de entrega o tiempo de ciclo a un panel, consulte Widgets de Plazo de Entrega y Tiempo de Ciclo.
Gráficos de ejemplo y métricas principales
El CFD de flujo continuo proporciona el gráfico más favorecido por los equipos que siguen un proceso lean.
Sin embargo, muchos equipos combinan prácticas ajustadas con Scrum u otras metodologías. Como resultado, usan prácticas ágiles y esbeltas durante una iteración o sprint. En esta situación, el diagrama tiene un aspecto ligeramente diferente. Proporciona dos elementos adicionales, y muy valiosos, de información, como se muestra en el siguiente gráfico, el CFD de período fijo.
CFD de flujo continuo
Este CFD de período fijo es para un sprint completado.
La línea superior representa el ámbito establecido para el sprint. Dado que el trabajo debe completarse para el último día del sprint, la pendiente del estado Cerrado 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 agotamiento.
En el gráfico, el primer paso del proceso se representa como el área superior izquierda. El último paso del proceso se muestra en la esquina inferior derecha.
CFD de período fijo para un sprint completado
Métricas de gráfico
Los CFD muestran el recuento de elementos de trabajo agrupados por estado o columna a lo largo del tiempo. Las dos métricas principales que se usan para el seguimiento son el tiempo de ciclo y el tiempo de espera. Puede extraer estas métricas del gráfico.
Métrica
Definición
Tiempo de ciclo1
El tiempo necesario para mover el trabajo a través de un único proceso o estado de flujo de trabajo. La longitud se mide desde el inicio de un proceso hasta el inicio del siguiente proceso.
Tiempo de ejecución1
Para un proceso de flujo continuo: el tiempo desde el momento en que se realiza una solicitud (como agregar una historia de usuario propuesta) hasta que se finalice esa solicitud.
Para un proceso de sprint o de período fijo: el tiempo desde el momento en que comienza el trabajo en una solicitud hasta que se completa el trabajo (por ejemplo, el tiempo desde el estado Activo hasta el estado Cerrado).
Trabajo en curso (WIP)
Cantidad de trabajo o número de elementos de trabajo en los que se está trabajando activamente.
Ámbito
Cantidad de trabajo confirmada durante el período de tiempo determinado. Esta métrica solo se aplica a los procesos de período fijo.
1 El widget CFD que usa datos de análisis y el CFD integrado que puede ver desde un trabajo pendiente de equipo o una placa no proporcionan valores discretos de tiempo de tiempo de ejecución y tiempo de ciclo. Sin embargo, los widgets Tiempo de ejecución y Tiempo de ciclo proporcionan estos valores.
Hay una correlación bien definida entre el tiempo de ejecución o el tiempo de ciclo y WIP. Un mayor trabajo en curso (WIP) resulta en tiempos de ciclo más largos, lo que lleva a tiempos de entrega más prolongados. Lo contrario también es cierto: menos WIP da lugar a ciclos y tiempos de entrega más cortos. 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 debe establecer límites de WIP en la tabla que utiliza para realizar un seguimiento y administrar el trabajo.
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 que se encuentra en la cola y se completó durante un día determinado.
La categorización del trabajo en columnas de placa específicas muestra la cantidad de trabajo en cada área del 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. Es difícil descifrar una vista tabular de los datos. Sin embargo, el CFD visual le ayuda a comprender lo que sucede en el proceso de trabajo y por qué está sucediendo.
Identificación de problemas y toma de medidas adecuadas
El CFD proporciona respuestas a las siguientes preguntas. En función de las respuestas, puede ajustar el proceso para mover el trabajo a través del sistema.
¿El equipo completará el trabajo a tiempo?
Esta pregunta solo se aplica a los CFD de período fijo. Puede comprender si examina la curva (o progresión) del trabajo en la última columna del panel.
En este escenario, podría considerar la posibilidad de reducir el ámbito de trabajo en la iteración. Esta acción es adecuada si está claro que el trabajo no se está completando lo suficientemente rápido, suponiendo que continúa a un ritmo constante. Este escenario puede indicar que el trabajo se ha infravalorado y que debe tenerse en cuenta en el siguiente planeamiento del sprint.
Sin embargo, puede haber otras razones por las que el trabajo no se está completando lo suficientemente rápido. Puede determinar esas razones 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? ¿Hay columnas que se mantienen estables durante un período de varios días? ¿O parece que se abultan?
Mura, o la irregularidad, es el término utilizado en la metodología Lean para líneas planas y abultamientos. Mura indica una forma de desperdicio llamada Muda en el sistema. Cualquier desigualdad en el sistema hace 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. Proteger el área más lenta del sistema se conoce como el proceso de drum-buffer-rope y forma parte de la planificación del trabajo.
Dos problemas se muestran visualmente como líneas planas y como abultas.
Las líneas planas aparecen cuando el equipo no actualiza el estado de sus elementos de trabajo con una cadencia regular. El panel que se usa para realizar un seguimiento y administrar el trabajo proporciona la manera 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 cuando solo una o dos partes tienen problemas, se puede observar un abultamiento.
Líneas planas
Las acumulaciones se producen cuando el trabajo se acumula en una parte del sistema y no se desplaza a través del proceso.
Por ejemplo, un abultamiento puede producirse cuando las pruebas tardan mucho tiempo, mientras que el desarrollo toma menos tiempo. El resultado es que el trabajo se acumula en el estado de desarrollo. Bulges indican que un paso siguiente tiene un problema, no necesariamente el paso en el que se está produciendo la protuberancia.
Bombeos
¿Cómo se corrigen los problemas de flujo?
Puede resolver el problema de una falta de actualizaciones oportunas realizando las siguientes acciones:
- Mantener reuniones diarias
- Celebración de otras reuniones periódicas
- Programación de 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 se detiene el trabajo en todo el sistema. Las causas subyacentes pueden incluir los siguientes problemas:
- Bloqueos de todo el proceso
- Procesos que tardan mucho tiempo
- El trabajo está cambiando hacia otras oportunidades que no se reflejan en el tablero
Un ejemplo de estancamiento sistémico puede ocurrir en un CFD de características. El trabajo en funcionalidades puede tardar mucho más tiempo que el trabajo en historias de usuario, ya que las funcionalidades se componen de varias historias de usuario. En estas situaciones, se espera la tendencia (como en un ejemplo anterior), o el problema es conocido y el equipo ya lo ha planteado. 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. La corrección adecuada puede depender de dónde se produzca el abulto. Por ejemplo, supongamos que el aumento se produce en el proceso de desarrollo. Puede que se esté produciendo un abultamiento porque las pruebas están tomando significativamente más tiempo que escribir el 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.
Hay dos formas potencialmente fáciles de resolver este problema:
- Cambie los desarrolladores del proceso de desarrollo al proceso de prueba hasta que se elimine el abulto.
- Cambie el orden de trabajo. Concretamente, intercala trabajos que se pueden realizar rápidamente con aquellos que requieren más tiempo.
Busque soluciones básicas para eliminar los abultos.
Nota:
Dado que pueden producirse varios escenarios que provocan que el trabajo continúe de forma desigual, es fundamental realizar un análisis real del problema. El CFD puede avisarle que existe un problema. También puede avisarle aproximadamente dónde está el problema, pero debe investigar para llegar a las causas principales. Esta guía proporciona acciones recomendadas que resuelven problemas específicos, pero es posible que las soluciones no se apliquen 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 va a realizar en el primer día. Los cambios realizados en la línea principal indican la adición o eliminación de tareas.
En un escenario determinado, no se puede realizar un seguimiento de los cambios de ámbito con un CFD. Ese escenario se produce cuando se agrega y quita el mismo número de elementos de trabajo en el mismo día. La línea permanece plana en este caso.
Para realizar un seguimiento de los cambios de ámbito en este caso, realice las siguientes acciones:
- Compare varios gráficos entre sí.
- Supervise problemas específicos.
- Use la reducción de sprint para supervisar los cambios de ámbito.
¿Hay demasiado WIP?
Puede supervisar fácilmente la placa para determinar si se superan los límites de WIP. También puede supervisar los niveles de WIP mediante 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 expande el abultamiento adoptando una forma ovalada. Este comportamiento es una indicación de que el WIP afecta negativamente al ciclo y al tiempo de espera.
Esta es una buena regla general para WIP: no debe haber más de dos elementos en curso por miembro del equipo en un momento dado. La razón principal para usar un límite de dos elementos, no un límite más estricto, es que la realidad suele intruirse en el proceso de desarrollo de software.
A veces se tarda tiempo en obtener información de una parte interesada o adquirir el software necesario. Hay varias razones por las que se puede detener el trabajo. Tener un segundo elemento de trabajo al que cambiar puede ofrecer algo de flexibilidad. Si ambos elementos están bloqueados, es el momento de generar una marca roja para desbloquear algo, no solo cambiar a otro elemento. Tan pronto como haya un gran número de elementos en curso, la persona que trabaja en esos elementos puede tener dificultades para cambiar el contexto. Es probable que se olviden de lo que estaban haciendo, lo que puede provocar 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 inicia cuando se crea un elemento de trabajo y finaliza cuando el elemento de trabajo entra en una categoría de estado Completado. El tiempo de ciclo se inicia cuando un elemento de trabajo entra por primera vez en una categoría de estado En curso o Resuelto. El tiempo de ciclo finaliza cuando el elemento de trabajo entra en una categoría de estado Completado.
Si un elemento de trabajo entra en una categoría de estado Completado y luego se reactiva, sus tiempos de entrega y ciclo se ven afectados. Cualquier tiempo adicional que pase en una categoría de estado Propuesto, En curso o Resuelto contribuye a sus tiempos de entrega y de ciclo.
Si el equipo usa un panel para realizar un seguimiento y administrar el trabajo, ayuda a 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, consulte Administrar columnas en la placa.
Para obtener más información sobre cómo el sistema usa las categorías de estado( Propuesta, En curso, Resuelta y Completada), consulte Acerca de los estados de flujo de trabajo en trabajos pendientes y paneles.
Estimar tiempos de entrega según los tiempos de entrega anticipada y ciclo.
Puede usar el promedio de los tiempos de espera y de ciclo junto con las desviaciones estándar para estimar los tiempos de entrega.
Al crear un elemento de trabajo, puede usar el tiempo medio de tiempo de ejecución de su equipo para calcular la fecha de finalización de 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 después de que comience el trabajo.
Widget Tiempo de ciclo de ejemplo
En el gráfico siguiente, el tiempo medio del ciclo es de ocho días. La desviación estándar es de seis días. Con estos datos, puede estimar que el equipo finaliza las historias de usuario futuras 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.
Identificación de problemas de proceso
Los valores atípicos suelen representar un problema de proceso subyacente. Algunos ejemplos incluyen esperar demasiado tiempo para revisar las solicitudes de incorporación de cambios o no resolver rápidamente una dependencia externa. Revise el gráfico de controles del equipo para ver los valores atípicos.
Widget De tiempo de ciclo de ejemplo que muestra varios valores atípicos
En el gráfico siguiente se muestran varios valores atípicos, ya que varios errores tardaron más tiempo que el promedio en completarse. Investigar por qué estos errores tardaron más tiempo podrían ayudar a descubrir problemas de proceso. Solucionar los problemas de proceso puede ayudar a reducir la desviación estándar de su equipo y mejorar la previsibilidad del equipo.
También puede ver cómo los cambios de proceso afectan a los tiempos de entrega y ciclo. Por ejemplo, el 15 de mayo, el equipo realizó 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.