Diferencia entre revisiones de «Backlog Del Producto»

De Dos Ideas.
Saltar a: navegación, buscar
(Ver también)
Línea 1: Línea 1:
 
[[Category:Scrum]]
 
[[Category:Scrum]]
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 (o pila) 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.
+
El backlog es un inventario o una lista priorizada de requerimientos de usuario 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  aporte valor al usuario, en términos del producto final, tiene  que  estar  reflejado en el backlog.
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:
 
Estos son algunos ejemplos de posibles entradas de un backlog:
Línea 11: Línea 10:
 
* Permitir  la consulta de una obra a través de un API web.
 
* 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.
+
A  diferencia  de  un  documento  de  requisitos  del sistema,  la pila del producto 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.
+
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.
 
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.
 
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.
+
El backlog  evolucionará  de  forma continua mientras el producto esté en el mercado, para  darle  valor  de  forma  continua,  y mantenerlo útil y competitivo.
 
 
  
 
===Formato===
 
===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.
+
El desarrollo ágil prefiere la comunicación directa, antes  que  a  través  de  documentos.  El  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:
 
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.
+
* Identificador  único  de  la [historia de usuario]
* Descripción de la funcionalidad.
+
* Títilo de la [historia de usuario]
* Campo o sistema de priorización.
+
* Descripción de la [historia de usuario]
 +
* Importancia
 
* Estimación
 
* Estimación
 +
* Criterio de aceptación
 +
* Notas a considerar por el equipo de trabajo
  
Dependiendo del tipo de proyecto, funcionamiento del equipo  y  la organización, pueden  resultar aconsejables otros campos:
+
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.
  
* Observaciones
+
== Características de un backlog orientado al cliente ==
* Criterio de validación
 
  
[[Ejemplo De Product Backlog]]
+
* Tiene etapas o fases y cada una aporta valor al usuario del producto
 +
* Permite entender la complejidad de la funcionalidad
 +
* La funcionalidad revelante para el usuario y la funcionalidad compleja estàn al principio
 +
* Considera la cantidad de uso de cada funcionalidad para entender la importancia que representa una historia frente al resto
 +
* Permite entender la criticidad de determinada funcionalidad, es decir, que significa para el usuario no disponer de la funcionalidad en un momento dado
 +
* Permite saber si una funcionalidad puede suplirse con la combinación de otras
 +
* Da noción de volúmen de información que se manipula en cada funcionalidadentos más valorados por el usuario.
  
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.
+
== Pasos para priorizar el backlog del producto ==
 +
 
 +
# Plantear fases o etapas de entrega del producto al usuario: el cliente piensa que cuanto más aspectos cubra más rendimiento le sacará a su inversión y nosotros tenemos que trabajar con la info para proponer y negociar las etapas de entrega.
 +
# Estimar el costo del primer lanzamiento: cuanta más historias vitales tenga el proyecto, mayor coste terminarlo. Un buen contrapeso al tiempo total de desarrollo es poder determinar la fecha de implementación de la primera etapa productiva del producto.  
 +
# Poner un valor estratégico de cada historia: conocer los elementos más valorados por el usuario nos van a ayudar a priorizar el resto de las historias. Y habiendo negociado una primera etapa, para el resto de las etapas nos permitirán ubicarnos en un contexto más colaborativo.
 +
 
 +
== Ver también ==
  
==Ver también==
+
* [http://scrum.es/scrum/mejorar-una-pila-de-producto-backlog http://scrum.es/scrum/mejorar-una-pila-de-producto-backlog]
 +
* [http://www.agileslatinoamerica.com.ar/10/ http://www.agileslatinoamerica.com.ar/10/]
 +
* [[Historias de usuario]]
 
* [[Scrum]]
 
* [[Scrum]]
 
* [[Backlog Del Sprint]]
 
* [[Backlog Del Sprint]]

Revisión del 15:13 19 jul 2011

El backlog (o pila) 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 de usuario 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 aporte valor al usuario, en términos del producto final, 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, la pila del producto 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 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 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 [historia de usuario]
  • Títilo de la [historia de usuario]
  • Descripción de la [historia de usuario]
  • Importancia
  • Estimación
  • Criterio de aceptación
  • Notas a considerar por el equipo de trabajo

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.

Características de un backlog orientado al cliente

  • Tiene etapas o fases y cada una aporta valor al usuario del producto
  • Permite entender la complejidad de la funcionalidad
  • La funcionalidad revelante para el usuario y la funcionalidad compleja estàn al principio
  • Considera la cantidad de uso de cada funcionalidad para entender la importancia que representa una historia frente al resto
  • Permite entender la criticidad de determinada funcionalidad, es decir, que significa para el usuario no disponer de la funcionalidad en un momento dado
  • Permite saber si una funcionalidad puede suplirse con la combinación de otras
  • Da noción de volúmen de información que se manipula en cada funcionalidadentos más valorados por el usuario.

Pasos para priorizar el backlog del producto

  1. Plantear fases o etapas de entrega del producto al usuario: el cliente piensa que cuanto más aspectos cubra más rendimiento le sacará a su inversión y nosotros tenemos que trabajar con la info para proponer y negociar las etapas de entrega.
  2. Estimar el costo del primer lanzamiento: cuanta más historias vitales tenga el proyecto, mayor coste terminarlo. Un buen contrapeso al tiempo total de desarrollo es poder determinar la fecha de implementación de la primera etapa productiva del producto.
  3. Poner un valor estratégico de cada historia: conocer los elementos más valorados por el usuario nos van a ayudar a priorizar el resto de las historias. Y habiendo negociado una primera etapa, para el resto de las etapas nos permitirán ubicarnos en un contexto más colaborativo.

Ver también