Estimación

Por Mitch Lacey. Propietario, Mitch Lacey & Associates, Inc, firma consultora especializada en adopciones y mejoras de metodologías ágiles y de Scrum.

Enero de 2012

Mitch Lacey describe la dificultad de estimación en torno a un proyecto de software y proporciona consejos para usar dos técnicas de estimación de estimación de software Agile cuando se estiman proyectos.

Se aplica a

Administración del ciclo de vida de la aplicación; Team Foundation Server

Contenido

• Introduction

• Por qué es difícil hacer estimaciones

• Técnicas de estimación

• Puntos de caso como unidad de medida

• Planeación de póquer

• Estimación en el muro

• Estimación

• Asignación de prioridades

• Conclusión

Estimar el trabajo que es creativo e imprevisible es muy duro. Elegir una manera de hacerlo puede igualmente complicado. Fred Brooks lo dice mejor: “Es muy difícil presentar una defensa sólida, plausible y arriesgada de una estimación que no derivada de métodos cuantitativos, respaldada con pocos datos y certificada principalmente por presentimientos de los directivos”.

Aun así, se nos pedían estimaciones para los proyectos de software con antelación y en las primeras etapas y, a pesar de todos nuestros esfuerzos para recordar a la administración que estas estimaciones son aproximadas, es muy frecuente que nuestras estimaciones iniciales se conviertan en compromisos.

En este caso, le mostraré por qué es complicado estimar proyectos por adelantado, cómo ayudan las técnicas de estimación del Software Agile y cómo estimar el trabajo pendiente del producto usando planeación de póquer y puntos de caso.

Por qué es difícil hacer estimaciones

En la mayoría de los proyectos, hay que hacer estimaciones con antelación. Para saber por qué esto es un problema, debemos examinar el Cono de incertidumbre, que Barry Boehm introdujo para nosotros en 1981 y que Steve McConnell reintrodujo en 1997 en su libro Software Project Survival Guide.

El cono muestra que no tenemos absolutamente ninguna certidumbre al principio de cualquier proyecto (una desviación de 4x a 0,25x en el intervalo). Esta varianza significa que lo que estimamos que será un proyecto de un año podría acabar teniendo cualquier duración entre 3 y 48 meses. El principio de cualquier proyecto es el momento en el que estamos menos seguros sobre el proyecto, pero también es cuando se nos solicitan previsiones muy precisas.

En Agile, se intenta pasar de la incertidumbre a la certeza lo más rápido posible. Esto se logra maximizando el aprendizaje temprano del sistema y cómo se debería diseñar. Para ello, creamos una sola ruta por el sistema, un caso completo que funciona. Lo utilizamos para vaciar los supuestos de requisitos y de diseño en una fase temprana, lo que nos permite acercarnos a la certeza mucho más rápidamente y con mucha más confianza.

Técnicas de estimación

Existe una gran variedad de técnicas válidas de estimación, como contar, opinión de expertos (individuos y grupos), descomposición, analogía, estimación de proxy, planeación de póquer y estimación en el muro. También podemos utilizar herramientas como Cocomo II. Todas estas técnicas requieren que elijamos una unidad de valoración (horas, días, semanas, meses, días ideales, ajuste de tamaño de camisetas, puntos) o todas ellas. Si no comprendemos la unidad, la estimación no significa nada. En la vista de todo esto, no es de sorprender por qué luchamos con la valoración.

Aunque los equipos ágiles graviten hacia un determinado tipo de unidades de estimación y técnicas de estimación del trabajo pendiente del producto (puntos de caso y planeación de póquer), el equipo debe poder elegir libremente el método que mejor se adapte a sus necesidades. Según mi experiencia, expresar estimaciones en términos de puntos de caso, usando la técnica de planeación de póquer o la estimación del muro, produce los mejores resultados. En los párrafos siguientes, obtendrá información sobre los puntos de caso como una unidad de medida y sobre dos técnicas de estimación que me gustan: planeación de póquer y estimación del muro.

Puntos de caso como unidad de medida

