Cuando hablamos de metodologías ágiles, una de las primeras cosas que primero le vienen a la gente a la cabeza, o que me dicen algunos clientes cuando les visito es, “Si, aquí trabajamos con iteraciones/sprints“, y en ciertas ocasiones la afirmación termina ahí, al final lo que se acaba teniendo es un modelo en cascada … con cascadas que duran aproximadamente cuatro semanas.
Pero, ¿por qué se hacen las iteraciones? Es una de las cosas que tenemos que preguntarnos, y una de las primeras respuestas, pero no la única, que me viene a la cabeza es, entregar valor lo antes posible y de modo continuado. Por lo que, si tras finalizar la iteración, nos hacemos la pregunta, ¿podemos darle esto a nuestros clientes?, y la respuesta es algo como “bueno, aún queda …” o “si bueno, pero hay que estabilizar el …”, hay algo que no hemos hecho bien, ya que el resultado de cada iteración, para que pueda darse por bueno, debería de ser potencialmente entregable a los clientes, aunque no vayamos a ponerlo en producción tras cada iteración.
Otra de las respuestas al por qué de las iteraciones es, eliminar la incertidumbre. Esto es básico en los proyectos de desarrollo de software, especialmente en metodologías ágiles. Cuando empezamos a trabajar en un proyecto así, siempre se habla de conceptos como arquitectura emergente, evitar planes detallados desde el principio, etc. Lógicamente esto genera incertidumbre, algo que tenemos que ir eliminando, pero la iremos eliminando según vayamos abordando el desarrollo del producto.
Seguro que todos hemos vivido situaciones, en las que, después de realizar un plan al detalle, desarrollar uan arquitectura, anticiparnos a casi todas las posibles situaciones, las prioridades, de repente, cambian, y todo ese trabajo no es válido, en este punto se suelen oír cosas como “es que el cliente no sabe lo que quiere”.
Lo que vamos a hacer, apoyándonos en las iteraciones, es establecer un plan a alto nivel inicial, en el que se plantee la visión del producto a construir, y establezcamos las prioridades iniciales, y aquí entran las iteraciones, iteración a iteración, vamos a ir estableciendo un plan, más detallado.
Las iteraciones las mantendremos entre 2 y 4 semanas, ya que más cortas es difícil (en la mayor parte de ocasiones) producir valor, y más allá de 4 semanas, es difícil hacer un plan detallado. Y aún así, es un plan, que, durante la iteración, el equipo (si, el equipo al completo), irá refinando, con prácticas como los daily stand-ups o daily scrum, en definitiva, con comunicación y transparencia.
Por supuesto, esto no es fácil, y requiere muchas otras cosas prácticas y mentalidad como poner la calidad desde el principio, en vez de al final, las ya mencionadas comunicación, transparencia, sentimiento de equipo, tener un objetivo compartido tanto para el producto al completo, como para cada iteración, y otras muchas cosas, que, si os parecen interesantes, iremos trabajando en futuros post, y relacionándolas con prácticas concretas de metodologías y desarrollo.
Foto | Flickr
Luis Fraile lleva trabajando en entornos Microsoft desde más de 10 años, empezando con Visual Basic 6, y posteriormente desde la primera versión del .NET Framework, habiendo participado en multitud de proyectos relacionados con estas tecnologías.
En los últimos años, a parte de desarrollar, también se ha dedicado a ayudar a equipos a la hora de abordar procesos de metodologías ágiles, especialmente en entornos Microsoft con tecnologías como Team Foundation Server. También es colaborador habitual de la revista Dotnetmania, así como ponente en eventos, a nivel nacional, relacionados con gestión de ciclo de vida y Team Foundation Server.
Puedes seguirlo en Twitter: @lfraile
Sus blogs son: <a href="http://ifraile.net">lfraile.net</a> y <a href="http://geeks.ms/blogs/lfraile">geeks.ms/blogs/lfraile</a></p> <br />
