A veces, cuando empezamos un nuevo proyecto no transmitimos o no nos transmiten correctamente la idea de lo que se va a desarrollar. Sí, sabemos las especificaciones técnicas y conocemos los requisitos pero no sabemos el porqué ni para qué se necesita esa nueva funcionalidad o ese nuevo sistema.
Sucede como cuando hay niebla en la carretera, no vemos bien hacia donde vamos por lo que tendemos a reducir la velocidad. No vamos tan rápido como si hubiese una clara visión del objetivo.
Si nos piden que desarrollemos un nuevo servicio web que acepta y envía un complejo lenguaje con información de residuos lo construiremos tal y como nos dijeron y ya está ¿Funcionó? ¿Sirvió para algo? ¿Se está usando? Ni idea, nadie sabe muy bien.
En cambio, si en la reunión de arranque del proyecto, alguien explica al equipo de trabajo que con ese servicio web se pretende conseguir que todas las comunidades autónomas intercambien información sobre lo que se hace con los residuos y hacia dónde los llevan los gestores. Sabiendo que con software como ese se puede evitar que baterías de coche usadas terminen vertidas en una playa de Senegal por el mercado ilegal de residuos tendremos un idea mucha más clara del objetivo.
Saber esto desde el principio va a ayudar al programador a entender mejor los requisitos, identificar si alguno es incorrecto o a proponer incluso mejoras ahora que sabe para qué sirve. Además de todo eso puede que esté más contento. Sabe que lo que está haciendo es útil, que sirve para algo y que es importante que no tenga errores (quizás esto sea más efectivo para la calidad del software final que las pruebas unitarias).
Referencias:
- Solving today’s complex projects with agility de Mike Griffiths en ULPGC por ITProiectus.
