Creación de product backlog – Resultados del tercer encuentro ágil en Barcelona

 

En este encuentro se compartieron experiencias sobre los siguientes temas:
  • Principios de Lean Software Development, a modo de ayuda cuando Scrum no proporciona una solución directa a un problema.
  • Cómo gestionar historias de usuario que comparten implementación, haciendo énfasis en no perder el foco de que toda historia de usuario debería proporcionar algún valor al cliente.
  • Empezar por las historias de usuario más claras y que aportan más valor, y así en el futuro evitar modificar código de requisitos actuales dudosos.
  • La “generalización” del producto puede ser peligrosa para el negocio, no hay que olvidarse de obtener resultados a corto-medio plazo para el negocio
  • Cómo poner las pruebas de concepto en el product backlog, siempre sin perder de vista que el tiempo para estas pruebas debe estar acotado (timebox) y que debe poder medirse el progreso de la prueba.
  • El backlog como iceberg, en el cual los primeros objetivos son más pequeños, están más detallados, y los últimos son meros recordatorios de grandes objetivos a conseguir.
A continuación se detallan las ideas que se trataron respecto a estos temas.

 
Principios de Lean Software Development
La reunión comenzó haciendo una enumeración de los principios de Lean Software Development, de manera que sirviesen como ayuda por si se trataba algún problema para el que Scrum o XP no tuviesen una solución directa:
  • Respetar a las personas, por que el equipo es quien conoce cómo mejorar el proceso en que trabaja.
  • Eliminar los desperdicios que se producen en el proceso, todo aquello que no produce valor añadido en el producto.
  • Aplazar el compromiso, retardar las decisiones hasta que se disponga de toda la información o no se pueda esperar más.
  • Crear conocimiento, tener feedback regular con el cliente para alinearse con sus expectativas.
  • Hacer entregas rápidas, para permitir que el cliente pueda aprovechar antes los beneficios que le aporta el proyecto.
  • Desarrollar con calidad interna, de manera que el producto pueda ir creciendo con una velocidad sostenida.
  • Optimizar la totalidad del proceso, mejorar el proceso de creación del producto, desde la idea hasta su entrega.
Cómo gestionar historias de usuario que comparten implementación
En ocasiones hay historias de usuario que comparten una misma implementación. Lo más conveniente es formular toda historia de usuario de manera que aporte un valor al cliente (por ejemplo, cuantificable en dinero que el cliente podrá recuperar a partir de sus usuarios). No deberían existir historias de usuario de implementación del estilo “crear un motor de indexación”.
Dado que la primera historia de usuario siempre tendrá un esfuerzo mayor de implementación, puede ser conveniente hacer lo siguiente:
  • Explicar al cliente esta situación. De esta manera puede tomar una mejor decisión de qué historia de usuario le interesa que se implemente antes (puede llegar el caso de que el cliente vaya retardando la segundo historia de usuario y que al final ésta no se implemente nunca).
  • Ver qué orden de implementación de las dos historias de usuario es el que necesitará de un menor esfuerzo global.
Empezar por las historias de usuario más claras y que aportan más valor
Siguiendo el principio de Lean “aplazar el compromiso”, ante la duda de si en el futuro será necesario un requisito o una parte de arquitectura, lo mejor es sólo implementar lo que se necesite en el momento actual y utilizar técnicas como patrones de diseño para que en el futuro no cueste crecer encima (“Desarrollar con calidad interna”). Estas primeras necesidades deberían estar claras para el cliente, dado que deberían ser las que le aporten más valor en el momento actual.
Se consiguen varios beneficios de no implementar lo que no está claro (que sea necesario para el producto o cómo debe funcionar):
  • Se consiguen completar antes los requisitos que sí están claros (“Hacer entregas rápidas”).
  • Cuando llegue el momento de incorporar los requisitos que en su día fueron dudosos (y puesto que la idea original puede haber cambiado), las modificaciones/refactorizaciones a realizar pueden ser menores que si se tuviesen que hacer sobre un código implementado a partir de requisitos no claros. En un caso extremo, puede ser que el cliente no necesite nunca esos requisitos.
La “generalización” del producto puede ser peligrosa para el negocio
Si el cliente o el equipo dedica demasiado tiempo en generalizar el producto y las historias de usuario para que la solución cubra el máximo número de futuras posibilidades del producto (posibilidades que quizás acabarán cambiando o que nunca llegarán), se corre el peligro de desviarse de obtener resultados a corto-medio plazo para el negocio.
Cómo poner las pruebas de concepto en el product backlog
Es conveniente que todos los objetivos del proyecto aparezcan en el product backlog, incluidas las pruebas de concepto (spikes) que sean necesarias:
  • Si es posible, es mejor ser transparente con el cliente y que entienda el sentido y necesidad de realizar pruebas de concepto.
  • Es más sencillo utilizar una única herramienta (el product backlog) para tener la visión de todos los objetivos en que está trabajando la fuerza productiva (el equipo).
Las pruebas de concepto deben estar acotadas en el tiempo (tareas con timebox) para ayudar a tomar decisiones, especialmente si no se están consiguiendo resultados de las pruebas. Para ver si se va por buen camino, se pueden utilizar diferentes técnicas:
  • Hacer que el timebox sea pequeño (siempre menor que una iteración), pero suficiente para poder obtener un resultado y tomar una decisión. Si al final resulta insuficiente, se puede volver a utilizar otro timebox.
  • Definir la estrategia de la prueba de concepto, dividiéndola en tareas que al completarlas permitan saber si se está progresando.
  • Hacer varias pruebas de concepto para reducir riesgos. Por ejemplo, en el caso de una aplicación web, se pueden hacer públicas variantes de una misma funcionalidad (o diferentes funcionalidades) para diferentes usuarios, de manera que se obtenga feedack directo y real de su aceptación.
El backlog como iceberg
Se explicó la metáfora del backlog como iceberg:
  • En las primeras iteraciones, en que aparecen las historias de usuario más prioritarias, estas historias de usuario son más pequeñas y detalladas.
  • Conforme las entregas son más lejanas, los objetivos se redactan como grandes temas que actúan a modo de recordatorio (“épicas”).
Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona
Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, los snacks y las bebidas.

Artículos relacionados

 

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s