Mike Cohn es el que mejor resume los puntos de caso: “Los puntos de caso son la unidad de medida para expresar el tamaño total de un caso de usuario, característica u otro elemento de trabajo. ” Los puntos de caso nos indican la relevancia de un caso, en relación con otros, en términos de tamaño o complejidad. Mike se refiere a menudo a los “puntos de perro” cuando ayuda a los equipos entender el concepto de tamaño relativo. Un perro de 2 puntos (pequeño) sería un Chihuahua. Un perro de 13 puntos (grande) sería un Gran Danés. Teniendo presentes esas dos guías, resulta fácil calibrar el tamaño las otras razas de perros en relación con un chihuahua o un gran danés. Un Beagle, que es el doble de grande que un Chihuahua, podría ser 5. Un Labrador, que es mayor que un Beagle pero menor que un Gran Danés, podría ser 8.

Si está aprendiendo a utilizar puntos de caso, el equipo necesitará establecer sus propios puntos fijos de comparación. Para ello, elija un caso del trabajo pendiente del producto en el que todos coincidan que es pequeño (en términos de tamaño o de complejidad) y uno en el que todos coincidan en que es enorme. Me gusta que mi caso particular se un caso de dos puntos porque, si necesito ir desglosarlo más (por ejemplo, descubrir un Chihuahua de juguete), puedo hacerlo. Si limito el caso más pequeño que tengo a un caso de un punto y necesito que se menor, tendré problemas. Los otros casos se pueden ajustar de tamaño en relación con estos.

Cuando se trata de elegir números para representar estos tamaños, he descubierto que la secuencia de Fibonacci es la mejor. Fibonacci es la suma de los dos números anteriores. De forma que si hay 1 y 2, el siguiente es 3. 3 y 2, el siguiente es 5. 5 y 3, el siguiente es 8, y así sucesivamente. Prefiero Fibonacci antes que, por ejemplo, una camiseta cuya talla aumenta exponencialmente (4/8/16/32/64/128/256, etc.) porque los seres humanos son buenos en la base diez. Cuando salimos de ese intervalo, aunque estemos en él con, por ejemplo, xs, s, m, l, xl, se vuelve más confuso. Los números de Fibonacci son sencillos, de fáciles de comprender y aportan la precisión suficiente para llevarnos al objetivo, aportando estimaciones relativas. Puede elegir un conjunto de números distinto, pero recuerde que lo importante es ser coherente.

Los puntos de caso son valores relativos, no fijos. No hay ninguna correlación directa entre las horas y los puntos. Por ejemplo, no se puede decir con algún grado de certeza que un caso de dos puntos sea igual a 12,2 horas porque los casos del intervalo de dos puntos variarán considerablemente en el número de horas reales que lleva completarlos. De igual forma, no puede comparar los puntos de caso un equipo con los de otro con algún grado de certeza. Los puntos de caso los crea el equipo que realizó las estimaciones y son específicos de él; además, probablemente incluirán un grado de complejidad que solo comprenderá el grupo, y no son absolutos.

Planeación de póquer

Después de haber elegido la unidad de medida y establecido su escala, es la hora de realizar los cálculos. La mayoría de los equipos de Agile usan la planeación de póquer para calcular el tamaño relativo de los casos. Es muy conocido entre los equipos de Agile porque es una medida objetiva que incluye varias técnicas subjetivas de estimación, lo cual incluye un opiniones de analogía y de expertos. La clave para la planeación de póquer es la participación. Todos los miembros del equipo necesitan participar (sí, todos). Los evaluadores funcionales estimarán las tareas de desarrollo y viceversa. Los jefes de proyecto funcionales también podrían estimar las tareas de desarrollo. Esto garantiza que los números objetivos incluyan la valoración más subjetiva posible.

Comience con un conjunto de cartas de planeación de póquer. Las cartas de planeación de póquer pueden confeccionarse fácilmente con cartas de índice, realizadas para que sean cartas de juego o pueden comprarse (incluso Visual Studio las confecciona). Cada tarjeta tiene uno de los números en el intervalo elegido de puntos de caso (1, 2, 5, 8, 13, etc.). Cada participante trata con toda la gama de los puntos de caso disponibles.

Después de que se distribuyan las cartas, el juego se inicia.

1. El ScrumMaster muestra el elemento superior en el trabajo pendiente del producto al equipo.

2. El equipo discute el caso.

3. El propietario del producto aclara las preguntas, los supuestos y los aspectos desconocidos, así como los criterios de aceptación.

