DevOps-Teamstruktur

Der Fokus auf Produkte statt auf Projekte ist ein Markenzeichen der digitalen Transformation. Und da Unternehmen schneller auf sich wandelnde Kundenbedürfnisse reagieren und Disruptoren abwehren wollen, ist die Notwendigkeit, den End-to-End-Produktlebenszyklus besser zu managen, zu einem entscheidenden Differenzierungsmerkmal geworden. In jüngerer Zeit hat sich DevOps als bevorzugter Ansatz für die Organisation von Produktteams etabliert, um Transparenz über die End-to-End-Wertschöpfungskette zu gewinnen, was unter anderem zu höherer Liefergeschwindigkeit und verbesserter Qualität führt. Der 14^. jährliche Bericht zum Stand der agilen Strategie berichtete, dass:

• 76 % der Befragten haben derzeit eine DevOps-Initiative oder planen eine in den nächsten 12 Monaten.
• 90 % der Befragten sagten, DevOps-Transformation sei in ihrer Organisation wichtig.

Wenn DevOps Organisationen einen Mehrwert bieten soll, wie sollten sie ihre Teams strukturieren, um das Beste aus diesem Ansatz herauszuholen? Gibt es eine Standardformel, an die sich alle halten sollten, oder ist sie anpassungsfähig an die spezifischen und einzigartigen Bedürfnisse der Organisation? Dieser Artikel versucht, dieses Thema zu behandeln.

Eigenschaften eines DevOps-Teams

Eine DevOps-Teammentalität unterscheidet sich von traditionellen IT- oder Scrum-Teams , da sie eine Ingenieurmentalität ist, die darauf abzielt, sowohl die Produktbereitstellung als auch den Produktwert für die Kunden während des gesamten Produktlebenszyklus zu optimieren. Damit diese Denkweise Wert liefert, muss das Team die folgenden Qualitäten annehmen, wie sie von DASA definiert sind:

• Agil. Das Team konzentriert sich darauf, Kundenwert entsprechend der verpflichteten Zeit, Qualität und dem Wert zu schaffen. Sie sind transparent in Bezug auf Leistung, Fortschritt und Hindernisse und setzen sich kontinuierlich und unermüdlich nach Verbesserung durch Feedback ein.
• Selbstorganisation. Das Team ist innerhalb festgelegter Grenzen autonom und ist durch eine klare Vision und Zieldefinition auf andere Teams ausgerichtet, daher ist es voneinander abhängig.
• Funktionsübergreifend. Alle erforderlichen Kompetenzen zur Entwicklung und Steuerung von Produkten sollten im Team erfolgen. Das Erreichen von kammenförmigen Kompetenzen ist für alle Teammitglieder bevorzugt, ebenso wie kontinuierlicher Wissensaustausch und Zusammenarbeit.
• Keine Unterteams. Das Team arbeitet optimal als eine Einheit und teilt sich nicht in separate Teams auf, um Arbeitsprobleme zu lösen.

(Entdecken Sie verschiedene Arten von IT-Teams.)

DevOps-Organisationsmodell

Die Struktur, die heute für DevOps-Organisationen am meisten geschätzt wird, ist ein zweistufiger Modus und umfasst:

• Business System Teams , die die volle Verantwortung für den Produktlebenszyklus von Ende zu Ende übernehmen sowie das Geschäfts- und Endnutzermanagement übernehmen.
• Plattformteams , die die zugrundeliegenden Plattformen und Infrastrukturen verwalten und diese als Self-Service für Geschäftssystemteams über APIs präsentieren.

Produktorientierte DevOps-Teams sind multidisziplinär und verfügen über alle für den gesamten Produktlebenszyklus erforderlichen Fähigkeiten. Dies reduziert teure Übergaben und Verzögerungen, wobei das Team sich darauf konzentriert:

• Produktfunktionen so schnell wie möglich an Kunden zu liefern
• Feedback autonom einzubeziehen, ohne bürokratische Hürden durch andere isolierte Einheiten zu überwinden

