Cinco mejores KPI de ingeniería de software, y cómo se engañan

Por Bill Harding,Programador/CEO
Publicado el 31 de marzo de 2020.Última actualización el 17 de abril de 2020.

Cuando la gente habla de KPIs de ingeniería, hay dos tópicos contradictorios que uno escucha a menudo:

Lo que se mide mejora.-Peter Drucker

Y

Cuando una medida se convierte en un objetivo, deja de ser una buena medida.-Ley de Goodhart

Ambos enunciados describen en parte los KPI de ingeniería, pero en conjunto implican que es posible utilizar la medición para mejorar. ¿Cómo puede un gestor orientado a los datos salvar esta brecha?

La mala noticia es que se necesita un cierto compromiso de aprendizaje, especialmente para aquellos que vienen de roles distantes (es decir, no técnicos).La buena noticia es que las métricas cuidadosamente elegidas pueden y siguen funcionando a pesar de «convertirse en un objetivo». De hecho, para muchas de las métricas que recomendaremos, cuanto más «juegue el sistema» un empleado, más se servirán los intereses de la empresa a largo plazo. El objetivo final es que las métricas sigan funcionando mientras se «juegan». Hay cinco métricas que cumplen este requisito.

Público objetivo: Gestor orientado a la acción

Cualquier gestor que haya intentado arrancar más tickets completados a su equipo de ingeniería conoce la lucha.Quieren tomar acciones justas y respaldadas por datos que mejoren su velocidad. Saben que tomar decisiones basadas en instintos viscerales es caro y poco escalable. Sin embargo, cuando miran su lista de tareas pendientes, está llena de tareas que parecen más urgentes que «mejorar la medición». En la práctica, la adopción de la medición a menudo se produce después de un fracaso catastrófico, como una versión con errores o la constatación de que un desarrollador no ha cerrado ningún ticket en un mes.

Incluso cuando está claro que hay que medir, es ambiguo por dónde empezar. Se puede buscar en Google «KPI de ingeniería», hacer clic en toda la primera página de resultados y no tener claro qué pasos hay que dar. Tomemos como ejemplo la métrica «Velocidad del equipo», que se anuncia a menudo. Casi todos los resultados de Google recomiendan medir la «velocidad del equipo», pero nadie quiere decir si se mide en… ¿tickets cerrados? ¿Líneas de código? ¿Puntos de historia? Sea lo que sea, los directivos no tienen tiempo para averiguarlo. Necesitan pasar de esta montaña de 15.000 pies de teoría a algo que puedan entender, en lo que puedan confiar y de lo que se puedan beneficiar… preferiblemente de forma inmediata.

La premisa organizativa de este artículo es que usted es un directivo que quiere entender las métricas de la ingeniería del software lo suficientemente bien como para hacer que su equipo sea más eficaz. Ser un gerente significa que está demasiado ocupado para aprender sobre la teoría, excepto cuando se vincula directamente a cómo puede beneficiarse de esa teoría.

Las métricas deben ser prácticas para que las empresas reales las prueben

Antes de escribir este artículo, digerimos las métricas propuestas por los 20 primeros resultados de Google en el dominio de las métricas de software. Como se puede imaginar, cada fuente tenía sus propias teorías sobre las métricas más importantes.Sus artículos suelen agrupar las métricas en grupos como «métricas de proceso» y «métricas de proyecto». Seguiremos su ejemplo en cuanto a la agrupación de métricas, pero nuestros grupos serán «métricas de calidad» y «todo lo demás».

