Facebook Pixel
Searching...
Deutsch
EnglishEnglish
EspañolSpanish
简体中文Chinese
FrançaisFrench
DeutschGerman
日本語Japanese
PortuguêsPortuguese
ItalianoItalian
한국어Korean
РусскийRussian
NederlandsDutch
العربيةArabic
PolskiPolish
हिन्दीHindi
Tiếng ViệtVietnamese
SvenskaSwedish
ΕλληνικάGreek
TürkçeTurkish
ไทยThai
ČeštinaCzech
RomânăRomanian
MagyarHungarian
УкраїнськаUkrainian
Bahasa IndonesiaIndonesian
DanskDanish
SuomiFinnish
БългарскиBulgarian
עבריתHebrew
NorskNorwegian
HrvatskiCroatian
CatalàCatalan
SlovenčinaSlovak
LietuviųLithuanian
SlovenščinaSlovenian
СрпскиSerbian
EestiEstonian
LatviešuLatvian
فارسیPersian
മലയാളംMalayalam
தமிழ்Tamil
اردوUrdu
Team Topologies

Team Topologies

Organizing Business and Technology Teams for Fast Flow
von Matthew Skelton 2019 240 Seiten
4.21
4k+ Bewertungen
Hören

Wichtige Erkenntnisse

1. Conways Gesetz formt Softwarearchitektur durch Teamstrukturen

Wenn die Architektur des Systems und die Architektur der Organisation im Widerspruch stehen, gewinnt die Architektur der Organisation.

Kommunikationsstrukturen sind entscheidend. Conways Gesetz zeigt, dass die Kommunikationsstruktur einer Organisation direkt das Design der von ihr erstellten Systeme beeinflusst. Dieses Prinzip hat tiefgreifende Auswirkungen auf die Softwarearchitektur und die Teamorganisation. Durch die Ausrichtung der Teamstrukturen an den gewünschten Systemarchitekturen können Organisationen Conways Gesetz zu ihrem Vorteil nutzen.

Reverse Conway Manöver. Anstatt die Teamstrukturen das Systemdesign diktieren zu lassen, können Organisationen ihre Teams bewusst so gestalten, dass sie die gewünschte Architektur hervorbringen. Dieser Ansatz, bekannt als "Reverse Conway Manöver", umfasst:

  • Identifizierung der Zielsystemarchitektur
  • Gestaltung von Teamstrukturen, die diese Architektur widerspiegeln
  • Zulassen der natürlichen Kräfte von Conways Gesetz zur Steuerung der Entwicklung

Strategische Teamgestaltung. Durch bewusstes Design der Teamstrukturen können Organisationen:

  • Modulare, lose gekoppelte Systeme fördern
  • Klare Schnittstellen zwischen Komponenten schaffen
  • Die Wartbarkeit und Skalierbarkeit des Systems verbessern

2. Team-First-Ansatz optimiert für kognitive Belastung und Flow

Die Reduzierung der kognitiven Belastung für Teams und die Erleichterung der Teaminteraktionen helfen, den Flow zu optimieren.

Kognitive Belastung ist wichtig. Der Team-First-Ansatz erkennt an, dass es eine Grenze für die Komplexität gibt, die ein Team effektiv bewältigen kann. Durch die Priorisierung der kognitiven Kapazität des Teams können Organisationen:

  • Produktivität und Innovation steigern
  • Stress und Burnout reduzieren
  • Die Codequalität und Systemzuverlässigkeit verbessern

Strategien zur Verwaltung der kognitiven Belastung:

  • Begrenzung der Teamverantwortlichkeiten auf ihre kognitive Kapazität
  • Aufteilung großer Systeme in teamgerechte Komponenten
  • Bereitstellung klarer, gut definierter Schnittstellen zwischen Teams
  • Investition in Tools und Plattformen, die komplexe Aufgaben vereinfachen

Optimierung für Flow. Durch die Reduzierung unnötiger kognitiver Belastungen können Teams einen Zustand des Flows erreichen, der gekennzeichnet ist durch:

  • Hohe Produktivität und Kreativität
  • Erhöhte Arbeitszufriedenheit
  • Schnellere Problemlösung und Innovation

