Los puntos de historia son un medio común de estimar el trabajo mientras se utilizan marcos ágiles como Scrum y eXtreme Programming.
desafíos relacionados con la estimación
Cuando los ingenieros estiman el tiempo para completar cualquier tarea, a menudo estiman en un día de ingeniería ideal. Desafortunadamente, los días ideales de ingeniería no existen. Si tienes en cuenta el tiempo dedicado a otras actividades, como Slack, correo electrónico, reuniones y otras tareas administrativas y no técnicas, si tienen suerte, obtendrán el 50% del tiempo productivo.,
A veces el trabajo es fácil de estimar. Los elementos que tienen un aire de repetición, como leer algunos datos de una base de datos y mostrarlos en la pantalla, son fáciles de entender y estimar. El trabajo repetitivo o similar también es fácil de estimar. Sin embargo, el desarrollo de software a menudo requiere soluciones a medida que nunca se han intentado antes (al menos no por el equipo que hace las estimaciones). También pueden necesitar integrarse con componentes desarrollados por otros grupos. A medida que aumenta la complejidad, también aumenta la incertidumbre.,
cuando se nos pide que estimemos algo a medida o complejo, a menudo confiamos demasiado en el tiempo que tomará completar la tarea. Un contribuyente significativo a esto es el hecho de que no podemos predecir cada paso que podría ser necesario. Las tareas a menudo surgen a medida que el trabajo está en marcha, ya que los desafíos imprevistos generan pasos adicionales. Este exceso de confianza se traduce en subestimar el tiempo y el esfuerzo para hacer el trabajo.
beneficios de estimar
no a todo el mundo le gusta estimar, y lleva tiempo y esfuerzo hacerlo. Dados los costos y desafíos para hacerlo bien, ¿por qué molestarse en absoluto?,
beneficios para los equipos de desarrollo:
- saben cuánto planificar en un sprint para que puedan trabajar a un ritmo sostenible.
- Es más probable que creen un incremento hecho al no planificar demasiado el sprint.
- Aumenta la comprensión de los requisitos y la estrategia de implementación a través de la discusión y la elaboración
beneficios para los propietarios de productos:
- están para pronosticar la entrega a largo plazo de su producto.,
- pueden evaluar la «relación calidad-precio «o el» retorno de la inversión » de los artículos
- obtienen visibilidad de los riesgos técnicos asociados con artículos grandes
conceptos críticos en el story pointing
Story pointing reúne varios conceptos
la estimación relativa es más fácil que la estimación absoluta. Es mucho más fácil comparar dos artículos de backlog de productos y decir que uno es el doble de difícil que el otro. Es mucho más difícil pensar cuántas líneas de código toma una cosa y, por lo tanto, cuánto tiempo se tarda en codificar y probar.,
utilizar la diversidad de todo el equipo crea mejores estimaciones. También conocido como la sabiduría de las multitudes. Los equipos aportan una diversidad de pensamiento y opinión. Diferentes miembros del equipo verán el mismo problema desde un punto de vista diferente, lo que permitirá una entrada más amplia en la discusión del problema. Una simple corrección de errores solo puede tomar una línea de código para cambiar, pero muchas horas de pruebas de regresión. Si solo se considera una opinión, el tamaño del artículo puede estar muy lejos.
La precisión y la comprensión se reducen a medida que los elementos se hacen más grandes. El tamaño de los diamantes se mide en mm por lo general con 1 decimal., La diferencia en ese 0.1 mm extra puede ser bastante significativa y vale la pena discutirla. Comparándolo con Júpiter, que tiene un radio medio de 69911km, sería ridículo discutir sobre un extra de 0.1 mm. Los puntos de la historia usan una escala no lineal como la secuencia de Fibonacci, que aumenta los espacios entre los números a medida que aumenta. Hay un 34 pero no 33 o 35.
Los puntos de la historia no son sobre el tiempo que le llevará a cualquier individuo hacer el trabajo. En Scrum y XP, a una persona no se le asigna trabajo en el punto de estimación., Todo el equipo sigue siendo dueño del trabajo, lo que significa que cualquiera en el equipo puede recogerlo. En lugar de esfuerzos individuales de tiempo, los puntos de historia representan una combinación de tamaño, complejidad y riesgo. La cantidad de trabajo que se puede completar en el sprint se calcula utilizando la velocidad del equipo (cuántos puntos completó en el sprint anterior).
enfoque
calibración
antes de comenzar a estimar en puntos, todo el equipo necesita calibrar lo que vale un punto., Para calibrar la báscula, elija un elemento del backlog que sea simple, y todos los miembros del equipo lo entienden y lo definen en la báscula. (por ejemplo, 2 puntos). Para mejorar aún más su calibración, encuentre un ejemplo más arriba en la escala tal vez cuatro veces más grande y defínelo como un 8. La calibración de la escala de estimación mejorará significativamente su éxito con la estimación.
ponerse de acuerdo sobre cómo gestionar las diferencias
el equipo de desarrollo debe ponerse de acuerdo sobre cómo gestionar las diferencias en las estimaciones. Cuántas rondas Irán y qué deben hacer si las estimaciones no convergen., Para obtener los beneficios de la estimación de grupo, un mínimo de dos rondas proporcionará diálogo para desentrañar suposiciones. Es posible que el facilitador tenga que recordarle al equipo que hay un valor limitado en los largos debates entre estimaciones similares: si el equipo está luchando para ponerse de acuerdo si se trata de un 2 o un 3, simplemente elija uno y siga adelante.
reunión de estimación
la reunión de estimación procede de la siguiente manera:
- El Scrum Master, que no jugará, preside la reunión.
- el propietario del producto proporciona una breve descripción de un artículo de backlog de producto (PBI) para ser estimado., El equipo de desarrollo hace preguntas y discute para aclarar supuestos y riesgos. Un resumen de la discusión es grabado por el equipo de desarrollo.
- Cada miembro del equipo de desarrollo compara el tamaño del PBI en relación con el PBIs de calibración y elige su estimación de tamaño. Durante la discusión, los números no deben mencionarse en absoluto en relación con el tamaño de la característica para evitar el anclaje.
- Todos llaman a sus estimaciones simultáneamente. Solo el equipo de desarrollo puede estimar., El propietario del producto puede preguntar por qué algo tiene un tamaño determinado y puede iniciar una negociación sobre el alcance que puede afectar al tamaño de un artículo.
- Las personas con estimaciones altas y bajas ofrecen su justificación para su estimación, y luego la discusión continúa. Durante el debate, las suposiciones deben ser aireadas, y el propietario del producto puede proporcionar claridad.
- este paso a menudo presenta una comprensión diferente del alcance o la implementación, que luego puede aclararse y acordarse., La persona que dio un 2 puede conocer una solución fácil, pero la persona que dio un 13 puede anticipar una dificultad que nadie más pensó.
- repita el proceso de estimación hasta que se alcance un consenso. O se logra suficiente convergencia según las propias reglas de los equipos de desarrollo.
no se trata de los puntos
El éxito al final de un sprint/iteración no se mide por el número de puntos completados o la proporción de puntos planificados vs puntos reales alcanzados. El éxito se mide por cuánto valor se creó. Los puntos son un medio para ayudar a crear valor, no un fin en sí mismos.
