A fines de los 90′, cuando se comenzaba a hablar de Extreme Programming y otras propuestas similares como Scrum, DSDM u otros, se les llamaba en conjunto “metodologías livianas”, en contraste con el sobrepeso del imperante ciclo de cascada basado en “analizar-diseñar-implementar-probar”. Sin embargo el término “liviano” poseía un sesgo negativo, por lo que al juntarse los mayores proponentes dichos métodos, decidieron que era mejor hablar de “agilidad”.
La agilidad es entendida como la capacidad de adaptarse de buena manera a los cambios, lo que en el incierto mundo del desarrollo de software es la norma. Sin embargo, este concepto halla sus raíces en una industria que, al igual que la informática, en algún momento lideró la inventiva humana: la automotriz.
Luego de que Ford aplicara como innovación en la producción de automóviles la llamada “gestión científica” promovida por Taylor, logró efectivamente disminuir brutalmente los tiempos de producción al planificar en detalle cada paso de la línea de ensamblaje y al especializar radicalmente a los obreros en tareas específicas y aisladas, pero con una gran falla, que Ford enunciaba como virtud : You can paint it any color, so long as it’s black”. - “Puedes pintarlo (el auto) de cualquier color, mientras sea negro” -
La empresa Toyota planteó un modelo que permitía pasar por sobre esta rigidez productiva, permitiendo configurar la fábrica de autos de manera ágil siguiendo un principio fundamental: “eliminar desperdicios”. ¿Qué es un desperdicio? Todo aquello que no aporte valor. En un proceso productivo, que se encarga de generar de manera repetitiva una línea de productos, podemos encontrar varios tipos de desperdicios (del excelente libro “Lean Software Development” de Mary y Tom Poppendieck), nombrando algunos:
- Inventario: Productos estacionados en bodegas
- Sobre-producción
- Transporte
- Esperas
- Defectos
Si estamos hablando del mundo de la producción, ¿que pasa con el del desarrollo? Primero debemos notar que entre ambos existe una gran diferencia: mientras en el primero se buscar generar repetidamente un producto, en el segundo se está creando el producto. No es lo mismo hacer un queque de alguna fruta exótica, digamos sandía, que inventar la receta de dicho queque, en donde hay que enfrentar varias incertidumbres, como los es el uso de una fruta poco conocida para este tipo de pasteles. Aquí aparece el concepto de “desarrollo de nuevo producto“, que refleja la incertidumbre como parte de la naturaleza de toda invención.
Si aplicamos el principio de “reducción de desperdicios” al desarrollo de software en particular, podemos hacer un parangón entre los desperdicios anteriores y los de un desarrollo:
| Producción |
Desarrollo de Software |
| Inventario: Productos estacionados en bodegas |
Funcionalidades a medio hacer |
| Sobre-producción |
Sobre-ingeniería: funcionalidades que no se necesitan realmente |
| Transporte |
Cambios de contexto entre tareas |
| Esperas |
Esperas |
| Defectos |
Bugs |
¿Cómo está relacionado lo anterior con lo que conocemos de las metodologías ágiles? la primera relación obvia está en la generación de software funcional y útil para el cliente lo antes posible dentro del desarrollo de software a través la permanente retroalimentación con los desarrolladores, lo que a su vez evita cuellos de botella en el flujo de conocimiento y, por ende, tener que esperar información importante para poder continuar trabajando.
¿Qué sacamos de todo lo anterior? Que las metodologías ágiles no aparecieron de la nada, existiendo una vasta experiencia anterior. Pero lo más importante es que hay un Norte (o Sur si nos ponemos nacionalistas) al cual referirnos siempre si queremos adaptarnos nuestra forma de trabajar frente a imprevistos, y es la permanente y porfiada reducción de lo que no sirve, o dicho en positivo, la búsqueda permanente del mayor valor.
)
Recent Comments