4. Cada miembro del equipo decide en privado la magnitud de este caso en relación a un caso, a una serie de casos de referencia o a todos los casos en el trabajo pendiente del producto.

5. Cuando se cuente tres, todo el mundo muestra a la vez la tarjeta elegida.

Si todo el mundo jugó la misma carta, el equipo puede registrar la estimación y pasar al siguiente caso.

Si hay una desviación grande (por ejemplo, los números mostrados se extienden van de uno a ocho), el equipo pasará tiempo debatiendo sobre el caso. Para centrar la discusión, pida al mejor y al peor postor que expliquen en qué basan sus estimaciones. La conversación es lo que tiene valor aquí, no el número, porque es donde se produce el aprendizaje y se destapan todas las suposiciones. Después de un breve debate de 30 segundos a 1 minuto, el equipo repite los pasos 4 y 5. Esto continúa hasta que el equipo llegue a un acuerdo sobre una estimación para el caso.

Esto es relativamente sencillo, pero es importante entender algunas reglas básicas. Primero, si los miembros del equipo no llegan a un acuerdo, no debería seguir adelante. Por ejemplo, supongamos que hay una persona del equipo que reproduce un ocho pero las otras elijen todas un cinco. Si el organizador de la reunión dice: "Suficientemente cerca. Aceptamos el cinco; adelante,” ¿qué hará la persona que sacó el ocho? Según mi experiencia, esa persona hará lo que decida el equipo pero dejará de participar plenamente. La planeación puede ir más rápidamente de esa forma, pero ha perdido algo valioso. No solo esta persona se perdió en la descripción del trabajo, además el equipo pierde los comentarios y perspectiva de un miembro. Además, está bien discrepar. Las discusiones sobre por qué una persona eligió un número más alto que el resto proporcionan un valioso conocimiento. Si ha llegado a un punto muerto, haga que el organizador intente la técnica “Fist to Five” (los miembros de un equipo levantan la mano y pueden mostrar desde el puño, cuyo valor es cero, hasta los cinco dedos para indicar el valor máximo de cinco). Funciona a las mil maravillas desarrollar reuniones sin alienar a los participantes.

Dado que la planeación del póquer expresa estimaciones en puntos, se adapta perfectamente para estimar el trabajo pendiente del producto. Sin embargo, el trabajo pendiente del sprint se debe estimar en horas. Dicho esto, la planeación de póquer puede utilizarse y se ha utilizado para calcular trabajos pendientes del sprint; los números de la carta serán horas, no puntos. Por lo tanto, una regla sencilla –

• Las estimaciones del trabajo pendiente del producto están en puntos.

• Las estimaciones del trabajo pendiente del sprint son en horas.

Puede utilizar la planeación de póquer al principio de cualquier proyecto y a lo largo de su ciclo de vida, a medida que aparezca nueva información, cambien las prioridades y surja la claridad.

Estimación en el muro

La planeación de póquer es una herramienta fantástica para estimar casos de usuario, pero lleva un tiempo excesivo calcular centenares de casos, uno de cada vez, usando la planeación de póquer. Si tiene un trabajo pendiente sin formato rellenado con centenares de casos que no se han estimado ni se han establecido sus prioridades, va a necesitar una manera más rápida de estimación.

La estimación en el muro está diseñada para permitir que los equipos eliminen debates de 2 contra 3 y 5 contra 8, y en su lugar agrupar las cosas de una manera puramente relativa a lo largo de una secuencia, por lo menos inicialmente. También permite que las partes interesadas proporcionen unas prioridades generales a un grupo grande de casos sin quedarse anclado en si un caso es ligeramente más importante que otro.

Para hacer la estimación en el muro, primero debe imprimir los casos de usuario en tarjetas. A continuación, reúna al equipo y a las partes interesadas en una sala que tenga un gran muro vacío (de unos 4 metros de largo por unos 2,5-3 metros de alto). Tenga presentes dos cosas sobre el muro:

• El alto determina la prioridad. Los casos de la parte superior tienen mayor prioridad que los de la parte inferior. La prioridad de un caso se basa en la rentabilidad de la inversión, el valor comercial o en algo tan sencillo como “simplemente es importante, y no sé por qué”.

