¿Cómo responder a la pregunta de "Cuánto vas a tardar"?

Cartas para estimar la complejidad
Utilizando la técnica de Planning Pocker

Es inevitable. Te lo van a preguntar; y no importa cuanta información te falte: quien te pregunte "¿Cuánto vas a tardar?" querrá una contestación inmediata y no aceptará otra respuesta que una cifra. El asunto entonces es cómo responder rápidamente y con cierto criterio.

Negocia, calcula y argumenta

Para decir cuánto vas a tardar no vale mirar al cielo, esperar la inspiración divina y dar una cifra. Si dices un número sin más criterio que la "inspiración" o la "intuición", no podrás justificarlo cuando te rebatan la cifra diciendo que es muy grande.

Y lo harán, tarde o temprano.

Quien te pregunta cuánto vas a tardar, espera que le digas el menor número posible porque es tu cliente y quiere tenerlo cuanto antes y pagar poco, porque es tu jefe y quiere que termines pronto para asignarte a otras tareas, porque es un comercial y quiere que el producto sea "barato" para venderlo mejor...

El asunto es que debes asumir que en algún momento alguien dirá o pensará que te has pasado de lo que esperaba, cuando dices cuánto vas a tardar. De modo que, para darle credibilidad a tu respuesta y evitar o cambiar el criterio de tu interlocutor, deberías justificar el dato basándote en una estimación consensuada con tu interlocutor.

¿Cómo estimar rápidamente cuánto vamos a tardar?

Partamos del hecho de que estamos hablando de estimaciones rápidas, en momentos previos a la existencia del proyecto. De modo que queda absolutamente descartado cualquier método de estimación paramétrica como Puntos de Función, COCOMO, Puntos de Casos de Uso o, incluso, estimaciones más ágiles, como las basadas en Puntos de Historias de Usuario; primero, porque no se ha analizado suficientemente el problema como para descomponerlo al nivel que éstos métodos requieren y, segundo, porque no hay tiempo para hacerlo.

De modo que, para no adivinar, ni intentar aplicar unas métricas imposibles, una buena opción es hacer una estimación por analogía, haciendo una lista de los requisitos que se nos piden y asignándoles una complejidad a cada uno que, finalmente, traduciremos a un valor en horas.

Entonces, el proceso para estimar por analogía cuánto tardaríamos en hacer un desarrollo, podría ser el siguiente:

1. Hacer una lista de los requisitos que nos han planteado.
2. Buscar el requisito más simple que encontremos y calificarlo con la complejidad que estimemos.
3. Seleccionar el siguiente requisito no calificado y asignarle una complejidad, teniendo en cuenta las calificaciones asignadas a los requisitos previamente analizados.
4. Repetir el paso 3, hasta que no queden requisitos por calificar.
5. Asignar un valor en horas a cada requisito, según su complejidad para pasar de un valor cualitativo de complejidad a uno cuantitativo de su duración.
6. Sumar el total de horas teniendo en cuenta todos los requisitos.

Dicho así parece simple y, al mismo tiempo indefinido. ¿Qué complejidad asigno a un requisito? ¿Qué pasa si no tengo experiencia previa? ¿Qué cantidad de horas asigno a requisitos de determinada complejidad?

¿Cómo calificar la complejidad de un requisito?

Para simplificar la calificación, siempre partiremos del principio de que es más fácil calificar la complejidad de algo simple y conocido, que de algo complejo y desconocido. 

Por ese motivo, cuando se comienza a estimar, se parte buscando lo que parece el requisito más simple, intentando recordar si ya hemos hecho alguna vez algo parecido y cuán complejo fue; para asignar entonces a dicho requisito la misma complejidad que la de nuestras experiencias pasadas. Ahora, si no encontramos ninguna experiencia parecida, tendremos que descomponer este primer requisito (y solo este) hasta el punto de entender cómo podríamos desarrollarlo y, una vez entendido, estaremos en condiciones de definir la complejidad del mismo.

Una vez calificado el requisito más simple con un grado de complejidad, el resto se calificaría basándose en la experiencia y comparándolo con el requisito ya calificado sin necesidad de comprender a fondo las interioridades del mismo. Para ello, bastaría con responder a las preguntas:

1. ¿Ya he hecho antes algo parecido? ¿Cuán complejo fue?
2. ¿Este requisito es igual, más complejo o mucho más complejo que los anteriores?

Al final del proceso de calificación se obtiene una lista de requisitos cuya complejidad de implementación está justificada en nuestra experiencia y en el análisis realizado. Por supuesto, no es una estimación inmutable y, seguramente las estimaciones cambien, si repetimos el proceso varias veces o consultamos con otra persona. Sin embargo, es probable que estos cambios sean puntuales y con poca variación, sin grandes saltos, en sentido general.

¿Cómo cuantificar en horas la duración la complejidad?

Después de la cualificación, necesitamos cuantificar la complejidad para obtener un resultado en horas y poder responder a la pregunta de cuánto vamos a tardar para hacer determinado desarrollo.

Cuantificar a partir de datos previos

Lo ideal sería contar con estadísticas de proyectos anteriores. Tener una base de datos donde hemos ido guardando por cada proyecto realizado, la lista de requisitos, su complejidad estimada y su duración real.

Con estos datos, podríamos hacer una estimación del proyecto actual con unas cifras cercanas a nuestro desempeño medio y dar una estimación difícil de cuestionar porque, simplemente, negar las estadísticas sería poco razonable.

Cuantificar a partir de una duración "negociada"

Si no tenemos estadísticas que faciliten una cuantificación completa de todos los niveles de complejidad, podríamos, una vez más, apoyar la estimación en la adaptación del principio antes mencionado: es más fácil estimar la duración de algo simple y conocido, que de algo complejo y desconocido.

De modo que, partiremos asignando una duración en horas a la funcionalidad más simple del proyecto y negociaremos esa duración con quien nos ha pedido la estimación. 

Una vez consensuada la duración del requisito más simple, asignaremos duraciones proporcionales a cada complejidad.

Una convención generalmente aceptada es que a medida que aumenta la complejidad, la duración suele aumentar en una proporción mayor, debido a que mientras más complejo es lo que se estima, más imprecisa será la estimación y, por tanto, deberá admitirse un mayor margen de error.

Por ejemplo, algo simple, podría ser el doble de largo que algo muy simple y no, solamente, un poco más largo. De hecho, es frecuente considerar que, a medida que aumenta la complejidad, el tiempo estimado se duplique.

Algo a tener en cuenta es que el punto donde se asigna la primera estimación es clave pues, una vez nuestro interlocutor haya aceptado la estimación inicial, el resto se justificará en el propio sistema de estimación de la complejidad y la duración donde cada valor estará ligado al resto. 

Es decir, que el tiempo que tendrás que negociar será el de la funcionalidad más simple, en la que ambas partes podrán argumentar y justificar sus cifras y, una vez hecho, el resto de las estimaciones será una consecuencia coherente con esa estimación inicial y, por tanto, el resultado final será difícil de cuestionar pues estará basado en un valor consensuado.

Un ejemplo práctico

Supongamos que alguien nos pregunta cuánto tardaríamos en hacer una pequeña aplicación móvil para generar una alarma en caso de una emergencia. La idea es que el usuario pueda indicar un teléfono y que, en caso de emergencia, baste con abrir la aplicación para que ésta recupere el teléfono guardado y le envíe a dicho número un SMS con el texto "SOS" y un enlace a un mapa con la posición del usuario.

Lo primero sería listar las funcionalidades del sistema:

1. Guardar teléfono de contacto para emergencias.
2. Enviar SMS con mensaje y enlace a mapa con posición del usuario.

Sin embargo, la segunda funcionalidad, podríamos descomponerla en dos más simples y más fáciles de estimar: obtener posición del usuario y enviar SMS con un texto predeterminado. De modo que la lista de funcionalidades podría quedar así:

