Descargo de responsabilidad: soy un desarrollador, por lo que no pretendo tener un conocimiento profundo de las prácticas ágiles, por lo que es posible que no siempre use las palabras y los términos correctos. Por favor corrígeme si es necesario.
Los equipos ágiles a menudo usan la métrica de "puntos de la historia" para estimar el esfuerzo de una tarea. Sin embargo, noté que no me siento del todo cómodo dando una estimación de "punto de la historia", porque parece demasiado especulativo. En su lugar, prefiero desagregar primero los puntos de la historia en volumen de trabajo , riesgo , complejidad e incertidumbre (por ejemplo, como se menciona aquí ) y luego combinar estos cuatro en una estimación de "punto de la historia". Desafortunadamente, no tengo una forma clara de hacerlo (el promedio simple parece demasiado... simple), así que se me ocurrieron varias preguntas:
en su práctica, ¿utiliza la desagregación antes mencionada? ¿Por qué o por qué no?
Animo a los equipos a centrarse en estimar la consistencia en lugar de tener un enfoque de estimación complicado.
Hay una serie de razones para esto, incluyendo:
Las estimaciones relativas (puntos) son útiles porque tienden a dar una mejor aproximación que las estimaciones absolutas y tienden a ser más fáciles de trabajar. Sin embargo, los puntos son solo una aproximación y tienen más sentido cuando se observan en conjunto y durante un período de tiempo. Me pregunto si le estás dando demasiada importancia a los detalles. Algunas sugerencias a continuación.
Ciertamente tomo en cuenta todos los factores que mencionaste, pero tiendo a hacerlo en comparación relativa con las historias completadas previamente ("esta es tan grande/difícil/incierta como esta"). Tener en mente algunas historias familiares de "línea de base" para comparar hace que la estimación sea mucho más fácil.
Use Fibonacci o una serie de Fibonacci modificada para las estimaciones. Para las historias más grandes, no necesita ser tan preciso porque los intervalos entre los números son grandes. Para historias más pequeñas, un punto o dos de cualquier manera apenas importa.
Estimar como equipo (delphi de banda ancha / póquer de planificación) y apuntar a un consenso. Las estimaciones del equipo actúan como un control de sentido entre sí. Los equipos tienden a llegar a un entendimiento común de lo que significa el tamaño de los puntos.
Las estimaciones realmente solo tienen que ser lo suficientemente precisas para que decidas si una historia encajará en un sprint o si necesita dividirse.
En realidad, los "puntos de la historia" son exactamente para no hacer lo que estás tratando de hacer :) La idea detrás de esto es esta;
Hay un malentendido de que cada punto de la historia debe coincidir con una métrica basada en el esfuerzo, como horas, minutos, días, etc. Eso está mal. El punto de historia "3" puede tardar 5 horas en completar este sprint, pero el mismo punto puede tardar 2 horas en completar el siguiente sprint.
Todo lo que tratamos de hacer es tratar de dimensionar las historias de acuerdo con las demás, relativamente. Confiamos en nuestros sentidos y decimos: "Oye, si ISSUE-1234 es 3, entonces ISSUE-4321 definitivamente debería ser 8". eso es todo.
No creo que haya una función matemática para tomar en cuenta el esfuerzo, el riesgo, la complejidad y la incertidumbre para devolver un valor único en puntos de la historia. Tampoco creo que ese enfoque tenga sentido.
Una forma de pensar en ello es reducir los factores. La incertidumbre es una forma de riesgo, por lo que no necesita identificar ambas. En el peor de los casos, observaría tres factores: esfuerzo, riesgo y complejidad. También sospecho que a menudo (pero no necesariamente) existe una relación entre el esfuerzo y la complejidad, ya que el trabajo complejo requiere más esfuerzo para asegurarse de que todo esté bien. Sin embargo, podemos trabajar con tres factores.
Creo que subestimar el trabajo es mucho peor que sobreestimarlo, por lo que un aumento en cualquiera de los tres factores da como resultado un aumento en los puntos de la historia. Si miro la descripción y creo que se trata de un 5 para dar cuenta del esfuerzo, pero todavía hay algunas preguntas abiertas que pueden afectar el trabajo, entonces sube a un 8. Si hay riesgos conocidos que no se han mitigado. , podría subir a 13 o 20. Requerirá trabajo (esfuerzo) resolver preguntas para obtener respuestas o mitigar riesgos, por lo que conceptualmente tiene sentido. La cantidad a aumentar depende de cuántas preguntas, cuánto trabajo llevará responder esas preguntas y cuántos riesgos no mitigados hay.
Sin embargo, si hay demasiadas preguntas abiertas o demasiados riesgos no mitigados, el elemento debe volver al Product Backlog y no considerarse listo para la selección en un Sprint. Si está utilizando Scrum, hay un estado mínimo que es necesario para seleccionar un elemento de la cartera de productos para un Sprint: el equipo cree que puede completar el trabajo descrito en un solo Sprint. Si el equipo no está seguro de si puede traer el artículo y responder a todas las preguntas sin respuesta o manejar cualquier riesgo que pueda surgir al asumir el trabajo, necesita más refinamiento. El refinamiento se puede utilizar para responder esas preguntas o mitigar esos riesgos.
Al final, sin embargo, hay un valor único para la estimación del trabajo. Esto es cierto para los puntos de la historia, las horas ideales o cualquier otra forma de medición. El equipo está haciendo una declaración sobre el esfuerzo necesario para completar el trabajo.
Los Story Points no se basan en ningún tipo de fórmula tangible y no son el punto de estimación.
Durante la Planificación del Sprint, el equipo debe acordar el trabajo que se incluirá en el Sprint Backlog. Esto se basa en dos cosas:
Qué elementos ha puesto el propietario del producto en la parte superior de la cartera de productos, lo que significa que son de máxima prioridad para completar; y
Cuánto trabajo creen los Desarrolladores que pueden entregar cómodamente dentro del Sprint.
La resolución 1 proviene de que la OP hable con las partes interesadas y comprenda qué brindará el mayor valor. Resolver 2 proviene de que los Desarrolladores comprendan su propia capacidad y capacidad.
Los Story Points son una herramienta para facilitar esa comprensión al proporcionar un punto de comparación entre el trabajo que el equipo ya ha realizado y el trabajo que aún está en Backlog. No se traducen exactamente en medidas de tiempo o esfuerzo, y son mucho más útiles en conjunto: dos miembros del equipo pueden estar en desacuerdo sobre si un PBI es 1 o 2 Story Points, pero es más probable que estén de acuerdo sobre si un PBI es 1 o 2 Story Points. la colección de PBI es de 40 u 80 Story Points (y, lo que es más importante, es probable que estén de acuerdo en si este último es demasiado ambicioso para un Sprint).
Como tal, los Story Points siempre serán especulativos y siempre se medirán en relación con otros PBI y siempre serán subjetivos, pero es de esperar que haya un consenso general en el equipo sobre cuántos PBI pueden caber en el Sprint antes de que finalice. comienza a verse tembloroso. Si no hay consenso, entonces no necesita una medida más precisa de la escala de trabajo, debe esforzarse en comprender y resolver las diferencias (por ejemplo, manteniendo una discusión para desentrañar parte de la complejidad, separando partes con mayor incertidumbre, utilizando prácticas como la programación en pareja para compartir conocimientos dentro del equipo, etc.).
Para usar una analogía, si quiero copiar 1000 archivos de diferentes tamaños de un servidor a otro a través de varias rutas, no necesariamente necesito saber que un archivo tiene 1,44 MB y otro 1,43 MB, pero podría ser útil saberlo. que el archivo más grande es de aproximadamente 1 TB y el más pequeño es de aproximadamente 1 MB. Tampoco necesito saber que el archivo de 1 MB tarda exactamente 0,5 s en transferirse en la conexión A, pero 0,6 s en la conexión B, pero probablemente sí quiero saber que el ancho de banda total es de alrededor de 20 Mbps. Y aún mejor si puedo configurar la transferencia de archivos en bloques para no intentar enviar accidentalmente el archivo de 1 TB a través de la conexión más lenta y tener que esperar a que termine mucho después de que todo lo demás ya se transfirió.
Lo que estás sintiendo es normal cada vez que un nuevo equipo comienza o entras de nuevo en un equipo.
La versión actual (2020) de la Guía Scrum ya ni siquiera menciona los puntos de la historia o el esfuerzo; lo más cerca que se acerca a este tema es una breve reseña en la sección Planificación de Sprint:
Seleccionar cuánto se puede completar dentro de un Sprint puede ser un desafío. Sin embargo, cuanto más sepan los desarrolladores sobre su rendimiento anterior, su próxima capacidad y su definición de hecho, más confianza tendrán en sus pronósticos de Sprint.
IIRC, esto era diferente en el pasado. Cuando obtuve mi certificación de Scrum Master hace muchos años, definitivamente se habló sobre los puntos de la historia, obtuvimos nuestras tarjetas de Planning Poker y se habló mucho sobre cómo lograr un número real para cada historia. Sí recuerdo que se le dio mucha importancia al hecho de que los puntos de la historia no deben escalarse directamente al esfuerzo (es decir, tiempo o dinero), pero entonces no estaba claro cuáles eran.
En cada proyecto Scrum o Agile (es decir, kanban, scrumban, zombie-scrum, scrum-but, ...) en el que participé, los equipos utilizaron otra metodología y escala para el esfuerzo de cada historia. Tallas de camisetas, números de fibonacci, etc. No hay magia detrás de esto. Para mí, el único significado de los números de Fibonacci es que reducen la cantidad de números a elegir, es decir, eliminan las discusiones sobre si la historia "vale" 11 o 12 puntos, mientras que son un poco más granulares que los números exponenciales directos 2, 4. , 8, 16, 32...
Al final del día, no importa. Después de algunos sprints, cada miembro del equipo tiene una imagen mental de lo que significan los números. En uno de mis proyectos actuales, pensamos que 13 o 15 puntos es aproximadamente la cantidad de trabajo que un miembro puede hacer por sprint; evitamos tener historias con más de 8 puntos (si pensamos que son más grandes, las dividimos en varias más pequeñas). En otros proyectos usamos S, M, L, XL sin un mapeo particular al tiempo real.
El Manifiesto Ágil no menciona en absoluto el esfuerzo, el tiempo, el dinero o los puntos de la historia y también puede servir como inspiración de por qué esto puede ser así en un contexto ágil.
No hay una forma particularmente útil de convertir los puntos de la historia a las otras dimensiones que mencionas (volumen, riesgo, complejidad...), está perfectamente bien dejarlo un poco nebuloso. Si su PO u otra persona es un PL disfrazado, es libre de dividir el costo del equipo en horas-hombre/dinero por la velocidad para llegar a una tasa de €/punto si los hace felices, pero este tipo Es mejor que las discusiones no se lleven a cabo donde cualquiera de los miembros del equipo las escuche, ya que solo confunde la materia y es un paso atrás a los "viejos" tiempos pre-ágiles.
TLDR: por experiencia, un equipo expresa la dificultad o complejidad de una tarea con puntos de historia. Un posible punto de tener puntos de historia es obtener una medida aproximada de si una acumulación de sprint es razonable dada la capacidad en ese sprint; y que el equipo comunique estas cosas al propietario del producto sin atascar a nadie con tiempo o dinero. No es tan importante, considerando que la Guía Scrum oficial prácticamente los ha eliminado por completo de su folleto central y el Manifiesto Ágil y otros esquemas ágiles más puros se esfuerzan por eliminar estos elementos del proceso.
Me di cuenta de que no me siento del todo cómodo dando una estimación de "punto de la historia", porque parece demasiado especulativo.
Estoy de acuerdo con las otras respuestas, pero pensé en ofrecer una versión ligeramente diferente. Según la cita anterior, el problema no son los puntos de la historia, es su incomodidad al ofrecer una estimación sin un modelo matemático firme.
Pero los puntos de la historia están destinados a hacer dos cosas.
La gran tentación del PM es confundir nuestro trabajo de estimar la duración con la capacidad de controlar la duración. Tenemos que confiar en el equipo para estimar la duración y cumplir con esa estimación. Nos gustan los modelos matemáticos y los cimientos firmes; los equipos tienden a preferir exactamente lo contrario.
Hylle