Desarrollo de software. Metodologías ágiles vs Calidad del código
Asunto espinoso. Las metodologías ágiles están orientadas a la entrega de productos funcionales que vayan completando mediante iteraciones sucesivas y a través del feedback del usuario un sistema completo acorde a las necesidades del usuario (por tanto, un sistema de calidad), dentro los plazos y presupuesto establecido.
¿Es incompatible con lo anterior la calidad del código? Por supuesto que no, pero, ¿es lo más importante? Tampoco lo es.
El objetivo es conseguir que un sistema sea satisfactorio para el usuario, sin eso de nada vale lo demás y eso se consigue mediante aproximaciones sucesivas teniendo como soporte a un usuario que es aliado y que está comprometido en el proyecto.
Si nos centramos exclusivamente en el objetivo y no vemos más allá, la calidad del código queda en un octavo o noveno plano, es decir, el sistema es lo que el usuario quería, ¿para qué pedir más?. Si el sistema no se va a tocar nunca más, si se van a realizar modificaciones mínimas en el mismo o si no presenta problemas de rendimiento por una mala codificación y/o arquitectura, puede tener sentido que no importe mucho lo que está dentro (la máquina me da buen café y no requiere mantenimiento, ¿qué más me da cómo se hayan construido los circuitos que la hacen funcionar?).
Ahora bien, si se prevén modificaciones de cierta envergadura en el proyecto o que las mismas pueden existir, sí que entra en juego la calidad del código, ya que la deuda técnica del software puede hacer muy costoso el mantenimiento (y hacerte recordar a los ancestros de quiénes codificaron el sistema).
Esta misma idea podría ser aplicable a las sucesivas iteraciones en la construcción del producto. Hay que tener en cuenta que en cada iteración además de nuevas funcionalidades, se corrigen aspectos funcionales y no funcionales del sistema de acuerdo a las directrices del usuario y del equipo técnico del proyecto. Una mala arquitectura, una mala codificación, puede condicionar las sucesivas evoluciones del producto, haciéndose cada vez más pesadas y costosas, lo que obligaría a ser menos ambicioso en cada iteración y requiriéndose un mayor número de iteraciones para obtener el sistema, lo que puede provocar que se ponga en riesgo el cumplimiento de plazos y el presupuesto.
Jummp 
Hola,
Realmente no veo la relación que expones entre calidad de código y metodologías ágiles. En mi opinión, la principal ventaja de usar ágil es la búsqueda continua de la satisfacción del cliente mediante entregas parciales usando iteraciones cortas (2 o 3 semanas es lo recomendable). Por satisfacción podemos entender tanto a nivel funcional permitiendo adecuación del desarrollo a requisitos cambiantes, pero también a otros aspectos cómo calidad en el entregable (documentación, código, etc). En este contexto es el cliente el que debe establecer los parámetros de aceptación de cada entregable, mediante pruebas de aceptación para la funcionalidad y métricas e indicadores para los aspectos de calidad. Si el entregable no cumple con alguno de estos parámetros claramente se está incumpliendo la política de entrega del cliente, y aquí poco tiene que ver el uso de metodologías ágiles o clásicas.
Entre las desventajas del uso de ágiles no se encuentra la poca calidad de código, sino más bien, aspectos como que no todas las empresas clientes pueden trabajar con está metodología, ya que no tienen capacidad para recibir entregas cada poco tiempo y que pasen sus procesos de calidad para pasar a producción sin que ello haga perder la filosofía ágil.
Un saludo.
Lo que quiero decir es que la orientación a la entrega de la metodología ágil puede traer consecuencias sobre la calidad del código ya que el objetivo es cumplir plazos a través de una entrega que satisfaga funcionalmente al cliente.
Lo mismo no es la intención bajar el listón de la calidad del código, pero las prisas son las prisas.
El cliente (y, ¿por qué no?, el proveedor) son los que establecen el listón de la calidad del software de las entregas (tal y como comentas), pero ¿lo mantendrían si se pusiera en riesgo cumplir una entrega?, ¿hasta cuándo están dispuestos a bajarlo?.
Estimado, me gustó la nota y te cuento que la estaré colocando como debate dentro de mi grupo de discusión Testing & QA (comunidad de habla hispana) en Linkedin para conocer la opinión de sus miembros respecto a este tema.
Por supuesto que citaré la fuente para que también puedan seguirte, y además, publicaré la url de tu blog como favorito dentro del mio : http://www.testingbaires.com
Si quieres, puedes hacer lo mismo,
Te mando un abrazo
Gustavo
Muchas gracias por tu comentario. Ya he colocado tu enlace en el blog.
Muy buena reflexión jummp.
Efectivamente, una cosa es la calidad funcional y otra la calidad técnica de un determinado desarrollo.
Trabajar muy cercano al cliente en sus expectativas, a veces conlleva el riesgo de darle demasiada importancia a la calidad funcional, en detrimento de la técnica. Muchas veces porque el cliente no está capacitado o concienciado con ella y, de las entregas, solo ve y revisa los aspectos funcionales.
Efectivamente, como indica Eduardo, eso poco tiene que ver con «ágil» o «clásico». Pero es así.
EL quid de la cuestión es enfocar la calidad de un desarrollo de forma holística, contemplando tanto aspectos funcionales como técnicos y compartiendo la visión entre proveedor del desarrollo y cliente del mismo. ¿una utopía?…
No creo que sea una utopía en esencia, todos esos ingredientes se pueden dar, el problema es que los intereses individuales son los que rompen un proyecto colectivo.