Moderne DevOps-Teams nutzen Value Stream Mapping , um ihre Aktivitäten zu visualisieren und notwendige Erkenntnisse zu gewinnen, um den Fluss der Produktinkremente und die Wertschöpfung zu optimieren. Ein Beispiel aus Spotify: Die Business-Teams werden Squads genannt, die bestimmte Services (z. B. Suche, Playlist, Player usw.) betreuen. Diese Squads sind klein, multidisziplinär und autonom. Sie arbeiten zusammen und agieren als Mini-Startups, wobei jede Komponente integriert wird, die für die Unterstützung eines Services während seines gesamten Lebenszyklus erforderlich ist. Die Squads sind lose gekoppelt, aber eng aufeinander abgestimmt. Wenn mehrere Squads an einem Feature zusammenarbeiten, bilden sie Tribes. Und für Spezialisten wie DBAs oder JavaScript-Entwickler gibt es:

• Kapitel zur Angleichung von Standards
• Gilden für Gemeinschaften, die Best Practices über die gesamte Organisation hinweg teilen möchten

Plattformteams bei Spotify werden Betriebsteams genannt. Ihre Rolle unterscheidet sich jedoch von dem traditionellen IT-Operations-Team, das an Bereitstellung und Support beteiligt ist. Ihr Kernauftrag ist es:

1. Bauen Sie die Pipeline zur Produktion auf, die von den Geschäftsteams genutzt wird.
2. Stellen Sie die Infrastruktur und Automatisierungstools bereit, die die Geschäftsentwickler benötigen, um den Code selbst zu veröffentlichen und zu unterstützen.
3. Stellen Sie sicher, dass die zugrundeliegende Infrastruktur und Plattformen die Dienste durch Kapazitäts- und Verfügbarkeitsplanung, Überwachung und Optimierung effektiv unterstützen können.

DevOps-Teamnummer

Die optimale Größe eines DevOps-Teams ist umstritten. Natürlich ist ein kleines Team aus mehreren Gründen vorzuziehen:

• Koordination ist einfacher
• Die Entscheidungsfindung zieht sich nicht in die Länge
• Das Gelling würde nicht lange dauern

Das Risiko bei kleinen Teams bedeutet jedoch, dass es eine Herausforderung sein kann, alle erforderlichen Fachkenntnisse zu erlangen, und der Verlust eines Teammitglieds könnte den Durchsatz des Teams erheblich beeinträchtigen. Allgemein gilt, dass Teamgrößen zwischen 5 und 12 liegen sollten.

DevOps-Teamrollen

Da erwartet wird, dass das DevOps-Team die End-to-End-Verantwortung für den Service trägt, umfassen einige der erwarteten Rollen innerhalb des Teams:

1. Der Product Owner steuert die Interaktion mit dem Kunden, um die Anforderungen zu verstehen, und arbeitet mit dem restlichen Team zusammen, um deren Lieferung zu priorisieren und Feedback einzubeziehen.
2. Der Teamleiter übernimmt die Aufsicht und leitet das Team basierend auf dem gewählten Ansatz (z. B. Scrum, Kanban, Lean usw.). Unterstützt außerdem die Koordination mit anderen Teams.
3. Der Solution Architect ermittelt, wie die Anforderungen im Einklang mit der Organisation und den bestehenden Systemen gestaltet werden.
4. Entwickler übersetzen das Design in Code und unterstützen den Code durch Tests und Deployment.
5. Qualitätssicherung (QA) validiert das Produkt, um sicherzustellen, dass es sowohl Kunden- als auch Organisationsanforderungen während der gesamten Entwicklungs- und Bereitstellungsphase erfüllt.
6. Der Platform Engineer unterstützt die Plattformteams, um sicherzustellen, dass die Umgebung die Produkte effektiv unterstützt, und nutzt die bereitgestellten Werkzeuge, um Integration und Bereitstellung zu automatisieren.

Da jede Organisation unterschiedlich ist, können die Rollen je nach Fähigkeiten des Teams von Einzelpersonen übernommen oder gemischt sein. Doch während das Team weiterhin zusammenarbeitet, findet eine Gegenseitigkeit statt, da Wissen und Verantwortung geteilt werden. Der Upskilling-Bericht des DevOps Institute 2021 bewertete die wichtigsten Fähigkeiten, die ein DevOps-Teammitglied benötigt, sind:

