Categoría: planificación_proyecto

Introducción a la estimación y planificación ágil

Autor: Xavier Quesada Allue

 

Saber estimar y planificar es fundamental a la hora de encarar proyectos donde el producto necesita de un grado importante de creatividad y/o innovación, como por ejemplo los de desarrollo de software. En este artículo, presentamos algunos principios y prácticas introductorias para aprender a estimar y planificar un proyecto ágil.


Una de las características de la gestión de proyectos ágiles es el ser una actividad adaptativa en vez de predictiva. No es extraño, entonces, que los procesos de estimación y planificación en un proyecto ágil sean radicalmente diferentes a los de un proyecto tradicional.

En un proyecto tradicional, el proceso es relativamente lineal: se estima el producto a desarrollar (generalmente haciendo un desglose por etapas); se planifica el desarrollo (con la consecuente transformación de lo que antes eran estimaciones en compromisos); y luego se procede a ejecutar el plan, que por supuesto debe cumplirse al pie de la letra. Cuando las cosas comienzan a atrasarse (y siempre lo hacen) empiezan las complicaciones.

El problema fundamental de la planificación tradicional es que trata al desarrollo de software como una actividad predecible, cuando no lo es. Y este problema fundamental es lo que intenta atacar la estimación y planificación ágil. El desarrollo de software es una actividad de creación y transmutación de conocimiento. Como tal, no puede ser predicha ni estimada en forma precisa. El primer paso hacia la planificación ágil es la aceptación de este concepto.

Pero pocas organizaciones están dispuestas a embarcarse en un proyecto sin tener siquiera una idea aproximada de cuánto va a costar o cuándo va a estar terminado el producto. Si esto fuera aceptado, podríamos dedicarnos directamente a producir sin ningún tipo de estimación o planificación (lo cual tal vez no sería mala idea).

Entonces, cómo encarar la estimación y planificación de algo que no sabemos predecir?

Bueno, empecemos por refinar un poco qué significa no poder predecir el tamaño del producto. En la práctica, cualquier desarrollador senior puede dar una idea del orden de magnitud de un proyecto. Esto nos brinda lo que en inglés se denomina ballpark figure, un número grueso que nos permite ir pensando si es negocio desarrollar el producto o no. Y es lo primero que debe hacerse, ágil o no ágil. Las probabilidades de estar equivocados en un órden de magnitud son realmente bajas (en ese caso, por favor reconsiderar el titulo de “senior” de los desarrolladores). En mi experiencia, los proyectos tradicionales suelen excederse de sus estimaciones originales en numeros que van del 30% al 300%. Esto es lo que intentaremos mejorar con la técnica que explicaremos a continuación.

Las metodologías ágiles implementan muchos conceptos de Lean, el sistema de producción de Toyota. Uno de ellos es small batch sizes, que significa producir valor en lotes pequeños. El desarrollo tradicional, con sus etapas, produce todo el valor (el proyecto) en un solo lote. En todo momento, el 100% del proyecto está siendo procesado y 0% ha sido terminado. Finalmente se llega al “Dia D”, el “Big Bang”, donde todo el proyecto es entregado de un saque. Los métodos ágiles, por contraste, buscan entregar valor incrementalmente. En el caso del desarrollo de software, esto se consigue agregando funcionalidad en cada iteración y manteniendo siempre el producto funcionando con la funcionalidad que haya sido implementada hasta ese momento.

Objetivos como historias de usuario

Siguiendo esta línea, el primer paso en la estimación y planificación ágil es la creación del product backlog, o sea la definición del proyecto a realizar. Se puede dividir en objetivos expresados como historias de usuario (user stories), cada una aportando valor de negocios incremental e individual. Una historia es un requisito de negocio visto desde el punto de vista de un usuario. Se escriben con el siguiente formato: “Como xxx, quiero hacer yyy con el objetivo de zzz“,  donde, xxx es el tipo de Usuario (quien), yyy es lo que el sistema debe permitir realizar (el qué) y zzz es el beneficio o valor buscado (el por qué).

Ejemplo:
“Como cliente del banco, quiero pedir un préstamo para poder comprar una casa” .

tarjeta-historia-usuario-scrum-backlog

Las condiciones de satisfacción de los objetivos suelen ponerse en forma de criterios de aceptación, pruebas que se realizarán para verificar si el sistema se comporta de la manera esperada. Para ello se puede utilizar la sintaxis de BDD (Behaviour Driven Development) siguiendo el siguiente formato: “Dado aaa, cuando se produzca bbb, entonces ccc“, donde aaa es la situación en la que se encuentra el sistema, bbb es un evento que lo hará cambiar y ccc es el resultado. Esta técnica permite evitar la aparición de errores por malos entendidos y evitar retrabajar (siguiendo los principios Lean). Por ello es recomendable no empezar a desarrollar en una iteración sin antes haber escrito los casos de prueba, especialmente por que es más barato escribir texto y pensar en cómo desambiguar los requisitos que arreglar errores importantes debido a su mal entendimiento.

Pero en la práctica no hace falta usar estos formatos, cualquier sintaxis donde la acción sea clara y el beneficio buscado sea entendido por todos es suficiente. Si no partimos de cero, podemos simplemente tomar los requerimientos en cualquier formato que estén escritos (por ejemplo casos de uso).

Es importante no confundir Criterios de Aceptación de cada objetivo (requisito / historia de usuario) con la Definición de Hecho (DoD) que tienen que cumplir TODOS los requisitos.

Estimación con Planning Poker

El product backlog es, para ser exactos, una lista priorizada y estimada de historias. Por ahora sólo tenemos historias. Falta estimarlas y priorizarlas. El proceso de estimación se puede hacer utilizando una técnica llamada planning poker (póker de planificación). El objetivo del planning poker es obtener una medida de tamaño relativo de todas las historias respecto a sí mismas.

Cartas de planning poker

La teoría es que resulta relativamente fácil decir “A es más grande que B y que C” [no voy a entrar en detalle respecto a cómo efectuar planning poker, dejándolo para otro artículo]. Lo importante de efectuar planning poker sobre todo el backlog (a efectos de la planificación) es que da como resultado que todas las historias han sido estimadas con muy poco esfuerzo. Pero no en días/hombre como se haría tradicionalmente. Planning poker produce estimaciones en una medida arbitraria de tamaño llamada story points o “puntos de historia”. Los story points son específicos de cada equipo, no pueden compararse entre diferentes equipos y a veces ni siquiera entre diferentes proyectos del mismo equipo. Lo único que indican es el tamaño relativo que tiene cada funcionalidad del backlog respecto a las demás. Lo importante es que ahora tenemos el tamaño total del proyecto estimado en una unidad llamada story points, y esto nos va a servir de mucho.

Priorización

La etapa de priorización es sencilla y depende exclusivamente del Product Owner. Sabiendo ya el tamaño de las historias, debe priorizarlas por valor de negocio. Notar que también es posible comenzar con la asignación de valor y después aportar el tamaño, en todo caso, la priorización se realiza balanceando el valor respecto al coste y respecto a los riesgos de cada objetivo.

Una manera rápida de empezar a asignar valor a las historias es dividirlas en 3 grupos, según sean imperativas, importantes o cosméticas/prescindibles (de manera que si se llega a una fecha de entrega predeterminada y no se han completado por lo menos hemos aportado el máximo de valor posible). Dentro de cada grupo nos resultará más fácil realizar una ordenación relativa por valor y después asignarlo.

La prioridad puede cambiar todo el tiempo; pero el tamaño en story points debe mantenerse fijo con la estimación original (o sea: como regla general, no reestimar). Si aparecen historias nuevas, deben estimarse utilizando el mismo criterio que se utilizó originalmente.

Ahora bien: todo esto todavía no nos dice nada respecto a cuánto durará o costará el proyecto; pero al menos es un paso más respecto a como estábamos antes, que solo teníamos el ballpark estimate. Si sólo pudiéramos averiguar a cuántos días/hombre o días/equipo equivale un story point, tendríamos nuestra estimación, y luego nuestra planificación.

Duración y proyección a partir de la velocidad del equipo

El último paso, por lo tanto, es calcular la velocidad del equipo completando objetivos a lo largo de las iteraciones. Así pues, la velocidad es la cantidad de story points que se completan por iteración. Calcularla es sencilla: solo hay que sentarse y esperar. En dos -como máximo tres- iteraciones, tendrás una idea bastante clara de cuál es la velocidad del equipo y por lo tanto el tamaño y duración del proyecto. Mientras tanto se puede ir construyendo el burndown chart, cosa que no me animo a traducir (gráfico de quemado?). El burndown chart nos muestra en el eje Y la cantidad total de story points del proyecto, y sobre el eje X las iteraciones. Cada vez que se finaliza una iteración, se completa un punto del gráfico, indicando la velocidad en ese ciclo.

Si teníamos una fecha prefijada en la que queremos terminar el proyecto, esto nos permite calcular la velocidad teórica a la que tendremos que ir para alcanzar esa fecha. El burndown chart permite rápidamente y en todo momento ver dos estadísticas vitales para la planificación: la estimación actual de cuándo va a estar terminado el 100% del proyecto; y la estimación del porcentaje de proyecto que va a estar terminado cuando lleguemos a cierta fecha.

