Aunque las habilidades prácticas y el conocimiento de lenguajes de programación, herramientas y tecnologías específicos son la clave para conseguir un trabajo de tiempo completo como desarrollador de software, hay otro indicador valioso que, en muchos sentidos, puede verse como un presupuesto para el éxito en esta profesión: productividad. La medición de la productividad es algo que todos los desarrolladores de software profesionales deben comprender y tener en cuenta, ya que las métricas de rendimiento son inherentemente importantes para cualquier equipo de desarrollo de software en el entorno empresarial actual.
¿Por qué es importante tu productividad como desarrollador?
En la era del desarrollo Agile, DevOps y ciclos de lanzamiento de software cada vez más reducidos, cuando los desarrolladores necesitan enviar nuevas versiones de productos lo más rápido posible, las empresas utilizan múltiples métricas de productividad diferentes para evaluar el rendimiento de los programadores individuales y de un equipo como un todo. Mirando esto desde el punto de vista de un desarrollador, la medición del rendimiento puede servir para una serie de propósitos valiosos, ayudándole a realizar un seguimiento del progreso de sus habilidades de programación, lo que le permitiría lograr un crecimiento profesional constante. Los codificadores altamente productivos son los que terminan recibiendo ofertas salariales asombrosas y se ponen a trabajar en los proyectos más emocionantes. Pero incluso si no es exactamente un gran triunfador y solo quiere cualquier trabajo en desarrollo de software y tener un éxito razonable en él, aún necesita tener al menos una comprensión básica de los indicadores de rendimiento y cómo se utilizan para medir la productividad de su entrada en el trabajo. Que es de lo que vamos a hablar hoy.
Métricas de medición de la productividad del desarrollo de software
¿Qué son las métricas de productividad del desarrollo de software?
Las métricas de desarrollo de software son las áreas del trabajo de programación en las que se pueden aplicar medidas cuantitativas para realizar un seguimiento del rendimiento, la calidad del trabajo y la productividad de un desarrollador. Cada métrica de productividad se basa en tomar datos del proceso de desarrollo y usarlos para medir la productividad. Como prácticamente nada relacionado con el desarrollo de software es fácil y directo, se podría decir que medir la productividad de la programación también es bastante inconsistente y fragmentado en toda la industria. O, en pocas palabras, varios equipos y empresas pueden usar indicadores de rendimiento completamente diferentes y abordar este problema desde varios ángulos. Por lo tanto, no necesita preocuparse por aprender todas y cada una de las métricas que pueden utilizar los equipos de desarrollo de software.
¿Qué tipos de métricas de productividad de desarrollo de software existen?
Naturalmente, existen múltiples métricas de productividad diferentes que abordan la medición del rendimiento en varios niveles y ángulos. Estos son los tipos más comunes de dichas métricas de productividad:
Métricas formales centradas en el tamaño.
Estas métricas se centran en medir el tamaño del resultado del trabajo de un programador, como las líneas de código (LOC), la longitud de las instrucciones del código, la complejidad del código, etc. Estas métricas se consideran cada vez más obsoletas en la industria de desarrollo de software actual.
Métricas de productividad centradas en el tiempo y la función.
Hay una selección de métricas de productividad tradicionales utilizadas en el desarrollo de software en cascada, como los días activos, el alcance de la funcionalidad enviada en un período de tiempo determinado, las tasas de rotación de código, la cantidad de tareas asignadas, etc.
Métricas ágiles del proceso de desarrollo.
Las métricas del proceso de desarrollo ágil, como el informe de trabajo pendiente del sprint, la velocidad, el tiempo de entrega, el tiempo del ciclo y otras, son probablemente las métricas más utilizadas entre los equipos de desarrollo de software en la actualidad. Hablaremos sobre las métricas ágiles con más detalle más adelante en el artículo.
Métricas de analítica operativa.
Este conjunto de métricas se centra en medir el rendimiento del software en su entorno de producción actual. El tiempo medio entre fallas (MTBF), el tiempo medio de recuperación (MTTR) y la tasa de fallas de la aplicación son las métricas más utilizadas aquí.
Métricas de prueba.
Las pruebas de software tienen su propio conjunto de métricas para medir la calidad de las pruebas del sistema, como el porcentaje de pruebas automatizadas, la cobertura del código, etc.
Métricas de satisfacción del cliente.
Finalmente, la métrica definitiva para cualquier pieza de software es la experiencia del cliente final, y también hay un conjunto completo de métricas para eso, como la puntuación de esfuerzo del cliente (CES), la puntuación de satisfacción del cliente (CSAT), la puntuación neta del promotor (NPS) y otros.
Métricas ágiles de desarrollo de software
Como puede ver, es bastante fácil perderse en todas las complejidades de las métricas de productividad del software. Sin embargo, los únicos con los que un desarrollador de software habitual debería estar bien familiarizado son las métricas ágiles, comúnmente utilizadas por los equipos de desarrollo de software hoy en día como estándares de medición de la productividad del equipo en diferentes partes del ciclo de vida del desarrollo de software. Hagamos una lista de las métricas ágiles principales y más utilizadas.
1. Agotamiento de Sprint.
Los informes Sprint Burndown son una de las métricas clave para los equipos ágiles de desarrollo de scrum. Como en Agile el proceso de desarrollo se organiza a través de sprints con límite de tiempo, Sprint Burndown se utiliza como una forma de realizar un seguimiento de la finalización de las tareas durante un sprint. Las horas o los puntos de la historia se utilizan como unidad de medida. El objetivo es lograr un progreso constante y entregar el trabajo en línea con las proyecciones iniciales. Sprint Burndown ayuda a los equipos a medir el ritmo de trabajo y ajustarlo cuando sea necesario.
2. Velocidad del equipo.
La velocidad es otro indicador clave, que también se basa en horas o puntos de la historia como unidad de medida. Mide la cantidad promedio de trabajo que completa un equipo durante un sprint y se utiliza para la estimación y la planificación a lo largo de todo el proyecto. La velocidad de seguimiento es importante para asegurarse de que el equipo ofrezca un rendimiento constante.
3. Puntos de la historia.
En el nivel de un miembro del equipo de desarrollo individual, los puntos de la historia son una métrica valiosa, ya que el tamaño de las historias que entrega un programador durante cada versión es un indicador de la productividad de este codificador.
4. Cuadro de Control de Ciclos.
Mide el tiempo total desde el momento en que se inicia el trabajo en una tarea u otro elemento pendiente hasta su finalización. Permite rastrear y controlar los tiempos de ciclo brindando resultados más predecibles.
5. Rendimiento y valor entregado.
Los gerentes de proyecto analizan las tareas asignadas a los desarrolladores y les asignan valor. Esta métrica se usa luego para medir el rendimiento del equipo o, en otras palabras, la cantidad de trabajo de valor agregado realizado.
6. Cambio de código.
Code churn es otra métrica que vale la pena mencionar, ya que se utiliza para medir tanto la productividad de un equipo en su conjunto como para realizar un seguimiento del rendimiento de los programadores individuales. La rotación de código mide la frecuencia con la que un desarrollador elimina o realiza cambios en las líneas de código agregadas previamente, y qué porcentaje del código escrito anteriormente termina cambiado o desechado.
Opiniones de expertos
Finalmente, para agregar algo de perspectiva, algunas citas sobre el tema de profesionales experimentados en la industria del desarrollo de software. “Espero que no esté buscando "comparar" sus métricas con algún tipo de estándar o incluso con el desempeño de otro equipo en otra empresa. En todos los lugares en los que he trabajado ha habido variaciones únicas en sus definiciones de puntos de la historia, velocidad, estimaciones por hora, tareas, etc. que realmente harían casi imposible comparar el desempeño de un equipo de una empresa directamente con el de otro equipo en otra compañía”, señaló Cliff Gilley, ex Gerente Técnico de Producto y Entrenador Ágil.. “Soy un poco desconfiado con las métricas cuando se trata de guiar el desempeño del equipo. Una vez que presta atención a solo una o dos variables, es muy fácil caer (intencionalmente o no) en jugar con la métrica y engañarse a sí mismo pensando que está mejorando, cuando todo lo que está haciendo es mejorar la métrica. Por ejemplo, las métricas basadas en la velocidad pueden "mejorar" si el equipo pasa a historias más pequeñas (menos trabajo por historia, por lo que se completan más historias, por lo que la velocidad aumenta). Eso podría ser bueno si las historias son historias de usuario útiles que ofrecen incrementos más pequeños de valor comercial. Eso podría ser algo malo si las historias se vuelven tareas más pequeñas y más "técnicas" que no brindan un valor real por sí mismas”, dijo Adrian Howard, otro profesional de la industria.. “Cuando trabajo en un sistema basado en extracción, valoro el rendimiento y el tiempo de ciclo. El primero me da información general sobre la capacidad de nuestro equipo y, con el tiempo, puede convertirse en una medida predictiva muy poderosa. El segundo es útil como indicador general de la eficiencia de nuestros oleoductos. Si el tiempo del ciclo es alto, es hora de comenzar a mirar la canalización, porque hay una restricción que probablemente podamos trabajar para aliviar/explotar. Pero las métricas son solo herramientas. No se pierda en ellos, y ciertamente no comience a planificar hacia una métrica específica. Piense en lo que está haciendo como equipo y cómo trabaja naturalmente, luego construya el sistema alrededor de las personas. Las métricas deberían ayudarlo a ver cómo su sistema respalda el trabajo de todos. O no”, concluyó Dave Cerra, productor de desarrollo de videojuegos .
GO TO FULL VERSION