h1

Agile Software Development: The Cooperative Game

12/07/2011

Wizbook [Icon By Buuf]  Libros.

Mientras más elaborados nuestros medios de comunicación, menos nos comunicamos.

Joseph Priestley (1733 – 1804), teólogo, filósofo, científico, educador y teórico político inglés.

El libro Agile Software Development: The Cooperative Game es una buena lectura para aquellos que quieran conocer los principios y filosofía detrás de las metodologías ágiles. Con entretenidas analogías, tales como comparar al desarrollo de software con la escalada de montaña e interesantes anécdotas salidas de lugares tan dispares como el Lockheed Skunkworks y el famosísimo Proyecto C3 de la Chrysler (donde Extreme Programming hizo su aparición), el autor Alistair Cockburn nos muestra cómo la dinámica de grupo entre los diferentes actores de un proyecto puede influir en el éxito o fracaso del mismo, indicando las trampas que socavan el así denominado flujo de información y mostrándonos cómo pueden evitarse para llevar a buen término un proyecto de esta índole.

La imposibilidad de la comunicación

Desde pequeños detalles de información que sólo se quedan en la mente de algún programador, hasta la falta de retroalimentación temprana entre el usuario, el patrocinador y el equipo, la falta de comunicación entre los stakeholders es uno de los principales problemas que afectan la productividad en un proyecto de desarrollo de software. Esto sucede porque es muy difícil comunicar adecuadamente un pensamiento sencillo – por ejemplo, la palabra “manzana” significa cosas muy diferentes para cada persona. Entonces comunicar reglas de negocio, requerimientos o pensamientos aún más abstractos es prácticamente imposible. Por ello, este libro intenta resolver dos grandes interrogantes:

• Si la comunicación es fundamentalmente imposible, ¿cómo puede la gente en un proyecto lograr comunicarse?

• Si todas las personas y proyectos son diferentes, ¿cómo podemos crear reglas para alcanzar proyectos productivos?

La primera cuestión permite al autor mostrar la teoría subyacente tras una serie de técnicas que facilitan la comunicación, tales como programación por pares, iteraciones cortas, equipos colocados, maquetas, retrospectivas, etcétera. La segunda es la base para explicar y demostrar cómo trabajan las metodologías de desarrollo ágil como Extreme Programming, Crystal Clear o Scrum.

Escalada de montaña

De acuerdo al autor, el desarrollo de software es un “juego colaborativo”. Es decir, dentro de la teoría de juegos, ésta es una actividad finita de conlleva procesos de decisión, donde los jugadores trabajan para alcanzar una estrategia de ganar-ganar y continúan en el juego mientras consideren que ésta vale la pena. La analogía propuesta por el autor, y que me parece muy interesante, es comparar al desarrollo de software con la escalada de montaña, ya que algunas de sus similitudes incluyen:

• Trabajo en equipo. En ambos casos existen personas que trabajan solas, pero en términos generales, estas actividades son llevadas a cabo por un equipo que posee fuerzas y debilidades que favorecen o entorpecen el juego.

• Individuos con talento. En ambos casos existen personas que se desempeñan mucho mejor que otras. Algunos escaladores no treparán jamás ciertas cumbres, mientras algunos programadores jamás podrán desarrollar ciertas clases de software.

• Uso de herramientas especializadas. Para cualquier escalada o desarrollo es indispensable contar con las herramientas adecuadas, tales como arneses, sogas, dados o mosquetones; IDEs, una correcta PC o laptop, frameworks y patrones de diseño. Mientras más extensa o difícil la iniciativa, más crítica se vuelve la selección de dichas herramientas.

• Un plan. Desde subir algunas piedras hasta una escalada de múltiples días, mientras mayor dificultad para alcanzar la meta, más extenso y detallado debe ser el plan. Un punto importante a considerar por todos los involucrados es que dicho plan probablemente será insuficiente y en algunos casos, completamente incorrecto.

• Improvisación. Obstáculos imprevistos o impredecibles pueden presentarse incluso en los planes más meticulosamente detallados, a menos que la meta sea muy fácil de alcanzar y el proyecto posea un equipo extraordinariamente experimentado.

• Peligroso. Tal vez el peligro de morir por una mala decisión en el alpinismo no es tan fácil de trasladar a la industria de software. Sin embargo, en caso de tomar una mala decisión durante la definición de la arquitectura o el diseño de ciertos componentes críticos sí puede provocar la cancelación del proyecto e incluso la pérdida del trabajo, que en estos tiempos de incertidumbre económica es casi tan estresante como el miedo a morir.

Aunque escalar montañas es mucho más acertado que la vieja metáfora de “construir edificios“, comparto la opinión de Jeff Atwood en el blog Coding Horror: si el objetivo número uno es alcanzar la cima, el número dos es arreglar todo para que otros equipos también alcancen la cima – comúnmente denominado como soporte y mantenimiento o sustaining. En muchos casos, ambos objetivos son mutuamente excluyentes, lo que provoca la muy común falta de documentación, ya que es siempre preferible entregar algo funcionando que documentarlo al detalle. Es más, en todos estos años que he laborado en la industria jamás me he topado con un desarrollo que haya dejado tras de sí una buena documentación. Por ello estrategias como la denominada arqueología de software.

Comunicación osmótica

Uno de los capítulos más importantes del libro se refiere a la eficiencia en que la comunicación fluye de un miembro del equipo a otro. Cockburn explica que con una mayor cohesión del equipo y menor latencia en la comunicación, existe una mejor diseminación de la información entre el resto del grupo, como si se tratara de un proceso de ósmosis:

La comunicación osmótica significa que la información fluye en el fondo auditivo de los miembros del equipo, de tal forma que ellos captan la información relevante, como si fuera por ósmosis. Esto se realiza normalmente por estar en la misma habitación. Así, cuando una persona hace una pregunta, otros en la habitación pueden sintonizar o desconectarse, contribuyendo a la discusión o continuando con su trabajo. Muchas personas han relatado su experiencia de manera parecida a la siguiente anécdota:

Teníamos cuatro personas realizando programación por pares. El jefe se acercó e hizo una pregunta a mi compañero. Yo comencé a responderla, pero di el nombre equivocado de un módulo. Nancy, programando con Neil, me corrigió, sin que Neil se diera cuenta siquiera que ella había hablado o que se había formulado una pregunta.

— Alistair Cockburn. Osmotic Communication.

Esto se ejemplifica perfectamente en un plano de oficina muy parecido al siguiente:

Plano de oficina

Plano de oficina, mostrando las diferentes áreas de una pequeña compañía de investigación y desarrollo. El área de “innovación”, a la derecha del plano, está bien adaptada para desarrollos ágiles (Fuente: inventables.blogspot.com)

El plano de oficina muestra algunas técnicas ágiles que impulsan la comunicación entre los miembros del equipo, incluyendo:

• Estar sentados lo más cerca posible. De acuerdo al principio de comunicación de la longitud de un autobús definido por el mismo Cockburn, “la comunicación entre las personas cae radicalmente tan pronto como la distancia entre ellas sobrepase la longitud de un autobús escolar.” Si no es posible tener a todos en el mismo espacio, es recomendable usar las maravillas de nuestra era, como chat y videoconferencia.

• Contar con paneles o pizarrones que desplieguen la Estructura de Descomposición del Trabajo o Product Backlog a la vista de todos, con el estatus de ejecución de cada componente o tarea. Cockburn denomina a este tipo de paneles como radiadores de información.

• Un pizarrón de reflexiones, con los resultados de una retrospectiva realizada al final de cada iteración, desplegando qué está haciendo bien el equipo y cuáles son sus áreas de oportunidad, parecido al siguiente ejemplo:

Retrospectiva

Resultados de una retrospectiva, mostrando el desempeño del equipo durante la pasada iteración. A la izquierda lo que hicieron bien, a la derecha lo que necesitan mejorar. (Fuente: industrialxp.org)

En principio la comunicación osmótica suena muy interesante, sin embargo por experiencia me he dado cuenta que tener a todo el equipo en el mismo espacio ayuda mucho en proyectos de hasta 8 personas, pues en equipos más grandes la colocación se vuelve un detractor: cuando hay muchas personas reunidas en un mismo lugar, incluso si son muy quietas, generan ruido. Ante este tipo de interferencia, ¿qué es lo primero que hacen los desarrolladores? Ellos se colocan sus audífonos, obstruyendo o eliminando por completo cualquier intento de comunicación. De hecho, el “estatus” que cualquiera de nosotros mostramos cuando nos colocamos uno de estos aparatitos es: estoy ocupado; favor de no molestar.

Ahora bien, ¿qué pasa si enfrentamos un proyecto distribuido? Nuestra dependencia en la tecnología se incrementa exponencialmente, además que es necesario seguir toda una serie de reglas de etiqueta para alcanzar una colaboración satisfactoria. Esto por supuesto, cambia la dimensión de lo que significa una comunicación osmótica.

Conclusiones

En términos generales, el autor está muy influenciado por Extreme Programming. Esto no es malo, sin embargo XP no es la metodología ágil más usada en el mundo; de hecho una gran parte de las técnicas de mejora en la comunicación pareciera que vienen directamente de Scrum. Lo interesante consiste en encontrar la teoría detrás de muchas de estas técnicas. Por ejemplo, las maquetas o demos que se muestran a los usuarios al final de toda iteración deben invitar a la reflexión y retroalimentación “en el momento”, debido a que los seres humanos podemos absorber información con mayor facilidad si ésta es tangible y podemos tocarla, manipularla y en algunos casos, hasta modificarla. De una anécdota encontrada en el libro:

Borrador de dibujos de diseño

Un arquitecto diseñando un hospital me dijo alguna vez que nunca le muestra a sus clientes un plano por computadora del edificio. Los clientes lo ven como demasiado formal como para cambiarlo, sin importar lo que él diga.

Por lo tanto, siempre dibuja el plan a lápiz para que los clientes se sientan cómodos dibujando sobre él.

Agile Software Development: The Cooperative Game. Addison-Wesley Professional; 2nd edition (October 29, 2006).

Entonces, para aquellos que conocen las técnicas y artefactos de su metodología ágil favorita, recomiendo este libro ya que nos muestra el razonamiento detrás de las mismas, lo que nos permitirá ser mejores ScrumMasters, coaches ágiles o líderes de proyecto.

2 comentarios

  1. Sin lugar a dudas este tipo de textos no sólo enriquece el conocimiento sino que, además proporciona una visión basada en la experiencia.
    Si el conocimiento se adquiere estudiando y las habilidades experimentando entonces lecturas como esta nos permiten adquirir ambos lo que en verdad se agradece.
    Es cierto que “nadie escarmienta en cabeza ajena” pero se puede aplicar “ve las barbas de tu vecino cortar y pon las tuyas a remojar”.
    En cuanto a la reseña simplemente excelente,


  2. […] manera (por ejemplo, la “puerta del refrigerador” es mejor conocida como “radiadores de información” en el ámbito ágil), todos estos patrones permiten mejorar la productividad […]



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: