DevOps: Change Mindset before Toolset
•Als PPTX, PDF herunterladen•
1 gefällt mir•599 views
In diesem Webcast beschäftigen wir uns mit den Werten und Prinzipien der DevOps-Ansätze. Unsere Experten nehmen Stolpersteine sowie Lösungsansätze für die Etablierung von DevOps unter die Lupe. Sie erfahren, was bei einem solchen Change zu beachten ist und welche Vorteile sich schon im Transformationsprozess für Ihre Organisation ergeben können.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (14)
Ähnlich wie DevOps: Change Mindset before Toolset
Ähnlich wie DevOps: Change Mindset before Toolset (20)
Mehr von OPITZ CONSULTING Deutschland
Mehr von OPITZ CONSULTING Deutschland (20)
DevOps: Change Mindset before Toolset
- 1. © OPITZ CONSULTING 2019 Informationsklassifikation: Öffentlich Digitale Service Manufaktur © OPITZ CONSULTING 2019 OC|Webinar Cornelia Spanner, Andreas Lenz & Halil Hancioglu DevOps: Change Mindset before Toolset
- 2. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset Today‘s moderator Andreas Lenz Managing Consultant @ Opitz Consulting Deutschland GmbH @andreas_lenz andreas.lenz@opitz-consulting.com
- 3. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset Bitte beachten Sie… Wir werden Ihnen die Aufzeichnung dieses Webinars sowie die Vortragsfolien in den nächsten Tagen zusenden. Alle Teilnehmer sind stummgeschaltet. Nur so können wir ein störungsfreies Webinar bei großer Personenzahl gewährleisten. Bitte melden Sie sich bei technischen Störungen während des Webinars über die Frage-Funktion an die Organisatoren.
- 4. © OPITZ CONSULTING 2019 Informationsklassifikation: Öffentlich Seite 4 Agenda 1 2 3 4 5 Die Relevanz von DevOps für die Organisation Wie tickt die DevOps Organisation? Mindset before Toolset Die häufigsten Fragen unserer Kunden im Wissens-Ping-Pong Q & A DevOps: Change Mindset before Toolset
- 5. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset Today‘s speakers Cornelia Spanner Senior Consultant @ Opitz Consulting Deutschland GmbH @cospamuc cornelia.spanner@opitz-consulting.com Halil Hancioglu Solution Architect @ Opitz Consulting Deutschland GmbH @satspeedy halil.hancioglu@opitz-consulting.com
- 6. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset Die Relevanz von DevOps für die Organisation Quelle: https://puppet.com/resources/whitepaper/state-of-devops-report Quelle: https://inthecloud.withgoogle.com/state-of-devops-18/dl-cd.html
- 7. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset Performance der Softwarebereitstellung 2018 Quelle: Accelerate: State of DevOps 2018 Teilnehmer in % 7% von High 48% 37 % 15 % Geschwindigkeit Stabilität Messgrößen Elite High Medium Low Deployment- Frequenz On Demand (mehrere Deployments pro Tag) Zwischen einmal pro Stunden und einmal pro Tag Zwischen einmal pro Woche und einmal pro Monat Zwischen einmal pro Woche und einmal pro Monat Durchlaufzeit Weniger als eine Stunde Zwischen einem Tag und einer Woche Zwischen einer Woche und einem Monat Zwischen einem Monat und sechs Monaten Mittlere Wiederher- stellungszeit Weniger als eine Stunde Weniger als ein Tag Weniger als ein Tag Zwischen einer Woche und einem Monat Ausfallrate bei Änderungen in % 0 - 15% 0 - 15% 0 - 15% 46 - 60%
- 8. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset Performance-Metriken Gap zwischen High- & Low-Performern Abstand für alle Performance-Metriken im Vergleich zum Vorjahr vergrößert oder gleich geblieben Stagnation bei Low-Performern deutet auf Schwierigkeiten bei der Bereitstellung hin Verbesserung der Ausfallrate bei Änderungen zeigt Trends für Resilienz auf Durchsatz erhöhen und gleichzeitig die Stabilität verbessern ist möglich Quelle: Accelerate: State of DevOps 2018
- 9. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset Auswirkungen auf Unternehmensperformance Umfrage umfasst Fragen in Hinblick auf Rentabilität, Marktanteile und Produktivität Bereitstellungsperformance wirkt auf Unternehmensperformance High-Performer erreichen Ziele ~1½ mal häufiger als Low-Performer Einführung von DevOps-Praktiken und -Kompetenzen sowohl in Bezug auf die Unternehmensleistung als auch auf die Qualität der Ergebnisse zahlt sich aus. Quelle: Accelerate: State of DevOps 2018 Performance der Softwarebereit- stellung Unternehmens- performance Nicht- kommerzielle Performance z.B. • Betriebliche Effizienz • Kundenzufriedenheit • Qualität & Quantität der Produkte und Services
- 10. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset DevOps Werte: CALMS C | Culture Vertrauenskultur, „Fehlerkultur“ Gemeinsame Verantwortung A | Automation Everything as Code Tools L | Lean Prozessoptimierung Transparenz M | Measurement Qualitätsverbesserung durch Messung S | Sharing Wissen teilen „open Innovation“ Voneinander Lernen Kulturbildung Automatisierung Lean Messung Teilen
- 11. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset Kategorien der Kompetenzen für Verbesserungen Continuous Delivery Architektur Produkt & Prozess Lean Management & Monitoring Kultur
- 12. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset Häufig anzutreffendes Evolutionsmodell 0 - Aufbau des Fundaments • Monitoring inkl. Alerting sind durch das Team, das den Service betreibt konfigurierbar • Deployment Patterns werden geteilt und wiederverwendet • Testverfahren & Patterns werden geteilt und wiederverwendet • Teams tragen zur Verbesserung der von anderen Teams bereitgestellten Werkzeuge bei • Verwaltung von Konfigurationen erfolgt über ein Konfigurationsmanagement-Tool 1 - Normalisierung des Technologie-Stacks • Teams verwenden ein Versionskontrollsystem • Teams deployen auf einem Standard-Set von Betriebssystemen 2 - Standardisierung und Reduzierung der Variabilität • Entwicklung erfolgt basierend auf einem Standardset von Technologien • Bereitstellung auf einem einzigen Betriebssystem 3 - Aufbau der DevOps Praktiken • Deployment Patterns werden geteilt und wiederverwendet • Teammitglieder können ohne manuelle Genehmigung von außerhalb des Teams arbeiten 4 - Automatisierung der Infrastruktur- Bereitstellung • Systemkonfigurationen sind automatisiert • Bereitstellung ist automatisiert 5 - Bereitstellung von Self-Service-Funktionen • Reaktion auf Incidents automatisieren • Ressourcen sind über den Self-Service verfügbar Quelle: State of DevOps Report 2018
- 13. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset “CHANGE” (CC-BY-NC-ND) by Martin Deutsch Und Mindset?
- 14. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset DER MENSCH IM MITTELPUNKT
- 15. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset NUMMI Plant Story Joint Venture aus Toyota & General Motors Toyota Plant System Verschwendung meiden Fehler- / Vertrauenskultur Just-in-time Produktion Hat bei NUMMI funktioniert Teil der Belegschaft war in Japan Sushi-Feste mit gesamter Belegschaft Kultur adaptiert Übertragung auf andere GM-Werke floppte & Quellen: https://www.thisamericanlife.org/403/nummi-2010 https://www.popularmechanics.com/cars/a5514/4350856/
- 16. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset Entscheidungsprämissen Entscheidungsprämissen sind Festlegungen, die den alltäglichen operativen Entscheidungen einer Organisation einen Orientierungsrahmen geben. Programme & Initiativen Prozesse & Strukturen Personen Organisations- kultur Umwelt Entscheidbare Prämissen Nicht entscheidbare Prämissen können explizit entschieden und zielgerichtet umgesetzt werden, im Idealfall in Kombination. können nicht angewiesen werden bzw. zu erwartende Ergebnisse sind nicht vorhersagbar Programme • Projekte, Strategien, Mission Statements,… Informelle Kommunikationswege • Seilschaften, Freundeskreisen, Kaffeeküchenklatsch, ... Prozesse • formale Kommunikationswege, klare Berichtswege Strukturen • Verantwortlichkeiten, Zuständigkeiten, Beziehungen, Organigramme Kultur • Identität, Werte- und Glaubensmuster, Mindsets, implizite Spielregeln, Stories, Rituale, Symbole, … Personen (Kopplungen zw. sozialen u. psychischen Systemen) Niklas Luhmann, 2000
- 17. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset
- 18. © OPITZ CONSULTING 2019 Informationsklassifikation: Öffentlich Phase Beschreibung Beispiele Responsibility | Verantwortung Man hat die Fähigkeit und Kraft, selbst zu wählen, um Leben und Umfeld aktiv und wirkungsvoll zu gestalten Auslieferungsstrang hat höchste Priorität OnDemand Self-Service-Umgebung Quit | Innere Kündigung Man gibt auf, um “shame” oder “obligation” zu entfliehen „DevOps ist doch eh eine Utopie“ Obligation | Verpflichtung Man handelt, weil es getan werden muss (nicht freiwillig) „Dann bringen wir uns eben früh ein und klären 2nd Level Anforderungen direkt zu Projektstart.“ Shame | Schämen Sich selbst die Schuld geben “Ich weiß, dass ich schon zum vierten Mal verpasst habe, xyz zu tun.” Justify | Rechtfertigen Den Umständen die Schuld geben „But it works on my machine!“ Lay Blame | Beschuldigen Anderen die Schuld geben „Hey, hier fehlt komplett das Logging, das habt ihr vergessen!“ Denial | Leugnen Existenz einer Sache leugnen oder ignorieren „Releases sind halt eine komplexe Angelegenheit!“ Responsibility Process Christopher Avery DevOps: Change Mindset before Toolset
- 19. © OPITZ CONSULTING 2019 Informationsklassifikation: Öffentlich Change-Formel Die Change-Formel besagt, wo die Energie für die Veränderung herkommt. Die Formel besagt: Energie für Veränderung (E) entsteht, wenn es folgende Faktoren gibt: ein gemeinsames Verständnis der Notwendigkeit der Veränderung (Driver = D) ein gemeinsames Bild einer gewünschten Zukunft / Vision (V) ein Bewusstsein der vorhandenen Ressourcen, Stärken und Qualitäten (R) und Ideen für die ersten Schritte und Maßnahmen (First Steps = F) Ruth Seliger DevOps: Change Mindset before Toolset Change-Formel: D x V x R x F = E
- 20. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset Wissens-Ping-Pong “Ping Pong ~ Table Tennis” (CC-BY) by Dustin Gaffke
- 21. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset Q & A "question mark" (CC-BY-SA) by Karen Eliot
- 22. © OPITZ CONSULTING 2019 Informationsklassifikation: ÖffentlichDevOps: Change Mindset before Toolset Weiterführendes OpenDevStack Webinar 10.10.2019 www.opitz- consulting.com/webinar- opendevstack Continuous Lifecycle 2019 12.11.2019 DevOps-Discovery- Workshop mit LEGO & Schokolade IT-Tage 2019 09.12.2019 DevOps? Eine Entdeckungstour mit Lego & Schokolade
- 23. © OPITZ CONSULTING 2019 Informationsklassifikation: Öffentlich Digitale Service Manufaktur @OC_WIRE OPITZCONSULTING opitzconsultingWWW.OPITZ-CONSULTING.COM “Change mindset before toolset.” Cornelia Spanner Senior Consultant DevOps Expertin cornelia.spanner@ opitz-consulting.com +49 173 727 9572 Melanie Deutschmann Change Coach & Organisationsentwicklerin melanie.deutschmann@ opitz-consulting.com +49 151 4146 39 00 DevOps: Change Mindset before Toolset Halil Hancioglu Solution Architect DevOps Experte halil.hancioglu@ opitz-consulting.com +49 173 727 9311 Alle Bilder von https://www.flickr.com entnommen. Weitere Fragen: Gerne per E-Mail an events@opitz-consulting.com
Hinweis der Redaktion
- Zu Beginn ein paar Worte zu mir selbst… Conny: Senior Developer & DevOps Community Member Fokussiert auf Architektur, DevOps, Organisationskultur… Halil: Solution Architect & DevOps Community Member Fokussiert auf Architektur, DevOps & CI/CD, Agile, Lean, Integration
- Die Relevanz von DevOps für die Organisation: Welche Chancen und Risiken birgen DevOps-Ansätze für das Geschäft? Wie tickt die DevOps Organisation? DevOps-Werte und das Evolutionsmodell Mindset before Toolset: Wie Sie Organisation und Mitarbeiter mitnehmen Die häufigsten Fragen unserer Kunden im Wissens-Ping-Pong Q&A Punkt 1 und 2 wird von Halil präsentiert Punkt 3 wird von Conny präsentiert Punkt 4 und 5 diskutieren beide gemeinsam
- Conny: Senior Developer & DevOps Community Member Fokussiert auf Architektur, DevOps, Organisationskultur… Halil: Solution Architect & DevOps Community Member Fokussiert auf Architektur, DevOps & CI/CD, Agile, Lean, Integration
- AGENDA: Die Relevanz von DevOps für die Organisation Worum geht es: Welche Chancen und Risiken birgen DevOps-Ansätze für das Geschäft? 8 Min. 2012 gab es den ersten DevOps Research von Puppet Seit den darauffolgenden Jahren wird jährlich das State of DevOps Report veröffentlicht, welches Daten von Umfragen über diverse Kanäle zusammenfassend darstellt Die Veröffentlichung wurde von dem Puppet Team und dem DevOps Research and Assessment (DORA) Team bis zum Jahr 2018 durchgeführt. Die Gründer von DORA sind Nicole Forsgren, Gene Kim und Jez Humble Die Entstehung kam aus der Neugier heraus, zu verstehen wie überlegene technische Performance möglich ist und was zu einer ausgezeichneten Softwarebereitstellung beiträgt Bedeutet, es wird geforscht welche Kompetenzen und Praktiken für Entwicklung und Bereitstellung von Software am wichtigsten sind. Betrachtung in Hinblick auf Rentabilität, Produktivität und Marktanteile und auch Betrachtung von nicht-kommerziellen Auswirkungen wie Effektivität, Effizienz und Kundenzufriedenheit. Das Ziel: Verstehen, was zu einer Verbesserung der Softwareperformance und der Unternehmensleistung führt. Unterstützung der IT Branche durch zur Verfügungstellung der Informationen, um die Kompetenzen zu identifizieren und zu verstehen, die tatsächlich Leistungsverbesserungen bewirken. Die Mittel: Mittels wissenschaftlicher Forschungsmethoden - solche Methoden werden auch in anderen Bereichen angewandt, um Zusammenhänge zu verstehen Mehr als 30.000 Umfrageantworten aus der ganzen Welt Mehr als 2000 Unternehmen verschiedenster Größe und Branche Von Legacy bis Greenfield Projekten alle dabei Ergebnisse sind unabhängig von der Vorgehensmethodik „Wasserfall“ oder „Agile“. Fokus ist auf Softwarebereitstellung. Die Besonderheit in 2018 war, dass diesmal zwei Reports veröffentlich wurden. Zum einen von Puppet mit weiteren Partnern und zum anderen von DORA mit insbesondere Google als Partner. Im State of DevOps Report 2018 von Puppet wurden insbesondere neue Erkenntnisse beim Verständnis der evolutionären Reise von DevOps aufgesammelt. Dazu zählen die die fünf verschiedenen Phasen des Evolutionsmodell einer DevOps-Reise Im Accelerate State of DevOps 2018 von DORA & Google wurden die Auswirkungen von der Cloud-Etabilierung, der Einsatz von Open-Source-Software, organisatorische Praktiken (einschließlich Outsourcing) und Kultur auf die Softwarebereitstellungsleistung haben untersucht.
- Oben drüber sieht man nochmal den prozentualen Anteil ein Teilnehmer je Gruppe. Primär werden zur Messung der Performance der Softwarebereitstellung die zwei Faktoren verwendet: Geschwindigkeit (Throughput) und Stabilität (Stability). Fokus liegt auf Ergebnismessung, nicht auf Leistungsmessung Hierzu werden für jedes die folgenden Messgrößen Deployment-Frequenz: Wie häufig deployed ihre Organisation den Code auf die produktive Umgebung, bezogen auf die Applikation an der der Sie arbeiten Durchlaufzeit: Wie lange dauert die Durchlaufzeit für Änderungen an der primären Anwendung oder dem primären Dienst, an der Sie arbeiten (d.h. wie lange dauert es, bis der Code vom Code Commit zum erfolgreich in der Produktion laufenden Code übergeht)? Mittlere Wiederherstellungszeit: Wie lange dauert es für die primäre Anwendung oder den Service, an der Sie arbeiten, im Allgemeinen, um den Service wiederherzustellen, wenn ein Servicefall eintritt (z.B. ungeplanter Ausfall, Beeinträchtigung des Service)? Ausfallrate bei Änderungen: Welcher Prozentsatz der Änderungen führt bei der primären Anwendung oder dem primären Dienst, an dem Sie arbeiten, entweder zu einer Verschlechterung des Dienstes oder muss anschließend korrigiert werden (z.B. führt dies zu Serviceeinschränkungen, Serviceausfällen, erfordert einen Hotfix, Rollback, Fix Forward, Patch)? Neu hinzugekommen sind die Elite-Performer. Repräsentieren ein Teil der High-Performer und setzen neue Maßstäbe Diese neue Kategorie gibt es für zwei Gründe. High-Performer Gruppe wächst und expandiert, was auf die Gesamtheit der die Industrie betrachtet die Softwareentwicklung und Lieferpraktiken verbessert. Messlatte für Exzellenz wird in der gesamten Branche weiterentwickelt, mit den leistungsstärksten Unternehmen noch immer Durchsatz und Stabilität optimieren. Auffällig ist, dass Medium-Performer in Sachen Stabilität gut abschneiden (auf Augenhöhe mit den High Performern), fallen aber in Sachen Geschwindigkeit zurück -> Hinweise auf Kompromisse Dahingegen haben Low-Performer mit erheblichen Stabilitätsproblemen zu kämpfen: Ausfallraten von über 50% sind bereits kritisch zu sehen Wie erwartet und in Übereinstimmung mit den Vorjahren hinken Low-Performer erneut allen Gruppen in allen Aspekten der Leistung hinterher Backup Deployment-Frequenz: High 1,460 deploys pro Jahr (4 * pro Tag * 365) – Low 32 deploys pro Jahr Durchlaufzeit: <=60 minutes für Elite-Performers – Low 26940 Minuten Mittlere Wiederher-stellungszeit: High 168 Stunden – Low 5040 Stunden Ausfallrate bei Änderungen: Konkrete liegt es bei den Elite bei ca. 7,5 % und bei Low 53%
- Das Diagramm auf der rechten Seite zeigt den Gap zwischen High- & Low-Performern pro Jahr Generell ist der Abstand für alle Performance-Metriken im Vergleich zum Vorjahr größer geworden oder blieb gleich Der größer werdende Abstand deutet auch auf eine Leistungsstagnation bei Low-Performern hin Gründe hierfür können möglicherweise die zunehmende Komplexität von Systemen sein und damit auch die Schwierigkeiten bei der Bereitstellung von Software Verbesserung der Ausfallrate bei Änderungen zeigt auf, dass es einen Trend zum Entwurf resilienter Systeme und bessere Beherrschbarkeit komplexer Systeme gibt. Die Erwartungen von Instabilitäten werden eingeplant. High-Performer haben 46 Mal häufiger als andere Unternehmen ihre Software released und ihre Fehlerrate bei Änderungen um den Faktor 7 reduziert Darüber hinaus, wird auch hier nochmal deutlich, dass die kontinuierliche Verbesserung bei High-Performern adaptiert ist und diese somit robuster gegen Technologie-Wellen sind Ergebnis der Clusteranalyse: Durchsatz erhöhen und gleichzeitig die Stabilität des Systems verbessern ist möglich. Folglich kann auch gesagt werden, dass sich Durchsatz und Stabilität gegenseitig enablen Der Aha-Effekt ist, dass keine Kompromiss zwischen Geschwindigkeit und Stabilität eingegangen werden muss Wichtig dabei ist, dass auf Qualität geachtet wird! Denn die Qualität ist entscheidend für Beide: Geschwindigkeit und Stabilität!
- Ok, nun schauen wir uns an, in wie weit die Bereitstellungsperformance sich auf die Unternehmensperformance einwirkt In der selben Umfrage werden auch Fragen in Hinblick auf Rentabilität, Marktanteile und Produktivität gestellt, um sehen zu können ob es Zusammenhänge zwischen Performance der Softwarebereitstellung und Unternehmensperformance deutlich werden Diese korrelieren auch mit der Kapitalrendite (ROI) Deutlich wird, dass High-Performer Ihre Ziele ~1,45 mal häufiger erreichen als Low-Performer Bedeutet, dass Aktivitäten zur Steigerung der Bereitstellungsperformance, tatsächlich einen Wettbewerbsvorteil für Sie in Ihrer Branche darstellen kann Heutzutage ist die Software der Motor zur Beschleunigung von Unternehmen Es zeigt, dass sich die Implementierung von DevOps-Praktiken und -Fähigkeiten bei Technologietransformationen sowohl in Bezug auf die Unternehmensleistung als auch auf die Qualität der Ergebnisse auszahlt. BACKUP Von Jahr zu Jahr nehmen immer mehr DevOps‘ler an der Umfrage teil Low-Perform tun sich damit schwer, den Anschluss zu finden Gravierende Unterschiede zeigen sich zwischen Low und High-Performern auf Wohingegen der eine sich deutlich weiterentwickelt, stagniert es bei den Low-Performern Systeme werden aber immer komplexer und somit auch die Ausfälle kritischer Dies könnte eine Herausforderung bei der Bereitstellung darstellen Alle Unternehmenstypen und Branchen sind vertreten Branchenunabhängigkeit sticht hervor - Teams in Elite, High, Medium und Low Performer klassifiziert, existieren in allen Unternehmenstypen und Branchen Messen der Softwarebereitstellung und verbessern ist für jeden möglich, solange die Führung kontinuierliche Unterstützung bietet – wie Zeit, Aktivitäten und Ressourcen, eine wahrhafte Verpflichtung zur Verbesserung demonstriert und die Teammitglieder sich ebenfalls der Arbeit verpflichtet fühlen.
- Wie tickt die DevOps Organisation? DevOps-Werte und das Evolutionsmodell 10 Min.
- Es gibt 24 Schlüsselkompetenzen, die zur Verbesserung bei der Performance der Softwarebereitstellung wirken. Diese Übersicht zeigt die Kategorien der Kompetenzen auf. Die Kompetenzen sind in keiner besonderen Reihenfolge aufgeführt. Continuous Delivery Versionsverwaltung Deployment Automatisierung Continuous Integration Trunk-basierte Entwicklung Testautomatisierung Testdatenmanagement Shift Left zur Sicherheit Continuous Delivery (CD) Architektur Architektur mit loser Kopplung Eigenverantwortliche Teams Produkt und Prozess Kundenfeedback Wertstrom In kleinen Losgrößen/Batchsizes arbeiten Teamexperimente Lean Management und Monitoring Verfahren für Änderungsgenehmigungen Monitoring Proaktive Benachrichtigung Limitierung der laufenden Arbeit (WIP) Arbeit visualisieren Kultur Unternehmenskultur nach Westrum Lernen unterstützen Zusammenarbeit zwischen den Teams Jobzufriedenheit Transformationale Führung Bildquellen: Quelle: https://www.auto-medienportal.net/artikel/detail/12948
- Das Evolutionsmodell wurde im State of DevOps Report 2018 veröffentlicht und sehr detailliert beschrieben. Es zeigt auf Basis der Umfrage aus, wie Unternehmen ihre Praktiken im Laufe der Zeit weiterentwickeln Jede Phase wird durch zwei Schlüsselpraktiken definiert Darüber hinaus gibt es Praktiken in jeder Phase die am meisten zum Erfolg beitragen - genannt "Contributors to Success“. Diese sind allerdings hier nicht aufgeführt. 0 – Ist wiederkehrend 1 - Reduzierung der Komplexität 2 – Standardisierung von Technologien 3 - Befähigung von Teams 4 - Infrastruktur-automatisierung 5 - Self-Services Tatsächlich wird wenig bemerkbar, bis vor Stage 4. Und alles vor Stage 4 ist der schwierigere Teil. Stage 0 ist wiederkehrend und reift von jeder Stage zum Stage weiter.
- OK! Nun haben wir sehr viel über DevOps Praktiken und Kompetenzen gesprochen, doch viel wichtiger ist eigentlich der Mindset Change Aspekt hierfür. Um Ihnen auch hierzu einiges vorzustellen, übergebe ich nun an meine Kollegin Conny.
- Wie Sie Organisation und Mitarbeiter mitnehmen (15 Min.) Cultural Change Responsibility Process (Avery Model) „Change Formel“ hervorheben Leute mitnehmen -> Zusammensetzen reicht nicht aus, jeder hat seinen Elefanten -> Menschen im Fokus -> Stichwort: Elephant in the room! Darum „Mindset before Toolset“ – Wie ticken wir? Change
- Toyota wollte in den amerikanischen Markt GM wolle eines seiner „schlechtesten“ Werke aufbessern TPS adaptieren Hat bei NUMMI geklappt, bei allen anderen GM Werken aber nicht
- Es stellt sich die Frage, wie ein Cultural-Change angegangen werden kann => Neuwaldegger Dreieck beschreibt 3 Faktoren, die Kultur von außen beeinflusst. Kultur = Blackbox => ist nicht vorhersagbar, folgt keiner Wenn-Dann Logik Faktor Mensch sehr wichtig => Mensch im Mittelpunkt, Menschen mitnehmen bei einem Change
- 5 Themengebiete (konkrete Beispiele) was man bei einem Cultural Change in DevOps Bereich im Auge haben muss.
- Menschen müssen Verantwortung übernehmen (siehe Vertrauenskultur). Um Verantwortung übernehmen zu können, muss man sich aber bewusst machen, was dies bedeutet. Avery beschreibt diesen Prozess mit unterschiedlichen mentalen Zuständen
- zB kein gemeinsames Ziel -> es ist nicht klar für das Team und der Change wird nicht erfolgreich sein. Kreis schließen zum Anfang: Menschen mitnehmen, gemeinsames Ziel haben
- Wissens-Ping-Pong Die häufigsten Fragen unserer Kunden vorab geclusterred werden hier im Wissens-Ping-Pong erläutert und diskutiert (8 Min.)
- Q&A Zuhörer dürfen Fragen stellen (10 Min.)
- Und auch eine 2 Tätige Schulung rundum DevOps Prinzipien am 07-08.11.2019 Schulung in Gummersbach