Estimaciones
Última actualización
Última actualización
Una vez que tenemos esta primera versión del Backlog, necesitaremos saber cuán grande es el producto a construir para estimar el costo y también para planear un equipo que, teniendo en cuenta las restricciones de tiempo y dinero, lo desarrolle.
Hacemos la estimación inicial de la manera más rápida y eficiente posible, sin perder tiempo en adivinanzas y especulaciones, usando la técnica de Planning Poker para asignar Story Points a cada una de las User Stories descubiertas. Noten que estimamos incrementos de funcionalidad visibles. Esto es fundamental para la posterior gestión del proyecto, ya que medimos el progreso del mismo en base a funcionalidad terminada.
Deberemos arriesgar el tiempo que involucraría 1 Story Point, para inferir cuánto nos llevaría completar todo el proyecto. Esta primera estimación carga con mucha incertidumbre, ya que se hace con poca información (tanto del negocio como de la parte técnica posiblemente). Usaremos esta estimación para construir el plan inicial, pero será fundamental durante las primeras semanas entender mejor la dimensión del producto y también la capacidad real del equipo (Velocity).
He mencionado unos cuantos conceptos sobre los que, desde mi punto de vista, vale la pena profundizar. En las secciones que siguen, les contaré más sobre estimaciones relativas, Story Points, Planning Poker, la Velocity y sobre cómo usamos estos conceptos para el planeamiento y la gestión del proyecto.
Durante muchos años de mi vida realicé estimaciones en tiempos absolutos. Para hacerlas, desagregaba los componentes que, entendía, debían desarrollarse y asignaba tiempos (que luego sumaba) para cada uno de ellos. Usé puntos de función y complejas planillas de cálculo creadas dentro del marco de estándares de calidad como CMMI (que procuraban tener métodos estandarizados para la organización). Ninguna de estas técnicas resultó, en mi experiencia, en estimaciones precisas, generando siempre comportamientos disfuncionales que terminaron siendo perjudiciales para la organización. Un ejemplo que todos conocerán es el que consta en agregar un "padding" a la estimación, para "cumplir" con los tiempos. ¿Les parece que tiene sentido?
Cuando empecé a trabajar con Scrum, descubrí el concepto de estimaciones relativas usando Story Points. Con esta técnica, no estimamos cuánto esfuerzo demanda completar una User Story, sino cuánto demanda una con respecto a otra. Asignamos puntos, que llamamos Story Points, como resultado de estas comparaciones relativas. Así, una User Story que tiene asignado 2 requerirá el doble de esfuerzo que otra de 1 y 2/3 de una tercera de 3. Estos puntos amalgaman todos los factores que pueden influir en el esfuerzo, entre los que puedo nombrarles[Cohn]:
Cantidad de Trabajo: ¿Es un formulario con 3 o 10 campos? ¿Involucra mucho testing?
Incertidumbre: ¿Conocemos el negocio? ¿Las funcionalidades están cerradas o hay puntos abiertos? ¿Es una tecnología que conocemos o es nueva y no tenemos experiencia? ¿Tenemos que interactuar con servicios desconocidos?
Complejidad: Volviendo al ejemplo del formulario, ¿los componentes usados son sencillos? ¿Involucran validaciones? ¿Están interrelacionados?
Los valores que pueden ser usados como Story Points pertenecen a una escala discreta, por ejemplo, la Sucesión de Fibonacci. Limitarnos a valores discretos simplifica notablemente el proceso. Cuando estimamos de esta manera, podemos imaginar que tenemos baldes que representan cada uno de los valores y luego decidimos a cuál asignar cada User Story. De este modo, evitamos discusiones que aportan muy poco valor, como si debiéramos asignar 2.5 o 2.7. ¡No disponemos de tanta información como para ser tan precisos! Los valores discretos incorporan intrínsecamente este grado de incertidumbre. La sucesión de Fibonacci es particularmente intuitiva en este sentido, ya que las distancias entre los números de la sucesión crecen a medida que los números se vuelven más grandes.
Si bien es bastante frecuente usar Story Points, estos no son fundamentales dentro del concepto de estimaciones relativas. Pueden usar talles de remera, como en el gráfico que se encuentra abajo, o cualquier otra medida. El punto es que cada número, por sí mismo, carece de sentido. Toma sentido cuando se mide en comparación con otro.
¿Por qué usamos estimaciones relativas? La primera razón es que vuelven el proceso más sencillo y liviano, ya que no nos detenemos en tratar de adivinar lo que no conocemos o en investigaciones que haremos cuando empecemos a trabajar. Además, las estimaciones relativas nos desplazan de razonamientos tales como "esta User Story la desarrollará una persona determinada por sus skills o seniority" que no tienen ningún sentido. Simplemente decidimos, como equipo, cuanto más grande o más chica es una User Story con respecto a otra. La segunda razón es que realizar las estimaciones de esta manera nos protege de cualquier intento de presión (por parte de Jefes/Project Managers, etc.) a través de la existencia de este nivel nuevo de indirección. Estas presiones siempre generan, como ya mencioné, conductas que no son beneficiosas para nadie.
Un punto a tener en claro, antes de estimar, es qué significa completar una User Story. No basta con haber "codeado" la funcionalidad. Debemos, como mínimo, ejecutar exitosamente todos los casos de prueba y el Product Owner debe validar y aceptar la User Story. Además, deben existir tests automatizados para toda la nueva funcionalidad, que cobrarán vital importancia para su posterior regresión.
Todos estos puntos, y quizás algunos otros que se agreguen para algún proyecto u organización en particular, constituyen la definition of done. No tiene sentido escribirlos en cada User Story porque están implícitos, aplican a todas. Es muy importante que todo el equipo entienda lo mismo. En otras palabras, que para todos signifique lo mismo completar una User Story. Una actividad que podemos realizar, para asegurarnos de ésto, consiste en armar un afiche con la lista de los criterios definidos. Una vez creado, podemos pegarlo cerca de nuestros escritorios, para que funcione como un radiador de información.
Usamos esta técnica para asignar estimaciones a las User Stories. Para ello, invitamos a todo el equipo que participará del proyecto (desarrolladores, testers, diseñadores y product owners), entregándoles mazos similares al que se encuentra abajo, donde cada una de las cartas representa un número de Story Points:
La explicación del funcionamiento de esta técnica yace en la teoría de la sabiduría de las masas, que argumenta que la participación de todo el equipo incrementa la precisión de las estimaciones al escuchar las perspectivas de todos los integrantes. Que una persona sola, por más que sea un experto, realice todas las estimaciones implica un riesgo mucho mayor ya que es muy probable que omita factores poco visibles en su rol.
El proceso para hacer las estimaciones con esta técnica es el siguiente:
El Product Owner describe la User Story, qué desea lograr y cómo aportará valor.
Se debate brevemente. ¿Qué implica? ¿Qué riesgos existen? Escuchar las diferentes perspectivas es fundamental para enriquecer las nuestras.
Se deja un momento para que cada persona piense y elija su carta.
A la cuenta de 3, todos al mismo tiempo mostramos la carta seleccionada: ¡No queremos que nadie se sienta influenciado!
Contamos cuántas personas eligieron cada carta. En general, la distribución es una campana de Gauss, ya que la mayoría suele elegir un valor y sólo unos pocos eligen uno superior o inferior.
Es bueno escuchar a los outliers, es decir, aquellas personas que tienen estimaciones muy bajas o muy altas ya que pueden tener información que el resto desconoce u omite. Por supuesto que también pudo desconocerse o malinterpretarse algún punto de la User Story. De igual modo, resulta relevante escuchar sus argumentos y, en base a ellos, decidir si se desea repetir la estimación.
¡Siempre llegamos a un consenso! Al menos, es mi experiencia. Que los valores sean discretos ayuda mucho. Después de todo, sólo estamos decidiendo cuántos Story Points asignar a una User Story y no cuántos días vamos a tardar en completarla.
Para finalizar esta sección, les contaré el proceso que usamos para estimar un conjunto de User Stories, que podría llegar a ser el Backlog completo o sólo el próximo release (personalmente no creo que valga la pena hacer una estimación de más de 2 meses de trabajo).
Empezamos por seleccionar una User Story que esté entre las prioritarias y que consideremos de las más pequeñas del Backlog y le asignamos 1 punto. Luego estimamos, usando Planning Poker, la primera User Story, es decir la que está en el primer lugar del Backlog, estableciendo una comparación con la precedente a la que habíamos asignado 1 punto.
Una vez establecida una estimación para la segunda User Story, seguiremos con la tercera, la cuarta y así sucesivamente. Durante los comienzos, puede llegar a surgir la necesidad de algunos ajustes, pero puedo asegurarles que el sistema se estabiliza muy rápidamente y estas primeras estimaciones establecen el parámetro para todos las User Stories que restan en el Backlog (y para todas las que se descubran en el futuro).
Como ya lo mencioné, no creo que tenga sentido invertir una cantidad exagerada de tiempo en esta actividad. Si ya definimos el Producto Mínimo Viable (hablaremos sobre este concepto que llamamos MVP en la próxima sección), nos limitaremos a estimar solamente sus User Stories. Si el MVP fuera demasiado grande, sería bueno partirlo en releases. Debe tenerse en cuenta que, mientras más User Stories estimemos, mayor será el riesgo de perder el tiempo en ítems que después no sean construidos. Tampoco vale la pena invertir tiempo para comprender cada User Story en profundidad. Una técnica que empleo habitualmente, para no extenderme, consiste en delimitar el tiempo que se va a usar para la estimación de cada User Story (5 minutos puede ser adecuado). Otra opción consiste en, de ser el equipo numeroso, repartir las User Stories entre 2 grupos para que puedan hacer las estimaciones en paralelo dando lugar a la exposición de los resultados.
Para comenzar un proyecto, se debe tener una idea de la dimensión del producto a construir, principalmente para conocer el costo y para poder planificar en base a él.
Para hacer la traducción de los Story Points del Backlog a una unidad de tiempo, simplemente estimamos 1 Story Point con el equipo que elegimos infiriendo, de este modo, el tiempo total del Backlog.
Visualicemos esto mediante un ejemplo. Imaginen que estimamos nuestro Backlog inicial en 75 Story Points y pensamos en un equipo de 3 personas para desarrollarlo. El paso siguiente sería estimar cuánto nos llevaría completar 1 Story Point con este equipo.
Por cuestiones de simplicidad, podríamos estimarlo en 1 día. Es decir, que proyectamos completar 1 Story Point por día.
De este modo, demoraríamos 75 días en terminar o alrededor de 8 iteraciones de 2 semanas (10 puntos por iteración). Podríamos incluso inferir, siendo que tenemos nuestro Backlog priorizado, qué funcionalidades entregaríamos en cada una de las iteraciones para planificar de acuerdo a esto. No es una actividad en la que encuentre demasiado valor, por lo que no la fomento.
Si quisiéramos hacer un presupuesto, deberíamos multiplicar este número por la cantidad de personas en el equipo y éste, a su vez, por la cantidad de horas que, en promedio, trabajan esas personas.
En nuestro ejemplo:
Podríamos pensar que existe una similitud entre las horas descritas y las horas-hombre de la gestión tradicional de proyectos, pero no son exactamente lo mismo. La diferencia, sutil, radica en que las estimaciones para cada una de las User Stories se basan en un equipo, mientras que para la gestión tradicional de proyectos se trata de estimaciones del tiempo que demora un "recurso" en completar una actividad.
Al comenzar a trabajar, mediremos la cantidad de Story Points que podemos terminar en cada iteración, lo que nos dará una pauta de la verdadera capacidad del equipo. Llamamos a ésto Velocity [Cohn], que es un término que proviene de la física y que incluye la celeridad y la dirección.
Midiendo la Velocity de la primera iteración, podríamos inferir, con más información que antes de empezar, cuánto nos queda por delante. Sigamos con el ejemplo de la sección anterior e imaginemos que el equipo completa 2 User Stories: una de 5 puntos y otra de 3. La Velocity será entonces de 8 puntos. De los 75 puntos estimados, completamos 8 (en la jerga decimos "quemamos 8" y ya veremos la causa), o sea que nos quedan 68. Podemos inferir entonces que, si seguimos con esta Velocity, necesitaríamos 8.5 iteraciones (68 / 8) para terminar.
Al completar la 2da iteración y medir la Velocity, dispondremos de mayor información, ya que podremos obtener un promedio de las velocities de las 2 primeras iteraciones. Por ejemplo, si hubiera sido igual a 6, el promedio de las 2 iteraciones sería igual a 7, lo que nos indica que necesitaríamos 8.8 iteraciones más para terminar.
Para visualizar la Velocity, podemos usar el gráfico de Burndown:
En este gráfico, el eje "Y" indica la cantidad de puntos por quemar y el "X" muestra el tiempo.
En este ejemplo, sobrestimamos nuestra capacidad (o subestimamos la complejidad del proyecto). Con esta información, debemos actualizar nuestro plan: ¿Podemos extender la fecha de entrega? ¿Podemos acotar el scope, dejando algunas funcionalidades para un release posterior? ¿Podríamos aumentar la Velocity sumando a un integrante más? La confianza y la colaboración existentes entre los miembros del equipo permiten dar lugar a estas conversaciones.
Mike Cohn dice que la Velocity es el gran ecualizador, ya que nos permite actualizar nuestro plan automáticamente. Mientras que las estimaciones relativas sean consistentes, la medición de la Velocity nos permitirá inferir un calendario actualizado sin necesidad de efectuar ningún tipo de re-estimación.
Me gustaría contarles, para finalizar, cuáles son los puntos fundamentales del enfoque ágil en mi opinión. No son los Story Points, ni el Planning Poker, sino el proceso que usamos para estimar. En resumen:
Se hacen sobre User Stories, es decir, sobre incrementos de funcionalidad visibles al usuario final. El progreso, posteriormente, será medido en base a esto.
No se invierte mucho tiempo en hacer un análisis detallado para hacer la estimación, porque la precisión que presumiblemente se podría alcanzar no justifica la inversión. Esto no significa que las estimaciones dejen de hacerse por completo ya que es necesario tener una noción del tamaño para hacer la planificación.
No implican un compromiso. La presión ejercida sobre el equipo, ya sea para acortar los tiempos o para cumplir con la fecha inicialmente estimada, es la principal causa de disfuncionalidad que conozco. Queremos evitar que el equipo sienta la necesidad de poner un pad a la estimación o quiera cortar camino para cumplir con las estimaciones y que consecuentemente agregue deuda técnica. Ninguno de estos comportamientos resulta beneficioso.
En esta sección estudiamos cómo hacer una estimación inicial del producto. Necesitamos tener una idea de la dimensión del mismo para poder planificar el equipo y proyectar tiempos (de acuerdo a los deadlines y expectativas del negocio). No deseamos, ni podemos, saber exactamente cuánto llevará. Tampoco, invertir demasiado tiempo en intentarlo, sin enfrentarnos con los problemas prácticos. No lo considero un buen uso del tiempo. Asumir un compromiso con esta información tampoco me parece razonable y es causa de muchas disfuncionalidades. Cuando comencemos a desarrollar, podremos verificar si las asunciones y estimaciones resultaron correctas, plasmando el conocimiento adquirido en nuestros planes. Usando Story Points y midiendo la Velocity, esto es automático.
