archivo

Archivo de la etiqueta: John Gall

La Ley de Gall se adapta perfectamente a los enfoques de desarrollo iterativo incrementales, si bien, y como os he comentado otras veces, la estrategia o metodología no sirve para nada si en la práctica no se toman decisiones efectivas.

Es decir, si el planteamiento del desarrollo no está basado en el intento de buscar las alternativas más simples que solucionen el problema y satisfagan las expectativas el usuario, nos encontraremos finalmente con un sistema más complejo del necesario, lo mismo si tratamos de construir la aplicación por el tejado sin haber trabajado previamente con funcionalidades que pueden ser igual o más prioritarias y en donde malas decisiones y/o implementaciones pueden condicionar sensiblemente el resto del sistema.

Es cierto que al ser un desarrollo de tipo evolutivo la complejidad se añade por incrementos y se tiene la oportunidad de rectificar a tiempo (el coste siempre será mucho menor que con el producto desarrollado de manera completa o con una buena parte de sus subsistemas ya desarrollados).

En un desarrollo en cascada el riesgo de caer en soluciones complejas que no han pasado previamente por un período de maduración basado en versiones más simples crece de manera exponencial, ya que este tipo de desarrollos tiene una vocación finalista que no es otra que la entrega del sistema completo (concepto llave en mano).

Su enunciado es el siguiente: “Un sistema complejo que funciona se encuentra de manera invariable como el resultado de un sistema simple que funcionaba. La proposición inversa también parece correcta: Un sistema complejo diseñado desde cero no funciona y no se conseguirá hacerlo funcionar. Tienes que empezar de nuevo con un sistema simple que funcione”.

John Gall, acierta de pleno en lo que al desarrollo de software se refiere. ¿Cuántos sistemas han fracasado por tratar de resolver el problema de una sola vez en lugar de tratar de hacerlo poco a poco?.

Después, tratar de darle la vuelta a la situación es complejo y costoso porque el sistema es muy grande, tendrá usuarios trabajando en él que se estarán continuamente quejando y que provocarán que los responsables funcionales centren las prioridades en resolver estos continuos incendios en lugar de buscar una solución general.

Este tipo de situación provoca un gran desgaste en usuarios y desarrolladores y se entra en un bucle de difícil solución porque cuando se plantee a los gestores que tal vez lo mejor sea empezar de nuevo o rehacer buena parte del sistema pondrán muchas resistencia y se negarán en la mayoría de los casos porque el coste les parecerá siempre excesivo (no tienen en cuenta el coste de mantener una solución no satisfactoria), teniendo en cuenta que acaban de realizar, no hace mucho una inversión muy fuerte.