Planning Poker y desarrolladores de Wordy [cerrado]

10

Mi equipo está compuesto por 4 desarrolladores; Todo sazonado y experto. Uno de ellos es un tipo prolífico y bien intencionado que insiste en definir la solución técnica a nuestras historias antes de presentar nuestras estimaciones con Planning Poker. Se niega a estimar si no tiene una idea aproximada de la solución técnica acordada (que suena razonable, ¿verdad?).

¡El problema es que nuestras sesiones de estimación tardan una eternidad en terminar! En tu experiencia, ¿cómo lidias con este tipo de personalidad cuando juegas al poker de planificación?

agile planning

— Pomario
fuente

13

Parece que le gusta que las cosas se definan formalmente, por lo que un temporizador sería una buena idea, ya que la planificación del póker se define como tener una cantidad fija de tiempo para que la gente hable.

También tiene una idea equivocada sobre la estimación, todos estiman en contra de la historia y no de la implementación , por lo que obtienes tanta variación. Por ejemplo, algunas personas pueden ignorar un marco o una solución estándar y comenzar a escribir cosas desde cero.

— StuperUser
fuente

1

Un temporizador es una gran idea. Les recuerda a los oradores que sean concisos y los obliga a destilar lo que están tratando de decir hasta el punto más básico.

— Shane Wealti

También ayuda si el trabajo preliminar sobre las historias se lleva a cabo temprano, entonces los preliminares de diseño técnico se pueden hacer "fuera de línea" desde la reunión misma. El póker no es el lugar para encontrar soluciones, está perdiendo el tiempo de todo un departamento. Otra idea sería agregar "diseñar estas cosas" como una historia que compila una caja de tiempo temprana de "implementar estas cosas". La siguiente ronda obtiene estimaciones reales para la implementación.

— Patrick Hughes

2

Un temporizador no solo es una buena idea, creo que es recomendable (tal vez alguien con Agile Planning and Estimation pueda confirmarlo). Tengo entendido que, como la mayoría de las actividades, la planificación de las sesiones de póker debe tener un calendario para evitar situaciones como a qué se refiere la pregunta.

— Thomas Owens

1

For example some people may be ignorant of a framework or off the shelf solution and start writing things from scratch- De ahí la discusión. Entonces todos lo saben y las estimaciones son mejores.

— Izkata

3

Tu miembro del equipo suena como una personalidad de analista. Los analistas necesitan mucha información para tomar una decisión. La idea del temporizador es la mejor, pero tenga en cuenta que va a advertir todo lo que da. Trabaje con él para explicarle que es solo una estimación temprana basada en el problema, NO la solución. Si quiere hacer preguntas, pídale que lo mantenga al problema, no a la solución. Es posible que tengas que cortarlo o molestarlo por un tiempo cuando siga buscando soluciones.

Asegúrate de mantener a los demás miembros del equipo con estas mismas reglas para que no se sienta singular. Los analistas son una personalidad común en la programación, por lo que es muy posible que te encuentres con otros como él.

— Bill Leeper
fuente

2

+1, soy una personalidad analista y lucho con este problema. Noto que soy mucho más completo y completo y tengo menos errores que mis compañeros, pero me estreso fácilmente y soy ineficaz en situaciones con información menos que perfecta. Me esfuerzo todos los días para tratar de lidiar con lo desconocido de una manera menos estresante.

— maple_shaft

2

Parece que su colega no entiende la diferencia entre estimación y compromiso o no se le ha comunicado durante el entrenamiento. Y, dado que trataste de vincular el problema a su personalidad, es posible que todo tu equipo aún no lo entienda. (¡Pero no se preocupe! La mayoría de nuestra industria no lo entiende. ¡Ágil es difícil!)

Cuando decimos que el tamaño de una historia es X puntos, en realidad queremos decir una distribución de probabilidad. Si nuestras estimaciones son correctas, la historia debería llevar más tiempo el 50% del tiempo (y el otro 50% llevará menos tiempo). Si su colega cree que, cuando hayan transcurrido X unidades de tiempo, se le pedirá que demuestre la historia o, de lo contrario, eso cambiará su enfoque de estimación.

