Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Producto. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Producto. Mostrar todas las entradas

domingo, junio 18, 2017

Sobre el Backlog de Producto, el Refinamiento del Producto y el Rol del Dueño de Producto

La Guía de Scrum define el Refinamiento del Backlog de Producto como:
“El refinamiento de la Lista de Producto es el acto de añadir detalle, estimaciones y orden a los elementos de la Lista de Producto. Se trata de un proceso continuo en el cual el Dueño de Producto y el Equipo de Desarrollo colaboran acerca de los detalles de los elementos de la Lista de Producto. Durante el refinamiento de la Lista de Producto, se examinan y revisan sus elementos. El Equipo Scrum decide cómo y cuándo se hace el refinamiento. Este usualmente consume no más del 10% de la capacidad del Equipo de Desarrollo. Sin embargo, los elementos de la Lista de Producto pueden actualizarse en cualquier momento por el Dueño de Producto o a criterio suyo”.
Pero ¿qué hay detrás de escena? ¿Cómo luce un buen refinamiento de producto? Hablemos un poco sobre eso.
Sobre el Producto
Primero, me gustaría decir algunas palabras sobre backlogs y cómo logramos que estos sean grandiosos:
Actualmente sabemos que
“La Lista de Producto es una lista ordenada de todo lo que podría ser necesario en el producto y es la única fuente de requisitos para cualquier cambio a realizarse en el producto. El Dueño de Producto es el responsable de la Lista de Producto, incluyendo su contenido, disponibilidad y ordenación”.
Aunque no es un concepto complicado, la noción de backlog de producto (o como se llama en español, la Lista de Producto), no siempre la entendemos completamente.
Roman Pichler y Mike Cohn dicen que un backlog de producto apropiado debería ser DEEP:
Detallado apropiadamente. Los elementos del backlog de producto difieren en su nivel de detalle. Los que se desarrollarán en los próximos sprints deben haber sido lo suficientemente entendidos hasta el punto de que puedan ser completados por el equipo en cada uno de esos sprints. De otro lado, aquellos elementos que no serán construidos durante un tiempo deberían describirse con menos detalles.
Emergente. El backlog de producto es una entidad viva que cambia constantemente y evoluciona a medida que el producto está siendo desarrollado o mantenido. A medida que el Dueño de Producto y el equipo aprenden más acerca del producto y de su entorno, por ejemplo, del mercado y de sus usuarios, adicionan nuevos elementos, eliminan otros y ajustan otros. Emergente es un atributo el cual no solo esperamos que este atributo esté presente en cada backlog, sino que es un indicativo de un backlog de producto sólido y efectivo.
Estimado. Cada elemento del backlog de producto tiene un estimado que corresponde al esfuerzo requerido para desarrollar ese elemento. El Dueño de Producto usa muchas veces este número, entre otras cualidades, para determinar la prioridad del elemento en el backlog de producto.
Priorizado. ¡Ni más faltaba! Todos los elementos el backlog de producto están priorizados (ordenados). Los elementos de mayor valor deben estar en la parte superior y los de menos valor en el fondo. El ordenamiento del backlog de producto determina el orden de entrega de sus elementos. Esta es una de las muchas formas en que un Dueño de Producto maximiza el esfuerzo del equipo y el valor entregado al negocio.
Por experiencia también sé que un buen backlog de producto es:
  • Transparente. Es visible a todos aquellos involucrados en el diseño y desarrollo del producto y a todos los interesados en el producto.
  • Relevante. Los nuevos cambios que se observan mientras se desarrolla el producto se reflejan en el backlog de producto, refinando sus elementos de manera adecuada.
Una vez que hemos entendido estas premisas, estamos preparados para jugar el juego del refinamiento del producto.
Sobre el Refinamiento
El refinamiento establece un entendimiento común entre el Dueño de Producto y los miembros del equipo acerca de los elementos priorizados y su funcionalidad y los desafíos técnicos. También crea más transparencia entre los miembros del equipo Scrum.
Aunque no hay una sola forma de definir el refinamiento del Backlog de Producto genéricamente en Scrum, - no hay ninguna fórmula que garantice el éxito cuando de afinar el backlog se trata – en la práctica hacemos refinamiento cuando enfrentamos:
  • Un backlog de producto muy grande
  • Un elemento de backlog grande
  • La adición de nuevos elementos al backlog de producto
