400440303. ¿Es informativo nuestro Espacio de trabajo?

¿Qué dice de nosotros nuestro espacio de trabajo?

Un atento observador de la escena actual del software podría haber registrado los siguientes ejemplos recientes de comportamiento peculiar en los equipos de desarrollo:
-# Un programador se toma tiempo libre cuando está realizando un trabajo de desarrollo en un importante proyecto de software corporativo para diseñar un circuito que puede controlar lámparas de lava. Al introducirse en el puerto paralelo del servidor CruiseControl del equipo – tarea que en el mundo post-DOS, .NET, implica encontrar la DLL correcta, acceder a la clase correcta y modificar uno de sus métodos- al final monta un dispositivo para encender bien una lámpara roja de lava cuando fallan las pruebas durante una compilación o una lámpara verde cuando se pasan todas las pruebas – es decir una compilación con éxito. Más tarde, añade una gran bola brillante de espejitos de discoteca que gira mientras se está produciendo una compilación. El equipo aplaude su logro.
-# Un equipo de desarrollo pasa horas todas las semanas moviendo tarjetas de índice en una pared cubierta de una rejilla de cajas. Cada caja contiene tarjetas de distintos colores perforadas con chinchetas estratégicamente coloreadas. Hay cuerdas que van de una chincheta en una caja a otra chincheta de distinto color en otra caja. Los miembros del equipo actualizan con celo las tarjetas y las mueven conforme a un rígido programa. Y esto no es una disciplina impuesta por uno de esos directivos a los que les encanta contar cuentas de collar, sino que es algo que hacen voluntariamente.
-# En una conferencia para desarrolladores, los programadores pasan horas construyendo casas de muñecas con pequeños personajes de LEGO y los colocan en alféizarres de ventana y debajo de mesas de despacho. Hablan intensamente de “mantener a raya a la policía mobiliaria”.

Imagen 1

El espacio de trabajo de Bjarne Stroustrup.

Otro “Brit ” en el Muro

Lo que se muestra en todos estos casos de comportamiento peculiar de programadores es uno u otro aspecto de los «Espacios de Trabajo Informativos», el Feng Shui de la metodología del desarrollo del software.

El lector tiene razón, no es nada más que palabrería. La única conexión entre los Espacios de Trabajo Informativos y la práctica china del Feng Shui es que los dos están relacionados con el efecto que un espacio de trabajo ejerce en los que trabajan en él.

Pero los Espacios de trabajo Informativos tienen realmente que ver con la construcción de mecanismos efectivos de feedback para dar soporte a los equipos de programación. Rachel Davies – que es la propietaria del dominio informativeworkspaces.org y por lo tanto debería saberlo- y David Hussman explicaron en una reciente conferencia sobre OOPSLA (acrónimo en inglés de Aplicaciones, Lenguajes y Sistemas de Programación Orientados a Objetos) que estos mecanismos de feedback normalmente se incluyen en una de estas dos categorías generales:
– (1) presentaciones visuales no electrónicas y manualmente actualizadas, y
– (2) dispositivos electrónicos vinculados a procesos automatizados.

Al primero, en el familiar estilo de Capitalizar Conceptos Importantes de Patrones de Diseño, se le denomina “Radiadores de Información”, y al segundo “Dispositivos de Feedback eXtreme”. En un boletín informativo de la Sociedad de Computación Británica, Ian Alexander y Kathleen Maitland se refirieron a esta terminología como la “horrible jerga neoBlairita” y sugirieron sustituir el término «Radiadores de Información» por el más breve de «El Muro», que yo creo se podría denominar en justicia “neo-PinkFloydita”.

Pero los términos tienen significado. La parte “Información” o “Informativo” implica, por ejemplo, que los muros deberían hablar. Tal y como lo refleja Kent Beck, cuando un observador interesado entra en el espacio de tu equipo, él –o ella- debería poder obtener en 15 segundos una idea general de cómo va el proyecto, y poder obtener una perspectiva más profunda de los problemas reales o potenciales al mirar con más detenimiento. Espacios de trabajo Informativos

Flujo de trabajo y flujo de lava

