Necesito saber sobre la planificación del desarrollo de productos en un escenario particular. Planifiqué mi sprint y lo ejecuté, y luego envié la URL del producto para recibir comentarios y recibí una respuesta de mi Product Owner. En este caso, ¿en qué sprint (sprint actual o próximo sprint) debo implementar la retroalimentación? ¿Cuál es el procedimiento normal para esto en el desarrollo ágil?
Creo que Aziz proporcionó un enfoque sólido.
En el escenario que describiste, parece que obtuviste retroalimentación de tu PO al final de tu sprint.
Si es así, entonces la respuesta es simple: no le queda tiempo en el sprint actual y tendrá que estimar y priorizar los comentarios para considerarlos en futuros sprints. Agile no requiere extender un solo sprint para trabajar en una función o retroalimentación.
Para ayudarlo a administrar mejor la amplia variedad de comentarios, es responsabilidad de uno tener definidos los criterios de aceptación del usuario (UAC) para las historias de usuario en un sprint.
Espero que esto ayude.
Los elementos de retroalimentación eventualmente se convierten en parte de la cartera de productos ya sea revisando o agregando nuevos elementos en la cartera de pedidos. Estos deben ser priorizados por el Product Owner antes de que el equipo los lleve a un Sprint/Iteration Backlog. Así que para responder a tu pregunta:
en qué sprint (sprint actual o siguiente) debo implementar las respuestas de retroalimentación
La retroalimentación se implementa en función de la prioridad establecida por el PO. Si PO quiere que se complete una característica/historia antes que los elementos de retroalimentación, entonces el equipo implementará la retroalimentación en un sprint futuro.
Es necesario estimar todos los elementos de retroalimentación agregados a la cartera de pedidos. Dependiendo de la estimación, el equipo puede llegar a la conclusión de que es posible que deba agregar uno o más sprints al plan del proyecto. Si este es el caso, debe comunicarse claramente a la OP lo antes posible porque eso ayudará a la OP a priorizar correctamente el trabajo pendiente.
Un circuito de retroalimentación efectivo y eficiente es muy importante durante el desarrollo ágil. Sin embargo, la gestión fuerte y potente de esta retroalimentación es igualmente crítica, de lo contrario tendremos una cartera de productos desorganizada e inmanejable en nuestras manos. No todos los elementos de retroalimentación deben ir al backlog. PO tiene una responsabilidad muy importante de analizar los comentarios y controlar lo que se acumula. Una de las herramientas que puede usar PO es la técnica de priorización de MoSCoW , donde cada elemento se puede categorizar (o desglosar más) de la siguiente manera según el objetivo del producto/proyecto:
Los artículos que no tendrán también deben documentarse y asignarse un estado de cerrado , para que no los perdamos de vista y podamos rastrearlos. Estos elementos pueden ser elementos de retroalimentación que no son relevantes para el producto o que no son rentables de implementar en este momento.
Algunas referencias sobre el uso de MoSCoW en ágil:
Sin embargo, esta es solo una de las herramientas disponibles. Hay otras técnicas de priorización que también se pueden emplear. El objetivo es una mejor priorización de la cartera de productos.
Te estás perdiendo algunas reuniones definidas que dejarían todo esto mucho más claro. Específicamente, parece que te estás saltando:
Los comentarios se pueden incorporar en cualquier punto del ciclo del Sprint, pero los comentarios que generan nuevos objetivos o historias de usuarios siempre se programan para futuros Sprints, a menos que el Product Owner invoque la Terminación anticipada del Sprint con un regreso inmediato a la Planificación del Sprint.
Si bien muchas historias de usuarios son marcadores de posición de conversación que facilitan la comunicación entre los miembros del equipo (y, a veces, las partes interesadas, otros equipos o usuarios finales), esto es bastante diferente de una revisión. Si está teniendo una conversación con su Product Owner sobre el trabajo en curso durante el Sprint, esto puede ayudar al equipo a hacer pequeñas correcciones para ayudar a mantener el Sprint Goal encaminado. Esta es una de las muchas razones por las que un Product Owner debe sentarse con el equipo y estar disponible para el equipo durante todo el Sprint.
Sin embargo, hacer pequeñas correcciones que no afecten el Sprint Goal o que cambien significativamente las historias de usuario aceptadas en el Sprint no es en absoluto de lo que estás hablando en tu publicación. Cuando tu dices:
Planifiqué mi sprint y lo ejecuté, y luego envié la URL del producto para recibir comentarios y recibí una respuesta de mi Product Owner.
está describiendo una situación en la que se completa la entrega de funciones para el Sprint y el equipo está demostrando las funciones para el propietario del producto y las partes interesadas. Esta es la Revisión del Sprint , donde el equipo compara los resultados del Sprint actual con el Objetivo del Sprint definido durante la sesión de Planificación del Sprint más reciente.
Esta es la oportunidad de la organización para revisar el progreso del proyecto, proporcionar comentarios sobre el proyecto o las funciones al equipo e identificar posibles historias de usuarios para que el propietario del producto las priorice en función del trabajo que acaba de completar. Esta es una de las reuniones definidas de inspección y adaptación que sustentan el marco Scrum, y omitirla o usarla de manera incorrecta es definitivamente un antipatrón de Scrum.
Sklivvz
Aziz jeque
Sklivvz
Aziz jeque
Sklivvz
Sklivvz
Aziz jeque