1.- El contrato, el cliente y el modelo de negocio
Decía el manifiesto ágil que aquello de que la agilidad requería de “Colaboración con el cliente sobre negociación contractual”.
Pero claro, si tu cliente es de los que te entrega al principio del proyecto un documento enorme lleno de requisitos, clausulas y posibles penalizaciones y no vuelves a verlo hasta el último día
de proyecto… olvídate de la agilidad, en serio, no va a funcionar.
La agilidad pretende obtener software que cumpla lo que los usuarios necesitan no que cumpla lo que pone en un documento de requisitos
2.- La calidad del software
Antes de ser ágil, hazte las siguientes preguntas…
¿Tenemos un robusto control de versiones? ¿programamos con calidad? ¿hacemos código espagueti? ¿copy paste? ¿complejidad ciclomática disparada? ¿pruebas unitarias? ¿diseño mantenible?
¿refactorizas? etc., etc., etc. Supongo que saber por dónde voy, no es cuestión de seguir con la lista.
Los anteriores son tan necesarios en un proyecto ágil, como en cualquier proyecto software, pero en uno ágil, por lo cortas que son las iteraciones… tiene el doble de impacto…si no las tienes a la
perfección… dudo que la agilidad te dure más de 5 iteraciones.
Como decía Fowler, “If you’re afraid to change something it is clearly poorly designed”.
3.- La documentación
Volviendo al manifiesto ágil… “Software funcionando sobre negociación extensiva”. Lo que no es lo mismo que “Software funcionando Y NO documentación comprensiva”.
Que en agilidad la documentación es menor, cierto. Que ocupa otro rol, cierto. Que se crea de otra manera, también. Pero no que no hay documentación.
Recuerda aquello de cómo lograr que tus clientes nunca puedan sustituirte y tenerlos atados para la eternidad.
Puedes encontrar más información en este libro:
Fundamentos de los Requisitos de Software