Esta nueva entrega del Manual de Metodologías Ágiles para el Desarrollo de Software, la vamos a dedicar a los Artefactos en Scrum, que nos dan las claves para una organización diaria.

Introducción

Scrum, propone tres herramientas o "artefactos" para mantener organizados nuestros proyectos. Estos artefactos, ayudan a planificar y revisar cada uno de los Sprints, aportando medios ineludibles para efectuar cada una de las ceremonias que veremos en un siguiente capítulo.

Describiremos ahora, cada uno de los artefactos, su definición e importancia para Scrum.

Backlog de Producto

El Backlog de Producto es un listado dinámico y públicamente visible para todos los involucrados en el proyecto.

En él, el Dueño de Producto, mantiene una lista actualizada de requerimientos funcionales para el software. Esta lista, representa "qué es lo que se pretende" pero sin mencionar "cómo hacerlo", ya que esta última, como vimos en el capítulo anterior, será tarea del Scrum Team.

El Backlog de Producto, es creado y modificado únicamente por el Dueño de Producto. Durante la ceremonia de planificación, el Scrum Team obtendrá los items del producto, que deberá desarrollar durante el Sprint. Formato del Backlog de Producto
El Backlog de producto, es una lista de items que representan los requerimientos funcionales esperados para el software.

Para cada uno de estos ítem, será necesario especificar:

• El grado de prioridad
• Esfuerzo que demanda
• Granulidad
• Criterios de aceptación

Priorización de los ítems del Backlog de Producto
Los items del backlog de producto, deben guardar un orden de prioridad, cuya base se apoye en:

• Beneficios de implementar una funcionalidad
• Pérdida o costo que demande posponer la implementación de una funcionalidad
• Riesgos de implementarla
• Coherencia con los intereses del negocio
• Valor diferencial con respecto a productos de la competencia

Estimación de esfuerzo
A diferencia de las metodologías tradicionales, Scrum, propone la estimación de esfuerzo y complejidad que demanda el desarrollo de las funcionalidades, solo para aquellas cuyo orden sea prioritario.

Estas estimaciones, no se efectúan sobre items poco prioritarios ni tampoco sobre aquellos donde exista un alto grado de incertidumbre.

De esta manera, se evita la pérdida de tiempo en estimaciones irrelevantes, postergándolas para el momento en el cual realmente sea necesario comenzar a desarrollarlas.

Granulidad de los ítems
Los items del Backlog de Producto no necesariamente deben tener una granulidad pareja. Es posible encontrar ítems tales como "es necesario contar con un módulo de control de stock y logística" o uno tan pequeño como "Modificar el color de fondo de los mensajes de error del sistema, de negro a rojo".

Ítems de tan baja granulidad, suelen agruparse en un formato denominado "Historias de Usuario" mientras que los de alta granulidad, son los denominados Temas o Epics.

Una historia de usuario es aquella que puede escribirse con la siguiente frase:

Como [un usuario], puedo [una funcionalidad] para [un beneficio]
Como usuario registrado, puedo cargar un voucher para calcular mi descuento en la compra.

Criterios de Aceptación
Cada ítem del Backlog de Producto, es necesario que especifique cuales son los criterios de aceptación (o test de aceptación que debe superar), para considerar cumplido el requisito.

Ejemplo:

Backlog de Sprint

El Backlog de Sprint es la recopilación sintética de items del Backlog de Producto, negociados entre el Dueño de Producto y el Scrum Team en la ceremonia de planificación, reunión que se realiza al comienzo del Sprint.

Esta recopilación, que durante la planificación ha sido propuesta por el Dueño de Producto y ya negociada, es aquella que el Scrum Team se compromete a construir durante el Sprint en curso.

El Backlog de Sprint, generalmente (y muy recomendado), se visualiza mediante tableros físicos – también llamados Scrum Taskboard - que hacen visible el proceso de construcción, a toda persona que ingrese al área de desarrollo.

Para armar el Backlog de Sprint, el Scrum Team, divide los items en tareas – tasks – de que no demanden una labor superar a una jornada de trabajo. Es decir, que una tarea, no debería superar las 8 horas de trabajo.

Estas tareas, serán divididas en pendientes, en curso y terminadas y cada una de ellas, debe permitir visualizar, como mínimo, el esfuerzo que demanda su construcción y el nombre del miembro del equipo que se ha asignado dicha tarea.

Es muy frecuente, a la vez de ser una práctica recomendada, que cada tarea sea a la vez, "etiquetada", diferenciando, por ejemplo, cuando representa un bug, una tarea de diseño, un test, etc.

Dividiendo un ítem del Backlog de producto en tareas
La estrategia consiste en desmembrar el item a la mínima expresión posible, encuadrada en un mismo tipo de actividad. El desmembramiento debe hacerse "de lo general a lo particular, y de lo particular al detalle".

Retomando el ejemplo anterior, intentaremos desmembrar, el primer ítem del Backlog de Producto:

Como administrador quiero poder administrar las secciones del sistema para poder establecer el orden de visualización de las mismas

Yendo de lo general (un ABM de secciones) a lo particular (hacer los modelos, vistas - lógica y layot - y controladores; testearlo, integrarlo y documentarlo), obtenemos una lista de tareas tentativa:

1. Crear modelos ? actividad: programar
2. Crear la lógica de las vistas ? actividad: programar
3. Diseñar el layout de las vistas ? actividad: diseñar
4. Crear los controladores ? actividad: programar
5. Correr los test ? actividad: testear
6. Integrar el ABM al sistema ? actividad: integrar
7. Documentar el ABM en el manual del usuario ? actividad: documentar

Luego, de lo particular, se irá al detalle. Los detalles, son aquellas restricciones que deberán considerarse para todo lo anterior. Por ejemplo, la creación del modelo, repercutirá en la base de datos. Por lo cual, tras crear los nuevos modelos, habrá que correr el ORM para que modifique las tablas.

Otro detalle a considerar, es el tiempo que demanda cada tarea. Por ejemplo, correr un ORM lleva solo algunos minutos, pues no puede ser considerado una única tarea. Entonces, puede "sumarse como detalle" a la tarea "crear modelos". De manera contraria, documentar en el manual del usuario, llevará todo un día de trabajo. Por lo cual, debe asignarse a una única tarea.

Tableros de Scrum
Con la lista de tareas ya armada, estamos en condiciones de crear el tablero.

Un Scrum Taskboard, básicamente se divide en 3 columnas: pendientes, en curso y terminadas y se complementa la información con un Diagrama de Burndown que mostrará el esfuerzo restante para concluir el Sprint.

Existen decenas de tableros que pueden implementarse. Recomiendo para ello, visitar http://www.xqa.com.ar/visualmanagement/

Incremento de Funcionalidad

El incremento de funcionalidad, es el que el equipo entrega al finalizar el Sprint. El mismo debe asemejarse a un "software funcionando", permitiendo implementarse operativamente sin restricciones en un ambiente productivo.