Anfälle

In diesem Artikel möchte ich meine Erfahrungen darüber teilen, wie wir das Problem des Einfrierens von Aufgaben in unserem Unternehmen gelöst haben.

Ich arbeite in einem Startup, das wie alle Startups eine Wachstumsphase von 10 Personen vor einem Jahr auf heute 35 Personen durchläuft, und die Anzahl der Programmierer ist in dieser Zeit von 5 auf 25 Personen gestiegen, und die meisten von ihnen sind in den letzten sechs Monaten gekommen.

Die Struktur des Unternehmens würde ich trotz seiner Jugend als altmodisch bezeichnen, da noch nie jemand an Bauprozessen beteiligt war. Mit dem Wachstum teilten wir uns in ein Entwicklungsteam, ein Testteam und ein Entwicklerteam auf, und alles funktionierte mehr oder weniger.

Der Entwicklungsprozess, wenn er als "Prozess" bezeichnet werden kann, sah folgendermaßen aus:

Die Arbeit des Entwicklers endete, sobald der Code die Codeüberprüfung bestanden hatte und er ihn in die Entwicklung verpfändete.

Die Arbeit des Testers endete, als er in der Master-Branche testete und smerzhil.
Die Entwickler klickten manchmal auf die Schaltfläche "Deploy to Prod", nachdem der Manager des täglichen Projekts gesagt hatte: "Sie wurden schon lange nicht mehr bereitgestellt. Vielleicht werden wir heute abgebrochen?"

Was gut:

• Viele Automatisierungen, z. B. Status in Jira, werden mit Zweigbezeichnungen in GitLab synchronisiert, eine Aufgabe in Jira wird nach einem Deployment für Prod geschlossen, der Code wird automatisch zum Testen und Staging von Umgebungen mit einer Zusammenführung von Entwickeln und Mastern bereitgestellt.
• Alles wird mit Tests vertuscht.
• Programmierer schreiben selbst Testpläne und testen die Hauptfunktionen.

Die Probleme:

• Tester können da eine Woche lang nichts machen Aufgaben hängen in der status code_review. Am Ende der Woche machen die Programmierer noch diesen Test und am Montag haben die Tester viel Arbeit.
• Da nach der Codeüberprüfung alles in der Entwicklung behoben ist und wenn etwas einen Fehler enthält, können wir nichts bereitstellen. Während ein Entwickler diesen Fehler behebt, stinkt ein anderer möglicherweise nach einer anderen Funktion, die ebenfalls einen Fehler enthält. Aus diesem Grund haben wir ein oder zwei Wochen gewartet, bis sich dieser Brunch stabilisiert hat und der Tester Zeit hat, ihn im Master zu stampfen, bevor einer der Entwickler etwas anderes für die Entwicklung festlegt.
• Bereitstellen von Features in großen Bundles, wodurch das Risiko erhöht wird, dass während der Bereitstellung etwas schlecht getestet oder abgefangen wird.

Ich werde zwei Fälle beschreiben, die uns klar gemacht haben, dass es unmöglich ist, weiterzuarbeiten.

So hatten wir zum Beispiel an einem Freitag 15 Brunchs im Status code_review und am Montag haben alle den Status auf ready_for_test geändert. Tester sagten dem Daily, wie sehr sie uns lieben. Und drei Monate lang konnten wir aus verschiedenen Gründen nicht ein paar ziemlich große Features verkaufen.

Zunächst haben wir eine Menge code_review herausgefunden. Es stellte sich heraus, dass sich dieses Problem mit den folgenden Regeln ganz einfach lösen lässt:

1. Es können nur drei Tasks im Status code_review sein. Dies ist die wichtigste Regel, die nicht verletzt werden kann.
2. Wenn der Programmierer die Entwicklung abgeschlossen hat und die Aufgabe in code_review übersetzen möchte, prüft er, ob er dies kann (siehe Regel 1).
3. Wenn der Status code_review bereits drei Aufgaben enthält, hilft er zuerst seinem Kollegen bei der Codeüberprüfung. Wenn er während des Überprüfungsprozesses Kommentare oder Änderungsvorschläge hat, führt er die Paarprogrammierung mit einem Kollegen durch, dessen Aufgabe er überprüft.

Die Hauptidee ist, den Code nicht einfrieren zu lassen, wenn er bereits geschrieben wurde, und den Testern für eine Woche einen gleichmäßigen Arbeitsfluss zu bieten.

Wir haben dies in einer Stunde umgesetzt: Wir haben uns getroffen, besprochen und eine Überprüfung durchgeführt und eine Paarprogrammierung durchgeführt.

Wenn jemand die erste Regel vergisst (und manchmal muss jemand sie vergessen), fliegt der Satz „Wir haben mehr als 3 PR in code_review“ sofort in den Chatraum. Lassen Sie uns überprüfen !!! ". Gleichzeitig gibt es keine spezielle Person, die dafür sorgen würde, dass nicht mehr als drei Pull-Requests eingehen. Dies wird von den Entwicklern selbst durchgeführt.

