¿Ah, pero es que tiene defectos?
Pues claro. No existen metodologías todoterreno al 100% Vayamos viendo algunos. No con ánimo de decir: "mirad lo malo que es SCRUM" sino más bien "tened en cuenta esto en caso de que aplique a vuestros proyectos". Al final, lo importante es saber detectar los riesgos y mitigarlos adecuadamente.
- En general, dificultad de aplicación en grandes proyectos.
- Se requiere de un “agile champion”, experto en la metodología que monitorice su cumplimiento.
- Parte del paradigma consiste en usar el método “tal cual”, evitando adaptarlo a la empresa (supuestamente esto saca a la luz problemas en la metodología de desarrollo existente). Claro, si por otro lado arrancamos con el método ya adaptado a la empresa, es posible que no estemos aprovechando las ventajas de la metodología ágil.
- Plantea un problema si el desarrollo está restringido por una fecha de entrega y un precio de entrega cerrados por contrato
- Presupone que los requerimientos cambian, pero no de forma que el cliente acepte un diseño funcional/técnico.
- Presupone que el equipo está muy formado y motivado
- Presupone que el cliente está muy involucrado en el desarrollo, participa de forma activa y continua, y revisa frecuentemente el avance de la funcionalidad conforme salen a la luz los sprints. Esto sin embargo no parece producirse en la mayoría de nuestros proyectos: el cliente participa, pero no hasta el punto de dedicar tiempo y recursos para revisar pequeños avances en el desarrollo.
- Presupone que el cliente no exige ni necesita toda la documentación que manejan actualmente las empresas y que las diversas normativas internacionales requieren.
Parece que hay muchas, y así es. Pero esto no deja de ser una visión general de riesgos como en cualquier otro proyecto, pero esta vez desde el punto de vista de la metodología.
Para ver la segunda parte de este post, puedes hacer clic en este link.
No hay comentarios:
Publicar un comentario