Medir la productividad de la ingeniería es un proceso complicado: es difícil tener una idea completa de cómo los desarrolladores emplean su tiempo. Una forma común de medir la productividad es analizar métricas del sistema como DORA o SPACE. Estas pueden ser métricas extremadamente útiles para comprender la productividad del equipo en comparación con los estándares de la industria. Profundizar en cada una de esas métricas también puede proporcionar información sobre lo que está frenando al equipo. Pero a veces, también hay “bolsillos ocultos” de tiempo que los desarrolladores dedican a lo largo del día y que pueden no percibirse como un impacto en la productividad. Sin embargo, cuando empezamos a sumar esas cosas, las cifras pueden resultar alarmantes. Por ejemplo, considere la cantidad de tiempo que un desarrollador dedica a depurar una prueba inestable tratando de determinar si falló debido a su cambio o no. O el tiempo dedicado por un desarrollador que intenta resolver un error de compilación principal. Para brindar esa perspectiva, creamos una calculadora que intenta evaluar la eficiencia de la ingeniería. De ninguna manera esto proporciona un análisis completo de la eficiencia de su equipo de ingeniería. Lo que sí ofrece es un vistazo de los “bolsillos ocultos” de tiempo perdido que normalmente no aparecen en métricas de productividad más comunes. La calculadora se centra en cuánto tiempo pierden usted y su equipo debido a fallas de compilación y prueba en los flujos de trabajo de los desarrolladores. Si compara esto con las métricas de DORA, el tiempo de entrega de los cambios se ve significativamente afectado por la inestabilidad de la compilación y las pruebas. Ese impacto se puede evaluar utilizando esta calculadora. Cómo funciona Le pedimos que ingrese datos basados en sus actividades de GitHub y cómo usa las ramas de GitHub. Para explicar los cálculos reales a continuación, asignemos variables a cada uno de ellos: M – RP fusionados por día X – fallas principales en una semana T – tiempo promedio de CI F – factor de descamación % Con base en estos aportes, estimamos cuánto tiempo pierde semanalmente su equipo de ingeniería en administrar fallas de compilación y lidiar con pruebas inestables. Repasemos los resultados uno por uno. Horas perdidas para arreglar Esto calcula cuántas horas se desperdician para identificar, clasificar, corregir y hacer que la compilación pase nuevamente cuando se detecta una falla en la compilación principal. Normalmente, en un equipo grande, alguien notará e informará la compilación de la línea principal rota. Suponemos que una falla de compilación principal involucra a un promedio de 1 a 3 desarrolladores para depurar y corregir. Si consideramos un promedio de una hora para informar el problema y aplicar una solución, dedicamos a rastrear, investigar y resolver el problema. (2*T + 1) horas Eso significa que si hay X fallas por semana, dedicamos (( de tiempo de desarrollador a combatir las fallas de compilación principales todos los días. 2 desarrolladores * X/5 * (2*T + 1)) horas Horas perdidas resolviendo conflictos de fusión Las reversiones y los conflictos de fusión pueden causar más problemas. Suponiendo que hay aproximadamente un 2 % de RP que tienen conflictos de fusión durante el período de tiempo de compilación interrumpido y RP que llegan cada hora, gastaremos desperdiciados en la resolución de estos conflictos. ((2*T + 1) * X/5) M/8 ((2* T + 1) * X/5) * 0,02 * M/8 Fallos semanales de CI debido a compilaciones rotas Si el equipo no utiliza una rama dorada para basar sus ramas de funciones, probablemente crearán ramas de funciones encima de una rama principal fallida. Dado que la cantidad de RP creados durante cualquier momento sería similar a la cantidad promedio de ramas de funciones basadas en la línea principal, esto causaría cantidad de fallas de CI que ocurren todos los días. . (2*T + 1 hora) * X/5 * M/8 Es hora de resolver la CI Con aproximadamente quince minutos de contexto cambiando el controlador en cada falla de compilación, eso es horas de tiempo de desarrollador desperdiciadas cada día con fallas de CI. (2*T + 1 hora) * X/5 * M/8 * 0,25 Tiempo dedicado a volver a ejecutar pruebas inestables. De manera similar, con las pruebas inestables, el tiempo de cambio de contexto requerido para investigar si la prueba era inestable o real, y volver a ejecutar las pruebas toma un promedio de quince minutos por ejecución. Dependiendo del factor de descamación, los desarrolladores perderían horas cada día. (0,25 * M * F / 100) Mejorando la eficiencia Aunque la mayoría de estos impactan las métricas de DORA asociadas con todavía estamos apenas arañando la superficie en términos de medir las ineficiencias en los flujos de trabajo del equipo de ingeniería. El impacto de las fallas de compilación y prueba también genera retrasos en los lanzamientos que afectan las otras métricas de DORA, como y la persistencia de pruebas inestables en el sistema, lo que puede generar una mayor probabilidad de tasa de fallas. . el tiempo de entrega de cambios, la frecuencia de implementación, el tiempo para restaurar el servicio Obtenga más información sobre las métricas de DORA O aprenda más sobre sus desventajas. Construimos para resolver algunos de estos desafíos ocultos para grandes equipos de ingeniería. Hoy en día, al utilizar Aviator MergeQueue, muchas organizaciones de ingeniería pueden escalar su flujo de trabajo de fusión sin interrumpir las compilaciones. Combinando eso con un sistema de supresión de pruebas inestable como , los equipos pueden ahorrar cientos de horas de ingeniería cada semana. Aviator TestDeck También publicado . aquí
