🙅🏻 👩🏾‍🤝‍👨🏿 🤬 Le travail d'une équipe répartie dans des conditions d'isolement: comme on n'a presque pas remarqué la différence 🛀🏽 🧓🏽 🚰

Le mode d'auto-isolement a forcé de nombreuses personnes à travailler à domicile. C'est plus facile pour quelqu'un, plus difficile, et quelqu'un ne remarquerait pas du tout la différence, mais après l'annonce de la semaine de quarantaine (puis du mois), l'augmentation des publications Lifehack, de l'efficacité et de la productivité dans le flux a considérablement augmenté.

Je m'appelle Mikhail Troshev, je dirige le service d'interface de recherche Yandex. Notre équipe travaille sur une base distribuée depuis de nombreuses années - je vais vous expliquer ci-dessous en quoi elle diffère, comment elle est similaire à «à distance», comment elle est organisée, pourquoi elle ne se casse pas et comment notre expérience peut être utile à ceux qui ont été subitement pris brutalement par un changement de mode de fonctionnement.

Quelque chose vous semblera sûrement banal (Agile, Scrum, Kanban, DevOps - wow découvertes!), Mais c'est comme charger le matin: tout le monde sait que c'est utile, mais pour une raison quelconque, la paresse se fait régulièrement et en pleine force. Donc: nous le faisons. Et il fonctionne.

Pas à distance, mais distribué

À quoi cela ressemble: 90 fournisseurs frontaux se réunissent chaque jour dans les bureaux de Moscou, Saint-Pétersbourg, Kazan, Innopolis, Iekaterinbourg, Simferopol et Minsk - il est facile de remarquer que nous sommes séparés non seulement par les distances, mais aussi par les fuseaux horaires. Cependant, ce n'est pas tout: les distributeurs front-end sont répartis entre des équipes produit (équipes virtuelles) d'environ trois à sept + back-end, designers, testeurs et managers (en 2019, il a parlé en détail de nos structures de travail ici ). Autrement dit, presque tous les membres d'une telle équipe sont dans des villes différentes. Pas tout à fait à distance, mais très proche de cela: bien que plusieurs collègues soient encore à proximité, les possibilités de microsynchronisation avec les autres sont significativement limitées par rapport au travail en open space.

Il est nécessaire d'utiliser une communication asynchrone avec un long délai de réaction. Plus l'équipe est dispersée entre les différents bureaux, plus dans l'interaction quotidienne de travail, les frais généraux d'attente que tout projet peut enterrer. Pour gagner du temps:

- le cycle de vie de chaque tâche de l'idée à la production est organisé de la manière la plus cohérente possible: procédures, statuts, transition entre les étapes - tout ce qui est possible est formalisé (environ 90% des tâches). En même temps, nous essayons de garder la bureaucratie simple et compréhensible, sinon elle cesse d'être utile et commence à interférer;

- toute l'équipe est au courant des règles régissant le processus de travail et essaie de les suivre clairement; Nous essayons d'automatiser la routine. Ainsi, chacun est occupé par sa propre entreprise et ne perd pas de temps à faire le même type de micro-décisions: programmeurs - programme, chefs de produit proposent des fonctionnalités produit, designers - designers.

Rien de nouveau, non? Cependant, cette approche simple nous a beaucoup aidés dans les conditions d'auto-isolement: chaque employé peut apporter un maximum d'avantages par lui-même, car il connaît les détails suffisants pour le travail.

Mais tout d'abord.

Étape 0. Planification

Chaque équipe a un carnet de commandes, dont le sommet est évalué et priorisé:

Le point fondamental est que chaque membre de l'équipe doit comprendre: cette tâche doit être accomplie car elle est liée à l'épopée, l'épopée est liée à l'objectif et l'objectif est important. Sinon, soit les gens peuvent commencer à faire ce qui n'est pas nécessaire, soit le gestionnaire sera obligé de surveiller et d'éteindre constamment les incendies. Ce dernier, en passant, peut être difficile à remarquer au bureau, mais il est impossible de le manquer à distance: il y a beaucoup de confusion, le travail est en cours, une douzaine de bavardoirs démarrent dans le messager pour tenter de se synchroniser - en conséquence, toute l'équipe discute au lieu d'écrire du code. Il est extrêmement important d'organiser la planification en équipe afin que chaque participant au processus comprenne quoi et dans quel ordre il doit faire. Le chef d'équipe pourra alors se concentrer sur le produit sans être distrait par de petites questions constantes.

