🤘🏿 💌 📋 El trabajo de un equipo distribuido en condiciones de autoaislamiento: como casi no notamos la diferencia 👨‍🏭 🍍 👎🏾

El modo de autoaislamiento obligó a muchos a trabajar desde casa. Es más fácil para alguien, más difícil, y alguien no notaría la diferencia en absoluto, pero después del anuncio de la semana de cuarentena (y luego el mes), el aumento en las publicaciones de salvavidas, la eficiencia y la productividad en el feed ha aumentado significativamente.

Mi nombre es Mikhail Troshev, encabezo el servicio de interfaz de búsqueda Yandex. Nuestro equipo ha estado trabajando de forma distribuida durante muchos años. A continuación, le diré cómo difiere y cómo es similar a "remotamente", cómo está organizado, por qué no se rompe y cómo nuestra experiencia puede ser útil para aquellos que repentinamente se vieron afectados por un cambio en el modo operativo.

Seguramente, algo te parecerá banal (Agile, Scrum, Kanban, DevOps: ¡asombrosos descubrimientos!), Pero es como cargar por la mañana: todos saben que es útil, pero por alguna razón la pereza se hace con regularidad y con toda su fuerza. Entonces: lo hacemos. Y funciona.

No remotamente, sino distribuido

Lo que parece: 90 vendedores frontales se reúnen todos los días en las oficinas de Moscú, San Petersburgo, Kazán, Innopolis, Ekaterimburgo, Simferopol y Minsk; es fácil notar que estamos separados no solo por distancias, sino también por zonas horarias. Sin embargo, esto no es todo: los distribuidores de front-end se distribuyen entre los equipos de productos (equipos virtuales) de alrededor de tres a Seven + back-end, diseñadores, testers y los administradores (en 2019 habló en detalle sobre nuestras estructuras de trabajo aquí ). Es decir, casi todos los miembros de uno de esos equipos están en diferentes ciudades. No del todo remoto, pero muy cerca de esto: aunque varios colegas todavía están cerca, las posibilidades de microsincronización con los demás son significativamente limitadas en comparación con trabajar en espacios abiertos.

Es necesario utilizar la comunicación asincrónica con un largo retraso de reacción. Cuanto más fuerte esté el equipo disperso entre las diferentes oficinas, mayor será la interacción diaria de trabajo con la sobrecarga de espera que cualquier proyecto puede enterrar. Para ahorrar tiempo:

- el ciclo de vida de cada tarea desde la idea hasta la producción se organiza de la manera más consistente posible: procedimientos, estados, transición entre etapas: todo lo que es posible se formaliza (aproximadamente el 90% de las tareas). Al mismo tiempo, tratamos de mantener la burocracia simple y comprensible, de lo contrario deja de ser útil y comienza a interferir;

- todo el equipo conoce las reglas que rigen el proceso de trabajo y trata de seguirlas claramente; Intentamos automatizar la rutina. Por lo tanto, todos están ocupados con su propio negocio y no pierden el tiempo tomando las mismas microdecisiones: programadores, gerentes de programa presentan características, diseño de diseñadores.

Nada nuevo, ¿verdad? Sin embargo, este enfoque simple nos ayudó mucho en las condiciones de autoaislamiento: cada empleado puede aportar el máximo beneficio por sí mismo, ya que conocen los detalles suficientes para el trabajo.

Pero lo primero es lo primero.

Etapa 0. Planificación

Cada equipo tiene una cartera de pedidos, cuya parte superior está clasificada y priorizada:

El punto fundamental es que cada miembro del equipo debe entender: esta tarea debe hacerse porque está vinculada a la epopeya, la epopeya está vinculada a la meta y la meta es importante. De lo contrario, las personas pueden comenzar a hacer lo que no es necesario o el gerente se verá obligado a monitorear y extinguir los incendios constantemente. Esto último, por cierto, puede ser difícil de notar en la oficina, pero es imposible pasarlo por alto de forma remota: hay mucha confusión, el trabajo está en progreso, una docena de salas de chat comienzan en el mensajero en un intento de sincronización; como resultado, todo el equipo está chateando, en lugar de escribir código. Es de vital importancia organizar la planificación en un equipo para que cada participante en el proceso comprenda qué y en qué orden debe hacer. Luego, el líder del equipo podrá concentrarse en el producto sin distraerse con constantes pequeñas preguntas.