1. Guardar teléfono de contacto para emergencias.
2. Obtener posición del usuario.
3. Enviar SMS.

Luego tendríamos que estimar la complejidad de cada una. Debido a que tenemos poca experiencia en desarrollos móviles (solo hemos hecho cosas básicas) estimamos que:

1. Guardar teléfono de contacto para emergencias es "muy simple" pues ya hemos hecho antes otras aplicaciones de gestión de datos y guardar un solo dato en local es una tarea bastante sencilla. 
2. Obtener posición del usuario es "muy complejo" porque -por lo que sabemos- hay que lidiar con distintos niveles de precisión en la localización, temas de batería y no lo hemos hecho nunca.
3. Enviar SMS es algo "simple" pues, aunque no lo hemos hecho nunca, hemos leído algo sobre las APIs implicadas en las comunicaciones por SMS y parecen bastante fáciles de usar.

No obstante, nuestro potencial cliente nos dice que lo de la posición no debería ser "muy complejo" pues ya le hicieron anteriormente una aplicación con localización integrada y los desarrolladores le comentaron que era menos complejo de lo que parecía. De modo que, con la promesa de ponernos en contacto con esos desarrolladores para que os ayuden con las dudas que puedan surgir, acordamos bajar la complejidad del segundo punto de "muy complejo" a "complejo", quedando la complejidad por requisito así:

1. Guardar teléfono de contacto para emergencias: "Muy simple" (XS). 
2. Obtener posición del usuario: "Complejo" (L).
3. Enviar SMS: "Simple" (S).

(Con el tiempo verás que es cómodo utilizar el sistema de tallas XS, S, M, L, XL y XXL para definir cualitativamente la complejidad de los requisitos.)

Ahora toca estimar cuánto tardaremos en implementar el requisito más simple: el número 1.

Dada nuestra experiencia, decimos que implementar la interfaz, guardar el dato y hacer las pruebas pertinentes, nos tomaría algo más de medio día de trabajo (5 horas, aproximadamente); pero nuestro cliente -siempre inconforme- protesta porque le parece excesivo 5 horas para algo "tan elemental"; así que nos enzarzamos en un debate sobre la calidad del software, la documentación que no ve el usuario final, las pruebas unitarias, los test exploratorios... y después de estirar y encoger las propuestas, quedamos en que 4 horas para el requisito 1 estarían bien.

Así que solo nos falta trasladar la duración en horas a cada requisito restante, partiendo de que cada requisito podría tomar el doble de tiempo que otro con una complejidad inferior. Es decir, si tuviéramos un requisito por cada complejidad, la duración de cada uno sería:

1. Muy simple (XS): 4 h.
2. Simple (S): 8 h.
3. Medio (M): 16 h.
4. Complejo (L): 32 h.
5. Muy complejo (XL): 64 h.
6. Muy muy complejo (XXL): 128 h.

Lo que en nuestro caso, significaría una duración en horas por requisito de:

1. Guardar teléfono de contacto para emergencias: "Muy simple" (XS), 4 h.
2. Obtener posición del usuario: "Complejo" (L), 32 h.
3. Enviar SMS: "Simple" (S), 16 h.

Lo que en total, nos daría una duración de 52 horas o 6 días y medio, ideales; es decir, 6 días y medio si trabajáramos 8 horas exclusivamente en el proyecto.

No obstante, para ser realistas, de las 8 horas diarias, es muy probable que perdamos 1 o 2 horas en comunicaciones (e-mails, llamadas telefónicas), o interrupciones varias (consultas, incidencias con otros productos, etc.). De modo que, siendo objetivos,  aunque el tiempo de desarrollo serían 52 horas, el tiempo para entregar el producto sería de casi 9 días.

Un par de aclaraciones útiles

Las estimaciones de requisitos muy complejos son malas

Volvamos a la lista de tiempos por complejidad enunciada para el ejemplo anterior y fijémonos cómo, a pesar de que el requisito más simple dura solo 4 horas, el más complejo puede parecer excesivamente extenso.

