4 Minuten lesen
Wissen ist wertvoll, aber seine wahre Kraft liegt darin, wie wir es in die Tat umsetzen. Bei Freyr waren wir mit DevOps, den damit verbundenen Praktiken und der Frage vertraut, wie es unser Unternehmen in ein leistungsstarkes Produktentwicklungszentrum verwandeln könnte, das in der Lage ist, unseren Kunden aus dem Bereich Life Sciences hochwertige Produkte und Lösungen zu liefern. Zu Beginn unserer Reise legten wir mit unseren Bemühungen ein solides Fundament, aber um wirklich zu einem Entwicklungszentrum zu werden, wussten wir, dass wir einen strategischeren und anpassungsfähigeren Ansatz verfolgen mussten.
Die größte Herausforderung bei der Umsetzung von Wissen in Maßnahmen besteht darin, zu wissen, wann man die richtigen Schritte unternehmen muss. Da sich Maßnahmen auf viele Menschen in einem Unternehmen auswirken, hängt es davon ab, wo wir als Unternehmen stehen, wie unsere aktuellen Prozesse und Praktiken aussehen und welche Fähigkeiten und Fertigkeiten unsere Mitarbeiter haben, das Richtige zum richtigen Zeitpunkt zu tun.
Dies markierte einen Wendepunkt in unserem Wandel. Als Softwarehersteller, der sich auf kundenspezifische Lösungen spezialisiert hat, verfügten wir über ein engagiertes Team, das sich für die Erzielung von Ergebnissen besonders ins Zeug legte. Wir sahen jedoch eine Möglichkeit, die Qualität zu verbessern, die Produktivität zu steigern und die Umsetzung von Geschäftsanforderungen in Ergebnisse zu beschleunigen. Anstatt uns auf Last-Minute-Korrekturen zu konzentrieren, wollten wir von der reaktiven Problemlösung zur proaktiven Innovation übergehen und skalierbare, hochwirksame Lösungen entwickeln.
Wir hatten eine Vision davon, wo wir hinwollten - wie wir arbeiten, Software entwickeln, testen, bereitstellen und veröffentlichen wollten. Wir wussten jedoch, dass das Erreichen dieser Ziele eine durchdachte Strategie, kontinuierliches Lernen und eine Verpflichtung zur Verbesserung erfordert.
Spulen wir bis heute vor: Im letzten Jahr haben wir mehr als 100 Releases mit nahezu null Implementierungsfehlern durchgeführt und eine fast vollständige Automatisierung beim Rollout von Änderungen erreicht. Darüber hinaus haben wir erhebliche Fortschritte bei den Einnahmen, schlankere und agilere Teams und eine allgemeine Verlagerung hin zu unserer Vision, ein führendes Unternehmen für Softwareprodukte, -lösungen und -dienstleistungen zu werden, festgestellt. Auch wenn es immer noch mehr zu erreichen gibt, sind wir zuversichtlich, dass wir ein starkes Fundament gelegt haben und bereit sind, das Tempo zu erhöhen.
Während wir vorankommen, nehmen wir uns einen Moment Zeit, um über unsere Transformation nachzudenken - was funktioniert hat, was nicht, und was wir gelernt haben. Wir hoffen, dass wir andere, die vor ähnlichen Veränderungen stehen, mit unserer Reise unterstützen können.
Diese Blogserie ist vor allem empirisch und zeigt, was wir getan haben, während wir unsere Maßnahmen mit bewährten Verfahren und Empfehlungen aus verschiedenen DevOps- und Agile-Ressourcen in Verbindung bringen.
Die richtigen Dinge zur richtigen Zeit tun
Einer der wichtigsten Aspekte unserer Umstrukturierung bestand darin, die richtigen Maßnahmen zum richtigen Zeitpunkt zu ermitteln. Bei mehreren möglichen Initiativen brauchten wir einen strukturierten Ansatz, um sinnvolle Fortschritte zu erzielen.
Rückblickend können wir diese Maßnahmen in drei Kategorien einteilen: Werkzeuge und Prozesse, Softwarearchitektur und Menschen. Diese Kategorien sind eng miteinander verwoben, wobei sich Änderungen in einer Kategorie auf die anderen auswirken. Es war jedoch möglich, schrittweise Änderungen in jeder Kategorie vorzunehmen und den Fortschritt in Richtung unserer Gesamtziele zu messen.
Die Initiativen in diesen Kategorien hingen oft voneinander ab. Veränderungen in einem Bereich eröffneten Möglichkeiten für weitere Verbesserungen in einem anderen.
Die ersten Schritte
Um eine solide Grundlage zu schaffen, haben wir uns auf drei Kerninitiativen konzentriert:
- Integration unserer Quellcode-Datenbanken mit SonarQube für Code-Qualitätsmetriken.
- Umstellung aller Teams auf ein gemeinsames Tool zur Verwaltung von Anforderungen, Quellcode und Testplänen - in unserem Fall Azure DevOps.
- Strukturierung von Teams mit klaren Zuständigkeiten zur Stärkung von Eigenverantwortung und Rechenschaftspflicht.
Diese drei Initiativen verschafften us in:
- Die zu erledigende Arbeit (Anforderungen und Aufgaben).
- Die Codequalität (SonarQube-Metriken).
- Die beteiligten Personen (Verantwortlichkeiten im Team).
Die größte Herausforderung war die Festlegung klarer Teamzuständigkeiten. Anfänglich waren die Teamstrukturen fließend und die Mitarbeiter wechselten je nach Bedarf zwischen den Projekten. Der Übergang zu fest zugeordneten Teams mit unterschiedlichen Funktionsbereichen war ein notwendiger Schritt, der jedoch durch unsere bestehende Produktarchitektur erschwert wurde, die nicht vollständig darauf ausgelegt war, klare Verantwortlichkeiten zu unterstützen.
Die Rolle der Software-Architektur
Wir erkannten schnell, dass die Produktarchitektur einer der wichtigsten Bereiche für Veränderungen war. Eine modulare Architektur war unerlässlich, damit unabhängige Teams die Verantwortung für ihre Arbeit übernehmen konnten. Ohne sie waren unsere Bemühungen, die Eigenverantwortung der Teams zu stärken, in ihrer Wirkung begrenzt.
Die Umstrukturierung unseres Portfolios war ein komplexer Prozess. Dazu gehörte die vollständige Verlagerung in die Cloud und der Beginn der Entwicklung von Cloud-nativen Anwendungen unter Verwendung einer Microservices-Architektur. Dieses Thema wird in einem späteren Beitrag behandelt. Die wichtigste Erkenntnis ist jedoch, dass Veränderungen schrittweise erfolgen und dass einige Schritte anderen vorausgehen müssen, um Vorteile und weitere Fortschritte zu erzielen.
Metriken und kontinuierliche Verbesserung
Nachdem wir mit der Umstrukturierung begonnen hatten (ein fortlaufendes Unterfangen), konzentrierten wir uns auf die Überwachung von Kennzahlen und die Festlegung von Zielen:
- Metriken zur Codequalität in SonarQube.
- Metriken zur Code-Integration in Azure DevOps.
- Durchsatzmetriken für einzelne Teams.
- Einführung von Cloud-nativen Diensten.
Diese Ziele waren keine harten Vorgaben, sondern Leitziele, die den Teams helfen sollten, ihre Bemühungen aufeinander abzustimmen.
Menschen befähigen
Nach der Einführung von Metriken wurde deutlich, dass die Teams Unterstützung benötigten, um diese Ziele zu erreichen. So war es zwar einfach, Ziele für die Abdeckung von Unit-Tests und die Automatisierung von API-Tests festzulegen, aber das Erreichen dieser Ziele stellte eine Herausforderung dar, vor allem bei Legacy-Code, der nicht für die Testbarkeit entwickelt worden war.
Um dieses Problem anzugehen, haben wir:
- Setzen Sie niedrigere Ziele für Legacy-Code.
- Organisierte Workshops und praktische Schulungen zum Schreiben hochwertiger Unit-Tests und zum Entwurf von testbarem Code.
- Anleitung zur Erstellung von Stubs für API-Tests.
- Durchführung von Prüfungen der Einheitstests durch leitende Architekten.
Das Dreieck aus Werkzeugen, Architektur und Menschen
Ein gutes Beispiel für die Wechselwirkung zwischen diesen Kategorien war die Code- und Repository-Verwaltung. Die Integration von SonarQube, das eine Verbesserung der Werkzeuge darstellt, ergab eine geringe Abdeckung der Unit-Tests, was auf architektonische Probleme hinwies, die die Testbarkeit einschränkten. Verbesserungen der Architektur und der Teamfähigkeiten führten zu qualitativ besseren Unit-Tests, die jedoch aufgrund schlechter Verzweigungspraktiken nicht regelmäßig ausgeführt wurden. Wir haben dieses Problem gelöst, indem wir die Verzweigungsstrategien standardisiert und eine regelmäßige Integration des Codes in den Hauptzweig sichergestellt haben, damit die CI-Pipelines alle Tests ausführen können.
Die richtige Abfolge der Veränderungen
Ein Ansatz zur Umgestaltung ist die wahllose Umsetzung bewährter Verfahren. Dies kann zwar Vorteile bringen, aber die Ergebnisse rechtfertigen oft nicht den Aufwand, was zu Frustration führt.
Wir verfolgten einen anderen Ansatz, der auf dem Prinzip des Flusses basierte: Analyse des gesamten Prozesses, Ermittlung von Engpässen und deren schrittweise Beseitigung.
Jede Verbesserung brachte neue Engpässe zutage, die weitere Maßnahmen erforderten. Es handelte sich dabei nicht um ein "Wischiwaschi"-Spiel, sondern um einen bewussten Prozess, bei dem das Richtige zur richtigen Zeit getan wurde .
Die Vorgabe einer Testabdeckung ohne Verbesserung des Code-Designs hätte beispielsweise zu Frustration und "Abdeckungs-Theater" geführt (oberflächliche Tests, die geschrieben werden, um die Messwerte zu erfüllen). Indem wir uns zuerst mit der Architektur und den Fähigkeiten befassten, konnten wir sinnvolle Fortschritte erzielen.
Blick in die Zukunft
Bei echter Transformation geht es nicht um eine einzige große Veränderung, sondern um kluge, gut getimte Entscheidungen, die zu kontinuierlichem Fortschritt führen. Wir freuen uns darauf, unseren Weg und unsere Erkenntnisse mit anderen zu teilen, um ihnen zu helfen, ihren eigenen Weg zu skalierbaren, wirkungsvollen Veränderungen zu finden.
In den kommenden Blogs dieser Reihe – DevOps for the Win – werden wir jede Phase unserer Transformation im DevOps-Dreieck – Tools, Architektur und Menschen – aufschlüsseln, die us dabei geholfen hat, eine nachhaltige Wirkung us .
