Cómo Evaluar a un Buen Desarrollador de Software: Métricas Clave y Deuda Técnica

Una de las cosas más habituales en las que todo el mundo, que dirige proyectos, falla es en la evaluación técnica de los desarrolladores. A pesar de ser crítica es muy difícil encontrar un proyecto que no use la técnica CMVS o "¿como vas?". Realizar profesionalmente esta evaluación supone disponer de unas métricas actualizadas de cada miembro del equipo y del proyecto.

Para no caer en intuiciones, o justificaciones imposibles de algo que no se sabe medir, es necesario trabajar siempre con datos, que te aseguran una objetividad y un paraguas que te puede facilitar amparar a tu equipo en situaciones complicadas que todo proyecto vive.

¿Como conseguir métricas efectivas del proyecto?

Empecemos por las métricas más usadas, que no son siempre las mejores...

Velocidad de desarrollo

Esta métrica procede del mundo agile, en todos los cursos que impartimos es sujeto de debate... y es complicado disponer de este valor si no se cumple correctamente la metodología y si el equipo no está entrenado para actuar como debe.

Consiste en saber cuantos "Puntos de historia" es capaz de hacer en cada sprint (SCRUM) el equipo. Aplicar esto a un equipo kanban es más complejo. Es una métrica que requiere un tiempo en conseguirse, pues depende del grado de autoorganización del equipo. Cuanto más expertise posee el equipo en trabajo en equipo más preciso es este valor.

En una encuesta realizada recientemente a 20 scrum-masters y project managers todos sin excepción evaluaban el rendimiento de cada desarrollador según el número de historias o tareas que cada miembro ejecutaba, (algo en conflicto con agile pues las historias son multidisciplinares para su cumplimiento, lo que significa que necesitan varios actores). Por otro lado tampoco indicaban el marco de trabajo en dichas historias. Esto resultaba de nuevo en un sentimiento de justificación de una intuición y muy ineficaz para una evaluación objetiva.

Otra forma aún muy habitual es medir las historias en horas lo cual se puede hacer de 2 formas: el project manager decide la duración de cada una, y la segunda es consensuadamente por el equipo. Obviamente la segunda es superior a la primera en cuanto a colaboración, pero no mejora la precisión del resultado.

Esto fue estudiado por Daniel Kahneman, ganador de un premio Nobel, en su tesis de "la Falacia de la Planificación" que describe la tendencia que presentan las personas y las organizaciones a subestimar el tiempo que durará una tarea, incluso sabiendo que tareas similares han tardado más tiempo en el pasado. Está demostrado que nadie es capaz de predecir el tiempo en realizar una tarea que se estime por encima de 1 jornada. Por lo tanto, si quieres engañarte... sigue usando este sistema.

Deuda Técnica provocada

Este es uno de los factores con más seguidores para evaluar técnicamente a un desarrollador. Obviamente es complejo, pues se trata de medir el impacto que el desarrollador provoca conscientemente o no en el rendimiento del desarrollo. Esta se produce en cada commit que realiza ya sea por desconocimiento de buenas prácticas, el uso de frameworks obsoletos o demasiado "verdes", o por una codificación sin testar adecuadamente.

Podemos usar métodos indirectos, o forenses,  para determinar la deuda técnica:

• Detectar la reducción de la velocidad de desarrollo,  
• Medir diferencia de satisfacción del usuario.

Está bien saber que hay deuda técnica... pero nos pagan por evitarla, ¿Verdad?

Metodos directos:

• Incremento de bugs por sprint. Esto incluye aquellos bugs que fueron generados en sprints anteriores y no fueron atendidos.
• Complejidad del código. El código puede estar libre de bugs, pero si su diseño no sigue buenas prácticas como Clean Code, o Solid el mantenimiento se ve muy perjudicado y esto implicara inevitablemente una caída del rendimiento del producto, y lo que es peor: incrementa los tiempos en producir nuevas mejoras. Esto se debe al incremento de la Carga Cognitiva que el desarrollador debe asumir para analizar el código y adaptarlo a los nuevos requerimientos. No solo una mala práctica del desarrollador aumenta la carga cognitiva, sino también:
•   Una mala definición de los requisitos (historias de usuario),
•  un acoplamiento elevado de módulos por no definir una arquitectura adecuada (monolitos),
•  y el caso contrario: un exceso de modularización sin control,
•  o el "postureo" técnico de algunos desarrolladores en probar nuevos frameworks innecesarios.

Todo esto provoca que el diferencial de complejidad se dispare absurdamente.

¿Como evaluar por tanto un buen desarrollador del malo?

Si me has seguido hasta aquí sabes la respuesta: Aquel que genera menor deuda técnica.

El buen desarrollador, en situaciones normales, no es quien mejor comunica, ni el que siempre habla en las reuniones, ni el más asertivo hacia el cliente, ni el que parece mas comprometido porque es puntual y pone la cámara en los dailys sin que se le tenga que pedir... por favor dejad de considerar estas cosas.

El buen desarrollador es el que:

• Asume compromisos tras un análisis adecuado
• Cumple sus compromisos sin sacrificar la calidad del código
• Su código posee una cobertura por encima del 90% (unit testing)
• Genera pocos bugs en cada sprint y su código cumple los principios Clean Code y SOLID.
• Expone su código a prácticas como CODE REVIEW por otro compañero
• Demuestra interés por aprender nuevos frameworks y arquitecturas que aceleren el desarrollo estudiando los riesgos que pueden generar si se incorporan.
• Le duele cuando descubre código ofuscado o malas prácticas, y las expone para su corrección al equipo.

Sería posible añadir más características del buen desarrollador, pero en solitario un desarrollador nunca podrá llegar a ser excelente, por la cantidad de impedimentos que tiene un proyecto. En especial la carga cognitiva es la principal causa de esta imposibilidad.

Por eso se requiere un Squad o un Equipo Tecnico mínimo viable (MVTT por sus siglas en inglés) para tener la garantía de que el proyecto es viable... Obviamente el coste de la inversión es un poco más elevado, pero el riesgo de no tener el producto hecho en un plazo razonable es mucho más caro. Si tienes dudas, estamos a tu disposición.