• El ancho se reserva para el tamaño. Los casos de la izquierda son más pequeños que los de la derecha. (Puede invertir esto y desplazarse de derecha a izquierda si está, por ejemplo, en Japón y resulta más lógico.) Lo importante es imaginarse una línea desplazándose en horizontal y otra en vertical. Los miembros del equipo y las partes interesadas deben preguntarse a sí mismos dónde encaja este caso, en relación con los otros.

El equipo utilizará el muro para calibrar todos los casos. Las partes interesadas utilizarán el muro para dar prioridad a los casos. Como con la técnica de planeación del póquer, estamos usando el tamaño relativo, pero en lugar de usar dos casos de referencia para la comparación, la pared se convierte en la constante. ¿Caso pequeño? Desplácese a la izquierda. ¿Gran caso? Desplácese a la derecha. ¿Caso importante? Colóquelo alto. ¿Podemos vivir sin este caso por el momento? Colóquelo bajo.

Aunque las partes interesadas no tienen que estar presentes mientras se estiman los casos, el equipo debe estar en la sala mientras se clasifican los casos según su prioridad. El ScrumMaster y el propietario del producto deben asistir a las actividades de estimación y asignación de prioridades.

Ahora, si ya tiene un trabajo pendiente estimado, puede hacer simplemente la parte de asignación de prioridades de este ejercicio. Si los propietarios del producto y las partes interesadas ya se le han conferido un trabajo pendiente con la prioridad establecida, puede hacer simplemente la sección de estimación de este procedimiento. (El propietario del producto probablemente querrá volver a visitar la asignación de prioridades tras la realización de las estimaciones. Después de todo, el costo tiene un gran impacto en la en prioridad.) Observemos en detalle cómo funciona esto, empezando por el rol del equipo.

Estimación

Facilite al equipo el trabajo pendiente del producto sin procesar y empiece con la estimación. Indique al equipo que el extremo izquierdo de la muro debe contener los casos más pequeños posible y el extremo derecho los más grandes, independientemente de los números. El equipo coloca los casos en alguna parte del muro basándose en esos dos polos. La ventaja de hacerlo de esta forma es que no hay ninguna noción preconcebida de lo que es un caso de dos o tres puntos; es relativo en función del tamaño del muro, por lo que un muro realmente grande resulta práctico.

Si el equipo tiene dificultades para hacer esto, puede proporcionar más estructura al muro proporcionando casos adicionales de referencia que vayan de 1 a 8 puntos. No se preocupe por crear un caso mayor de referencia; cualquier cosa más grande será normalmente desglosada según va aumentando su prioridad. Una vez que el equipo haya identificado los cinco casos, colóquelos en la pared en una ubicación que se corresponda con sus tamaños (de nuevo desplazándose de izquierda a derecha). Deje sitio en la parte derecha del muro para casos superiores a ocho puntos. Coloque estos casos en el muro e indique al equipo que coloque los casos restantes en el muro relativo a estos casos de referencia, teniendo presente que los casos más pequeños van a la izquierda y los casos mayores van a la derecha.

Con los casos en el muro, pida al equipo que identifique las interrupciones lógicas entre los tamaños de los casos. Trace una línea vertical entre los grupos de casos para mostrar estas interrupciones. Pronto tendrá un muro con un aspecto similar al mostrado aquí. Todo en el primer grupo podría ser un 2; todo el segundo, un 3; todo el tercer grupo, un 5; y todo el último grupo, un 8. Los números no importan tanto como el hecho de que todos los casos ahora se calculan en relación unos con otros.

Ahora que ha estimado sus casos, deberá implicar a las partes interesadas para poder asignar una prioridad a los casos.

Asignación de prioridades

Aunque sus clientes y partes interesadas desearán saber la importancia de un caso para ayudarles a determinar la prioridad, estarán mucho más centrados en buscar casos relacionados con ellos y en asegurarse de que esos casos se completen. Espere a que las partes interesadas discrepen sobre las prioridades; el propietario del producto usará esta información para ayudar a decidir la prioridad final.

