Alineando las Sillas en la Cubierta del Titanic

Desde la aparición de la agilidad aplicada a equipos de desarrollo de software, hemos estado avanzando en nuestra profesión. En mi experiencia, veo que la calidad de lo producido ha mejorado, en general. Por lo menos, cuando veo los proyectos en los que he participado en este siglo, comparados con anteriores, noto esa mejora general. Y también en la satisfacción personal de cada miembro del equipo, en el manejo de los tiempos, los esfuerzos, y demás. Y veo lo mismo en decenas de proyectos en los que no participé pero he visto crecer de cerca.

Pero a veces, veo tomar decisiones que no son las más ágiles, o no están alineadas con lo que el contexto del proyecto pide. Una tendencia, no muy frecuente por suerte, es poner énfasis en alguna métrica o herramienta en lugar de lo que es importante para el proyecto.

Por ejemplo, he visto “sprints”, iteraciones, dedicadas a “incrementar el porcentaje de code coverage a 80%”. Por más que repaso las circunstancias de los casos que conozco, no logro ver que sea realmente lo importante. Es más, tomar ese tipo de trabajo es perder una oportunidad de mejora real en el equipo. El trabajar “a posteriori” en el incremento del code coverage, es poner el carro delante del caballo. Lo que buscamos en un sistema que estamos armando es que funcione como esperamos. Y eso se logra mejor si escribimos los tests de la conducta esperada, de cada caso de uso que queremos cumplir (uso “caso de uso” en un sentido amplio, desde la conducta esperada en una simple clase, hasta el resultado esperado luego de una serie de pasos de negocio). Cuando uno sigue ese “approach”, el “code coverage” nos da automáticamente cumplido como métrica, casi seguro mayor que el 80%, o que el 90%. Eso es lo que tiene que ser la medición del “code coverage”: una métrica que de evidencia de que estamos siguiendo el buen camino, antes que un objetivo en sí mismo. Trabajar a “posteriori” para incrementar esta métrica NO ASEGURA que estemos escribiendo un buen sistema. Ver ejemplo mencionado en el post El Programador Profesional (1) , donde aún con un gran “code coverage”, lo entregado se rompía luego de dos clicks en el browser, en cuatro continentes.

Otra versión parecida de errar en el blanco, es adoptar prácticas porque parecen las “mejores prácticas” o poner procesos obligatorios en el desarrollo, como obligación de manejarse con “branch por feature”, y “code review”, para mantener “la calidad del código”. Las veces que vi que se llegara a esa situación, son pocas, por suerte. Pero igual de vez en cuando aparecen, y veo que es de nuevo atacar un problema con procesos y herramientas, adoptar prácticas que tienen sentido en otro contexto, sin aprovechar atacar las causas raíces y obtener una mejora en el equipo.

Por ejemplo, “branch por feature”, podría adoptarse, pero en casos particulares. Si se necesita adoptar en un caso, es seguramente porque no estamos trabajando en forma incremental, simplemente mejorando el “branch” de desarrollo, trabajando juntos, esforzándonos por no romper algo (por ejemplo, usando TDD (Test-Driven Development) me facilita mucho el saber automáticamente si la conducta esperada no se cumple). Y dificulta la integración, tenemos que trabajar más casi siempre al final de la iteración para tener algo entregable. Y vi que promueve el trabajo en silos, donde cada cual trabajar en un “branch”, en lugar de trabajar todos juntos en una tarea. Cuando la adopción de “branch por feature” se hace obligatoria, es como que se naturalizan esos “bad smell” de equipo, y no podemos activamente trabajar en la mejora. He visto DECENAS de proyectos de equipos ágiles donde no se usa “branch por feature” y todo funciona de forma armoniosa. Esto me lleva a pensar que “branch por feature” es algo más útil cuando el proyecto es de código abierto. En un equipo ágil, donde hay una reunión diaria, donde hay comunicación (aun remota), donde el sistema se va armando de tal forma de saber cuando algo no funciona o cuando introducimos un bug sin quererlo, donde el sistema no se ha dejado llevar por la complejidad accidental y puede entonces ser desarrollado incrementalmente, cuando veo que se da este contexto, veo que no es tan necesario el “branch por feature”.

En cuanto a “pull request con code review” obligatorio, de nuevo: veo que es un síntoma de no atacar otra causa raíz. Por ejemplo, no lo vi tan necesario cuando hay trabajo de a pares. O cuando hay confianza en los miembros del equipo, y se sabe que cualquier cosa que uno agregue puede ser revisada en cualquier momento, porque estamos armando un sistema evolutivo, sin complejidad accidental, que admite cambios como todo lo ágil promueve. Cualquier cosa que parezca mejorable, se puede mejorar en cualquier momento. Por supuesto, cada uno debe hacer el mejor esfuerzo desde el principio.

En definitiva: adoptar herramientas y procesos de esta forma, es como alinear las sillas en la cubierta del Titanic: estamos haciendo algo que parece bueno, en vez de hacer lo correcto, lo que la situación amerita. Y nos naturaliza los problemas, sin atacar las causas raíces.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com

 

This entry was posted in Desarrollo Agil, Programacion, Uncategorized. Bookmark the permalink.