¿Tiene sentido estimar? Quizá no deberíamos estimar proyectos #NoEstimates explicado

No está muy claro el origen de la idea, pero desde luego, en los últimos tiempos, el movimiento que recomienda y defiende que las estimaciones en el mundo del software no tienen sentido (e incluso son perjudiciales) ha crecido con relativa fuerza en el mundo del desarrollo software y, más concretamente, en el mundo ágil.
Más allá de los orígenes, por si quieres seguir este tema, quienes más están liderando el #NoEstimates son Woody Zuill y Neil Killick.
Hoy en día, este movimiento en contra de las estimaciones software podemos encontrarlo agrupado bajo el nombre #NoEstimates (lo de la # al principio del nombre viene de que éste es un hasghtag de twitter, por si no eres muy tuitero, bajo el que se recopilan opiniones sobre el tema).
Aunque aún es un tema desconocido para “el gran público”, éste, como tantos otros, es de los que genera bastante confusión, desconocimiento, pasiones, desamores, etc. Así como también genera un gran número de caras que se quedan blancas al escucharlo, genera frases del estilo a “se os ha ido la cabeza”, o “yo no puedo vivir sin saber cuánto algo me va a costar” y otras similares.
Con el objetivo de dejar al mundo mi “gotita” de aclaración, os voy a resumir en este post de qué va, y en qué se basa, el movimiento #NoEstimates. Luego saca tus propias conclusiones y si las compartes en los comentarios… mejor.

Realmente, por la naturaleza del software, es imposible obtener una estimación precisa

Como expone en un artículo Neil Killick, que como te decía es unos de los precursores del movimiento, la base del movimiento #noEstimates está en “¿Cómo podemos estimar cuando todavía no sabemos o entendemos la solución?”
El desarrollo software es, por su propia naturaleza, impredecible y no repetitivo. A diferencia de la producción de, por ejemplo, automóviles (te recomiendo aquí aquel post de Dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas), el producto exacto que estamos construyendo es desconocido hasta que lo hemos construido.
Por esta razón, fijar el alcance exacto (en tiempo – esfuerzo) de los proyectos software es imposible. Incluso si lo fuera, no es deseable, ya que un enfoque de este tipo limita el cambio durante el proyecto, limita un diseño emergente, los requisitos cambiantes y la innovación.
Si aceptamos que el alcance de aplicación a desarrollar es siempre la variable… también debemos aceptar que la fecha de entrega puede ser variable.

Sino es posible cerrar los requisitos de manera precisa antes de comenzar ¿cómo vamos a obtener una estimación precisa?

Obtener una estimación se basa en satisfacer un conjunto fijo de requisitos, si los requisitos no son precisos… las estimaciones no son precisas (lo volveré a repetir al final del post, este argumento se viene exponiendo en estimación software desde que tiene nombre, esta idea no es algo revolucionario).
Y tener unos requisitos precisos antes de comenzar… ya sabemos, y está muy debatido, que es algo que muy pocos proyectos se pueden permitir, algo que siempre pretendió el ciclo de vida en cascada, algo que generó (genera) proyectos en los que todas las partes acaban inconformes, etc. No me extiendo en las razones de todo esto, que ya las hemos contado muchas veces, no obstante, si tienes interés léete estos dos post: Contrato cerrado, ¿el peor enemigo del software o mal necesario? Y Diagramas Gantt cómo arma de destrucción masiva de proyectos.
Como argumentan desde el #noEstimates, para construir software necesitamos sólo una visión clara y un propósito compartido, objetivos de alto nivel, y no el detalle de cómo vamos a lograrlos. Entonces… ¿qué sentido tiene buscar una estimación precisa y condicionar todo el proyecto a ella? ¿qué sentido tiene si sabemos desde el principio que es inexacta por naturaleza?

Bueno, y en Scrum… ¿No se estimaba con la velocidad? ¿No es entonces la estimación en base a la velocidad algo ágil?

Una de las bases que normalmente se utilizan en Scrum para hacer estimaciones, previsiones, es el uso de la velocidad o la cantidad de trabajo completada en un tiempo (normalmente por Sprint). Si no estás familiarizado con la velocidad léete ¿Qué es la velocidad en un proyecto software (normalmente ágil o Scrum)? Aclaración de dudas frecuentes y Como estimamos proyectos Scrum o en general ágiles.
Bueno, pues en este sentido, los defensores del #noEstimates no se cortan y llegan a decir que estimar con velocidad no es ágil. Argumentan para ello que en lugar de hacer pronósticos cada Sprint sobre cuántos puntos o historias de usuario se pueden hacer, los equipos deben comprometerse desde el principio a ofrecer el mejor producto posible en una fecha determinada.
Y que la planificación en base a la velocidad es contraria a un enfoque iterativo (mejora evolutiva holística del producto) siendo más acorde sólo con un enfoque puramente incremental (añadir valor, requisitos, al Producto). De nuevo, este tema ya lo hablamos en su momento, si no te queda claro te recomiendo leer El ciclo de vida iterativo e incremental y el riesgo de olvidarse del iterativo y quedarse solo con el incremental
Y algo más: El Product Owner no debería priorizar a una historia sobre otra en base a que tenga una menor estimación (puntos historia), siendo así, la estimación… ¿qué utilidad tiene? El Product Owner debe prioriza las historias por valor. Si las estimaciones son lo importante frente al valor… acabaremos teniendo software malo.

