Desarrollo Ágil (III): Comparativa entre métodos

Un pensamiento generalizado es que los métodos ágiles no son ni disciplinados ni planificados, y a pesar de que esto es totalmente erróneo es difícil, en muchas ocasiones, quitarles esta etiqueta. Lo cierto, es que los métodos ágiles pueden ser desde adaptativos a predictivos con el amplio abanico de puntos intermedios que esto conlleva. De hay que den esa impresión en ocasiones, si los miras desde fuera, de que son un poco caóticos.

Los métodos predictivos son aquellos que se centran en las planificaciones a futuro y en que estas sean lo mas detalladas posibles de forma que puedan en cualquier momento saber que tendrán que hacer a lo largo de toda la duración del proyecto. Desafortunadamente, estos planes de proyecto se basan en la definición inicial de este, con lo cual todos los cambios de dirección o alcance que puedan acontecer durante su transcurso serán difícilmente incorporables y requerirán de un esfuerzo extra para cambiar el rumbo del proyecto, por no mencionar, de que en ocasiones parte del trabajo hecho puede ser descartado para adaptarse a la nueva dirección.

En contraposición a esto, tenemos los métodos adaptativos. Métodos en los cuales, aunque no se podrá explicar con claridad las tareas a futuro, si que son altamente adaptables a cambios. Es decir, un equipo adaptativo podrá explicar con toda claridad que va a hacer la semana que viene, podrá explicar las características planificadas para dentro de un mes, pero como mucho, podrá hacer solamente una declaración de intenciones para dentro de seis meses.

Pues bien, como se ha comentado antes, los métodos ágiles pueden alojarse en cualquier punto entre ambos extremos.

Como ya se ha comentado anteriormente, los métodos ágiles se enmarcan dentro de los métodos iterativos ya que ambos se fijan el mismo objetivo de la liberación de software en cortos periodos de tiempo. La principal diferencia entre unos y otros, es que mientras que los métodos iterativos suelen medir estos periodos por meses, los métodos ágiles lo hacen en semanas. Además, en estos últimos, el trabajo se realiza de forma colaborativa.

Otro de los métodos más habituales es el de cascada que basa toda su fortaleza en la planificación y separación de todas las fases del proyecto: toma de requisitos, análisis, diseño, codificación y pruebas, cada una de ellas con unos entregables específicos para poder medir y controlar el correcto desarrollo del proceso. El principal problema que representa este modelo, es la dificultad de adaptarse a los cambios que se producen tras en inicio del proceso de desarrollo. Por este motivo, el modelo en cascada no se debería utilizar si no están claramente especificados los requisitos o se sospecha que en algún momento del proyecto estos pueden cambiar.

En una metodología ágil, este problema no se da, ya que al realizarse la planificación cada pocas semanas, la adaptación al cambio no es demasiado compleja.

Aún así, como para todo, hay opiniones que defienden unos y otros métodos.

Otro de los métodos es al que yo llamo ASM (A Salto de Mata) y que en ocasiones lo he visto también etiquetado como “cowboy”.Este método se basa en que los desarrolladores hacen lo que creen que es correcto, avanzando allí por donde pueden y solucionando los problemas como, en su opinión, creen que es correcto. En este tipo de proyecto se caracteriza por una comunicación de forma verbal, ausencia de documentación y reevaluaciones del proyecto.

Algunas de las características de los métodos ágiles concuerdan en ocasiones con esta última metodología, por este motivo, se desconfía de las metodologías ágiles.

Pero la verdad dista mucho de esto. Es cierto que la comunicación en los métodos ágiles, en muchas ocasiones en verbal y no genera documentación, pero no nos equivoquemos, esta comunicación es periódica, estricta, disciplinada y rigurosa, lo cual la diferencia sin duda del método ASM.

No vemos.