También, cuando eliminamos elementos existentes del backlog de producto lo estamos refinando.
Cualquier elemento del backlog de producto debería refinarse cuando y a medida que conocemos información adicional sobre él.
Deberíamos dar prioridad al refinamiento de elementos del backlog de producto que se van a desarrollar en el siguiente Sprint.
El refinamiento del backlog de producto es o debería ser un proceso continuo conducido por el Dueño de Producto. Este se reúne con los interesados y usuarios para recolectar cualquier información necesaria para el refinamiento. Pero también planea y lleva a cabo reuniones con el equipo para que sus miembros conozcan los elementos nuevos/modificados en el backlog. El Dueño de Producto también debería conducir estas sesiones de refinamiento del backlog de producto.
Para saber más de Refinamiento del Producto puedes leer mi artículo sobre Purga Ágil del Producto.
Sobre el Dueño de Producto
Esta es la razón por la cual, solo a través de una buena sinergia entre el equipo y el dueño de producto, que ellos pueden construir un producto útil y fantástico. Un gran desafío para el dueño de producto es gestionar el flujo de los múltiples requisitos que llegan desde los distintos interesados y lograr que haya consenso entre todos (interesados, usuarios, equipo de desarrollo) sobre los requisitos que proporcionen el mayor valor al negocio.
El resultado de una sesión de refinamiento de producto es un entendimiento común de los elementos del backlog de producto que pueden desarrollarse en el siguiente sprint. ¡Por lo menos!
Un Dueño de Producto extraordinario sabe que si un producto debe ser competitivo en el mercado, entonces este debe cumplir con todos sus atributos requeridos que se hayan definido (las características imprescindibles), pero también con sus atributos de desempeño (las características importantes o que sería bueno que tuviera) y sus atributos interesantes (esas características que tienen valor para el negocio y que sería bueno que el producto tuviera).
Por cosas como esta es que ejercer el rol de Dueño de Producto eficientemente no solamente es vital para desarrollar productos fructíferos con Scrum. También es un proceso de aprendizaje para los individuos que ejecutan el rol y para la organización.
Desde este punto de vista, el rol del Dueño de Producto significa lograr un balance entre el tira y el afloje del desarrollo del producto. No es una tarea simple de llevar a cabo. Construir el producto correcto en el momento correcto es un asunto de mayor interés para el éxito de todo Dueño de Producto. Es lo que se conoce como el “Dilema del Dueño de Producto”.
Cuando un producto exhibe una historia bien construida que es coherente, se convierte en un producto no ordinario. Cuando las partes de este producto no ordinario interactúan, generan resonancia, una mejora de la potencia que hace que un producto sea más grande y más eficaz de lo que la suma de sus partes podría predecir. Esta resonancia incita a respuestas de sus usuarios. Por lo general, son reacciones que hacen que la gente experimente un producto como algo extraordinario, útil y valioso.
Scrum, junto con otro conjunto de prácticas y técnicas ágiles, nos proporciona el marco de trabajo necesario para construir tales productos de valor con las características correctas.
¡Y para eso es que están los Dueños de Producto!
Así que, ¿qué estás haciendo tú para crear esta sinergia y construir productos sorprendentes? Déjamelo saber en la sección de comentarios abajo.

Nota:
Publiqué este artículo en Pulse el 1 de junio de 2017, originalmente en inglés:
On Product Backlog, Backlog Refinement and the Product Owner Role
Para saber más sobre el rol del Dueño de Producto puedes leer mi artículo Guía Supernumeraria para un Dueño de Producto Virtuoso.

miércoles, junio 14, 2017

De las Reuniones de Requisitos - 1 -


Empiezas a construir una solución errónea y a nadie le importa...
¡Solicitas una reunión de requisitos y todo el mundo pierde la cabeza!

miércoles, marzo 29, 2017

Guía Supernumeraria para un Dueño de Producto Virtuoso


El Dueño de Producto es un nuevo rol para muchas, en realidad para la gran mayoría de las compañías. Y de estas, un gran conjunto no lo entiende o simplemente no ha tenido las mejores experiencias con sus responsabilidades. En términos generales, el Dueño de Producto es un ilustre olvidado.
Mientras que la promesa de un equipo de TI es diseñar y construir el mejor producto o servicio que el negocio necesita, una solución con Valor, dadas las restricciones de tiempo, presupuesto, tecnología, entre otras, la promesa de un Dueño de Producto es trabajar con el equipo en la priorización y negociación de características del producto, lograr no solo que el equipo de desarrollo aprenda del negocio sino de lo que significa Valor para el negocio.
La proposición de valor del Dueño de Producto también incluye mantener al equipo motivado y contribuir desde su posición a que se cumplan los compromisos con los usuarios o consumidores que él mismo representa. También, mientras la organización confía en la mentalidad Ágil del equipo y del Scrum Master para mantener la alineación con las áreas de TI, delega en el Dueño de Producto la responsabilidad de mejorar los tiempos de salida al mercado a la vez que optimizar el retorno de la inversión.
El Dueño de Producto es precisamente el dueño de la visión del producto, el plan del negocio, las ganancias, el plan de entregas y de un backlog de producto cuidadosamente refinado y priorizado con precisión para que el equipo pueda trabajar sin tropiezos. Mientras el trabajo del equipo es construir correctamente el producto, el Dueño de Producto debe entregar el producto correcto. ¡Es un juego de palabras, pero es verdad!
El Dueño de Producto es o será el encargado de devolver el encanto que muchos usuarios, socios y empleados perdieron en el pasado a raíz de las soluciones de TI disfuncionales que estábamos produciendo. Eran soluciones con muy poco o ningún sentido de la calidad, tardaban años en llegar al mercado y carecían de la innovación necesaria para resolver problemas reales del negocio. Las cosas así, la responsabilidad moral de un Dueño de Producto es una carga pesada que todos en la Organización tenemos obligación de ayudar a soportar mediante el apoyo incondicional a su trabajo.
Scrum en particular y el enfoque Ágil en general proporcionan las herramientas suficientes para que el Dueño de Producto cumpla con sus responsabilidades de manera decidida y franca, para conectar efectivamente los deseos y necesidades de los usuarios y el negocio con el equipo de desarrollo, de forma dinámica y receptiva.
En su libro “Agile Product Management with Scrum”, Roman Pichler describe ampliamente las principales actividades que un Dueño de Producto de talante realiza:
Definir y manejar la Visión del Producto

Una visión efectiva del producto responde o debería responder a las siguientes cuestiones:
  • ¿Quién comprará o usará el producto? ¿Quién es el consumidor o usuario final?
  • ¿Qué necesidades cubrirá el producto? ¿Qué valor agrega el producto al usuario o a la organización?
  • ¿Cuáles son los atributos críticos del producto para que este sea exitoso?
  • ¿Cómo y qué tantas ganancias tendrá la compañía con el producto?
Entre otras no menos importantes. En resumen, la visión debería comunicar la esencia del futuro producto de una manera concisa y describir un objetivo compartido que conduzca la creación del producto pero que sea lo suficientemente amplio como para facilitar la creatividad del equipo que lo desarrollará.
Un aspecto importante a considerar aquí es el conocido como el Mínimo Producto Viable (MVP) o, a veces, el Mínimo Producto Mercadeable. Este es un producto con la mínima funcionalidad que cubra algunas de las necesidades básicas de los usuarios y genere valor a la organización. Un Dueño de Producto hábil sabe que el producto debe estar en funcionamiento muy pronto y que este debe entregarse en pequeños incrementos en cortos lapsos de tiempo. Esto reduce la incertidumbre y aumenta el aprendizaje no solo sobre el producto sino sobre los hábitos de consumo de sus usuarios finales.
Para saber más sobre cómo crear la Visión del Producto, pueden ver este Webinar sobre Inception Ágil que facilité con mi gran amigo Jorge Abad:
Es prácticamente imposible, por no decir menos, establecer una visión del producto apropiada sin tener en cuenta el factor humano. En otras palabras, definir una correcta visión del producto es un acto puramente humano.
Trabajar con el backlog de Producto

