(
c )
Casi desde el advenimiento de la industria de la tecnología, ha estado buscando la "ballena blanca", la métrica laboral de los desarrolladores. Quizás el deseo de contar a los programadores de KPI nació de una frase común en los negocios tradicionales: "No se puede planificar, si no se puede medir".
Después de los cientos de KPI diferentes que los programadores intentaban sortear, aparecieron muchos métodos diferentes para analizar datos operativos, desde el seguimiento de la dirección de la mirada en el monitor hasta Scrum y Kanban. Las mediciones de la calidad del trabajo han funcionado tan bien en muchas industrias que parecía lógico transferir esta experiencia al desarrollo de software. El resultado fue desalentador.
La medición y gestión de la productividad del desarrollador no ha dado lugar a un único estándar internacional de calidad. Las empresas de TI de alta tecnología están desarrollando sus propias métricas ... algunas de ellas son casi imposibles de comparar con los KPI tradicionales en otros campos de actividad.
En este artículo, hablaremos sobre las métricas actuales más interesantes y sobre las "métricas" en TI.
Ya es difícil encontrar información (al menos en fuentes abiertas) sobre el uso de la cantidad de horas trabajadas, la cantidad de líneas en el código fuente (SLOC), los puntos de función o la cantidad de errores creados por cada desarrollador como una métrica.
En el discurso público, fue posible llegar a un consenso de que trabajar más
no significa trabajar mejor, que una solución con 200 líneas de código puede ser más rápida o más productiva que una solución con mil líneas, y la métrica de Puntos de Función creada en 1979 está irremediablemente desactualizada.
Pero, ¿qué pasó con el deseo de medir y calcular todo? Al parecer, no ha desaparecido.
Netflix
(
c )
Netflix se centró en superar las barreras que separan a los usuarios del contenido. Cada vez que algo le impide ver el próximo episodio de su serie favorita, los desarrolladores solucionan el problema y miden el tiempo que tomó resolverlo.
La plataforma de transmisión prueba nuevas ideas en términos reales y mide las diferencias estadísticamente significativas en las interacciones del usuario con el producto. Además, los errores en la etapa de prueba de hipótesis son bastante aceptables: "el único error real que es inaceptable en Netflix es la incapacidad de innovar".
El desarrollo de productos en Netflix comienza con una hipótesis que se parece a esto:
Algoritmo / función / diseño (×) aumentan la interacción de los suscriptores con el servicio y, en última instancia, su retención.
La hipótesis puede ser aumentar la relevancia de los resultados de búsqueda, usar un nuevo diseño para las interfaces de usuario o una nueva característica, por ejemplo, mostrar a los participantes lo que sus amigos de las redes sociales están mirando Netflix. La intuición y una idea de cómo proporcionar mejor servicios a los suscriptores se convierten en la base del enfoque de desarrollo.
El segundo paso de desarrollo es escribir una prueba que mida el impacto de la hipótesis. A veces esto significa que puede crear inmediatamente un prototipo que refleje la esencia del concepto, lo que le permitirá probar rápidamente la hipótesis y esforzarse por construir una mejor solución.
El tercer paso es la prueba en sí, en la que pueden participar cientos de miles de espectadores. El prototipo se implementa para los participantes en el experimento durante un período de tiempo determinado. Puede tener dos cohortes para la prueba o 20, cada una de las cuales utiliza un enfoque diferente o mezclar diferentes elementos nuevos. Se pueden lanzar docenas de diferentes pruebas de consumo en cualquier momento.
Incluso un fracaso de la hipótesis se considera un resultado logrado. En consecuencia, la probabilidad de que la siguiente hipótesis resulte ser mejor solo aumenta. El equipo de desarrollo tiene una gran libertad para aplicar ideas al producto durante un largo período de tiempo.
Ibm
(
c )
La métrica más antigua y más "obvia" para el desarrollo de software es contar el número de líneas producidas por un desarrollador o equipo individual, y la cantidad de tiempo dedicado a ello. Esta métrica fue utilizada por primera vez por IBM. En el documental Triumphof the Nerds: The Rise of Accidental Empires, Steve Ballmer señaló que en la década de 1980, IBM parecía hacer de esa métrica la religión.
En 2011, IBM
introdujo una herramienta para analizar automáticamente el código fuente en cuanto a rendimiento, seguridad y complejidad técnica. Los desarrolladores cuyo código tenía la calificación más alta recibieron la calificación más alta del sistema. Los indicadores de bajo rendimiento sirvieron como señal para prestar atención a la capacitación de los empleados (IBM afirmó que un puntaje final bajo no se utilizó como castigo).
Sin embargo,
publicaciones posteriores dan la impresión de un cambio de paradigma: la metodología para construir hipótesis ya se menciona en el corazón del desarrollo. El desarrollo hipotético no puede prescindir de la pérdida de tiempo y recursos.
Lo principal en esta métrica son los comentarios de los clientes sobre el producto. Debemos centrarnos en lo que es más importante para los clientes y abandonar las funciones que no son beneficiosas o que incluso interfieren con los usuarios. Esta estrategia se representa en el diagrama de arriba.
Spacex
(
c )
Hay muy poca información sobre el trabajo de los desarrolladores en SpaceX, que está asociado con el secreto general de los proyectos de esta empresa no pública. Pero según
la información indirecta, puede comprender los contornos aproximados de la imagen general. Y esta imagen habla de la importancia de las pruebas.
En la ciencia de los cohetes, las pruebas son la base del diseño. En el software de programación para cohetes,
se utilizan los mismos principios . Por ejemplo, si el cohete aterrizó de manera segura, entonces todos los equipos responsables del desarrollo completaron el KPI. Sin pruebas preliminares, no es posible completar con éxito dicho proyecto.
Dados los problemas que enfrentan los equipos involucrados en la preparación de equipos para el entorno espacial hostil, no es difícil entender qué responsabilidad les corresponde.
SpaceX está
tratando de paralelizar el código entre diferentes proyectos: con este paradigma de desarrollo, la corrección de errores para un proyecto (relativamente hablando, cohetes) se extiende automáticamente a otros proyectos.
La compañía eligió C ++ como el lenguaje de programación principal. En primer lugar, le permite contratar a muchos desarrolladores de alto perfil, ya que el lenguaje sigue siendo relativamente popular. Al mismo tiempo, la elección a menudo se hace a favor de los desarrolladores de juegos que están acostumbrados a escribir código y trabajan en entornos con memoria y potencia informática limitadas.
En segundo lugar, se benefician del gran ecosistema de C ++. No es necesario crear un software especial cuando puede usar herramientas familiares, como gcc y gdb.
Y finalmente, en desarrollo, se presta gran atención a las métricas de prueba. Se recomienda a los desarrolladores e ingenieros que verifiquen la seguridad y la tolerancia a fallas en todo lo que se les ocurra.
Los datos recopilados durante las pruebas se almacenan junto con el código fuente que funcionó durante las pruebas. Si se produce un mal funcionamiento durante la prueba de cohetes, SpaceX podrá recrear el entorno de lanzamiento exacto, reproducir el problema y solucionarlo.
La integración continua se utiliza para probar automáticamente todo el código. Incluso tienen plataformas de prueba con todos los componentes del motor para simular completamente el arranque y detectar posibles problemas.
Amazonas
Amazon tiene una de las estrategias más interesantes descritas en esta entrevista de 40 minutos con el director de AWS Developer Tools.
La idea clave de formar equipos de desarrollo es la escala mitótica. Los equipos se dividen en grupos más pequeños, preservando completamente la continuidad y las funciones de los equipos "madre".
Jeff Bezos, CEO de AWS Developer Tools,
cree que un equipo ideal no debería incluir más personas de las que pueden llenar dos pizzas.
En equipos pequeños, la comunicación es mucho más efectiva, permanecen descentralizados, independientes, se desarrollan más rápido e introducen innovaciones.
Originalmente, Amazon tenía una arquitectura monolítica y de software (Perl / Mason / C ++). Luego, la arquitectura se descompuso en servicios, y la estructura organizativa en equipos de pizza. Entonces, el servicio en la nube Amazon Elastic Compute Cloud (Amazon EC2) fue formado por un grupo que consta de solo dos "equipos de pizza".
Amazon se compromete a automatizar completamente todos los procesos (compilación, implementación, transferencia de confirmación, etc.). Dentro de cada implementación, se utilizan varios tipos diferentes de pruebas: integración, navegador, web y carga. Por lo tanto, todo está controlado y medido.
La seguridad se supervisa durante todo el proceso de lanzamiento del producto, por lo que es perfectamente normal que Amazon "piense como un ingeniero de seguridad" en cualquier cultura de Amazon. Al lanzar un nuevo proyecto, los desarrolladores trabajan principalmente en la arquitectura y el modelo de amenaza.
Las validaciones están integradas en todas las canalizaciones a través de una combinación de políticas de confianza locales y globales. El líder puede establecer de forma independiente la política de auditoría para su equipo (por ejemplo, antes del despliegue, cada nueva confirmación debe estar cubierta por pruebas unitarias en un 70%).
Al mismo tiempo, existen reglas generales de Amazon que cubren cada implementación (por ejemplo, una prohibición de la implementación única en cada región).
Son los desarrolladores del equipo, y no el arquitecto, los responsables de la arquitectura del proyecto. Y solo entonces es considerado por un arquitecto o ingeniero jefe. La misma situación con la seguridad y las pruebas: el equipo gestiona todo el proceso. Aunque este enfoque tiene un signo negativo, que consiste en un largo período de entrenamiento.
Cada año, los equipos preparan un plan operativo en seis páginas (tales "planes de negocios" se presentan en todos los niveles de Amazon). El plan indica qué se logrará el próximo año con recursos fijos y qué se puede lograr con recursos adicionales. Los gerentes recopilan documentos de seis páginas de todos los equipos que administran, crean sus propios documentos de seis páginas y los envían a su gerencia, y así sucesivamente hasta Jeff Bezos. En la dirección opuesta, los recursos se asignan a los equipos.
¿Qué tienen allí las startups?
Gracias a las encuestas
realizadas por Stackify (una plataforma en la nube para monitorear y solucionar problemas de aplicaciones web), fue posible conocer la actitud hacia las métricas en algunas empresas nuevas y conocidas de la "mano media".
CircleCI es un servicio de integración continua, incluso en Rusia, con configuraciones flexibles para aplicaciones web y móviles. Rob Zuber, CTO CircleCI, cree que la mejor métrica para medir la productividad y la eficacia del desarrollo de software es una medida del tiempo que tarda el código en pasar del compromiso al despliegue: tiempo de compromiso para el despliegue (CDT).
El objetivo de medir CDT es "rastrear" las barreras al despliegue. Idealmente, si usa automatización y / o pruebas de buena calidad, puede ir a la implementación en minutos (o incluso segundos) para un microservicio. Si utiliza principalmente el proceso de control de calidad manual, esto probablemente significará que la implementación llevará más tiempo.
El análisis CDT de CircleCI muestra dónde encontrar oportunidades de mejora. Las mejoras pueden ser más técnicas (por ejemplo, hacer que las pruebas sean más efectivas), más orientadas al proceso o una combinación de ambas. Cuanto más pequeños sean tus commits, más rápido se pueden iniciar, respectivamente, más rápido puedes arreglar la situación si algo sale mal.
Adeva es una empresa de reclutamiento y forma equipos de desarrollo listos para emprender. Para ofrecer a los clientes un mejor servicio, ha estado investigando las métricas de rendimiento del programador durante varios años. La conclusión es simple: no existe una medición formal y objetiva de la efectividad y productividad del desarrollo de software.
En lugar de usar KPI, Adeva organiza reuniones cortas con desarrolladores, en las cuales la gerencia escucha atentamente historias sobre logros y fracasos. Para determinar la efectividad del departamento en su conjunto, a los desarrolladores se les hacen preguntas sobre la utilidad y la conciencia del resto del equipo. En estas reuniones, todos pueden expresar ideas que podrían ser útiles tanto para ellos como para otros miembros del equipo.
Además de las comunicaciones interpersonales, Adeva analiza cómo se integra el código del desarrollador con la base del código, verifica su rendimiento, seguridad y determina si el código tendrá un menor costo de mantenimiento a largo plazo.
Scorchsoft, un desarrollador inglés de aplicaciones web y móviles, estima los plazos de entrega del proyecto. Dado que la mayoría de los clientes de Scorchsoft esperan recibir un producto a un precio fijo, la compañía debe identificar de inmediato una especificación clara e inequívoca. El rendimiento se mide en términos de tiempo de desarrollo basado en las herramientas Toggl (rastreador de tiempo) y Jira.
Un proyecto se considera exitoso si el cliente está satisfecho y el equipo cumple con la fecha límite.
Conclusión
A veces, con la evaluación de las métricas, aún puede llegar a un denominador común: este es un enfoque en la comodidad del usuario. En lugar de tratar de medir directamente la productividad del programador, la atención se centra en medir todo lo que impide el progreso en la entrega de valor al cliente.
Cuando el cliente final es el principal indicador de éxito, es mucho más fácil usar métricas que provienen del marketing: tasa de conversión, comportamiento del usuario o evaluaciones de calificación. En esta área, el éxito depende en gran medida de la gestión, que puede tomar una decisión equivocada. Por ejemplo, el desarrollo de una función que no es necesaria para el cliente tiene un impacto mucho más negativo en el negocio que un desarrollador que se destaca de los "estándares".