Las mejores unidades medibles para la estimación de equipos no interdisciplinarios

Tengo un nuevo equipo de desarrollo y quiero usar Story Points para una estimación de alto nivel.

Pero tengo dos problemas:

  1. Mi nuevo equipo no es multifuncional (estamos tratando de resolver esto, pero es un proceso lento).
  2. Las historias de usuario son muy específicas y exigen un conocimiento detallado.

Por lo tanto, durante el refinamiento de la cartera de productos, asumimos que, en la mayoría de los casos, un desarrollador concreto implementará una historia concreta. Obviamente, solo este desarrollador estimará su Historia (porque solo él tiene el conocimiento requerido).

Pero Story Point son unidades medibles para todo el equipo, no para una sola persona dentro del equipo. Si vamos a estimar Stories por un desarrollador concreto, un Story Point de un desarrollador no será lo mismo que un Story Point de otro desarrollador.

Entonces, la pregunta es:

  1. ¿Es una buena idea usar Story Points en mi situación?
  2. Si no, ¿qué unidades medibles es mejor usar? ¿Horas-hombre a la antigua/horas-hombre ideales o algo más?
(Pregunta, antes de agregar una respuesta :) ¿Puedes definir entregables para cada desarrollador y usarlos como hitos? (Y no olvide agregar integración). O pruebe el antiguo sistema EVS (Sistema de valor ganado). ¿O estoy malinterpretando tu pregunta?
¿Puedes dar un ejemplo de una historia de usuario? Antes de responder, me gustaría asegurarme de no asumir que sus historias son requisitos detallados y profundos y no "Como $tipo de usuario, quiero $hacer cosas para obtener $negocios". valor", que es lo que prescribe scrum. Después de todo, se supone que los puntos de la historia son de alto nivel, no estimaciones detalladas en profundidad.
@DannySchoemann, lamento la demora con mi respuesta. Descomponemos la historia de usuario en tareas técnicas y eso separa las tareas en subtareas (si es necesario). A pesar de que la mayoría de las Historias no suponen el trabajo paralelo de dos (o más) desarrolladores, las tareas bien separadas me ayudan a seguir bien el progreso. Por lo tanto, no hay problema con el seguimiento y control. El problema es que perdemos beneficios principales de los Story Points, como su unidad relativa y universal de la capacidad del equipo (con ayuda de la cual podemos entender si aumentamos la productividad del equipo, o no).
@ jmort253 Mis disculpas por la aclaración tardía. Sí, durante la estimación, nuestras Historias ya están bien refinadas y son "requisitos detallados y profundos". Pero esta no es la raíz de mi problema. La raíz del problema es que tenemos muchos sistemas técnicos y pocos desarrolladores. Entonces, hay muchos casos en los que solo un desarrollador tiene conocimiento sobre el sistema técnico y puede hacer una estimación sobre la cantidad de trabajo con él.

Respuestas (4)

La razón para usar puntos de historia es que nos permite calcular la capacidad del equipo.

La pregunta que debe hacerse es cuál es la mejor manera para que el equipo que describe desarrolle su capacidad.

Si fuerza los límites entre disciplinas, entonces realmente tiene varias capacidades y no solo una.

Por ejemplo, digamos que el equipo constaba de 5 desarrolladores. 2 desarrolladores solo pueden trabajar en historias relacionadas con la base de datos. 1 desarrollador solo puede trabajar en el front-end y otros 2 desarrolladores solo pueden trabajar en los servicios web.

En esta situación, el equipo tiene capacidad para trabajar con bases de datos, capacidad para desarrollar front-end y capacidad para servicios web. Eso es incluso antes de que comencemos a hablar sobre las pruebas. ¿Hay un solo probador que pueda trabajar en cada área? ¿Los desarrolladores hacen las pruebas?

Estimar en Scrum funciona mejor cuando asumimos que los miembros del equipo pueden trabajar en cualquier historia. Pueden ser mejores trabajando en algunos tipos de historias que en otras, pero aun así pueden trabajar en todo tipo de historias. Si un desarrollador no sabe cómo hacer algo, puede capacitarse o emparejarse con un desarrollador que sí sepa cómo hacerlo. De esa manera, el conocimiento se comparte en todo el equipo.

Le recomendaría que adopte este enfoque para compartir conocimientos y que haga que cada miembro del equipo calcule cada historia. Descubrirá que los desarrolladores estiman alto las historias con las que no están familiarizados y bajo las historias que entienden bien. Eso está bien, solo haga que el equipo llegue a una estimación de consenso que incorpore las aportaciones de todos los miembros del equipo. La forma en que se calcula la velocidad como un promedio móvil tiende a compensar este tipo de cosas con el tiempo.

