DevOps. Mitarbeiter im traditionellen IT-Betrieb hin zu Agilität führen. Michael Schneegans

Transkript

1 DevOps Mitarbeiter im traditionellen IT-Betrieb hin zu Agilität führen Michael Schneegans Softwareforen Leipzig, User Group IT-Servicemanagement, 25./26. April 2017

2 Inhalt Agilität und DevOps als Herausforderung für den traditionellen IT-Betrieb (Fallbeispiel) Good Practices 10 identifizierte Hebel (in chronologischer Reihenfolge des Fallbeispiels) Organisatorische Änderungen Mitarbeiter involvieren Erfolgsfaktoren und Stolpersteine 03 Status Quo DevOps & Ausblick 2

3 Agilität und DevOps Herausforderung für den traditionellen IT-Betrieb

4 Ausgangssituation Business Dev (Applikationen) Ops (Applikationen) Ops (Infrastruktur) 60 business-kritische Applikationen global = 24 / 7 / 365 traditionell IT gibt vor Wasserfall ITIL iseries Business treibt IT Scrum, Kanban Unix, Windows heute 4

5 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, ) Organisations- und Kulturproblem 5

6 bottom up vs. top down Quelle: Niek Bartholomeus: My experience with introducing DevOps in a traditional enterprise 6

7 Good Practices 10 identifizierte Hebel für DevOps-Einführung

8 1. Brückenbauer einsetzen Design Thinking IT-Strategie stützt Unternehmensstrategie anwenderorientierte IT-Services entwickeln Strategy Design PRINCE2Agile Transitionsprojekt Transition Scrum Kanban DevOps Betrieb der IT-Services Operation Design Thinking Kontinuierliche Verbesserung CSI Agilität ITSM ITIL V3,

9 2. Aufklären Agile Manifesto (2001) Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. übersetzt Heißt NICHT (!!!): Menschen und ihre Interaktionen sind wichtiger als Prozesse und Tools. Funktionierende Software (analog: Hardware und IT- Betrieb) ist wichtiger als umfassende Dokumentation. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen. Eingehen auf Veränderungen ist wichtiger als das Festhalten an einem Plan. Es gibt keine Prozesse und Tools. Es gibt keine Dokumentation. (Im IT-Betrieb nach wie vor sehr wichtig!) Es gibt keine Verträge bzw. SLAs. Es gibt keinen Plan. 9

10 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 Deployment einer UNIX-Software im Applikationsbetrieb: UNIX-Admin und iseries-admin Quelle: Wikipedia Pair programming 1 von Lisamarie Babik - Ted & Ian 10

11 4. Selbstorganisation des Teams fördern Zu Champions machen = Führungsaufgabe 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) Quelle:

12 5. Internes Marketing 12

13 6. Marketing Richtung Management 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 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 13

14 7. Ops in Dev integrieren Scrum Master Product Owner Dev-Team 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 Ops ITSM 14

15 8. Organisation neu designen Dev Entwicklung Dev + Ops Transition Ops Betrieb ITIL Change Management RfC Bewertung (Risiken, Auswirkungen) Genehmigung Planung Umsetzung ( 4-Augen-Prinzip ) Dokumentation Request Fulfilment Event Management Incident Management Problem Management Access Management ITIL + DevOps DevOps Continuous Delivery 15

16 9. Auf eine lange Reise einstellen Quelle: Alex Slale / cco gemeinfrei / Unsplash.com 16

17 10. Fortlaufend dazulernen Strategy Design Ausrichtung der IT (Dev + Ops) am Business Transition Operation CSI ITIL V3,

18 Status Quo Devops & Ausblick

19 Worum geht es eigentlich? Time to think about DevOps 19

20 Es geht um den zufriedenen Kunden! ITIL Kunde Dev vs. Ops Software-Nutzer Business Service Software mit den neusten Features im Produktionsbetrieb IT-Services Software entwickeln (Testsystem) Software in Produktion übernehmen und betreiben Supplier Dev Ops 20

21 Es geht um den zufriedenen Kunden! ITIL Kunde ITIL + DevOps Software-Nutzer Business Service Software mit den neusten Features im Produktionsbetrieb IT-Services Software entwickeln (Testsystem) Software in Produktion übernehmen und betreiben Supplier IT 21

22 DevOps wird Mainstream : traditionelle Communities 22

23 DevOps wird Mainstream : Ausbildungen & Zertifizierungen DASA DevOps Qualifizierungsprogramm 5 Master Master 4 Expert Expert Enable and Scale 2 Tage Specify and Verify Create and Deliver 2 Tage 3 Tage 3 Proficient Proficient DevOps: Practitioner 2 Tage 2 Compete nt Competent DevOps: Fundamentals 3 Tage 1 Novice Novice 23 mit freundlicher Genehmigung von Dierk Söllner (trainiert DevOps From the BACK of the Room )

24 DevOps wird Mainstream : Reifegradmodelle 24

25 Thank you for your attention. Michael Schneegans Senior Consultant Phone: +49 (0) amendos gmbh Frankenstraße Hamburg, Germany Phone: +49 (0) Fax: + 49 (0)