Si va a Google y busca “medir la productividad del desarrollador de software” encontrarás un montón de nada. Seriamente — nada.
Nick Hodges, Medición de la productividad del desarrollador

A estas alturas todos deberíamos saber que no sabemos medir la productividad del programador.

No hay forma clara de medir qué programadores están haciendo un trabajo mejor o más rápido, o para comparar la productividad entre equipos. “Sabemos” quiénes son las estrellas de un equipo, en quién podemos confiar para entregar, y quien esta luchando. Y sabemos si un equipo está pateando traseros o arrastrando el trasero. Pero como lo demostramos? ¿Cómo podemos cuantificarlo??

Todo tipo de cosas estúpidas y malvadas pueden suceder cuando tratar de medir la productividad del programador.

Pero hagámoslo de todos modos.

Estamos escribiendo más código, así que debemos ser más productivos

A los desarrolladores se les paga por escribir código. Entonces, ¿por qué no medir cuánto código escriben? cuantas lineas de codigo ser entregado?

porque hemos conocido desde la década de 1980 que esta es una forma pésima de medir la productividad.

Las líneas de código no se pueden comparar entre idiomas (por supuesto), o incluso entre programadores que usan el mismo lenguaje trabajando en diferentes marcos o siguiendo diferentes estilos. por eso Puntos de función fueron inventados: un intento de estandarizar y comparar el tamaño del trabajo en diferentes entornos. Suena bien, pero puntos de función no lo he hecho en la corriente principal, y probablemente nunca lo hará – muy pocas personas saber cómo funcionan los puntos de función, cómo calcularlos y cómo deben usarse.

El problema más fundamental es que medir la productividad por líneas (o Puntos de Función u otros derivados) escrito no tiene ningún sentido. Mucho trabajo importante en el desarrollo de software., el trabajo mas importante, implica pensar y aprender, no escribir.

Los mejores programadores pasan mucho tiempo entendiendo y resolviendo problemas difíciles., o ayudar a otras personas a comprender y resolver problemas difíciles, en lugar de escribir. Encuentran formas de simplificar el código y eliminar la duplicación. Y mucho del código que escriben no contará de todos modos, a medida que iteran a través de experimentos y construyen prototipos y lo desechan todo para llegar a una solución óptima.

Las fallas en estas medidas son obvias si consideramos los resultados ideales: la menor cantidad de líneas de código posibles para resolver un problema, y la creación de simplificado, procesos comunes e interacciones con los clientes que reducen la complejidad en los sistemas de TI. Nuestra gente más productiva es aquella que encuentra formas ingeniosas de evitar escribir código..
jez humilde, La empresa esbelta

Este es claramente uno de esos casos en los que el tamaño no importa..

Estaban haciendo (o ahorrando) mas dinero,
así que debemos estar trabajando mejor

Podríamos tratar de medir la productividad a un alto nivel utilizando la rentabilidad o el rendimiento financiero de lo que cada equipo está entregando., o alguna otra medida comercial, como cuántos clientes están usando el sistema, si los desarrolladores están ganando más dinero para el negocio (o ahorrar más dinero), Deben estar haciendo algo bien.

Usar medidas financieras parece una buena idea a nivel ejecutivo, especialmente ahora que “cada empresa es una empresa de software". Estas son medidas organizativas que los desarrolladores deben compartir en. Pero no son medidas efectivas, ni justas, de la productividad de los desarrolladores.. Hay demasiados factores comerciales que están fuera del control del equipo de desarrollo. Algunos productos o servicios tienen éxito incluso si las personas que los entregan están haciendo un pésimo trabajo., o fallar incluso si el equipo hizo un gran trabajo. Centrarse en el ahorro de costos en particular lleva a muchos gerentes a despedir personal y tratar de “hacer más con menos” en lugar de invertir en mejoras reales de productividad..

Y como Martin Fowler Señala hay un lapso de tiempo, especialmente en organizaciones grandes: a veces puede llevar meses o años ver los resultados financieros reales de un proyecto de TI, o de mejoras en la productividad.

Necesitamos buscar en otro lugar para encontrar métricas de productividad significativas.

vamos más rápido, así que debemos ser más productivos

Medición de la velocidad de desarrollo – velocidad en Agile: parece otra forma de medir la productividad a nivel de equipo. Después de todo, el objetivo del desarrollo de software es entregar software que funcione. Cuanto más rápido entrega un equipo, el mejor.

Pero velocidad (cuanto trabajo, medido en puntos de historia o puntos de características o días ideales, que el equipo entrega en un periodo de tiempo) es realmente una medida de previsibilidad, no productividad. Velocity está destinado a ser utilizado por un equipo para medir la cantidad de trabajo que pueden asumir, para calibrar sus estimaciones y planificar su trabajo a futuro.