Conclusión

La estimación y planificación ágil permiten así en todo momento saber cuál es la fecha estimada de finalización del proyecto, y en qué iteración estará lista determinada funcionalidad. Un beneficio adicional que nos brinda es que de existir complicaciones severas, que pongan en juego la factibilidad del proyecto, éstas generalmente se ven expuestas bien temprano, permitiendo cancelar el proyecto antes de incurrir en grandes pérdidas. Por esto, sumado al hecho de que el desarrollo iterativo e incremental garantiza que en todo momento se cuenta con el producto listo para ser entregado (por ejemplo software funcionado), está el hecho de que los métodos ágiles disminuyen enormemente los riesgos tradicionales en el desarrollo de proyectos.

Artículos relacionados

Planificación ágil de proyectos dependientes

Para planificar un proyecto desde la óptica ágil y crear la primera versión del backlog (lista de objetivos priorizados) se pueden utilizar los siguientes criterios de priorización:

  • El valor para el cliente de cada objetivo o requisito de alto nivel.
  • El esfuerzo estimado de desarrollo de los objetivos, proporcionado por el equipo.
  • El riesgo asociado a cada objetivo (madurez de requisitos, riesgos tecnológicos, personas que participan, en línea con los factores de complejidad de los proyectos).
En el caso de planificar varios proyectos dependientes, puede ser necesario añadir nuevos criterios como, por ejemplo:
  • Las dependencias e integraciones entre los proyectos, para asegurar que se traten de manera simultánea y en el momento adecuado.
  • El riesgo asociado a estas dependencias e integraciones.
Estos últimos criterios pueden obligar a repriorizar algunos objetivos de los proyectos.
 
En esta planificación inicial, para facilitar la colaboración de los participantes en los diferentes proyectos (clientes / product owners, equipos y scrum masters / facilitadores), se puede utilizar tarjetas de historia de usuario pegadas sobre una pizarra blanca o pared.
 
tarjeta-historia-usuario-scrum-backlog

 
 
A continuación se detalla el proceso de creación conjunta del backlog de varios proyectos.

  1. Crear las tarjetas con los objetivos de cada proyecto, escribiendo el valor, estimación de esfuerzo y riesgo iniciales de cada objetivo.
  2. Elaborar el backlog de cada proyecto, ordenando las tarjetas teniendo en cuenta las dependencias entre objetivos y utilizando los criterios de priorización anteriores.
  3. Pegar las tarjetas de cada proyecto en la pizarra, encajando el esfuerzo de los objetivos en la capacidad de las iteraciones.
  4. Identificar las dependencias entre objetivos de diferentes proyectos y realizar los movimientos de tarjetas y recálculos de esfuerzo necesarios.

planificacion-proyectos-dependientes-scrum

 
En este ejemplo los objetivos o requisitos de alto nivel de cada proyecto aparecen clasificados por áreas (módulos o paquetes funcionales de un proyecto) que se desarrollan incrementalmente en diferentes momentos e iteraciones.

 

Artículos relacionados

Creación de product backlog – Resultados del tercer encuentro ágil en Barcelona

 

En este encuentro se compartieron experiencias sobre los siguientes temas:
  • Principios de Lean Software Development, a modo de ayuda cuando Scrum no proporciona una solución directa a un problema.
  • Cómo gestionar historias de usuario que comparten implementación, haciendo énfasis en no perder el foco de que toda historia de usuario debería proporcionar algún valor al cliente.
  • Empezar por las historias de usuario más claras y que aportan más valor, y así en el futuro evitar modificar código de requisitos actuales dudosos.
  • La “generalización” del producto puede ser peligrosa para el negocio, no hay que olvidarse de obtener resultados a corto-medio plazo para el negocio
  • Cómo poner las pruebas de concepto en el product backlog, siempre sin perder de vista que el tiempo para estas pruebas debe estar acotado (timebox) y que debe poder medirse el progreso de la prueba.
  • El backlog como iceberg, en el cual los primeros objetivos son más pequeños, están más detallados, y los últimos son meros recordatorios de grandes objetivos a conseguir.