1. Muy simple (XS): 4 h.
2. Simple (S): 8 h.
3. Medio (M): 16 h.
4. Complejo (L): 32 h.
5. Muy complejo (XL): 64 h.
6. Muy muy complejo (XXL): 128 h.

Ese contraste es, justamente, lo que nos ayudará a hacer estimaciones más realistas pues, a medida que aumentemos la complejidad de un requisito, estamos diciendo que sabemos poco de él y que, por tanto tenemos menos idea de cuánto va a durar su desarrollo y, por ende, que estamos siendo imprecisos.

De modo que, si tienes un requisito estimado como "muy muy complejo", es sinónimo de que deberías descomponer ese requisito en otros menos complejos que puedas entender mejor y, por tanto, estimar mejor.

Demasiadas estimaciones de requisitos muy simples son malas

Esto podría parecer una contradicción con la afirmación anterior, pero no lo es. Es mejor tener requisitos con estimaciones de complejidad pequeña, que estimaciones de complejidad muy grande porque significa que seremos más precisos a la hora estimar la duración de los mismos.

Sin embargo, no es frecuente que tengamos información tan detallada como para comprender a fondo todos los requisitos y evaluarlos con complejidades simples. De hecho, es muy frecuente que cuando estemos generando estimaciones, subestimemos la complejidad de las mismas y generemos estimaciones a la baja.

Por eso, si tienes muchas estimaciones de requisitos muy simples, deberías reevaluarlas con detención intentando ver posibles riesgos que podrías estar pasando por alto.

Conclusiones

Lamentablemente, en muchas ocasiones que nos piden estimar cuánto vamos a tardar en un desarrollo, no disponemos de la información ni el tiempo suficiente como para aplicar un método de estimación que tenga en cuenta la mayor cantidad de variables posibles y, en su lugar, debemos apoyarnos en la experiencia y unos principios simples que nos permitan hacer unas estimaciones que, si no son tan precisas, al menos sean justificables; porque, sin olvidar que cualquier estimación de tiempo en una fase temprana y con poca información de base puede tener una desviación grande del resultado final, siempre será mejor una estimación argumentada que una "corazonada".

Mis primeras experiencias con Kanban: lecciones aprendidas

Hace varios meses comencé a usar Kanban en un proyecto doméstico. Contento con los resultados, decidí intentarlo en la oficina para experimentar en un entorno mas complejo. La cara de duda de algunos que me observaban cortar y garabatear un cartón para prepararlo como pizarra no se hizo esperar... y las dificultades para aplicar Kanban, tampoco.

El principio: motivado por la desmotivación

Trabajar en solitario tiene sus pros y sus contras. Las ventajas seguro que podrían ser enumeradas y disfrutadas por cualquiera pero... ¿cómo aminorar los inconvenientes si no tienes a tu lado a nadie que pueda ayudarte?

En la primavera del 2010 comencé a trabajar en un pequeño proyecto -en mi casa- que se suponía debía terminar en un par de meses; pero por gestionar mal el proyecto y permitir que los requisitos del sistema aumentaran descontroladamente el verano terminó y el proyecto no hacía más que crecer. Llegó el otoño y con la caída de las hojas se me cayeron a mí las ganas de trabajar en el desarrollo: los incentivos iniciales parecían escabullirse y la soledad del cuarto de estudio no ayudaba, así que mi dedicación y motivación estaban en los mínimos.

La gestión de los requisitos del sistema la estaba haciendo con Scrumpy, que es un software para gestionar al estilo Scrum; de modo que tenía una larga lista de historias de usuario sin hacer y unas estadísticas de velocidad y puntos de historias de usuario por sprint que solo podían estimar una entrega aún lejana. En otras palabras tenía justo lo que un desarrollador desmotivado necesita para que desee invertir el tiempo en leer en lugar de programar.

Y fue leyendo que reencontré a Kanban.