Describa el muro a las partes interesadas. Dígales que las cartas de la pared reflejan todas las características que desean ver en el producto final. Explique que el equipo ya ha estimado cada caso y que pueden determinar la estimación del punto para un caso basado en la columna que esté en el muro. Recuerde a todo el mundo que los miembros del equipo no son participantes activos en la asignación de prioridades. Están allí para observar, tomar notas de comportamiento, interacciones y las razones por las que ciertos casos adquieren o pierden prioridad. También pueden responder cualquier pregunta de las partes interesadas si es necesario. Si el equipo no puede calibrar uno o más casos con confianza porque requería respuestas de una parte interesada concreta, el equipo puede hacer preguntas acerca de esos casos, según el tiempo lo permita.

Pida a las partes interesadas que ayuden a determinar la prioridad relativa de todos estos casos moviendo estos casos en dirección ascendente o descendente dentro de las columnas insertadas. Recuérdeles también que cuanto más alto esté un caso en el muro, mayor prioridad tiene para la empresa. Establezca las reglas siguientes:

• Si coloca un caso en la parte superior, esté preparado para justificar esa colocación.

• Pueden preguntarse unos a otros por qué un caso es más importante que otro. No dude en preguntarse mutuamente, “¿Quién la movió para abajo (o para arriba?” o decir en voz alta: “Creo que hay que mover esta. ¿Quién no está de acuerdo?” Esto permite la conversación entre las partes interesadas, sin que sea necesario promoverla.

• Si desplaza un caso en sentido descendente en el muro que realizó algún otro, márquelo con un punto de color a modo de alerta.

La mayor ventaja a la que se debe dar prioridad como grupo es a que todas las partes interesadas puedan entender mejor las prioridades de varios casos. Si una discusión se prolonga demasiado sin resolverse, el propietario del producto debe recuperar la carta, identificar la dos partes interesadas que no se pueden poner de acuerdo y redactar una nota para reunirse con ellos en privado más adelante.

El ejercicio puede tardar 2-6 horas, dependiendo del número de casos y del número de partes interesadas. Cuando termine, el muro tendrá un aspecto similar al de la imagen que se muestra a continuación.

El muro se dividirá aproximadamente en cuatro cuadrantes. Los casos de la parte superior izquierda son pequeños y tienen gran prioridad, por lo que terminarán en las primeras posiciones de la lista de trabajo pendiente del producto. Los casos de la parte superior derecha tienen gran prioridad, pero también son grandes. Estos casos se deben dividir pronto para poder incluirlos en futuros sprints.

El cuadrante de la parte inferior izquierda se compone de pequeños casos con menor prioridad. Probablemente caerán a la parte más baja de la lista de trabajo pendiente. El cuadrante de la parte inferior derecha se rellena con casos grandes que también son de menor prioridad. Estos casos son las epopeyas o temas. Al final deberán dividirse en casos más pequeños y manejables, pero no antes de que aumente su prioridad.

Pase algún tiempo observando el muro en su conjunto con el grupo. Si un caso está en el cuadrante incorrecto, muévalo. Si un caso de prioridad alta debe desglosarse y el tiempo lo permite, hágalo mientras todos están en la sala.

Al final de la valoración del muro, tendrá el inicio de un plan de la versión. Si conoce la velocidad histórica del equipo, incluso puede proporcionar un intervalo aproximado de qué casos en el cuadrante superior izquierdo se completarán.

La estimación es difícil porque hay mucha incertidumbre al principio de un proyecto. Los propietarios del producto y administradores de proyectos Agile intentan maximizar el valor mediante conversaciones los propietarios del producto y las partes interesadas, la generación de software que funcione y la integración de comentarios sobre ese software para llegar a la fase de lanzamiento. Pero incluso los proyectos Agile deben proporcionar alguna valoración sobre cuándo un conjunto de características estará listo para su lanzamiento.

Las dos técnicas de estimación que recomiendo son planeación de póquer (adecuada para conjuntos de casos más pequeños) o estimación en el muro (apropiada para administrar grandes listas de trabajos pendientes del producto sin procesar). Cualquiera de ellos le dará los datos que necesita comenzar a plantear un plan, que es el objetivo final de la valoración.

Vea también

Conceptos

Colaborar [redirigido]

Colaboración (Profundizar más) [redirigido]

Crear el trabajo pendiente

Repasar y estimar el trabajo pendiente

1. Mike Cohn, Agile Estimating and Planning, página 36

2. Toma de decisiones por consenso: señales con las manos (Wikipedia)