Verwendung von Team-Topologien zur Entdeckung und Verbesserung der Zuverlässigkeitsqualitäten

Team Topologies ist das Werk von Matthew Skelton und Manuel Pais, und ich verwende es im Rahmen meiner Arbeit. Aus soziotechnischer Sicht ist ein teamorientierter Ansatz für jede Organisation von größter Bedeutung und hilft, die zufällige Komplexität zu verringern. Daher werde ich oft gefragt: "Wie können wir mit DevOps arbeiten?" oder "Wie kann ich einen zuverlässigen Service für meine Kunden bereitstellen?".

TL;DR

Die Kombination von Team Topologies aus der DevOps-Bewegung mit Context Mapping aus der Domain-Driven Design-Community kann Einblicke in die potenziellen Reibungskontaktpunkte zwischen Softwareentwicklungsteams geben. Nachfolgend erfahren Sie, wie sich die beiden Ansätze kombinieren lassen und wie Sie Ideen generieren können, um Ihre Organisationen auf ein neues Leistungsniveau zu bringen und ein sicheres und gesundes Arbeitsumfeld zu schaffen.

Qualitäten der Servicezuverlässigkeit

Es gibt verschiedene Zuverlässigkeitsqualitäten, und es gibt Literatur darüber. Denken Sie an die SRE-Bücher von Google oder Building Evolutionary Architectures von Neal Ford, Rebecca Parsons und Patrick Kua. Sie beschreiben verschiedene Qualitäten für digitale Dienste und verschiedene Ansätze dafür. Aber bevor Sie diese Konzepte in die Tat umsetzen, sollten Sie sich fragen: Wie wirkt sich das auf die Teams aus?

Soziotechnisches Denken in Aktion

Um diese Frage zu beantworten, verwende ich Context Mapping und Team Topologies in einem Workshop-Modus (in letzter Zeit in einem Remote-Modus; ich werde in einem späteren Beitrag über meine Erfahrungen berichten), um (1) die Domänen, die begrenzten Kontexte und ihre Interaktionen und (2) die Teams und ihre Interaktionen zu visualisieren. Auf diese Weise können die beteiligten Personen die Komplexität ihrer Landschaft erkennen und sehen, wie die Teams organisiert sind, um Lösungen für den Problemraum zu schaffen.

Mit diesen Erkenntnissen, sowohl aus sozialer als auch aus technischer Sicht, können die Menschen über ihre Designentscheidungen nachdenken. Mit Design-Entscheidungen meine ich die Organisation von Teams und Einzelpersonen (Organisationsdesign) und das technische Design (Lösungs-/Softwarearchitektur). Daher das soziotechnische Denken, bei dem das Konzept eines Teams kein nachträglicher Gedanke ist.

Gut, nette Einleitung. Wie sieht es mit meiner Servicezuverlässigkeit aus?

Ja, ich kenne den Titel dieses Beitrags :) Dazu komme ich gleich, aber zuerst möchte ich über ein anderes wichtiges Konzept schreiben. Komplexität, und zwar auf dem Gebiet der Software. Frederick P. Brooks Jr. schrieb bereits 1986 das Papier No Silver Bullet - Essence and Accident in Software Engineering, in dem er zwei Arten von Komplexität beschreibt: essentielle Komplexität und zufällige Komplexität. Komplexität ist einem verteilten System inhärent (denken Sie nur an den Stack, um einen Webserver mit einem Datenbankserver zu verbinden), und wir entwickeln komplexe Lösungen für komplexe Probleme. Häufiger als wir erwarten, wachsen die Lösungen organisch (in Anlehnung an Kent Becks Pointe: wir kennen keine andere Art von Wachstum), aber leider fast zufällig; die Komplexität der Lösung wächst über die Komplexität des Problems hinaus.

Zurück zu den Qualitäten der Servicezuverlässigkeit: Ich erlebe, dass die Leute mehr Verfügbarkeit (oder irgendeine andere Fähigkeit) für den Dienst X fordern. Und wieder fügen die Teams immer neue Komponenten hinzu, um dies zu erreichen, was den kognitiven Overhead erhöht. Da ich mir dessen bewusst bin (ich bin schuldig, weil ich mich in der Vergangenheit genauso verhalten habe), habe ich begonnen, das Problem aus einem anderen Blickwinkel zu betrachten: Was wäre, wenn die Antwort in der Art und Weise liegt, wie die Teams interagieren, anstatt noch mehr Technologie darauf zu werfen?

Mit den Erkenntnissen aus der Context Map und den Teamtopologien können wir Überlegungen zum organisatorischen Design anstellen, um die gewünschten Qualitäten der Servicezuverlässigkeit zu erreichen. Normalerweise habe ich ein paar Fragen, wie zum Beispiel:

• Fließt der Wertefluss durch mehrere Teams? Wenn ja, um welche Arten von Teams handelt es sich? Eine Mischung aus Plattform und Stream-Align?
• Gehören sie zur selben Abteilung oder zu verschiedenen Abteilungen?
• Haben sie die gleichen Manager?
• Sind die Teams an denselben Orten oder in verschiedenen Zeitzonen?
• Verwenden wir Modelle in unterschiedlichen Kontexten?
• Müssen wir unsere SLA/SLO/SLI überarbeiten?
• Sollten wir eine lebende Dokumentation einführen?
• Wie viele Übergaben haben wir?

