Omitir navegación.
Principal

CuestionesMetafóricas


Experiencias e informes

Escrito por Martin Fowler
Traducido por Rafael Vacas
Revisado por Ismael Ferrer

Como mis lectores habituales saben, se me conoce por usar metáforas de otras profesiones para razonar acerca del desarrollo de software. En particular, creo que la metáfora de la ingeniería ha hecho mucho daño a nuestra profesión - en cuanto a que ha promovido la noción de separación entre diseño y construcción.

Esta misma cuestión nos surgió en nuestra oficina de Londres en el contexto de la industria textil - una metáfora usada a menudo en los círculos ágiles - particularmente por los Poppendieck.. Así como no me gusta mucho razonar mediante la metáfora de la ingeniería civil, ¿me gustará más la metáfora de la industria textil?.

Pienso que tienen los mismos peligros, pero todo depende de como se haga uso de la metáfora. Hacer comparaciones con otra actividad es útil si te ayuda a formular preguntas, pero es peligroso si lo utilizas para justificar respuestas.

Como ejemplo, uno de los principios de la industria textil es la eliminación de inventarios. Esto nos lleva a preguntarnos si existe algo análogo al inventario en el desarrollo del software. Hay quien sugiere que lo análogo es la documentación 'up front'. Está ahí, sin aportar valor, hasta que realmente hay un software que entregar que se basa en dicha documentación.

La metáfora nos ayuda a observar nuestras prácticas desde otro punto de vista. Nos ayuda a formularnos preguntas sobre lo que hacemos. En este sentido, creo que la metáfora es útil.

El punto de conflicto surge cuando la gente dice: "eliminamos los inventarios en la industria textil, la documentación 'up front' es el equivalente al inventario, entonces eliminamos la documentación 'up front'. Aquí estoy de acuerdo en que necesitamos reducir substancialmente este tipo de documentación especulativa; pero este razonamiento debe surgir de pensar en el proceso de desarrollo de software, y no de pensar en la analogía.
Artículo Original