3. Vier grundlegende Team-Topologien treiben effektive Softwarebereitstellung voran

Die vier grundlegenden Team-Topologien sind: Stream-aligned, Enabling, Complicated Subsystem und Platform.

Stream-aligned Teams bilden das Rückgrat der Organisation und liefern direkt Wert an Benutzer oder Kunden. Sie sind:

  • Funktionsübergreifend
  • An ein spezifisches Produkt, eine Dienstleistung oder eine Benutzerreise ausgerichtet
  • Befähigt, End-to-End-Wert zu liefern

Enabling Teams unterstützen und beschleunigen Stream-aligned Teams durch:

  • Bereitstellung spezialisierter Expertise
  • Durchführung von Forschung und Prototyping
  • Erleichterung des Wissenstransfers

Complicated Subsystem Teams verwalten komplexe Komponenten, die tiefgehende Expertise erfordern, sodass Stream-aligned Teams sich auf die Wertschöpfung konzentrieren können.

Platform Teams bieten interne Dienste und Tools, die Stream-aligned Teams befähigen, effizienter und autonomer zu arbeiten.

Durch die Einführung dieser vier Teamtypen können Organisationen:

  • Teamverantwortlichkeiten und -interaktionen klären
  • Abhängigkeiten und Engpässe reduzieren
  • Die Gesamtgeschwindigkeit und Qualität der Bereitstellung verbessern

4. Gut definierte Team-Interaktionsmodi verbessern Zusammenarbeit und Produktivität

Die Begrenzung der Teaminteraktion auf drei Modi – Zusammenarbeit, X-as-a-Service und Erleichterung – vereinfacht und klärt wesentliche Interaktionen zwischen Teams, die Softwaresysteme entwickeln.

Zusammenarbeitsmodus beinhaltet enge Teamarbeit für Entdeckung und Innovation. Es wird am besten verwendet:

  • In den frühen Phasen der Entwicklung neuer Systeme
  • Zur Lösung komplexer, bereichsübergreifender Probleme
  • Wenn schnelles Lernen und Anpassung entscheidend sind

X-as-a-Service-Modus etabliert klare Anbieter-Konsumenten-Beziehungen zwischen Teams. Es ist ideal für:

  • Stabile, gut definierte Dienste oder Komponenten
  • Maximierung der Teamautonomie
  • Ermöglichung vorhersehbarer, skalierbarer Interaktionen

Erleichterungsmodus beinhaltet, dass ein Team einem anderen hilft, neue Fähigkeiten zu entwickeln. Es ist nützlich für:

  • Wissenstransfer und Kompetenzentwicklung
  • Temporäre Unterstützung während Übergangsphasen
  • Bewältigung bereichsübergreifender Herausforderungen

Durch die explizite Definition dieser Interaktionsmodi können Organisationen:

  • Mehrdeutigkeit in den Teambeziehungen reduzieren
  • Fokus und Produktivität verbessern
  • Reibungslosere bereichsübergreifende Zusammenarbeit erleichtern

5. Softwaregrenzen an die kognitiven Kapazitäten der Teams anpassen

Wählen Sie Softwaregrenzen, die zur kognitiven Belastung des Teams passen.

Teamgerechte Architektur. Die Anpassung der Softwaregrenzen an die kognitiven Kapazitäten der Teams stellt sicher, dass Teams ihre Teile des Systems effektiv besitzen und weiterentwickeln können. Dieser Ansatz führt zu:

  • Erhöhter Eigenverantwortung und Verantwortlichkeit
  • Schnellerer Entwicklung und Problemlösung
  • Verbesserter Wartbarkeit des Systems

Strategien zur Definition von Grenzen:

  • Verwenden Sie Domain-Driven Design, um natürliche Systemgrenzen zu identifizieren
  • Berücksichtigen Sie Teamgröße und -expertise bei der Definition des Komponentenumfangs
  • Nutzen Sie Microservices-Architektur, um handhabbare, teamgerechte Dienste zu schaffen

Vorteile der richtigen Grenzanpassung:

  • Reduzierte kognitive Überlastung für Teams
  • Klarere Verantwortlichkeiten und Schnittstellen zwischen Teams
  • Verbesserte Fähigkeit, das System im Laufe der Zeit weiterzuentwickeln und zu skalieren

