Mi primer proyecto usando una metodología menos “formal” que proceso unificado (RUP) fue un proyecto que típicamente se habría desarrollado en 3 meses y que por las restriccines de negocio tenía que ser liberado en 1 mes. Lo bueno es que era un proyecto para un equipo de no más de 10 personas y donde teníamos todo el respaldo y disposición del cliente para poder ir haciendo revisiones muy periódicas, diarias o varias veces al día. Iniciamos con un documento de casos de uso muy básico que en realidad eran las historias de usuario
mismas que se repartieron entre los desarrolladores. Se realizaron Wireframes y temas de diseño; trabajamos en un War Room, hicimos nuestras juntas diarias y revisiones de todas las miniversiones con el cliente final; el poryecto fue un éxito, al final terminamos con un producto con mucho más funcionalidades que las que se tenían identificadas al principio.
A continuación enumero algunas recomendaciones para usar metodologías Agile como SCRUM o Extreme Programming en los proyectos de desarrollo de software:
Seleccionar un proyecto pequeño pero significativo. No se recomienda iniciar con proyectos de demasiado alcance tanto en funcionalidad como organizacionalmente.
Armar un equipo de trabajo pequeño. Los equipos pequeños se comunican mejor y en Agile la comunicación del equipo es clave. El ideal de los equipos para desarrollo Agile es de 7 a 10 desarrolladores según experiencia de la industria.
Obtener respaldo del cliente. Si el cliente está acostumbrado a desarrollos largos con versiones de producto muy espaciadas, es importante educarlo y lograr su aceptación y respaldo de este nuevo enfoque donde se tendrán versiones muy rápidas e iterativas del producto; posiblemente implique más tiempo de revisión de los clientes, pero al final su nivel de aceptación será mayor.
Tener clara la funcionalidad y objetivos. Es crítico tener muy claro los objetivos y lista de funcionalidades deseadas, el desarrollo iterativo no tiene porque ser aleatorio o avance a ciegas.
Cambio de Actitud. Tanto el equipo de trabajo en compromiso como el cliente en tener la mente abierta para poder revisar versiones incompletas del producto.
En general, Agile no es para todo tipo y tamaño de proyectos ni para todos los tipos de empresas y/o clientes, si logras tener la mayoría de estas recomendaciones seguramente tu historia será de éxito.
Califica este articulo
(1 votes, average: 5 out of 5)
Loading ...
Discussion
No comments for “Agile Software Development no es para todos ni para todo”