Desarrollo en Cascada (III)

Habréis de disculparme. En mi último post de "Desarrollo en Cascada (II)", tuve un gazapo. Si leísteis algún párrafo sin sentido o aparentemente fuera de lugar, fue un error de un estilo que me hizo una juguarreta. Ya se ha corregido.
Y llegamos a esta entrega, en la que mientras revisamos el desarrollo en cascada, estamos viendo otras muchas más cosas sobre el desarrollo software.

Hoy toca hablar de porqué fracasó el modelo en cascada.

¿Qué hizo que fracasara el modelo en cascada? Pues básicamente que no había otra cosa. Existían variantes del modelo, pero la rigidez básica en que estaba basado, lo hacía inoperativo. Además, se dieron cita una serie de circunstancias:

• Los clientes quieren ver avance. Efectivamente, los clientes quieren estar seguros de que el dinero que se han gastado, está siendo usado correctamente. Existe la creencia de que lo que quieren ver, es cómo se van construyendo las funcionalidades: nada más falso. En gran número de ocasiones, al "cliente", al que "paga", le preocupa más satisfacer sus necesidades. Y entre sus necesidades, también están que su compra sea correcta, que llegue a tiempo, que no supere el presupuesto...Estos requisitos pueden ser más valiosos que el hecho de ver las funcionalidades una a una. Por ejemplo, a todos nos gusta ver cómo construyen nuestra casa. Pero porque no queremos que se gaste nuestro dinero, y nos quedemos sin casa. NO (y repito: no) queremos ver cómo se añaden funcionalidades (puertas, paredes, suelos...). No queremos que nos pregunten por cada elemento que se añade al edificio. Tenemos otras cosas que hacer. Ahora: eso sí, no nos gustaría esperar a que se termine de construir, no nos gusta que nos digan que va a costar más porque han detectado "noseque", ni que se va a retrasar la entrega de llaves "pornosecuantos". Al único que le interesa que el cliente vea cómo se añaden funcionalidades, es al equipo de desarrollo. ¿Porqué? Pues porque somos inseguros, nos sentimos perdidos al añadir 2400 casos de uso, y nos sentimos más protegidos si el cliente los va validando uno a uno. Es algo natural. Pero entonces, no digamos que escuchamos al cliente. Estamos escuchando al equipo de desarrollo.
• No tener a un cliente que valide el producto a medida que lo desarrollamos, nos impide tener la seguridad de llegar al resultado deseado. Claro, somos nosotros los que queremos cercionarnos de que vamos por buen camino.
• Las pruebas en la metodología en cascada, se producen muy tarde, cuando ya se ha realizado el esfuerzo de desarrollo. Esto es natural para simples o pequeños desarrollos, pero es antinatural para proyectos más grandes. De todas formas esto es otra falacia: las pruebas no detectan que se esté construyendo algo incorrecto. Lo que verifican las pruebas, es que lo construído se corresponda con los requisitos identificados. Y si éstos son los que se tomaron incorrectamente...tendremos un desastre. No podemos reemplazar de un plumazo el análisis, diseño y pruebas por un usuario que nos valide el producto.
• La calidad del producto no se conoce hasta que no nos encontramos en las etapas más tardías del proyecto, tras el desarrollo. Aquí también tengo que quejarme. La calidad, está basada en una serie de actividades: validación, verificación, auditoría y control. Tan sólo la primera, valida sobre el producto final, que se cumplen los requisitos. El resto, permiten identificar desviaciones en la calidad del producto. Por ejemplo, la técnica de Peer Review, se puede utilizar durante todo el ciclo de vida: desde los requisitos, hasta el despliegue final. El problema es que tradicionalmente se han asimilado todas las actividades de aseguramiento de calidad a las pruebas, y por tanto, se estaba autolimitando al equipo de desarrollo.
• Los clientes siguen proporcionando funcionalidades nuevas (o cambios sobre las existentes). El argumento que se suele dar, es que es muy complejo asimilar estos cambios. De nuevo, estoy parcialmente de acuerdo. La gestión del cambio, es un proceso de gestión que está totalmente desvinculado del ciclo de vida de desarrollo que se esté utilizando. Y hay que realizarlo siempre, aunque uses SCRUM. Que el cliente tarde 3 meses en darse cuenta de que quiere algo nuevo, va a ocurrir tanto si trabajo en cascada, como si no. La esperanza de los detractores de las metodologías tradicionales, consiste en que al ver el cliente las funcionalidades parcialmente desarrolladas, podrá darse cuenta ANTES de que se han pasado cosas por alto. Existe un miedo irracional de que si se producen cambios tras la fase de análisis, no se podrán asimilar convenientemente esos cambios. De nuevo, esto lo único que me dice, es que los procesos de gestión del cambio ESTABAN MAL IMPLANTADOS.
• La metodología en cascada enlaza estrictamente unas actividades con otras, impidiendo que una actividad empiece hasta no terminar la anterior totalmente. Esto aumenta el tiempo de desarrollo innecesariamente.
• Al separar las fases, cada especialista trabaja separado de los demás. De esta forma, los analistas trabajan como en una cadena de montaje, pasando de proyecto a proyecto durante la fase de análisis de cada uno de ellos. Lo mismo ocurre con los programadores, o con los testers. El problema es que no hay un concepto de "equipo", que sepa hacer frente a los cambios solicitados. Con el tiempo, se ha ido cambiando de un modelo de profesionales especializados, a profesionales más generalistas. Por desgracia, esto también ha ido degenerando en unos cada vez más capacitados programadores, que hacen un poco de todo. Ya no se lleva tanto el analista que se dedica exclusivamente a realizar análisis y el tester que sólo diseña, construye y ejecuta pruebas. Esto último es parte ventaja, y parte inconveniente, aunque en modelos ágiles por ejemplo, quizás encaje mejor un perfil generalista que uno muy especializado.
• El cobro de las facturas durante el proyecto, se complica al no ver el cliente algo de valor. Efectivamente, es más fácil ir cobrando al cliente por partes "ya construidas".