La planificación del póker introduce otro error: en lugar de tratar de precisar X, lo hacemos coincidir con una escala discreta, siendo la escala de Fibonacci (1, 2, 3, 5, 8, etc.) la más popular. Está diciendo que el tamaño no es tanto como lo que es. Cuando decimos que el tamaño de la historia es de 3 puntos, realmente decimos "es X más menos alguna variación y X está más cerca de 3 que de 2 o 5".

Su equipo podría beneficiarse al comprender cuán impreciso es este ejercicio y cómo la estimación difiere del compromiso. Si quiere / necesita estudiar estos conceptos en profundidad, este libro lo tiene.

— azheglov
fuente

Cuando planifique si cree que una historia lleva 3 días y una hora, debe usar los 5 días, no redondearla . Depende del desarrollador mantener su disciplina y hacer la estimación contra la tarea, no hacer que el plan de la tarea se ajuste a la estimación.

— StuperUser

10

"Parece que su colega no comprende la diferencia entre la estimación y el compromiso" Puedo relacionarme completamente con esto ya que muchos gerentes SIEMPRE tomarán sus estimaciones iniciales y las convertirán en compromisos . Algunos de nosotros, como yo, estamos muy nerviosos por dar una estimación aproximada porque los gerentes nos han retenido con ellos y luego esperaban que trabajáramos los fines de semana largos sin dormir para hacerlo antes de la fecha límite del sprint.

— maple_shaft

1

@maple_shaft: tiene toda la razón, la estimación / compromiso es uno de los conceptos erróneos más grandes de nuestra industria y este concepto erróneo es uno de sus mayores impedimentos. Su "nerviosismo", "fines de semana largos", "no dormir", etc. están entre sus consecuencias. Puede resolver este problema solo si incluye a todos, a todo su equipo, a su gerente, etc. Es por eso que la transición ágil es tan difícil. Recoger un mazo de cartas sin comprender estos conceptos es fácil.

— azheglov

1

@azheglov, a veces la transición ágil es difícil porque la gerencia piensa que quieren a Agile cuando en realidad son micro megalómanos con un complejo complejo de inferioridad y un fuerte deseo de NUNCA ajustar los horarios de sprint cuando cambian los requisitos o se descubre nueva información. En otras palabras, realmente no quieren a Agile porque el verdadero Agile es fundamentalmente contradictorio con todo lo que saben.

— maple_shaft

@maple_shaft, ¡también tienes razón! No voy a entrar en todas las razones por las que agile es difícil en mi comentario ;-)

— azheglov

1

Puedo ver de dónde viene el miembro de tu equipo, pero claramente no ha comprendido completamente el concepto de Agile and Planning Poker. Debe comenzar asegurándose de que todos entiendan los conceptos y el razonamiento detrás de ellos, y luego deben hacerlo bien por su cuenta.

— AJC
fuente

1

Para los equipos con los que trabajo, al comienzo de cada sesión de planificación puse un reloj de arena de 3 minutos en la mesa. Dejo que todo el equipo sepa que si en algún momento sienten que la conversación se está convirtiendo en una inmersión profunda, o irrelevante, o de alguna otra manera va más allá de lo que sienten que es necesario para estimar la historia en los puntos de la historia, entonces cualquiera en el equipo puede voltear el temporizador. Una vez que se acaba la arena, el equipo calcula de inmediato.

Este método permite a cada individuo en el equipo limitar la conversación, cuando sienten que la conversación ya no es útil para estimar la historia que se está discutiendo. Al mismo tiempo, no interrumpe inmediatamente la conversación, pero les da a todos una indicación visual de que su conversación debe concluir en los próximos minutos, porque luego vamos a votar.

Otra herramienta que utilizo para ayudar a mantener enfocadas las sesiones de planificación es asegurarme de que todos en el equipo hayan revisado las historias en la parte superior de la cartera de pedidos al menos un par de días antes de la planificación. La idea es que si tiene una lista de preguntas inmediatamente después de leer las historias, puede informar al propietario del producto sobre las posibles preguntas varios días antes, para que puedan aclarar la historia o la crítica de aceptación para limitar la discusión posterior. Esto también permite a las personas comenzar a pensar en el diseño potencial de la historia, antes de estar en la planificación (y tratar de diseñar durante la planificación).

— Shawn S
fuente