La Pila de Producto, o Product Backlog, es un artefacto del marco de trabajo para la gestión agile de proyectos de desarrollo de software, SCRUM. Y que es, en líneas generales, una lista ordenada u priorizada de las tareas que componen un proyecto de aplicación.
Aunque SCRUM no lo define, el formato que más se utiliza para la tarjeta de trabajo que compone una Pila de Producto es la Historia de Usuario. Sin que haya mayores problemas en utilizar Casos de Uso, o una lista de tareas.
Lo importante es que el propio esfuerzo de realizar la división en tareas implica una organización del trabajo y una primera visión del alcance del proyecto. Es decir, qué es lo que se quiere obtener después de semanas o meses de trabajo.
Construcción
La Pila de Producto, según Scrum, es propiedad del Dueño del Producto. Es decir el cliente final o su representante. Esto suena un tanto utópico ya que es muy difícil encontrar a un cliente que le pueda o quiera dedicar el tiempo y dedicación que requiere una gestión Agile de un proyecto, pero para esto tenemos la figura del Proxy.
Persona que se empapa del dominio y de lo que quiere el cliente final, para ejercer las labores de Dueño del Producto, y por ello quien, asesorado por el Scrum Master, define las historias de usuario que componen el Product Backlog.
Teniendo en cuenta que es un artefacto vivo y que va a sufrir modificaciones tanto de prioridad como de alcance durante todo el proyecto, se construye una primera Pila de Producto que comprenda la descripción de las funcionalidades esperadas a alto nivel.
En este momento el Product Backlog empieza a mostrar sus ventajas. Es un punto inicial para gerencia, si hubiese que presentar una oferta al cliente, en la estimación en tiempo y dinero del coste del proyecto. Ya que la definición del alcance la genera el propio cliente, o las personas que más saben sobre lo que quieren que realice la futura aplicación.
Por otra parte, el equipo adquiere la primera visión del proyecto. Cual es el objetivo y la motivación que ha llevado al cliente a pensar en que un desarrollo de software puede ser una ventaja o una solución a sus necesidades. En definitiva, porque es una mejora.
Y el cliente puede observar de forma visual y cómoda todo el trabajo que representa el construir su proyecto, decidir las funciones que más valor le aportan y detectar que cosas puede dejar en duda, por si no fuera necesario o interesante de construir.
Otra gran ventaja de utilizar Pilas de Producto es que permite encapsular una metodología Agile, como Scrum, dentro de un proceso formal de gestión de proyectos. Es decir, puedo cumplir con los artefactos clásicos de Toma de requisitos, Análisis funcional, Análisis Técnico, etc. Y, simultáneamente construir el Product Backlog (aunque con más esfuerzo) para empezar a desarrollar y ha obtener software que funcione de forma iterativa.
Hasta que dirección se dé cuenta que el esfuerzo dedicado a la documentación exhaustiva es dinero tirado a la basura en la mayoría de los casos.
Gestión y mantenimiento
El seguimiento de la Pila de Producto es una gestión relativamente sencilla pero que genera decisiones importantes y fundamentales en el proyecto.
En cada iteración, se realiza una revisión de las tareas del Product Backlog que han sido completadas y el Dueño del Producto tiene la potestad de repriorizar las tareas que quedan por realizar. O, como casi en todos los casos, hay que añadir nuevas tareas que no fueron detectadas en la construcción inicial de la Pila de Producto o que han surgido durante el proyecto.
Y aquí emerge otra ventaja de este artefacto. Ya que tenemos las historias de usuario estimadas y, como veremos más adelante, una media de velocidad del equipo, podemos darnos cuenta de forma temprana que el alcance no se va a poder completar en los plazos iniciales, por lo cual el cliente debe decidir qué cosas no se realizaran para poder añadir las tareas nuevas.
En una alegoría, un desarrollo Agile es como un cántaro. Lo puedes llenar de agua hasta el borde. Pero por cada gota que añadas de más, debes ser consciente que saldrá otra del recipiente. Ya que este no se puede estirar, al igual que pasa con el tiempo. Aún no se han inventado los días de 25 horas.
BurnDown y velocidad
La herramienta visual que nos facilita el conocimiento del estado actual del proyecto, basado en la Pila de Producto, es el BurnDown Chart.
Es un eje de ordenadas simple en donde en la horizontal tenemos una medida temporal. Ya sean fechas, o iteraciones. Mientras en el vertical tenemos una medida de cantidad de trabajo ha realizar. Ya sea por estimaciones en trabajo (horas o puntos de esfuerzo), número de tareas, etc.
Con ello, según va pasando el tiempo, obtenemos una línea descendente (o ascendente, según la orientación de la gráfica) en donde se visualiza de forma sencilla el estado del proyecto. Que cosas se han realizado, cuanto queda por realizar, si se ha variado el número de tareas o si se está dentro del alcance del proyecto.
Otra métrica que se puede obtener a partir del BurnDown es la velocidad del equipo. Por ejemplo, si veo en la gráfica que cada sprint de dos semanas el equipo, de media, es capaz de completar 230 puntos de esfuerzo, puedo afinar la estimación del número de tareas que me entran dentro del alcance del proyecto y tomar decisiones correctivas lo antes posible.
Y si en un sprint se han completado 150 puntos de esfuerzo, está claro que tengo un impedimento que ha llevado al equipo a trabajar por debajo de su ritmo habitual y que debe ser localizado, señalado y corregido.
Conclusión
El Product Backlog, o Pila de Producto, es un “must have“. Es decir, algo que todo equipo que considere la implantación de la filosofía Agile y sus metodologías asociadas, debe estar dispuesto a construir, mantener y utilizar.
Es importante comprender que el objetivo no es reportar a dirección o al cliente del trabajo realizado, aunque se pueda utilizar de esa forma. Si no que el equipo y el cliente sean conscientes del estado actual del proyecto y poder mantener una previsión del alcance de los desarrollos a futuros.
Es un mecanismo que provee de la visión del proyecto, que ayuda a que los errores salgan pronto y de forma llamativa para corregirlos lo antes posible; que permite ajustar el alcance de acuerdo a las necesidades reales y cambiantes de los clientes; y todo esto de una forma poco costosa para el proyecto y, a diferencia que en metodologías clásicas, no bloqueante. Es decir, mientras lo construyo o lo modifico el equipo no para de construir ni se queda detenido a la espera del documento funcional de turno.
En GenbetaDev | Historias de usuario, una forma natural de análisis funcional