¿Debería considerarse la habilidad individual en los puntos de la historia?

Mi comprensión de la estimación de la historia ha sido que uno debe estimar el tamaño de una historia como lo sería para un desarrollador imaginario promedio, un poco como el concepto de ley "espectador razonable". Es decir, no debe estimar el tamaño de la historia suponiendo que tiene que hacerlo .

Para dar un ejemplo: en mi trabajo anterior era parte de un equipo en el que era el desarrollador de Ruby más confiado. Mis compañeros de equipo rutinariamente estimarían las historias relacionadas con Ruby mucho más grandes que yo, con argumentos como: "Bueno, no sé cómo funciona X en Ruby, así que esto me llevaría mucho tiempo".

Mi argumento en contra de esto proviene del hecho de que la planificación del sprint es donde entra en juego la capacidad del equipo. Ese es el foro correcto para decir: "Nuestra capacidad este sprint será un poco menor de lo habitual porque la mayoría de las tareas están basadas en Ruby, y solo tenemos un desarrollador Ruby fuerte". Factorizar esto durante la estimación duplicaría este aspecto.

Agradecería cualquier referencia autorizada en las respuestas, pero las opiniones simples también serían geniales.

Los puntos de la historia son una estimación relativa. Entonces, el doble de puntos significa el doble de nivel de esfuerzo. Las estimaciones relativas están menos sujetas a variaciones de nivel de habilidad. La pregunta no es cuánto tiempo tomaría para 1 punto, sino que 2 puntos requieren 2 veces más esfuerzo potencial. El nivel de habilidad podría importar más si tomara días ideales en lugar de puntos de historia, porque asume un nivel de productividad individual.

Las estimaciones relativas son más robustas. Además, la evaluación del punto de la historia no debe ser realizada por un individuo, sino el resultado de un esfuerzo colectivo del equipo . Para historias menos complejas, generalmente hay un acuerdo rápido. Para historias más desafiantes, el equipo obtendrá un resultado con el que la mayoría de los miembros estarán de acuerdo y, por lo tanto, tomarán en cuenta implícitamente el nivel de habilidad colectiva del equipo.

Finalmente, la evaluación de la historia se realiza en un momento en que las tareas dentro del equipo no están necesariamente decididas. Este es un argumento más para no tener en cuenta el nivel de habilidad individual. Para la planificación del sprint, tomará la capacidad de puntos de historia del equipo, que es una cifra que evolucionará en función de las cifras de rendimiento reales, de modo que se autoajustará al nivel de habilidad global de su equipo.

En conclusión, la capacidad individual no debe tenerse en cuenta para la estimación. Pero incluso si se hiciera, debido a las estimaciones colectivas y la solidez del enfoque relativo, no importaría tanto.

La respuesta canónica es que no debe cambiar las estimaciones por desarrollador. Eso significaría que obtendrá toneladas más de puntos por sprint que sus pares, y eso está bien porque los puntos miden la velocidad del equipo , no los desarrolladores. Las empresas pueden estimar cuánto producirá el equipo para obtener expectativas aproximadas de entrega, y todo es excelente.

Sin embargo, eso causa todo tipo de problemas en la práctica. ¿Qué pasa si estás de vacaciones esa semana? ¿Qué sucede cuando llega el tiempo de revisión y te das cuenta de que estás produciendo el 200% del promedio de puntos de historia por el 110% del salario promedio? ¿Qué sucede cuando las empresas comienzan a pensar que la velocidad del equipo dividida por las personas es en realidad una aproximación precisa? ¿Qué sucede cuando la empresa se da cuenta de que está produciendo muchos más errores que sus pares (mientras ignora que produce mucha más funcionalidad)? ¿Qué constituyen las historias "del tamaño de un bocado" cuando las personas tienen bocados tan variados?

Lo que he encontrado a través de mi carrera es que en gran medida no importa. El proceso está ahí para servirle, no al revés. Si su organización necesita medir si los desarrolladores están sobrecargados, los puntos de historia por desarrollador son una buena solución. Si su organización necesita medir la velocidad del equipo, los puntos de historia independientes del desarrollador proporcionarán una imagen más clara. Sin embargo, siempre son una aproximación, y siempre serán abusados ​​y malinterpretados.

Al final, son puntos inventados para un proceso inventado que necesita adaptar a su entorno.

TL; DR
Siempre debemos suponer que solo los desarrolladores competentes serán asignados a una historia en particular.

La competencia (o falta de ella) no es un insulto. Es simplemente una medida razonable de las habilidades de un desarrollador que no está rezagado ni tiene una experiencia excepcional.

Esto puede ser una cuestión del enfoque de una empresa en particular. He visto compañías adaptar estimaciones a desarrolladores particulares. También he visto compañías que aplicaron un sistema donde tres desarrolladores seleccionados al azar hacen estimaciones de historias antes de asignar casi al azar un desarrollador (no uno de los tres iniciales) a la tarea.

Cada sistema puede funcionar, cada sistema puede fallar. La pregunta no es tanto qué sistema es mejor, sino cuáles son los defectos que la empresa puede / está dispuesta a resolver .

En principio, no se debe incluir el tiempo de estudio para dominar el lenguaje / marco. Tangente menor: aunque no deberían existir en un mundo ideal, se debe incluir tiempo de estudio para obstáculos específicos de proyectos o historias.

Hay muchas justificaciones para hacerlo, pero creo que este enfoque generalmente es una mejor opción, ya que se mantiene fiel a la intención de estimar una carga de trabajo. Esto podría ser solo una cuestión de mi opinión, en lugar de objetividad. No puedo decir con certeza.