Necesitaba algo más visual que una lista ordenada de trabajo pendiente y unas estadísticas negativas. Necesitaba algo que me motivara, que me dijera: "Te falta por hacer esto; pero haz hecho todo esto... ¡Ya falta menos!" Así que al releer los principios de Kanban y la simplicidad del método me decidí a utilizarlo.

Busqué una pizarra, la preparé y coloqué en la columna de to-do un post-it por cada historia de usuario del sprint en curso; tomé una de tamaño S, la pasé a la columna in progress y me puse a programar.

La rápida aglomeración de las historias cortas terminadas en la columna done! fue el combustible que necesitaba para reemprender con ganas el proyecto. Entraba en el estudio desorientado y la pizarra me le ponía claro: "estás trabajando en esto (y solo en esto) que ves en in progress". Levantaba la vista del ordenador y ahí estaba la pizarra de Kanban mostrándome cuánto había hecho y, sobre todo... ¡cuán poco me faltaba!

Definitivamente Kanban me ayudó con aquél proyecto, lo terminé, la pizarra permanece ahí, esperando el siguiente proyecto para organizarme el trabajo y darme el ánimo que necesite. Sin embargo, la experiencia fue demasiado buena para dejarla en casa, así que decidí probar en el trabajo.

Llevando Kanban a la oficina

En el departamento de desarrollo tenemos una pared de cristal que hace la mayoría de las veces de pizarra colectiva pero, debido a su carácter comunitario tuve que improvisarme el tablero con un trozo de cartón. Así que entre risitas y chistes de "una cerveza y una ración de calamares para la mesa 1", monté mi pizarrita con los primeros post-it.

Las primeras impresiones fueron positivas: cada vez que venían a preguntarme cómo estaba de trabajo o en qué estado estaba un proyecto, con un par de explicaciones y una mirada rápida a la pizarra eran suficientes para que se formaran una idea rápida de lo que querían saber.

Mi pizarra Kanban en la oficina

Sin embargo los problemas comenzaron pronto, con la priorización de tareas, pues resulta que en la empresa suelo llevar más de un proyecto a la vez, de modo que el trabajo planificado respondía a 2 niveles de prioridades: prioridad entre proyectos y prioridad entre las tareas de cada proyecto. Esto obligaba a hacer una reorganización engorrosa que rápidamente pasó a ser una división imaginaria de la pizarra con una fila para cada proyecto, lo cual ya deformaba la visión global de la prioridad real de las tareas y cambiaba el alto de las "filas", con su consiguiente reorganización, cada vez que aumentaba una tarea en un proyecto.

El experimento perduró durante unas semanas, hasta que el número de proyectos en paralelo y la necesidad de compartir el tiempo de trabajo entre proyectos terminaron haciendo insostenible el mantenimiento de la pizarra.

De modo que la experiencia de Kanban en la oficina no dio los frutos que esperaba pero me sirvió para algo:

1. Corroborar que Kanban es una herramienta magnífica para visualizar rápidamente el estado de un proyecto (o una etapa del proyecto).
2. Concluir que una pizarra Kanban no es útil para llevar más de un proyecto a la vez.

¿Entonces es o no es útil Kanban en el desarrollo de software?

Bueno, la experiencia del proyecto doméstico sugiere que Kamban sí es útil para gestionar el trabajo en un proyecto con tareas estables, bien definidas y con prioridades poco cambiantes; por ejemplo, en un ciclo corto de desarrollo como los sprint de Scrum. Sin embargo, la experiencia en la oficina sugiere que Kanban no es útil si intentamos aplicarlo a varios proyectos a la vez o con tareas muy variables y con prioridades en constante cambio.

Todo esto, claro está, debido al carácter material de una pizarra Kanban física. Si tuviéramos los recursos para dedicar una pizarra electrónica y montar un sistema de e-Kanban, otro gallo cantaría.

Entonces... ¿es útil Kanban? Si, es útil; aunque todo depende de las características del proyecto y el entorno.