Metodologias agiles en el desarrollo de sw


En mi experiencia como desarrollador he participado en varios proyectos donde he trabajado con una metodología pesada. La extensa documentación que se debe llevar en estas metodologías frente a la premura que muchas veces presentan los clientes en querer ver el proyecto en funcionamiento, causa que frecuentemente “pequemos” en solo centrarnos en la codificación, dejando a un lado aspectosimportantes en las etapas de análisis y diseño, incluso en la misma de requerimientos, llevándonos a suponer varios aspectos concernientes a estos, sin contar con la confirmación clara por parte del usuario.

Haciendo referencia a las palabras escritas en [3], donde el autor cita:
“Uno de los principios básicos define que el grado de progreso de un proyecto únicamente se mide por el softwarecreado que funciona. Es decir, software que ya proporciona valor al cliente, y que es potencialmente utilizable por él”.Pienso que poniéndome del lado del cliente es precisamente, el ver su proyecto funcionando, lo que le dice que un grupo de ingenieros está haciendo lo que debe hacer; suena “injusto” porque éste no sabe, a ciencia cierta, que hace un desarrollador (cuando utiliza una metodologíapesada) antes de mostrarle su producto. El cliente solo percibe que después de tomarle sus requerimientos el/los ingeniero(s) se va(n) por un tiempo y no se vuelve(n) a comunicar con él.

Enfrentado a esto y dado el largo tiempo que debe transcurrir para que el usuario final logre ver algo en funcionamiento y que muchas veces no tenga la aceptación total por parte del mismo, es el motivo por elcual en donde laboro, nos decidimos a cambiar a una metodología ágil.

Pudimos observar que no pasaba mucho tiempo después de la toma de requerimientos, en pasar a la codificación y luego empezar a involucrar al cliente mostrándole los avances por módulos de su proyecto. Pudimos notar la satisfacción del cliente, que aún sin tener el proyecto en su totalidad, se alegraba de ver pequeños módulos enfuncionamiento, creándose una idea de cómo iba a ver al final su producto. De estas pequeñas entregas veíamos que nos hacía nuevos requerimientos, pero debíamos entender que esto era parte del diario vivir de una metodología ágil.

En mi concepto, a pesar de que en las metodologías agiles se pase tempranamente de los requerimientos a la codificación, no quiere decir que las etapas de análisisy diseño sean menos importantes o que se aborden de manera superficial. Se aborda una etapa de Planificación-Definición donde se establece la visión y se fijan las expectativas del nuevo desarrollo, y para el diseño, el uso de las metáforas para dar una visión general y un entendimiento común del sistema y sus funciones y de cómo se debería construir sin dejar de lado que se debe diseñar lasolución más simple que pueda funcionar.
.

Como lo indica el autor en [2], citando el segundo valor del manifiesto ágil, en uno de los apartes dice: “La documentación, en las metodologías ágiles procura mecanismos más dinámicos y menos costosos como son la comunicación personal, el trabajo en equipo, la autodocumentación y los estándares”. Si bien es cierto que se reduce considerablemente lageneración de documentos, no quiere decir que estos desaparezcan del todo, pues de igual manera se llevan algunos (como para el caso de las retroalimentaciones con el cliente, en las que en ocasiones se generan nuevos requerimientos que debemos registrar con formatos como las historias de usuario o como cuando se hacen las entregas tempranas que se hace una lista de verificación con los ítems ocaracterísticas de lo entregado al cliente). Teniendo en cuenta lo anterior, esto es mucho más llevadero que la documentación exhaustiva de una metodología pesada, con esto quiero decir, que con la generación de los artefactos necesarios, se respalda la documentación de cada uno de los sistemas, logrando así que no queden sistemas sin ser analizados y documentados.

Me llama la atención el valor...