6. Plattformen sollten „gerade groß genug“ sein, um Stream-aligned Teams zu unterstützen

Eine gute Plattform bietet Standards, Vorlagen, APIs und bewährte Best Practices, die Dev-Teams nutzen können, um schnell und effektiv zu innovieren.

Dünnste lebensfähige Plattform (TVP). Die ideale Plattform bietet gerade genug Unterstützung, um Stream-aligned Teams zu beschleunigen, ohne zu komplex oder restriktiv zu werden. Merkmale einer guten TVP sind:

  • Klare, gut dokumentierte APIs
  • Self-Service-Fähigkeiten
  • Abstraktion von gemeinsamen, komplexen Aufgaben

Plattformentwicklung. Mit dem Wachstum der Organisation und dem Wandel der Technologien sollte sich die Plattform weiterentwickeln, um:

  • Aufkommende Bedürfnisse der Stream-aligned Teams zu adressieren
  • Neue Technologien und Best Practices zu integrieren
  • Untergenutzte Funktionen zu vereinfachen oder zu entfernen

Vorteile einer gut gestalteten Plattform:

  • Reduzierte kognitive Belastung für Stream-aligned Teams
  • Schnellere Markteinführung neuer Funktionen und Produkte
  • Verbesserte Konsistenz und Zuverlässigkeit über Systeme hinweg

7. Teamstrukturen kontinuierlich weiterentwickeln, um sich an veränderte Bedürfnisse anzupassen

Unterschiedliche Topologien und unterschiedliche Teaminteraktionen für verschiedene Teile einer Organisation müssen sich zu unterschiedlichen Zeiten weiterentwickeln, basierend auf dem, was sie tun und was sie zu erreichen versuchen.

Organisatorisches Sensing. Kontinuierlich die Effektivität und Interaktionen der Teams überwachen und bewerten, um Verbesserungsmöglichkeiten zu identifizieren. Wichtige Indikatoren sind:

  • Geschwindigkeit und Qualität der Bereitstellung
  • Zufriedenheit und Engagement der Teams
  • Effektivität der bereichsübergreifenden Zusammenarbeit

Adaptive Teamstrukturen. Seien Sie bereit, Team-Topologien und Interaktionsmodi anzupassen, wenn sich die Bedürfnisse ändern. Dies könnte beinhalten:

  • Aufteilung oder Zusammenführung von Teams
  • Wechsel zwischen Zusammenarbeit und X-as-a-Service-Modi
  • Schaffung oder Auflösung von Enabling Teams

Vorteile der kontinuierlichen Weiterentwicklung:

  • Verbesserte Reaktionsfähigkeit auf Markt- und Technologieänderungen
  • Erhöhte Effektivität und Zufriedenheit der Teams
  • Optimierte Organisationsstruktur für aktuelle Ziele und Herausforderungen

8. Behandeln Sie den Betrieb als hochpräzisen sensorischen Input für die Entwicklung

Die Behandlung von Ops als Input für Dev erfordert ein radikales Umdenken der Rollen dieser oft getrennten Gruppen.

DevOps-Integration. Die Verwischung der Grenzen zwischen Entwicklung und Betrieb schafft eine Feedbackschleife, die die Gesamtqualität und Zuverlässigkeit des Systems verbessert. Dieser Ansatz umfasst:

  • Geteilte Verantwortung für die Systemleistung
  • Kontinuierliches Feedback von der Produktion zur Entwicklung
  • Kollaborative Problemlösung über traditionelle Grenzen hinweg

Vorteile von Ops-als-Input:

  • Schnellere Identifizierung und Lösung von Problemen
  • Verbesserte Systemzuverlässigkeit und -leistung
  • Erhöhtes Einfühlungsvermögen zwischen Entwicklungs- und Betriebsteams

Strategien zur Implementierung:

  • Implementieren Sie robuste Überwachungs- und Alarmsysteme
  • Etablieren Sie funktionsübergreifende Teams mit sowohl Dev- als auch Ops-Expertise
  • Schaffen Sie Prozesse für schnelles Feedback und Iteration basierend auf operativen Erkenntnissen

9. Design für teamgerechte Softwarearchitektur zur Verbesserung der Eigenverantwortung

