Llevo ocho meses trabajando en un proyecto que implica el desarrollo de software. El proveedor de desarrollo utiliza internamente metodología ágil. Todavía no sé si la amo o la odio. La metodología me refiero. Depende del día que me preguntes.
La teoría es fácil. El desarrollo de software utilizando metodología ágil, permite entregas frecuentes de software, la funcionalidad que se añade está bien definida y priorizada por el cliente y éste puede probar y ajustar de acuerdo con las necesidades del entorno. Se supone que vamos a desarrollar más rápido, con más calidad, vamos a satisfacer mejor las expectativas del cliente y va a ser más barato. ¿Es esto verdad? Solo a veces.
En un proyecto tradicional, la cosa está clara. Se definen unos requerimientos, se acuerda que tipo de arquitectura se va a utilizar, el proveedor hace una oferta con un precio cerrado de desarrollo que incluye plazos de entrega y se empieza. El proyecto puede ir bien o mal, pero hay un plan inicial y tenemos metodologías suficientes para medir y gestionar desviaciones, tomar decisiones para manejar estas desviaciones y llevar el proyecto a una conclusión.
En un proyecto ágil, en el que todo va evolucionando según las iteraciones se desarrollan:
- ¿Cómo se define el alcance?
- ¿Cómo se sabe cuándo se va a acabar el desarrollo?
- ¿Cómo se controla el presupuesto?
- ¿Cómo se gobiernan los cambios?
- ¿Qué papel tiene que jugar el cliente?
Los proyectos ágiles exigen un cambio de mentalidad en todos los que participan, especialmente cuando el proveedor del software es una empresa contratada por el cliente y no un departamento de desarrollo interno.
Durante los próximos post iré tratando los diferentes aspectos mencionados anteriormente. Ahora, hay que leerlos con la mente muy abierta, porque si estás a punto de embarcarte en un proyecto de este tipo, ya te aviso … tu vida va a cambiar