Trabajo en equipos distribuidos

Nuestra experiencia en trabajar en equipos distribuidos en distintos lugares físicos fue dándose gradualmente:

1. pasamos de trabajar en dos oficinas separadas - por una cuestión de calidad de vida de algunas de las personas que tenían mucho tiempo de viaje -,
2. a trabajar para clientes en el exterior - lo que implicó cambiar nuevamente algunos hábitos laborales -,
3. hasta ser parte de un grupo de equipos de desarrollo ubicados en puntos distantes del planeta.

En este camino que llevamos recorrido hemos tenido que aprender a adaptarnos y compartir experiencias para poder llevar adelante los proyectos manteniendo el uso de metodologías ágiles.

Siguiendo consejos de quienes ya habían pasado por estos menesteres y aportando nuestro propio conocimiento y sentido común, resumimos en este artículo algunos de los puntos que nos parecen más importantes para considerar en estos casos.

Algunos puntos relevantes

Si bien en las metodologías ágiles la comunicación tiene un rol fundamental, encontramos por allí quienes aconsejan también darle tanta o más importancia a la estructuración del proyecto y la gente que va a formar parte de los distintos equipos. Ese trabajo previo debe llevar a que cada miembro tenga claro el contexto, los objetivos y los roles. En nuestra experiencia esto resultó fundamental.

Considerar algunas características culturales y tratar de unificar criterios de colaboración no sólo entre equipos sino también dentro de cada uno de ellos. Algunos de esos criterios son:

• Definir metas estándar de distinto tipo (por ejemplo, respecto de la calidad del software, armado de prototipos, criterios de aceptación o del significado de "done", etc.)

• Definir la frecuencia de control para cada meta, para evitar desvíos o minimizarlos

• Definir cuándo y cómo se van a realizar las Stand up meetings, quiénes van a estar presentes y cómo se van a cargar las horas insumidas por cada equipo 

• Definir qué herramientas se van a usar, cómo y en qué casos. Es importante entender que no existe una única herramienta que sirva para todos los fines. Si bien es necesario tratar de minimizar la cantidad de éstas para evitar duplicación de trabajo, tampoco tenemos que forzar que una sola h pueda cubrir todas las necesidades. En este punto puede servir detenerse a pensar:
• qué necesitamos
• qué herramientas ya tenemos (o usan los distintos equipos para cubrir esas necesidades)
• qué herramientas nuevas necesitamos incorporar, qué uso se le va a dar y verificar que no entre en conflicto con alguna de las pre-existentes

• Invertir en el entrenamiento de todos los equipos para el uso de herramientas, estándares en la codificación, metodologías, etc. permitirá ahorrar tiempo y errores a lo largo del proceso. Y puede ser un buen terreno de intercambio de conocimientos entre los equipos

Otros aspectos a tener en cuenta

Para lograr los objetivos cuando los equipos se encuentran físicamente distribuidos y deben ensamblarse es necesario contar con un rol de alguien que sirva como guía, gerente, scrum master, coordinador o la etiqueta que quiera ponérsele para que se encargue de aunar los criterios de trabajo, la relación con el cliente y la comunicación entre teams. Y por sobre todas las cosas debe asegurarse que los equipos puedan reaccionar rápidamente a los cambios que se presenten.

En otro aspecto, en metodologías ágiles son bienvenidas las habilidades diversas dentro del equipo. Al trabajar con equipos de diferentes culturas y niveles de conocimiento hay que ser muy cuidadosos y optimizar el uso de las distintas capacidades dentro de cada uno de  los equipos y entre los equipos dado que muchas veces pueden darse colisiones. El rol del "administrador" en estos casos es fundamental.


Por supuesto, uno de los aspectos importantes en esta forma de trabajo está referido a la creación y mantenimiento de canales de comunicación que permitan suplantar de la mejor manera los beneficios de la comunicación "presencial" o cara a cara. Pero además es necesario equilibrar la comunicación escrita con la oral para evitar el uso exagerado de una sola de las dos.

En el mismo sentido anterior, el uso de las Historias de Usuario puede tener un apartado especial. Cuando los equipos son tan diversos es posible que la adminstración de las historias requiera un detalle más exhaustivo de lo que un equipo independiente está acostumbrado a usar.
En nuestra experiencia hemos necesitado que las historias o estén complementadas con otra forma de documentación o que sea necesario el uso de una herramienta un poco diferente a la tradicional pizarra para poder llevarlas adelante. Sobre todo, porque hay que tener en cuenta que dados los distintos husos horarios y la integración con tareas hechas por otros equipos, las historias deben considerarse como lugar de conversación y de tracking de necesidades o consultas con otros miembros.
En este sentido una herramienta que nos ha sido muy útil es Assembla.

Respecto de la integración de código, Github es altamente recomendable (How Github works)
Y por supuesto Skype, GoogleDocs y Join.me son también de gran ayuda.

Más artículos de interés:

Distributed Agile: 8 ways to get more from your distributed teams
3 Surprising Reasons Distributed Teams Work Better
Fully Distributed Teams: are they viable?
The Secret Ingredients of a Successful Distributed Team

De nuestro blog:

Trabajo distribuido
Herramientas para trabajo distribuido
Reuniones diarias


(Fuentes de las imágenes:
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3wsAFqagSKNM1OtBnF9a2GJ48mFgQmuofIUnXBr0CWDMvLc898fb4q8bOMLZ4wgrO7opYdqhvE8IAJUKZKn2VGXl91UKq9hVqYVntXYV6pZWI6Hh3LI8lV4fi7MMESwC0et6jR9GYKrM/s200/distributed-teams.jpg
http://qablog.practitest.com/wp-content/uploads/2012/07/ID-10064353.jpg) 


Twittear        Seguir a @3p_ar

Leer más...