¿Qué ciclo de desarrollo es el mejor?
Esta discusión es ya un clásico del desarrollo del software y, aunque no hay una respuesta genérica, sí hay factores que permiten responder a la pregunta en un proyecto concreto.
No todo es WATERFALL o AGILE
Aunque siempre se focaliza en estos dos en el post reflejaré los 4 ciclos de desarrollo más extendidos: WATERFALL, INCREMENTAL, ITERATIVO y AGILE.WATERFALL o CASCADA: Es el ciclo de desarrollo tradicional. Se trata de un modelo de desarrollo secuencial con resultados claramente definidos para cada fase. Para su ejecución se requieren profesionales especializados en cada fase.
INCREMENTAL: Su objetivo principal es la construcción del sistema de forma gradual, incorporando nuevas capacidades al sistema con cada iteración. Cada iteración puede considerarse un subproyecto WATERFALL.
ITERATIVO: Similar al anterior con la diferencia de que en cada iteración se revisa el producto. Mientras que el INCREMENTAL tiene un enfoque de "añadir a" el enfoque del ITERATIVO es "re-hacer".
Los modelos INCREMENTAL e ITERATIVO añaden flexibilidad frente a WATERFALL ya que en cada iteración incorporan requisitos (ya partan de una revisión del producto o no) pero cada iteración es desarrollada mediante WATERFALL. Además, en cada iteración es posible incorporar las mejoras aprendidas de la anterior con lo que es posible mejorar el desarrollo.
Las métodologías ágiles están basadas en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan mediante la colaboración de grupos auto organizados y multidisciplinarios. Se valoran la interacción y los productos entregados frente a la documentación.
Actualmente AGILE se ha convertido también en base del modelo de desarrollo de negocios (al ser junto a Lean y Customer Development una de las influencias del método "Lean Startup" de Eric Ries).
El siguiente diagrama refleja esquemáticamente el ciclo de desarrollo en cada metodología:
En mi proyecto, ¿qué opción es la mejor?
No existe tal respuesta aunque sí algunos factores que pueden determinarlo en cada proyecto. A continuación describo los de mayor impacto:1.- GRADO DE CERTEZA
¿Conozco los requisitos?, ¿son estables?
Cuanto más claros y estables estén los requisitos del proyecto más apropiado puede ser WATERFALL. En WATERFALL es viable gestionar los cambios de requisitos pero, cuanto menor es la certeza de los mismos y más avanzado está el proyecto, el riesgo de los cambios es mayor.
Cuanto menor sea el grado de certeza más apropiado AGILE. En AGILE los nuevos requisitos son bienvenidos, AGILE aporta la flexibilidad necesaria para que estos cambios no impidan el correcto avance del producto.
En casos intermedios los modelos INCREMENTAL o ITERATIVO pueden aportar la flexibilidad necesaria.
2.- EQUIPO
¿Qué tamaño tiene mi equipo?, ¿qué experiencia tiene?, ¿dónde está ubicado?
Si el proyecto requiere un equipo muy grande será necesario partirlo en equipos menores que trabajen en aspectos concretos del proyecto. En este caso es probable que el equipo esté formado por especialistas (analistas, arquitectos, desarrolladores, testers, etc). Si este es el caso WATERFALL parece lo sensato. Existen modelos que permiten escalar AGILE a proyectos de grandes dimensiones aunque ponerlos en marcha de forma efectiva no es trivial.
Otra opción en este primer caso es emplear INCREMENTAL o ITERATIVO.
Por contra, si el equipo de proyecto es menor o se trata de un equipo multidisciplinar, podemos aplicar AGILE.
Finalmente, la localización distribuida complica los proyectos AGILE. Esto no significa que sea imposible pero es un hecho que se complica y hay que buscar mecanismos que lo compensen.
¿Conozco a mis usuarios?, ¿están dispersos o son un grupo controlado?, ¿qué grado de implicación esperan del proyecto?
Un grupo controlado de los usuarios finales con fuerte influencia puede ayudarle a definir los requisitos y gestionar los cambios. Esto puede ayudar a lograr la estabilidad de requisitos (Certeza) que un proyecto WATERFALL precisa.
Un grupo disperso de usuarios puede tener un amplio abanico de requisitos que, en ocasiones, no se puede definir hasta que tienen acceso al producto. En esta situación la elección sería AGILE.
Finalmente, si los usuarios esperan una implicación importante en el proyecto, AGILE les proporciona un papel fundamental. Los modelos INCREMENTAL e ITERATIVO también les permiten ver versiones del producto antes de finalizar. En WATERFALL sus expectativas no se verían cumplidas.
4.- RESTRICCIONES TEMPORALES
¿El plazo del proyecto agresivo o conservador?, ¿existen prioridades en ese plazo?
En plazos agresivos, si somos capaces de consensuar prioridades claras, usar AGILE puede proporcionar resultados a corto plazo que reduzcan la presión del proyecto.
Por contra, si los plazos no son agresivos, tanto WATERFALL como AGILE son modelos viables.
Existen otras variantes como son plazos agresivos con prioridades no claras. En ese caso, previsiblemente el proyecto no tenga salvación. Lo más recomendable sea la negociación para llegar a uno de los 2 escenarios anteriores.
5.- BASE TECNOLÓGICA
¿Dispongo ya de lo necesario para arrancar?, ¿qué esfuerzo implica crear la infraestructura hardware y software?
En proyectos grandes se puede requerir un tiempo importante para la construcción de la base tecnológica sobre la que ir creciendo.
Esa base incluye los entornos (virtuales o físicos), el software sobre el que construir, etc.
Si el tiempo requerido para construir esta base supone la mayor parte del tiempo del proyecto (por ejemplo porque la solución se basa en un producto comercial sobre el cual básicamente hay que configurar) puede encajar WATERFALL. Aplicando AGILE en este contexto es importante tener en mente el producto completo y no sólo el ciclo de desarrollo en curso para evitar la deuda técnica nos obligue a enormes esfuerzos de refactorización.
Una vez construida esa base se puede utilizar AGILE en las evoluciones posteriores.
No hay comentarios:
Publicar un comentario