HPE entre los líderes de almacenamiento de Gartner
¿Qué tienen en común el arte marcial Aikido y las metodologías ágiles de desarrollo de software? La adaptación al cambio como premisa esencial.
Aikido plantea que, como el agua, uno debe adaptarse ante situaciones cambiantes. Uno debe unirse al adversario para lograr redirigir la energía y lograr de esta manera el control de la situación. Uno debe ser uno con su oponente para lograr la armonía.
En paralelo, las metodologías ágiles comprenden al cambio como un elemento presente a lo largo de todas las etapas de un proyecto. Uno debe saber adaptarse a las situaciones y escenarios de negocio cambiantes que hoy se plantean. Uno debe focalizarse en escuchar lo que el cliente necesita y colaborar con él, para lograr el objetivo último que es satisfacer sus necesidades. El cliente y quienes construyen el software deben ser un único equipo para lograr el éxito del proyecto.
A diferencia de varias de las metodologías llamadas “tradicionales” o de “cascada”, el modelo ágil utiliza un método de trabajo iterativo. No se plantea un análisis exhaustivo al comenzar el proyecto, sino que en su lugar se planifican entregas con funcionalidades generales llamados “Releases”, dentro de los cuales el alcance es negociable. Esto pone de manifiesto el precepto fundamental de que el cambio es bueno y debe aceptarse en cualquier etapa del proyecto. Esto genera una planificación de alto nivel necesaria para la gestión macro.
Por otro lado, las tareas se planifican y ejecutan en lapsos de tiempo constantes de entre dos y cuatro semanas, llamados Sprints. Al comenzar un Sprint, se prioriza en conjunto con el cliente los requerimientos existentes. Luego, en conjunto se define lo que se construirá en ese lapso de tiempo en base al tiempo disponible del equipo o Capacidad. Esto brinda una planificación más detallada de un corto plazo, necesaria para el seguimiento.
A su vez, diariamente se realizan reuniones cortas con todo el equipo, de no más de 15 minutos, llamadas “standup meetings”. Tienen este nombre ya que la idea es que la gente no se siente para lograr el objetivo de que sean de corta duración. En estas reuniones cada uno comenta 3 cosas: qué hizo el día anterior, qué problemas encontró y qué hará el día de hoy. Esto brinda una visión del avance diario de las tareas del proyecto a todos los miembros del equipo.
Lo mencionado anteriormente muestra claramente que en un proyecto ágil, al contrario de lo que muchas veces se piensa, se planifica quizás aún más que en un proyecto “cascada” tradicional. Se planifica a nivel general, por medio de Releases. Se planifica para el corto plazo, a través de los Sprints. Y se planifica diariamente por medio de las standup meetings.
Debido a la modalidad iterativa y al objetivo de brindar software funcionando al finalizar cada Sprint, es que se realizan tareas de análisis, desarrollo y testing del producto durante todo el proyecto y no en etapas consecutivas. Una consecuencia importante de esto, es que los errores o defectos son detectados tempranamente en la vida del proyecto. Esto disminuye los costos de mantenimiento adicionales que se generan al encontrar un error en una etapa avanzada del proyecto.
En las metodologías tradicionales, al incluir el testing como una de las etapas finales, estos costos se generan indefectiblemente. Esto es así ya que al momento de reportar un bug se debe considerar el tiempo en que el desarrollador que lo corregirá debe tomarse para recordar la funcionalidad que se está corrigiendo. Adicionalmente, analizar y comprender el código fuente escrito para solucionar el error y actualizar la documentación, en el mejor de los casos. Y si quien corrige el error no es quien codificó ese componente, los tiempos se incrementan. Por otro lado, para demostrar que el producto cumple con los requerimientos planteados, a fin de cada sprint se realiza una reunión de demostración de las funcionalidades implementadas durante el mismo. Este momento se aprovecha adicionalmente para la realización de una retrospectiva de lo sucedido durante el sprint. Aquí cada integrante del equipo tiene la oportunidad de mencionar qué cosas se hicieron bien y qué cosas deben mejorarse.
Este concepto de generar un producto funcional en cada Sprint, obliga a contemplar la calidad desde el inicio mismo, fomentando la mejora continua sprint a sprint con la realización de retrospectivas.
Quizás el concepto más importante en esta metodología es el de equipo. El proyecto es llevado a cabo por un único equipo. El cliente y el proveedor forman parte de un único equipo, ya que si alguno falla, el proyecto entero falla y todos pierden. Esto genera una alta interacción, brindando transparencia y visibilidad del avance del proyecto para el cliente y feedback constante para el equipo de desarrollo. Por lo tanto, el espíritu de equipo, la flexibilidad para responder al cambio y la buena comunicación son virtudes esenciales para esta forma de trabajo.
A nivel local, existen iniciativas incipientes (comunidades, cursos, eventos) que buscan difundir a la metodología ágil y compartir experiencias de este tipo. En el plano mundial, Estados Unidos y Europa están impulsando el uso de este modelo cada vez con más fuerza.
¿Por qué muchas empresas se resisten a utilizar esta metodología? El miedo al cambio es uno de los principales motivos. Morihei Ueshiba, fundador el Aikido solía comentar a sus discípulos que uno debe ser como el agua de un arroyo, que adapta su forma y su curso para llegar al río y luego al mar. Quienes lo comprendan estarán más cerca de la metodología ágil y del Aikido, listos para adaptarse a nuevos desafíos.
Diego Ferreyra – Core Technologies Manager de Huddle Group