Si el equipo no quiere volverse multifuncional, entonces es mejor estimar a nivel de tarea en lugar de a nivel de historia. Es posible que descubra que estimar en horas ideales es más útil que los puntos de la historia en este enfoque.

El equipo quiere convertirse en multifuncional, pero no tenemos suficientes recursos para ello en este momento. Demasiado trabajo, demasiado conocimiento para compartir y pocos desarrolladores. Espero que el progreso de compartir sea más rápido, cuando podamos contratar a más desarrolladores, pero llevará algo de tiempo. Creo que la separación de capacidad para diferentes campos es una idea interesante, pero un poco complicada. Me inclino a usar horas-hombre en lugar de Story Points, como sugirió en su último párrafo.
Recomendaría el libro "Agile Estimating and Planning" de Mike Cohn. Incluye un capítulo sobre la estimación en días ideales.

Los puntos de historia siempre son una buena idea, el desafío radica en encontrar una tarea que todos los miembros del equipo puedan entender y que luego pueda funcionar como un "punto de referencia".

Al estimar una historia basada en esta tarea de referencia, la persona que tiene un conocimiento profundo sobre el tema debe explicar lo mejor que pueda qué factores están involucrados en la historia a estimar para que los otros miembros del equipo puedan hacer una estimación razonable de cuán compleja es en comparación con la tarea de referencia.

Al principio, esto será difícil ya que el conocimiento entre dominios aún es limitado, pero a medida que el equipo continúe trabajando en conjunto, notará que las estimaciones aumentan rápidamente en precisión. Eso es suponiendo que tenga una reunión retrospectiva después de cada sprint donde el equipo se toma un tiempo para analizar qué salió bien y qué salió mal durante el sprint, parte de la cual comparará las estimaciones iniciales de las historias con el tiempo real que tomó para completarlos.

Me temo que siempre será la misma situación: el tipo que tiene suficiente conocimiento sobre el sistema hará una estimación, y todos los demás miembros del equipo simplemente estarán de acuerdo con él. Incluso si alguien no está de acuerdo con la estimación del tipo más conocido, no tendrá conocimiento con el que argumentar su posición.

Probablemente esta no sea su situación, pero este es un problema inherente con los equipos de desarrollo de juegos (mi área principal de experiencia), porque normalmente no hay superposición en los conjuntos de habilidades, y nunca lo será si el proyecto es más grande que un par de equipos de scrum. En estos casos, he usado estimaciones de puntos de historia separadas en cada departamento, pero tiene algunas desventajas. Uno, puede aumentar la cultura y la mentalidad de silo (malo), y dos, hace que la planificación de sprints y lanzamientos limpios sea mucho más parecido a un rompecabezas. A menudo necesito "llenar pequeños vacíos" con una superposición factible, como pruebas o seguimiento, para aprender cómo funcionan los otros departamentos, u objetivos personales/amplios. Un aspecto positivo es que muestra rápidamente dónde están desequilibradas las partes del plan de lanzamiento y/o es posible que necesite la capacidad de un experto.

Habiendo dicho eso (y antes de que me voten negativamente :)), recomendaría el consejo de Barnaby Golden, con énfasis en un plan concreto y tangible para entrenar cruzado y emparejarse con el objetivo de estimaciones compartidas de valor único.

Como le comenté a Barnaby Golden, separar diferentes tipos de Story Points es una idea interesante, pero complicada para nosotros. Y tienes razón en tus preocupaciones: la planificación será mucho más difícil.

Este es un error común. La gente piensa que un equipo multifuncional es aquel en el que cada persona posee todas las habilidades necesarias para completar el trabajo.

Un equipo multifuncional tiene miembros con una variedad de habilidades, pero eso no significa que cada miembro tenga todas las habilidades.

Mike Cohn dijo una vez:

Si mi equipo incluye al mejor desarrollador de bases de datos del mundo, quiero que esa persona haga cosas increíbles con nuestra base de datos. No necesito al mejor desarrollador de bases de datos del mundo para aprender JavaScript.

Mi equipo generalmente contiene 2 desarrolladores BE, 2 desarrolladores FE y 2 QA. Cada miembro del equipo está involucrado en el proceso de estimación. Hacemos scrum poker por completo. Todos participan y dan su opinión, y decidimos los puntos finales como equipo.

Lo único que debes tener en cuenta es:

  • si tiene una cantidad equilibrada de trabajo FE y BE, entonces podrá lograr más puntos de historia
  • Si el trabajo a realizar se inclina hacia una capa sobre otra, entonces podrá lograr menos puntos de la historia.
Las mejores unidades medibles para la estimación de equipos no interdisciplinarios
RespuestasAquíPolítica de privacidad1y, 0v