⛹🏽 💇🏼 👸🏿 Die Arbeit eines verteilten Teams unter Bedingungen der Selbstisolation: Da wir den Unterschied fast nicht bemerkt haben 🈚️ 🧛🏾 🤲🏻

Der Selbstisolationsmodus zwang viele, von zu Hause aus zu arbeiten. Es ist für jemanden einfacher, schwieriger, und jemand hätte den Unterschied überhaupt nicht bemerkt, aber nach der Ankündigung der Quarantänewoche (und dann des Monats) nahm das Wachstum der Posts über Life Hacks, Effizienz und Produktivität im Feed erheblich zu.

Mein Name ist Mikhail Troshev, ich leite den Yandex Search Interface Service. Unser Team arbeitet seit vielen Jahren auf verteilter Basis. Ich werde Ihnen im Folgenden erläutern, wie es sich unterscheidet und wie es sich aus der Ferne unterscheidet, wie es organisiert ist, warum es nicht kaputt geht und wie unsere Erfahrung für diejenigen nützlich sein kann, die plötzlich von einem Wechsel des Arbeitsmodus plötzlich getroffen wurden.

Etwas wird Ihnen sicherlich banal erscheinen (Agile, Scrum, Kanban, DevOps - Wow-Entdeckungen!), Aber es ist wie morgens aufzuladen: Jeder weiß, dass es nützlich ist, aber aus irgendeinem Grund wird Faulheit regelmäßig und mit voller Kraft durchgeführt. So machen wir es. Und es funktioniert.

Nicht aus der Ferne, sondern verteilt

Wie es aussieht: Täglich versammeln sich 90 Front-End-Anbieter in den Büros von Moskau, St. Petersburg, Kasan, Innopolis, Jekaterinburg, Simferopol und Minsk - es ist leicht zu erkennen, dass wir nicht nur durch Entfernungen, sondern auch durch Zeitzonen voneinander getrennt sind. Dies ist jedoch nicht alles: Front-End - Händler sind zwischen Produktteams (virtuelle Teams) verteilt von etwa drei Minuten vor sieben + Back-End, Designer, Tester und Manager (im Jahr 2019 sprach er ausführlich über unsere Arbeitsstrukturen hier ). Das heißt, fast alle Mitglieder eines solchen Teams befinden sich in verschiedenen Städten. Nicht ganz entfernt, aber sehr nah dran: Obwohl noch mehrere Kollegen in der Nähe sind, sind die Möglichkeiten der Mikrosynchronisation mit den anderen im Vergleich zur Arbeit im Freien erheblich eingeschränkt.

Es ist notwendig, eine asynchrone Kommunikation mit einer langen Reaktionsverzögerung zu verwenden. Je stärker das Team auf verschiedene Büros verteilt ist, desto mehr Wartezeit kann ein Projekt in der täglichen Arbeitsinteraktion begraben. Um Zeit zu sparen:

- Der Lebenszyklus jeder Aufgabe von der Idee bis zur Produktion ist so einheitlich wie möglich angeordnet: Verfahren, Status, Übergang zwischen den Phasen - alles, was möglich ist, wird formalisiert (ca. 90% der Aufgaben). Gleichzeitig versuchen wir, die Bürokratie einfach und verständlich zu halten, da sie sonst nicht mehr nützlich ist und sich einmischt.

- Das gesamte Team kennt die Regeln für den Arbeitsprozess und versucht, diese klar zu befolgen. Wir versuchen die Routine zu automatisieren. Somit ist jeder mit seinem eigenen Geschäft beschäftigt und verschwendet keine Zeit damit, die gleichen Mikroentscheidungen zu treffen: Programmiererprogramm, Programmmanager entwickeln Funktionen, Designer entwerfen.

Nichts Neues, oder? Dieser einfache Ansatz hat uns jedoch unter den Bedingungen der Selbstisolation sehr geholfen: Jeder Mitarbeiter kann für sich selbst den größtmöglichen Nutzen bringen, da er die für die Arbeit ausreichenden Details kennt.

Aber das Wichtigste zuerst.

Stufe 0. Planung

Jedes Team hat einen Rückstand, dessen oberster Wert bewertet und priorisiert wird:

Der grundlegende Punkt ist, dass jedes Teammitglied verstehen muss: Diese Aufgabe muss erledigt werden, weil sie an das Epos gebunden ist, das Epos an das Ziel gebunden ist und das Ziel wichtig ist. Andernfalls können entweder Personen damit beginnen, das zu tun, was nicht benötigt wird, oder der Manager wird gezwungen sein, die Brände ständig zu überwachen und zu löschen. Letzteres kann im Büro übrigens schwer zu bemerken sein, aber es ist unmöglich, es aus der Ferne zu übersehen: Es gibt viel Verwirrung, es wird gearbeitet, ein Dutzend Chatrooms beginnen im Messenger mit Synchronisierungsversuchen - daher chattet das gesamte Team, anstatt Code zu schreiben. Es ist von entscheidender Bedeutung, die Planung in einem Team zu organisieren, damit jeder Teilnehmer des Prozesses versteht, was und in welcher Reihenfolge er tun muss. Dann kann sich der Teamleiter auf das Produkt konzentrieren, ohne von ständigen kleinen Fragen abgelenkt zu werden.

Natürlich ist es unmöglich, den gesamten Rückstand nach unten zu detaillieren, aber eine qualitativ hochwertige Studie nach oben ermöglicht es Ihnen, schnell neue Aufgaben im Sprint zu rekrutieren - fast alle Teams leben in zweiwöchigen Sprints - und eine Reserve für den nächsten zu halten. Mit diesem Ansatz kann ein erfahrenes Team einen Sprint auch ohne Manager eingeben, wenn sich plötzlich herausstellt, dass er nicht mehr zugänglich ist.

Um die Arbeitszeit für die Aufgabe nicht zu verlängern, ist das Team in eine „nützliche Bürokratie“ verwickelt: Der Manager formuliert eine klare Beschreibung, die Testamentsvollstrecker schreiben die korrekten Status auf, die Aufgaben „fließen“ von links nach rechts auf das Sprintbrett:

Hier sieht das gesamte Team das vollständige und aktuelle Bild des Sprints. Wenn jemand krank wird, Dienst hat oder Urlaub macht, übernehmen andere Teilnehmer sofort Aufgaben in ihrem aktuellen Status.

Nun, wie kann es ohne tägliche Synchronisierungen sein, wenn die formale Organisation des Prozesses nicht ausreicht, um bestimmte Fälle zu lösen, und die Bürokratie den Prozess eher stört. Normalerweise reicht es aus, Aufgaben nach Status zu detaillieren (offen> in Bearbeitung> in Überprüfung> bereit zum Testen> Testen> getestet> bereit für dev> dev> rc> geschlossen), aber in 10% der Fälle müssen Sie etwas klären, es in Worten sagen, erklären “ an den Fingern ". Ich bin übrigens davon überzeugt, dass alle Arbeitstreffen (einschließlich Stand-Ups) über Videokommunikation und nicht nur über Sprache durchgeführt werden müssen, da dies einen dazu zwingt, sich in Ordnung zu bringen und sich auf die Arbeit einzustellen.

Es ist sehr wichtig, dass das gesamte Team bei der Synchronisierung anwesend war: Sie überprüften schnell den Kontext, sortierten die Aufgaben und begannen unter Anleitung des Boards zu arbeiten, ohne mehr Zeit mit Fragen aneinander zu verschwenden. Natürlich haben wir auch funktionierende Chats, aber wir versuchen, sie nicht zu überfluten und sie zu verwenden, um eine schnelle (idealerweise binäre) Antwort zu erhalten: Ist es möglich, die Version zu rollen, wo Anweisungen zu finden sind, mit denen die Datenquellen-API besprochen werden kann.

Wo die Zeit gewonnen hat: Synchronisation, Mikroentscheidung

Stufe 1. Entwicklung: offen> in Bearbeitung

"Öffnen" - die Aufgabe wartet auf den Darsteller. Entwickler holen sie ab, damit jeder so schnell wie möglich bereit ist. Es kommt beispielsweise vor, dass es Freitag auf dem Hof ist und der Entwickler nächste Woche seinen Dienst aufnimmt (und dies ist im Voraus für einen Monat bekannt). In diesem Fall ist es für ihn besser, eine kleine Aufgabe zu übernehmen, um sie an einem Tag zu erledigen: Wir versuchen, nicht zu übertragen, was begonnen wurde. Wenn jemand keine Zeit hat, die Arbeit zu beenden, ist es besser, sie so wie sie ist zu gießen und dann die Überreste mit einer separaten Poolanfrage abzuschließen.

Ich habe eine lokale Arbeitskopie des Projekts bereitgestellt. Vergessen Sie nicht, die Aufgabe von "offen" auf "in Bearbeitung" zu übertragen, damit sie nicht von einer anderen Person übernommen wird. "Lokal" ist übrigens ein Schlüsselwort - Sie können von überall aus arbeiten, die Qualität Ihrer Internetverbindung ist kein blockierender Faktor. Jetzt, da die Infrastruktur und die Netzwerke überlastet sind, ist dies sehr wichtig. Mit unserem lokalen Entwicklungsserver können Sie Datendumps verwenden - Zip-Archive mit Daten für verschiedene Anforderungen, sodass Sie überhaupt ohne Internet arbeiten können. Nachdem der Entwickler die Arbeit beendet und die Poolanforderung gesendet hat, wird die Automatisierung aktiviert.

Wo Zeit gewonnen wurde: Eine unabhängige Bewertung der Stärken und Fähigkeiten, ist es nicht immer notwendig, eine instabile Internetverbindung zu überwinden

Stufe 2. Automatische Überprüfungen: in Bearbeitung> in Überprüfung

Bevor die Aufgabe in die Überprüfung geht, werden die Qualität des Codes, die Leistung sowie das Fehlen visueller und funktionaler Fehler überprüft. Hier könnte man viel über die Vollständigkeit und Vielfalt unserer automatischen Überprüfungen schreiben, aber erstens stützt es sich auf mehrere separate Geschichten, und zweitens geht es weit über das diskutierte Thema hinaus. Ich werde nur Links zur Beschreibung der Tools geben:

- einen Standardsatz von Werkzeugen für die statische Analyse: ESLint und Stylelint mit einem umfangreichen Satz von Plug-Ins;
- unsere eigenen statischen Überprüfungen: Verfügbarkeit und Qualität von Übersetzungen, Validierung von Yaml-Dateien;
- Standardwerkzeuge für Unit-Tests: Mocha , Karma , PhantomJS ,Istanbul ;
unser eigenes funktionales und visuelles Testwerkzeug, Hermine ;
- Puls - für Leistungstests - ist auch unser eigener. Sie haben ihn hier erwähnt .

Übrigens wird die Aufgabe bei Problemen zu jedem Zeitpunkt hierher zurückgesetzt - leider spart selbst die sorgfältigste Planung nicht 100% vor Fehlern, es kann etwas schief gehen. Wenn er die richtige Person in der Aufgabe findet, beschreibt er die Essenz des Problems, lädt Screenshots oder sogar Videos hoch und kann zusätzlich Befehle in den Chat schreiben, damit jeder merkt, dass die Aufgabe ins Stocken geraten ist. Was auch immer es ist - der Fehler ist während des Testens aufgetreten, das Design hat sich geändert, es gab nicht genügend Daten vom Backend.

: — , - —

3. -: in review > ready for test

Erstens möchte ich eine Poolanfrage nicht nur an einen kostenlosen Prüfer richten, sondern an eine Person, die versteht, was in Ihrem Code geschieht. zweitens von einem benachbarten Team, damit der gesamte Service eine Vorstellung davon hat, wer was tut - all dies ist in unseren Vorschriften festgelegt. Selbst in einem kleinen Büro kann es schwierig und zeitaufwändig sein, es manuell zu organisieren, ganz zu schweigen von der Verteilung (und der Selbstisolierung!). Eine automatisierte Codeüberprüferin hilft: Sie ändert auch den Status selbst. Ich werde nicht näher darauf eingehen, wie es im Detail funktioniert. Ich höre mir besser die Geschichte des Entwicklers an. Sie weiß auch, wie man Performer pingt: Je länger die Aufgabe in der Rezension hängt, desto heftiger pingt sie.

Wo Sie die Zeit gewonnen haben: Suchen Sie nach dem relevanten Prüfer, Erinnerungen an die Verarbeitung der Poolanforderung

Stufe 4. Testen: Testen> getestet

Wenn die Änderung die Codeüberprüfung bestanden hat, führen Sie Autotests aus. Erst wenn alle grün werden, wird die Aufgabe auf manuelle Tests übertragen. Es ist wichtig, dass der Ausführende für die Aufgabe immer verantwortlich ist, bis sie eindeutig an eine andere Person weitergegeben wird - er sollte seinen Code schnell durch die Codeüberprüfung und das Testen in die Produktion ziehen. Das heißt, wir wissen immer, wer extrem ist. Jeder überwacht ständig nicht nur seine Aufgaben, sondern auch alles, was im Team passiert. Der Tester im Team ist normalerweise alleine, und das ist auch für ihn praktisch: Er sieht, dass er als nächstes fliegen wird, er kann seine Zeit effizienter nutzen.

Der Tester kann:

- den Prüfern die Aufgabe des Testens übertragen - einen Beitrag mit allen Einzelheiten. Als Ergebnis von Tests durch Prüfer kann etwas Forschungstests oder eine erneute Überprüfung erfordern.
- Testen Sie die Aufgabe selbst auf einem Live-Gerät oder verwenden Sie eine Farm von Geräten mit Remotezugriff - Collective Farm.

Live-Geräte befinden sich in Hypercubes in jedem Yandex-Büro. Jeder Mitarbeiter kann das benötigte Gerät mit den erforderlichen Eigenschaften nehmen, nachdem er mit einem kostenlosen Gerät den nächstgelegenen Punkt ausgewählt hat. Normalerweise erinnert Sie das System nach einer Weile automatisch daran, dass es Zeit ist, das Gerät zurückzugeben. Diese Funktion wurde jedoch für die Zeit der Selbstisolierung deaktiviert. Das Dienstteam stellte sicher, dass diejenigen, die es dringend benötigten, die lebenden Geräte brauchten und dass alle anderen, um die Arbeitsprozesse nicht zu verlangsamen, bei der Verbindung zur Kollektivfarm halfen.

Eine Kollektivfarm ist eine Remote-Testgerätefarm, die jeder verwenden kann. Android, iOS - Wir überprüfen Änderungen auch bei den ältesten und am schwierigsten zu unterstützenden Systemversionen, damit unsere Dienste für jedermann verfügbar sind. Wir versuchen aber auch, so schnell wie möglich Flaggschiffe sowohl auf der Collective Farm als auch in Hypercubes zu bekommen. Erinnern Sie sich an den „Vorhang“ (es ist „Monobrow“), der auf dem neunten iPhone erschien, und an alle damit verbundenen Probleme?

Wo Zeit gewonnen wurde: Planung, automatische Tests, Geräteverteilung: Auch bei Selbstisolierung verfügbar

Stufe 5. Infusion: bereit für fev> dev

Die Aufgabe wird getestet - es ist Zeit, sie in einen gemeinsamen Zweig zu gießen.

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

Wenn es viele Injektionen gibt (zum Beispiel haben wir mehr als 30 infundierte Pool-Anfragen pro Tag), treten zwei Probleme auf:

- geringfügig : Die Historie in Git wird sehr verwirrend, wenn Sie zufällig mitmachen und nicht neu gründen, und wenn es einen Fehler gibt Das Zurückrollen ist sehr schwierig.

- kritisch : Integrationstests. Es ist physisch nicht immer möglich, auf das Ende des Testens Ihrer Änderungen zusammen mit der neuesten Version von Trunk zu warten. Daher kann Folgendes passieren: Zwei Pool-Anforderungen, von denen jede einzeln nichts kaputt macht, brechen den Trunk nach der Infusion. Um dies zu verhindern, halten wir uns an die Trunk-basierte EntwicklungDas heißt, eine Freigabe kann aus jedem Commit heraus eingeführt werden. Und obwohl wir noch nicht endgültig zur kontinuierlichen Bereitstellung gekommen sind, ist unser Kofferraum „grün“. Und es einmal in der Woche zu brechen, ist für uns kategorisch inakzeptabel.

Seit einigen Jahren verwenden wir das Tool "Warteschlange zusammenführen", um die Warteschlange zu automatisieren, und verbessern sie ständig. Änderungen werden nicht vom Entwickler, sondern vom Roboter vorgenommen. Bei jeder Poolanforderung wird die Basis gemäß der neuesten Version von Trunk neu erstellt und eine vollständige Reihe von Tests ausgeführt. Dies ist ein ziemlich langwieriger Prozess, daher ist es unmöglich, ihn auf lebenden Menschen aufzubauen - eine Person wird einfach nicht auf die endgültigen Ergebnisse warten. Und der Roboter arbeitet ohne Schlaf, Ruhe und freie Tage. Darüber hinaus wird die Aufgabe möglicherweise nicht vom Entwickler selbst in die Warteschlange gestellt, sondern vom Tester unmittelbar nach dem Ende des Tests. Auf diese Weise können Sie erneut Zeit sparen.

Mehr DetailsInformationen zur Zusammenführungswarteschlange.

Wo die Zeit gewonnen hat: Wir verhindern das Blockieren von Ausfällen. Sie müssen die Infusion der Poolanforderung nicht manuell steuern

Stufe 6. Release: rc> geschlossen

Jeden Arbeitstag um 5 Uhr ab dem letzten Commit im Trunk erhalten wir automatisch eine neue Version: die Zusammenstellung statischer und dynamischer Pakete, die Berechnung der Prestable, die Prüfung durch Prüfer. Als nächstes überprüft der diensthabende Tester den Bericht und meldet, falls es Fehler gibt, den Bereitschaftsentwickler darüber. Und wenn alles in Ordnung ist, geben Sie es an den diensthabenden Manager weiter. Wenn er die Freigabe erteilt, rollt der diensthabende Entwickler die Freigabe aus.

Es ist wichtig zu klären, dass die Aufgaben verschiedener Teams in die Version fallen. Daher ist es für alle von Vorteil, wenn ein Bereitschaftsentwickler eindeutig für die Versionen zugewiesen ist, der die ganze Woche über an fortlaufenden Versionen gearbeitet und die Fehlerüberwachung überwacht hat. Auf diese Weise können andere Projektentwickler so früh wie möglich zu neuen Aufgaben wechseln (tatsächlich unmittelbar nach dem Senden an die Merge Queue).

Normalerweise finden alle Release-Aktivitäten während der Geschäftszeiten statt (auch von zu Hause aus bitten wir alle, das Regime zu beachten - daher brechen alle es in verschiedene Richtungen, aber wir hören nicht auf, es zu versuchen), aber wenn etwas in der Produktion nicht stimmt, weckt die diensthabende Schicht den diensthabenden Entwickler. dass er sofort antwortete.

Ich erinnere Sie daran, dass die Hauptaufgabe darin besteht, die Synchronisationszeit der Teammitglieder untereinander und die Routine zu verkürzen: Jeder weiß, wer im Dienst ist. Jeder weiß was zu tun ist und wie, jeder hat Anweisungen. Wenn der Manager die Einführung des Releases zulässt, erklärt er dem Entwickler das Verfahren nicht, der Entwickler weiß alles und weiß wie.

Wo die Zeit gewonnen hat: Synchronisation, Mikroentscheidung.
Der Zyklus ist geschlossen.

Verteilte Arbeit ist eine Impfung gegen schlechte, ineffiziente Prozesse, die Projekte auch unter den üblichen Bedingungen hemmen, ganz zu schweigen von nicht standardmäßigen. Die Erfahrung unseres Teams bestätigt, dass es schwierig sein wird, den Workflow zu lähmen, wenn Sie mit angemessener Langeweile Verfahren und Interaktionen einrichten und alle Regeln ehrlich einhalten, egal wie alltäglich sie auch erscheinen mögen.

Etwas, das an das Verkehrsmanagement erinnert: Wenn es nur wenige Autos gab und sie langsam waren, dachten nur wenige Menschen über Verkehrsregeln nach. Jetzt gibt es viele Autos und sie sind schnell - Bewegung ohne Regeln ist unmöglich geworden. Je besser (und gleichzeitig einfacher) diese Regeln formuliert sind, desto gründlicher erfüllen die Verkehrsteilnehmer sie, desto höher ist die Verkehrskapazität der Straßen.

Vielen Dank für das Lesen bis zum Ende. Wir sehen uns in den Kommentaren!

Die Arbeit eines verteilten Teams unter Bedingungen der Selbstisolation: Da wir den Unterschied fast nicht bemerkt haben