"You can do DevOps without Agile but you can't do Agile without DevOps" (c) Dr. Bhaskar Ghosh, Accenture

1. Agenda
 Bestandsaufnahme
 Strategie
 Methode
 Analyse
 Lösungskatalog
 Diskussion
1 27.04.2018

2. Bestandsaufnahme Inhouse IT
 Quartals/Jahresziele nicht erreichbar trotz agiler Vorgehensweise
 Betriebsübergang zunehmend komplexer
2 27.04.2018
Bild: AYSO

3. Strategie
 Problemursachen nachvollziehen
 Abstimmbare Vorschläge aus dem Lösungskatalog
 Gemeinsame Festlegung der KPIs
 Umsetzung
 Validierung
3 27.04.2018
Bild: AYSO

4. Methodische Werkzeuge
 Interviews
 Hospitation insb. Sprint Retrospectiven
 Direktmessungen/Datenanalysen wo möglich/sinnvoll
4 27.04.2018
Bild: AYSO

5. Analyse: Der Entwicklungsprozess
 Fachbereiche nahmen nicht regelmäßig an Refinement-Meetings teil
 Fachliche Anforderungen werden oft missverstanden, vage vs. „Eigenleben“
 Rückfragen aus dem Scrum-Team oft zu detailliert für unsere Fachexperten
 Häufig keine stabile Test-Umgebung für Fachleute verfügbar
5 27.04.2018
Bild: El-Tounsy

6. Analyse: Der Betriebsübergang
 Risiken beim Betriebsübergang reduzieren
 Race Condition Betrieb/IT Support im Haus vs. Scrum-Team Support
 Entwickelte Software häufig nicht lauffähig bzw. neue Abhängigkeiten wurden dem
Ops-Team nicht frühzeitig kommuniziert
 Häufig ein Zeitfenster von nur wenigen Stunden für den Betriebsgang, Ops-Team
belastet
6 27.04.2018
Bild: SpaceX

7. Lösungskatalog: organisatorische Maßnahmen
 Bessere Spezifikationen: etablieren eines Scrum-externen Product Owners,
der verantwortlich ist für Einholung, Ausarbeitung und Übergabe sowie
Testbarkeit der Anforderungen langfristig gesehen
 Etablieren der SRE (Site Reliability Engineer) Rolle:
 Bei wachsender Anzahl vom Scrum-Teams ggf. Wechsel zu einem Agile
Framwork (SAFe, DAD..), mehr Analysen erforderlich
7 27.04.2018
“Fundamentally, it’s what happens when
you ask a software engineer to design an
operations function.”
– Niall Murphy, Google

8. Lösungskatalog: technische Maßnahmen
 Transition zur Microservice-Architektur
 Kleinere Komponenten statt Monolit
 Moderne Automation: Infrastructure as Code z.B. Kubernetes
 zur Portabilität der Shop-Lösung
 „Pets vs. Cattle“ oder Scale Up vs. Scale Out
 Zero Downtime mit „Agile delivery team“ Blue-Green Deployment
 Fortgeschrittenes Konzept zur Ablösung von Daten-Migrationen
 Quality Gates Agile „Definition of Done“ formalisieren und mit
automatisiertem Controlling erweitern, etwa Test-Abdeckung, Code-
Qualität – skaliert wenn mehrere technische Komponenten
8 27.04.2018

9. Maßnahme: Microservice-Architektur
 Am häufigsten aktualisierte Funktionen in
eigenständige technische Komponenten
ausgliedern
 Schnellere Lieferung, schnellere Fehlersuche
9 27.04.2018
Bild: Hacker Noon

10. Maßnahme: Infrastructure as Code
 Komplexe Systemadministrations-Vorgänge als
Code erfassen und managen
 Hoher Automations- und
Wiederverwendungsgrad
 Verteilte Systeme automatisch installierbar und
orchestrierbar
10 27.04.2018
--- version: '3.6'
services:
tomcat:
image: tomcat:8.5
replicas: 8
ports:
- „8080:8080“

11. Maßnahme: Blue-Green Deployments
11 27.04.2018
Bild: Martin Fowler

12. Maßnahme: QA-Controlling Automation
12 27.04.2018
Bild: DevOps Toolchain (Wikipedia) Bild: Tiobe

13. Vorschlag für DevOps KPI-Domänen

13 27.04.2018