¿Cómo programar desarrolladores front-end y back-end en función de los puntos de la historia?

Estamos acostumbrados a crear múltiples subtareas para cada historia de usuario y proporcionamos a cada subtarea una estimación en horas y asignado ( back -end o front-end ).

Con el siguiente resultado:

  • Tiempo total estimado necesario en horas para la historia del usuario dividida entre back -end y front-end
  • La disponibilidad de los desarrolladores back -end y front-end se puede tener en cuenta cuando las historias de usuario se colocan en sprints.
  • Los desarrolladores se programan en consecuencia en Harvest Forecast en función de su disponibilidad y función de back - end o front-end

A pesar de ello, no podemos proporcionar un tiempo estimado exacto. Por eso queremos ajustar nuestra gestión de proyectos:

Cuando apliquemos todo esto, lo más probable es que logremos una estimación total más precisa para un sprint y planifiquemos una cantidad factible de trabajo en un sprint en función de la velocidad.

Solo tenemos un problema. Si ya no usamos subtareas para la estimación , tampoco sabemos cuántas horas debe programar un desarrollador back o front-end en Harvest Forecast .

De ahí la pregunta: ¿cómo programar a los desarrolladores front-end y back -end en función de los puntos de la historia?

Relacionado:

Prográmelos durante 40 horas a la semana cada uno. Estime proyectos en semanas por personas, no desgloses de tareas. En resumen, sea menos granular para mejorar la precisión general.
@ToddA.Jacobs gracias! Pero, ¿y si resulta que es un 70 % trasero y un 30 % frontal?
Si desea los beneficios de la estimación ágil, no caiga presa de la falacia de utilización del 100 % ni realice una estimación individual. Estime el trabajo para el equipo como un todo.

Respuestas (2)

Si lo he interpretado correctamente, su pregunta es cómo convertir las estimaciones de Story Point para User Stories en estimaciones de tiempo para cada desarrollador individual.

¿Mi respuesta?

No.

La única razón posible por la que puedo pensar por qué necesitaría estimaciones individuales es para KPI (Indicadores clave de rendimiento) individuales. Los cuales, en mi experiencia, son en sí mismos dañinos.

En su lugar, debe estimar para el equipo . Tratar al equipo como un todo cohesionado. En lugar de tomar Desarrollador F 1 día y Desarrollador B 2 días, la historia toma los puntos de historia del Equipo 2. (Que luego puede convertir en estimaciones de tiempo para el Equipo, como creo que se ha respondido aquí antes).

De tu comentario:

Pero, ¿y si resulta que es un 70 % trasero y un 30 % frontal?

Esto me huele a falacia de utilización del 100% . Entonces resulta que toma un 70% de back-end y un 30% de front-end... ¿y qué? Eso significa que los desarrolladores front-end pueden usar su tiempo libre de manera más efectiva que Sprint. Tal vez puedan emparejarse con los desarrolladores de back-end para tener forma de T.

Gracias, muy esclarecedor! La razón es usar desarrolladores de la manera más eficiente posible en múltiples proyectos (en el caso de un 70% de back-end y un 30% de front-end) y así darle al cliente una buena relación calidad-precio, ¿puedo estar equivocado?
@BartvanKleef Vea la falacia de utilización del 100 %. Debe optimizar el rendimiento de las tareas, no el tiempo de los desarrolladores.
@BartvanKleef También advertiría contra la distribución de la misma persona en varios proyectos. Hay un costo enorme para ese tipo de cambio de contexto y también termina inevitablemente con dos proyectos luchando por el 70% del tiempo de la misma persona. Eso da como resultado un lugar de trabajo miserable y agotamiento.
@BartvanKleef: ¿Qué haría si la mayoría de los proyectos son 70 % atrasados ​​y 30 % adelantados para el próximo mes? ¿Enviar a la mitad de sus desarrolladores front-end con licencia sin goce de sueldo?
@BartvanIngenSchenau ¡Buena pregunta! Tenemos algunos empleados de guardia (0 horas). O los ubicamos en nuestros propios proyectos paralelos en lugar de los del cliente. Nunca licencia sin goce de sueldo.
@RubberDuck, esta es precisamente la razón por la que usamos Harvest Forecast. Programe a los desarrolladores en un sprint en función de su disponibilidad en días consecutivos. En el ejemplo dado, tanto los desarrolladores de back-end como los de front-end serán programados para un segundo sprint (y, por lo tanto, para otro proyecto) más tarde esa misma semana (porque hay trabajo adicional de back-end o front-end). ¿De qué otra manera le damos al cliente valor por su dinero?
@Sarov, ¡tienes un buen punto allí!
@BartvanKleef Si está programando desarrolladores en un sprint en función de su disponibilidad y el trabajo, no está haciendo nada relacionado con Scrum, por lo que llamarlo un sprint podría confundir a la gente.

Un enfoque que he visto realizado con éxito es el siguiente.

El equipo estima cada elemento pendiente en puntos de historia. Todo el equipo estima y acuerda la cifra de puntos de la historia en función del tamaño relativo.

Los puntos de la historia realizados en sprints anteriores se utilizan para calcular la velocidad del equipo. Esto proporciona una guía sobre la capacidad de futuros sprints.

En la reunión de planificación, el equipo extrae historias de la cartera de productos hasta que alcanzan su capacidad. Por ejemplo, si la velocidad del equipo es de 30 puntos de historia, agregarían historias a la acumulación de sprint hasta llegar a cerca de 30 puntos de historia.

A continuación, el equipo analiza la historia de mayor prioridad en la acumulación de sprint y la divide en tareas técnicas. Hacen estimaciones por horas sobre las tareas técnicas y anotan si requieren una especialización (por ejemplo, desarrollador front-end o desarrollador back-end).

Luego, el equipo usa el mismo enfoque en cada una de las historias restantes en la acumulación de sprint. Mientras hacen esto, el Scrum Master realiza un seguimiento de las horas de cada especialización. Si notan que una especialización se está sobrecargando, se lo dicen al equipo. En este punto, el equipo puede:

  • Elimine cualquier historia de la acumulación de sprint que aún no se haya desglosado en tareas técnicas
  • Mire la parte superior de la cartera de productos y vea si hay historias que puedan intercambiar en el sprint que crea un mejor equilibrio de trabajo para las diversas especializaciones.

Esto asegura que ninguna especialización se sobrecargue en el sprint.

Vale la pena señalar que un mejor enfoque a largo plazo es garantizar que los miembros del equipo tengan habilidades en forma de T. Si los miembros del equipo pueden hacer el trabajo de desarrollo de front-end y back-end, entonces pueden:

  • Sea mucho más flexible con los tipos de historias que traen a los sprints
  • Preocúpate menos de que los miembros del equipo trabajen demasiado o demasiado poco
  • Pasa menos tiempo estimando
¡Gracias por compartir! Este me parece el enfoque correcto para convertir puntos de historia en estimaciones para historias de usuario para back-end y front-end si lo desea.
¿Cómo programar desarrolladores front-end y back-end en función de los puntos de la historia?
RespuestasAquíPolítica de privacidad1y, 6v