Meiner Erfahrung nach ist ein Blick darauf, wie die Teams interagieren und wie wir unsere Lösungen gestalten, ein guter Anfang, um die Qualität der Servicezuverlässigkeit zu entdecken und zu verbessern, bevor wir die technischen Aspekte ändern. Wenn eine Organisation wächst, nimmt die Komplexität zu, und es ist wichtig, Designentscheidungen zu treffen, um diese Komplexität zu bewältigen. Das Wesentliche!

Lassen Sie uns ein Beispiel veranschaulichen

Nehmen wir einen fiktiven Fall an, in dem ein Unternehmen eine SaaS-Lösung zur Analyse von Leads anbietet (ich habe keine Ahnung, ob es so etwas gibt oder nicht, vielleicht ist es eine Geschäftsidee). Wenn wir das Team Gold analysieren, das für den Service zur Qualifizierung eines Leads verantwortlich ist, können wir die folgenden Team-Topologien haben:

Wie Sie sehen können, habe ich das Team Gold in die Mitte des Diagramms gesetzt. Auch die übrigen Teams haben Namen, die mit ihrem Zweck zusammenhängen, und ich überlasse es Ihrer Phantasie, die technologischen Details auszufüllen. In diesem fiktiven Fall wird Team Gold gebeten, die Durchlaufzeit von Funktionen bis zur Produktion zu verbessern, da sie ihre Alleinstellungsmerkmale an die Konkurrenz verlieren. Anhand der Team-Topologien können wir sehen, dass es unterschiedliche Interaktionsmodi mit verschiedenen Teams gibt, die sich auf die Zykluszeit der Features auswirken können.

Auch wenn wir hier noch Verbesserungspotenzial sehen, kann die Verwendung einer Context Map auch zeigen, wie flexibel die Beziehungen zwischen begrenzten Kontexten sind, und damit auch die Teams, denen diese gehören:

>

Für diese Übung nehmen wir an, dass das Team ERP den gebundenen Kontext Lead Information besitzt, das Team CRM die gebundenen Kontexte Customer Information und Customer Analytics und das Team Gold die gebundenen Kontexte Qualified Leads und Leads Analytics. Bei einer schnellen Analyse können wir feststellen, dass die Beziehungen zwischen Team Gold und Team ERP zwar X-as-a-Service sind, die Qualifizierten Leads aber in Wirklichkeit mit den Lead-Informationen übereinstimmen. Wenn das Team ERP beschließt, Änderungen an seinem begrenzten Kontext vorzunehmen, hat dies kaskadenartige Ausfälle für das Team Gold zur Folge. In der umgekehrten Richtung ist die Beziehung zwischen Lead Analytics und Lead Information eine Kunden-Lieferanten-Beziehung, bei der Team Gold Einfluss auf die Entscheidungen von Team ERP hat. Zu guter Letzt haben wir ein Team, das Dokumente verwaltet, mit dem jedoch keiner der gebundenen Kontexte in Verbindung steht. In diesem Beispiel können solche Unstimmigkeiten zu Reibereien zwischen Teams führen, da die funktionalen Anforderungen nicht mit den soziotechnischen Anforderungen übereinstimmen, z.B. Teamgrenzen und technologische Entscheidungen.

In diesem naiven Beispiel können wir das Potenzial erkennen, die Ausrichtung der Teams auf die funktionalen Bedürfnisse zu verbessern. Meiner Erfahrung nach war dies der erste Schritt zur Entdeckung und Verbesserung von Zuverlässigkeitsqualitäten. Wenn die Zuständigkeiten der Teams an den begrenzten Kontexten ausgerichtet sind und die Teams auf die vorteilhaftesten Interaktionsmodi hinarbeiten, verbessert dies die Zuverlässigkeit des Systems. Für Organisationen, die verschiedene Muster der Zusammenarbeit einführen, ist es ein guter Ausgangspunkt, die Grenzen auf Produktebene zu ermitteln. Welche Teams und Kontexte sind beteiligt und was könnte/sollte sich ändern, um die gewünschte Zuverlässigkeit zu erreichen. Die Gestaltung von Organisationen unter Berücksichtigung dieser Aspekte (d.h. der wesentlichen Komplexität) kann zu einer besseren Zusammenarbeit zwischen den Teams führen und gleichzeitig deren Autonomie wahren.

Heuristik

Eine kleine Liste von Heuristiken, die zur Gewinnung von Erkenntnissen verwendet werden können:

• Teaminteraktionen entsprechen den Kontextbeziehungen
• Investieren Sie erst in die Teamumgebung, dann in die Technologie
• Erhöhen Sie die Zuverlässigkeit durch Verbesserung der Interaktion im Team

Verwendung von Team-Topologien zur Entdeckung und Verbesserung von Zuverlässigkeitsqualitäten.md#a readers noteAreaders note

Ich arbeite hauptsächlich in komplexen Umgebungen, die stark reguliert sind, mit Hunderten von Teams. Ihr Kontext ist anders, nehmen Sie meine Erfahrung mit Vorsicht!

Hinweis: Dieser Beitrag wurde ursprünglich in meinem persönlichen Blog veröffentlicht: Verwendung von Team-Topologien zur Entdeckung und Verbesserung von Zuverlässigkeitsqualitäten