Ein Team, das mit Softwaresystemen arbeitet, die eine zu hohe kognitive Belastung erfordern, kann die Software nicht effektiv besitzen oder sicher weiterentwickeln.

Teamgerechte Komponenten. Zerlegen Sie große Systeme in handhabbare, teamgerechte Komponenten, die mit den kognitiven Kapazitäten der Teams übereinstimmen. Dieser Ansatz:

  • Erhöht die Eigenverantwortung und Verantwortlichkeit der Teams
  • Erleichtert schnellere Entwicklung und Problemlösung
  • Verbessert die Gesamtwartbarkeit des Systems

Strategien zur Implementierung:

  • Verwenden Sie Domain-Driven Design, um natürliche Systemgrenzen zu identifizieren
  • Nutzen Sie Microservices-Architektur, um handhabbare Dienste zu schaffen
  • Richten Sie die Teamverantwortlichkeiten an gut definierten Systemkomponenten aus

Vorteile der teamgerechten Architektur:

  • Reduzierte kognitive Überlastung für Teams
  • Klarere Verantwortlichkeiten und Schnittstellen zwischen Teams
  • Verbesserte Fähigkeit, das System im Laufe der Zeit weiterzuentwickeln und zu skalieren
  • Erhöhte Zufriedenheit und Engagement der Teams

Zuletzt aktualisiert:

Rezensionen

4.21 von 5
Durchschnitt von 4k+ Bewertungen von Goodreads und Amazon.

Team Topologies bietet Einblicke in die Organisation von IT-Teams für hohe Leistungsfähigkeit und betont einen teamzentrierten Ansatz, der für den Erfolg von DevOps und Agile entscheidend ist. Es stellt vier grundlegende Teamtypen und drei Interaktionsmodi als Werkzeuge für den Aufbau agiler Organisationen vor. Während das Buch für sein umfassendes Modell und seine praktischen Ratschläge gelobt wird, fanden einige Rezensenten es repetitiv und in bestimmten Bereichen unzureichend. Das Buch wird Führungskräften in der Softwareentwicklung empfohlen, obwohl die Meinungen über seine Tiefe und Anwendbarkeit in verschiedenen organisatorischen Kontexten variieren.

Über den Autor

Matthew Skelton ist ein britisch-kanadischer Autor, der seine Schriftstellerkarriere während seiner Tätigkeit in der Wissenschaft begann. Er verbrachte seine frühen Jahre in Kanada, bevor er nach Großbritannien zurückkehrte, wo er als Forschungsassistent in Oxford arbeitete. Skeltons literarischer Durchbruch kam im Jahr 2002, als er den Kurzgeschichtenwettbewerb von Richard und Judy gewann. Sein erster Roman, Endymion Spring, markierte sein Debüt als veröffentlichter Autor. Skeltons Hintergrund in der Wissenschaft und seine internationale Erziehung haben wahrscheinlich seinen Schreibstil und seine Themen beeinflusst.

0:00
-0:00
1x
Dan
Andrew
Michelle
Lauren
Select Speed
1.0×
+
200 words per minute
Create a free account to unlock:
Bookmarks – save your favorite books
History – revisit books later
Ratings – rate books & see your ratings
Unlock unlimited listening
Your first week's on us!
Today: Get Instant Access
Listen to full summaries of 73,530 books. That's 12,000+ hours of audio!
Day 4: Trial Reminder
We'll send you a notification that your trial is ending soon.
Day 7: Your subscription begins
You'll be charged on Nov 29,
cancel anytime before.
Compare Features Free Pro
Read full text summaries
Summaries are free to read for everyone
Listen to summaries
12,000+ hours of audio
Unlimited Bookmarks
Free users are limited to 10
Unlimited History
Free users are limited to 10
What our users say
30,000+ readers
“...I can 10x the number of books I can read...”
“...exceptionally accurate, engaging, and beautifully presented...”
“...better than any amazon review when I'm making a book-buying decision...”
Save 62%
Yearly
$119.88 $44.99/yr
$3.75/mo
Monthly
$9.99/mo
Try Free & Unlock
7 days free, then $44.99/year. Cancel anytime.
Settings
Appearance