Close

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.

1. 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.

2. 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.

3. 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.

4. 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?


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.

Wenn du gerade erst deinen Weg zu DevOps beginnst, kannst du die besten Praktiken mit unserem Leitfaden für DevOps erlernen. Um DevOps umzusetzen, empfehlen wir Open DevOps zu verwenden, denn es bietet alles, was Teams benötigen, um Software zu entwickeln und betreiben. Dank Integrationen mit führenden Anbietern und Marketplace-Apps erhalten Teams genau die DevOps-Toolchain, die sie benötigen. Jetzt testen.

Ian Buchanan
Ian Buchanan

Ian Buchanan ist Principal Solutions Engineer für DevOps bei Atlassian, wo er sich auf die aufstrebende DevOps-Community und den Einsatz von Jira, Bitbucket und Bamboo für eine bessere Continuous Integration und Continuous Delivery konzentriert. Ian verfügt über umfassende Erfahrung mit Java und .NET. Sein Spezialgebiet sind jedoch schlanke und agile Praktiken in großen Unternehmen.

Während seiner beruflichen Laufbahn hat Ian bereits erfolgreich verschiedene Tools zur Entwicklung von Unternehmenssoftware in allen Lebenszyklusphasen betreut. Durch unternehmensweite Prozessoptimierungen konnte er die Produktivität, die Qualität und die Kundenzufriedenheit steigern. Er hat multinationale, agile Teams zusammengestellt, die sich weitgehend selbst leiten und organisieren. Wenn er gerade keine Vorträge hält oder programmiert, befasst sich Ian mit Parsern, Metaprogrammierung und domänenspezifischen Sprachen.


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.

Abbildung: DevOps

DevOps-Community

Abbildung: DevOps

DevOps-Lernpfad

Abbildung: Karte

Kostenlos loslegen

Melde dich für unseren DevOps-Newsletter an

Thank you for signing up