El proyecto de la lámpara de lava que se ha descrito aquí es un respetado ejemplo de Dispositivo de Feedback eXtreme. De hecho, es tan respetado que ha conseguido un cierto estatus de culto. La motivación tras la construcción de este tipo de dispositivos, como el fundador de Agitar Software, Alberto Savoia lo describe, es “hacer que nuestro equipo preste atención al estado del proyecto/software y a las métricas que importan.”

Feedback Extreme no necesariamente quiere decir mucha cantidad de feedback, tal y como indica Savoia. De hecho, los dispositivos como las lámparas de lava ofrecen una muy pequeña cantidad de información, tan pequeña como un bit, pero es una información muy, muy importante (“las métricas que importan”) y se entrega de manera continua y automática.

Otros equipos han empleado dispositivos distintos para el mismo fin, incluidas auténticas luces de tráfico, Bolas Ambientales, cubos LED, un dispositivo acuático (mantener fluyendo la cascada, derramándose el cubo, etc. para continuar con éxito la construcción) efectos de sonidos como sirenas, presentaciones LED, y en un caso, un obstáculo de rastreador que hizo que un ciervo de escayola se cayera de espaldas, con las patas en el aire y agitando una bandera que decía «¡Ayuda! ¡El build se ha detenido!”

El extremadamente eXtreme Feedback Device propuesto por un programador — una herramienta de entrada que usara la subversión para identificar al programador o programadores responsables del último fallo del build, que orientara al lanzador de misiles USB según correspondiera e hiciera rebotar un misil (de gomaespuma) en la cabeza del culpable – no ha podido ser implementado todavía con éxito.

El equipo que pasaba todo el tiempo actualizando las tarjetas de indexado coloreadas estaba manteniendo el Radiador de Información.

Los radiadores de información llevan más bits que los Dispositivos de Feedback eXtremes, y sirven para fines diferentes. Hay mucha variedad en la forma en que los equipos implementan los Radiadores de Información, pero todos son grandes diagramas visibles que reflejan importantes métricas del estado actual del proyecto.
Un dispositivo que podría utilizar cualquier equipo es una pizarra para el “lanzamiento de ideas” o “brainstorming”.

Este lanzamiento de ideas podría tomar la forma de desarrollo de historias (más o menos equivalente a características), que puede llevar al establecimiento de un panel con tarjetas (para representar estas historias) que pueden ser movidas por el panel según se va avanzando en la idea. Quizá una fila de tarjetas que represente el trabajo de una semana.

Un equipo usó tarjetas verdes para marcar características para usuarios finales, tarjetas verdes para características para uso del personal, banderas naranjas y rojas para distintos estadios en la finalización, etiquetas amarillas para los hitos, y notas de post-it rojas para tipos concretos de preguntas.

Otro equipo puede usar cuadrados de colores sobre una pizarra blanca para representar el estado de las pruebas: Rojo para las que han fallado, verde para las que han pasado y X para las pruebas todavía no realizadas. Y además están los diagramas burn. Estos diagramas simplemente marcan el grado de finalización del proyecto o la tarea en el tiempo, aunque los matices sobre cómo se realiza ese marcado es en lo que versa el Espacio de trabajo Informativo o IW, por sus siglas en inglés.

Tal y como indica Alistair Cockburn, la elección de los hitos adecuados es fundamental, y puede significar que nos enteremos pronto de las cosas que funcionan mal – y así poder poner remedio. Además, hay opiniones distintas sobre si es mejor utilizar un diagrama burn hacia abajo, que desciende hacia una meta de cero pasos por dar, o un diagrama de quema hacia arriba, que se eleva hasta la meta de la finalización al 100 por cien.

¿Y qué hay de los programadores que construían casas de muñecas? Participaban en un taller para considerar las características que eran buenas y malas en la distribución de los espacios de trabajo.

Como más allá de los Dispositivos de Feedback eXtreme y de los Radiadores de Información, el concepto de los Espacios de Trabajo Informativos también abarca la distribución física del espacio de trabajo del equipo, incluidas las formas y orientación de las mesas/escritorios (que no moleste la cavidad de las rodillas, que los escritorios estén orientados de tal forma que faciliten la programación en pareja si eso es parte de nuestra metodología), el espacio común y una distribución general que hace que todos tengan que caminar por el espacio de trabajo del equipo para llegar a cualquier espacio privado e individual – para así garantizar la interacción. (Aquí es donde empieza realmente a sonar un poco como Feng Shui).