Este artefacto hermosamente simple sufre muchas veces de la falta de atención apropiada tanto por parte del Dueño de Producto como del mismo equipo de desarrollo.
Para quienes no están familiarizados con la herramienta, es una lista priorizada de los elementos necesarios para darle vida al producto. Estos elementos incluyen la exploración de las necesidades de los usuarios, pero también puede incluir una descripción de opciones técnicas y de requisitos funcionales y no funcionales, así como el trabajo necesario para poner a punto los distintos ambientes de trabajo.
Uno de los aspectos más importantes que debe estar en el radar del Dueño de Producto es este del Valor de cada uno de los elementos del backlog. El valor es un factor común de priorización de sus elementos. El Dueño de Producto sabe que debe entregar primero los elementos de mayor valor. Al agregar nuevos elementos, el Dueño de Producto no solo revisa o establece el valor de estos nuevos elementos sino que reexamina el valor de los existentes.
También hemos aprendido que un Dueño de Producto experimentado va adelante del equipo en cuanto al conocimiento detallado que tiene de los elementos del producto. Quizás uno o dos sprints más allá del actual y está continuamente practicando refinamiento al producto.
Para profundizar más en estos asuntos pueden leer mis artículos:
Sobre gestión del producto en general, en el que abordo cuáles son los atributos (DEEP) de un buen backlog de producto:
Sobre refinamiento del producto en particular:
Planear las entregas

En su libro Agile Estimating and Planning, el gran Mike Cohn escribió que “Planificar... es una búsqueda de valor”. Otra vez emerge el Valor como factor determinante a la hora de planear las entregas de un producto. También hemos aprendido que este plan de entregas no puede ir encadenado a las aristas de tiempo, costo y alcance de manera fija e inquebrantable. Es posible adherirse a una de ellas, quizás a dos, pero no a las tres en simultáneo.
Otra vez: la meta principal de todo Dueño de Producto es entregar el producto correcto. De allí que la planificación de esta entrega de producto, en pequeñas entregas incrementales es una tarea fundamental de todo Dueño de Producto hábil. Sobre este asunto en particular pueden leer mi artículo:
En donde agrego el atributo de Valor a las ya ampliamente difundidas bases de Ágil y propongo El Nuevo Nuevo Enfoque Iterativo e Incremental y de Valor.
Colaborar con las Reuniones del Sprint

¡Scrum!

Las reuniones son oportunidades de Conversación cara a cara y, en el caso específico de Scrum, son momentos propicios para la inspección y adaptación, pilares fundamentales de la mentalidad Ágil. Y el Dueño de Producto hace parte del equipo Scrum, así que bienvenido su aporte estratégico y táctico al equipo durante estas conversaciones.
Para saber más sobre los distintos eventos en Scrum pueden ir a mi Gazafatonario:

En conclusión, el Dueño de Producto es uno de los ejes fundamentales sobre los cuales avanzan los equipos Scrum como un todo hacia la búsqueda de un objetivo común: la generación de valor a la vez que responder al cambio de manera eficiente. En particular, el Dueño de Producto se constituye en una arista esencial para la correcta gestión ágil del producto pero sobre todo para entregar productos cuyos componentes generen resonancia entre ellos e impacten el modus vivendi de sus consumidores, nosotros la humanidad.

Puedes descargar la presentación complementaria del siguiente enlace:

domingo, junio 26, 2016

¡El tamaño sí importa!


