Esto es lo que pasa cuando intentas medir la productividad de un programador por las líneas de código que escribe al día

Muchos equipos de desarrollo han sufrido los intentos de medir la productividad de sus programadores. Ya sea con cualquier métrica que el manager responsable haya decidido o con algún plugin instalado en el gestor de tareas que arroje números sin ningún contexto. Todo ello, con la buena intención de saber la velocidad del equipo, aunque a veces se desvia hacia dónde pierden el tiempo los desarrolladores.

Pocos programadores acaban confiando en esas métricas, incluso son el principal foco de frustración, donde se valora la cantidad en lugar de la calidad o el impacto del producto que se está desarrollando.

¿Qué pasa si implantamos una métrica donde premiamos el número de tareas cerradas?

Lo más habitual es que el equipo se enfoque en resolver los tickets más fáciles, contestando y resolviendo los bugs que menos tiempo le llevan con la única motivación de engañar a las estadísticas. Es como cuando nos dan un tirón de orejas y de repente estamos super atentos y serviciales para todo.

Aunque las métricas indican que el equipo está trabajando en la línea acordada, la calidad del producto o el alcance de los nuevos desarrollos empeora. La realidad es totalmente distinta a los números.

Obviamente, esto conlleva que los programadores no confíen en esas métricas, mientras se incrementa la deuda técnica: reutilización de código con la intención de aumentar el número de líneas, inflar el proyecto innecesariamente con tareas de poco impacto o no prestar atención a los verdaderos problemas que tarde o temprano acabarán explotando.

Número de tareas o bugs resueltos

Esta es la métrica de los francotiradores de código: marcar como resueltos decenas de tickets o hacer pequeñas tareas insignificante solo por aumentar su estadística personal. Esto no vale de nada si no va acompañado de una estimación en puntos de historia y, por supuesto, una cierta prioridad (asumiendo el impacto).

No es nada aconsejable guiarse por una métrica así, ya que tendemos a premiar la cantidad sobre calidad. No tiene el mismo impacto un desarrollador que haya estado elaborando un buena arquitectura para escalar a medio plazo o resolviendo un bug importante que afectaba a una gran cantidad de usuarios a alguien que se haya dedicado a disparar Pull Requests con pequeñas tareas insignificantes. El equipo empezará a jugar al juego de las métricas sin producir ningún código significativo.

Líneas de código producidas

La frecuencia de commits y las líneas de código de un programador junior es normalmente mayor que la de uno senior, por supuesto, aquí lo que cuenta es la relevancia y la solución adoptada. Seguir una métrica que premia cantidad conduce a soluciones a corto plazo en lugar de buscar abstracciones con menor cantidad de código. Más código suele conllevar más deuda técnica. Podéis profundizar más en el artículo publicado por Jesús Dario sobre medir la productividad de los desarrolladores.

Siguiendo este planteamiento, no podemos comparar la resolución de ciertos bugs con otros más importantes en los que hemos dedicado media mañana a reproducirlos, asegurarnos con un par de tests para que no vuelvan a ocurrir y documentarlos. Lo cual, quizás sólo representen un par de líneas de código.

¿Y qué ocurre si emprendemos un refactor y borramos más líneas de las que introducimos nuevas? Esta métrica de número de líneas de código será totalmente inútil, mientras aflora otros elementos como haber conseguido que el código sea más eficiente, más reutilizable y, definitivamente, más libre de errores probablemente.

Porcentaje de código refactorizado, incluso siendo nuevo

Existe una tensión entre el código nuevo producido y el refactorizado. En muchas ocasiones tenemos la impresión de estar rehaciendo constantemente el mismo código, ya sea código nuevo o antiguo. Existen distintos motivos:

• Que dicho código necesite ser reemplazado definitivamente (deuda técnica), obligando al programador a pasar casi obligatoriamente por allí cada vez que desarrolla una funcionalidad.

• A pesar de ser código relativamente reciente o, incluso, de la misma funcionalidad necesite ser optimizado o que la indecisión del equipo de producto fuerce una y otra vez a rehacerlo.

Existen distintas herramientas que indican, por ejemplo el número de revisiones de un fichero. Lo cual puede indicar que es el más valioso o todo lo contrario. Merece la pena echar un vistazo detallado de la salud del proyecto con herramientas como Scope Ink, Codescene o SonarQube en el CI.