Una vez que la velocidad de un equipo se ha estabilizado, puede medir los cambios en la velocidad dentro del equipo como una medida relativa de la productividad. Si la velocidad del equipo está desacelerando, podría ser un indicador de problemas en el equipo o el proyecto o el sistema. O puede usar la velocidad para medir el impacto de las mejoras del proceso, para ver si la capacitación, las nuevas herramientas o las nuevas prácticas realmente hacen que el trabajo del equipo sea perceptiblemente más rápido.

pero tendrás que dar cuenta de los cambios en el equipo, como la gente se une o se va. Y tendrá que recordar que la velocidad es una medida que solo tiene sentido dentro de un equipo, que no se puede comparar la velocidad entre equipos.

Aunque esto no impide que la gente intente. Algunos talleres usan la idea de una historia de referencia conocida que todos los equipos en un programa entienden y usan para basar sus estimaciones de puntos de historia en. Siempre y cuando los equipos no tengan mucha libertad sobre cómo hacer estimaciones., y siempre que los equipos estén trabajando en el mismo proyecto o programa con las mismas restricciones y suposiciones, es posible que pueda hacer una comparación aproximada de la velocidad entre equipos. Pero Mike Cohn advierte que

Si los equipos sienten la más mínima indicación de que las velocidades se compararán entre equipos, habrá una "inflación de puntos" gradual pero constante.

ThoughtWorks explica que velocidad <> productividad en su último Radar Tecnológico:

Continuamos viendo equipos y organizaciones equiparando la velocidad con la productividad. Cuando se usa correctamente, la velocidad permite la incorporación del "clima de ayer" en el proceso de planificación de iteraciones internas de un equipo. La clave aquí es que la velocidad es una medida interna para un equipo., es solo una estimación de capacidad para ese equipo dado en ese momento dado. Las organizaciones y los gerentes que equiparan la velocidad interna con la productividad externa comienzan a establecer objetivos de velocidad, olvidando que lo que realmente importa es el software funcionando en producción. Tratar la velocidad como productividad conduce a comportamientos de equipo improductivos que optimizan esta métrica a expensas del software de trabajo real.

solo mantente ocupado

Un gerente que conozco dice que en lugar de tratar de medir la productividad

“Simplemente nos mantenemos ocupados. Si estamos ocupados trabajando como locos, podemos buscar problemas y cuellos de botella y solucionarlos y seguir adelante”.

En este caso, mediría y optimizaría para: Tiempo del ciclo, como en la manufactura esbelta.

Tiempo de ciclo: tiempo de respuesta o cambio de tiempo de entrega, desde que la empresa pide algo hasta que lo tienen en sus manos y ven que funciona, es algo que le importa a la empresa, y algo que todos pueden ver y medir. Y una vez que empiezas a mirar de cerca, los desperdicios y los retrasos aparecerán a medida que mida el tiempo de espera/inactividad, valor agregado vs. trabajo sin valor agregado, y eficiencia del ciclo de proceso (tiempo total de valor agregado / tiempo de ciclo total).

“No es importante definir la productividad, o para medirlo. Es mucho más importante identificar las actividades no productivas y reducirlas a cero”.
erik simmons, Intel

Los equipos pueden usar Kanban para monitorear, y limitar, el trabajo en curso e identificar retrasos y cuellos de botella. Y Mapeo de flujo de valor para entender los pasos, cruz, retrasos y flujos de información que deben optimizarse. Ser efectivo, debe observar el proceso de extremo a extremo desde que se realizan las solicitudes por primera vez hasta que se entregan y se ejecutan, y optimizar a lo largo del camino, no solo el trabajo en desarrollo. Esto puede significar cambiar la forma en que la empresa prioriza, cómo se toman las decisiones y quién las toma.

En casi todos los casos que hemos visto, hacer que un bloque de proceso sea más eficiente tendrá un efecto mínimo en el flujo de valor general. Dado que los tiempos de reelaboración y espera son algunos de los mayores contribuyentes al tiempo total de entrega, adoptar procesos “ágiles” dentro de una sola función (como el desarrollo) generalmente tiene poco impacto en el flujo de valor general, y por lo tanto en los resultados del cliente.
jezz humilde, La empresa esbelta

La desventaja de equiparar la velocidad de entrega con la productividad? La optimización del tiempo de ciclo/velocidad de entrega por sí sola podría generar problemas a largo plazo, porque esto incentiva a la gente a pensar a corto plazo, y tomar atajos y asumir deuda técnica.

Estamos escribiendo mejor software, así que debemos ser más productivos

“La paradoja es que cuando los gerentes se enfocan en la productividad, rara vez se realizan mejoras a largo plazo. Por otro lado, cuando los gerentes se enfocan en la calidad, la productividad mejora continuamente.”
Juan Seddon, citado en La empresa esbelta