Vamos al grano. Si la mayoría de tus historias de usuario llegan a “Terminado” apenas unas pocas horas antes de la Revisión del Sprint, todavía pueden ser más pequeñas. Tu equipo debería tener historias tan pequeñas que las puedas finalizar durante las primeras horas o días del Sprint, dependiendo de la duración de este. Así te aseguras desde las primeras de cambio que el equipo está siendo productivo, está enfocado y que van a entregar valor al final de la iteración. ¡Después de todo, finalizar una tarea aumenta la moral del equipo!
Aunque el objetivo de un Sprint no debe medirse en número de historias de usuario a terminar (implementar), sino al cumplimiento de un objetivo específico, siempre es mejor “prometer” o planear terminar varias historias pequeñas o muy pequeñas que muy pocas historias medianas o grandes.
Es evidente: si tienes 10 historias en tu lista de pendientes del sprint (alias el backlog del sprint), y no terminas 2, es mucho mejor que si solo tienes 4 y terminas 2. En ambos casos fallaste en el mismo número de historias, pero en el primer escenario tuviste un acierto del 80% mientras que en el segundo apenas llegaste a la mitad de la promesa del sprint. El resultado es menos alentador si las historias terminadas son dos de 3 puntos y dejaste sin terminar o aun a punto de terminar dos historias de 13. Solo cumpliste con 6 de los treinta puntos que prometiste.
Hablando de puntos, una buena medida, algo que me ha funcionado casi siempre, es implementar historias cuyo puntaje no sobrepase entre una décima parte y una sexta parte de la velocidad del equipo. Es decir, si la velocidad del equipo de desarrollo es 30 puntos por Sprint, las historias a implementar no deberían ser más grandes de 3 a 5 puntos. Historias de ½, 1 y 2 puntos siempre son bienvenidas en este escenario.
Ahora bien, el tamaño de las historias es un concepto relativo. Un equipo de 7 o 9 personas no ve igual una historia de usuario en un sprint de 3 o 4 semanas que un equipo de 3 o 5 personas en un sprint de 1 o 2 semanas. Pero algo en lo que todos estamos de acuerdo es que, una vez terminadas, las historias deben proporcionar valor al negocio. Las cosas así, otro indicador de “pequeño” es Pareto.
El objetivo siempre es encontrar ese 20% de la historia (de funcionalidades que se van implementar vía esa historia) que genere o entregue el 80% del valor total de la misma. A partir de allí, la división se hace de manera orgánica, adicionando historias al backlog de producto que complementen la historia de “más valor”.
También ayuda el nivel de entendimiento de toda la historia y qué tan rápido llegamos a entenderla por completo. Un índice de que quizás la historia no es pequeña es que no la hemos terminado de entender, quizás no están claros algunos de los criterios de aceptación o hay nubes en la conversación (la c de conversación de la historia) relacionadas con los requisitos funcionales o no funcionales a implementar.
El Principio de Sweepnoise, de mi amigo Leonardo Agudelo, ilustra muy bien este punto:


Finalmente, no solo la S de INVEST indica que la historia es pequeña (Sucinta). Un indicativo de que quizás no lo es tanto, es que  algunas partes de la misma (o toda la historia) no sean negociables o que no haya consenso en su estimación o que tengamos dudas acerca de si es posible conducirla a través de un proceso que nos asegure la calidad del producto terminado o de que incluso tenga dependencias con otra(s) historia(s).

Comparte conmigo y con los demás lectores del blog lo que piensas sobre este asunto del tamaño, ¿importa? ¿No importa? ¿Qué haces habitualmente para dividir tus historias de usuario? Cuéntanos tus heurísticas.
---------------------------------------------------------------------------------------------------------------
Para saber más sobre historias de usuario, puedes leer mi artículo introductorio:
Historias de Usuario: un nuevo orden en los requisitos del software:
http://www.gazafatonarioit.com/2013/07/historias-de-usuario-un-nuevo-orden-en.html

Para saber más de los criterios INVEST de las historias de usuario puedes leer mi serie de artículos sobre el asunto.
La serie de artículos "Escribiendo Historias de Usuario Altamente Efectivas":
Escribiendo Historias de Usuario Altamente Efectivas, 1 - Introducción
Escribiendo Historias de Usuario Altamente Efectivas, 2 - Independiente
Escribiendo Historias de Usuario Altamente Efectivas, 3 - Negociable
Escribiendo Historias de Usuario Altamente Efectivas, 4 - Valiosa (y Valuada)

Y este otro:

De historias de usuario, culturas y del arte de narrar historias


También puedes visitar el blog Lecciones Aprendidas de mi amigo Jorge Abad:
Video de explicación: Cómo se construyen historias de usuario
Ejemplo: Una historia de usuario - Listado de Morosos
Ejemplo de historia de usuario : Ingreso al sistema
http://www.lecciones-aprendidas.info/2015/03/ejemplo-de-historias-de-usuario-ingreso.html