Artikel
Tutorials
Interaktive Leitfäden
Teamtopologien
So beeinflussen vier fundamentale Topologien eine DevOps-Transformation
Ian Buchanan
Principal Solutions Engineer
Redaktioneller Beitrag: Shana Vu
Erfahre mehr über die Vorteile von am Wertstrom ausgerichteten Teams und wie sie mit Plattform- und Teilsystemteams zusammenarbeiten, und wie du es Teams ermöglichst, Kunden Mehrwert zu bieten.
Einführung in Teamtopologien
Engineering-Teams müssen schneller denn je handeln, um ihren Kunden einen Mehrwert zu bieten. Die Zunahme von Cloud-, SaaS- und stets verfügbaren Services bedeutet, dass Kunden neue Funktionen, weniger Fehler und eine Betriebszeit von 99,99 % (oder mehr) erwarten.
Um mit diesen Anforderungen Schritt zu halten, haben Unternehmen agile Praktiken und in jüngerer Zeit auch DevOps-Praktiken eingeführt. Diese sollen eine schnellere Markteinführung/Vorlaufzeit, eine verbesserte Deployment-Häufigkeit, eine bessere Teamkultur und eine verbesserte Zusammenarbeit zwischen Teams/Abteilungen ermöglichen.
Die Einführung von DevOps-Praktiken ist leichter gesagt als getan, deshalb bietet das Buch Team Topologies aufschlussreiche Möglichkeiten, wie Unternehmen DevOps-Konzepte übernehmen und ermitteln können, welche Art von Teams am effektivsten sind. Dieses Buch zeigt im Ansatz, wie Atlassian über Teams denkt. Anstatt die Ergebnisse des Buchs zu wiederholen, möchten wir unsere eigene Sichtweise auf die Teamtypen darstellen.
Der erste Schritt bei einer DevOps-Transformation besteht darin, die bestehende Organisationsstruktur zu identifizieren. In jedem Unternehmen gibt es heute jedoch viele verschiedene Teamtypen und in einigen Fällen übernehmen einzelne Teams mehrere Rollen und Aufgaben. Diese Vielseitigkeit macht es für Führungskräfte schwierig, die gesamte Organisationslandschaft zu visualisieren und Fragen wie die folgenden zu beantworten:
Lösung anzeigen
DevOps-Tools für das gesamte Team
Zugehöriges Material
Aufbau einer DevOps-Kultur
- Haben wir die richtigen Teams?
- Fehlen uns in einigen Bereichen Fähigkeiten, die keines unserer Teams vorweisen kann?
- Erhalten Teams gleich viel Autonomie und Unterstützung durch andere Teams?
Leiter von Entwicklungs- und Operations-Teams können besser verstehen, ob die richtigen Teams vorhanden sind, wenn sie in ihrem Unternehmen gezielt auf Teamtopologien achten. Wir empfehlen, die Anzahl der Teamvarianten auf vier grundlegende Teamtopologien zu reduzieren, die sowohl für die obere Führungsebene als auch für die tatsächlichen Teammitglieder einfacher nachvollziehbar sind:
- Auf Wertströme ausgerichtetes Team
- Plattformteam
- Team für komplizierte Teilsysteme
- Unterstützungsteam
Denke daran, dass diese Teamtypen je nach Größe und Reifegrad des Unternehmens unterschiedlich geartet sein können. Tatsächlich ist eine Kombination aus mehr als einem Teamtyp oder ein Team, das sich zu einem anderen Team entwickelt, oft der beste Ansatz.
Auf Wertströme ausgerichtetes Team
Auf Wertströme ausgerichtete Teams konzentrieren sich auf eine einzige, wirkungsvolle Aufgabe. Es kann sich um ein einzelnes Produkt oder einen Service, ein einzelnes Feature, eine einzelne User Journey oder einen einzelnen Benutzertyp handeln. Das Team ist angehalten, für Kunden oder Benutzer möglichst schnell, sicher und unabhängig Wert zu schöpfen und zu liefern, ohne dass Aufgaben teilweise zur Erledigung an andere Teams übergeben werden müssen.
Da auf Wertströme ausgerichtete Teams am gesamten Lieferspektrum mitwirken, sind sie notwendigerweise näher am Kunden und arbeiten in der Regel bereits mit agilen Methoden. Dieses Team bezieht Kundenfeedback in Entwicklungszyklen ein und pflegt gleichzeitig in der Produktion befindliche Software.
Während auf Wertströme ausgerichtete Teams in vielen Softwareunternehmen üblich sind, sind andere Unternehmen möglicherweise besser mit Teamstrukturen vertraut, die nach Funktionen (d. h. getrennte Teams für Engineering, Design, QA) und nicht nach der Position im Auslieferungsstrom organisiert sind.
Da das auf Wertströme ausgerichtete Team der gängigste Teamtyp in Unternehmen ist, wird die Rolle anderer Teams im Verhältnis zu diesen Teams definiert. Auf Wertströme ausgerichtete Teams sollten sich regelmäßig an die folgenden unterstützenden Teams (für komplizierte Teilsysteme, Unterstützung und Plattform) wenden, um die Liefergeschwindigkeit und Qualität ihrer Produkte und Services kontinuierlich zu verbessern.
Plattformteam
Plattformteams ermöglichen es auf Wertströme ausgerichteten Teams, Arbeitsergebnisse mit einem hohen Maß an Autonomie zu liefern. Während das auf Wertströme ausgerichtete Team die volle Verantwortung für das Erstellen, Ausführen und Reparieren einer Anwendung in der Produktion behält, bietet das Plattformteam interne Services, die das andere Team nutzen kann.
Plattformteams entwickeln Funktionen, die von zahlreichen auf Wertströme ausgerichteten Teams mit geringem Aufwand genutzt werden können. Durch die Optimierung eines Produkts minimieren Plattformteams Ressourcen und kognitive Belastungen des auf Wertströme ausgerichteten Teams. Dies kommt auch Endbenutzern zugute, da Plattformteams ein zusammenhängendes Erlebnis schaffen können, das verschiedene Benutzererlebnisse oder Produkte abdeckt.
Hier bei Atlassian bauen Plattformteams Services auf, die von allen unseren Produkten (wie Identitätsmanagement) genutzt werden, und es wird erwartet, dass sie auf Wertströme ausgerichteten Teams Dokumentation, Unterstützung und Beratung bieten.
Team für komplizierte Teilsysteme
Ein Team für komplizierte Teilsysteme ist für den Aufbau und die Wartung eines Teils des Systems verantwortlich, für den bestimmte Fähigkeiten und Kenntnisse erforderlich sind. Die meisten Teammitglieder müssen Spezialisten in einem bestimmten Wissensgebiet sein, um das Teilsystem zu verstehen und Änderungen daran vorzunehmen.
Das Ziel dieses Teams ist es, die Belastung von auf Wertströme ausgerichteten Teams zu reduzieren, die an Systemen arbeiten, die das Teilsystem enthalten oder verwenden. Aufgrund des Fachwissens und der Fähigkeiten des Teams in Bezug auf komplizierte Teilsysteme müssen auf Wertströme ausgerichtete Teams keine Fähigkeiten in Bereichen aufbauen, die für ihre tägliche Arbeit zu kompliziert sind. Teammitglieder dieses Teams verfügen möglicherweise über Spezialwissen über bestimmte Microservices (d. h. einen Abrechnungsservice), Algorithmen oder sogar künstliche Intelligenz.
Ein typischer Fehler ist der Versuch, Spezialisten in jedes auf Wertströme ausgerichtete Team zu integrieren, das das Teilsystem verwendet. Dies mag zwar effizient erscheinen, ist aber letztendlich nicht kostengünstig und nicht im Leistungsumfang für ein auf Wertströme ausgerichtetes Team enthalten.
Unterstützungsteam
Auf Wertströme ausgerichtete Teams stehen unter dem ständigen Druck, Veränderungen schnell umzusetzen und darauf zu reagieren. Das macht es schwierig, Zeit für weitere Recherchen, Weiterbildung und das Einüben von neuen Fertigkeiten zu erübrigen.
Ein Unterstützungsteam, das sich aus Spezialisten in einer bestimmten technischen (oder produktspezifischen) Domäne zusammensetzt, hilft dabei, diese Kompetenzlücke zu schließen. Diese Teams konzentrieren sich auf Forschung und Experimente, um fundierte Vorschläge zu Tools, Frameworks und Ökosystemen zu machen, die sich auf den Tool-Stack auswirken.
Dies gibt auf Wertströme ausgerichteten Teams Zeit, Fähigkeiten zu erwerben und weiterzuentwickeln, während sie sich weiterhin auf ihre Hauptziele konzentrieren. Das Unterstützungsteam versucht in erster Linie, die Autonomie von auf Wertströme ausgerichteten Teams zu erhöhen. Diese sollen sich dabei verstärkt mit Problemen und nicht mit der Lösung befassen.
Wenn ein Unterstützungsteam seine Arbeit gut macht, sollte das unterstützte Team nach ein paar Wochen keine Hilfe mehr benötigen. Das Unterstützungsteam sollte vermeiden, dass andere Teams dauerhaft auf es angewiesen sind.
Ist dein Team auf Wertströme ausgerichtet?
Du solltest dir die folgenden Fragen stellen, um herauszufinden, ob dein Team auf Wertströme ausgerichtet ist:
Hat dein Team vor, Features kontinuierlich zu erstellen?
Erfahrenere Teams geben Releases mehrmals pro Woche und in einigen Fällen mehrmals am Tag heraus. Um dieses Ziel zu erreichen, sollten sie Continuous Integration (CI) und Continuous Delivery (CI/CD) nutzen, um regelmäßig Features freizugeben.
Ändert dein Team nach Feedback (von Kunden oder internen Ressourcen) zu den neuesten Änderungen schnell die Richtung?
Es ist häufig das Beste, einen experimentellen Ansatz für die Produktentwicklung zu verwenden. Ausgereifte DevOps-Prozesse beinhalten automatisierte Tests, um qualitativ hochwertige Codeauslieferungen sicherzustellen. Das Experimentieren geht jedoch über einfache Einheiten- oder Akzeptanztests hinaus. Du kannst sicherstellen, dass deine Produkte den größten Mehrwert für Kunden bieten, indem du Feature-Flags verwendest. Damit werden Rollouts für einen Teil der Benutzer, Alpha- und Beta-Versionen automatisiert, um Benutzerfeedback einzuholen und deren Verhalten zu messen. Qualitatives kontinuierliches Feedback erhältst du zudem über Kommentare, Supporttickets und Community-Foren.
Übergibt dein Team nur wenige Aufgaben an andere Teams?
Diese Aussage sollte in zweierlei Hinsicht zutreffen. Dein Team sollte in sich geschlossen sein und seine Teammitglieder ausschließlich miteinander arbeiten, um eine schnelle Bereitstellung zu gewährleisten. Abgesehen vom Arbeitsumfang können die wenigen Übergaben auch in Form von automatisierten Prozessen erfolgen. Durch die Automatisierung deines Entwicklungszyklus wird sichergestellt, dass die Erledigung von Arbeiten ein nahtloser Prozess ist. Dabei spielt es keine Rolle, ob es sich beim nächsten Schritt um eine Aktion wie automatisierte Tests, einen Merge in den Haupt-Branch oder eine echte Person handelt.
Hier gibt es Bonuspunkte ...
Hat dein Team Zeit, sich mit Änderungen der Codequalität (auch bekannt als "technische Schulden") zu befassen, um sicherzustellen, dass Änderungen sicher und einfach sind?
Erfahrenere Teams verlassen sich auf Trunk-basierte Entwicklung und CI/CD-Praktiken, um ihre Codebasis aufrechtzuerhalten. Die Kapazitätsplanung sollte eine feste Zeit beinhalten, in der technische Schulden behandelt werden. Außerdem sollte Großprojekten, die sich mit den zugrunde liegenden Infrastruktur- oder Plattformproblemen befassen, ebenso viel Aufmerksamkeit geschenkt werden wie der Feature-Entwicklung.
Wird dein Team anhand der richtigen Metriken bewertet?
Hierbei geht es nicht nur darum, wie schnell dein Team Releases herausbringt, es sollte auch Metriken wie die Teamgesundheit und technische Qualität bei der Messung des Erfolgs berücksichtigen.
Was die letzte Frage zur Messung angeht, haben DevOps-Teams bisher die vier wichtigsten DevOps Research and Assessment (DORA)-Metriken für ihre Definition von Erfolg berücksichtigt:
- Deployment-Häufigkeit: Wie oft gibt es im Unternehmen erfolgreiche Produktionsfreigaben?
- Vorlaufzeit für Änderungen: Der Zeitraum, bis ein Commit zur Produktion gelangt
- Änderungsfehlerrate: Der Prozentsatz der Deployments, die einen Produktionsausfall verursachen
- Zeit für die Wiederherstellung des Service: Zeitdauer, bis sich ein Unternehmen von einem Produktionsausfall erholt
Neben diesen von DORA festgelegten Metriken hat Atlassian festgestellt, dass leistungsstarke, auf Wertströme ausgerichtete Teams auch diese Attribute im Blick behalten:
- Ausgewogenes Team: Dein Team bietet vielfältige Fähigkeiten und Perspektiven.
- Verantwortliche: Verantwortliche stellen sicher, dass das Kernteam und funktionsübergreifende Mitglieder wissen, an wen sie sich bei Fragen wenden müssen, und wie sie Entscheidungen in Bezug auf Projekte treffen, die dem Team gehören.
- Gemeinsames Verständnis: Alle Beteiligten sind sich der Anforderungen, Werte und Metriken bewusst und erkennen diese an.
- Fokussierung auf Werte und Metriken: Dein Team hat übergeordnete Ziele, die bestimmen, welche Aufgaben bis zum Release von Projekten zu erledigen sind.
- Proof of Concept: Mit einem echten Artefakt, mit dem Annahmen aufgestellt und getestet werden können, können Teams ständig iterieren und sich weiter verbessern.
- Verwaltete Abhängigkeiten zur Aufrechterhaltung der Geschwindigkeit: Das Verständnis für verwaltete Abhängigkeiten hilft, Blockierungen zu vermeiden, damit das Team mit gleichbleibender Geschwindigkeit weiterarbeiten kann.
Fazit
DevOps ist kein Ziel, sondern eine laufende Entwicklung zur konstanten Verbesserung von Tools, Teamkulturen und Praktiken. Wenn du mit DevOps keine Erfahrung hast, solltest du zunächst deine Ziele darauf ausrichten, deinen Kunden einen Mehrwert zu bieten. Wenn du mehr Erfahrung gesammelt hast, kannst du für deine Tools und Prozesse auch Automatisierung nutzen. Und wenn sich dein Team auf diesem Gebiet gut weiterentwickelt hat, solltest du Observability einbeziehen, um sicherzustellen, dass du die richtigen Dinge überwachst, misst und verbesserst.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
DevOps-Community
DevOps-Lernpfad
