Estamos comenzando con Scrum y hemos tenido algunos debates sobre si debemos estimar en puntos de historia o en horas ideales. El equipo está bastante dividido, así que me gustaría saber si se han realizado estudios reales sobre cuál es más eficaz. Ciertamente, he leído muchas opiniones sobre cuál es mejor y, si bien hay buenos argumentos para cada uno, no he encontrado un solo libro, artículo o publicación en una página web que esté respaldado por números concretos.
Entonces, ¿ha habido algún estudio realizado que no haya encontrado? ¿Qué hay de la investigación psicológica sobre estimaciones absolutas versus relativas? Si no existen, ¿qué pasa con los ejemplos del mundo real de lo que ha funcionado para diferentes equipos en varios tipos de empresas?
Mike Cohn en Agile Estimating and Planning describe la estimación usando puntos de historia frente a días ideales en los Capítulos 4-5, luego los compara en el Capítulo 8. Con respecto a la investigación:
Existe evidencia creíble de que somos mejores estimando “esto es así” que estimando el tamaño absoluto de las cosas (Lederer 1998; Vicinanza 1991).
Las fuentes de estas citas se dan como
En general, los días ideales pueden ser más fáciles de comprender para algunas personas / equipos, sin embargo, el riesgo es que se interprete con demasiada facilidad (incluso inconscientemente) como días concretos ( tiempo transcurrido ), que luego puede incluso verse como un compromiso (por ejemplo, por administración). Esta es principalmente la razón por la que muchos utilizan los puntos de la historia, para evitar cualquier posibilidad de mala interpretación. Con los puntos de la historia, siempre está claro que estamos estimando el tamaño relativo, no la duración.
También puede ser importante tener en cuenta que los puntos de la historia no se pueden traducir directamente en horas/días de tareas efectivos; durante un período de tiempo más largo, un equipo, por supuesto, puede calcular cuánto tiempo puede tomar en promedio completar un punto de la historia ; sin embargo, eso no significa que pueda usar ese valor para calcular el tiempo requerido para completar un elemento específico. En la vida real, un elemento concreto de 2 puntos de historia puede requerir la misma cantidad de tiempo para completarse que otro elemento de 1 punto de historia, o puede requerir 3 veces más tiempo. Sin embargo, en una muestra más grande, estas fluctuaciones individuales tienden a cancelarse muy bien, por lo que los puntos de la historia se pueden usar para estimar la velocidad del equipo a largo plazo.
Mike mismo claramente favorece los puntos de la historia:
Mi preferencia son los puntos de la historia. Encuentro que los beneficios que ofrecen como pura medida de tamaño son convincentes. Que los puntos de la historia ayuden a promover el comportamiento del equipo multifuncional es una gran ventaja. Cambiar el pensamiento de un equipo de "mi parte tomará tres días ideales y tu parte tomará dos días ideales, por lo que el total es cinco días ideales" es muy diferente de "en general, esta historia parece tener el mismo tamaño que esa, así que llamémosla cinco". puntos de la historia también.” Que un punto de la historia para mí pueda ser lo mismo que un punto de la historia para usted, mientras que lo mismo puede no ser cierto para un día ideal, es otro gran beneficio. Dos desarrolladores con diferentes habilidades o experiencia pueden ponerse de acuerdo sobre el tamaño de algo y no estar de acuerdo sobre cuánto tiempo llevará hacerlo.
Las deficiencias de los puntos de la historia son realmente cortas. Sí, es más fácil empezar con días ideales. Sin embargo, la incomodidad de trabajar con puntos de historia nebulosos dura poco. Los días ideales son definitivamente más fáciles de explicar a los que están fuera del equipo, pero probablemente no deberíamos elegir en función de lo difícil que será explicárselos a los de fuera. Que los días ideales sean tan fácilmente comprensibles también causa problemas. En algunas organizaciones habrá presión para hacer que un día real se acerque más a un día ideal. La presión por un mayor enfoque y concentración en nuestro trabajo está bien. Pero la presión organizacional para que cada día real se acerque a un día ideal también tendrá el efecto de hacernos estimar en tiempo real mientras lo llamamos día ideal. Es decir, un día ideal se redefinirá como “un día en el que hago seis horas de progreso y hago otras cosas durante dos horas”.
Acabo de toparme con otro artículo del blog de Jeff Sutherland con detalles de investigación y enlaces:
Eche un vistazo a esta publicación de blog de Jeff Sutherland sobre Story Points: ¿Por qué son mejores que las horas?
Esto es defendido vigorosamente por él en la discusión debajo del blog.
En esta publicación de blog, cita los siguientes ejemplos. Estos pueden ser útiles para usted como "ejemplos del mundo real de lo que ha funcionado para diferentes equipos en varios tipos de empresas":
Un estudio de 80 proyectos multimillonarios en GSI Commerce (ahora propiedad de eBay) mostró que los mejores expertos de la empresa eran totalmente incapaces de estimar cuánto tiempo tomaría un proyecto por parte de las personas que realmente lo implementaron.
La investigación de Rand Corporation en la década de 1940 mostró claramente que los humanos no son buenos para estimar horas y la experiencia práctica confirma repetidamente la investigación. El enfoque Delphi recomendado para la estimación que se adoptó en el desarrollo de software como la técnica Delphi de banda ancha. La misma técnica ahora está integrada en la práctica llamada Planning Poker para equipos ágiles.
Una empresa de CMMI Nivel 5 determinó que la estimación de punto de historia reduce el tiempo de estimación en un 80 %, lo que permite a los equipos realizar más estimaciones y seguimiento que un equipo de cascada típico.
Una empresa de telecomunicaciones notó que los puntos de historia estimados con el póquer de planificación eran 48 veces más rápidos que las prácticas de estimación en cascada en la empresa y dio estimaciones tan buenas o mejores.
Una explicación clásica sobre Story Points: una medida de esfuerzo (tiempo). Este artículo tiene 4 años y hemos estado haciendo ágil durante casi 20 años, pero aún así la gente malinterpreta los puntos de la historia. A menudo he escuchado puntos de la historia basados en el Esfuerzo o la Complejidad. Sin embargo, siempre se trata del esfuerzo y la complejidad influye en el esfuerzo. Creo que el ejemplo en este artículo pondrá fin a este debate (concepto erróneo): https://www.mountaingoatsoftware.com/blog/story-points-are-still-about-effort
El punto de la historia se trata de una estimación, pero lo que podría tomar 2 días para mí podría ser 1 día para otra persona. Así que estamos de acuerdo como una unidad común como 1 punto. Entonces puedo hacer 5 puntos en un sprint de 10 días y la otra persona 10 puntos. Eventualmente seré más experimentado y haré más puntos.
andres claro