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: michael.schneegans@amendos.de

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