mitarbeiter im traditionellen it-betrieb hin zu agilität ... · pdf filedaily standup...
TRANSCRIPT
DevOps
Mitarbeiter im traditionellen IT-Betrieb
hin zu Agilität führen
Michael Schneegans
Softwareforen Leipzig, User Group „IT-Servicemanagement“, 25./26. April 2017
Inhalt
01Agilität und DevOps als Herausforderung für den
traditionellen IT-Betrieb (Fallbeispiel)
02„Good Practices“ – 10 identifizierte Hebel
(in chronologischer Reihenfolge des Fallbeispiels)
2
Organisatorische Änderungen Mitarbeiter involvieren
Erfolgsfaktoren und Stolpersteine
03 Status Quo „DevOps“ & Ausblick
Agilität und DevOps
Herausforderung für den traditionellen IT-Betrieb
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 identifizierte Hebel für DevOps-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
Status Quo „Devops“ & Ausblick
Worum geht es eigentlich?
19
Time
to think about
DevOps
Es geht um den zufriedenen Kunden!
20
Software mit den neusten Features
im Produktionsbetrieb
Software-Nutzer
Supplier
Business Service
Kunde
Software
entwickeln
(Testsystem)
Software in
Produktion
übernehmen
und betreiben
Dev Ops
IT-Services
ITIL Dev vs. Ops
Es geht um den zufriedenen Kunden!
21
Software mit den neusten Features
im Produktionsbetrieb
Software-Nutzer
Supplier
Business Service
Kunde
Software
entwickeln
(Testsystem)
Software in
Produktion
übernehmen
und betreiben
IT
IT-Services
ITIL ITIL + DevOps
DevOps wird „Mainstream“:
„traditionelle“ Communities
22
DevOps wird „Mainstream“:
Ausbildungen & Zertifizierungen
23
DASA DevOps Qualifizierungsprogramm
DevOps: Fundamentals
Specify and VerifyEnable and Scale Create and Deliver
DevOps: Practitioner
Novice
Master
Compete
nt
Proficient
Expert
5Master
2Competent
3Proficient
4Expert
1Novice
3 Tage
2 Tage
2 Tage 3 Tage2 Tage
mit freundlicher Genehmigung von Dierk Söllner
(trainiert DevOps „From the BACK of the Room“)
www.dsoellner.de
DevOps wird „Mainstream“:
Reifegradmodelle
24
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