Trotz der Tatsache, dass diese Änderungen es uns ermöglichten, das Einfrieren der Aufgaben zu verhindern, hatten wir weiterhin Probleme mit der Bereitstellung und dem Austreten von Fehlern in der Entwicklung. Seitdem haben wir uns nach der Codeüberprüfung immer im Entwicklungszweig zusammengeschlossen und es wurde automatisch in der Testumgebung zum Testen bereitgestellt.

Diese Lösung war eine Art Hotfix, und dann mussten grundlegende Änderungen an den Prozessen vorgenommen werden.

Wir haben uns entschlossen, die Verantwortungsbereiche zu verlagern. Jetzt hat das Unternehmen kein separates Entwicklungsteam, Testteam oder Entwicklerteam, das Aufgaben aufeinander überträgt und nur für ihren Teil verantwortlich ist.

Wir haben die Entwickler in mehrere Teams gegliedert: eines für jeden Kunden, da wir ein Hauptprodukt haben, das jedoch für jeden Kunden schon seit längerer Zeit maßgeschneidert ist (wir sind eine Mischung aus Produkt- und Dienstleistungsunternehmen). Der Versand der Produkte zum Produkt liegt nun in der Verantwortung des Teams. Es gibt keine vertrauten Testteams und Entwickler, aber QA als Service und DevOps als Service.

QA as a Service ist ein Team, das nicht testet, sondern die Qualität der Produkte sicherstellt. QS-Ingenieure helfen Entwicklern beim Erstellen von Testplänen und bei der Teilnahme an Testsitzungen. Deshalb haben wir sie von manuellen Tests befreit, und sie hatten Zeit, End-to-End-Tests zu schreiben und Tools zu entwickeln, die beim Testen helfen. Wir haben auch ein Überwachungssystem implementiert.

DevOps as a Service ist ein Team, das Bereitstellungsskripts entwickelt, die Arbeit in Testumgebungen unterstützt und verschiedene Aufgaben automatisiert.

Der neue Entwicklungsprozess ist folgender:

1. Es gibt eine Aufgabe vom Kunden, Produktmanager oder einer der Spitzen.
2. In der Sprint-Planungsphase nehmen wir dies in die Entwicklung auf.
3. Der Entwickler schreibt den Code in einen separaten Zweig für die Aufgabe und übersetzt ihn nach Abschluss in den Status code_review.
4. Einer der Kollegen macht eine Überprüfung.
5. Wenn der Task die Überprüfung bestanden hat, fügt der Entwickler alles, was für die Entwicklung und Bereitstellung dieses Zweigs in der Testumgebung festgeschrieben ist, in den Zweig ein.
6. Dann plant er eine Rallye, die wir als Testsession bezeichnen, und lädt bei Bedarf einen QS-Techniker und Kollegen dazu ein.
7. Der QS-Techniker überprüft und verfeinert den Testplan vor der Testsitzung.
8. Während der Testsitzung durchläuft der Entwickler den gesamten Testplan als Demo. Manchmal wird ein Testplan in Teile zerlegt und dann parallel getestet. Die Hauptsache ist, dass dies zusammen in einem separaten Raum für Besprechungen durchgeführt wird.
9. Wenn nach dem Testen der Fehler keine gefunden wurden, führt der Entwickler seinen Code in den Entwicklungszweig und sofort in den Hauptzweig ein (dies haben wir noch nicht geändert, da wir die Bereitstellungsskripten noch aktualisieren müssen). In Zukunft planen wir, nur die Master-Filiale zu verlassen.
10. Danach startet der Entwickler die Bereitstellung beim Staging, um sicherzustellen, dass die Bereitstellung in einer Umgebung ausgeführt wird, die mit dem Produkt identisch ist.
11. Wenn alles in Ordnung ist, setzen Sie es sofort auf dem Produkt ein. Die Entscheidung über die Bereitstellung oder Nichtbereitstellung wird vom Entwicklungsteam getroffen. QA hat jedoch das Recht, die Bereitstellung zu beenden, wenn zusätzliche Tests erforderlich sind oder wenn gewartet werden muss, bis ein kritischer Fehler auf dem Produkt behoben werden muss.

Interessanterweise hat diese Transformation einige zusätzliche Änderungen nicht im Entwicklungsprozess, sondern in der Planung ausgelöst und die Themen geändert, über die wir in der Tageszeitung sprechen.

Nun, weil Der Entwickler ist für die Bereitstellung der User Story für das Produkt verantwortlich. Bei der Planung haben wir damit begonnen, die User Story so zu schreiben, dass sie unabhängig von den anderen ist und auch unabhängig von diesen bereitgestellt werden kann. User Story wurde größer, aber sie wurden kleiner.

Auch bei der Planung bewerten wir nicht die Entwicklungszeit, sondern besprechen, wann wir eine Funktion bereitstellen möchten.

Bei der Tageszeitung sagen wir nicht "Ich bin mit der Entwicklung fertig", sondern "Heute werde ich Feature X bereitstellen" oder "Heute nehme ich die Testumgebung mit. Wer hat Zeit, mir bei der Testsitzung zu helfen?"

Aus diesem Grund haben wir unabhängige Entwicklungsteams entwickelt, die über eigene Testumgebungen verfügen und planen, was und wann bereitgestellt werden soll.