El desarrollo de aplicaciones de Software es un trabajo extremadamente complejo que requiere de profesionales con un alto nivel de conocimientos, con talento, con capacidad intelectual y, además, vocación para hacer frente a la necesidad de una continua actualización.
Puede ser que no sea imparcial ya que yo soy programador, pero no conozco ninguna profesión que necesite un reciclaje y aprendizaje constante al nivel de la de “pica código”. Sobre todo porque estamos en un frenesí de novedades que lleva el dicho “camarón que se duerme se lo lleva la corriente” a su más cruel realidad.
Para aumentar la complejidad, es un trabajo que se realiza en equipo, y con problemas de comunicación y de organización inherentes a las propias limitaciones del lenguaje natural. Todos habremos tenido la experiencia de que un requisito, una funcionalidad, descrita al detalle en un documento tanto en el qué, como en el cómo, de repente se da la vuelta y donde describía hacer una cosa nos encontramos que se podía interpretar de otra forma muy distinta. Y cuanto mayor fuera el esfuerzo necesario para completar el requisito, más dudas y equívocos emergían.
Definición de Sprint Backlog
Hace unas semanas escribí un artículo sobre las Pilas de Producto, y hoy quiero hablar sobre la Pila del Sprint, o Sprint Backlog. La cual es, en mi experiencia, una poderosa herramienta para organizar el caos con el que se enfrenta un equipo en cada iteración.
El Sprint Backlog es un listado de tareas que proviene del desglose de las Historias de Usuario que conforman la Pila de Producto (Product Backlog). Entendiendo como tarea, divisiones del trabajo que se puedan realizar en un plazo máximo de dos días y un mínimo de una hora; que sean atómicas en el sentido que se puedan finalizar sin necesidad de que sean dependiente de otras; que estén asignadas y así el equipo pueda saber de forma sencilla quien o quienes las están realizando; y que estén estimadas para poder saber cuantas podremos añadir al sprint o para calcular la velocidad del equipo.
Pero una imagen vale más que mil palabras y a continuación muestro una ficha de una Tarea en la herramienta que utilizo normalmente, y que es similar en todas las herramientas que tienes a tu disposición en el mercado. En este caso, Tema foundation Server Preview, una versión Beta de la herramienta de ALM de Microsoft, pero en la Nube.
Construcción
La construcción del Sprint Backlog es, en mi opinión, la reunión más importante de la metodología Scrum después de la Retrospectiva. Es el momento en donde el equipo asume la responsabilidad de su trabajo y toma las decisiones basándose en la verdad de que nadie sabe tanto de desarrollo como los desarrolladores. Esto, que parece una obviedad, ha sido una de las grandes disfunciones de las metodologías formales basadas en arquitectos y analistas funcionales que, por medio de hojas de carga, le remitían el trabajo a los programadores esperando que no pensaran, solamente que picaran código. Lo cual se ha demostrado a costa de mucho dinero y horas extras, que es una aproximación con un enorme riesgo de fracaso.
La reunión en la que se construye la Pila del Sprint es el Planning Meeting, o Reunión de Planificación. El equipo al completo va analizando tanto funcional como técnicamente, cada una de las historias de usuario según su prioridad, para irlas desmenuzando en tareas estimadas. En estas reuniones comúnmente emergen requisitos funcionales ocultos o se toman las decisiones técnicas de cómo se va a abordar la construcción.
Según la velocidad del equipo, se puede hacer una previsión cercana de cuanto trabajo es capaz de desarrollar en un Sprint, por lo cual se van añadiendo tareas hasta “llenar el cuenco“. Y así todos los miembros del Team pueden responsabilizarse del trabajo a realizar de forma segura y con garantías, ya que la decisión de cómo, cuanto y porqué la ha toma quien lo va a realizar y no viene de las estrellas por la invención de alguien que no se va a manchar las manos.
Al finalizar el Planning Meeting, obtendremos un nuevo tablero Scrum en donde se visualizarán las historias de usuarios priorizadas, y todas las tareas con las que vamos a construirlas y que entren en el Timebox del Sprint.
El día a día
El objetivo final de un Sprint Backlog, es ser la fuente de tareas que vamos a ir moviendo en nuestro tablero, sea físico o electrónico como en este caso. El porqué de un tablero en donde representemos nuestro flujo de trabajo, está más allá del alcance de este artículo, pero te puedo decir que es una herramienta muy potente para que el equipo y los actores involucrados en el proyecto, puedan tener una visión general del estado actual del proyecto.
Una de las liturgias que componen el framework Scrum es la reunión diaria o Daily Meeting. En donde cada uno de los componentes del equipo comparte con el resto las tareas en las que está trabajando, el camino por el que piensa continuar y los impedimentos que le impiden avanzar. En los equipos más “maduros“ el movimiento de las tarjetas de tareas se realiza durante toda la jornada, en tiempo real por decirlo de alguna forma. En cambio en los primeros pasos de los equipos en metodologías agiles, prefiero realizar la actualización del tablero durante esta breve reunión diaria para reforzar la comunicación, la sensación de que el tablero es realmente útil y para que el propio equipo realice un seguimiento del estado del Sprint.
También, y siguiendo el concepto de que el equipo es quien más sabe de desarrollo por lo cual es el que toma las decisiones sobre la construcción, aquí se pueden añadir o quitar tareas del sprint. Ya sea porque en el momento de emerger el diseño se comprueba que hay más tareas que realizar, porque la velocidad del equipo es superior a lo esperado y se pueden añadir más tareas, o porque impedimentos de cualquier tipo nos obligan a pasar tareas al siguiente sprint o descartarlas.
Resumen
Un Sprint Backlog es el listado de tareas en el que subdivide las historias de usuario que describen las funcionalidades que componen un proyecto. Este listado se define y estima en la reunión de Planificación del Sprint al inicio de la iteración. Las tareas deben ser pequeñas y poco acopladas para poder estimarlas. Se añaden tantas tareas como velocidad tenga el equipo.
Quien decide qué tareas, cuando, en qué orden y de que forma construirlas es el equipo. Es su potestad por ser quien tiene el conocimiento necesario para tomar decisiones sobre la construcción del proyecto.
Es una poderosa herramienta de organización ya que evita el lanzarse a picar código sin tener la mínima planificación (ASM), da visibilidad al equipo del trabajo a realizar y permite mantener un tablero en donde se observa de forma visual el flujo de trabajo y el estado del proyecto.