Der Mensch ist der Hauptwert eines Unternehmens. Der Erfolg des Ganzen hängt davon ab, wie Menschen miteinander kommunizieren, wie sie ihre Ziele gemeinsam erreichen und wie sie zusammenarbeiten. Durch die ständige Verbesserung von Fähigkeiten, Prozessen und Werkzeugen können Sie effizienter arbeiten.
Wir auf dem Markt arbeiten daran, unseren Benutzern so schnell wie möglich neue Funktionen bereitzustellen. Dazu untersuchen wir ständig unsere Prozesse und optimieren alle Phasen der Aufgabe. Heute werden wir Habrs Lesern von der Optimierung eines von ihnen erzählen, nämlich dem Codeüberprüfungsprozess.
Zuerst müssen Sie sich vorstellen, welche Art von Entwicklungsfluss wir angenommen haben:
Das Gleiche, nur Punkt für Punkt und in Worten:
- Der Entwickler übernimmt die Aufgabe.
- Macht sie.
- Füllt Github aus und öffnet PR.
- Besteht eine Codeüberprüfung.
- Sammelt einen Demo-Stand und gibt ihn einem Tester.
- Der Tester überprüft den Demo-Stand.
- Verifizierte Aufgabe wird in Release gesammelt.
- Testen in der Version.
- Layout auf Art.-Nr.
- Letzte Prüfung im Kampf.
Nach Verantwortungsbereichen ist die Aufgabe in folgende Schritte unterteilt:
1-5 - Verantwortung des Entwicklers;
6-7 - Verantwortung beim Tester;
8-10 - Verantwortung beim Release Master.
Also begannen sie zu analysieren, was uns am meisten Zeit kostet. Glücklicherweise gibt es interne Analysewerkzeuge. Jeder hat sich darauf verlassen, was am längsten dauern wird, natürlich der Entwicklungsprozess selbst (der Status ist "In Arbeit") ... und es hat sich so herausgestellt. Aber ein Moment hat uns am meisten überrascht. Die durchschnittliche Dauer einer Überprüfung beträgt zwei Wochen!
Schritt 1. PR analysieren
Als sie anfingen, Pull-Anfragen zu studieren, sahen sie sich sofort einer sehr interessanten Tatsache gegenüber. Es stellte sich heraus, dass wir einen riesigen Friedhof mit nicht geschlossenen Pull-Anfragen haben. Die meisten Autoren dieser PRs arbeiteten nicht mehr für das Unternehmen, aber ihr Erbe war immer noch bei uns. Wer noch nie Dinosaurier gesehen hat, hier sind sie:
Diese Pull-Anforderungen fügten Rauschen hinzu und störten die korrekte Analyse der Codeüberprüfungszeit. Mit einem ruhigen Geist schlossen wir sie. Es blieb nur die Zeit zu erzählen. Aber es war immer noch im Bereich von 2-3 Tagen. Nicht gut.
Schritt 2: Demontage mit einem Browner
Reviewer ist ein in Yandex entwickeltes System, das zwei zufällige Personen mit Fachkenntnissen in einem veränderlichen Code und unter Berücksichtigung von Urlaub und Abwesenheit in die PR einbezieht. Die Analyse der wöchentlichen PRs ergab eine Gruppe von Personen, die die Codeüberprüfung ständig herausziehen. Nachdem wir Kollegen interviewt hatten, fanden wir ein weiteres Problem in unserem Prozess. Die Kollegen beschwerten sich, dass sie von den Eifersüchtigen zu viele Pull-Anfragen pro Tag erhalten hätten und einfach nicht genug Zeit für ihre Hauptarbeit hätten.
Dies stimmte nicht mit unseren Indikatoren überein: ein oder zwei PR pro Tag und Person. Die Studie führte zu Github, wo wir ein separates Team von Gutachtern haben. Dieses Team wurde seit mehreren Jahren nicht mehr aktualisiert. Seitdem hat sich die Anzahl der Mitarbeiter verdoppelt, aber keiner der Neuankömmlinge wurde in das Reviewerteam aufgenommen. Mit anderen Worten, die Hälfte des Teams hat überhaupt nicht an der Codeüberprüfung teilgenommen! Dieses nervige Missverständnis wurde korrigiert.
Schritt 3. Tools erweitern
Zu diesem Zeitpunkt haben wir versucht, das ohnehin schon einfache Leben der Rezensenten zu vereinfachen. Die folgenden Tools befanden sich im Arsenal des Frontends:
- Code Style Checker;
- Testlauf;
- verschiedene nerdige Checks in PR selbst;
- Revisionist;
- Warnungen auf Mail und Task-Tracker.
Es scheint, dass alles da ist. Nehmen Sie und überprüfen Sie!
Das erste, was sich als falsch herausstellte: ein anderer Codeüberprüfungsprozess in verschiedenen Repositorys. Wir haben das Anbringen von Etiketten für die bequeme Suche nach PRs über die Github-Oberfläche vereinheitlicht und gleichzeitig bewiesen.
Das zweite, was ihnen aufgefallen ist: Mail ist nicht das beste Tool, um schnell über den Status von Codeüberprüfungen zu berichten. Viele, um nicht von der Arbeit abgelenkt zu werden, analysieren seine Post mehrmals am Tag. Boten sind eine ganz andere Sache. Die Reaktion auf Nachrichten in Messenger ist viel höher. Und es wurde beschlossen, den Bot mit unserem Messenger zu verbinden. Der Bot sendet Warnungen über den Status einer Codeüberprüfung sowohl für den Autor der Pull-Anforderung als auch für die Überprüfung. Sehr bequem.
Schritt 4. Erste SLA
Parallel zu den Aktionen 2 und 3 haben wir begonnen, eng mit den Mitarbeitern zusammenzuarbeiten und zu erklären, dass die Codeüberprüfung untrennbar mit der eigentlichen Aufgabe verbunden ist. Sie erklärten, dass es in der Verantwortung des Entwicklers liege, "Verifiziert" zu bringen. Darüber hinaus liegt die Verantwortung nicht nur gegenüber Kollegen, sondern auch gegenüber Benutzern! Schnelle Lieferung von Funktionen an den Vertrieb - das wollte ich erreichen. Und das Team war mit dem Verbesserungsprozess einverstanden.
Zu diesem Zeitpunkt wurde die erste Idee der idealen Codeüberprüfung geboren. Natürlich möchte jeder, dass es in 5 Minuten stattfindet, aber das ist nicht immer möglich. Unter Berücksichtigung der Tatsache, dass wir ein multiregionales Team haben (mit einem Zeitunterschied von vier Stunden), haben wir vereinbart, dass unsere SLA einen Tag beträgt, d. H. 24 Stunden Diese SLA wurde allen Mitarbeitern angekündigt und begann, sich die Hände zu reiben, auf die Ergebnisse zu warten.
Die Situation hat sich jedoch nicht geändert. In den besten Wochen passt die Hälfte der Pull-Anfragen in einen Tag. Der Rest stieg für ihn aus.
Wir hatten ein kleines Skript, das die Überprüfung des Zeitcodes auf PR auswertete. Wir begannen, sie täglich für alle PRs verantwortlich zu machen, die auf der Suche nach "Rückstand" waren. Fast jeden Tag gab es eine Packung davon.
Es dauerte lange, sie zu analysieren. Meistens berechnete das Skript selbst den Zeitpunkt der Überprüfung unredlich. Er hat nicht berücksichtigt, dass einige PRs außerhalb der Arbeitszeit erstellt wurden (ja, einige mutige Fachkräfte arbeiten gerne ein oder zwei Stunden nachts, kommen zu uns, um zu arbeiten!). All dies hat uns gezeigt, dass unsere Tools zur Überwachung von Pull-Anforderungen nicht die effektivsten sind, da sie unehrlich sind. Ich muss neue Werkzeuge finden.
Schritt 5. SLA Tracker
Hilfe kam von dort, wo sie nicht gewartet hatten. Unsere Kollegen von Tracker haben eine erstaunliche Sache angekündigt: Jetzt können Sie SLA im Tracker selbst installieren. Darüber hinaus können Sie es ganz anders konfigurieren. Ein bestimmter Timer wird durch ein Ereignis in der Aufgabe aktiviert. Für einige Ereignisse kann es pausieren. Und bei einer Veranstaltung anhalten. Ja, das brauchen wir!
Sie haben sich sofort mit der Dokumentation befasst (übrigens hier ) und unsere Warteschlangen eingerichtet (es gibt mehrere davon, da es mehrere Repositories gibt). Wir stellen den Timer so ein, dass er sich einschaltet, wenn er in den Status "Codeüberprüfung erforderlich" wechselt, und endet, wenn er in einen anderen Status wechselt, mit Ausnahme von "Es gibt Kommentare" - wenn er läuft, pausiert der Timer, d. H. hat seine Zeit nicht verloren.
Es war auch cool, dass der Timer Arbeitszeiten und einen Kalender berücksichtigte! Wir setzen, dass 9h der Codeüberprüfung zugewiesen ist, d. H. ein Werktag. In diesem Fall wird 2 Stunden nach dem Start oder wenn eine Frist von neun Stunden unterbrochen wird, eine Warnung ausgelöst. Das Ergebnis war eine Art ehrliche Überwachung. Zuerst haben wir den Timer für das Experiment eingeschaltet, eine Packung Fehler gesammelt und in den Tracker exportiert.
Es ist anzumerken, dass der Timer nur für Aufgaben aktiviert wurde, die nach der Implementierung des Timers selbst erstellt wurden. Daher konnte der sofortige Effekt nicht gesehen werden. Aber schon zu diesem Zeitpunkt begann eine positive Dynamik. Wir hatten den Effekt einen Monat später, als der Fluss neuer Tickets mit einem Timer begann, die alten zu verdrängen. Es war bemerkenswert, dass sich die ungefähre Zeit der Codeüberprüfung auf den Bereich der Erinnerungsnachrichten konzentrierte, d.h. markiert 2h und 9h.
Zum Zeitpunkt dieses Schreibens haben wir 415 Aufgaben, bei denen der Timer gestartet wurde. Davon gingen 29 über die Neun-Stunden-Grenze hinaus. Wenn Sie genauer hinschauen, werden Sie jedoch auch auf solche Aufgaben stoßen, deren Codeüberprüfung innerhalb der nächsten Stunde abgeschlossen wurde. Wenn wir sie auch verwerfen, bleiben 17 Aufgaben übrig. Und das sind ungefähr 4,1%!
Das Ergebnis. Samurai schärft ständig sein Schwert
Wenn wir zurückblicken und uns an alle unsere Handlungen erinnern, kann eine Schlussfolgerung gezogen werden - alle Mittel sind gut. Alle unsere Schritte führten zum gewünschten Ergebnis: Mehr als 92% der Pull-Anfragen erfüllten unsere SLA ! Immer weniger zerrissene Aufgaben, die Codeüberprüfung ist schneller. Langsam, nach und nach, passten 75% der Codeüberprüfung in 5 Stunden ! Und die Dynamik für Verbesserungen ist immer noch positiv. Zusätzlich zu den numerischen Indikatoren erhielten wir zunehmend positive Rückmeldungen von Subunternehmern. Noch zufriedener mit der Tatsache, dass das Team auf diesen gesamten Prozess reagiert hat. Sogar ein Prozess wie die Beschleunigung der Codeüberprüfung brachte das Team noch mehr auf Trab. Jeder Teilnehmer begann zu verstehen, welche Verantwortung er vor anderen trägt, da ein schneller Überprüfungscode es uns ermöglicht, unseren Benutzern noch schneller Vorteile zu bieten.
Natürlich ist 9h nicht der ultimative Traum, aber immer noch Erfolg. Aber wir wollen nicht damit aufhören. Wir überwachen weiterhin den Codeüberprüfungsprozess und lösen alle technischen und sogar psychologischen Probleme, mit denen Mitarbeiter konfrontiert sind, damit unser Prozess so produktiv wie möglich und gleichzeitig für das Team angenehm ist.
Fragen und Antworten. Was ist, wenn ...?
F : Was ist, wenn ich denke, dass sie mich beobachten? Wofür ist dieser Timer?
A : Wir überwachen nicht speziell für jemanden, sondern für den Prozess. Die Pull-Anfrage hat zwei Seiten: den Autor und die Rezensenten. Wenn die Prüfer den Scheck herausziehen, leidet der Autor. Andererseits ist es auch unmenschlich, Inspektoren sofort von der Arbeit zu reißen. Es ist notwendig, ein Gleichgewicht zu finden, damit beide Seiten bequem sind. Der Timer wird nicht benötigt, um jemanden zu bestrafen, sondern um alle Abweichungen aufzuzeichnen. Die meisten dieser Abweichungen sind nicht auf das Verschulden der Prüfer zurückzuführen, sondern auf das Verschulden technischer Probleme. Die Herausforderung besteht darin, diese Probleme zu beheben. Damit andere ihnen nicht begegnen. Kontinuierliche Selbstverbesserung
F : Und was ist, wenn es komplexe PR, mehr als 100500 Codezeilen und "Change the Letter" gibt? Wo ist die Gerechtigkeit?
A : Ja, das ist wahr. Als wir an der Standard-Codeüberprüfung arbeiteten, haben wir sie nur entlang der oberen Grenze genommen, d. H. Die Codeüberprüfung komplexer PR sollte in das SLA passen. Gleichzeitig haben wir aber nicht das Ziel, alle an diese Grenzen zu bringen. Wir sind immer sympathisch, Anfragen zu stellen, in denen es trotz der gebrochenen Messlatte an einem Tag eine lebhafte, nützliche Diskussion gibt.
Wir haben Pläne für SLA-Noten für Storypoints. Zum Beispiel 1SP - 1h, 3SP - 5h, 5SP - 2d. Glücklicherweise ist der Tracker dazu bereits in der Lage. Wir sind einfach noch nicht bereit dafür - wir haben noch einen langen Weg vor uns.