Por supuesto, es imposible detallar toda la cartera de pedidos hasta el final, pero un estudio de alta calidad de su parte superior le permite reclutar rápidamente nuevas tareas en el sprint (casi todos los equipos viven en sprints de dos semanas) y mantener una reserva para el siguiente. Con este enfoque, un equipo experimentado puede escribir un sprint incluso sin un gerente, si de repente resulta ser inaccesible.

Para no estirar el tiempo de trabajo en la tarea, el equipo se dedica a una "burocracia útil": el gerente formula una descripción clara, los ejecutores establecen los estados correctos, las tareas "fluyen" de izquierda a derecha en el tablero de sprint:

Aquí todo el equipo ve la imagen completa y actual del sprint. Si alguien se enferma, va de servicio o de vacaciones, otros participantes retoman inmediatamente las tareas en su estado actual.

Bueno, ¿cómo puede ser sin sincronizaciones diarias, cuando la organización formal del proceso no es suficiente para resolver algunos casos particulares, y es más probable que la burocracia interfiera con el proceso? Por lo general, detallar las tareas por estado (abierto> en progreso> en revisión> listo para prueba> prueba> probado> listo para desarrollo> dev> rc> cerrado) es suficiente, pero en el 10% de los casos necesita aclarar algo, decirlo en palabras, explicar " en los dedos ". Por cierto, estoy convencido de que todas las reuniones de trabajo (incluidas las de pie) deben llevarse a cabo mediante comunicación por video, y no solo por voz, porque obliga a uno a ponerse en orden y sintonizarse para trabajar.

Es muy importante que todo el equipo estuvo presente en la sincronización: verificaron rápidamente el contexto, resolvieron las tareas y comenzaron a trabajar, guiados por la junta, sin perder más tiempo entre ellos. Por supuesto, también tenemos chats en funcionamiento, pero tratamos de no inundarlos y usarlos para obtener una respuesta rápida (idealmente binaria): ¿es posible lanzar el lanzamiento, dónde encontrar instrucciones, con quién discutir la API de la fuente de datos?

Donde ganó el tiempo: sincronización, toma de microdecisiones

Etapa 1. Desarrollo: abierto> en progreso

"Abierto": la tarea está esperando al intérprete. Los desarrolladores los recogen para que cada uno esté listo lo más rápido posible. Por ejemplo, sucede que es viernes en el patio, y el desarrollador entra en servicio la próxima semana (y esto se sabe de antemano, durante un mes). En este caso, es mejor para él realizar una pequeña tarea para lograr hacerlo en un día: tratamos de no transferir lo que se inició. Si alguien no tiene tiempo para terminar el trabajo, es mejor verterlo como está y luego terminar los restos con una solicitud de grupo por separado.

Implementé una copia de trabajo local del proyecto; no olvide transferir la tarea de "abierto" a "en progreso" para que otra persona no lo asuma. "Local", por cierto, es una palabra clave: puede trabajar desde cualquier lugar, la calidad de su conexión a Internet no será un factor de bloqueo. Ahora que la infraestructura y las redes están sobrecargadas, es muy importante. Nuestro servidor de desarrollo local le permite utilizar volcados de datos: archivos zip con datos para diversas solicitudes, de modo que pueda trabajar completamente sin Internet. Una vez que el desarrollador ha finalizado el trabajo y enviado la solicitud del grupo, se activa la automatización.

Cuando se gana tiempo: una evaluación independiente de las fortalezas y capacidades, no siempre es necesario superar una conexión a Internet inestable

Etapa 2. Verificaciones automáticas: en progreso> en revisión

Antes de que la tarea entre en la revisión, pasa controles sobre la calidad del código, el rendimiento, la falta de errores visuales y funcionales. Aquí se podría escribir mucho sobre la integridad y variedad de nuestras comprobaciones automáticas, pero, en primer lugar, se basa en varias historias separadas, y en segundo lugar, va mucho más allá del tema discutido. Solo daré enlaces a la descripción de las herramientas:

- un conjunto estándar de herramientas para el análisis estático: ESLint y Stylelint con un amplio conjunto de complementos;
- nuestras propias comprobaciones estáticas: disponibilidad y calidad de las traducciones, validación de archivos yaml;
- herramientas estándar para pruebas unitarias: Mocha , Karma , PhantomJS ,Estambul ;
nuestra propia herramienta de prueba funcional y visual, Hermione ;
- Pulse - para pruebas de rendimiento - también es nuestro. Lo mencionaron aquí .

