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...

SCRUM, problemas en la reunión diaria: qué podemos hacer al respecto?

Internamente muchas veces nos preguntamos si las reuniones diarias están cumpliendo el objetivo que realmente tienen y al leer blogs y foros sobre metodologías ágiles descubrí que muchos equipos tienen los mismos problemas que detectamos puertas adentro.

Revisar objetivos

Para comenzar es bueno recordar cuál es el objetivo y qué debe hacer cada miembro del equipo en una típica reunión diaria.


La reunión diaria tiene como fin el facilitar la transferencia de información y la colaboración entre los miembros del equipo para aumentar su productividad, al poner de manifiesto puntos en que se pueden ayudar unos a otros.


Cada miembro del equipo participa del trabajo que el resto está realizando (dependencias entre tareas, progreso y problemas) para luego de finalizar la reunión poder hacer las adaptaciones que permitan cumplir con las historias que el equipo comprometió para el sprint en curso.

Cada miembro del equipo debe responder las siguientes preguntas en un tiempo estipulado de como máximo 15 minutos:

• ¿Qué he hecho desde la última reunión diaria? ¿ Pude hacer todo lo que tenía planeado? ¿Cuál fue el problema?
• ¿Qué voy a hacer a partir de este momento?
• ¿Qué problemas tengo o voy a tener para cumplir con este sprint y en el proyecto?

Como apoyo a la reunión, el equipo cuenta con la lista de tareas del sprint (sprint backlog) donde se actualiza el estado y el esfuerzo pendiente para cada tarea. 

Con esto se ponen en evidencia los beneficios y restricciones que tiene cada equipo en realizar sus tareas. 

(Para quienes quieran profundizar recomendamos leer "Scrum y XP desde las trincheras")

¿Problemas? ¿Qué problemas?

Si bien la práctica descripta en el párrafo anterior puede ser muy clara y parecer muy simple, nos pasa que, con el correr del tiempo notamos que hay cosas que empiezan a fallar o a sacarnos del eje de lo que indican los libros. ¿Cuáles son esas cosas? Aquí listamos algunos ejemplos de situaciones que pueden presentarse en las reuniones diarias y que pueden ser tratadas durante la misma, así como también recomendaciones recopiladas entre experiencia propia y de otros:


1. Algún miembro del equipo se queda sin tareas dentro del sprint

• Que él mismo elija qué cosas puede hacer para ayudar al equipo (test, documentación, scripts, etc.)
• O decidir entre todos que ayude con otros tipos de tareas, por ejemplo que sea el cadete del grupo. 

2. Falta tiempo para corregir código o hacer una corrección que no produce historias válidas dentro del sprint.

• Bajar el rendimiento del equipo, para poder dedicarle el tiempo suficiente a las tareas de mejoras o correcciones, es decir, plantearse hacer menos historias para el sprint.

3. Ante un proyecto grande con muchos desarrolladores

• Cuando la cantidad de personas en un proyecto es grande, se dispersa mucho la información, lo ideal es armar varios grupos más pequeños de entre 3 y 10 desarrolladores.
• Si hay varios equipos en el mismo proyecto , lo más recomendado sería, un solo project owner (dueño del proyecto), sprint sincronizados para que las demos sean el mismo día, la planificación unificada para repartir las historias y luego cada equipo hace su propia planning poker. Hacer en diferentes horarios las reuniones diarias, para que el project owner esté en todas. La gran ventaja de esta experiencia es que cuando termina cada sprint los miembros del equipo pueden ser intercambiados, o reorganizados minimizando así las dudas y/o problemas. 

4. Llegadas tarde a la reunión diaria

• Elegir una hora buena para todos ( en la generalidad de los casos, se toma como horario de la reunión diaria, entre 15 y 30 minutos posteriores al horarios de inicio de la jornada).
• Si los retrasos son habituales se puede "llenar la alcancía", "traer algo para compartir para todos". Ante la reincidencia eligen hacer que duela un poco más el bolsillo y así tratar de evitar llegar retrasado.  
• Llegar tarde se puede deber al desinterés, con lo cual es válido plantear como alternativa que el propio implicado en los sucesivos retrasos puede exponer sus propias explicaciones ante el grupo y/o alternativas de participación para aumentar su interés. 
• Contar o no qué paso en la reunión o a los que no estuvieron presentes, depende de dos puntos de vista, el interés de escribir en una breve "minuta" sobre lo hablado por el project owner y el otro punto de vista el interés del integrante retrasado en interiorizarse en lo sucedido en la reunión diaria. 

5. Equipo distribuido geográficamente

