Proyectos de software ágiles
A menudo, cuando hablo con colegas ingenieros de otras áreas o jefes de proyectos de desarrollo tradicional acerca los proyectos de desarrollo software ágiles, me preguntan cómo es posible que podamos trabajar en el proyecto sin disponer de una planificación definida. La respuesta es sencilla, el hecho de que no sigamos una rigurosa planificación definida al inicio del proyecto, no significa que no planifiquemos. El desarrollo ágil en general y en Scrum en particular SÍ planificamos, es sólo que lo hacemos de otra manera distinta a la tradicional.
La planificación ágil parte de la idea de planificar en función de objetivos de negocio en lugar de tareas (a diferencia de la planificación tradicional), priorizando los que aportan más valor, y esperando a dar detalle a objetivos y tareas conforme se va acercando el momento de construcción de estos objetivos, cuando la indeterminación se va reduciendo, de manera que se amortiza el esfuerzo de planificar de manera detallada.
Si pensamos que la planificación ágil es lo mismo que la planificación de proyectos tradicional estaríamos cometiendo un error. El hecho es que debe adoptar un enfoque muy diferente cuando se trata de agilismo en general y de Scrum en particular, ya que los proyectos Scrum, por ejemplo, se llevan a cabo en iteraciones cortas e independientes conocidas como Sprints.
En terminología Scrum, cuando definimos el proyecto, o producto, vamos añadiendo diferentes niveles de detalle a medida que nos acercamos al momento presente. Es decir, partiendo de una definición de la familia de productos o la línea de trabajo desde la que partimos, se define la visión del producto, y de ahí el roadmap de desarrollo, que incluye los diferentes releases del producto. Dicho de otra forma, tenemos la visión de lo que queremos conseguir, un plan a nivel general de las diferentes entregas y qué incluirá cada una. Con este plan se construye el Product Backlog que es una lista priorizada de las funcionalidades que tendrá nuestro producto, escritas en formato de User Stories. En cada iteración o sprint, se eligen aquellas que van a ser utilizadas, conformando el sprint backlog.
La idea clave de la planificación ágil es vincular todo lo que se hace en el desarrollo a las estrategias y objetivos de la empresa.
Esto significa que la planificación comienza en la cima (CEO, alta dirección) y se va detallando progresivamente hasta llegar al nivel de los equipos que ejecutan el trabajo.
Una metáfora de este proceso de planificación es la cebolla de la planificación ágil, la cual representa de manera gráfica una planificación multicapa.
Agilismo y planificación de producto o proyecto no son incompatibles. La planificación multicapa o “Cebolla de la Planificación” ayuda a los equipos de producto a elegir el nivel adecuado de detalle dependiendo del alcance temporal en el que están planificando.
Estos niveles son:
- Visión
- Roadmap
- Release
- Iteración
- Diario o daily
Visión
En lo más alto del modelo tenemos el nivel de la Visión. La visión define el futuro del producto a largo plazo, que según el proyecto de que se trate puede ser un período típicamente de entre uno y varios años. La visión debe expresar y ayudarnos a entender el valor que nuestro producto aporta a los clientes y cómo podría diferenciarse de otras soluciones que intentan resolver los mismos problemas. Aunque la visión debe tener una vocación de estabilidad y de referencia a largo plazo esto no quiere decir que no tenga que revisarse periódicamente, sobre todo en mercados muy dinámicos como es el del software.
Roadmap
El roadmap es uno de los artefactos principales de la estrategia de producto y define cómo se van a alcanzar los objetivos plasmados en la visión a lo largo del tiempo, a medio plazo en los próximos meses. El roadmap despliega y expande la visión en una sucesión de versiones de producto, que se conocen como backlogs de release.
El roadmap interno va dirigido a departamentos y stakeholders de la propia empresa y suele ser muy detallado, incluyendo calendarios, proyectos, tecnologías, etc. y constituye una potente herramienta de planificación y desarrollo. El roadmap no habla solamente de features, sino también de mercados, aplicaciones, personas, problemas, escenarios, valor, capacidades y diferenciadores clave y objetivos de negocio.
Por el contrario, el roadmap externo va dirigido al mercado, es menos detallado y constituye esencialmente una herramienta de comunicación y marketing.
Tanto los roadmaps internos como los externos transmiten una información de prioridades y de disponibilidad.
El roadmap debe revisarse y actualizarse con mayor frecuencia que la visión y, obviamente, siempre cuando ésta ha sido modificada. Períodos entre dos y seis meses, e incluso menores son habituales.
Release
En este nivel el objetivo es especificar las funciones y características que poseerá cada release definida en el roadmap. El backlog de release es un artefacto táctico que lista los trabajos necesarios para cumplir el plan estratégico de producto. La constituyen principalmente los equipos de proyecto y desarrollo.
A diferencia del roadmap, que no debería entrar en excesivo detalle sobre funciones y características, el backlog de release se compone de épicas e historias de usuario, diagramas de flujo, bocetos de diseño y mockups de experiencia de usuario.
El backlog de release se deriva del roadmap. Pero la influencia contraria también es posible, ya que el feedback sobre la release que recibimos de los clientes puede servir para reajustar el roadmap. Por lo tanto, roadmap y backlog deben estar sincronizados.
El backlog de release se debe actualizar con cada actualización del roadmap y con cada liberación de release.
En Scrum, se usa un artefacto que está a caballo entre el roadmap y el backlog de release, llamado “backlog de producto” y puede recoger un backlog que abarca varias releases.
Iteración (Sprint)
En una filosofía de desarrollo ágil, en el nivel de iteración el equipo selecciona los elementos individuales del backlog que comprende el siguiente ciclo y crean un plan para entregar cada historia.
En Scrum a este nivel tenemos la sesión de planificación del sprint (Sprint Planning). La planificación de iteración se realiza al principio de cada ciclo, es decir al inicio de cada sprint, que tienen una duración de entre 1 a 4 semanas.
El Sprint Planning es una reunión que se realiza al comienzo de cada Sprint donde participa el equipo Scrum al completo; sirve para inspeccionar el Backlog del Producto (Product Backlog ) y que el equipo de desarrollo seleccione los Product Backlog Items en los que va a trabajar durante el siguiente Sprint. Estos Product Backlog Items son los que compondrán el Sprint Backlog.
Diario (Daily)
En este nivel de planificación el equipo evalúa el status al principio del día actual y colabora para elaborar un plan para avanzar hasta el siguiente día.
En Scrum esta planificación diaria se lleva a cabo mediante una reunión diaria llamada daily o standup.
“La Daily” es una reunión diaria de 15 minutos en la que participa exclusivamente el equipo de desarrollo, en ella, todas y cada una de las personas del equipo de desarrollo responden a las siguientes preguntas:
- El progreso conseguido en el día anterior.
- El progreso que esperan conseguir en el día actual.
- Si tiene obstáculos o impedimentos que pueden impedir dicho progreso.
En conclusión, una gestión ágil de proyecto no debe significar que no tengamos un plan, sino que nos centramos en aplicar un plan que sea flexible que nos permita acomodar cambios y mantenga un equilibrio entre el largo y el corto plazo.
¿Quieres aprender a desarrollo y gestión ágil de proyectos Python? Puedes hacerlo en el Máster Profesional en Programación avanzada en Python para Big Data, Hacking y Machine Learning