Por cierto, la tarea se revertirá aquí en caso de problemas en cualquier etapa; desafortunadamente, incluso la planificación más cuidadosa no ahorra el 100% de los errores, algo puede salir mal. Si encuentra a la persona adecuada en la tarea, describe la esencia del problema, sube capturas de pantalla o incluso videos, además puede escribir comandos en el chat para que todos noten que la tarea se ha estancado. Sea lo que sea, el error salió durante las pruebas, el diseño cambió, no había suficientes datos del backend.

: — , - —

3. -: in review > ready for test

En primer lugar, quiero llamar a una solicitud de grupo no solo a un revisor gratuito, sino a una persona que entienda lo que está sucediendo en su código; en segundo lugar, de un equipo adyacente, para que todo el servicio tenga una idea de quién está haciendo qué, todo esto se explica en nuestras regulaciones. Incluso en una oficina pequeña puede ser difícil y lento organizarlo manualmente, sin mencionar la distribución (¡y el autoaislamiento!). Un revisor de código automatizado viene al rescate: ella también cambia el estado por su cuenta. No me detendré en detalles sobre cómo funciona, no lo haré; es mejor escuchar la historia del desarrollador. También sabe cómo hacer ping a los artistas intérpretes o ejecutantes: cuanto más se cuelga la tarea en la revisión, más violentamente suena.

Dónde ganó el tiempo: busque el revisor relevante, recordatorios para procesar la solicitud del grupo

Etapa 4. Prueba: prueba> probado

Cuando el cambio haya pasado la revisión del código, ejecute las pruebas automáticas. Solo después de que todos se vuelvan verdes, la tarea se transfiere a pruebas manuales. Es importante que para la tarea, hasta que sea claramente transmitida a otra persona, el intérprete siempre sea responsable: es él quien debe arrastrar rápidamente su código a través de la revisión del código y las pruebas a producción. Es decir, siempre sabemos quién es extremo, todos supervisan constantemente no solo sus tareas, sino también todo lo que sucede en el equipo. El probador en el equipo generalmente está solo, y esto también es conveniente para él: ve que volará a continuación, puede usar su tiempo de manera más eficiente.

El evaluador puede:

- asignar la tarea de evaluación a los evaluadores - una publicación con todos los detalles. Como resultado de las pruebas de los evaluadores, algo puede requerir pruebas de investigación o verificación;
- Pruebe la tarea usted mismo en un dispositivo en vivo o utilizando una granja de dispositivos con acceso remoto - Granja colectiva.

Los dispositivos en vivo se encuentran en Hypercubes en todas las oficinas de Yandex. Cualquier empleado puede tomar el dispositivo que necesita con las características necesarias, después de seleccionar el punto más cercano con un dispositivo libre. Normalmente, después de un tiempo, el sistema le recordará automáticamente que es hora de devolver el dispositivo, pero esta función se desactivó durante el tiempo del autoaislamiento. El equipo de trabajo se aseguró de que aquellos que lo necesitaran críticamente necesitaran los dispositivos vivos, y que todos los demás, para no retrasar los procesos de trabajo, ayudaran a conectarse a la granja colectiva.

Una granja colectiva es una granja de dispositivos de prueba remota que cualquiera puede usar. Android, iOS: verificamos los cambios incluso en las versiones de sistemas más antiguas y difíciles de admitir, para que nuestros servicios estén disponibles para cualquier persona. Pero también estamos tratando de obtener buques insignia lo antes posible tanto en la Granja Colectiva como en los Hipercubos. ¿Recuerdas la "cortina" (es "monobrow") que apareció en el noveno iPhone, y todos los problemas asociados con él?

Donde ganó tiempo: planificación, pruebas automáticas, distribución de dispositivos: disponible incluso con autoaislamiento

Etapa 5. Infusión: listo para fev> dev

La tarea se prueba: es hora de verterla en una rama común.

N.B. , master trunk, dev. . trunk.

Cuando hay muchas inyecciones (por ejemplo, tenemos más de 30 solicitudes de grupo infundido por día), surgen dos problemas:

- menor : el historial en git, si te unes al azar y no rebasas, se vuelve muy confuso, y si hay algún tipo de error retroceder es muy difícil;

