Cómo estimar un punto de la historia, que involucra al equipo móvil y al equipo de back-end

Estoy administrando un producto de aplicación móvil. contiene el equipo de back-end, el equipo de diseño y el equipo de flutter (móvil). Las historias de usuario generalmente consisten en subtareas, que involucran tanto al equipo de back-end, diseño y móvil.

Mis preguntas son,

  • ¿Cómo estimar tal historia, ya que la estimación del equipo móvil es mucho más alta que la del equipo de diseño y es completamente diferente por parte del equipo de desarrollo? ¿Qué estimación se tendrá en cuenta?
  • ¿Estas subtareas deberían ser realmente subtareas en la historia de Jira, o deberían ser solo tareas vinculadas a la historia como su padre? la razón de esta pregunta es que, cuando son subtareas, no podemos considerarlas por separado como hechas, porque estimamos la historia en sí, y no las subtareas, entonces suceden muchos problemas, como: no puedo saber cuánto puntos que tiene cada desarrollador, 2- Si el sprint finaliza antes de que terminemos una historia completa, sus puntos de historia no se cuentan en el informe, incluso si se completó en un 90%, y luego los gráficos de velocidad y quemado no reflejan el esfuerzo real que el equipo puede hacer dentro de un sprint.

Realmente agradecería algunos consejos prácticos de cómo manejar una situación así.

Respuestas (3)

Al evaluar las historias de los usuarios, todos deben considerar el esfuerzo total requerido por el equipo para terminar la narración. Como resultado, el desarrollador de back-end no solo debe estimar el tiempo que le llevará completar su parte, sino también el tiempo que le llevará completar el front-end, el diseño móvil y todas las pruebas (y similares para los otros miembros del equipo). El beneficio de utilizar puntos de la historia en esta situación es que los valores son relativos al esfuerzo estimado previamente, y la mayoría de las personas pueden estimar si algo es menos/más/mucho más trabajo que una narración de referencia, incluso si carecen de las habilidades para realizar el trabajo ellos mismos.

Esto permite que el desarrollador front-end tome en cuenta el trabajo de las otras disciplinas al estimar el esfuerzo total requerido para lograr una historia. Si hay grandes disparidades en las estimaciones, el equipo debe reunirse para examinar de dónde se originaron las diferencias y si todos están en la misma página.

Puede realizar otra ronda de cálculos para esa narración después de que todos hayan tenido la oportunidad de indicar qué factores utilizaron para llegar a su estimación. Lo más probable es que las estimaciones sean sustancialmente más cercanas entre sí.

gracias por responder a Olivia, pero ¿cómo podría el, digamos, tipo de frontend, tener alguna idea de cuán compleja es una parte de una historia que se implementará en IOS? por lo general, no tiene experiencia con eso
Después de algunas iteraciones, el chico de la interfaz debería tener una idea de cómo los chicos de iOS probablemente estimarían la historia. Por ejemplo, si necesita un widget que iOS no tiene, es posible que sepa que implementarlo requiere más esfuerzo que piratear un widget similar con Bootstrap o cualquier marco que esté usando. Esa es un área donde la comunicación dentro del equipo es importante.

¿Tienes un equipo o varios equipos? Su descripción no es clara en esto. Si está haciendo Scrum, realmente debería estar trabajando con un equipo que desarrolle una comprensión común de la complejidad de las historias.

La estimación de puntos de historia solo es aplicable si la realiza un equipo en consenso. Esto puede implicar una discusión y una nueva estimación si las estimaciones iniciales de los miembros del equipo difieren considerablemente.

Si los desarrolladores encuentran que las subtareas de la historia suponen una carga demasiado alta para las personas o los subgrupos (como los desarrolladores de back-end) de modo que la suma de los puntos de la historia coincida con la velocidad del equipo según la experiencia, pero el sprint parece estar en riesgo, deben tener eso en cuenta. al seleccionar historias para incluirlas en el sprint.

De hecho, acabo de terminar la planificación del sprint y, para responder a su pregunta, solo tenemos un equipo. e hicimos exactamente lo que dijiste, todo el equipo estuvo de acuerdo en el punto de la historia de una historia que tenía tanto backend como trabajo móvil. Gracias por su respuesta

Un sprint es un evento de tiempo limitado. En ese caso, todos deben completar algunas historias y proporcionar resultados.

Los desarrolladores móviles y de back-end pueden trabajar en paralelo para la misma historia, pero los diseños de esa historia deben estar listos antes de que puedan comenzar. Esto nos lleva a crear una historia/tarea separada para el diseño. Cuando la historia/tarea para el diseño se completa en un sprint, los desarrolladores móviles y de back-end pueden comenzar a trabajar en la historia principal en el siguiente sprint.

Dado que tiene historias/tareas separadas para el diseño y las partes móviles y de back-end, tendrán diferentes puntos de historia. Esto resuelve muchos de tus problemas.

Para avanzar más limpio, puedes tener dos sprints paralelos, por cierto; un sprint de diseño y un sprint de desarrollo, por ejemplo.

Por supuesto, los desarrolladores backend y los desarrolladores móviles (o desarrolladores frontend) darán diferentes puntos de historia a la misma historia, pero es por eso que jugamos al póquer de planificación .

Cómo estimar un punto de la historia, que involucra al equipo móvil y al equipo de back-end
RespuestasAquíPolítica de privacidad1y, 0v