Ingeniería o Artesanía v1

Hace tiempo que se trata de encontrar una analogía al desarrollo de software. Es un arte, una ciencia, un conjunto de técnicas,...

¿Por qué es esa discusión interesante?

Porque siendo el software una actividad relativamente joven, buscamos utilizar la experiencia existente en otras actividades, por ejemplo para copiar como enseñamos, como organizamos el trabajo y como lo evaluamos.

Diego Fontdevila, Pablo Rodríguez Facal, Vanesa Dell'Acqua y Juan Gabardini nos reunimos en una sesión de Agile Open Buenos Aires 2009 para hablar de estos temas, y estas son nuestras notas.

¿Por qué buscamos la analogía?

¿No podemos simplemente admitir que el software es distinto y analizarlo per se, sin buscar analogías?

Podemos, pero cuando se trabajan con nuevos conceptos, ni siquiera tenemos las palabras para describirlos, lo que hace difícil pensar y discutir sobre ello.

Por ejemplo, Philosophiae Naturalis Principia Mathematica de Newton no es el libro que usamos para aprender física o cálculo matemático. A lo largo de los años se ha mejorado el lenguaje y la forma de explicar los conceptos.

Si logramos una buena analogía, podemos usar el lenguaje y modelos mentales ya probados.

Micah y Bob Martin proponen la idea de artesanía (video en Ágiles 2008 y manifiesto).

Artesano u Operario

Creemos que la analogía se basa en la comparación de las personas que fabricaban artefactos complejos de manera artesanal, a fines del 1800 o principios del 1900. Podemos comparar a estas personas que fabricaban artesanalmente relojes o automóviles versus el operario en una linea de montaje tipo Taylor/Ford.

El resultado del trabajo del artesano es un artefacto de complejidad considerable pero se producía de forma artesanal debido a la falta de la tecnología que permitiera automatizar los procesos (y porque Ford y Taylor todavía no habían metido la cuchara, je).

Pero es útil comparar al desarrollo de software con la fabricación?

Que analogía usamos:

- producción (silla hecha a mano vs silla hecha en linea de producción)

- diseño (diseño de la silla

vs cuadro o escultura de la silla)

- ingeniería civil (diferencias entre el diseño del edificio y el obrero que lo construye - en nuestro entorno el compilador es el "obrero" mientras que cuando programamos estamos haciendo "diseño"). El problema de esta analogía es que en general cuando hablamos de ingeniería civil estamos tratando con un entorno medianamente estático (la estructura del terreno donde se construye un edificio se considera constante) mientras que en software, el entorno cambia permanentemente, cambian las reglas de negocios, las regulaciones y legislaciones, los usuarios, etc.

En muchos casos, parece que el desarrollo de software se parece más al diseño de productos que a la producción repetitiva de los mismos.

Acá tenemos una primera conclusión: si comparamos entre el artesano y el operario, ¡el desarrollador es artesano!

Esta definición no es poco, cuantas veces nos encontramos con formas de trabajo en las que el programador sólo implementa lo que definió el diseñador, que a su vez se basó en lo que dijo el analista.

Ingeniero o Artesano

Esta comparación es más difícil, y cada uno tiene en su cabeza definiciones distintas de Ingeniero y Artesano.

Artesanía: Consiste en la construcción o producción de un objeto complejo, pero el balance de entre resultados y costos es en general desfavorable ¿?

Ingeniería: Consiste en resolver problemas

complejos, siempre con un balance o compromiso entre los resultados y los costos.
Artesanía -> ¿Técnica? Algo hecho directamente por las manos

del hombre con herramientas.
Ingeniería -> ¿Tecnología? Algo hecho indirectamente por las manos del hombre con máquinas capaces de

repetir su trabajo.

¿Open Space es una tecnología o una técnica?

Orgullo de lo producido

Cabe a ambos, el artesano y el ingeniero, en función de su identificación con el producto de su trabajo.

Produce una de las condiciones fundamentales que es la satisfacción con el trabajo por el trabajo en sí. Puede ser conflictivo si implica que tome precedencia sobre la percepción de valor que tiene el usuario final o el cliente.
En ambos casos hay criterios estéticos y de elegancia, aunque no necesariamente compartidos con el usuario. Un ejemplo: para algunos las ecuaciones de Maxwell son elegantes y tienen la belleza de la simetría. Otro ejemplo, en las artes marciales, cuanto más se sabe, menos movimientos se requieren.

¿Están menos orgullosos los ingenieros que participaron en el diseño y construción del Alfa Romeo 8C Competizione que lo que estaría un artesano?

Entonces, ¿cuál es la diferencia?

Separación entre la creación y el producto final

Una posibilidad es que la diferencia esté en la distancia con lo "real", distancia semántica (usamos distintas palabras, distintos idiomas).

Un artesano conoce bien las herramientas, el material con el que trabaja, el producto que realiza. El ingeniero puede hablar el idioma científico para tomar novedades que pueda aplicar en forma novedosa. Puede tener una mayor capacidad para manejar distancia semántica. Pero eso conlleva el riesgo de alejarse del día a día.

El equipo y el especialista
¿Qué sabe cada uno? ¿Qué parte de lo que sabe se pone en juego en el trabajo conjunto? El equipo es un espacio común definido por un espacio físico (Gemba, en japonés el "Lugar real" donde se produce valor) y un lenguaje común. Este lenguaje limita los conceptos que pueden manejarse (pensamos con las palabras que tenemos a nuestra disposición). Un ejemplo de lenguaje común es el que se desarrolla cuando los integrantes del equipo aprenden del negocio. Sin embargo, muchas cuestiones propias de los especialistas quedan fuera. El problema aparece cuando ese lenguaje no es capaz de describir todo lo necesario (lógica, comportamiento, interfaces, etc.) En el futuro, es posible que se desarrollen lenguajes propios de cada dominio de problema, o que se formalice el lenguaje del equipo para soportar tanto el negocio como la lógica del software.

El compromiso es aprender, es decir expandir siempre los límites de nuestra ignorancia, alejando a cada paso el horizonte de lo que hay por aprender. ¿Cómo aprende el equipo? Como en Toyota, podrían seleccionarse responsables de aprender o desarrollar ciertos temas o capacidades (costos, calidad, seguridad, etc.) y cada cierto tiempo rotar esas responsabilidad. Este sistema funciona muy bien para temas que escapan a la especialidad de todos los miembros del equipo.

Y nuestra segunda conclusión: todos tenemos que conocer las herramientas, nunca alejarnos mucho del gemba, y quizás somos ingenieros si nos preocupamos en diseñar no sólo el producto, sino también mejorar o crear nuevas herramientas.

¡Da para más! ¿Cómo impacta en la educación? ... lo seguimos en el próximo Agile Open