Diferencia entre revisiones de «Backlog Del Producto»
(→Ver también) |
|||
| Línea 39: | Línea 39: | ||
==Ver también== | ==Ver también== | ||
* [[Scrum]] | * [[Scrum]] | ||
| − | * [[Backlog | + | * [[Backlog Del Sprint]] |
Revisión del 19:04 31 jul 2008
El backlog del producto en Scrum es el artefacto más importante de Scrum, ya que dirige la construcción. Hasta el equipo más efectivo y eficiente fallará si construye lo que no es necesario.
El backlog es un inventario o una lista priorizada de requerimientos funcionales, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de las sucesivas iteraciones. Representa todo aquello que esperan los clientes, usuarios, y en general 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 una 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; o un proceso de “Exploración” (Extreme Programming), o en el Sprint 0 (preparación) donde 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.
El product backlog evolucionará de forma continua mientras el producto esté en el mercado, para darle valor de forma continua, y mantenerlo útil y competitivo.
Formato
El desarrollo ágil prefiere la comunicación directa, antes que a través de documentos. El product backlog no es un documento de requisitos, sino una herramienta de referencia para el equipo. Es recomendable el formato de lista que incluya al menos la siguiente información para cada línea:
- Identificador único de la funcionalidad o trabajo.
- Descripción de la funcionalidad.
- Campo o sistema de priorización.
- Estimación
Dependiendo del tipo de proyecto, funcionamiento del equipo y la organización, pueden resultar aconsejables otros campos:
- Observaciones
- Criterio de validación
Cada ítem del backlog del producto debe tener una estimación de alto nivel del esfuerzo para convertir cada item en un elemento completo del sistema. El Dueño Del Producto es el responsable de mantener el contenido del backlog del producto, y asegurar que están continuamente priorizados para alinearse a las necesidades del negocio. La prioridad debería ser asignada en base a la importancia de cada item para el negocio, o aquellos que ofrezcan un más rápido retorno de la inversión. Esta lista debería evolucionar, cambiando a medida que varian las condiciones del negocio o cambia la tecnología.
