¿Cómo gestiona un Scrum Master & # 8220; & # 8221; un dueño de producto fuera de control? [cerrado]

Question

Soy nuevo en Scrum y, si bien entiendo el concepto de equipo detrás de los Sprints, imagino que todavía debe haber un tutor para el equipo que minimice la interferencia de los propietarios de productos que no están familiarizados con el desarrollo de software. ¿Cuáles son tus éxitos y qué historias de terror has vivido?

Actualización:

Estoy buscando el equilibrio entre la codificación para implementar el proceso comercial y la creación de la arquitectura adecuada para un cliente. Si el propietario del producto es de la unidad de negocio, debe haber orientación sobre la cantidad de tiempo que se debe dedicar al modelo de datos, etc.

Definición:

Por "fuera de control" propietario del producto, me refiero a alguien de la unidad de negocios que establece agresivamente marcos de tiempo sin tener una capacidad técnica real para crear esa estimación. Por lo general, esta persona dirá: "Necesito esas pantallas antes de la próxima reunión con el Comité Operativo la próxima semana, así que priorice primero esos productos de trabajo". Abordaremos la base de datos después de hablar con Operaciones. & Quot;

Grandes respuestas para todos. Gracias por el buen aporte.

Answer 1

" tiene que haber una guía sobre la cantidad de tiempo que se debe dedicar al modelo de datos, etc. "

Correcto. De eso se trata la priorización. Usted define el trabajo, prioriza. Trabajas de acuerdo con las prioridades.

¿Qué puede salir de control?

1. ¿Redefinir el trabajo antes de que se haga algo?

2. ¿Redefiniendo las prioridades antes de que se realice el trabajo?

La solución es la misma. Divide el trabajo en partes más pequeñas para que se haga algo antes de que haya una oportunidad de hacer un cambio.

Si tienes sprints cortos (2 semanas), no es posible estar fuera de control. Si optas por sprints un poco más prácticos de 4 semanas, entonces tienes una pequeña posibilidad de meterte en problemas.

Answer 2

Las responsabilidades están claramente definidas en Scrum: el propietario del producto define los elementos atrasados ??y los prioriza, los desarrolladores se comprometen a saber cuánto pueden hacer en un Sprint.

Entonces, el Propietario de un producto simplemente no tiene autoridad para establecer estimaciones. Por supuesto, todavía puede decir que necesita algo en un momento específico, eso simplemente sucede. Pero siguen siendo los desarrolladores quienes dirán si se puede hacer . Y si no puede, tienen que trabajar juntos sobre cómo cambiar el alcance o cualquier otra cosa que se pueda hacer para satisfacer las necesidades de la OP lo mejor posible.

Ahora, cómo exactamente debe actuar el SM en una situación donde esto no funciona sin problemas depende mucho de la situación específica. Sin embargo, prefiero verlo facilitar una buena relación y cultura de comunicación entre la OP y el equipo que tener que proteger al equipo de la OP.

Answer 3

Se supone que el propietario del producto es el que lo protege de los requisitos ambiguos o variables del cliente.

El propietario del producto no debe dar las estimaciones.

Answer 4

No creo que sea una cuestión de "fuera de control".

  

" Necesito esas pantallas antes de la próxima   reunión con el Comité Operativo   la próxima semana, así que prioriza esos trabajos   Productos primero. Abordaremos el   base de datos después de hablar con Operaciones. "

No hay nada intrínsecamente incorrecto con esa declaración por sí misma . Si su aplicación está correctamente abstraída, su base de datos está separada de todos modos. El principal problema con la interfaz de usuario primero es más psicológico: los no desarrolladores supondrán que la mayor parte del trabajo se realiza si ven pantallas y se vuelven locos cuando las cosas se ralentizan. Sin embargo, esto es lo que creo que su verdadero problema podría ser:

La persona que ha marcado como Propietario del producto no es propietaria del producto y, por lo tanto, no asume la responsabilidad suficiente.

El producto es lo completo , no solo los "requisitos funcionales" (para tomar prestada la terminología). Su SM debe sentarse y mantenerse firme en que la OP no debe intentar dejar de comprender el alcance del trabajo detrás de escena que debe lograrse. Una vez que su OP comienza a analizar todo el alcance, puede ser su representante ante la comunidad más amplia de partes interesadas.

Finalmente, su SM es el encargado de hacer cumplir el proceso. Deberían actuar así.

Answer 5

He usado Agile en dos tiendas diferentes, ambas veces funciona bien. No veo cómo algo fuera de control puede arruinar el sistema. Antes del sprint, planificas todas las tareas que harás y adivinas cuánto tiempo tomarán (siempre redondeando). Luego puedes calcular aproximadamente cuánto trabajo puedes hacer durante tu sprint.

La mayoría de las tiendas usan sprints de 4 semanas y 6.5 horas de tiempo de trabajo por día. Cuando se ha establecido un sprint, no se introducen nuevas tareas y solo el trabajo no planificado que se desliza en un sprint está corrigiendo errores en las funciones que está agregando, por supuesto, se supone que se incluirá en su tiempo estimado.

Si desea una respuesta más específica, debe definir qué quiere decir con "fuera de control" propietario del producto.

Answer 6

Tengo dos cosas que decir.

Probablemente tenga algún tipo de administrador de I + D (que no es necesariamente scrum master) y que no es propietario del producto).