El tiempo de estudio es personal . Está dentro del alcance de un desarrollador en particular que necesita trabajar en una tecnología en particular. No es relevante al evaluar la carga de trabajo de una historia de usuario, ya que una historia de usuario solo está en el alcance de la aplicación (y la tecnología que utiliza).

El tiempo de estudio generalmente no se acumula. Digamos que nuestro novato sabe poco de C #, y estimamos que necesita tres días adicionales para descubrir el entorno antes de que pueda hacer el trabajo. Como es común en muchas empresas en las que he trabajado, ahora estamos en una reunión en la que se espera que calculemos varias historias de usuarios (individualmente). Por el bien de ejemplo, digamos que tenemos tres historias que abordar.

• ¿Agregamos tres días a cada historia? Si las tres historias tienen un enfoque técnico similar, eso significa que el novato no necesitará más tiempo en la segunda y tercera historia. Hemos sobreestimado el trabajo por seis días.
• ¿Agregamos un día a cada historia? Esto tampoco es correcto. Si solo terminamos asignando al novato a una de tres historias, entonces le hemos cambiado dos días necesarios de tiempo de estudio; y le hemos dado dos días innecesarios de tiempo de estudio a otros desarrolladores.
• ¿Agregamos tres días a una historia? ¿Cómo podemos garantizar que esta historia se manejará antes que las otras dos? El objetivo de crear historias de usuario separadas es que las historias generalmente se pueden abordar independientemente una de la otra. La exactitud de nuestra estimación ahora depende tanto de la suposición de que nuestro novato hará el trabajo, más el orden en el que se le asignan esas tareas (si es importante, por ejemplo, si la carga de trabajo combinada supera un solo sprint).

Nota :
Hay otros casos en los que el tiempo de estudio hace pila, por ejemplo, si las tres historias están violentamente temas diferentes y requieren diferentes habilidades.
Pero para saber si este es el caso o no, tendríamos que mirar las tres historias al mismo tiempo, lo que lentamente comienza a violar el principio de tener historias de usuarios independientes . Si hubiéramos abordado estas estimaciones en reuniones separadas, posiblemente con diferentes desarrolladores presentes; no podríamos medir con precisión la superposición entre las historias.

Debido a que no podemos garantizar qué historias terminarán siendo hechas (el cliente podría rechazar una estimación grande) y quién será asignado a ellas, tratar de dar cuenta de que un desarrollador en particular se asignará a una historia en particular es inútil. Solo termina enturbiando el agua.

En cambio, deberíamos hacer una estimación de la carga de trabajo asumiendo que el novato ya ha sido actualizado (y por lo tanto es un desarrollador igual para sus compañeros de trabajo).
Tal estimación es independiente del desarrollador, y la exactitud de la estimación, por lo tanto, no fluctúa dependiendo de qué desarrollador termina siendo asignado a la historia.

Nota:
Sigue siendo relevante reconocer que un desarrollador en particular puede necesitar tiempo adicional para estudiar antes de poder abordar una historia en particular. Esa sigue siendo una consideración muy relevante. Pero esta consideración no debe adjuntarse a la historia , sino más bien la asignación de este desarrollador particular a esta historia particular.

Pero, como comencé, esto puede variar de una compañía a otra. Es posible que algunas empresas no estén tan preocupadas por el tiempo de estudio (por ejemplo, si el desarrollador inevitablemente tendrá que aprender a usar la tecnología de todos modos). Otros pueden depender en gran medida de la precisión de estas estimaciones, ya que influye en la facturación a un cliente.

Al final, es cuestión de elegir tu veneno. No se garantiza que ninguno de estos enfoques sea más preciso que los demás.

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.

1. 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í?

2. 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.

3. 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.

4. 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.

TLDR

No, pero tal vez no por la razón que piensas.

Versión larga

Muchas de las otras respuestas han explicado que los puntos de historia deben calcularse únicamente en relación con otros trabajos. Esto es absolutamente cierto. Como los Story Points estiman la cantidad de trabajo en lugar del tiempo requerido para completarlo, entonces tiene poco sentido dar Story Points en función de un individuo.

Por ejemplo (uno de mis favoritos), considere su tarea "Cavar un hoyo". Puede estimar esto en función de la cantidad de tierra que se eliminará o del tiempo que le llevará eliminarla. Mi amigo cava un todo a una velocidad de 3 metros por hora, ¡tengo una excavadora mecánica grande para poder manejar 100! La única constante es la cantidad de tierra, por lo tanto, eso es lo que usamos como nuestra unidad de estimación.

Sin embargo, una segunda razón (y en mi opinión más importante) para descontar la capacidad del desarrollador para estimar historias de usuarios es el hecho de que casi todas las historias de usuarios probablemente serán trabajadas por varias personas.

Es posible que tenga un arquitecto, un desarrollador, un probador, quizás un segundo desarrollador para hacer la interfaz de usuario. Antes de que su historia de usuario se marque como Hecho (idealmente implementada y hecha), muchas personas diferentes habrán trabajado en ella. De repente, la idea de estimar con base en el desarrollador en cuestión tiene muy poco sentido, la única forma de estimar con precisión cuánto esfuerzo involucrará el equipo es medir la velocidad de los equipos y estimar el trabajo para que el equipo complete.

¡No hay un "yo" en el equipo y absolutamente ningún yo en la planificación ágil!