• Skype, o cualquier vía de comunicación on line conectado permanentemente, reunión diaria del equipo completo, comunicación lo más fluida posible (skype, cámaras web, mail, de ser necesario palomas mensajeras!!!)

En forma anecdótica podemos decir, que en Tercer Planeta, hemos intentado varias de estas recomendaciones, algunas con funcionamiento óptimo y otras en vías de mejoras seguras. 

La más importante que hacemos es la de realizar una reunión diaria del grupo completo, ya sea que pertenezcan o no al mismo proyecto, contándonos en qué estamos cada uno y pidiendo todos los S.O.S. necesarios, esto permite que ninguno de los proyectos quede estancado, reconociendo que no todos sabemos todo. Además de poder contar con ayuda, podemos saber en qué estado está cada uno. A esta reunión diaria grupal general, muy cortita, le siguen las reuniones diarias específicas de cada proyecto en concreto (reuniones de avance). 

Personalmente, la primer reunión diaria es la más saludable y a veces hasta la más esperada por todos, nos permite entender el estado de cada uno, estar al tanto de temas generales del equipo y temas más sociales. Es una manera de mantener la comunicación "viva", más allá de los detalles particulares que presente cada proyecto. 

Twittear Seguir a @3p_ar

Leer más...

Herramientas para trabajo distribuido

En el artículo sobre trabajo distribuido comentamos que estamos aplicando ésta forma de trabajo desde el 2009. Por supuesto al principio la implementación supuso varios desafíos, entre los cuales estaban sostener una comunicación fluida en el equipo, mantener el código actualizado y además llevar a cabo las prácticas ágiles a las cuales estamos acostumbrados.
¿Cuáles serían las herramientas que nos facilitarían esta tarea? A continuación hago una breve reseña de las aplicaciones que utilizamos y cómo nos ayudaron:

Team Foundation Server

Es una herramienta de control de código que no presenta inconvenientes a la hora de trabajar tanto en la red local como desde una conexión de Internet.
También cuenta con un modo de trabajo offline que funciona muy bien si por una de esas casualidades nos quedamos sin conexión.
Team Foundation Server

Live Mesh

Es un sistema de sincronización de datos que nos permite mantener compartidos y actualizados los cambios que vamos realizando en archivos y carpetas de uso conjunto.
Principalmente nos ayudó a mantener actualizada nuestras bases de datos ya que cada uno poseía una copia local (solo de las que necesitaba) y era indispensable algún medio que nos permitiera aplicar los cambios realizados por otros miembros del equipo.
El procedimiento que seguimos fue el siguiente: Cuando realizábamos alguna modificación creábamos un script de actualización. Estos scripts se iban colocando numerados en una carpeta compartida de cada proyecto, donde además teníamos un documento con un registro de las actualizaciones que había corrido cada uno. Luego, para saber si necesitábamos actualizar la BD, sencillamente entrábamos a esta carpeta y verificábamos hasta que script habíamos corrido y de haber nuevos scripts a continuación de éste, ejecutábamos los que nos faltaban.
Pronto va a ser reemplazado por la nueva versión de Windows Live Sync.
Live Mesh

Scrumy

Esta aplicación web hace las veces de Task Board permitiéndonos realizar el seguimiento de nuestro sprint virtualmente. Realmente es muy fácil de usar y posee una versión gratuita con las funcionalidades necesarias. La única desventaja es que no podemos agregar La columna del medio.
Pizarra Virtual:

Scrumy

Google Docs:

La posibilidad de que varias personas puedan editar un documento al mismo tiempo convierte a esta aplicación en una excelente herramienta para trabajo distribuido.
En nuestro caso, nos sirvió muchísimo a la hora de hacer las retrospectivas de cada proyecto. Para hacerlo utilizábamos una planilla en la cual podíamos escribir todos, y que además tenía unas columnas adicionales para realizar la votación.
Retrospectiva en Docs:
Google Docs

Skype:

Si bien no hace falta ninguna presentación, debo decir que esta aplicación se ha vuelto fundamental en nuestras vidas a la hora de comunicarnos mediante voz, mensajería instantánea y video. Resulta de gran utilidad por ejemplo a la hora de realizar la reunión diaria.
Skype

Yuuguu:

Esta herramienta nos permite compartir escritorio con varias personas al mismo tiempo, e inclusive ceder el control de Mouse y teclado. Como punto interesante quiero añadir que la persona que se conecta a nuestra computadora puede hacerlo desde cualquier navegador sin instalar la aplicación.
Yuuguu
Seguramente habrá muchas más herramientas que se puedan explorar (sobre todo las que no son específicas para desarrollar) y que no conocemos. Lo importante es que cada equipo incorpore aquellas con las que se sienta más cómodo en cada caso. Para esto resulta muy valioso el conocer experiencias de otros en el tema. Cualquier intercambio en este sentido es siempre muy bienvenido !!

Etiquetas de Technorati: Herramientas para trabajo distribuido,trabajo distribuido,trabajo remoto,teletrabajo,compartir carpetas

Leer más...

Trabajo distribuido

Durante el mes de Julio del año pasado tuvimos la oportunidad de empezar a experimentar con esta modalidad de trabajo. Si bien la idea rondaba desde hacía tiempo por nuestras cabezas, todavía no habíamos tenido motivos suficientes como para tomar el riesgo de enfrentarnos a este terreno desconocido.

Lo que verdaderamente nos dio el impulso final fue el brote de Gripe A que por ese entonces estaba en su punto más alto. Siendo que varios de nosotros (entre los cuales me incluyo) pertenecíamos al grupo de riesgo, surgía la necesidad de desarrollar medidas preventivas. Entonces, con el objetivo de abogar por nuestra salud, y de paso aprovechar la oportunidad para probar que tal nos iba trabajando de forma remota , tomamos la decisión de replegarnos todos con nuestros equipos hacia nuestros respectivos hogares. Sólo una persona quedó en la oficina haciendo un poco de auxiliar en caso de que surgiera cualquier necesidad.

Mi experiencia

Debo decir que al principio me costó algo la adaptación, sin embargo a los pocos días ya me sentía como “en casa”. Realmente la tecnología con la que contamos hoy en día nos otorga una gran flexibilidad a la hora de trabajar.

Enfocándonos en la calidad de vida, quiero decir que el hecho de evitar las complejidades que se nos presentan camino a la oficina (como el tráfico) es una experiencia más que grata. Esto sin mencionar el tiempo y dinero que nos ahorramos.

Durante todo el mes trabajando en mí en casa sufrí algunos desperfectos técnicos. Afortunadamente como contamos con un buen servicio técnico los pudimos solucionar rápidamente, por lo tanto les recomiendo tener este tipo de seguridad a su disposición.

Los Resultados

Luego de un mes trabajando fuera de la oficina hicimos una evaluación de cómo nos había ido. Los resultados en general fueron bastante positivos:

• Pudimos mantener sincronizados código y bases de datos sin demasiado esfuerzo.
• Comprobamos nuestra flexibilidad para trabajar en equipo .
• Se notó una gran autonomía para administrar los tiempos individuales con responsabilidad.
• Logramos sostener la productividad.
• Ahorramos tiempo y dinero en viajes.

En cuanto a lo negativo, creo que una de las cosas más importantes a destacar es la pérdida de la comunicación cara a cara.

Pienso que uno de los ingredientes principales que nos permitió obtener buenos

resultados donde otros fallan, es que hace tiempo que venimos trabajando juntos.

El hecho de que nos conozcamos y que estemos acostumbrados al trabajo en equipo hace que tengamos un lenguaje común. Es mucho más fácil lograr la resolución de un problema cuando las partes involucradas hablan el mismo idioma.

Trabajo Distribuido Hoy

Ahora bien, si esta experiencia nos dio tan buenos resultados cabe preguntarse ¿Por qué no adoptar esta modalidad de trabajo siempre y trabajar todos desde nuestros hogares?

En una empresa como la nuestra, donde mantener el espíritu de equipo y la identidad son valores muy importantes, esto sería difícil. Sin embargo, vimos que podíamos aprovechar esta metodología para los casos en los que nos es más útil y necesario.

Por ejemplo, uno de nuestros compañeros dentro de unos días va a ser padre, y más alla del tiempo contemplado para ello, va a trabajar durante unas semanas desde su casa ya que creemos que es importante que este cerca de su familia. Lo mismo se da para otros casos personales donde un día a la semana o cada 2 ó 3 semanas alguno de nosotros hace trabajo remoto.

Mirando al futuro

Evidentemente esta modalidad está totalmente instalada entre quienes nos dedicamos al software, modificando la calidad de vida de quienes la practican. Me parece importante señalar que para aprovechar los beneficios de la misma y lograr que este cambio sea positivo, no debemos olvidar lo valioso de poder salir de nuestras computadoras y ensayar distintas soluciones entre varios frente una pizarra, experimentar las virtudes de programar de a dos (de la forma” tradicional”) o simplemente compartir una charla extra laboral mientras nos tomamos una taza de café.

Leer más...