|
|
|
|
| LEADER |
12592nmm a2200469 u 4500 |
| 001 |
EB002189775 |
| 003 |
EBX01000000000000001327240 |
| 005 |
20260105000000.0 |
| 007 |
cr||||||||||||||||||||| |
| 008 |
240103 ||| ger |
| 020 |
|
|
|a 9783960108368
|
| 050 |
|
4 |
|a HD30.2
|
| 100 |
1 |
|
|a Skelton, Matthew
|
| 130 |
0 |
|
|a Team topologies
|
| 245 |
0 |
0 |
|a Team Topologies
|b Organisation von Business- und IT-Teams für einen schnellen Arbeitsfluss : Inklusive Interaktionen in verteilten Teams - Workbook : Team-Topologies-Patterns für eine produktivere Zusammenarbeit
|c Matthew Skelton, Manuel Pais ; Deutsche Übersetzung von Michael Plöd
|
| 260 |
|
|
|a Heidelberg
|b dpunkt.verlag
|c 2023
|
| 300 |
|
|
|a 1 online resource
|
| 505 |
0 |
|
|a Zusammenfassung: Adaptieren und entwickeln Sie Team-Topologien, die zu Ihrem aktuellen Kontext passen -- Kapitel 5: Die vier grundlegenden Team Topologies -- Stream-aligned Teams -- Fähigkeiten innerhalb eines Stream-aligned Teams -- Warum Stream-aligned Team und nicht »Produkt«- oder »Feature«-Team? -- Erwartete Verhaltensweisen -- Enabling Teams -- Erwartete Verhaltensweisen -- Enabling Team versus Communities of Practice (CoP) -- Complicated-subsystem Teams -- Erwartete Verhaltensweisen -- Platform Teams -- Erwartete Verhaltensweisen -- Stellen Sie die Plattform aus Gruppen anderer grundlegender Teams zusammen -- Vermeiden Sie Team-Silos im Zuge des Wandels -- Eine gute Plattform ist »gerade groß genug« -- Die Thinnest Viable Platform (schlankste brauchbare Plattform) -- Reduzierung der kognitiven Belastung und Beschleunigung der Produktentwicklung -- Überzeugende, konsistente und sorgfältig ausgewählte Rahmenbedingungen -- Auf einer zugrunde liegenden Plattform aufgebaut -- Als Live-Produkt oder Service managen -- Ordnen Sie die bekannten Teamtypen den grundlegenden Team Topologies zu -- Bevorzugen Sie Stream-aligned Teams, um Langlebigkeit und Flexibilität zu erreichen -- Von Infrastruktur-Teams zu Platform Teams -- Von Komponenten-Teams zu Platform Teams oder anderen Teamtypen -- Von Tooling-Teams zu Enabling Teams oder einem Teil einer Plattform -- Die Transformation von Support-Teams -- Die Neuausrichtung von Architektur und Architekten -- Zusammenfassung: Verwenden Sie lose gekoppelte, modulare Gruppen von vier spezifischen Teamtypen -- Kapitel 6: Entscheiden Sie sich für teamorientierte Grenzen -- Ein teamorientierter Ansatz für Zuständigkeiten und Grenzen von Software -- Versteckte Monolithen und Kopplung -- Anwendungsmonolith -- Datenbankmonolith -- Monolithische Builds (alles neu bauen) -- Monolithische (gekoppelte) Releases
|
| 505 |
0 |
|
|a Beschränken Sie die Verantwortlichkeiten des Teams auf die kognitive Belastung des Teams -- Messen Sie die kognitive Belastung mithilfe relativer Fachkomplexität -- Begrenzen Sie die Anzahl und den Typ der Domänen pro Team -- Passen Sie die Systemgröße und Softwaregrenzen an die kognitive Belastung der Teams an -- Entwerfen Sie »Team-APIs« und gestalten Sie Teaminteraktionen -- Definieren Sie »Team-APIs«, die Code, Dokumentation und Benutzererlebnis beinhalten -- Förderung von Teaminteraktionen für Vertrauen, Bewusstsein und Lernen -- Entwerfen Sie explizit die physische und virtuelle Umgebung, um Interaktionen im Team zu unterstützen -- Warnung: Engineering-Praktiken sind unerlässlich -- Zusammenfassung: Begrenzen Sie die kognitive Belastung von Teams und gestalten Sie Teaminteraktionen, um einfacher und schneller zu arbeiten -- TEIL II: Team Topologies, die für einen reibungslosen Arbeitsfluss sorgen -- Die wichtigsten Erkenntnisse -- Kapitel 4: Statische Team Topologies -- Team-Anti-Patterns -- Design für den Fluss des Wandels -- Gestalten Sie die Kommunikation zwischen den Teams, um einen reibungslosen Arbeitsfluss und eine gute Wahrnehmung zu ermöglichen -- DevOps und die DevOps-Topologien -- DevOps-Topologien -- Erfolgreiche Team-Patterns -- Feature-Teams erfordern eine hohe technische Reife und Vertrauen -- Produktteams brauchen ein Support-System -- Cloud-Teams erstellen keine Anwendungsinfrastruktur -- SRE ergibt bei Skalierung Sinn -- Überlegungen bei der Auswahl einer Topologie -- Technischer und kultureller Reifegrad -- Unternehmensgröße, Softwareskalierung und Engineering- Reifegrad -- Verantwortlichkeiten aufteilen, um Silos aufzubrechen -- Abhängigkeiten und Wartezeiten zwischen Teams -- Verwendung von DevOps-Topologien zur Weiterentwicklung der Organisation
|
| 505 |
0 |
|
|a Entdecken Sie effektive APIs zwischen Teams durch bewusste Evolution von Team Topologies -- Wählen Sie Teaminteraktionsmodi, um Unsicherheiten zu verringern und den Arbeitsfluss zu verbessern -- Nutzen Sie den Collaboration-Modus, um praktikable X-as-a-Service-Interaktionen zu ermitteln -- Ändern Sie vorübergehend den Modus der Teaminteraktion, um einem Team zu helfen, Erfahrung und Empathie zu entwickeln -- Nutzen Sie die Unbeholfenheit in Teaminteraktionen, um ein Gespür für fehlende Fähigkeiten und unpassende Grenzen zu bekommen -- Zusammenfassung: Drei gut abgegrenzte Modi der Teaminteraktion -- Kapitel 8: Entwickeln Sie Teamstrukturen mit einem Gespür für organisatorische Belange -- Wie viel Collaboration ist für jede Teaminteraktion angemessen? -- Beschleunigung des Lernens und der Übernahme neuer Praktiken -- Konstante Evolution der Team Topologies -- Die Kombination von Team Topologies für mehr Effektivität -- Auslöser für die Evolution von Team Topologies -- Auslöser: Die Software ist zu groß für ein Team geworden -- Auslöser: Die Auslieferungsrate wird langsamer -- Auslöser: Mehrere Business Services hängen von einer großen Anzahl von Basis-Services ab -- Selbststeuerung von Design und Entwicklung -- Behandeln Sie Teams und Teaminteraktionen als Sinnesorgane und Signale -- IT-Betrieb als wertvoller sensorischer Input für die Entwicklung -- Zusammenfassung: Evolutionäre Team Topologies -- Vier Team-Arten und drei Interaktionsmodi -- Teamorientiertes Denken: Kognitive Belastung, Team-API, Architektur in Teamgröße -- Strategische Anwendung des Conway'schen Gesetzes -- Weiterentwicklung des Organisationsdesigns für Anpassungs- und Wahrnehmungsfähigkeit -- Team Topologies allein sind nicht ausreichend für die Effektivität der IT -- Nächste Schritte: Wie Sie mit Team Topologies loslegen -- Schritt 1: Beginnen Sie mit dem Team
|
| 505 |
0 |
|
|a Monolithisches Modell (eine Sicht auf die Welt) -- Monolithisches Denken (Standardisierung) -- Monolithischer Arbeitsplatz (Großraumbüro) -- Softwaregrenzen oder »Bruchflächen« -- Bruchfläche: an Geschäftsdomäne angelehnter Bounded Context -- Bruchfläche: regulatorische Compliance -- Bruchfläche: Änderungskadenz -- Bruchfläche: Teamstandort -- Bruchfläche: Risiko -- Bruchfläche: Performance-Isolierung -- Bruchfläche: Technologie -- Bruchfläche: User Personas -- Natürliche Bruchflächen für Ihre spezifische Organisation oder Technologien -- Beispiel aus der realen Welt: Fertigungsindustrie -- Zusammenfassung: Wählen Sie Softwaregrenzen, die der kognitiven Belastung des jeweiligen Teams entsprechen -- TEIL III: Evolution von Teaminteraktionen für Innovation und schnelle Lieferfähigkeit -- Die wichtigsten Erkenntnisse -- Kapitel 7: Die Modi der Teaminteraktion -- Gut definierte Interaktionen sind der Schlüssel zu effektiven Teams -- Die drei wesentlichen Modi der Teaminteraktion -- Collaboration: Motor für Innovation und schnelle Discovery, aber die Grenzen verschwimmen -- X as a Service: Klare Zuständigkeiten mit berechenbarer Bereitstellung, aber ein gutes Produktmanagement ist erforderlich -- Facilitating: Erkennen und Verringern von Kompetenzlücken -- Teamverhaltensweisen für jeden Interaktionsmodus -- Teamverhaltensweisen für den Modus Collaboration: »Hohe Interaktion und gegenseitiger Respekt« -- Teamverhaltensweisen für den Modus X as a Service: »Setzen Sie einen Schwerpunkt auf User Experience« -- Teamverhaltensweisen für den Modus Facilitating: »Helfen und Hilfe annehmen« -- Auswahl geeigneter Modi für die Teaminteraktion -- Auswahl der grundlegenden Teamorganisation -- Verwenden Sie das Reverse Conway Maneuver mit den Interaktionen Collaboration und Facilitating
|
| 505 |
0 |
|
|a Intro -- Inhalt -- Team Topologies -- Vorwort -- Vorwort des Übersetzers -- Einleitung -- Wie wir dazu kamen, dieses Buch zu schreiben -- Wie man dieses Buch benutzt -- Wichtige Einflüsse, die dieses Buch geprägt haben -- TEIL I: Teams als entscheidendes Mittel bei der Lieferung -- Die wichtigsten Erkenntnisse -- Kapitel 1: Das Problem mit Organisationsdiagrammen -- Kommunikationsstrukturen einer Organisation -- Das Denken in Organigrammen ist das Problem -- Jenseits des Organigramms -- Team Topologies: Eine neue Art, über Teams zu denken -- Das Revival von Conway's Law -- Kognitive Belastung und Engpässe -- Zusammenfassung: Überdenken Sie Teamstrukturen, Zweck und Interaktionen -- Kapitel 2: Das Conway'sche Gesetz und seine Bedeutung -- Das Conway'sche Gesetz verstehen und anwenden -- Das Reverse Conway Maneuver -- Softwarearchitekturen, die einen teamorientierten Arbeitsfluss fördern -- Organisationsgestaltung erfordert technische Expertise -- Beschränken Sie unnötige Kommunikation -- Es muss nicht jede mit jedem kommunizieren -- Achtung! Naive Anwendungen des Conway'schen Gesetzes -- Die Tool-Auswahl beeinflusst die Kommunikationsmuster -- Viele verschiedene Komponenten-Teams -- Wiederholte Reorganisationen, die Machtpositionen schaffen oder den Personalbestand reduzieren -- Zusammenfassung: Conway's Law ist entscheidend für effizientes Teamdesign in der Tech-Branche -- Kapitel 3: Teamorientiertes Denken -- Setzen Sie auf kleine, langlebige Teams als Standard -- Kleinere Teamgrößen fördern das Vertrauen -- Arbeitsabläufe für langlebige Teams -- Das Team verantwortet die Software -- Teammitglieder brauchen ein teamorientiertes Mindset -- Begrüßen Sie Vielfalt in Teams -- Belohnen Sie das ganze Team, nicht einzelne Personen -- Gute Grenzen verringern die kognitive Belastung
|
| 653 |
|
|
|a Computer software / Development / Management
|
| 653 |
|
|
|a Teams in the workplace / Management / fast / (OCoLC)fst01144690
|
| 653 |
|
|
|a Information technology / Management / fast / (OCoLC)fst00973112
|
| 653 |
|
|
|a Computer software / Development / Management / fast / (OCoLC)fst00872548
|
| 653 |
|
|
|a Teams in the workplace / Management
|
| 653 |
|
|
|a Information technology / Management / http://id.loc.gov/authorities/subjects/sh2008006980
|
| 653 |
|
|
|a Technologie de l'information / Gestion
|
| 653 |
|
|
|a Équipes de travail / Gestion
|
| 700 |
1 |
|
|a Pais, Manuel
|e author
|
| 700 |
1 |
|
|a Plöd, Michael
|e translator
|
| 041 |
0 |
7 |
|a ger
|2 ISO 639-2
|
| 989 |
|
|
|b OREILLY
|a O'Reilly
|
| 500 |
|
|
|a Description based upon print version of record
|
| 776 |
|
|
|z 9783960092315
|
| 856 |
4 |
0 |
|u https://learning.oreilly.com/library/view/~/9781098168933/?ar
|x Verlag
|3 Volltext
|
| 082 |
0 |
|
|a 658
|
| 082 |
0 |
|
|a 658.4/022
|
| 082 |
0 |
|
|a 658.4022
|
| 082 |
0 |
|
|a 331
|
| 520 |
|
|
|a Effektive Softwareteams sind für jedes Unternehmen unerlässlich, um kontinuierlich und nachhaltig Werte zu schaffen.Team Topologies ist ein praktisches, schrittweise anpassbares Modell für die Gestaltung von Organisationen und die Interaktion von Teams. Es basiert auf vier Teamtypen und drei Formen der Teaminteraktion und versteht Teams als entscheidenden Faktor der Wertschöpfung. Mit der technologischen und organisatorischen Reife einer Organisation werden sich Teamstrukturen und Kommunikationswege kontinuierlich weiterentwickeln.Im Bestseller Team Topologies präsentieren die IT-Berater Matthew Skelton und Manuel Pais eine grundlegende Weiterentwicklung des Organisationsdesigns für die Entwicklung von Software. Anhand von Fallstudien und Beispielen aus der Industrie beschreiben sie eine klar definierte Vorgehensweise für die Interaktion und das Zusammenwirken von Teams. Ihre Methode trägt entscheidend dazu bei, die Architektur von Software klarer und nachhaltiger zu gestalten und Probleme zwischen Teams in wertvolle Signale für eine sich selbst lenkende Organisation zu verwandeln.- Verstehen Sie das Conway’sche Gesetz und seine Bedeutung- Vereinfachen Sie mit vier Teamtypen die Organisation moderner Softwareteams- Gestalten Sie Teamgrenzen – und -APIs und reduzieren Sie die kognitive Belastung Ihrer Entwicklungsteams- Verbessern Sie durch drei Formen der Interaktion die Bereitstellung von Software- Nutzen Sie den Betrieb der Software als sensorischen Input zur Selbststeuerung Ihrer Organisation
|