"Si puedes soñarlo, puedes hacerlo". Walt Disney.
 |
| Image courtesy of Stuart Miles / FreeDigitalPhotos.net |
Quienes venimos de enfoques tradicionales de desarrollo de software
caracterizados por proponer y hasta exigir una diversidad de artefactos,
encontramos la Lista de Producto (Product
Backlog) de Scrum como algo tan hermosamente simple que raya en lo poético.
Quizás a esa simplicidad se deba su inmensa popularidad entre los practicantes
ágiles.
La Lista de Producto es un inventario priorizado del
trabajo pendiente necesario para traer el producto a la vida. El Dueño de Producto
es el responsable de la Lista de Producto y de su contenido. Nadie tiene una
visión del producto que va más allá del producto en sí, como el Dueño de
Producto.
Sus elementos pueden incluir:
- Una exploración de las necesidades del usuario
- Opciones técnicas variadas
- Una descripción tanto de requisitos funcionales como no funcionales
- El trabajo necesario para lanzar el producto
También puede contener otros elementos como:
- Configuración del entorno
- Defectos del producto.
La Lista de Producto reemplaza los artefactos tradicionales de
requisitos, tales como las especificaciones de requisitos del software. Mientras
que el Dueño de Producto se compromete a manejar la Lista de Producto, el Scrum
Master, el equipo y los interesados contribuyen a esta tarea. Juntos, descubren
la funcionalidad del producto. Además, la Lista de Producto es también una
herramienta para proporcionar transparencia durante el proyecto.
Sobre la Priorización
La priorización de la Lista puede hacerse de muchas
formas, pero es algo que siempre se hace con el Dueño de Producto a bordo,
liderando la priorización. Por ejemplo, es posible crear temas que contienen
una lista de historias. Cada uno de estos temas tiene un “costo de retardo”
asociado. Esto permite conocer el impacto de no implementar un tema si antes
implementamos otro.
En este apartado debemos tener en cuenta que si se nos
dificulta la priorización de la Lista de Elementos del Producto, puede estar
sucediendo que:
- Los elementos, por ejemplo las historias de usuario, son muy grandes para priorizar
- No hay ningún valor de negocio asociado al Elemento de la Lista de Producto.
Sobre los defectos del producto
Si te estás preguntando como encargarte de esas anomalías que surgen o
pueden surgir luego de la salida a producción del software y no sabes si
decidirte por usar historias y priorizarlas en la Lista de Producto junto con
las nuevas características, y si no estás buscando dogmas, puedes simplemente
pensar en trabajar con el Dueño de Producto para clasificar y priorizar esos
defectos en producción, luego los puedes tratar como historias de usuario a
incluirlos en una entrega específica.
Al igual que en enfoques clásicos de mantenimiento de productos, si el
defecto causa un alto impacto en los usuarios, este debe escalarse y resolverse
como un ajuste en producción sin pasar por la cadencia normal de Scrum. Lo que
sí puedes hacer es manejar la reparación del software usando un proceso Kanban,
el cual permite un enfoque más liviano de gestión. Eso sí, no olvides que un
error en producción representa valor negativo para el negocio así que dedica un
esfuerzo mayor a evitarlos o a reducirlos al mínimo más que a corregirlos.
Cuando hagas esto piensa que:
- Si una parte del producto tiene desperfectos, todavía no está Terminada.
- Cualquier trabajo que necesite hacerse, necesita priorizarse.
- Cualquier actividad que realice el equipo, toma tiempo.
- El tiempo consumido en una cosa, no puede consumirse en otras cosas.
Los Atributos DEEP de la Lista
de Producto
Dice Mike Cohn que una Lista de Producto efectiva tiene estas cuatro
propiedades: detallada
apropiadamente, estimada, emergente y priorizada. De allí el acrónimo DEEP.
Detallada Apropiadamente
Los Elementos de la Lista de Producto en la parte superior se describen
en mayor detalle que los que están en la parte inferior de la Lista. A medida
que bajamos en la lista, los elementos están menos detallados. Esto tiene
sentido: son elementos que se convertirán en software apenas varias iteraciones
más adelante o quizás nunca, si el usuario nota que no los necesita o si se
acaba el presupuesto del proyecto. De hecho, es posible que el Dueño de
Producto cambie la prioridad de alguno de estos, en cuyo caso solo debe llenar
los vacíos de ese elemento para que quede “preparado” para construirse.
Figura: La priorización de la Lista de Elementos del Producto determina
el nivel de detalle
Esta técnica
asegura que la Lista de Producto se mantenga concisa y que los elementos a
implementarse en el siguiente sprint son trabajables. Una consecuencia de este
enfoque es que los requisitos se descubren, se descomponen y se refinan a lo
largo de todo el proyecto. Es otra de las razones por las cuales el Dueño de
Producto debe trabajar con el Equipo de Desarrollo cotidianamente durante todo
el proyecto, o más o menos así reza uno de los Principios Ágiles.
Estimada
La estimación
de los Elementos de la Lista de Producto usualmente se expresa en puntos de
historia o en “días ideales”. Conocer el tamaño de los elementos ayuda a
priorizar y a planificar las entregas a producción. Recordemos que otras
estimaciones más detalladas a nivel de tareas se realizan durante la Reunión de
Planificación del Sprint; y también, estas tareas y sus estimados se capturan
en la Lista de Pendientes del Sprint.
Un día ideal es una abstracción del número
de horas diarias en las que normalmente esperas que un miembro del equipo sea
productivo, restando tiempo para asistir a reuniones, ir al baño, tomar un café
o simplemente hacer una pausa laboral.
Emergente
La Lista de
Producto tiene una cualidad orgánica. Evoluciona y su contenido cambia frecuentemente.
Nuevos elementos se descubren y adicionan a la Lista basados en
retroalimentación del usuario, principalmente. Los elementos existentes se
modifican, re-priorizan, refinan o se remueven permanentemente.
Priorizada
Todos los
elementos en la Lista de Producto se ordenan según su valor e trascendencia
para la Organización. Los elementos más importantes y de más alta prioridad se
implementan primero. Estos pueden encontrarse al principio de la lista, como
indico en la Figura 1. Luego de que un elemento esté “Terminado”, se elimina de
la Lista de Producto.
Finalmente
La Lista de
Producto existe por un propósito más grande: construir un producto que impacte
a los usuarios, que haga resonancia en ellos/ellas y que cambie en algo sus
estilos de vida.
El producto
debe construirse de manera orgánica, es decir, tan pronto como sea posible,
debemos tener una versión que los usuarios puedan usar, el producto mínimo
viable. A partir de este producto parcial, coherente y de valor, se construye
el producto completo.
Al
construirlo, piensa que estás componiendo una pieza musical grandiosa, la
sinfonía definitiva, una que será recordada por siempre. Una obra así despliega
patrones, trayectorias e incita a las personas a estar a su alrededor.
¿Quieres saber más?
Te recomiendo
ampliamente este artículo de Jeff Sutherland:
Enabling
Specifications: The Key to Building Agile Systems
La Guía de Scrum: http://www.scrum.org/scrum-guides
El libro de Roman Pichler,
Agile Management with Scrum, Creating
Products That Customers Love. Addinson-Wesley,
2010.
Sobre Historias de Usuario, mi serie de
artículos:
Historias de Usuario: un nuevo orden en los requisitos
del software
Historias de Usuario Altamente Efectivas,
Parte 1
Historias de Usuario Altamente Efectivas,
2
Historias de Usuario Altamente Efectivas,
3
Historias de Usuario Altamente Efectivas,
4