Este tipo puede y debería (creo) "proteger" desarrolladores Estábamos en situación cuando teníamos a ese tipo, y funcionó bastante bien. Nos ayudó a obtener cosas no funcionales en la cartera de pedidos, por ejemplo.

Ahora no tenemos a este tipo. Nuestro gerente es scrum master. Y también hace un buen trabajo protegiéndonos. Aunque ... el problema aquí es que el scrum master genérico no tiene poder oficial, por lo que no puede decir "no los presionarás tanto", pero por supuesto que puede y debe hablar si ve que ese tipo necesita ayuda.

El equipo en sí y el propietario del producto también evolucionan con el tiempo para que empiecen a preocuparse más el uno por el otro. El propietario del producto comprende cuándo el equipo simplemente no se compromete a más o dice "necesitamos algo de tiempo para cosas no funcionales ahora".

Pero entonces, de nuevo, es bueno, por supuesto, si hay un gerente de I + D separado cuya responsabilidad principal es cuidar a los desarrolladores ... entonces creo que será más equilibrado ...

También tenemos un departamento de soporte que presta préstamos a los desarrolladores para tareas de soporte. A veces es difícil acordar qué se va a hacer o no para este o aquel cliente (porque el soporte lo quiere todo). Para este caso, administrador de I + D; una muy buena idea también ...

Idealmente, me gusta que la idea sea completamente ágil para que los desarrolladores no necesiten un administrador o escudo ... pero no sé si funciona y cómo funciona ... :)

Answer 7

Estoy de acuerdo con S. Lott. Los sprints cortos son mejores. Las historias cortas de los usuarios pueden ayudar. Intentamos limitar nuestras historias de usuario a 2 - 4 días como máximo.

1. Asegúrese de que todos sus usuarios las historias están bien definidas y eso El propietario está de acuerdo con ellos.

2. Una vez que ha comenzado un sprint, insiste     que no se pueden agregar nuevas tareas a     el sprint actual, pero pueden ser     alta prioridad en el próximo sprint.     Los sprints más cortos hacen esto mucho     más fácil.

3. Además, para eliminar el     imposición de plazos artificiales,     realmente no deberías entregar artículos     desde el sprint actual hasta el     comienzo del próximo sprint cuando     posible.

La parte más difícil del desarrollo ágil es la disciplina. Una vez que tienes un equipo disciplinado y un scrum master, los usuarios se acostumbran y las cosas se mueven mucho mejor. No estoy seguro de si utiliza algún software para la gestión de proyectos, pero eche un vistazo a Rally. Han realizado algunas mejoras importantes durante el año pasado más o menos.

Answer 8

El alcance de la iteración (Sprint en Scrum) no debe cambiarse durante la iteración. Es por eso que solo se planea una iteración a la vez. Como señaló S. Lott, cuanto más corta sea la iteración, antes podrá el Propietario del producto planear cosas nuevas.

El rol de Scrum Master es aislar al Equipo de tal presión y debe decirle al Propietario del Producto que las nuevas solicitudes deben esperar a la próxima iteración.

Ahora, el rol del propietario del producto es maximizar el valor del trabajo que produce el equipo, por lo que si hay un nuevo elemento de alta prioridad, que no puede esperar hasta el final de la iteración actual, aún es posible reemplazar los elementos con una estimación similar y que no se han iniciado . Esta debería ser la excepción, no la regla.

Answer 9

Siga las reglas de compromiso claramente definidas, entonces usted (SM) puede pasar el tiempo liderando a su equipo.

Answer 10

Un equipo ágil está formado por Desarrollador, Analista de negocios, Tester, DBA, Scrum master y Propietario del producto. Todos trabajan como un equipo basado en funciones .

La metodología ágil está aquí para ayudar a las empresas a acelerar el desarrollo más rápido del producto. El propietario del producto puede definir la prioridad y cambiar la prioridad de la misma. En realidad, es un equipo de Scrum, que lo estima incluyendo (PYME, Desarrollador, diseñador, probador ... Todos). Cada miembro del equipo aporta una perspectiva diferente sobre el producto y el trabajo requerido para entregar una historia de usuario y un sprint comprende con gran y pequeña historia de usuario. Si el equipo Scrum siente que no se puede hacer dentro del sprint, entonces debe ser una división en la pequeña parte de la historia del usuario y la estimación basada en el seguimiento de la pila involucrada para desarrollarlo.

es decir Si el Propietario del producto (PO) desea que la historia de usuario específica necesite terminar primero, pero si esa historia incluye los múltiples cambios (es decir, Frontend y backend, incluida la base de datos) y no puede completarse en un sprint, el equipo Scrum puede seguir las siguientes reglas clave:

Elementos clave :

• Divide en la historia del subusuario basada en el seguimiento de la pila
• Estime cada historia de usuario relacionada con esto
• Scrum master debe informar al propietario del producto sobre la línea de tiempo  para terminar esta historia de usuario basada en la velocidad actual del equipo
• El propietario del producto debe ser lo suficientemente maduro como para comprender la línea de tiempo a medida que  no se puede completar dentro del sprint.

• Si todavía PO tiene el problema de prioridad, Él / ella puede consultar el  Scrum Master / Coach.

  De un vistazo, Agile es más para ayudar a las empresas, pero debe cuidar que no sobrecargará al equipo scrum. Como es un proceso regular para desarrollo iterativo.