Algo que los participantes en el taller aprendieron fue que queda mucho que aprender sobre la mejor manera de aplicar los Espacios de trabajo Informativos para nuestro equipo de programación. Algunos de estos Dispositivos de Feedback eXtreme y Radiadores de Información son mejores que otros, o al menos mejores para nuestro equipo, y debería quedar claro tras pensarlo un momento cómo la moral y la concentración se verían afectados si, a intervalos no predecibles, saltara una sirena en el espacio de trabajo de nuestro equipo.

Artefactos de Agilidad

Conscientemente he pasado por alto la tarea de colocar los Espacios de trabajo Informativos en el lugar que le corresponde dentro de las jerarquías conceptuales e históricas de las metodologías de diseño de software, pero debo al menos reconocer que los Espacios de trabajo Informativos es un concepto desarrollado en el contexto de la metodología de diseño Ágil. Da por supuestos muchos de los aspectos que caracterizan el desarrollo Ágil, incluido el énfasis en la programación en pareja, el alto grado de interacción entre los miembros del equipo y el desarrollo orientado a la comprobación.

Si no estamos realizando un desarrollo Ágil, puede que tengamos que traducir parte de la terminología o incluso algunas de las ideas de Espacios de trabajo Informativos, pero aún así encontraremos bastantes cosas útiles. Y me da la impresión de que, a pesar de las protestas de los puristas, muchos equipos de desarrollo seleccionan elementos de estas cuidadosamente construidas metodologías y eliminan otros elementos, y terminan así con su propia metodología específica para el equipo y el proyecto. Y si les funciona, ¿por qué no?

Así pues, ¿Cuál es la experiencia de trabajar en un Espacio de trabajo Informativo? Es probable que hayan observado un tema recurrente en algunos de los detalles que aquí se describen sobre el Espacio de trabajo Informativo: Una sensación de diversión, de extravagancia. Esas lámparas de lava, por ejemplo.

Pues resulta que el par de lámparas de lava es un excelente dispositivo de feedback, porque ofrece una señal clara y sin ambigüedades, sin ser detestable. Y son algo extravagantes, lo que también hace que sea una característica tremendamente deseable en un entorno de trabajo, al menos según mucha de la gente que ha aplicado los Espacios de trabajo Informativos.

Pero ¿cumple con su función? ¿Cuál es el veredicto de los Espacios de trabajo Informativos y la productividad?

A primera vista, parece extraño que para una disciplina que pone tanto énfasis en las comprobaciones haya poco más que pruebas anecdóticas del éxito de la misma. Pero de hecho, es difícil de imaginar como podríamos construir un estudio científico para comparar dos metodologías de software distintas. ¿Podríamos realmente asignar programadores de forma aleatoria a grupos experimentales, dar a cada grupo una metodología a usar y un proyecto de meses a solucionar, y observar sus resultados?

Suena poco práctico, pero parece que cualquier otra cosa que no se le parezca resultará en un sesgo de auto-selección u otros problemas de diseño experimentales. Y además está el problema de definir el éxito. Un objetivo de los Espacios de Trabajo Informativos es la satisfacción de los programadores.

Eso, al menos, es no sólo mensurable, sino además darviniano. Si IW hace que los programadores se sientan más a gusto y los programadores tienen influencia sobre las metodologías que utilizan en los proyectos de desarrollo de software, IW crecerá.

Y además hay pruebas de que los Espacios de trabajo Informativos hacen sentirse a gusto a los programadores. Una investigadora canadiense (Elizabeth Whitworth, «Agile Experience: Communication and Collaboration in Agile Software Development Teams,» Carleton University) habló con una importante muestra de desarrolladores Ágiles y no-Ágiles y averiguó que los Espacios de trabajo Informativos como elemento del desarrollo Ágil «se veían como algo realmente motivador, que hacía más probable que los miembros del equipo…. exhibieran un fuerte sentimiento de orgullo, motivación y entusiasmo por su trabajo.»

Y eso no puede ser malo.

DDJ

1N. del T: Referencia a la canción “Another brick in the wall” (El Muro) de Pink Floyd y juego de palabras entre “brit” (británico) y “brick” (ladrillo).