Tengo un nuevo equipo de desarrollo y quiero usar Story Points para una estimación de alto nivel.
Pero tengo dos problemas:
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:
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.
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.
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.
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:
danny schoemann
jmort253
Serguéi Kudryavtsev
Serguéi Kudryavtsev