- crítico : pruebas de integración. No siempre es físicamente posible esperar el final de la prueba de los cambios junto con la última versión de troncal, por lo que puede ocurrir lo siguiente: dos solicitudes de agrupación, cada una de las cuales no rompe nada, romperán la troncal después de la infusión. Para evitar esto, nos adherimos al desarrollo basado en Trunk, es decir, se puede implementar un lanzamiento desde cualquier confirmación. Y aunque todavía no hemos llegado finalmente a la implementación continua, nuestro tronco es "verde". Y romperlo incluso una vez por semana es categóricamente inaceptable para nosotros.

Durante varios años, hemos estado utilizando la herramienta Merge Queue para automatizar la cola y la estamos mejorando constantemente. Los cambios no los vierte el desarrollador, sino el robot. En cada solicitud de grupo, se reajusta según la última versión de troncal y ejecuta un conjunto completo de pruebas. Este es un proceso bastante largo, por lo tanto, es imposible construirlo sobre personas vivas: una persona simplemente no esperará los resultados finales. Y el robot funciona sin dormir, descansar y días libres. Además, el desarrollador no puede poner la tarea en la cola, pero el probador inmediatamente después del final de la prueba, esto le permite una vez más ahorrar tiempo.

Más detallesAcerca de la cola de fusión.

Cuando el tiempo ganó: evitamos las interrupciones del bloqueo, no es necesario controlar manualmente la infusión de la solicitud del grupo

Etapa 6. Lanzamiento: rc> cerrado

Todos los días laborables a las 5 a. M. Desde la última confirmación en el tronco, automáticamente recibimos una nueva versión: el ensamblaje de paquetes estáticos y dinámicos, el cálculo en predecible, las pruebas de los asesores. A continuación, el probador de servicio revisa el informe y, si hay errores, informa al desarrollador de guardia sobre ellos. Y si todo está bien, se lo pasa al gerente de turno. Si él da el visto bueno, el desarrollador de turno lanza el lanzamiento.

Es importante aclarar que las tareas de los diferentes equipos se incluyen en el lanzamiento, por lo tanto, es beneficioso para todos cuando un desarrollador de turno está claramente asignado para los lanzamientos, que ha estado trabajando toda la semana en lanzamientos continuos y monitoreando el monitoreo de errores. Esto permite a otros desarrolladores de proyectos cambiar a nuevas tareas lo antes posible (en realidad, inmediatamente después de enviar a Merge Queue).

Por lo general, todas las actividades de lanzamiento ocurren durante el horario comercial (incluso desde casa, les pedimos a todos que observen el régimen; como resultado, todos lo rompen en diferentes direcciones, pero no dejamos de intentarlo), pero si algo está mal en la producción, el turno de servicio despertará al desarrollador en servicio, que él respondió rápidamente.

Les recuerdo que la tarea principal es reducir el tiempo de sincronización de los miembros del equipo entre sí y la cantidad de rutina: todos saben quién está de servicio. Todos saben qué hacer y cómo, todos tienen instrucciones. Cuando el gerente permite que se implemente la versión, no le explicará al desarrollador el procedimiento, el desarrollador lo sabe todo y sabe cómo.

Donde ganó el tiempo: sincronización, toma de microdecisiones.
El ciclo se cerró.

El trabajo distribuido es una vacuna contra procesos malos e ineficientes que inhiben los proyectos incluso en las condiciones habituales, por no hablar de los no estándar. La experiencia de nuestro equipo confirma que si, con el debido tedio, pasa a establecer procedimientos e interacciones y cumple con todas las reglas, sin importar cuán comunes puedan parecer, el flujo de trabajo será bastante difícil de paralizar.

Algo que recuerda a la gestión del tráfico: cuando había pocos automóviles y eran lentos, pocas personas pensaban en las normas de tránsito. Ahora hay muchos automóviles y son rápidos: el movimiento sin reglas se ha vuelto imposible. Cuanto mejor (y al mismo tiempo más simple) se formulan estas reglas, cuanto más se cumplan los participantes del tráfico, mayor será la capacidad de tráfico de las carreteras.

Gracias por leer hasta el final. ¡Nos vemos en los comentarios!

El trabajo de un equipo distribuido en condiciones de autoaislamiento: como casi no notamos la diferencia