Langlebig - solange die Komponente besteht existiert das Team.
Oft bei Monolithen, zB Frontend/Backend-Teams
Manche Komponenten sind im Maintenance-Modus
Das Team kann zum Engpass für die Komponente werden
Features basieren meist auf mehreren Komponenten
Funktioniert auch mit geringer technischer und organisatorische Reife.
Feature-Teams
long-lived—the team stays together so that they can ‘jell’ for higher performance; they take on new features over time
cross-functional and cross-component
co-located
work on a complete customer-centric feature, across all components and disciplines (analysis, programming, testing, …)
composed of generalizing specialists
in Scrum, typically 7 ± 2 people
Im Monolithen
Monolithic Delivery
Build-run-Teams
Sowohl Feature als auch Component-Teams
Volle Verantwortung für alle Features von einer Komponente
Nur auf Basis von Micro/Mini-Service-Architekturen machbar
Kann weitgehend autark agieren - von GUI zu Deploy
Mit den anderen Komponenten
wird über APIs geredet.
Build-run-Teams
Platform Team
Eigenständiges Team, das sich um Auswahl, Aufbau und Konfiguration des Basissets von Werkzeugen und Praktiken, die von allen Teams genutzt werden, kümmert.
Selbst ein Built-Run-Team für die Platform.
Fokus ist sowohl Stabilität der Platform als auch Performance und Arbeitserleichterung für die anderen Teams
Service Delivery
Das Start-Dilemma
Die Plattform existiert noch nicht
es fehlt die neue Infrastruktur
es fehlen Services und Beispiele, die sie nutzen
Die alte Plattform muss auch weiterbetrieben werden
Die Kollegen kennen die neuen Technologien noch nicht
Core Team
Das erste Team für die neue Platform
Drei Deliveries:
die neue Platform
Architektur und Beispiele
Bootcamp, Onboarding & Schulung
HandsOn-Aufbau der neuen Plattform
Geht später in Platform-Team und BR-Teams auf.
MVP Platform
Wird vom Core Team gebaut
Sobald es von anderen nutzbar ist können auch andere Teams darauf aufsetzen
nach ca 2 Monaten vorhanden
20%-40% der finalen Plattformfeatures
Experimente und PoC gehören dazu.
Zeitlinie
Zeitlinie
Strangle Monolithic Organization
Man muss nicht nur die Technik, sondern auch die Leute modernisieren
Dilemma: Nur Legacy machen ist doof, neues Knowhow ohne Anwendung ist doof
Also graduelles Onboarding, Team für Team
Mit einer klaren Roadmap für Technik und Organisation(!)
Alignment von Technik, Orga und Knowhowaufbau
When it's done: SRE-TEams
Wenn alles läuft uns sich jeder um seinen Kram kümmert ...
... wer kümmert sich um die Verbesserung des ganzen?
die besten Engineers kommen ins SRE-Team
50% Reliability, 50% Verbessserung der internen Prozesse und Dev-Praktiken
Verantwortlich für Error Budgets & Hilfe durch Automatisierung