• Automatisierungsfähigkeiten: Ersetzung manueller Aktivitäten, Aufgaben oder Ereignisse
• Menschliche (weiche) Fähigkeiten: Zusammenarbeit, Kommunikation, Empathie
• Technische Fähigkeiten: Programmierung, Cloud, Microservices, APIs
• Spezifische Automatisierungstools-Fähigkeiten: CI/CD, Orchestrierung
• Funktionales Wissen: Entwicklung, Betrieb, Sicherheit
• Prozessfähigkeiten und -wissen: SAFe, SRE, ITIL^®
• Geschäftskompetenz: Planung, Finanzen, Vertrieb

Tauchen Sie tiefer in DevOps-Stellenbezeichnungen, Rollen und Verantwortlichkeiten ein, im nächsten Artikel unseres DevOps-Leitfadens.

Verwandte Literatur

• • BMC DevOps Blog
  • Product Owner vs. Product Manager: Was ist der Unterschied?
  • Agile Rollen und Verantwortlichkeiten
  • Häufige Rollen im Cloud Computing
  • Tiger Teams: Wie man kritische Probleme löst

DevOps-Leitfaden

1. Was ist DevOps? Eine umfassende Einführung
2. Eine kurze Geschichte von DevOps
3. Einführung in die DevOps-Architektur
4. Automatisierung in DevOps: Warum und wie man DevOps-Praktiken automatisiert
5. Was ist CI/CD? Kontinuierliche Integration und kontinuierliche Lieferung erklärt
6. Wie man eine CI/CD-Pipeline mit Jenkins aufbaut
7. DevOps-Metriken zur Optimierung von CI/CD-Pipelines
8. Kontinuierliche Liefermetriken
9. Ist Continuous Integration in Continuous Deployment ein Fortschritt – oder nicht?
10. Unterschiede zwischen Continuous Integration (CI), Delivery (CD) und Deployment
11. Quellcode und Versionskontrolle in DevOps
12. Was ist kontinuierliche Testung?
13. Testautomatisierungs-Frameworks: Der ultimative Leitfaden
14. Release Management in DevOps
15. Erklärt: Monitoring & Telemetrie in DevOps
16. Anwendungs-Leistungsmanagement in DevOps
17. DevOps-Orchestrierung im SDLC
18. Einführung in Datenbank-DevOps
19. Die Rolle der Microservices in DevOps
20. Die Rolle der Virtualisierung in DevOps
21. Container & DevOps: Wie Container in DevOps-Lieferpipelines passen
22. Was ist eine Containerpipeline?
23. Was ist eine DevOps-Toolchain?
24. Verwaltung von Containern und Code für DevOps
25. Die Rolle von Agile in DevOps
26. Die Rolle der Cloud in DevOps
27. Was ist FinDevOps?
28. Top-DevOps-Trends im Jahr 2022
29. DevOps-Werte & Prinzipien
30. DevOps-Kennzahlen und KPIs
31. DevOps-Ratschläge für kleine, mittlere und große Organisationen
32. DevOps-Teamstruktur
33. Top-DevOps-Bücher, die man heute lesen sollte
34. Buchrezension von The Phoenix Project: DevOps For Everyone
35. DevOps-Influencer: 11 DevOps-Experten, denen Sie auf Twitter folgen können
36. GitHub, GitLab, Bitbucket & Azure DevOps: Was ist der Unterschied?
37. Best Practices: Wie man Anwendungen für Kubernetes architekt
38. Konfigurationsmanagement in DevOps
39. DevOps-Verzweigungsstrategien erklärt
40. DevOps-Jobbezeichnungen, Rollen und Verantwortlichkeiten
41. Testen in DevOps: Konzepte, Best Practices und mehr
42. Der vollständige DevOps-Zertifizierungsleitfaden für 2022
43. Was ist das Kubernetes-Operator-Muster?

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.