Bien sûr, il est impossible de détailler l'intégralité de l'arriéré, mais une étude de haute qualité de son sommet vous permet de recruter rapidement de nouvelles tâches dans le sprint - presque toutes les équipes vivent dans des sprints de deux semaines - et de maintenir une réserve pour la suivante. Avec cette approche, une équipe expérimentée peut taper un sprint même sans manager, s'il s'avère soudainement inaccessible.

Afin de ne pas étirer le temps de travail sur la tâche, l'équipe est engagée dans une «bureaucratie utile»: le manager formule une description claire, les interprètes notent les bons statuts, les tâches «coulent» de gauche à droite sur la planche de sprint:

Ici, toute l'équipe voit l'image complète et actuelle du sprint. Si quelqu'un tombe malade, part en service ou en vacances, les autres participants reprennent immédiatement les tâches dans leur état actuel.

Eh bien, comment peut-il se passer de synchronisations quotidiennes, lorsque l'organisation formelle du processus n'est pas suffisante pour résoudre certains cas particuliers et que la bureaucratie est plus susceptible d'interférer avec le processus. Généralement, détailler les tâches par statut (ouvert> en cours> en révision> prêt pour le test> test> testé> prêt pour le développement> dev> rc> fermé) est suffisant, mais dans 10% des cas, vous devez clarifier quelque chose, le dire en mots, expliquer " sur les doigts ". Soit dit en passant, je suis convaincu que toutes les réunions de travail (y compris les stand-up) doivent être réalisées par communication vidéo, et pas seulement par la voix, car cela oblige à se mettre en ordre et à se mettre au travail.

Il est très important que toute l'équipe soit présente à la synchronisation: ils ont rapidement vérifié le contexte, trié les tâches et commencé à travailler, guidés par le conseil d'administration, sans perdre plus de temps à se poser des questions. Bien sûr, nous avons également des discussions de travail, mais nous essayons de ne pas les inonder et de les utiliser pour obtenir une réponse rapide (idéalement binaire): est-il possible de lancer la version, où trouver des instructions, avec qui discuter de l'API de la source de données.

Où le temps a gagné: synchronisation, micro-prise de décision

Étape 1. Développement: ouvert> en cours

«Ouvrir» - la tâche attend l'interprète. Les développeurs les récupèrent pour que chacun soit prêt le plus rapidement possible. Par exemple, il arrive que c'est vendredi dans la cour, et le développeur part en service la semaine prochaine (et cela est connu à l'avance, pendant un mois). Dans ce cas, il vaut mieux pour lui prendre une petite tâche afin de réussir à le faire en une journée: on essaie de ne pas transférer ce qui a commencé. Si quelqu'un n'a pas le temps de terminer le travail, il est préférable de verser tel quel, puis de terminer les restes avec une demande de piscine séparée.

J'ai déployé une copie de travail locale du projet - n'oubliez pas de transférer la tâche de «ouverte» à «en cours» afin que quelqu'un d'autre ne la prenne pas en charge. «Local», soit dit en passant, est un mot-clé - vous pouvez travailler de n'importe où, la qualité de votre connexion Internet ne sera pas un facteur de blocage. Maintenant que l'infrastructure et les réseaux sont surchargés, c'est très important. Notre serveur de développement local vous permet d'utiliser des vidages de données - des archives zip avec des données pour différentes demandes, afin que vous puissiez pleinement travailler sans Internet. Une fois que le développeur a terminé le travail et envoyé la demande de pool, l'automatisation est activée.

Là où le temps a gagné: une évaluation indépendante des forces et des capacités, il n'est pas toujours nécessaire de surmonter une connexion Internet instable

Étape 2. Contrôles automatiques: en cours> en révision

Avant que la tâche ne passe en revue, elle vérifie la qualité du code, les performances, le manque de bugs visuels et fonctionnels. Ici, on pourrait écrire beaucoup sur l'exhaustivité et la variété de nos contrôles automatiques, mais, premièrement, il s'appuie sur plusieurs histoires distinctes, et deuxièmement, il va bien au-delà du sujet discuté. Je vais simplement donner des liens vers la description des outils:

- un ensemble standard d'outils pour l'analyse statique: ESLint et Stylelint avec un riche ensemble de plug-ins;
- nos propres contrôles statiques: disponibilité et qualité des traductions, validation des fichiers yaml;
- outils standard pour les tests unitaires: Mocha , Karma , PhantomJS ,istanbul ;
notre propre outil de test visuel et fonctionnel, Hermione ;
- Pulse - pour les tests de performance - est également le nôtre. Ils l'ont mentionné ici .

Soit dit en passant, la tâche sera annulée ici en cas de problème à n'importe quel stade - malheureusement, même la planification la plus minutieuse n'économise pas 100% des erreurs, quelque chose peut mal tourner. La personne qui appelle appelle la bonne personne à la tâche, décrit l'essence du problème, télécharge des captures d'écran ou même des vidéos, peut également écrire des commandes dans le chat afin que tout le monde remarque que la tâche est au point mort. Quoi qu'il en soit - le bug est sorti pendant les tests, la conception a changé, il n'y avait pas assez de données du backend.

: — , - —

3. -: in review > ready for test

Tout d'abord, je veux appeler une demande de pool non seulement un réviseur gratuit, mais une personne qui comprend ce qui se passe dans votre code; deuxièmement, d'une équipe adjacente, afin que l'ensemble du service ait une idée de qui fait quoi - tout cela est précisé dans nos règlements. Même dans un petit bureau, il peut être difficile et long de l'organiser manuellement, sans parler de la distribution (et de l'auto-isolement!). Un réviseur de code automatisé vient à la rescousse: elle change également de statut par elle-même. Je ne m'attarderai pas en détail sur son fonctionnement, je ne le ferai pas - il vaut mieux écouter l'histoire du développeur. Elle sait également comment cingler les interprètes: plus la tâche est suspendue dans la revue, plus elle cingle violemment.

Où vous avez gagné du temps: recherchez le réviseur concerné, des rappels pour traiter la demande de pool

Étape 4. Test: test> testé

Une fois la modification réussie, passez des tests automatiques. Ce n'est qu'après qu'ils deviennent tous verts, que la tâche est transférée aux tests manuels. Il est important que pour la tâche, jusqu'à ce qu'elle soit clairement transmise à quelqu'un d'autre, l'interprète est toujours responsable - c'est lui qui doit rapidement faire glisser son code à travers la révision et les tests de code jusqu'à la production. Autrement dit, nous savons toujours qui est extrême, tout le monde surveille en permanence non seulement leurs tâches, mais aussi tout ce qui se passe dans l'équipe. Le testeur de l'équipe est généralement seul, ce qui est également pratique pour lui: il voit qu'il volera ensuite, il pourra utiliser son temps plus efficacement.

Le testeur peut:

- confier la tâche de test aux évaluateurs - un poste avec tous les détails. À la suite de tests effectués par des évaluateurs, quelque chose peut nécessiter des tests de recherche ou une nouvelle vérification;
- Testez la tâche vous-même sur un appareil en direct ou en utilisant une batterie d'appareils avec accès à distance - Ferme collective.

Les appareils en direct sont situés dans des hypercubes dans chaque bureau Yandex. Tout employé peut emporter l'appareil dont il a besoin avec les caractéristiques nécessaires, après avoir sélectionné le point le plus proche avec un appareil gratuit. Normalement, après un certain temps, le système vous rappellera automatiquement qu'il est temps de retourner l'appareil, mais cette fonction a été désactivée pendant le temps de l'auto-isolation. L'équipe de service s'est assurée que ceux qui en avaient un besoin critique avaient besoin des appareils vivants et que tout le monde, afin de ne pas ralentir les processus de travail, aidait à se connecter à la ferme collective.

Une batterie de serveurs collective est une batterie de périphériques de test à distance que n'importe qui peut utiliser. Android, iOS - nous vérifions les modifications même sur les versions les plus anciennes et les plus difficiles des systèmes à prendre en charge, afin que nos services soient accessibles à tous. Mais nous essayons également d'obtenir des produits phares dès que possible à la ferme collective et aux hypercubes. Rappelez-vous le «rideau» (c'est «monobrow») qui est apparu sur le neuvième iPhone, et tous les problèmes qui y sont associés?

Là où le temps a gagné: planification, tests automatiques, distribution d'appareils: disponible même avec auto-isolation

Étape 5. Infusion: prêt pour fev> dev

La tâche est testée - il est temps de la verser dans une branche commune.

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

Lorsqu'il y a beaucoup d'injections (par exemple, nous avons plus de 30 demandes de pool infusées par jour), deux problèmes surviennent:

- mineur : l'historique dans git, si vous vous inscrivez au hasard et ne rebase pas, cela devient très déroutant, et s'il y a une sorte de bogue , revenir en arrière est très difficile;

- critique : tests d'intégration. Il n'est pas toujours physiquement possible d'attendre la fin du test de vos modifications avec la dernière version du tronc, de sorte que les événements suivants peuvent se produire: deux demandes de pool, chacune individuellement ne cassant rien, briseront le tronc après la perfusion. Pour éviter cela, nous adhérons au développement basé sur le tronc, c'est-à-dire qu'une version peut être déployée à partir de n'importe quel commit. Et bien que nous ne soyons pas encore arrivés au déploiement continu, notre coffre est «vert». Et le casser même une fois par semaine est catégoriquement inacceptable pour nous.

Depuis plusieurs années, nous utilisons l'outil Merge Queue pour automatiser la file d'attente et nous l'améliorons constamment. Les modifications ne sont pas apportées par le développeur, mais par le robot. Dans chaque demande de pool, il rebase selon la dernière version de trunk et exécute un ensemble complet de tests. Il s'agit d'un processus assez long, il est donc impossible de le construire sur des personnes vivantes - une personne n'attendra tout simplement pas les résultats finaux. Et le robot fonctionne sans sommeil, repos et jours de congé. De plus, la tâche peut ne pas être mise en file d'attente par le développeur lui-même, mais par le testeur immédiatement après la fin du test, cela vous permet encore une fois de gagner du temps.

Plus de détailsÀ propos de la file d'attente de fusion.

Là où le temps a gagné: nous évitons les pannes bloquantes, vous n'avez pas besoin de contrôler manuellement l'infusion de la demande de pool

Étape 6. Sortie: rc> fermée

Chaque jour ouvrable à 5 heures du dernier commit dans le tronc, nous obtenons automatiquement une nouvelle version: assemblage de packages statiques et dynamiques, mise en page pré-stable, tests par des évaluateurs. Ensuite, le testeur en service examine le rapport et, s'il y a des bogues, en informe le développeur sur appel. Et si tout va bien, passez-le au gestionnaire de service. S'il donne le feu vert, le développeur en service déploie la version.

Il est important de préciser que les tâches des différentes équipes relèvent de la version, il est donc avantageux pour tout le monde lorsqu'un développeur sur appel est clairement alloué pour les versions, qui a effectué toute la semaine un travail sur les versions continues et la surveillance de la surveillance des erreurs. Cela permet aux autres développeurs de projets de passer à de nouvelles tâches le plus tôt possible (en fait immédiatement après l'envoi à Merge Queue).

Habituellement, toutes les activités de libération ont lieu pendant les heures de bureau (même à la maison, nous demandons à tout le monde d'observer le régime - en conséquence, tout le monde le casse dans des directions différentes, mais nous n'arrêtons pas d'essayer), mais si quelque chose ne va pas dans la production, le quart de travail réveillera le développeur en service, qu'il a répondu rapidement.

Je vous rappelle que la tâche principale est de réduire le temps de synchronisation des membres de l'équipe entre eux et la quantité de routine: tout le monde sait qui est de service. Tout le monde sait quoi faire et comment, tout le monde a des instructions. Lorsque le gestionnaire autorise le déploiement de la version, il n'explique pas la procédure au développeur, le développeur sait tout et sait comment.

Là où le temps a gagné: synchronisation, micro-prise de décision,
le cycle s'est clôturé.

Le travail distribué est une vaccination contre les processus mauvais et inefficaces qui inhibent les projets même dans les conditions habituelles, sans parler des projets non standard. L'expérience de notre équipe confirme que si, avec un peu d'ennui, vous passez à la mise en place de procédures et d'interactions et respectez honnêtement toutes les règles, aussi banales qu'elles puissent paraître, le workflow sera assez difficile à paralyser.

Quelque chose qui rappelle la gestion du trafic: quand il y avait peu de voitures et qu'elles étaient lentes, peu de gens pensaient aux règles de la circulation. Maintenant, il y a beaucoup de voitures et elles sont rapides - le mouvement sans règles est devenu impossible. Mieux (et en même temps plus simples) ces règles sont formulées, plus les participants à la circulation les respectent, plus la capacité de circulation des routes est élevée.

Merci d'avoir lu jusqu'au bout. A bientôt dans les commentaires!

Le travail d'une équipe répartie dans des conditions d'isolement: comme on n'a presque pas remarqué la différence