El Lego y la plasticidad del software

Hola a todos

Como muchos saben, comencé en el mundo del software desde mi carrera de origen, "la ingeniería civil" - muchos en el mundo del software venimos de otras áreas -, en esta carrera se programa bastante (al menos en mis tiempos) y luego profesionalmente fuí girando desde sistemas de información geográfica hasta estar completamente en el mundo de las clases, los métodos, los NullPointerException, etc, hice mi especialización, terminé mi maestría, y desde hace un buen tiempo navego en el sinfín de certificaciones, cursos, amores y desencantos de los proyectos de software.

Muchas cosas me quedaron de mi "anterior reencarnación":

• saber a simple vista como una columna esta torcida, 
• saber presupuestar proyectos civiles y cantidades de obra, 
• saber cuando comprar o no una casa.
• entre otras

Hoy en día cuando comparto con mis compañeros gerentes de proyectos de software, aprendices a Scrum Master, desarrolladores, tanto en los cursos como en nuestras discusiones sobre proyectos, hablamos de que no aplican los principios de planeación predictiva de ingeniería civil a ingeniería de software - y eso que dudo que seamos una ingeniería -, y es solo mirar este APU (Análisis de Precios Unitarios)

APU (Análisis de Precios Unitarios) (1)

Tan pulido, tan perfecto, que hasta tiene determinado cuanto va a ser el desperdicio de cantidades de obra (10%). Es sino decir cuanto va a medir el muro y sabremos:

• cantidades de obra (ladrillo, cemento, arena)
• tiempo de construcción
• elementos adicionales requeridos

Cuanto quisiéramos nosotros que fuera así para nuestra industria, pero la incertidumbre en software es brutal -es nuestro pan de cada día-, se encuentra entre el 25% y el 400% tendiendo con mayor seguridad al 400% (todos sabemos que sí), ver el cono de la incertidumbre para software:

Cono de la incertidumbre (2)

Y para acabar de ajustar aunque te encuentres en la zona de construcción del software del cono, le preguntas a alguien del equipo:

- ¿y en cuanto crees que terminas esa funcionalidad?
- mmm, pues yo creo que en tres horitas más
- Ok, quedo atento, me cuentas cuando termines(3)

y resulta que era el mejor ingeniero y se demoró 6 horas, que sucedió entonces:

• algo se desconfiguro en el servidor
• la clase era mas compleja de lo esperado
• no le refrescaba bien lo que quería ver
• o simplemente ese día "no daba pie con bola"- pues hacer software es una actividad intelectual y creativa-  pero se levantó al siguiente y todo quedó resuelto.

¿y es mal ingeniero? 

¿se robó esas tres horas de más? pues ese tiempo no era el estimado (una pequeña reflexión a este respecto acá - Una pequeña diatriba: ¿quién/cómo van a reponer ese tiempo? )

Hombeeeee.. la verdad no..

Solo que un estimado, es un valor que tiene asociado un valor de probabilidad, que lo vamos ajustando en la medida que avanzamos en el conocimiento de lo que estimamos, y solo sabremos cuanto duraría la tarea (hablo de software) cuando por fin la terminamos.

Como decía Peter Drucker si "el reto en el siglo pasado era  la productividad de los trabajadores de manufactura, el reto de este es la productividad de los trabajadores de conocimiento"(4), y resolver esto será la clave del éxito de nuestras organizaciones de conocimiento. Pero tengamos seguro algo, las herramientas de uno, no funcionaran bien en otro.

Yo le insisto mucho a mis compañeros con frases como:

• no estamos pegando piezas de lego, que son lisas y encajan perfecto
• es que no son albañiles, no se puede hacer como con los muros, que si el muro quedo a la mitad no puede llegar otro a terminarlo con las mismas características (gracias @luchosalazarc por este ejemplo)
• como Carlos se imagina la solución no es igual a como la hace Luisa ambos piensan distinto e interpretan diferente, uno lo ve menos acoplada, otro más dinámica.
• metiendo más gente no vamos a terminar más rápido, van a estorbar manos, igual en un edificio donde se tengan muchos obreros llegará el momento en que se dirá: "no más", después de este punto somos improductivos
• No podes pedir predictibilidad sobre algo incierto y plástico que 
• Carlos lo ve gigante 
• Luis lo ve pequeño
• Juan lo ve complejo
• y Diana lo ve de tamaño regular
• y para acabar de ajustar todos tienen la razón pues la claridad con la que se acercan al problema depende de cuantos problemas similares hayan resuelto, cuanta experiencia tengan con la herramienta, y de la ayuda de sus compañeros

He observado que es más exitoso en soportarse en las herramientas que proporciona la agilidad:

• frameworks como scrum
• la gestión empírica de proyectos basada en la inspección y adaptación
• el planning poker y su escala de fibonacci
• los sprints de 2 semanas que nos permite conocernos como equipo y conocer la complejidad de estimación del sistema
• las retrospectivas como habilitadoras del aprendizaje
• Apuntarle al pareto del sofware (20% del software resuelvel el 80% de las necesidades de negocio) y no constuir software innecesario
• Soltar el alcance fijo, tiempo fijo, y costo fijo y centrarnos en la generación de valor fundamentada en la confianza de un gana-gana entre cliente y proveedor

Es más provechoso ser ágil

Concluyo con tres frases importantes:

HACER SOFTWARE NO ES UNA ACTIVIDAD PREDICTIVA

HACER SOFTWARE NO ES UNA ACTIVIDAD PREDICTIVA

HACER SOFTWARE NO ES UNA ACTIVIDAD PREDICTIVA

Saludos ágiles

Jorge Abad

Notas, Observaciones y Referencias

(1) Para ver más análisis de precios unitarios clic aquí  

(2) Tomado de "Estimating" en msdn.  clic aquí

(3) En scrum no ocurre esto, pues hay dos mecanismos de actualización uno el tablero kanban y el segundo es el daily donde todos sabemos que se terminó y que sigue en curso.

(4) Parafraseando un poco lo que el decía, la cita original es:  Según Peter Drucker1: “ La más importante, y en realidad la verdaderamente única, contribución de la ciencia de la gestión en el siglo XX fue el incremento, en 50 veces, de la productividad del trabajador manual en la producción.

La más importante contribución que la gestión necesita hacer en el siglo XXI es, de manera similar, incrementar la productividad del trabajo del conocimiento y del trabajador del conocimiento. El activo más valioso de una compañía del siglo XX era su equipo de producción. El activo más valioso de una institución del siglo XXI (sea o no de negocios) serán sus trabajadores del conocimiento y su productividad.” para ver más clic aquí.

(5) ¡Me desahogué!, hacia tiempo tenía pendiente escribir este post.