DevOps
Mitarbeiter im traditionellen IT-Betrieb beim Change
hin zu Agilität und DevOps mitnehmen
Michael Schneegans
itSMF-Jahreskongress, 1. Dezember 2016, Weimar
Inhalt
01 Ausgangssituation
02 „Good Practices“ – 10 Hebel
2
Ausgangssituation
Ausgangssituation
4
Business
Dev(Applikationen)
Ops(Applikationen)
Ops(Infrastruktur)
60 business-kritische Applikationen
global = 24 / 7 / 365
traditionell
heute
Scrum, Kanban
Wasserfall ITILIT gibt vor
Business treibt IT
iSeries
Unix, Windows
Kernproblem
• Organisatorische und räumliche Trennung von Dev und Ops führt zu
Reibungsverlusten
• Schnell entwickelte Software wird zu langsam in den Betrieb überführt:
Continuous Delivery vs. (?) ITIL
• Gegenseitige Schuldzuweisungen bei Incidents
• Keine technische „Streitfrage“ (Docker, Jenkins, …)
5
Organisations- und Kulturproblem
„bottom up“ vs. „top down“
6
Quelle: Niek Bartholomeus: „My experience with introducing DevOps in a traditional enterprise“
„Good Practices“ –
10 Hebel für Bottom Up-Einführung
1. „Brückenbauer“ einsetzen
8
ITIL V3, 2011
Strategy
CSI
Operation
Transition
Design
ITSM
IT-Strategie stützt
Unternehmensstrategie
Kontinuierliche
Verbesserung
Betrieb der IT-Services
Transitionsprojekt
anwenderorientierte
IT-Services entwickeln
Agilität
Design Thinking
PRINCE2Agile
DevOpsKanban
Scrum
Design
Thinking
2. Aufklären
Agile Manifesto
(2001)
übersetzt Heißt NICHT (!!!):
„Individuals and
interactions over
processes and tools.“
„Menschen und ihre
Interaktionen sind wichtiger als
Prozesse und Tools.“
„Es gibt keine
Prozesse und Tools.“
„Working software over
comprehensive
documentation.“
„Funktionierende Software
(analog: Hardware und IT-
Betrieb) ist wichtiger als
umfassende Dokumentation.“
„Es gibt keine
Dokumentation.“
(Im IT-Betrieb nach
wie vor sehr wichtig!)
„Customer
collaboration over
contract negotiation.“
„Zusammenarbeit mit dem
Kunden ist wichtiger als
Vertragsverhandlungen.“
„Es gibt keine Verträge
bzw. SLAs.“
„Responding to change
over following a plan.“
„Eingehen auf Veränderungen
ist wichtiger als das Festhalten
an einem Plan.“
„Es gibt keinen Plan.“
9
3. Eigenes Team mitnehmen
Beispiel: Pair Programming (Operating)
• Eignet sich hervorragend auch für
den Wissenstransfer in IT-
Betriebseinheiten
• Weniger Fehler, geringeres Risiko
• Bessere Resultate, weniger
gedankliche Sackgassen, höhere
Qualität
• Teambildung, mehr Freude an der
Arbeit
• Paare werden seltener
unterbrochen als jemand, der
alleine arbeitet
10
Quelle: Wikipedia
„Pair programming 1“
von Lisamarie Babik - Ted & Ian
Deployment einer UNIX-Software
im Applikationsbetrieb:
UNIX-Admin und iSeries-Admin
4. Selbstorganisation des Teams fördern
Quelle: www.bereally.org
„Wir sind wie Champignons:
Wir leben im dunklen Keller,
man schüttet Kompost auf uns,
und wenn wir den Kopf rausstrecken,
schlägt man ihn ab.“
(O-Ton Ops-Mitarbeiter)
„Zu Champions machen“ = Führungsaufgabe
5. Internes „Marketing“
12
https://agileprojektmanagement.files.wordpress.com/2015/12/kanban-lego.jpg?w=545
6. „Marketing“ Richtung Management
13
Traditionelles Teammeeting:
• 1x pro Woche
• Agenda / Protokoll
• Offizielle Dauer: 2,5 h
Daily Standup Meeting:
• Täglich
• Kanban Board
• Timebox: 15 Minuten
Teammeeting Daily Standup
Teilnehmer 10 10
Dauer pro Woche 2,5 h 5 x 0,25 h = 1,25 h
Vor-/Nachbereitung 0,5 h -
Zeit p.W. insgesamt 10 x 3 h = 30 h 10 x 1,25 h = 12,5 h
Erfüllung Aufgaben mäßig gut
ITSM
7. Ops in Dev integrieren
14
Product
Owner
Scrum
MasterDev-Team
Ops
Vorteile:
• „Raus aus dem RZ, hin zum
Kunden.“
• Zwischenmenschlicher Kontakt
• Besseres gegenseitiges
Verständnis
• Reduktion des Trainings in der
Transition
• Ops-Anforderungen fließen
unmittelbar in Dev ein
8. Organisation neu designen
15
DevEntwicklung
Dev + OpsTransition
OpsBetrieb
DevOpsContinuous Delivery
Request Fulfilment
Event Management
Incident Management
Problem Management
Access Management
Change Management • RfC
• Bewertung (Risiken, Auswirkungen)
• Genehmigung
• Planung
• Umsetzung („4-Augen-Prinzip“)
• Dokumentation
ITIL
ITIL + DevOps
9. Auf eine lange Reise einstellen
16
Quelle: Alex Slale / ccO – gemeinfrei / Unsplash.com
10. Fortlaufend dazulernen
17
ITIL V3, 2011
Strategy
CSI
Operation
Transition
Design
Ausrichtung der
IT (Dev + Ops)
am Business
Thank you for your attention.
Michael Schneegans
Senior Consultant
Phone: +49 (0) 40 248 276 00
E-Mail: [email protected]
amendos gmbh
Frankenstraße 3
20097 Hamburg, Germany
Phone: +49 (0)40 248 276 00
Fax: + 49 (0)40 248 276 01
www.amendos.de