Introduccin a la estimacin y planificacin gil

Mon, 08/06/2009 - 21:55 - Xavier Quesada Allue

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 innovacin, como por ejemplo los de

desarrollo de software. En este artculo, presentamos algunos principios y prcticas

introductorias para aprender a estimar y planificar un proyecto gil.

Una de las caractersticas de la gestin de proyectos giles es el ser una actividad

adaptativa en vez de predictiva. No es extrao, entonces, que los procesos de estimacin

y planificacin 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 transformacin 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 planificacin 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 estimacin y planificacin gil. El desarrollo de software es una actividad

de creacin y transmutacin de conocimiento. Como tal, no puede ser predicha ni

estimada en forma precisa. El primer paso hacia la planificacin gil es la aceptacin de

este concepto.

Pero pocas organizaciones estn dispuestas a embarcarse en un proyecto sin tener

siquiera una idea aproximada de cunto va a costar o cundo va a estar terminado el

producto. Si esto fuera aceptado, podramos dedicarnos directamente a producir sin ningn

tipo de estimacin o planificacin (lo cual tal vez no sera mala idea).

Entonces, cmo encarar la estimacin y planificacin de algo que no sabemos predecir?

Bueno, empecemos por refinar un poco qu significa no poder predecir el tamao del

producto. En la prctica, cualquier desarrollador senior puede dar una idea del orden de

magnitud de un proyecto. Esto nos brinda lo que en ingls se denomina ballpark figure,

un nmero 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 tcnica que explicaremos a

continuacin.

Las metodologas giles implementan muchos conceptos de Lean, el sistema de produccin

de Toyota. Uno de ellos es small batch sizes, que significa producir valor en lotes

pequeos. 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 mtodos giles, por contraste, buscan entregar valor

incrementalmente. En el caso del desarrollo de software, esto se consigue agregando

funcionalidad en cada iteracin y manteniendo siempre el producto funcionando con la

funcionalidad que haya sido implementada hasta ese momento.

Objetivos como historias de usuario

Siguiendo esta lnea, el primer paso en la estimacin y planificacin gil es la creacin del

product backlog, o sea la definicin 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 requerimiento de negocios 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 prstamo para poder comprar una casa" .

Las condiciones de satisfaccin de los objetivos suelen ponerse en forma de pruebas de

aceptacin que se realizarn, indicando cmo debe comportarse el sistema (o BDD,

Behaviour Driven Development) con el formato "Dado aaa, cuando se produzca bbb,

entonces ccc", donde aaa es la situacin en la que se encuentra el sistema, bbb es un

evento que lo har cambiar y ccc es el resultado. Esta tcnica permite evitar la aparicin de

errores por malos entendidos y evitar retrabajar (siguiendo los principios Lean). Por ello es

recomendable no empezar a desarrollar en una iteracin sin antes haber escrito los casos

de prueba, especialmente por que es ms barato escribir texto y pensar en cmo

desambiguar los requisitos que arreglar errores importantes debido a su mal entendimiento.

Pero en la prctica no hace falta usar estos formatos, cualquier sintaxis donde la accin 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 estn escritos

(por ejemplo casos de uso).

Estimacin con Planning Poker

El product backlog es, para ser exactos, una lista priorizada y estimada de historias. Por

ahora slo tenemos historias. Falta estimarlas y priorizarlas. El proceso de estimacin se

puede hacer utilizando una tcnica llamada planning poker (pker de planificacin). El

objetivo del planning poker es obtener una medida de tamao relativo de todas las historias

respecto a s mismas.

La teora es que resulta relativamente fcil decir "A es ms grande que B y que C" [no voy

a entrar en detalle respecto a cmo efectuar planning poker, dejndolo para otro artculo].

Lo importante de efectuar planning poker sobre todo el backlog (a efectos de la

planificacin) es que da como resultado que todas las historias han sido estimadas con muy

poco esfuerzo. Pero no en das/hombre como se hara tradicionalmente. Planning poker

produce estimaciones en una medida arbitraria de tamao llamada story points o "puntos

de historia". Los story points son especficos 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 tamao relativo que tiene cada funcionalidad del backlog respecto

a las dems. Lo importante es que ahora tenemos el tamao total del proyecto estimado en

una unidad llamada story points, y esto nos va a servir de mucho.

Priorizacin

La etapa de priorizacin es sencilla y depende exclusivamente del Product Owner.

Sabiendo ya el tamao de las historias, debe priorizarlas por valor de negocio. Notar que

tambin es posible comenzar con la asignacin de valor y despus aportar el tamao, en

todo caso, la priorizacin se realiza balanceando el valor respecto al coste y respecto a los

riesgos de cada objetivo.

Una manera rpida de empezar a asignar valor a las historias es dividirlas en 3 grupos,

segn sean imperativas, importantes o cosmticas/prescindibles (de manera que si se llega

a una fecha de entrega predeterminada y no se han completado por lo menos hemos

aportado el mximo de valor posible). Dentro de cada grupo nos resultar ms fcil realizar

una ordenacin relativa por valor y despus asignarlo.

La prioridad puede cambiar todo el tiempo; pero el tamao en story points debe mantenerse

fijo con la estimacin 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 todava no nos dice nada respecto a cunto durar o costar el

proyecto; pero al menos es un paso ms respecto a como estbamos antes, que solo

tenamos el ballpark estimate. Si slo pudiramos averiguar a cuntos das/hombre o

das/equipo equivale un story point, tendramos nuestra estimacin, y luego nuestra

planificacin.

Duracin y proyeccin 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 iteracin. Calcularla es sencilla: solo hay que sentarse y esperar. En dos -

como mximo tres- iteraciones, tendrs una idea bastante clara de cul es la velocidad del

equipo y por lo tanto el tamao y duracin del proyecto. Mientras tanto se puede ir

construyendo el burndown chart, cosa que no me animo a traducir (grfico 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 iteracin, se completa un punto

del grfico, indicando la velocidad en ese ciclo.

Si tenamos una fecha prefijada en la que queremos terminar el proyecto, esto nos permite

calcular la velocidad terica a la que tendremos que ir para alcanzar esa fecha. El

burndown chart permite rpidamente y en todo momento ver dos estadsticas vitales para

la planificacin: la estimacin actual de cundo va a estar terminado el 100% del

proyecto; y la estimacin del porcentaje de proyecto que va a estar terminado cuando

lleguemos a cierta fecha.

Conclusin

La estimacin y planificacin gil permiten as en todo momento saber cul es la fecha

estimada de finalizacin del proyecto, y en qu iteracin 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

prdidas. 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 mtodos giles disminuyen

enormemente los riesgos tradicionales en el desarrollo de proyectos.