A continuación se detallan las ideas que se trataron respecto a estos temas.

 
Principios de Lean Software Development
La reunión comenzó haciendo una enumeración de los principios de Lean Software Development, de manera que sirviesen como ayuda por si se trataba algún problema para el que Scrum o XP no tuviesen una solución directa:
  • Respetar a las personas, por que el equipo es quien conoce cómo mejorar el proceso en que trabaja.
  • Eliminar los desperdicios que se producen en el proceso, todo aquello que no produce valor añadido en el producto.
  • Aplazar el compromiso, retardar las decisiones hasta que se disponga de toda la información o no se pueda esperar más.
  • Crear conocimiento, tener feedback regular con el cliente para alinearse con sus expectativas.
  • Hacer entregas rápidas, para permitir que el cliente pueda aprovechar antes los beneficios que le aporta el proyecto.
  • Desarrollar con calidad interna, de manera que el producto pueda ir creciendo con una velocidad sostenida.
  • Optimizar la totalidad del proceso, mejorar el proceso de creación del producto, desde la idea hasta su entrega.
Cómo gestionar historias de usuario que comparten implementación
En ocasiones hay historias de usuario que comparten una misma implementación. Lo más conveniente es formular toda historia de usuario de manera que aporte un valor al cliente (por ejemplo, cuantificable en dinero que el cliente podrá recuperar a partir de sus usuarios). No deberían existir historias de usuario de implementación del estilo “crear un motor de indexación”.
Dado que la primera historia de usuario siempre tendrá un esfuerzo mayor de implementación, puede ser conveniente hacer lo siguiente:
  • Explicar al cliente esta situación. De esta manera puede tomar una mejor decisión de qué historia de usuario le interesa que se implemente antes (puede llegar el caso de que el cliente vaya retardando la segundo historia de usuario y que al final ésta no se implemente nunca).
  • Ver qué orden de implementación de las dos historias de usuario es el que necesitará de un menor esfuerzo global.
Empezar por las historias de usuario más claras y que aportan más valor
Siguiendo el principio de Lean “aplazar el compromiso”, ante la duda de si en el futuro será necesario un requisito o una parte de arquitectura, lo mejor es sólo implementar lo que se necesite en el momento actual y utilizar técnicas como patrones de diseño para que en el futuro no cueste crecer encima (“Desarrollar con calidad interna”). Estas primeras necesidades deberían estar claras para el cliente, dado que deberían ser las que le aporten más valor en el momento actual.
Se consiguen varios beneficios de no implementar lo que no está claro (que sea necesario para el producto o cómo debe funcionar):
  • Se consiguen completar antes los requisitos que sí están claros (“Hacer entregas rápidas”).
  • Cuando llegue el momento de incorporar los requisitos que en su día fueron dudosos (y puesto que la idea original puede haber cambiado), las modificaciones/refactorizaciones a realizar pueden ser menores que si se tuviesen que hacer sobre un código implementado a partir de requisitos no claros. En un caso extremo, puede ser que el cliente no necesite nunca esos requisitos.
La “generalización” del producto puede ser peligrosa para el negocio
Si el cliente o el equipo dedica demasiado tiempo en generalizar el producto y las historias de usuario para que la solución cubra el máximo número de futuras posibilidades del producto (posibilidades que quizás acabarán cambiando o que nunca llegarán), se corre el peligro de desviarse de obtener resultados a corto-medio plazo para el negocio.
Cómo poner las pruebas de concepto en el product backlog
Es conveniente que todos los objetivos del proyecto aparezcan en el product backlog, incluidas las pruebas de concepto (spikes) que sean necesarias:
  • Si es posible, es mejor ser transparente con el cliente y que entienda el sentido y necesidad de realizar pruebas de concepto.
  • Es más sencillo utilizar una única herramienta (el product backlog) para tener la visión de todos los objetivos en que está trabajando la fuerza productiva (el equipo).
Las pruebas de concepto deben estar acotadas en el tiempo (tareas con timebox) para ayudar a tomar decisiones, especialmente si no se están consiguiendo resultados de las pruebas. Para ver si se va por buen camino, se pueden utilizar diferentes técnicas:
  • Hacer que el timebox sea pequeño (siempre menor que una iteración), pero suficiente para poder obtener un resultado y tomar una decisión. Si al final resulta insuficiente, se puede volver a utilizar otro timebox.
  • Definir la estrategia de la prueba de concepto, dividiéndola en tareas que al completarlas permitan saber si se está progresando.
  • Hacer varias pruebas de concepto para reducir riesgos. Por ejemplo, en el caso de una aplicación web, se pueden hacer públicas variantes de una misma funcionalidad (o diferentes funcionalidades) para diferentes usuarios, de manera que se obtenga feedack directo y real de su aceptación.
El backlog como iceberg
Se explicó la metáfora del backlog como iceberg:
  • En las primeras iteraciones, en que aparecen las historias de usuario más prioritarias, estas historias de usuario son más pequeñas y detalladas.
  • Conforme las entregas son más lejanas, los objetivos se redactan como grandes temas que actúan a modo de recordatorio (“épicas”).
Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona
Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, los snacks y las bebidas.

Artículos relacionados