Agile – aníbal goicochea

Para el desarrollo de sistemas, ¿deberíamos utilizar más prototipos?

Si la metodología en cascada no es lo más recomendable para implementar sistemas de información (como comentábamos en el post anterior), ¿qué deberíamos hacer? Quizás, una alternativa podría ser una metodología basada en el uso de prototipos.

Sobre el uso de prototipos, el documento de referencia señala: “… el proceso comienza con la creación de un prototipo inicial con todos los requerimientos pero no todas las funcionalidades. Con este prototipo los usuarios podrán probar el sistema y así observar errores o disfuncionalidades que sirven para revisar y mejorar el prototipo… un proceso iterativo que culminará con la obtención de la solución final que no requiera mejoras”

Las pruebas constantes que realizarán los usuarios, ayudarán a gestionar mejor los tiempos y a detectar mejor y más pronto los fallos. El uso constante de prototipos durante la implantación de un sistema o aplicación informática, podría brindar los siguientes beneficios:

Incrementa la productividad del equipo que implanta la solución y de los usuarios clave que colaboran definiendo las pautas desde la perspectiva del negocio.
Aumenta la calidad del producto final.
Disminuye los costes de mantenimiento.
Mayor receptividad del usuario.

Referencia: ISBN 978-84-7356-814-2

Para el desarrollo de sistemas, ¿la metodología en cascada debería evitarse?

A muchos de nosotros nos puede resultar familiar llegar a la puesta en marcha de un nuevo sistema o aplicación informática para darnos cuenta que algo no funciona como se esperaba, ya sea porque no se comprendió lo que se solicitaba o porque al realizar el desarrollo técnico se encontró una “limitación” de la herramienta informática. Esta situación, en gran medida, es por la metodología de desarrollo que se ha optado.

En la actualidad, muchos proyectos siguen la metodología de las fases Análisis, Diseño, Construcción, Implantación y Mantenimiento. Una metodología, con fases rígidas, formales, siguiendo un orden riguroso, secuencial, empezando la siguiente fase cuando ha culminado la anterior. Una metodología clásica, sino nos equivocamos, de más de 30 años, tiempos en que todo tenían un ritmo más pausado, muy distintos a los tiempos actuales que exigen más rapidez y flexibilidad.

El documento de referencia señala muy bien cuando podría ser útil la metodología clásica (también denominada en cascada):

“… este tipo de metodologías sólo se usa para el desarrollo de sistemas muy grandes que requieren gran formalización y los requerimientos son fácilmente reconocibles”

Y se señala las siguientes limitaciones de esta metodología:

Dificultad para eliminar errores
Falta de flexibilidad, el cual incrementa los costes y duración del proyecto.

Los fallos más comunes o triviales se detectan al comienzo, mientras que los más graves se detectan a la implantación, volviendo a ser necesario a analizar, diseñar y construir aquello que estaba mal implantado… ¡y comienza el caos!

Referencia: ISBN 978-84-7356-814-2

Lecciones sobre XP para implementar productos “desconocidos” (o nuevos)

Se trata de un nuevo producto, tanto para el usuario como para el implementador, hay nuevos términos, conceptos y formas de hacer las cosas, no hay más alternativa, el producto ya ha sido elegido, no cabe la marcha atrás y decir que el producto es malo, simplemente porque ante todo se desconoce, no ayuda.

Para un producto que aún tiene la etiqueta de “reciente innovación”, utilizar la misma metodología de implementación que se adoptaría si existiera más experiencia en el tipo proyecto y producto, ¿es lo más adecuado?

Utilizando como referencia un libro que comentamos meses atrás, mencionamos los aspectos más relevantes que hacen posible la eXtreme Programming (XP o programación extrema), aspectos que podrían ser tomados en consideración para facilitar la implementación de productos nuevos, cuyo funcionamiento es todo un “misterio”:

XP elimina la definición exhaustiva de requisitos, diseño y arquitectura, restringida en un espacio o período de tiempo concreto. No propone eliminar estas tareas, sino distribuirlas en toda la duración del proyecto.
Por ejemplo, cada semana se podría realizar un ciclo completo o iteración en la que se aborda algo de cada una de las fases tradicionales de un típico proyecto. Esto es posible abordando, según su importancia, las “historias de usuario” (requisitos o especificaciones del usuario sobre las tareas que realiza).
Cada semana se abordaría una “historia”, realizando en este período una planificación, análisis, diseño, desarrollo, pruebas y despliegue. Al finalizar la semana, se podría mostrar al usuario el resultado para obtener sus opiniones.
Es fundamental la identificación de usuarios clave con el conocimiento claro sobre las “historias” a implementar.
Al inicio del proyecto, las historias de usuario deben ser organizadas para su implementación, desde el punto de vista de prioridad del negocio y exigencia técnica.
La comunicación con los usuarios debe ser clara y fluida.

Una sugerencia para conocer más sobre Agile

Pretender recoger todos los requisitos o necesidades de los usuarios para un proyecto en concreto, en unas cuantas reuniones y luego de lo cual, dar por cerrada esta fase, impidiendo cualquier cambio o adicional posterior, “so pena” de cobro adicional. Seguro que nos parece “razonable” si pensamos como implementadores, pero nos parece algo incompresible si nos ponemos en el papel del usuario.

Ya sea porque siempre se “escapará” algún aspecto o porque el panorama es muy cambiante, el afán de tenerlo todo “atado” para iniciar un proyecto, debería superarse para lograr la real satisfacción del usuario. Cambiar este paradigma es posible con metodologías Agile, nada nuevas, pero muy desconocidas en cuanto a su estructura y puesta en aplicación.

“No debemos esperar a probar el nuevo producto en la fase final ya que la resolución del problema será, en sí misma, un problema.”

Un enfoque tradicional de un proyecto, propone fijar los requisitos con un alto nivel de detalle al inicio del proyecto y a partir de ellos, se hace una estimación del coste y de la fecha de entrega del mismo. Los métodos ágiles parten de un presupuesto y unas fechas de entrega y a partir de ahí se trabaja para implementar la funcionalidad, de este modo se logra un alcance flexible.

Para conocer más sobre Agile, sugerimos un libro que recientemente hemos “descubierto”, se trata de “Métodos Ágiles y Scrum” de Anaya (ISBN 978-84-415-3104-8), por lo poco que lo hemos leído, nos parece un documento de mucha utilidad.