|
 La ingeniería del software clásica diferencia dos áreas de requisitos: requisitos del sistema, y requisitos del software.
A los primeros los sitúa en el proceso de adquisición, haciendo por tanto al cliente responsable de definir cuál es su problema y qué funcionalidades tiene que aportar la solución.
No importa que sea gestión tradicional o ágil. Esta sigue siendo la responsabilidad del cliente, aunque por supuesto las formas son diferentes.
- Los requisitos del sistema suelen especificarse en documentos formales; y el product backlog, o pila del producto toma la forma de una lista de historias de usuario.
- Los requisitos del sistema formales se especifican completamente en el inicio del ciclo de desarrollo, el product backlog es un documento vivo que se va desarrollando durante todo el ciclo de desarrollo de forma concurrente con el resto de actividades.
- Los requisitos del sistema los desarrolla una persona o equipo especializado en ingeniería de requisitos a través del proceso de obtención con el cliente. En Scrum la visión del cliente es conocida por todo el equipo y el product backlog se realiza y evoluciona de forma continua con las aportaciones de todo el equipo.
Pero la responsabilidad es del cliente, en el caso de scrum "propietario del producto", que tiene la responsabilidad de decidir lo que se incluye en la lista, y el orden de prioridad. El product backlog es la relación de las funcionalidades, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de las sucesivas iteraciones de desarrollo.
Representa todo aquello que esperan los clientes, usuarios, y en general todos los interesados en el producto.Todo lo que suponga un trabajo que debe realizar el equipo tiene que estar reflejado en el backlog.
Estos son algunos ejemplos de posibles entradas de un backlog: Permitir a los usuarios la consulta de las obras publicadas por un determinado autor.
Reducir el tiempo de instalación del programa.
Mejorar la escalabilidad del sistema.
Permitir la consulta de obra a través de un API web.
A diferencia de un documento de requisitos del sistema, el product backlog nunca se da por completo; está en continuo crecimiento y evolución.
Habitualmente se comienza a elaborar con el resultado de una reunión de "fertilización cruzada" o brainstorming en la que colabora todo el equipo partiendo de la visión del propietario del producto.
El formato de la visión no es relevante. Según los casos, puede ser una presentación informal del responsable del producto, un informe de requisitos del departamento de marketing, etc.
Sí que es importante sin embargo disponer de una visión real, comprendida y compartida por todo el equipo. La pila del producto evolucionará de forma continua mientras el producto esté en el mercado, para proporcionarle constantemente el mayor valor posible, y que resulte en todo momento útil y competitivo. Lo necesario para comenzar a desarrollar el producto es disponer de una visión comprendida y conocida por todo el equipo, y elementos suficientes en la pila del producto para llevar a cabo el primer sprint.
Formato de la pila del producto 
El desarrollo ágil prefiere la comunicación directa, antes que a través de documentos.La pila del producto no es un documento de requisitos, sino una herramienta de referencia para el equipo.
El formato debe ser el de una lista que incluya al menos la siguiente información para cada línea: - Identificador único de la tarea.
- Descripción de la tarea.
- Criterio de validación
- Campo o sistema de priorización.
Dependiendo del tipo de proyecto y funcionamiento del equipo y la organización, pueden resultar aconsejables otros campos:
- Estimación
- Persona asignada
- Nº de Sprint en el que se realiza
- Módulo del sistema al que pertenece
- Etc.
Scrum no debe tomarse como un protocolo rígido. El formato del product backlog no es cerrado.
Los resultados de scrum no dependen de la rigidez en la aplicación del protocolo, sino de la institucionalización de sus principios y la implementación en un "formato" adecuado a las características de la empresa y del proyecto.
 |
RSS de los comentarios
# Identificador único de la tarea.
# Descripción de la tarea.
# Campo o sistema de priorización.
# Persona asignada
# Nº de Sprint en el que se realiza
# Módulo del sistema al que pertenece
Leí de uno de los creadores de Scrum que no se podía considerar product backlog si no era una lista "estimada" y "priorizada" de tareas, así que a nosotros nos falta la estimación.
Sobre lo que comenta Juan, me parece interesante el campo "Criterio de validación", ya que nos da unas pruebas de aceptación al estilo que proponía XP con sus historias de usuario.
Si además conseguimos automatizar esas pruebas de aceptación, ya nos salimos (:
Saludos
JM