Introducción
Una de las métricas clave que utilizamos para evaluar y optimizar la eficiencia del flujo de trabajo es el Cycle Time. En este artículo, exploramos qué es el Cycle Time, cómo se descompone y cómo puedes utilizar esta métrica para impulsar mejoras en la productividad de tu equipo.
¿Qué es el Cycle Time?
El Cycle Time es el tiempo total que toma desde que se comienza con el desarrollo de una tarea hasta que esta se despliega en producción. Está influido por varias partes del ciclo de desarrollo de software (SDLC), por lo que es necesario descomponerlo para poder analizarlo correctamente.
En términos generales, siempre vamos a buscar a tener un Cycle Time lo más bajo posible. Lo que buscamos con esto es aumentar el throughput en el desarrollo. Es decir, la tasa a la que está fluyendo el trabajo de comienzo a fin.
También es importante destacar que el Cycle Time es una de las 4 métricas DORA, lo cual refuerza su relevancia. Al ser tan ampliamente utilizada, nos permite realizar una comparación con el resto de la industria.
Componentes del Cycle Time
El Cycle Time se divide en varias fases clave, cada una representando una etapa distinta en el ciclo de vida de una tarea de desarrollo:
Coding Time: Este es el tiempo que toma desde que se inicia el desarrollo de una tarea hasta que el código está listo para ser revisado (es decir, un pull request que está ready for review).
Pickup Time: Refleja el tiempo que pasa desde que el código está listo para revisión hasta que un revisor comienza a revisarlo.
Review Time: Mide el tiempo que lleva desde el inicio de la revisión del código hasta que está aprobado.
Merge Time: Es el tiempo que transcurre desde que el código es aprobado hasta que hacemos merge con la rama principal.
Deploy Time: Finalmente, este es el tiempo que pasa desde que el código está merged hasta que se hace el deploy en producción.
Interpretación y Mejora del Cycle Time
Junto con buscar un Cycle Time bajo, también queremos que sea uniforme. Esto significa que buscamos que las tareas tomen un tiempo similar en completarse
¿Y por qué nos interesa que el Cycle Time sea bajo y uniforme? Podemos entender que el desarrollo de software con sus distintas etapas es una cadena de producción, la cual queremos hacer lo más eficiente posible, y aumentar el throughput de ésta. Sabemos que para esto tenemos que tener bajo inventario y que las tareas tienen que pasar de etapa en etapa sin detenerse más tiempo del necesario. Si alguna de estas dos cosas ocurren, no solo será lenta esa tarea en particular, si no que retrasará el avance de todas las tareas.
Identificación de Cuellos de Botella
Analizar cada subciclo del Cycle Time te permite identificar exactamente dónde se encuentran los cuellos de botella en tu proceso de desarrollo. Por ejemplo, si el Review Time es consistentemente alto, podría indicar que necesitas cambiar la manera en que estos se están asignando, o la metodología de revisión en general.
De los 5 subciclos del Cycle Time, queremos dedicarle el tiempo y esfuerzo en el Coding y el Review, manteniendo estos tiempos dentro de un rango controlado. Los otros 3 subciclos, sí queremos que sean lo más cercano a 0 posible, por lo que ahí ya tenemos mucho espacio para optimizar, y serán nuestros primeros accionables para aumentar la productividad de los equipos.
Cómo se calcula el Cycle Time
Hay distintos eventos que gatillan el inicio y fin de cada uno de los subciclos, vamos a revisarlos uno a uno.
Coding time: comienza cuando una tarea pasa a estado "En Progreso" (In Progress), o bien en el momento del primer commit. Como queremos capturar el inicio de este subciclo lo más temprano posible, se considera el evento que ocurra primero.
Para pasar del Coding Time al Pickup Time, hay tres posibles eventos:
Pull Request se marca como "Listo para revisión" (Ready for review)
Pull Request se asigna a algún revisor
Tarea pasa a estado "En Revisión"
El Pickup Time finaliza con el primer evento de revisión, y con esto comienza el Review Time. Para dar por terminado el proces de revisión, también hay tres posibles eventos:
Con la última aprobación que obtenga el Pull Request
Con la primera aprobación
Con la última revisión
La prioridad por defecto de estos eventos es la que se presenta aquí, pero puede se puede personalizar en los Ajustes de la Organización.
Al terminar el proceso de revisión comienza a contabilizarse el Merge Time, el cual finaliza en el momento en que se hace merge del Pull Request hacia la rama principal de desarrollo, con lo cual se da inicio al Deploy Time.
Por último, para dar por finalizado el último subciclo - y con eso también a todo el Cycle Time - se considerará el momento en que el Pull Request pase a la rama de producción.
Si se quiere tener un Deploy Time más preciso, y que considere también los tiempos del pipeline que efectivamente deja el código en estado productivo, se puede utilizar también un endpoint de la API de Teambit.
Conclusión
El Cycle Time es una métrica poderosa para entender y mejorar la eficiencia de tu flujo de trabajo de desarrollo. Al descomponerlo en sus componentes y analizar cada fase, puedes identificar áreas específicas para optimizar, acelerando así el proceso de entrega de software y mejorando la productividad general del equipo.
En Teambit, estamos aquí para ayudarte a sacar el máximo provecho de tus métricas de productividad. Utiliza el Cycle Time para detectar y eliminar cuellos de botella, y verás cómo tu equipo logrará continuamente aumentar su capacidad de entrega.