Estoy tratando de entender los "puntos de la historia" usando la metodología Scrum. Como punto de partida, he estado siguiendo el siguiente artículo:
http://scrummethodology.com/scrum-effort-estimation-and-story-points/
Con mi equipo estamos utilizando el enfoque de tallas de camiseta (S, M, L y demasiado grande). Usando este enfoque, ¿cómo cuantificamos el tiempo para cada historia de usuario?
Está haciendo:
un buen enfoque?
Está haciendo:
- S = 1/2 al día (máximo)
- M = un día (máximo)
- L = 2 días (máximo)
un buen enfoque?
Absolutamente no. Los puntos de la historia miden la complejidad y el nivel de esfuerzo requerido para completar una función, incluida la Definición de Listo del equipo. No es, y nunca debería ser, mapeado directamente a unidades de tiempo.
Durante la segunda mitad de la Planificación del Sprint, las historias de usuario del Product Backlog se pueden descomponer en tareas para el Sprint Backlog. La regla general común es que las tareas de Sprint Backlog deben tener una duración aproximada de 0,5 a 2,0 días, de modo que sea fácil determinar si una tarea está "terminada" o "no terminada" durante las paradas diarias, pero la historia del usuario en sí misma nunca es mapeado en una unidad de tiempo.
La velocidad es una métrica para determinar la capacidad del sprint actual. Entonces, si bien es razonable preguntarse si una historia determinada puede caber dentro del cuadro de tiempo de un solo sprint, esta es realmente una cuestión de capacidad en lugar de una conversión de tiempo. Tenga en cuenta que algunos expertos sugieren que una sola historia nunca debe exceder el 50 % de la capacidad disponible para una caja de tiempo, pero el propio marco Scrum permite que una sola historia ocupe hasta el 100 % de la capacidad planificada. Su kilometraje puede variar en este sentido.
Como dice CodeGnome, no desea cuantificar el tiempo, desea abstraer el esfuerzo y luego usarlo como "velocidad": mida los puntos de varios sprints completados y luego utilícelos para fines de planificación.
El tamaño relativo entre los valores también es importante, de modo que algo con un valor de punto de 3 es aproximadamente 3 veces el tamaño de un 1, o 1/3 del tamaño de un 9. Sin el tamaño relativo, su velocidad de iteración variará ampliamente dependiendo de si haces muchas cosas pequeñas o solo unas pocas cosas grandes. Trate de revisar el trabajo pendiente y busque historias que se sientan como si estuvieran "en el medio" en cuanto al tamaño, o de tamaño promedio, y utilícelo como su valor medio (como 5 en una escala de 1 a 13). Luego simplemente clasifica las otras historias según sean más grandes o más pequeñas y, en una pasada final, cuánto más grandes o más pequeñas. Después de algunas sesiones de estimación, se vuelve mucho más fácil debido a la familiaridad y una lista cada vez mayor de historias completas y dimensionadas que puede usar como referencia ("triangulación", por así decirlo).
La relación entre puntos y horas es una distribución. Un punto es igual a una distribución con una media de x y alguna desviación estándar. Lo mismo es cierto, también, para las historias de dos puntos, y así sucesivamente. Si bien puede haber cierta superposición en el tiempo transcurrido entre historias de 1 y 2 puntos (algunas historias de un punto pueden resultar más grandes de lo que pensaba el equipo; algunas historias de dos puntos terminan siendo más pequeñas), o entre historias de 2 y 3 puntos. historias, rara vez habrá superposición entre una historia de 1 punto y, digamos, una historia de 13 puntos en términos de tiempo real transcurrido. Dicho todo esto, le advierto que no relacione formalmente los puntos con las horas. Corre el riesgo de olvidar que el tiempo medio de finalización de cada equipo será tan diferente como su idea de lo que constituye un punto. Los puntos son, después de todo, una medida relativa.
Imponer un máximo arbitrario no va a funcionar ya que hay una desviación estándar tan grande entre las estimaciones en cada tamaño de punto/camiseta. Ese SD es la razón por la que usamos la estimación del esfuerzo relativo en lugar de compensar una cantidad de horas que de todos modos será incorrecta.
Ahora, si está trabajando con terceros o contratistas, debe pensar en sprints. Si tiene un sprint de duración fija y un número fijo de personas , entonces tiene un costo fijo para su Sprint.
Lo que luego varía es la velocidad , o la cantidad de funcionalidad entregada, en cada Sprint, o incremento realizado .
Supongo que puede conocer su presupuesto, y puede decidir el presupuesto por el costo del sprint y ver cuántos sprints puede financiar.
Usted configura al equipo para que entregue a un ritmo sostenible y en cada sprint tiene un software que funciona. Puede detenerse en cualquier momento y puede enviar una vez que esté satisfecho.
Si no está satisfecho con la velocidad, entonces debe lidiar con eso. Puede agregar más equipos, hacer que el equipo sea más grande o detener el desarrollo.
muan