Estimaciones en proyectos software

Domingo 25 de noviembre de 2012. Voy a desvelar un secreto muy bien guardado. Algo que tratamos de disimular muy bien los implicados. Los desarrolladores de software molamos, y molamos un huevo.

Las cómodas de Ikea

Hoy he pensado en la forma en que estimamos las cosas en nuestra vida diaria. He recordado cuando tuve que montar dos cómodas de Ikea para mi dormitorio. Claro, de cómodas (de montar) no tienen nada. Casualmente una es, aproximadamente, el dobre de grande que la otra, así que, cuando las tuve en casa, me dije a mí mismo “paciencia, que cuando acabes la grande, la otra sólo te costará la mitad”. ¿Qué estamos haciendo en estos casos? Estimar en proporción.

Una de mis cómodas

Ahora hagamos una aproximación a este mismo problema con las buenas costumbres del desarrollo de software. Mi mujer me pide que monte dos cómodas y me pide un tiempo de montaje. Yo, que soy de todo menos manitas para esas cosas, le digo que voy a tardar una hora en montar la grande y media en la pequeña. Parece lo mismo que antes, ¿verdad? Bueno, en realidad, tras esta conversación, la pobre Pechu va a esperar que en hora y media le entregue todo, y, casi sin darse cuenta, va a estar contando los minutos que le quedan para ver sus nuevas cómodas, esas que con tanta ilusión hemos comprado. ¿Y qué pasa cuando llega tras la primera hora y me ve todavía enredando con la primera cómoda? Pues que viene en primer chof. ¿Por qué? Por la expectativa creada, la que yo he generado. 

Toca priorizar

Para saber por cuál empezar ella necesita tener una medida de coste para establecer una relación de coste/beneficio (bendito ROI). Si esto se lo digo a Pechu me suelta un bofetón, pero si la digo “Nena, tardo en montar la grande el doble que la pequeña. ¿Por cuál empiezo?” seguro que lo entiende genial, entiende de qué forma expreso lo que cuesta cada una y es capaz de establecer una prioridad clara en función del partido (valor) que va a sacar a cada cómoda.

¿Y por qué hacemos esto en el desarrollo de software? Ya lo he dicho antes, aunque esto no valga para nada, lo hacemos porque molamos.

Estimemos software como cómodas

¿Y sí hiciéramos lo mismo cuando planteamos un proyecto que cuando montamos unas cómodas en casa? Planteemos el siguiente problema:

A la cómoda pequeña le doy un valor de referencia de 5. Por tanto, a la grande de 10. Por mi dilatada experiencia montando cómodas, sé que soy capaz de sacar 30 puntos diarios. ¿Puedo establecer un plan de entrega de cómodas? Podría saber cuántas podré entregar, más o menos, en un mes? 

Como vemos, eliminar la variable tiempo cuando hablamos del coste de un desarrollo software no es tan difícil, sólo tenemos que desaprender y volver a aprender. Pero ¿por qué hacer esto? Para gestionar mejor mis expectativas y, sobre todo, las de la persona a quien mando el mensaje.

Anuncios

Acerca de juanmagomez

Acerca de mí tengo un teléfono, mi portátil, el ipad y esas cosas.

Publicado el noviembre 25, 2012 en Agile, Scrum. Añade a favoritos el enlace permanente. 4 comentarios.

  1. Estoy contigo en que siempre vamos a acertar más indicando cuánto nos cuesta que para cuándo va a estar, y con la experiencia ir afinando y acercando ambos puntos.

    Un abrazo

    • Hola Vanesa.

      Al final, el tiempo no deja de ser otra unidad de medida de coste. El problema que le veo es, como comento, la expectativa que genera como unidad de medida. Y, lo que no termino de entender, es esa necesidad de cambiar nuestros hábitos más naturales cuando hablamos de software.

      Claro, si yo saco 70 puntos de historia cada 2 semanas de trabajo y valoro una funcionalidad en 21, alguien tendrá que hacer una operación de más para calcular el tiempo que conlleva, y no todo el mundo está preparado para estas cosas 😉

  2. Antonio de la Torre

    Creo que la creación de expectativas es inevitable. Lo que creo que hay que hacer es intentar contenerlas a un ámbito cómodo (con cajones pero chico).
    Es decir, fijar sprints de 70 puntos a dos semanas es más cómodo y seguro que coger cada historia y hacer el proporcional (“A 7 puntos por día, te tendré la historia de 21 puntos en tres días”), que es lo que no queremos.

    Al final consiste en enseñar al cliente o al P.O. que es una estimación, y como tal hay que verla.

  3. Buenas Antonio.

    La creación de expectativas seguramente sea inevitable, la diferencia radica en quién crea la expectativa. Por otro lado, la estimación al fin y al cabo no es más que una medida de peso, coste, envergadura… y para saber el cuándo, hay mil formas de hacerlo sin necesidad de que utilicemos el tiempo como unidad de medida.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: