Saltar al contenido

Blog técnico | Un equipo de desarrolladores a distancia

Nunca he conocido a mis compañeros en persona.

Es una situación extraña, posible gracias a los avances en el teletrabajo / trabajo a distancia / equipos distribuidos. A pesar de trabajar con mis compañeros desarrolladores durante unos meses – en el momento de escribir este artículo – nunca hemos tenido la oportunidad de darnos la mano.

Blog técnico | Un equipo de desarrolladores a distancia
Blog técnico | Un equipo de desarrolladores a distancia

Algunos antecedentes

Los tres empezamos a trabajar en oficinas con equipos de trabajo compartidos. A través de cambios de equipo y cierres de oficinas, nos encontramos juntos en un equipo distribuido que se extiende por todo el ancho de los Estados Unidos continentales. Ahora trabajamos desde casa a tiempo completo, y poco a poco estamos descubriendo cómo hacerlo de forma efectiva. no tiene muchos equipos de desarrollo remotos, pero tenemos la suerte de ser parte de uno ahora.

Comunicación

La optimización de la comunicación dentro y alrededor del equipo es de alta prioridad. La mayor parte de nuestra comunicación a lo largo del día se produce a través del chat de texto en Slack. Esto incluye peticiones asincrónicas de gente de fuera del equipo y charlas entre los miembros del equipo. Aumentamos el texto con video conferencias de pie – diariamente para los desarrolladores, tres veces por semana para los miembros de funciones cruzadas – para coordinar al principio del día. También utilizamos audio y video llamadas de Slack cuando explicar, demostrar o discutir el tema sería más fácil de hacer sincrónicamente. Sin embargo, la comunicación sincrónica es un caso especial, y no es el modo predeterminado.

En mi opinión, es importante asegurar que se produzca la mayor cantidad de comunicación posible en un entorno abierto. Así como alguien podría esperar a que todo un equipo se sentara en sus escritorios co-ubicados antes de hacer un anuncio, hacemos un uso cuidadoso de los canales de Slack para asegurarnos de que la información se comparte correctamente. Para mi equipo, tenemos unos cuantos foros diferentes:

  • Un canal de equipo público, al que se anima a unirse todo el equipo interfuncional y los principales interesados. Este es un gran lugar para actualizaciones de progreso y puestos más formales. También animamos a los forasteros a que se pongan en contacto con el equipo aquí.
  • Un canal privado de equipo multifuncional. Aquí podemos ser un poco más francos en nuestras discusiones. En general, hay un nivel de charla en este canal que no es abrumador para ponerse al día después de un día lejos de la computadora. Podemos sentirnos cómodos con que todos tengan la oportunidad de leer cuando publiquemos los anuncios del equipo.
  • Un canal de desarrollo privado. Mucha charla de desarrolladores es confusa y está llena de jerga. El jefe de producto del equipo y yo tenemos un acuerdo sobre este canal: mantendremos discusiones cruciales sobre el equipo y nuestro producto en canales visibles para el resto del equipo. Este canal es donde los desarrolladores operan diariamente. Coordinamos las tareas y pedimos ayuda. Además de la charla ociosa, los desarrolladores a menudo publican actualizaciones al final del día sobre lo que han completado y lo que sigue. Como terminamos nuestros días en diferentes momentos, estos mensajes forman un gran punto de partida para el trabajo del día siguiente.

Con estos canales, nuestros mensajes directos entre los desarrolladores se han reducido a comprobaciones de “¿estás listo?” antes de iniciar una llamada de Slack. Esta inclinación hacia la comunicación abierta es crítica para asegurarse de que todos están en la misma página.

Programación de pares

En la historia reciente, nuestra tendencia al programa de emparejamiento ha disminuido y florecido. Nos emparejamos a menudo mientras estamos a bordo y resolvemos problemas, y nos emparejamos menos mientras hacemos tareas rutinarias. Para la mayoría de nuestros emparejamientos, la característica de compartir la pantalla de Slack ha sido suficiente siempre y cuando cada participante tenga una fuerte conexión a Internet. Hemos usado Discordia, FaceTime y la pantalla compartida integrada de Apple Message para aumentar las diferentes bandas de comunicación (voz, video, pantalla) cuando es necesario. (Consejo: no tengas miedo de llamar a alguien por teléfono.)

Sin embargo, últimamente, Visual Studio Code ha abierto un acceso de previsualización a su función Live Share. Anecdóticamente, la experiencia ha sido increíble. En nuestras sesiones, el compartir ha manejado efectivamente proyectos grandes con múltiples archivos cambiando a la vez. También ha mostrado resistencia cuando la gente hace cambios contemporáneos en un solo archivo. He llegado a apreciar algunos detalles, como el marcador en la cuneta que representa los cursores de otros. Espero que herramientas similares como el teletipo de Atom se pongan al día pronto, para promover una sana competencia e innovación.

No hemos formalizado ninguna regla para el emparejamiento (otros equipos tienen roles de desarrollador y rotaciones cronometradas para mecanografiar, conducir, etc.). Generalmente intercambiamos la pantalla de quién se muestra dependiendo de si estamos abordando un problema en el ordenador de un desarrollador individual o trabajando de forma más general. Aunque podemos compartir la capacidad de controlar la pantalla con otros en la llamada, a menudo no lo hacemos. En cambio, Slack nos permite dibujar efímeramente en la pantalla. Esto es útil para señalar lo que queremos decir, aunque referirse a los números de línea es un recurso efectivo cuando se navega a través del código. (Restringir la capacidad de los desarrolladores principales para escribir también tiene el beneficio de forzar la transferencia de más conocimientos entre los desarrolladores. Esto aborda uno de los posibles inconvenientes de la programación en parejas / mob).

Revisiones del código

Para los momentos en los que no estamos emparejados, usamos la solicitud de extracción de GitHub y las características de revisión. Recientemente hemos añadido la integración de GitHub (actualizado) a nuestro canal de Slack. Sólo nos suscribimos a las notificaciones de extracción y revisión, que nos dan lo siguiente:

  • Notificación de que un PR está abierto. Esta es la manera número uno de ver el progreso en tiempo real. Usamos una rápida reacción emoji para señalar que uno de nosotros lo revisará.
  • Notificación de que una revisión está completa. Para aquellos de nosotros que mantenemos las notificaciones de correo electrónico de GitHub superpegadas en la posición “off”, esto significa que no hay que refrescar ansiosamente la página de relaciones públicas o mirar el icono de la notificación.
  • Notificación cuando un PR se ha fusionado. Esto es genial para fines de celebración.

Estos métodos son fluidos y se espera que cambien con los proyectos en los que trabajamos, la gente con la que trabajamos y las formas en que elegimos trabajar.

¿Qué sigue?

Estoy emocionado de conocer a mis compañeros de equipo en un futuro próximo, porque son personas realmente grandes con las que tengo el honor de trabajar. Mientras tanto, sin embargo, hemos sido capaces de construir un equipo fuerte utilizando la comunicación deliberada y la amplia gama de herramientas disponibles. Basándome en mi experiencia hasta ahora, no tengo ninguna duda de que los equipos de productos remotos eficaces están al alcance de la mano.

Categorías: artesaníaTags: emparejamiento, comunicación