Tema 5.1 - Producto

Product Roadmap 

• La visualización de las características del producto 
• El mapa de productos equivale a la división de productos en su conjunto 
• Esto se hace y es propiedad del PO

El Producto 

Calidad:

• El Product Owner es responsable de retransmitir al equipo la expectativa de calidad.
• EI Development Team es responsable de cubrir esa expectativa. 
• EI Development Team debe involucrar la expectativa de calidad en Ia definición de “Done”.
• EI Product Owner es responsable de Ia calidad en los requerimientos. 

• Entender con claridad las expectativas, retos y uso del producto.
• Discutir los requerimientos con el equipo. 
• Hacer el Product Backlog del producto disponible y transparente. 
• Entender que la calidad no se logra solo con pruebas.
• La integración continua y automatización de pruebas son fundamentales para la entrega Ágil. 
• NO presionar el compromiso, confiar. 
• NO aceptar productos que no cumplan con la definición de “Done”. 
• Escuchar al equipo cuando identifica problemas técnicos que deben ser corregidos. 
• Si se identifican problemas serios técnicos apoyar la refactorización propuesta. 
• Entender Ia profundidad requerida de las pruebas. 

• Visión del Producto. 
• Definición del Producto. 
• Definiendo el Product Backlog. 
• Refinamiento. 

• ¿Quién va a comprar/usar el producto? 
• ¿Cuál es el propósito del producto? 
• ¿Cuáles son los atributos críticos? 
• ¿Cuál es el presupuesto? 
• ¿Cuál es el modelo del negocio?

El Producto Mínimo Viable

• El futuro es incierto. 
• Se deben seleccionar las mínimas características del producto que cumplan las necesidades del usuario. 

Nivel de Detalle

User Stories Foundations Certificate

En consulta con el cliente o propietario del producto, el equipo divide el trabajo a realizar en incrementos funcionales llamados "historias de usuario". Se espera que cada historia de usuario produzca, una vez implementada, una contribución al valor del producto en general, independientemente del orden de implementación; La fórmula de INVEST captura estos y otros supuestos sobre la naturaleza de las historias de los usuarios.

INVEST 

El acrónimo INVEST ayuda a recordar un conjunto de criterios o lista de verificación ampliamente aceptados para evaluar la calidad de una historia de usuario. Si la historia no cumple con uno de estos criterios, es posible que el equipo desee volver a redactarla o incluso considerar una reescritura (lo que a menudo se traduce en romper físicamente la tarjeta de la historia anterior y escribir una nueva). 

Una buena historia de usuario debería ser: 

• “I” ndependent / Independiente (de todas las demás) 
• “N” egotiable / Negociable (no es un contrato específico para funciones) 
• “V” aluable (o vertical) 
• “E” stimable (para una Buena aproximación) 
• “S” mall / Pequeña (como para que encaje dentro de una iteración) 
• “T” estable / Comprobable (en principio, incluso si aún no hay una prueba para ello)