Lo ideal sobre esta métrica es identificar cuál es problema principal con el que se encuentra el programador, con la finalidad de ayudar al equipo a ser más eficiente evitando caminar en círculos.

El impacto que puede conseguir un desarrollador viene de la mano de una buena planificación por parte del equipo de producto. Un buen roadmap con features donde los desarrolladores puedan dividir en tareas que cumplan el impacto deseado. En cambio, si el roadmap es inexistente o incompleto transmitirá esas dudas al equipo de desarrollo.

Tal como podéis ver en la imagen inferior, así se vería un PR de Facebook usando la herramienta de análisis de Scope Ink.

Algunas métricas a tener en cuenta, siempre usandolas a nivel de proyecto

Tal como decíamos más arriba: las métricas deben usarse como un apoyo para evaluar individualmente a los programadores. Nunca como una ciencia cierta. Además, lo fundamental es que se usen para identificar problemas en el propio proyecto, ya sea de forma interna o externa y no como una nota individual de rendimiento.

Ciclo de vida de los Pull Request.

Si cada semana dedicamos un tiempo en analizar el número de PRs abiertas, mezcladas y desplegadas podríamos ver ciertos patrones en nuestro equipo de desarrollo. Así como detectar ciertos problemas y cuellos de botella. ¿Cuál es el tiempo medio para que una PR sea mezclada?

Quizás haya un cuello de botella con el equipo de QA, no hay un compromiso firme para revisar PRs, se toman decisiones sin consultar previamente, demasiadas discusiones, etc.. Todo ello puede afectar el rendimiento del equipo y a su velocidad.

Si desde que una tarea se crea en Jira, por ejemplo, hasta que es desplegada en producción pasa demasiado tiempo uno de los factores de bloqueo puede pasar por cómo se hacen Pull Request. Si pasan demasiado tiempo de revisión o no se están separando adecuadamente cada funcionalidad. Conviene tener un monitor de actividad sobre ello y dedicar una discusión en el equipo sobre posibles impedimentos.

Deuda técnica

Conviene revisar cada cierto tiempo el porcentaje de deuda técnica que asume el proyecto. Esto se puede reflejar en un backlog actualizado con todas esas tareas fuera de producto que debemos prestar atención, ya sea porque el código es demasiado antiguo y debe ser actualizado o porque en su día asumimos una solución de una forma demasiado apresurada.

De nuevo, es una métrica del proyecto y del equipo en general. Y si quisiéramos usarla como un indicador de rendimiento individual nos costaría mucho trabajo. Más bien necesitamos tener un seguimiento constante para evitar que crezca y reducirla lo máximo posible.

No entra en las métricas de los product manager, pero cualquier Tech Lead debería revisar constantemente. ¿Cuánto nos ha costado a nivel de deuda cierta funcionalidad? ¿Cuánto hemos recortado en el MVP de producto y cuánto ha aumentado la deuda técnica?

Número de bugs

Dependiendo del tamaño del proyecto, según cómo evoluciona, suele crecer el porcentaje de bugs en producción. Ese porcentaje tiene que estar siempre presente en cada planificación, siendo capaces de detectar lo antes posible el impacto de cada uno de ellos y minimizarlo.

Los bugs representan “la velocidad negativa” del equipo, ya que resta tiempo para nuevas funcionalidades y disminuye la calidad del producto que se van a encontrar nuestros usuarios.

Debe ser siempre monitorizada a nivel de equipo para cumplir con el mayor porcentaje de crashfree del proyecto.

En conclusión: apostemos por las métricas a nivel de equipo

En definitiva, las métricas siempre son un factor superficial del equipo. Debe ser usadas como un apoyo, más bien para detectar problemas del equipo y casos extremos. Nunca como una forma de evaluar de forma cuantitativa a un programador. Ya que en muchos casos debemos tener en cuenta la parte creativa y no medible del trabajo.

El juego de las métricas, como hemos comentado en el artículo, conduce a una falsa sensación de que todo va bien, cuando realmente sólo nos estamos engañando apoyándonos en un métrica mal escogida para medir el rendimiento.

Foto de portada | Source{d}