#NoEstimates

   

https://oikosofy.safechkout.net/NoEstimates-Book  

Un desarrollador (o su representante) conversa con el cliente (o su representante):

- ¿Qué es lo que se necesita hacer?

- ABC, ¿cuánto tiempo te tomará?

- x

Luego de x tiempo:

- Ya pasó x, ¿cómo vamos?

- Aún en la tarea

- Vamos retrasados

Finalmente:

- Ya está listo ABC

- Ok, pasa la prueba. Pero se atrasaron y%

- Ok, trataremos de hacerlo mejor

Situaciones de ese tipo se presentan durante el desarrollo de un producto y nos parecen normales. Sin embargo, expresan una serie de supuestos que no son necesariamente ciertos. Ni siquiera relevantes.

¿Qué es lo se necesita hacer?

Supone que el cliente (o su representante) saben lo que se necesita hacer. Casi siempre no es así, y determinar lo que se necesita hacer es algo que habrá que resolver. ¿Qué es lo que quieres resolver? suele ser una mejor pregunta.  

¿Cuánto tiempo te tomará?

¿Cuánto tiempo toma hacer algo? Si has hecho algo similar varias veces, puedes tener una idea. Pero como programador habrás experimentado que muchas veces hacer exactamente lo mismo, con la misma gente, toma un tiempo diferente. Algunas razones:

• La programación es una actividad creativa
• Las actividades creativas requieren una buena conexión con el subconciente
• La conexión con el subconciente es sensible al humor, el stress, etc
• Los equipos de trabajo están conformados por personas

Y, si nunca has hecho algo similar, quizás sientas que debas importar la respuesta que otro desarrollador similar, de otro equipo similar, para un cliente similar. Pero eso no es correcto por algunas razones:

• El trabajo no lo va a realizar ese desarrollador ni ese equipo para tu cliente en tu contexto. Cada equipo es distinto y el rendimiento de un equipo es sensible al contexto.
• En realidad, no estás seguro de que lo que hay que hacer sea similar a lo que ellos hicieron.

Cuando nunca has hecho algo similar, es necesario empezar a hacer y ver qué tal lo vas haciendo, antes de poder ofrecer alguna estimación sincera.

Vamos atrasados

Supone que la estimación fue correcta. Si hubieras dicho una cifra mayor estarías a salvo. Algo como el doble más el 10% más el número que pensaste. De hecho, muchos desarroladores, o sus representantes, usan ese tipo de tácticas para estar tranquilos; pero el cliente, o su reprepresentante, saben que puede pasar y entonces se produce un regateo de tiempos estimados.

Cualquier supuesto atraso o adelanto es irreal si la estimación no es correcta. ¿Es correcta la estimación? Ya vimos que no es posible que lo sea.

Imagina que un entrenador se acerca te mira y te dice 'mmm tu debes estar saltando unos 150 cm'. 'Sí señor', respondes, mientras le ayudas a colocar la valla. Tomas tu distancia, corres y saltas, llevándote la valla de encuentro. 'Qué mal' dice el entrenador. 'Sí señor', respondes. Si hubieran puesto la vaya a 60 cm hubiera sido 'Qué bien, excelente'. Así de absurda es la situación.

Sería mejor aprender a aceptar las capacidades reales de la gente y trabajar con eso, en lugar de intentar hacer pronósticos y calificaciones arbitrarias.

Además, considerar que, tanto para el clima como para los humanos, todos los pronósticos pueden fallar.

Aprendiendo a programar

Aunque términos como ingeniería de software y ciencias de la computación dan la impresión de que hay un dominio del tema, en realidad estamos aprendiendo a programar.

Quizás no se trata tanto de algoritmos óptimos, sino de encontrar un proceso sostenible que permita desarrollar sistemas también sostenibles. Lo óptimo será alcanzado eventualmente.

Persiguiendo la ilusión del óptimo inmediato es que se suele perder el camino, del mismo modo que un artista principiante que trata de hacer un cuadro trabajando perfectamente cada centímetro cuadrado, para lograr un resultado que no cuadra porque las partes no siguen un bosquejo que nunca trazó.

Encontramos buenas prácticas en programación imperativa. Pero el retorno de la programación funcional parece indicar que son soluciones creadas para problemas generados por usar el modelo imperativo en primer lugar. 

Así, estamos en camino de aprender el oficio de programar.

Programación mental

En los años 70, cuando los ciclos computacionales eran muy caros, nadie podía imaginar usar las computadoras para diseñar software. El software era diseñado en papel, para luego ser codificado por programadores y funcionara a la primera, si era posible.

En las escuelas de programación se incentivaba a la gente hacer todo en papel antes de escribir una línea de código. Correr una línea de código en una computadora era más caro que correrlas en la cabeza, así que los programadores usaban sus cabezas, y mucho papel, como simuladores de computadoras.

En los años 80, con el ascenso de la computación personal, hacer software se volvió una actividad comercial importante. Así que la industria y las universidades impulsaron más la creación de productos de software. Como venían haciendo, tratando de usar la experiencia que tenían en desarrollar otros tipos de productos. Sin embargo, la ejecución de los proyectos de desarrollo de software empezó a mostrar que había cosas importantes que funcionaban de modo diferente.

En los años 90, cuando los ciclos computacionales ya no costaban lo que antes, los programadores se dieron cuenta que tenía más sentido usar la misma computadora para explorar con ella las cosas que quisieramos que ejecute, en lugar de seguir intentando que nuestros cerebros traten de imitar ese proceso.

Considerar los icebergs y los andamios

Lo que se quiere desarrollar se puede representar con algo como:

No es cierto que alguien pueda desarrollar una versión final directamente. Similar a un iceberg, las 9/10 partes de lo que se tiene que hacer queda debajo de las aguas.

Los andamios son necesarios para levantar y producir lo que se verá. Es la infraestructura util que sin embargo será removida y descartada luego. La construcción de andamios también es parte de la producción de software.

Aprovechar la computadora para explorar

El software de hoy es más complejo que el de los 70s, cuando era normal instar a resolver el diseño primero en papel y simulando mentalmente los procesos que realizaría la computadora.

Hoy es mejor aprovechar la potencia computacional disponible.

TDD (Test Driven Development) es una técnica que construye cajas de prueba que determinan cuando el software está cumpliendo lo que se requiere. TDD promueve un proceso de descubrimiento para diseñar software.

Hay partes del diseño que se puede realizar con más flexibilidad mentalmente, pero hay otras donde es más razonable usar la computadora. Permitirse codear, fallando y acertando, explorando, ayuda a tener una mejor estimación. 

¿Es necesario estimar?

Los manejadores de proyectos han sido entrenados a resolver problemas con contextos definidos, desempeños uniformes y destinos determinados.

Por otro lado, la mayor parte del desarrollo de sistemas consiste en adaptarse a un contexto cambiante y manejar los desempeños irregulares hacia destinos inciertos.

Y es insistir en usar buenas herramientas en un contexto equivocado lo que conduce a muchos de los problemas en el desarrollo de software.

El uso de estimaciones es un ejemplo de eso. No es muy util tratar de estimar algo en un contexto con tanta variabilidad. Se convierte en una tarea ingrata que solo produce halagos o llamadas de atención completamente arbitrarias. Sin embargo, es algo que se sigue haciendo.

#NoEstimates, de Vasco Duarte, es un libro que habla sobre eso.

En el video, Vasco explica como las estadísticas de story points muestran un comportamiento irregular sobre el que es inútil tratar de hacer estimaciones.

En cambio, el número de historias que puede resolver un equipo por periodo muestra un comportamiento más regular.

Es decir, es irrelevante tratar de asignar puntos de dificultad a las historias.

Y parece ser que las estimaciones en desarrollo de software vendrían a ser un error metodológico.