Die Welt der Technologie verändert sich schnell, schneller als je zuvor. Vor ein paar Jahren dachten wir, dass nur die Amazons oder Facebooks dieser Welt in der Lage sein würden, Continuous Delivery zu betreiben. Jetzt gewinnt das Phänomen an Zugkraft, wird allmählich zum Mainstream und bevor wir uns versehen, wird es zur Massenware werden. Jeder wird es tun.
Und warum? Denn die Fähigkeit zur Freigabe verschafft Unternehmen oft einen großen Wettbewerbsvorteil gegenüber ihren Konkurrenten mit langsameren Durchlaufzeiten. Um kontinuierliche Lieferung zu praktizieren, müssen Teams Qualität in alles, was sie tun, einbauen. Das bedeutet, dass das eigentliche Produkt die Kunden nicht nur schneller erreicht - es ist auch ein besseres Produkt. Das Erlernen des Einbaus von Qualität mit Kanban hat meinem Entwicklungsteam geholfen, Verschwendung zu reduzieren, schneller zu liefern und besser mit der Organisation um uns herum zu kommunizieren.
Keep reading to learn how my development team changed our infrastructure, development practices, and culture to enable continuous delivery.
Wie Qualität und kontinuierliche Lieferung zusammenhängen
Ich hatte das Glück, Teil eines Teams zu sein, das daran arbeitete, die Fähigkeit unseres Unternehmens zu verbessern, schnell zu liefern. So habe ich die Turbulenzen erlebt, die entstehen, wenn man von einer Veröffentlichung pro Monat zu mehreren Veröffentlichungen pro Tag übergeht.
Die Anwendung traditioneller Testansätze könnte die Herausforderung als unmöglich erscheinen lassen, und tatsächlich können wir nicht erwarten, dass wir eine nachhaltige kontinuierliche Bereitstellung erreichen, ohne die Art und Weise, wie wir Software erstellen und testen, komplett zu ändern.
Die Einführung von Kanban und der Kanban-Methode war grundlegend für die Richtung, die wir einschlugen. Durch die Anwendung der Methode konnten wir unsere Engpässe identifizieren, Wartezeiten sichtbar machen und die Vorteile von kleinen Chargen und kontinuierlichem Fluss maximieren.
Wir erkannten bald, dass wir die Nacharbeit reduzieren mussten, wenn wir eine Chance haben wollten, kontinuierlich zu veröffentlichen. In der alten Welt nahmen sich Tester und Geschäftsanwender zwei Wochen der Iteration für ihre Qualitätskontrollaktivitäten. Ein großer Teil der Zeit wurde nicht mit Testen verbracht, sondern mit der Identifizierung und Protokollierung einer großen Anzahl von Fehlern und dem Umgang mit instabilen Umgebungen.
Wir haben dieses Problem an drei Fronten angepackt: Infrastruktur, Entwicklungspraktiken und Kultur.
Infrastruktur: Reduzieren Sie menschliche Fehler
Um die Nacharbeit in unserer Infrastruktur zu reduzieren, haben wir eine brandneue Lieferpipeline entwickelt, die sowohl Code als auch Kontext enthält. Wir haben auch On-Demand-Testumgebungen geschaffen, um den Zeitaufwand für die manuelle Einrichtung und die Nachbearbeitung falscher Konfigurationen zu reduzieren.
Dies bedeutete eine drastische Reduzierung der manuellen Schritte bei der Erstellung und Bereitstellung. Obwohl dies zunächst nur in unseren Testumgebungen implementiert wurde, brachte es uns unmittelbare Vorteile. Die Möglichkeit, auf zuverlässigen Umgebungen zu testen, die mit einem wiederholbaren Prozess erstellt wurden, hat unsere Testzeit erheblich reduziert.
Entwicklungspraktiken: Bessere Kommunikation, kleinere User Stories
Verhaltensgesteuerte Entwicklung (BDD)
Wir haben die verhaltensgesteuerte Entwicklung (Behavior Driven Development, BDD) eingeführt, um die Missverständnisse zwischen den Geschäftsinteressenten und dem Entwicklungsteam zu verringern und so die durch Missverständnisse verursachte Nacharbeit zu reduzieren.
BDD lieferte schon sehr früh hervorragende Ergebnisse. Wir erkannten bald, wie viel wir der individuellen Interpretation überlassen hatten - und in welchem Ausmaß dies die Ursache für die meisten der Mängel war, die wir bei der Qualitätskontrolle feststellten. Dank BDD sind die Fehlerraten drastisch gesunken. Je mehr wir die Zusammenarbeit in den Teams verbesserten, desto mehr wuchs das geschäftliche Wissen der Teammitglieder. Dies erleichterte die Entscheidungsfindung; Entscheidungen, die zuvor lange, frustrierende Sitzungen erforderten, wurden nun zu schnellen Gesprächen.
Kleinere Anwenderberichte
Ein weiterer Ansatz, der sich als äußerst vorteilhaft für die Reduzierung von Nacharbeiten erwiesen hat, war die vertikale Aufteilung unserer User Stories und damit die Reduzierung ihrer Komplexität. Das bedeutete oft, dass die Logik im neuen Code einen einzigen Codepfad enthielt. Geringere Komplexität bedeutete weniger Fehler und weniger Nacharbeit.
Ausgewogene Strategie zur Testautomatisierung
Gleichzeitig legten wir eine Strategie fest, die einen hohen Einsatz von Automatisierungstests auf Unit-Ebene, eine konsistente Schicht von automatisierten Tests auf API-Ebene und eine sehr dünne Schicht von UI-gesteuerten Tests im Einklang mit der automatisierten Testpyramide von Mike Cohn vorsah. Dies ermöglichte es unserer Regressionssuite, schnell und stabil zu bleiben - etwas, das absolut grundlegend ist, wenn Sie in der Lage sein wollen, jedes Mal, wenn Ihr Entwicklungsteam einen neuen Code veröffentlicht, einen Mehrwert für den Kunden zu liefern.
Die Verwendung von BDD und die Implementierung der Testautomatisierung bedeutete nicht, dass wir keine explorativen Tests mehr durchführten, sondern dass diese Tätigkeit aufgrund der Reduzierung der Fehler und der geringeren Größe der Stories immer weniger Zeit in Anspruch nahm.
Qualität schaffen in
Ich habe einige Monate lang an einem Produkt gearbeitet, bei dem es um die Umwandlung eines Datenstroms in eine andere Datenstruktur ging, die von einem Kunden genutzt werden sollte. Ich erinnere mich, dass ich nie länger als 10 Minuten etwas explorativ getestet habe, und ich hatte nie das Gefühl, dass ich etwas hinter mir ließ. Das war befreiend für mich, denn ich hatte das Gefühl, dass ich in einem schnellen Tempo Qualitätsarbeit leisten konnte, ohne etwas zu opfern.
Auch bei unseren Kunden gab es keine Probleme. Wir inspizierten die Anwendung eine Größenordnung weniger als zuvor, aber die Qualität unserer Ergebnisse war höher. Wir haben Qualität eingebaut.
Kultur: Ermutigung zur Zusammenarbeit
Diese Art der Umwandlung ist vom technischen Standpunkt aus nicht allzu schwierig. Aus kultureller Sicht ist es viel komplizierter. Als ich zu dem Unternehmen kam, auf das ich mich beziehe, traf ich auf äußerst fähige Entwickler, die nicht an das Testen gewöhnt waren. Sie waren von den Testern verwöhnt worden, die ihrem chaotischen Code hinterherliefen, und entwickelten nie ein Interesse an dieser Disziplin.
Kultur ist schwer zu ändern. Unsere Strategie bestand darin, gesunde Verhaltensweisen zu fördern, anstatt schlechte zu bestrafen. Wir haben zum Beispiel Entwickler ermutigt und gelobt, die bereit waren, zu testen, und wir haben auch Leute gelobt, die zu zweit gearbeitet haben. Wir haben jede Art der Zusammenarbeit gefördert und anerkannt. Wir wussten, dass das Team eine Einheit von Menschen werden musste, die sich gegenseitig vertrauten, und nicht nur eine Gruppe von Menschen mit allen Fähigkeiten, die für die Bereitstellung einer komplexen Lösung erforderlich waren.
Wissen teilen und einen Teststamm gründen
Wir mussten einen Arbeitszusammenhalt erreichen, der die Fähigkeit zur Zusammenarbeit mit sich brachte und Engpässe beseitigte, während die Arbeit im Fluss blieb. Ein Schlüssel zum Erfolg war der Fokus, den wir auf den Aufbau von t-förmigen Fähigkeiten legten, indem wir voneinander lernten und jederzeit Hilfe anboten.
Eine erfolgreiche Initiative war die Gründung des Teststamms. Der Tribe war eine freiwillige und völlig autonome Gruppe von Menschen, denen die Qualität von Software am Herzen lag. Nach einer Weile wurde diese Gruppe, die sich jede Woche zu Gesprächen im Stil von Lean Coffee traf, immer größer, wobei die meisten Mitglieder Entwickler waren. Ich habe nicht genug Platz, um eine Reihe von Experimenten und Verbesserungen zu erwähnen, die auf dieser Ebene begonnen haben.
Ein bemerkenswerter Erfolg war die Entwicklung eines Tools, das die Testbarkeit unserer Hauptanwendung erheblich verbesserte und die Zeit für die Erforschung von Stunden auf Minuten reduzierte. Der Stamm trug auch dazu bei, unseren Prozess zu ändern, unnötige Schritte zu entfernen und in einem konkreten Fall eine Änderung zu identifizieren, die die Vorlaufzeit mit wenig Aufwand um 30% reduzierte.
Der Stamm florierte und seine Erfolge sickerten schnell zu den verschiedenen Teams durch, in denen es Stammesmitglieder gab. Die Teams fingen an, mehr und mehr zu experimentieren und ihre Systeme zu verbessern, indem sie über reine Qualitätsverbesserungen hinausgingen - das war großartig zu beobachten.
Build Quality In: Abschließende Überlegungen
Jedes Unternehmen kann Continuous Delivery praktizieren - und das sollte es auch, wenn es sich auf dem modernen Markt behaupten will. Continuous Delivery hilft Unternehmen nicht nur, schneller als ihre Konkurrenten zu liefern, sondern auch mit höherer Qualität.
Ich habe gesehen, wie das in meinem eigenen Entwicklungsteam funktioniert hat, und zwar durch eine Reihe schrittweiser Änderungen, die zu einer grundlegenden Veränderung unserer Arbeitsweise geführt haben - und uns dabei geholfen haben, von einer Version pro Monat zu mehreren Versionen pro Tag überzugehen:
Infrastruktur: Wir haben unsere Infrastruktur geändert, um die Anzahl der manuellen Schritte bei der Erstellung und Bereitstellung zu reduzieren. Dies ermöglichte uns zuverlässigere Testumgebungen mit deutlich kürzeren Testzeiten, so dass wir schneller und mit weniger Fehlern liefern konnten.
Entwicklungspraktiken: Wir haben unsere Entwicklungspraktiken geändert, um die Kommunikation innerhalb der Organisation zu verbessern. Dadurch konnten wir Nacharbeiten aufgrund von Missverständnissen reduzieren. Außerdem haben wir die User Stories verkleinert und vereinfacht, was die Komplexität reduzierte und es dadurch einfacher machte, häufig zu liefern. Wir haben eine ausgewogene Strategie zur Testautomatisierung eingeführt, die es unserer Regressionssuite ermöglicht, schnell und stabil zu bleiben.
Kultur: Schließlich änderten wir unsere Kultur auf dieselbe Weise, wie wir alles andere änderten - schnell, aber schrittweise, so dass die Veränderungen nachhaltig waren. Wir haben gesunde Verhaltensweisen gefördert, die das Testen und die Zusammenarbeit zwischen den Teams unterstützen. Wir gründeten einen Test Tribe, eine Gruppe von Test-Enthusiasten, deren Einfluss sich im gesamten Unternehmen ausbreitete und dazu beitrug, unsere neue Kultur zu festigen: eine Kultur, die auf Zusammenarbeit, Kommunikation und Qualität ausgerichtet ist.
Das Ergebnis all dieser Bemühungen ist ein System, das auf schnelle Lieferung ausgelegt ist und bei dem jeder Schritt des Prozesses mit Qualität verbunden ist.
![Ein globaler Plan für kollaboratives Arbeitsmanagement [Video]](https://blog.planview.com/wp-content/uploads/2019/07/A-Global-Collaborative-Work-management-blueprint.png)