Lo sabemos corregir errores más tarde cuesta más. Ya sea 10x o 100+x, realmente no importa. Y eso los proyectos con menos errores se entregan más rápido – al menos hasta un punto de rendimientos decrecientes para sistemas críticos para la seguridad y críticos para la vida.

Y sabemos que los costos de los errores y errores en el software para el negocio pueden ser significativos.. No solo los costos de reelaboración del desarrollo y los costos de mantenimiento y soporte. Pero los costos directos para el negocio. Falta del tiempo. Brechas de seguridad. IP perdida. clientes perdidos. Multas. Demandas. fracaso empresarial.

Es fácil de medir que estás escribiendo software bueno o malo. Densidad de defectos. Tasas de escape de defectos (especialmente los defectos, incluidas las vulnerabilidades de seguridad, que escapan a la producción). Métricas de análisis estático sobre la base del código, utilizando herramientas como SonarQube.

Y sabemos cómo escribir un buen software. – o deberíamos saberlo ahora. Pero, ¿la calidad del software es suficiente para definir la productividad??

Devops: medición y mejora del rendimiento de TI

Los equipos de Devops que construyen/mantienen y operan/apoyan sistemas extienden la productividad de desarrollo a operaciones. Miden la productividad en dos dimensiones que ya hemos visto: velocidad de entrega, y calidad.

Pero Devops no se limita solo a crear y entregar código, sino que analiza las métricas de rendimiento para la entrega de servicios de TI de extremo a extremo.:

1. Rendimiento de entrega: frecuencia de implementación y tiempo de entrega, maximizar el flujo de trabajo hacia la producción
2. Calidad de servicio: cambiar la tasa de fallas y MTTR

No se trata solo de entregar software más rápido o mejor. Es desarrollo y operaciones trabajando juntos para brindar servicios mejores y más rápidos., lograr un equilibrio entre moverse demasiado rápido o tratar de hacer demasiado a la vez, y excesiva burocracia y exceso de cautela que resultan en desperdicios y demoras. El desarrollo y las operaciones deben compartir la responsabilidad y la rendición de cuentas por el resultado, y para medir y mejorar la productividad y la calidad.

Como señalé en una publicación anterior Esto hace métricas operativas más importante que las métricas del desarrollador. De acuerdo a estudios recientes, el éxito en el logro de estos objetivos conduce a mejoras en el éxito empresarial: no solo productividad, pero la cuota de mercado y la rentabilidad.

Medir resultados, no Salida

En La empresa esbelta (que se puede decir que acabo de terminar de leer), Jez Jumble habla sobre la importancia de medir la productividad por resultado, midiendo cosas que son importantes para la organización, no por producción..

“No importa cuántas historias completemos si no logramos los resultados comerciales que nos propusimos lograr en forma de condiciones objetivo a nivel de programa”.

Deja de intentar medir productividad individual del desarrollador. Es una pérdida de tiempo.

• Todo el mundo sabe quiénes son los mejores. Señalarlos en la dirección correcta, y mantenlos felices.
• Todo el mundo conoce a las personas que están luchando. Consígales la ayuda que necesitan para tener éxito.
• Todo el mundo sabe quién no encaja. moverlos fuera.

Medir y mejorar la productividad en el equipo o (mejor) el nivel de la organización le dará rendimientos mucho más significativos.

Cuando se trata de productividad:

1. Medida cosas que importan – cosas que marcarán la diferencia para el equipo o para la organización. Medidas claras, importante, y que no son fáciles de jugar.
2. Usa las métricas para el bien, no por mal – para impulsar el aprendizaje y la mejora, no comparar resultados entre equipos ni clasificar a las personas.

Puedo ver por qué medir la productividad es tan seductor. Si pudiéramos hacerlo, podríamos evaluar el software mucho más fácil y objetivamente de lo que podemos ahora.. Pero las medidas falsas solo empeoran las cosas..
Martín Cazador, No se puede medir la productividad

Sobre el Autor

Jim Bird es un gerente de desarrollo de software con experiencia, gerente de proyecto y actualmente CTO en una firma de servicios financieros. Está enfocado en problemas difíciles en el desarrollo y mantenimiento de software., calidad y seguridad del software. Por el último 15 años ha dirigido equipos construyendo y operando sistemas financieros de alto rendimiento. Su interés especial es cómo los equipos pequeños pueden ser más efectivos en la construcción de software real.: alta calidad, sistemas seguros en los límites extremos de confiabilidad, actuación, y adaptabilidad. Software que tiene que funcionar, que está bien construido, y construido para durar. Este artículo fue publicado originalmente en su propio blog. Creación de software real.

Una publicación de blog representa la opinión personal del autor.
y puede no coincidir necesariamente con las políticas oficiales de Nesma.