Aquí está lo que se califica como métrica de calidad:

  • Valor de negocio.¿Es posible trazar una línea recta desde la métrica => valor de negocio creado?
  • Medible.¿Podemos definir un número específico y sus unidades de medida (por ejemplo, ¿Puede informar regularmente de las acciones que conducen a resultados positivos? Preferiblemente con un mínimo de falsos positivos?
  • Disponible/conveniente.¿Puede un equipo de ingeniería de software medio acceder a esta métrica sin cambiar sus procesos de desarrollo existentes?
  • Popular.¿Tiene suficientes seguidores para estar bien documentado y ser creíble?
  • La inclusión en el cubo de las «métricas de calidad» requiere los cinco puntos anteriores, además de una respuesta satisfactoria a nuestra pregunta de rigor: si confiamos en esta métrica, y los desarrolladores la optimizan posteriormente, ¿qué ocurre entonces? En los años que llevamos construyendo e iterando nuestra propia métrica de desarrollo («Impacto de la línea»), hemos aprendido que los subproductos tóxicos son una consecuencia esperada de la medición, a menos que la métrica esté alineada con precisión con el valor empresarial a largo plazo.Como ejemplo, más adelante mostraremos cómo los desarrolladores que intentan jugar con la métrica «Tiempo de entrega» provocan una menor transparencia para la dirección.

    KPIs de ingeniería de calidad

    Aquí hay cinco métricas de software que marcan todas las casillas para ayudar a los gestores a dirigir un equipo más eficiente.

    🏦 OKR-driven

    Plantilla de ejemplo de OKR

    Una de las muchas plantillas de ejemplo de OKR disponibles a través de Weekdone en Okrexamples.com

    Cualquier lista que se centre en maximizar el valor del negocio debería empezar por aquí. Empresas líderes como Google utilizan los OKR como eje principal para evaluar a los ingenieros senior. El inconveniente de las métricas basadas en los OKR es que, por definición, son específicas de las particularidades del negocio. Esto hace que sea imposible generalizar una fórmula para capturarlas, o generalizar el camino por el que van a ser jugadas.

    ¿Cómo jugar? El riesgo de que los OKRs sean jugados es bajo ya que suelen estar centrados en el negocio. El principal peligro de las métricas basadas en los OKR es que, dado que suelen formularse de forma puntual (o periódica), pueden ser menos fiables que las métricas que han sido examinadas durante años. Por ejemplo, establecer un OKR para «introducir menos de 10 errores al mes» podría ser una trampa si no se lanzan nuevas características. Suponiendo que ambas partes actúen de buena fe, en la práctica el juego de los OKR debería ser poco frecuente.

    ¿Cómo conseguirlo?A través de los cuadros de mando de medición existentes, o trabajando con empresas comoWeekdon, que ayudan a inspirar los OKR.

    📐Impacto de la línea

    Ejemplo de KPI de ingeniería Impacto de la línea: métrica fiable del código fuente

    10 repos graficados por su Impacto de la línea, una métrica que cuantifica el ritmo al que evoluciona el código fuente,imagen cortesía de GitClear

    El Impacto de la línea es una métrica diseñada para medir cuánta energía cognitiva se está poniendo en el desarrollo de software.Este vídeo ofrece una explicación ilustrada de cómo es posible. La explicación breve es que el impacto de línea anula toda la actividad intersticial («churn») que se produce a medida que se desarrolla una característica, dejando una representación concentrada del trabajo realizado. El impacto de la línea se conserva en todos los lenguajes, por lo que se necesita una cantidad de tiempo constante para generar el impacto de la línea, independientemente de que el desarrollador escriba en Java, Python, Javascript o cualquier otro lenguaje de programación importante (más de 30).

    En términos de valor empresarial, el impacto de la línea es paralelo a los puntos de historia: ilustra cómo el coste de una tarea fluctúa en función del desarrollador al que se asigna. A partir de esto, un gestor comprometido puede utilizar el informe de Expertos en el Dominio para hacer coincidir las Jiras con los expertos en la materia, lo que puede acelerar drásticamente la velocidad del producto.

    ¿Cómo jugar con ella? Cualquier métrica que reivindique las «Líneas de Código» (LoC) como fuente de datos (como hace el Impacto de Línea) merece ser abordada con precaución. Por eso GitClear ha creado las mejores herramientas de revisión de código del mercado: para que los gestores y los desarrolladores puedan revisar cómo se reparte el impacto de las líneas por cada compromiso y por cada archivo. La transparencia es un potente antídoto para combatir el juego.

    La protección adicional viene en forma de notificaciones que se activan cuando un desarrollador contribuye con trabajo a una velocidad inusual. Estas y otras medidas han dificultado lo suficiente el uso de Line Impact como para que GitClear no haya recibido todavía ningún cliente que haya informado de que su equipo ha utilizado Line Impact con éxito.Dicho esto, sería poco sincero afirmar que la métrica es de alguna manera impermeable a la manipulación, por lo que aquí hay una lista de caminos conocidos por los que se puede acumular un rápido Impacto en la Línea.La idea es que si un desarrollador escribe pruebas, elimina el código antiguo y añade documentación, ganará una gran parte del Impacto en la Línea.

    ¿Cómo conseguirlo? Si te gusta, los precios comienzan en $ 9 por desarrollador activo.Ver un breve video explicativo sobre Line Impact aquí.En la versión prem disponible.

    🎲 Story Points

    ingeniería KPIs: Informe de burndown de Jira

    Informe de «release burndown» basado en Story Points, disponible a través de Jira

    Los Story Points podrían reclamar ser el más «clásico» de los KPIs de ingeniería. Hay muchas formas diferentes de calcular los Story Points. Todas las formas se refieren a una estimación del tiempo esperado del desarrollador para completar alguna tarea. Los gestores pueden utilizar los Puntos de Historia para calcular los costes que implica una tarea, por ejemplo, si un desarrollador gana 10.000 dólares al mes, el ticket se estima en 10 Puntos de Historia = la mitad del mes, entonces el coste es de 10.000 dólares * 0,5 = 5.000 dólares.El uso de alguna versión de ese cálculo ayuda a priorizar las tareas en función de las que producen la mayor proporción de Valor Proyectado/Coste de Implementación Proyectado.

    ¿Cómo jugarlo? La forma más fácil de «jugar» con los Puntos de Historia es que el equipo de desarrolladores sesgue la escala de valoración, normalmente para sobreestimar la dificultad. Una opción para solucionar esto es permitir que las tareas se seleccionen en un «mercado de tareas», donde las tareas sobrevaloradas pueden repartirse uniformemente entre los desarrolladores para mantener la calibración relativa. Otra forma de solucionarlo es recalibrar regularmente la constante utilizada para traducir los Story Points en «días de desarrollador». Tenga en cuenta que, dado que la implementación de los Story Points a menudo difiere según el equipo, no es aconsejable utilizarlos para comparar el rendimiento entre equipos.

    ¿Cómo conseguirlo?La mayoría de los gestores de incidencias de este lado de GitHub permiten especificar Story Points. En cuanto a su visualización, Jira ofrece un «informe de velocidad de nueva generación» dedicado a mostrar los puntos de historia completados a lo largo del tiempo. GitClear también ofrece gráficos rudimentarios (por el momento) que ilustran los Story Points completados a lo largo del tiempo.

    🐞 Tasa de Bugs / Defectos Escapados

    Esta métrica es definida de varias maneras por varias fuentes, pero todas llegan a la misma pregunta esencial: ¿cuántos bugs están saliendo al mundo, y qué tan bien estamos respondiendo a ellos?Stackify lo relaciona en términos numéricos específicos:

    Tu tasa de escape de defectos se expresa como un porcentaje basado en cuántos defectos encuentras antes de que lleguen a producción o cuántos llegan a producción, como prefieras. Cada proyecto de software y equipo será diferente, pero sugerimos que se esfuerce por encontrar el 90% de todos los defectos antes de que lleguen a la producción.

    La definición de Stackify hace la suposición de que uno designará un campo en su seguimiento de problemas para capturar en qué fase de desarrollo se produjo el error. Para los equipos que no tienen el tiempo para establecer y rastrear las fases de desarrollo, una definición sustituta puede ser:

    ¿Cuántas veces el código creado en una nueva característica se convierte en código cambiado en el curso de la resolución de un error?

    Los usuarios de GitClear disponen de datos para responder a esta pregunta, pero es difícil de calcular manualmente (si no se es usuario de GitClear). Un desarrollador puede encargarse de un mayor número de tickets pequeños, pero cada ticket introduce un riesgo incremental de errores si no tiene cuidado. El riesgo de utilizar la tasa de errores es que necesita un contrapeso para el «progreso», como los puntos de historia o el impacto de la línea, de lo contrario un desarrollador podría quedarse con un solo problema durante todo el sprint, asegurando una tasa de errores del 0%.

    ¿Cómo conseguirlo?Si su equipo tiene el ancho de banda para etiquetar los problemas por la fase de desarrollo en la que se produjeron, entonces los Defectos Escapados se pueden calcular manualmente a través de cualquier rastreador de problemas. GitClear es otra opción disponible para calcular el porcentaje de características que se convierten en errores.

    ✅ Pull Request Completion Rate

    Ejemplo de KPI de ingeniería Pull Requests: estadísticas en GitClear

    Una muestra de las estadísticas de pull request proporcionadas por GitClear

    ¿Qué porcentaje de pull requests se cerraron dentro de una semana de haber sido abiertos? Esta pregunta incluye otras más detalladas, como «¿está el equipo comprometido en responder rápidamente a las nuevas solicitudes de extracción?», «¿son capaces de cooperar?» y «¿han pulido los desarrolladores su código antes de enviarlo para su fusión?»

    ¿Cómo se puede jugar? Esto es relativamente difícil de jugar, pero debe ser contrarrestado por una fuerza propulsora como los Puntos de Historia o el Impacto de Línea, de lo contrario todos los incentivos del equipo serán para pulir el trabajo en lugar de enviarlo (o someterlo a la revisión del PR).

    ¿Cómo conseguirlo?Todos los proveedores de Engineering Insight de «marca» (GitClear, Pluralsight, Code Climate, Pinpoint) ofrecen estadísticas que ilustran la eficiencia del proceso de pull request de un equipo.Ayudamos a comparar los proveedores aquí.

    Menciones honoríficas

    Debajo de las métricas de «nivel superior», encontramos un nivel intersticial. Se trata de métricas que poseen características deseables junto a importantes carencias. Pueden seguir aportando valor, siempre que un gestor sepa lo suficiente como para tener en cuenta sus limitaciones.

    Tiempo de espera/Tiempo de ciclo

    Gráfico de tiempo de espera visualizado a través de Azure Devops

    Aunque aparece (¡dos veces!) en la lista de las 5 principales métricas de Pluralsight, el tiempo de ciclo es una buena idea que es muy susceptible de ser jugada.

    El «Lead Time» se define más a menudo como «¿Cuál es el intervalo entre el momento en que se archiva una tarea en el issue trackery cuando se entrega al cliente?» Su primo, el «Cycle Time», es un subconjunto del Lead Time, definido como «el tiempo que transcurre entre el momento en que el equipo de producto lo saca de la cola y el momento en que llega a producción».

    ¿Cómo jugarlo? El rendimiento del Lead Time depende en cierta medida del mecanismo por el que se archivan las Jiras, lo que significa que su aplicabilidad entre equipos es baja. El tiempo de ciclo depende de las convenciones por las que el committer elige hacer su primer commit. Por lo tanto, esta métrica es fácil de jugar si un desarrollador guarda sus commits localmente y los libera en una ráfaga de trabajo inmediatamente antes de enviar el PR. Este fallo es lo que relega la duración del ciclo a la sección de «menciones honorables». Tampoco es lo ideal: al incentivar a un desarrollador a guardar sus commits sin empujarlos, es imposible que los compañeros de equipo intervengan mientras ese trabajo está en curso.Este efecto secundario reduce la transparencia entre un gestor y sus desarrolladores.

    ¿Cómo conseguirlo?Azure Devops Services proporciona el gráfico que aparece arriba.Jira también ofrece una versión del mismo.Todas las principales ofertas de Engineering Insight (GitClear, Pluralsight, Code Climate Velocity, Pinpoint) implementan alguna versión del cálculo del Lead Time.

    Cobertura de pruebas

    Tratar de capturar alguna medida de cobertura de pruebas es un objetivo razonable a considerar. Sin embargo, no llega a ser una métrica de primer nivel por dos razones:

  1. Es una solución incompleta. Las pruebas adecuadas deben incluir pruebas funcionales y de integración junto con las pruebas unitarias, y ninguna solución automatizada puede saber qué páginas deben ser visitadas dentro de la aplicación o el sitio web, esto todavía requiere la dirección humana
  2. Es muy difícil de relacionar con las métricas de negocio de primera línea. La cobertura de las pruebas es digna de ser evaluada como parte del plan de un Desarrollador Líder para monitorear la calidad del código, pero no se conecta con el valor del negocio directamente como para hacer el corte por sí mismo. Una métrica relacionada, pero más funcional para el negocio, para rastrear los defectos del código es la «Tasa de Bichos / Defectos Escapados».

Métricas de «Todo lo demás»

La lista anterior es relativamente corta comparada con el corpus de métricas anteriores que han sido propuestas por otros autores.En aras de la exhaustividad, vamos a repasar algunas de las métricas más mencionadas en otros lugares, y por qué no pasaron el corte.

Velocidad del equipo

Esta fue una de las métricas más populares citadas por otros artículos. Está recomendada porTechBeacon,InfoPulse y SeaLights.io.Sin embargo, los autores parecen recelosos a la hora de definir las unidades de esta importante métrica.TechBeacon la define como «cuántas «unidades» de software suele completar el equipo en una iteración». No es sotangible. InfoPulse no intenta especificar las unidades. SeaLights dice que las unidades son «Story Points». Por lo tanto, llegamos a la conclusión de que la noción de «velocidad» es adecuadamente capturada por los Puntos de Historia, o el Impacto de la Línea por aproximación.

Código Churn

El CEO de GitPrime (ahora adquirido por Pluralsight) fue uno de los que abogó por considerar el Code Churn.Argumentamos en respuesta que las implicaciones del Code Churn están por todo el mapa, lo que hace muy difícil actuar sobre el alto churn. Las métricas tienen que ser procesables.

Brease/Sprint Burndown

SeaLights e InfoPulse recomiendan prestar atención a la tendencia de un equipo hacia sus objetivos de sprint.Estamos de acuerdo en que esto es importante, pero ya está cubierto por la sección «Story Points» anterior.

Tiempo medio de reparación / Tiempo medio entre fallos

Entre el puñado de artículos que defienden estas métricas, ninguno se aventura a describir en qué unidades se basa la métrica, o qué servicio se puede utilizar para recopilar estos puntos de datos.La investigación encuentra que Atlassian ofrece un artículo de ayuda sobre el tema.Si este artículo no tuviera ya 2.500 palabras, el MTTR podría entrar en la sección de «Menciones Honoríficas». Pero no es fácil de relacionar con el valor de negocio, y no es straightforwardfor un equipo promedio para obtener acceso a sin cambiar sus rutinas.

Nos perdimos algo?

Leave a Reply

Deja una respuesta

Tu dirección de correo electrónico no será publicada.