Este es un tema complejo, y hay frecuentes debates sobre el tema. No me gusta el concepto de opinión "canónica" sobre esto: hay varias opiniones con valor. Pero hay valores, principios y prácticas de apoyo que deberían guiar el enfoque.
Lo siguiente se basa en mis propias opiniones trabajando con equipos scrum durante más de 10 años. Pero es solo MI opinión.
Puntos de historia como método de pronóstico La intención original de los puntos de historia era encontrar un método rápido para estimar el esfuerzo con el fin de pronosticar lo que un equipo puede completar durante un período de tiempo. Algunas de las "luminarias" afirman que los puntos se usan solo para pronosticar el alcance a más largo plazo (por ejemplo, en un lanzamiento) y no para determinar la capacidad en el nivel de sprint. Además, el concepto es que los equipos están aplicando un "tamaño relativo" basado en valores históricos (el esfuerzo X es similar al esfuerzo B, que fue de 3 puntos). Esto acelera el proceso de estimación para que los equipos no tengan que dividir el trabajo futuro en paquetes de trabajo detallados y aplicar horas a todas las tareas. Los equipos de alto rendimiento se esfuerzan por hacer que todos los trabajadores técnicos se conviertan en miembros muy competentes de niveles de habilidad similares. (Este concepto se explorará más en el punto 4). Cuando esto se logra, el nivel de habilidad individual no es realmente una variable en el tamaño. PERO: Por lo general, lleva bastante tiempo y un esfuerzo concertado lograr ese objetivo. Entonces ... ¿qué hacemos antes de llegar allí?
Las horas de tarea determinan la capacidad de sprint: de acuerdo con las mismas "luminarias" que afirman que los puntos se usan para pronósticos a largo plazo, también proponen que las horas de tarea se usen para determinar la capacidad de sprint, en lugar de los puntos. En mi opinión, eso está bien, pero diré que cuando ayudé a los equipos de entrenadores a "Alto rendimiento", sus habilidades niveladas se promediaron para poder determinar con precisión lo que podrían completar en un sprint usando solo Story Points . Nuevamente, ese puede ser un objetivo hacia el cual nos esforzamos, pero los equipos más nuevos no están listos para eso. Por lo tanto, puede encontrar en un solo sprint una Historia con 2 puntos que tiene 12 horas de esfuerzo y otra con 25 horas de esfuerzo. Entonces, ¿Qué haces? Algunas personas a las que llamo "puristas ágiles" afirmarán que el tamaño de la historia (en puntos) debe ser independiente de la duración. Otros no están de acuerdo. Lea la lógica en el ítem # 3 y vea lo que piensa.
- Señalar historias por consenso: aplicar volumen, incógnitas, complejidad, conocimiento
Por lo tanto, los equipos miran un trabajo y necesitan ponerse de acuerdo sobre los puntos que serán un proxy para el Nivel de esfuerzo. ¿Derecho? Suponiendo que todas las habilidades son iguales, entonces el consenso es fácil de alcanzar. Pero a menudo los equipos tienen un tipo que es un gurú de Java, otro que no es tan bueno en Java (tal vez ella era una persona de C # o .Net o Cobol y está aprendiendo Java). Entonces la tarea X para Bob es muy simple. Para Jane, es más difícil.
Los equipos ágiles intentan promover la propiedad del código colectivo y la experiencia creciente / en expansión. Por lo tanto, generalmente no asignamos historias a personas en función de su experiencia: preferimos que los equipos trabajen colectivamente en historias y aprendan juntos. Esto se alinea con el concepto de "reducir la velocidad para acelerar": si nos tomamos el tiempo para brindarle a Jane experiencia con Java, aunque esto puede retrasarnos al principio, más adelante tendremos desarrolladores de Java más competentes. De hecho, si solo tenemos UN experto en Java, y todos trabajan en sus propias áreas de especialización, estamos creando una situación con múltiples "puntos de falla" potenciales. ¿Qué sucede en el sprint cuando el 90% del trabajo es Java, pero Bob (nuestro experto en Java) está enfermo o de vacaciones? Al ampliar las habilidades, eliminamos posibles cuellos de botella y reducimos el riesgo. Con eso en mente: Cuando el equipo mira una historia, deben tener varios conceptos en mente al dimensionar. Puedes pensar en el acrónimo VUCK para recordar esto.
Volumen: algunos esfuerzos son bastante simples, pero requieren un gran volumen de tareas repetidas. (Tuve un tipo que tuvo que copiar y reformatear más de 50 tablas que dijo que era 1 punto porque era simple. Pero después de reflexionar, el equipo se dio cuenta de que si bien era fácil, tomaba mucho tiempo y había un gran volumen de tablas para ser movido y optimizado, así que tuvimos que reajustar los puntos debido al volumen de trabajo)
Incógnitas: a veces pensamos que sabemos qué hacer, pero también identificamos algunas incógnitas, que representan RIESGOS . Y esto implica que podemos encontrar problemas inesperados que tenemos que resolver, rediseñar o probar una solución diferente.
Complejidad: esta es bastante obvia. Algunas soluciones son técnicamente complejas. Sabemos exactamente qué hacer, pero requiere experiencia técnica. La complejidad también implica cierto riesgo, ¿no? Entonces, incluso si todos tenemos las mismas habilidades, la complejidad técnica implica que podríamos enfrentar desafíos imprevistos. Entonces podríamos hacer esta historia más grande.
Conocimiento: ¿REALMENTE sabemos lo que estamos resolviendo? A veces los clientes no tienen del todo claro la solución que desean, y estamos experimentando un poco. O tal vez nadie haya implementado esta solución (nueva tecnología nunca antes utilizada) y, por lo tanto, no sabemos lo que no sabemos.
En mi opinión, cada una de estas consideraciones es en realidad un proxy para una duración prolongada. Historia fácil, mucho volumen? Tomará más tiempo, o tenemos que dividir la historia. Incógnitas? Riesgo agregado, investigación, experimentación, puede tomar más tiempo o necesitamos dividir la historia. ¿Complejo? Riesgo adicional, necesita corregir errores, rediseñar, etc., por lo que puede llevar más tiempo. ¿No sabe si tenemos el conocimiento requerido? Tenemos un riesgo adicional, es posible que necesitemos experimentar, etc., por lo que puede llevar más tiempo ...
¿Ves a dónde va esto? Entonces, aunque el concepto de puntos de la historia nos desalienta de pensar en la duración al estimar, por otro lado, sería ilógico tener una historia de 1 punto que podamos completar en 4 horas y otra historia de 1 punto que sea simple pero tomará 2 semanas.
- Los equipos de alto rendimiento eliminan los silos y los cuellos de botella: debido a que los equipos intentan subir de nivel a todos los miembros, a veces tienen miembros con menos experiencia para asumir nuevos desafíos, o se emparejan para compartir conocimientos para mejorar como equipo. Como se mencionó anteriormente, este es un requisito si el equipo alguna vez alcanzará verdaderos niveles de alto rendimiento.
Entonces, si Jane se ofrece como voluntaria para asumir ese esfuerzo de Java y eso haría que el esfuerzo sea 2x o 3x la duración del mismo esfuerzo si Bob lo hiciera, ¿qué haría usted? Con el tiempo, mis equipos decidieron dimensionar historias basadas en el nivel de esfuerzo (LOE) / VUCK para las personas que trabajan en el esfuerzo. No tiene sentido para Bob, el gurú del equipo, decir "eso es un 1" cuando para Jane no será fácil y tardará una semana en completarse, además de requerir un poco de tiempo de Bob para la codificación de pares y la revisión del código. Por lo tanto, aumentamos esos puntos para reflejar la verdadera LOE. La próxima vez que apareció una historia similar, lo que era un 8 para Jane se convirtió en un 5. Finalmente, todos coincidieron en que era un 3. Fácil. En ese momento, sabíamos que estábamos creciendo como equipo.