Aquellos (estos) tiempos de cerrar requisitos

Las ocasiones que puedo, como hoy (sábado, aunque esto lo leerás el lunes), si tengo un rato tranquilo, después de levantarme, me pongo a leer libros técnicos, Ágiles, de software, etc. La mayoría de las veces me pongo con libros, relativamente, nuevos, pero otras muchas me gusta leer libros viejos.

Leer libros viejos mola, porque la mayoría de lo nuevo, lo que tanto nos gusta hoy, ya estaba escrito, y mola porque tiene su motivación intelectual descubrir viejas ideas, populares hoy, en sus páginas originales (como aquella vez del utilizamos la novedosa técnica de TDD»… ¿Cómo? ¿Novedosa? ¿Seguro?).

Y otra cosa que mola de leer libros viejunos es encontrar cosas obsoletas hoy, que se veían como imprescindibles en el pasado, y ver que aún hoy, «miles» de años después, hay quien se sigue aferrando a ellas y usándolas.

Hoy me dio por abrir el viejuno 201 Principles of Software Development del año 95. Un libro de hace casi 25 años, un clásico, que repasa 201 principios del desarrollo software, buenas y malas prácticas, la mayoría de ellas vigentes a día de hoy y que más de un@ debería leerse y memorizar. La mayoría de ellas vigentes… pero no todas.

Curiosamente, me llamó la atención el capítulo 3 que ofrece 22 principios de «ingeniería de requisitos» (el título del capítulo ya promete), los puedes leer más abajo, en la captura que he hecho del índice. 

Si repasas la mayoría de los anteriores, y lees (re-lees) el libro, quizá te teletransportes al pasado… o pienses que en casi 24 años no han cambiado tanto las cosas. 

Eran los tiempos, en muchos sitios siguen siéndolo, de cerrar los requisitos, de tener todos los requisitos cerrados antes de comenzar a desarrollar, de especificar al detalle, de escribir grandes documentos, etc.

Los tiempos del cascada, quizá más justificado su uso hace 20 años, quizá por no haber la incertidumbre del presente, la ambigüedad, las tecnologías, la competitividad, la cantidad de negocios de base tecnológica, etc., que hay ahora.

Te puede resultar antiguo, lo es, pero aún hoy, muchos años después existe mucho pensamiento similar, quizá remasterizado, ciertamente, quizá vestido de falsa agilidad, cambiando documentos por Backlogs en Jira, pero ese pensamiento de previsibilidad, especificar el futuro, miedo al cambio… existe. 

25 años pueden parecer muchos, en tecnología estamos acostumbrados a cambios casi a diario, pero para cierto tipo de pensamientos creo que el cambio no llega tan rápido, no es cuestión de unos cuantos años es cuestión… de muchos.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba