Ms NoBody y Mr. NoBody me invitaron, muy amablemente, eran buena gente, a tomar unas cerves con ellos. Y mientras, entre otras cosas, me contaron sus problemas aplicando Scrum y gestión Ágil.
Hasta aquí la historia no tendría nada de especial si no fuera porque Ms NoBody y Mr. NoBody trabajan en una constructora, una empresa que hace edificios, obras. Nada de software, cero.
Mientras me contaban las cosas «Ágiles» que no les encajaban, no me dejaba de resultar curioso estar hablando de cómo aplicar agilidad a un proceso de construcción de cosas físicas, como edificios… sabiendo como, en parte, la agilidad nace como un movimiento en contra de aplicar, en el mundo del software, los modelos de gestión típicos en arquitectura (edificios) e industria (cosas físicas) (de esto ya te hablé hace años en este post).
Aunque venimos diciendo desde hace años que la Agilidad se puede aplicar a contextos más allá del puro desarrollo software… eso no implica que se pueda aplicar de la misma manera, independientemente del tipo de producto que estemos creando (en este caso… edificios).
Sin ir más lejos, de entre muchos que podría citar, una premisa clave en eXtreme Programming es que la curva del coste de hacer un cambio en software debiera ser casi plana, es decir, debería costar siempre lo mismo hacer un cambio… aunque llevemos mucho tiempo trabajando con ese software.
En un edificio esa premisa, por ejemplo, no existe, cambiar un producto físico una vez hecho… es más caro que cambiar líneas de código. Y este es un argumento clave para evitar el uso de ciclos de vida en cascada al mundo del software y hacer uso de los iterativos e incrementales.
Claro que se puede aplicar mucho, y «agilizar» un proceso como el de la creación de edificios, toda la parte de equipos, multifuncionlidad, auto-organización, equipos estables, etc., todo eso, y mucho más, es muy probable que mejores mucho cualquier proceso de creación de algo. Incluso poder llevar hasta donde se pueda las ideas del iterativo, incremental e iteración.
Pero no va a ser igual que en software, que es dónde nació la Agilidad, en la programación (que algunos parece que no se acuerdan).
No digo que no se puedan aplicar las ideas, ni que sea peor, ni mejor, te digo que no puede ser igual y, probablemente, en productos físicos, no pueda ser en la misma medida.
Al final, queramos o no, aunque nos haga «salir de la moda», el producto que estás creando va determinar mucho hasta que punto puedes «agilizarte».
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Aunque las prácticas de agilidad y procesos iterativos e incrementales no puedan ser fáciles de aplicar en procesos constructivos de un edificio convencional, hay que ver otros paradigmas y conceptos de la arquitectura moderna y contemporánea como la arquitectura como producto, la arquitectura modular – la arquitectura móvil – la arquitectura como artefacto que puede ser insertada en cualquier lugar – la arquitectura como exploración del uso de materiales no convencionales – la arquitectura temporal, etc. Este tipo de arquitecturas pueden ser desarrolladas a partir de prototipos que pueden desecharse después de hacer pruebas de diversa índole como su comportamiento bioclimático o la aceptación de los usuarios, algo análogo a lo que sería un proceso iterativo como en el caso del software o en el desarrollo de un objeto de diseño industrial. Por otro lado dentro de la arquitectura y la construcción en términos convencionales los procesos ágiles, iterativos e incrementales se han aplicado y siguen aplicándose dentro de los procesos de diseño. En estos procesos puedes empezar con una idea en bozeto, o con prototipos en maqueta las cuales se van desarrollando con modelos (maquetas) cada vez más avanzadas agregando elementos en cada iteración hasta ir logrando distintos umbrales de desarrollo: Anteproyecto inicial, anteproyecto final, proyecto listo para ser sometido a legalización, anteproyecto para ser presentado en un concurso, etc. Así que como puedes ver hay muchas cosas interesantes en estas relaciones de la ingeniería de software no sólo con la arquitectura y la construcción sino en general con todas las ramas del diseño: industrial, producto, mueble, joyas, moda.