Estamos buscando cambiar nuestro enfoque sobre las estimaciones. Ahora estimamos en horas/días, pero nos gustaría cambiar esto y hacer que nuestro proceso sea más flexible. Estamos trabajando en base a Scrum, donde las historias se planifican en base a una estimación inicial y luego del análisis técnico se puede utilizar una nueva estimación (que es más refinada).
Debido a que notamos que nuestro proceso de estimación se puede mejorar, estamos buscando alternativas. Ya encontré documentación en línea sobre el uso de puntos de historia y velocidad para indicar el esfuerzo requerido para implementar algo.
¿Hay alguna alternativa además de los puntos de historia/velocidad? He estado buscando en línea, pero no puedo encontrar buenas fuentes con alternativas.
Para mí, parece que desea mejorar la precisión de su estimación, no hacerlo más flexible. Así que aquí hay algunos consejos.
Cuanto antes esté en el proyecto, menos precisa será su estimación. El cono de incertidumbre ilustra esto comenzando con una dispersión de 0,25x a 4x y convergiendo lentamente al factor de 1. Esta es la precisión máxima que puede esperar de sus estimaciones. Es decir. cuando comienza, no puede ser más preciso con su estimación, solo puede tener más suerte.
Menciono esto porque sus preguntas me suenan como si estuviera priorizando las historias en función de la estimación inicial, sin tener en cuenta ningún refinamiento. Sin embargo, podría estar equivocado acerca de esto.
En lugar de proporcionar estimaciones de un solo punto, ofrezca rangos. Comience por estimar el peor de los casos absolutos para su límite superior. Luego calcule el escenario "probable" para su límite inferior. Trate de establecer ambas estimaciones para que tenga un 90% de confianza de estar en lo correcto. Esto hace dos cosas: considerar primero el peor de los casos pone su mente en el camino de lo que puede salir mal y evita que asuma demasiados riesgos. En segundo lugar, si te obligas a expandir tus estimaciones a un rango extremo de confianza del 90 %, tendrás al menos un 30 % de posibilidades de acertar.
Siempre que sea posible, trate de evitar hacer estimaciones absolutas y trate de estimar elementos en relación unos con otros. Luego usa la velocidad para poner la cantidad de cosas completadas por sprint en relación con las estimaciones que le das. PUEDES hacer esto con horas si quieres. Es más natural si lo haces con puntos. Además, para conservar cualquier grado de confiabilidad, debe abstenerse de cambiar sus pesos relativos. Si estima su primer sprint sobre la base de que la Tarea X es Y horas/puntos y luego, después del sprint, mire su velocidad y diga "¡Ajá! Estábamos equivocados por un factor de 2.375, tengamos esto en cuenta para futuras estimaciones" te estás disparando en el pie.
Esencialmente, hay tres enfoques que puede tomar cuando necesita mover una pila de rocas:
Simulaciones de Montecarlo .
La idea es bastante simple. Tus historias de las semanas anteriores tendrán algún tipo de distribución en cuanto a cuánto tiempo tomó cada una. Digamos que las historias tomaron esta cantidad de días cada una hasta que se terminó la siguiente historia:
3, 2, 5, 4, 1, 2, 3, 10, ...
Estos a menudo siguen algo llamado distribución de Weibull , que está sesgada hacia una cola grande y gorda, ya que la mayoría de los descubrimientos lo ralentizan más de lo que lo aceleran. (La intuición humana tiende a asumir una distribución normal, que es una de las razones por las que generalmente somos optimistas).
A veces, aunque estas distribuciones son bimodales (hay algún sistema heredado que ralentiza cada historia que toca, por ejemplo) o simplemente desordenadas (nadie se registra un viernes porque no quiere romper la compilación). Lo bueno de las simulaciones de Montecarlo es... ¡no importa! Funciona independientemente de cuál sea su distribución.
La forma en que lo hace es calcular un viaje aleatorio a través de las historias que le quedan y encontrar cuándo termina ese viaje. Así que digamos que calculo que me quedan 60 historias. Para cada historia, elegiré el tiempo que transcurrió entre historias al azar de su distribución.
1, 5, 4, 10, 3, 2, 10, 2, 5...
Y sigues haciendo esto hasta que termines las 60 historias. Ahora agregue la cantidad de días que tomó hasta la fecha de inicio...
...Y luego hacerlo de nuevo.
Hágalo 1000 veces o más (sí, necesitará un software para esto o una hoja de cálculo especializada). No importa si ese extraño "10" se elige dos veces porque eso no sucederá en todos los viajes; algunos serán extrañamente lentos, pero la mayoría serán más rápidos. Registre las fechas de finalización de cada viaje.
Ahora tienes algo más que una estimación. Tienes un pronóstico probabilístico . Entonces, si empiezo el 1 de enero de 2018, podría obtener algo como:
100% 10-04-2018
95% 03-04-2018
90% 29-03-2018
85% 25-03-2018
etc.
Cada una de esas fechas muestra qué porcentaje de los viajes que realizó terminó para esa fecha. Esto le da una idea de la probabilidad de llegar a una fecha determinada con todas las historias. Alternativamente, puede ver cuántas historias ha terminado en una fecha determinada, solo contando hasta que se alcance la fecha.
La mayoría de las personas son realmente optimistas cuando hacen estimaciones, ¡y tienes suerte si alcanzas el 50% de los viajes que terminan en esa fecha!
Troy Magennis de Focused Objective tiene hojas de cálculo gratuitas para cosas como esta, y la herramienta de Dan Vacanti en Actionable Agile es lo suficientemente barata y, en mi opinión, excelente. Ambos también tienen numerosos videos que hablan sobre la técnica. También tengo un proyecto de código abierto que aún no tiene validación pero funciona lo suficientemente bien como para importar hojas de cálculo de Excel, incluidas las exportaciones de Jira.
Troy recomienda entre 7 y 25 semanas de datos para que esto funcione; más que eso suele estar desactualizado. Sin embargo, tenga en cuenta los patrones estacionales.
Estimaciones probabilísticas
Si no quiere pasar por la molestia de Montecarlo, pero sí quiere la distribución de probabilidad, una técnica que aprendí de Douglas Hubbard, autor de "Cómo medir cualquier cosa", podría ayudarlo.
Le pido al equipo que me dé una idea de cuándo creen que se enviarán. Por lo general, serán muy optimistas, por lo que si es a principios de enero dirán "Finales de abril", o algo así.
Luego les pregunto qué tan probable es que envíen en ese momento. “Ay, el 70%”, me dicen.
Así que les ofrezco un premio hipotético de £10,000 y dos formas diferentes de ganarlo. Pueden elegir una canica roja de una bolsa que contiene 7 canicas rojas y 3 blancas, o pueden enviarla a fines de abril.
Suelen ir a por las canicas; a pesar de decir que tienen un 70% de certeza de enviar, ¡prefieren las posibilidades de sacar 7 de 10 canicas!
Así que reducimos el número de canicas en nuestra bolsa hipotética hasta que prefieran enviarlas. Eso nos dice cuáles son sus niveles reales de confianza. Al hacer esto con diferentes números de canicas, podemos obtener un rango de diferentes niveles de confianza.
Cómo usar estos
Si depende de la fecha de envío de alguna manera, no use nada menos del 85% de confianza. Eso suele estar muy lejos en comparación con las estimaciones de la mayoría de las personas. A medida que se acerque la fecha, podrá ver si lo logrará o no, y aún tendrá la oportunidad de acelerar las cosas o cambiar otras dependencias si es necesario.
Tenga en cuenta que la empresa no estará contenta... hasta que comiencen a ver el tiempo ahorrado al no estimar en puntos de la historia fáciles de jugar y al no tener que rehacer un montón de planes basados en algo que de todos modos nunca iba a suceder. Es posible que deba educarse un poco o navegar por la política complicada hasta que acepten la realidad.
Sin estimaciones
Hay un movimiento bastante fuerte en contra de la creación de estimaciones. Al contrario del nombre, esto no significa que no se realicen estimaciones, sino que no se crean ni publican estimaciones.
Cómo funciona
Primero, el equipo debe conformarse con una historia de tamaño "promedio". Usaría una pauta como "Deberíamos poder hacer de 5 a 8 de estas historias en un sprint". Es útil tener 2 o 3 ejemplos de artículos anteriores que sean de este tamaño.
Ahora que tiene un tamaño de destino aproximado, desglose los elementos que son más grandes que eso hasta que coincidan cerca del tamaño. La idea aquí es que este proceso de estimación a medida eliminará las conversaciones beneficiosas en el equipo que genera la creación de estimaciones, pero dado que no hay números de estimación resultantes, evita muchas de las disfunciones y problemas que pueden surgir de la publicación de estimaciones.
La buena noticia para los propietarios de productos y las partes interesadas es que la previsión sigue siendo fácil. Si el equipo está completando de 5 a 8 elementos del backlog por sprint en promedio, puede adivinar cuántos sprints se necesitarán para llegar a un punto determinado en el backlog.
Si está practicando Scrum, debe ir con puntos de historia. Las razones son:
Dicho esto, déjame intentar responder a tu pregunta:
Ahora estimamos en horas/días, pero nos gustaría cambiar esto... ¿Existen otras alternativas además de los puntos/velocidad de la historia?
En industrias maduras, las estimaciones de alto nivel se realizan en función de la producción:
Aunque Scrum Guide no menciona los puntos de la historia, Jeff Sutherland, el cofundador de Scrum, es un gran defensor de los puntos de la historia . Una de las mayores debilidades de Scrum es que hay alguna unidad de medida para la entrada de esfuerzo, pero no hay una unidad de medida para la salida de resultados.
Existen organizaciones, estándares, herramientas y certificaciones bien establecidas para Function Point, que es una medida del resultado:
Organizaciones : en EE. UU., es el IFPUG International Function Point Users Group y en Europa , NESMA y FISMA, Asociación finlandesa de medición de software .
Estándares : puede ver los estándares ISO/IEC enumerados en la página Punto de función de Wikipedia .
with no attempt to measure the result output.Creo que "comprobable" a partir de los criterios INVEST (no Scrum, pero a menudo es una práctica sólida) y la función Sprint Review para proporcionar la evaluación de salida dentro del marco, pero ciertamente estoy de acuerdo en que el proceso de estimación en sí es principalmente impulsado por la entrada por diseño. ¡Muy buenos puntos, Ashok!¿Hay alguna alternativa además de los puntos de historia/velocidad?
Puede estimar en cualquier unidad que planee medir. Las medidas comunes incluyen tiempo, esfuerzo, dinero y objetivos basados en el calendario.
Los tres vértices del icónico "triángulo de hierro" de la gestión de proyectos son el alcance, el cronograma y los recursos. Todos los controles de proyectos y técnicas de estimación deben expresar uno o más de estos elementos, o las relaciones entre ellos.
La mayoría de los proyectos estiman los tres vértices, pero la teoría básica de la gestión de proyectos moderna es que solo puede controlar dos de los tres. No puede arreglar el alcance, la programación y los recursos simultáneamente; al menos uno de los tres necesita flexionarse.
Por ejemplo, podría estimar un proyecto en recursos y cronograma para llegar al alcance. También podría estimar el alcance y el cronograma para llegar a los recursos. Sin embargo, en general, a las empresas les preocupa más cuándo se puede entregar un proyecto, por lo que el tiempo y el esfuerzo a menudo tienen más sentido como técnicas de estimación primarias. Sin embargo, eso no significa que sean el único enfoque.
Algunas metodologías basadas en colas o ciclos no implican en absoluto una estimación basada en unidades. Por ejemplo, mientras que Kanban a menudo proporciona muchas métricas que pueden ser útiles para el seguimiento, la planificación de versiones y la mejora de procesos, los elementos de trabajo individuales nunca se estiman explícitamente.
Varios tipos de trabajo (por ejemplo, apoyo o mantenimiento) a menudo tampoco se estiman a nivel de unidad. Puede expresar dicho trabajo como una cola, un búfer circular o un cubo, pero en última instancia, todas estas son solo formas de planificar o presupuestar el trabajo a nivel macro en lugar de a nivel de unidad de trabajo.
Si desea evitar las estimaciones por completo, puede consultar el movimiento #NoEstimates . Sin embargo, Ron Jeffries tiene algunos pensamientos interesantes sobre eso, que creo que son de lectura obligatoria antes de subirse a ese tren en particular.
Debe evaluar y controlar su proyecto dentro de algunos parámetros básicos, y el tiempo y el esfuerzo son dos de los más comunes. Si desea alejarse de la estimación de horas-hombre o el nivel de esfuerzo, ciertamente puede hacerlo. Sin embargo, pasaría algún tiempo evaluando cuidadosamente su caso de negocios para hacerlo. Eso podría ayudarlo a descubrir una mejor métrica o ayudarlo a descubrir un problema X/Y que está impulsando la búsqueda de una alternativa. De cualquier manera, ¡tomarse el tiempo para introspeccionar sus suposiciones y su proceso generalmente es un tiempo bien invertido!
Que yo sepa, 'no'.
Las estimaciones de tiempo son el método intuitivo de estimación. Los gerentes quieren saber cuánto tiempo tomará X. ¿Solución intuitiva? Pregunte cuánto tardará X.
Hay, sin embargo, problemas con este enfoque. Por un lado, el tiempo necesario para lograr X variará dependiendo de quién complete X. Por otro lado, los humanos son malos para estimar el tiempo. Entonces surgieron los puntos de la historia, una forma de estimar en esfuerzo relativo. Desde entonces, se ha descubierto que están lejos de ser precisos. Se pueden convertir en tiempo aplicando la velocidad del equipo.
No creo que haya otro método, principalmente porque no veo qué más podría usarse de manera confiable. Tampoco veo la necesidad. Si necesita definir un proceso rápidamente y no quiere/no puede dedicar tiempo a pensarlo, calcule a tiempo. Si desea un método más preciso, use puntos de historia.
Editar: en el momento de escribir esto, me había olvidado del método 'sin estimaciones'. Aunque técnicamente se podría decir que tal método es el mismo que los puntos de la historia, solo que a cada tarea se le da el mismo esfuerzo. Incluso podría haber un continuo, con enfoques en los que todas las tareas se estiman de la misma manera, excepto por casos atípicos raros. Este es el enfoque en el que evolucionó mi último equipo: casi todas las Historias eran de 1 punto, con algunas Historias ocasionales de 0,1 o 3 puntos.
nvoigt
Daniel
Todd A. Jacobs