Como líder técnico dentro de un equipo "Scrum", estoy molesto con algunas reglas establecidas.
Se establece que solo Product Owner, Business Analyst y Scrum Master (y eventualmente Product Manager) forman parte del proceso de priorización de historias de usuario (backlog prioritization).
Están clasificando a los EE. UU. en función de los puntos de la historia, sin más hechos y conocimientos orientados al software.
Vale la pena señalar que esos puntos de la historia surgieron de un proceso de macroestimación rápido y probablemente "ciego", no de uno profundo.
Juzgan qué valiosos EE. UU. podrían entregarse y cuándo a través de esas macroestimaciones.
Me doy cuenta de que su decisión a menudo se basa en supuestos erróneos e hipótesis falsas; lo que lleva a un reajuste de clasificación, por lo tanto, perdiendo el tiempo de nadie.
¿Considera que un Tech Lead (o cualquier otro desarrollador calificado) debería ser parte de este proceso de priorización para ayudar a priorizar según el conocimiento de programación?
Como garante de viabilidad.
La Guía Scrum es muy clara en estos aspectos :
El refinamiento de la cartera de productos es el acto de agregar detalles, estimaciones y pedidos a los elementos de la cartera de productos. Este es un proceso continuo en el que el propietario del producto y el equipo de desarrollo colaboran en los detalles de los elementos de la cartera de productos.
La gestión de la cartera de productos incluye... Ordenar los elementos de la cartera de productos para alcanzar mejor los objetivos y misiones; ...aquellos que deseen cambiar la prioridad de un elemento de la Lista de Producto deben dirigirse al Propietario del Producto.
El Equipo de Desarrollo es responsable de todas las estimaciones. El propietario del producto puede influir en el equipo de desarrollo ayudándolo a comprender y seleccionar compensaciones, pero las personas que realizarán el trabajo harán la estimación final.
Sin embargo, la Guía Scrum no dice nada sobre la deuda técnica. No se menciona la deuda técnica ni nada remotamente parecido en la Guía Scrum. Cuando el equipo de desarrollo siente firmemente que se debe priorizar una deuda técnica, de lo contrario, habrá problemas mayores en el futuro ("Una puntada a tiempo ahorra nueve"), son impotentes para priorizar eso. Si el PO se niega a prestar suficiente atención a las opiniones del equipo de desarrollo sobre este aspecto, aconsejo a mis equipos de desarrollo que incluyan la deuda técnica en su estimación de las funciones relacionadas.
Entonces la respuesta a tu pregunta:
¿Considera que un Tech Lead (o cualquier otro desarrollador calificado) debería ser parte de este proceso de priorización...
es SÍ , tiene derecho a participar. La Guía Scrum lo dice.
Parece que hay muchas cosas que van mal con su proceso de Scrum.
Es importante darse cuenta de que no se prioriza una acumulación de productos. esta ordenado No hay ninguna referencia a un Product Backlog priorizado u ordenado por prioridad en ninguna parte de la Guía Scrum. En la sección de la Guía de Scrum sobre un Product Owner, se da a entender que los elementos individuales de la lista de pedidos del producto tienen prioridad. Sin embargo, los atributos necesarios de un elemento de la cartera de productos son una descripción, un pedido, una estimación y un valor.
El Product Owner es la persona responsable de gestionar el Product Backlog. Dos de las actividades de gestión de la cartera de productos son "ordenar los elementos de la cartera de productos para alcanzar mejor los objetivos y misiones" y "optimizar el valor del trabajo que realiza el equipo de desarrollo". Simplemente ordenar el trabajo en función de la prioridad para alguien no es probable que coloque los elementos en el orden que pueda realizar estas dos actividades.
El acto de refinar (o arreglar) el Product Backlog es una colaboración entre el Product Owner y el Development Team. Este es un momento para que el propietario del producto explique las intenciones detrás de los elementos de la cartera de productos al equipo de desarrollo y los revise y revise. Esta también es una buena oportunidad para que el equipo de desarrollo resalte las dependencias técnicas entre los elementos de la cartera de productos. Las discusiones durante las actividades de refinamiento deben informar al propietario del producto para poder tomar mejores decisiones al ordenar el backlog.
Según la descripción del proceso, también tengo otras preocupaciones.
Parece que se mencionan tres roles relacionados con el producto: Propietario del producto, Analista comercial y Gerente de producto. Es importante que haya un propietario del producto para la cartera de productos. Está bien que esta persona tenga un equipo que la respalde. En un entorno escalado con varios equipos que trabajan en un solo Product Backlog, es posible que también desee integrar a alguien en cada equipo. Pero pase lo que pase, hay una persona con el rol de Product Owner como se describe en Scrum.
El Scrum Master también parece estar muy involucrado en el trabajo. El Scrum Master es un entrenador. No dice cuál es su papel en la gestión del Product Backlog, pero que permiten que el Product Backlog se ordene sin la participación del equipo de desarrollo, no están estableciendo ni enseñando un buen refinamiento o actividades de preparación que incluyan todo. equipo, y no están enseñando al propietario del producto sobre la optimización del valor y el logro de objetivos es problemático.
También existen obstáculos potenciales relacionados con tener una posición de liderazgo en un Equipo Scrum, pero estos generalmente se pueden superar manteniendo a todo el equipo involucrado en el momento adecuado y pueden ser valiosos para el éxito a largo plazo de un equipo.
Las dos respuestas anteriores de Thomas y Ashok dan en el clavo (+1!) y solo quería arrojar una perspectiva ligeramente diferente no a la respuesta en sí, sino a la pregunta.
¿Debería una persona técnica formar parte del proceso de priorización de historias de usuario?
Se establece que solo Product Owner, Business Analyst y Scrum Master (y eventualmente Product Manager) forman parte del proceso de priorización de historias de usuario (backlog prioritization).
A veces, la gente tiende a apegarse a metodologías, pautas, reglas... y cuando sucede, sugiero dar un paso atrás y volver a preguntar por qué existen las metodologías . Bueno... no son la meta , son el camino hacia una meta determinada .
Ahora, pensando en los objetivos, ¿cuál es el objetivo de la priorización del trabajo pendiente ? Entregar el mayor valor posible, optimizando el tiempo y la capacidad. Eso es (potencialmente) aplicable si el equipo es un Scrum, un "Scrum", un Agile, un "Fragile" o un equipo completamente caótico... todos quieren cumplir.
Con eso en mente, ¿se puede justificar que la presencia de un personal técnico podría ayudar a lograr el objetivo ? Si su respuesta es "sí", no necesitará justificar que un técnico debe asistir "porque Scrum lo dice". Dependiendo del entorno en el que trabajes, puede haber más o menos resistencia a jergas como Scrum, pero dudo que nadie esté en contra de una propuesta que pueda agregar valor al equipo.
Mik378
Tomas Owens
Tomas Owens