Algunas conclusiones, «remakes» y peros…

Si ya los escépticos de la agilidad ponían “peros” con el ciclo de vida iterativo, si ya, y vuelvo a dejarte un post, constantemente decían que El problema de la agilidad es que no vamos a saber cuándo se termina el proyecto (y la típica solución al anterior problema), en ciertos sectores “tradicionales” extender el #noEstimates es todo un reto.
Y no puedo terminar sin decir que la justificación y parte de los argumentos del #noEstimates me parecen un “remake” avanzado de las ya múltiples y antiguas ideas que había desde hace muchos años alrededor del mundo de la estimación, con mención especial al cono de incertidumbre.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

12 comentarios en “¿Tiene sentido estimar? Quizá no deberíamos estimar proyectos #NoEstimates explicado”

  1. Hola Javier.
    Estoy muy deacuerdo con el post, y es algo que en nuestro equipo Scrum ya habíamos comentado otras veces. Pero mi pregunta sería, ¿cómo puede convivir el #noEstimes con la necesidad que tiene la parte de negocio de empresa/start up de saber que va a tener disponible para ofrecerle a los clientes?
    Un saludo, muchas gracias

  2. Es posible estimar.
    De hecho, es necesario estimar para dar una idea expresada en una alguna unidad (horas/hombre, por ejemplo) de la magnitud de lo que hay que realizar.
    Pero una estimación no es una planificación. Y ese es el único pero gravísimo problema.
    Si puede hacerlo un fontanero, un mecánico, un médico y un ingeniero, ¿cómo no vamos a poder responder a la pregunta «cuanto te llevará hacer esto»?
    Y para la gestión del proyecto, esto además te da una idea no sólo de la dificultad de la tarea sino también de la capacidad del que va a realizarla. Imprescindible a la hora de estimar, y es uno de los puntos que el agilismo venía a solucionar, permitiendo que los ejecutores dieran la estimación y no viniera impuesta.
    Y es donde se ha dado una vuelta de tuerca siniestra al convertir esa estimación en un compromiso.
    La cuestión es que lo que no ocurre en otros lados tampoco lo podemos asumir nosotros. La respuesta vaga e incial de los profesionales arriba citados no se convierte en ley contractual y/o planificación obligada. Y nadie reclama por ello. Y tampoco debe hacerse esa exigencia a un desarrollador.
    Y aquí entra el comentario a tu entrada. Has usado 5 veces la palabra precisa, que casa bastante mal con estimación. Y aunque se consiguiera (voy a tardar X, y lo cumples) no se puede olvidar que nunca has tenido un compromiso con el valor inicial que propusiste.
    Trasladar la estimación a planificación forma parte de las metodologías.
    Y aquí llega el segundo comentario, personalmente soy de la idea de que agilismo es flexibilidad. La velocidad se refiera a poder ver los progresos en producción antes que con otras metodologías (más rápido, por lo tanto) por medio de entregas parciales sobre las que, además, se pueden realizar ajustes (por no llamarlo correcciones) por medio de nuevas tareas (no ampliando las ya existentes y consideradas terminadas)
    Pero eso no significa que las tareas realizadas con SCRUM se hagan más rápido que en cascada. Se tarda lo que se tarda. Y en relación a esta entrada, sí puedes dar una idea aproximada de cuánto será ese tiempo (estimación)
    Las metodologías ágiles te permiten gestionar mejor los problemas de estimación (gestionando qué funcionalidades entran en qué entregas mientras ves evolucionar el software en producción)
    Pero no hacen que las cosas se hagan más rápido ni que las estimaciones sean más, como mencionas, precisas, ni tampoco te puedan obligar a tratar de cumplir más que en otros casos, que es la excusa que se está utilizando para dejar de hacer estimaciones.
    Hay dos problemas añadidos que acabo de recordar.
    Uno, es sentirte presionado por un compromiso y dar sobreestimaciones para darte colchón.
    Otro, es que, o bien contando con la sobreestimación o bien ignorando el criterio técnico del estimador (o ambas) no se aceptan las estimaciones. Trata de hacerle lo mismo a un cirujano («¿cuánto tardas en operar? – 14 horas – vale, hazlo en 8, QUE VAMOS MAL DE TIEMPO»)
    Por último, mencionar que Uncle Bob opina que las estimaciones no deben ser valores únicos fijos, sino rangos de tiempo revisables.
    Yo estoy de acuerdo. Ahora también toca gestionarlo en un proyecto. Y ese es nuestro trabajo, para eso nos pagan, y hay que conseguir que el cliente sea siempre consciente y nunca lo olvide (o si no, programa tú u opera tú)
    Hay que conseguir que no se diga nunca la frase «¿cuánto tardas en hacer esto hasta el viernes?».
    Y ya somos libres para estimar.

    1. Te agradezco la respuesta. Tenía ideas en la cabeza de todo lo que dices pero me las has ordenado y ahora tengo más capacidad de enfrentarme a mi product owner XD. Muchas gracias!! 🙂

  3. Totalmente de acuerdo, sin embargo, ese punto de estimar es muy solicitado a pesar de que no sea una aspecto muy preciso en la realidad pero es muy difícil escapar de la pregunta «Cuanto crees que te tome hacer eso?», muchas veces el cliente llega a presionar tanto por tiempos que hace que el equipo de desarrollo estime basado en la presión, y se diga un tiempo que ni siquiera llegar a estar cerca de lo que realmente necesitamos para hacer lo que se solicita.

  4. El problema es más bien que no se exije al cliente que pague por un presupuesto de algo complejo y/o se opta por hacer estimaciones malas antes que ninguna para no aparentar que no se ha hecho antes (y que por tanto se sabe cuánto tiempo puede llevar).
    Hay empresas que incluso «estiman» que algo lleva 40h y si luego son 60 no se corrije, se le pide al trabajador que siga imputando 40 (para no demandar sobrecostes o para evitar que se le caiga un poco el pelo al que hizo la estimación) y por tanto la estimación se sigue sin hacer como Dios manda.

  5. Hola a todos,
    primero de todos decir claramente que soy un «agilista híbrido» y por tanto incluyo en mi paleta conocimientos, prácticas y herramientas tanto de la ingeniería SW tradicional como de la ágil. En Scrum yo siempre aplicaría un Sprint 0 y unas estimaciones de alto nivel del backlog.
    Me ha gustado mucho el post de Javier Beneito, rezuma sentido común.
    A mi el #NoEstimates me parece una barbaridad (por evitar ser grosero). Está claro que no existen las estimaciones perfectas y tampoco es su objetivo (a no ser que estés mal informado o las utilices con fines perversos). Casi siempre se le puede dar un buen nivel de detalle a los requisitos y por tanto a las estimaciones, otra cosa es que el contexto lo permita (especialmente las personas involucradas).
    Un contrato cerrado con malos requisitos es, todos lo sabemos, una trampa y si entramos en ella es porque queremos (o nos obligan personas sin conocimientos de gestión de proyectos o a las que le da lo mismo).
    Sabiendo que es más fácil cambiar de método que de personas, las estimaciones ágiles (rough, etc.) y una planificación incremental son una buena solución a los problemas de planificación habituales de los proyectos, siempre que todos los actores sepan lo que hacen y se sientan cómodos con el nivel de riesgo que asumen (respecto a los requisitos y a las estimaciones). Esto permite la flexibilidad en el proyecto, evita decepciones y es una solución eficiente respecto a la carga de gestión del proyecto.
    El #NoEstimates me parece adecuado p.e. en Kanban donde no estimas ítems que sabes que son pequeños (p.e. <40h o <100h).
    Decir que medir la velocidad del equipo es antiágil me parece otra "barbaridad", porque es una manera muy eficiente de comunicar que crees en cada momento que podrás entregar en el próximo sprint o en la próxima release.
    Y al Product Owner, la estimación y el riesgo de una historia o épic si le pueden servir para optimizar el valor que se le entrega al cliente.
    En fin, a ver si me encuentro algún día a Zuill y a Killick, y me lo explican en persona, porque no le veo ningún sentido. 🙂
    Alex / http://www.itnove.com

  6. Sergio Antonio Espósito Pérez

    Yo siempre he pensado que el problema no es estimar, ni siquiera el problema es lo buenas o malas que sean las estimaciones. El problema es que las estimaciones se escriben con sangre y a fuego, se asumen obligaciones contractuales, cláusulas penales y demás yerbas aromáticas.
    ¿La alternativa? Nada fácil, pero necesaria: Luego de haber llegado a nuestra mejor estimación, labor pedagógica y negociación con clientes, usuarios, stakeholders o como se llamen dependiendo de la circunstancia en la que se desarrolle el proyecto. Explicarles, con responsabilidad: “nuestra mejor estimación arroja que para el 30 de junio tendremos una versión funcional del software con estas funcionalidades implementadas bla bla bla… pero por lo que pueda pasar (sustentado por un análisis de riesgos adecuado) deberíamos fijar como objetivo lanzar el software a los usuarios el 1 de agosto”

  7. Mi único problema con no estimar, es como cuantificar el presupuesto del que se cuenta para hacer ciertas tareas. Estoy hablando de como llevarlo a las altas esferas, a quienes les importa poco cuan ágiles podemos ser.
    Saludos y feliz año nuevo.

  8. Estaba pensando, sin estimaciones solo nos queda confiar ciegamente en que el equipo es un equipo comprometido y que hacen todo lo que pueden hacer. Ciegamente, porque no hay otra manera que pensar que el equipo siempre va a tope.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *