400510403. Retos del desarrollo distribuido

¿Acaso no han soñado todos los jefes de proyecto con tener a los desarrolladores trabajando en sus proyectos las veinticuatro horas del día? Por algun motivo, los desarrolladores individuales no se sienten por la labor. Pero con el desarrollo distribuido, este sueño puede convertirse en realidad.

Con equipos de desarrollo distribuidos, dependiendo de cómo se distribuya el desarrollo por todo el mundo, puede irse haciendo codificación casi las veinticuatro horas del día. Pero debido a las diferencias horarias entre países, los equipos implicados se enfrentan al gran reto de conseguir una comunicación eficaz. La comunicación por correo electrónico funciona hasta un cierto punto, pero siempre hay un retraso en el tiempo de respuesta.

Hay que programar las convocatorias de conferencia o bien por la mañana temprano o tarde por la noche para que los equipos estén disponibles todos a la misma hora. El retraso se refleja también cuando encontramos un defecto a última hora que tiene que solucionarse inmediatamente. Si el equipo está disperso geográficamente, puede que no logremos solucionarlo o incluso que no tengamos respuesta hasta el día siguiente, lo que puede influir negativamente en su lanzamiento.

La comunicación es uno de los grandes retos a los que se enfrentan los equipos de desarrollo distribuido. El problema presenta múltiples y distintas facetas, como dificultades lingüísticas, colaboración entre equipos y otros temas relacionados con las distintas culturas.

Unas cuestiones son más fáciles de abordar que otras. Los retos de carácter lingüístico se presentan en varias formas. En un extremo está el caso en que algunos o todos los miembros de un equipo lejano sencillamente hablan un idioma distinto al tuyo. Hay que garantizar que los términos comunes que se usan en el proyecto son entendidos por ambas partes.

Podemos usar esto como nuestro vocabulario básico común y empezar desde ahí. También hay que comprobar que los miembros del equipo se entienden entre sí. Una buena técnica es repetir con nuestras propias palabras lo que un miembro del equipo nos ha dicho para verificar que hemos entendido correctamente.

La colaboración entre equipos es fundamental, y los equipos que trabajan en distintos lugares necesitan depositarios de códigos fuente comunes, depositarios de requisitos y herramientas de búsqueda de defectos. Mecanismos de colaboración como las herramientas para conferencias sobre datos online o a través de la web pueden ayudar a que distintos equipos compartan pantallas o trabajen con una pizarra compartida en las reuniones.

Las herramientas de mensajería instantánea también ayudan a que los equipos colaboren y se comuniquen mejor. Es preciso asegurarse de que fluye la información entre equipos y de que todos los equipos van evolucionando hasta la colaboración plena. Hay que cuidarse de los miembros de un equipo que intentan dejar mal a otro equipo. Mi ejemplo favorito de construir equipos que sean iguales gira en torno a las revisiones de códigos.

En esas situaciones, el equipo principal o más experimentado (en particular al comienzo) puede sentir la necesidad de revisar todo lo que hace un equipo nuevo. Pero para avanzar, hay que implicar a los miembros de los equipos que están lejos en las revisiones de código del equipo principal. Ello nos aporta dos beneficios importantes:
– El conocimiento del código base se amplía durante las revisiones de código.
– Se consiguen otros pares de ojos para el código (y en este caso probablemente una visión fresca y objetiva del mismo).

Es preciso comprender las diferencias culturales y buscar compromisos cuando sea necesario para mantener funcionando bien el proyecto. Hay que saber distinguir también las diferencias culturales de los malos hábitos. Hay que desanimar y extraer los malos hábitos (como no compartir, no hacer la revisión del código, malas prácticas en la codificación) según se avanza.

Uno de los mayores retos en lo que respecta a las diferencias culturales es la tendencia por parte de algunos miembros de los equipos a no querer decir que no entienden lo que se les dice porque no es correcto hacerlo en su cultura. El primer síntoma de que esto ocurre es cuando uno de los equipos simplemente dice “sí” a todo lo que se le dice sin cuestionar nada ni hacer preguntas.

Y a continuación se van y hacen lo que ellos consideran necesario. Normalmente sólo se sabe al final del ciclo que han hecho lo que les ha parecido y han implementado lo que no se quería. Hay dos formas de evitar esta situación:
– Proporcionando a todos los equipos un conjunto claro de requisitos con documentación de apoyo.
– Pedirles a todos los equipos que contribuyan a documentar los requisitos y que los revisen.

Para tener éxito en un proyecto de desarrollo distribuido, hay que tener unos procesos bien definidos. Los procesos van desde requisitos para reunir y codificar estándares hasta las revisiones del código, la búsqueda de defectos y el procesado de los mismos.

Hay que asegurarse de que todos los miembros de los equipos siguen el mismo proceso. Los jefes han de reforzar estos procesos y han de tomar la iniciativa a la hora de confrontar a los miembros del equipo cuando no se siguen los procesos. Hay que establecer el mínimo de la calidad donde necesite estar y asegurarse de que los miembros del equipo alcanzan el mínimo.

La realización de revisiones en el diseño antes de que se empiece a codificar es también fundamental. Al realizar controles al comienzo del proceso, se garantiza que se obtiene lo que realmente se necesita.

Los equipos de desarrollo distribuido pueden ser realmente potentes, pero para tener éxito, hay que tener una perspectiva general. El desarrollo distribuido es en realidad una multitud de equipos trabajando como si fuera uno solo. DDJ