{"id":41818,"date":"2020-02-16T20:46:08","date_gmt":"2020-02-16T17:46:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/sem-arhetipov-prevrashheniya-po-princzipam-devops"},"modified":"2020-02-16T20:46:08","modified_gmt":"2020-02-16T17:46:08","slug":"sem-arhetipov-prevrashheniya-po-princzipam-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/sem-arhetipov-prevrashheniya-po-princzipam-devops","title":{"rendered":"Sieben Archetypen der Transformation nach DevOps-Prinzipien","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die Frage \"Wie implementiere ich DevOps?\" stellt sich schon seit einigen Jahren, aber es gibt nicht viele gute Materialien dazu. Manchmal wird man zum Opfer von Werbung durch nicht besonders kluge Berater, die einfach ihre Zeit verkaufen m\u00fcssen, egal wie. Oft sind es schwammige, sehr allgemeine Aussagen dar\u00fcber, wie die Schiffe von Megakonzerne durch das Universum segeln. Das wirft die Frage auf: Was haben wir davon? Sehr geehrter Autor, k\u00f6nnten Sie Ihre Ideen klar und \u00fcbersichtlich in einer Liste formulieren?<\/p>\n

All dies geschieht, weil es nicht viele praktische Erfahrungen und ein echtes Verst\u00e4ndnis f\u00fcr die Ergebnisse von Kulturtransformationen gibt. Ver\u00e4nderungen in der Unternehmenskultur sind langfristige Prozesse, deren Ergebnisse nicht innerhalb einer Woche oder eines Monats sichtbar werden. Wir brauchen jemanden, der ausreichend erfahren ist und gesehen hat, wie Unternehmen \u00fcber viele Jahre hinweg geschaffen und zerst\u00f6rt wurden.<\/p>\n

\"Sieben
\n
\nJohn Willis<\/b> John ist einer der V\u00e4ter des DevOps. Er blickt auf Jahrzehnte der Zusammenarbeit mit einer Vielzahl von Unternehmen zur\u00fcck. In letzter Zeit hat John spezifische Muster entdeckt, die in der Arbeit mit jedem von ihnen auftreten. Mit Hilfe dieser Archetypen weist John Unternehmen den wahren Weg der DevOps-Transformation. Mehr \u00fcber diese Archetypen erfahren Sie in der \u00dcbersetzung seines Vortrags von der DevOops 2018-Konferenz.
\n<\/a><\/noindex>
\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

\u00dcber den Redner:<\/b><\/p>\n

\u00dcber 35 Jahre Erfahrung im IT-Management, Mitbegr\u00fcnder des Vorl\u00e4ufers von OpenCloud bei Canonical, beteiligt an 10 Startups, von denen er zwei an Dell und Docker verkauft hat. Derzeit ist er Vice President of DevOps and Digital Practices bei SJ Technologies.<\/p>\n

Im Folgenden folgt die Erz\u00e4hlung aus Johns Perspektive.<\/b><\/p>\n

Mein Name ist John Willis, und am besten erreichen Sie mich auf Twitter, @botchagalupe<\/a><\/noindex>. Das ist auch mein Pseudonym auf Gmail und GitHub. Und \u00fcber diesen Link<\/a><\/noindex> finden Sie Videoaufzeichnungen meiner Vortr\u00e4ge und die dazugeh\u00f6rigen Pr\u00e4sentationen.<\/p>\n

Ich habe viele Meetings mit CIOs verschiedener gro\u00dfer Unternehmen. Sie klagen oft, dass sie nicht verstehen, was DevOps ist, und dass alle, die versuchen, es ihnen zu erkl\u00e4ren, von etwas ganz anderem sprechen. Eine weitere h\u00e4ufige Beschwerde ist: DevOps funktioniert nicht, obwohl die Direktoren angeblich alles so machen, wie es ihnen erkl\u00e4rt wurde. Dabei handelt es sich um gro\u00dfe Unternehmen, die seit \u00fcber einhundert Jahren existieren. Nachdem ich mit ihnen gesprochen habe, bin ich zu dem Schluss gekommen, dass f\u00fcr viele Probleme nicht hochentwickelte Technologien, sondern relativ einfache L\u00f6sungen am besten geeignet sind. Wochenlang habe ich einfach nur mit Menschen aus verschiedenen Abteilungen gesprochen. Das, was Sie auf dem allerersten Bild in meinem Beitrag sehen, ist mein letztes Projekt; der Raum sah nach drei Tagen Arbeit so aus.<\/p>\n

Was ist DevOps?<\/h2>\n

\nIn der Tat, wenn man 10 verschiedene Personen fragt, werden sie 10 unterschiedliche Antworten geben. Doch das Interessante ist: Alle diese zehn Antworten sind richtig. Es gibt hier keine falsche Antwort. Ich habe mich ziemlich tief mit DevOps besch\u00e4ftigt, etwa seit 10 Jahren, und war der erste Amerikaner beim ersten DevOpsDay. Ich will nicht sagen, dass ich der Kl\u00fcgste unter denjenigen bin, die sich mit DevOps besch\u00e4ftigen, aber wahrscheinlich gibt es niemanden, der so viel Energie darauf verwendet hat. Ich glaube, dass DevOps dann entsteht, wenn menschliches Kapital und Technologie zusammenkommen. Oft vergessen wir das menschliche Element, obwohl wir viel \u00fcber verschiedene Kulturen sprechen. <\/p>\n

\"Sieben
\n
\nAktuell verf\u00fcgen wir \u00fcber eine F\u00fclle von Daten, f\u00fcnf Jahre akademischer Forschung, und die Pr\u00fcfung von Theorien erfolgt in industriellem Ma\u00dfstab. Diese Forschungen zeigen uns Folgendes: Wenn man in der Organisationskultur bestimmte Verhaltensmuster kombiniert, kann man eine 2000-fache Beschleunigung erreichen. Diese Beschleunigung korreliert mit einer \u00e4hnlichen Verbesserung der Stabilit\u00e4t. Dies ist eine quantitative Messung des Vorteils, den DevOps jedem Unternehmen bieten kann. Vor ein paar Jahren sprach ich \u00fcber DevOps mit dem CEO eines Fortune-5000-Unternehmens. Als ich mich auf die Pr\u00e4sentation vorbereitete, war ich sehr nerv\u00f6s, da ich in f\u00fcnf Minuten meine jahrelange Erfahrung darlegen musste. <\/p>\n

Am Ende gab ich folgende Definition von DevOps<\/b>: Es handelt sich um eine Reihe von Praktiken und Mustern, die es erm\u00f6glichen, menschliches Kapital in hochproduktivem organisatorischem Kapital zu verwandeln. Ein Beispiel ist, wie Toyota in den letzten 50 oder 60 Jahren arbeitet.<\/p>\n

\"Sieben
\n
\n(Von hier an werden solche Diagramme nicht als Referenzmaterial, sondern als Illustrationen verwendet. Ihr Inhalt wird sich je nach Unternehmen unterscheiden. Dennoch kann das Bild separat betrachtet und vergr\u00f6\u00dfert werden, \u00fcber diesen Link.)<\/a><\/noindex><\/i><\/p>\n

Eine der erfolgreichsten Praktiken ist die Wertstromanalyse<\/b>. Dar\u00fcber wurden einige gute B\u00fccher geschrieben, das bekannteste von ihnen stammt von Karen Martin. Doch im letzten Jahr bin ich zu dem Schluss gekommen, dass selbst dieser Ansatz zu technologisch ist. Er hat zweifellos viele Vorteile, die ich oft genutzt habe. Aber wenn der CEO fragt, warum sein Unternehmen nicht auf neue Gleise umschwenken kann, ist es noch zu fr\u00fch, \u00fcber Wertstromanalyse zu sprechen. Es gibt viele viel grundlegendere Fragen, auf die man zuvor Antworten finden muss. <\/p>\n

Ich denke, dass der Fehler vieler meiner Kollegen darin liegt, dass sie dem Unternehmen eine Anleitung mit f\u00fcnf Punkten geben und dann nach sechs Monaten zur\u00fcckkommen, um zu sehen, was passiert ist. Selbst bei einem guten Ansatz wie dem Value-Stream-Mapping gibt es, sagen wir mal, blinde Flecken. Nach Hunderten von Interviews mit Gesch\u00e4ftsf\u00fchrern verschiedener Unternehmen habe ich ein bestimmtes Muster entwickelt, das es mir erm\u00f6glicht, das Problem in seine Teile zu zerlegen, und jetzt werden wir jede dieser Komponenten der Reihe nach besprechen. Bevor ich irgendwelche technologischen L\u00f6sungen anwende, benutze ich dieses Muster, und am Ende h\u00e4ngen alle W\u00e4nde voller Diagramme. Neulich arbeitete ich mit einem Investmentfonds und hatte schlie\u00dflich 100-150 solcher Diagramme.<\/p>\n

Schlechte Kultur frisst gute Ans\u00e4tze zum Fr\u00fchst\u00fcck.<\/h2>\n

\nDie Hauptaussage lautet: Keine Lean-, Agile-, SAFE- oder DevOps-Methoden helfen, wenn die Kultur der Organisation schlecht ist. Es ist, als w\u00fcrde man ohne Sauerstoffger\u00e4t in die Tiefe tauchen oder ohne R\u00f6ntgenaufnahme operieren. Anders ausgedr\u00fcckt, um Drucker und Deming umzuformulieren: Eine schlechte Unternehmenskultur wird jedes gute System verschlingen und nicht daran ersticken. <\/p>\n

Um dieses Hauptproblem zu l\u00f6sen, sind folgende Schritte erforderlich:<\/p>\n

    \n
  1. Alle Arbeiten sichtbar machen:<\/b> die gesamte Arbeit muss sichtbar sein. Nicht im Sinne, dass sie unbedingt auf irgendeinem Bildschirm angezeigt werden muss, sondern dass sie beobachtbar sein sollte.<\/li>\n
  2. Arbeitsmanagementsysteme konsolidieren:<\/b> es ist notwendig, die Managementsysteme zu konsolidieren. Im Problem des \"stammesbasierten\" Wissens und des institutionellen Wissens sind in 9 von 10 F\u00e4llen die Engp\u00e4sse die Menschen. In dem Buch \u201ePhoenix Project\u201c<\/a><\/noindex> lag das Problem bei einer einzigen Person, Brent, durch den das Projekt drei Jahre im R\u00fcckstand war. Und solchen \u201eBrents\u201c begegne ich \u00fcberall. Um diese Engp\u00e4sse zu l\u00f6sen, verwende ich die folgenden zwei Punkte in unserer Liste. <\/li>\n
  3. Theorie der Einschr\u00e4nkungen:<\/b> Theorie der Einschr\u00e4nkungen.<\/li>\n
  4. Kollaborations-Hacks:<\/b> Kollaborations-Hacks. <\/li>\n
  5. Toyota Kata (Coaching Kata<\/a><\/noindex>):<\/b> Ich werde nicht viel \u00fcber Toyota Kata sprechen. Falls es dich interessiert, gibt es auf meinem GitHub Pr\u00e4sentationen<\/a><\/noindex> zu fast jedem dieser Themen. <\/li>\n
  6. Marktorientierte Organisation:<\/b> marktorientierte Organisation.<\/li>\n
  7. Shift-left Auditoren:<\/b> Audits in den fr\u00fchen Phasen des Zyklus.<\/li>\n<\/ol>\n

    \"Sieben
    \n
    \nIch beginne die Zusammenarbeit mit einer Organisation ganz einfach: Ich gehe ins Unternehmen und spreche mit den Mitarbeitern. Wie man sieht, sind keine hochmodernen Technologien erforderlich. Alles, was ich brauche, ist ein Ort, an dem ich schreiben kann. Ich versammle mehrere Teams in einem Raum und analysiere, was sie mir aus der Perspektive meiner 7 Archetypen erz\u00e4hlen. Danach gebe ich ihnen einen Marker und bitte sie, alles, was sie bisher laut gesagt haben, schriftlich an die Tafel zu bringen. Normalerweise gibt es bei solchen Treffen eine Person, die alles aufschreibt, und im besten Fall schafft sie es, 10 % der Diskussion festzuhalten. Mit meiner Methode gelingt es, diesen Wert auf etwa 40 % zu steigern. <\/p>\n

    \"Sieben
    \n
    \n(Diese Illustration kann separat     unter diesem Link betrachtet werden<\/a><\/noindex>)<\/i><\/p>\n

    Mein Ansatz basiert auf der Arbeit von William Schneider (William Schneider, The Reengineering Alternative<\/a><\/noindex>). Die Grundlage dieses Ansatzes besteht darin, dass jede Organisation in vier Quadranten zerlegt werden kann. Dieses Diagramm ist in der Regel das Ergebnis von meine Arbeiten mit den vielen anderen Diagrammen, die bei der Analyse einer Organisation entstehen. Nehmen wir an, wir haben eine Organisation mit hohem Kontrollniveau, aber gleichzeitig mit geringer Kompetenz. Dies ist eine \u00e4u\u00dferst unerw\u00fcnschte Variante: Wenn alle nach Vorschrift arbeiten, aber niemand wei\u00df, was zu tun ist. <\/p>\n

    Etwas besser ist die Variante mit hohem Niveau sowohl an Kontrolle als auch an Kompetenz. Sollte ein solches Unternehmen profitabel sein, braucht es m\u00f6glicherweise kein DevOps. Am interessantesten ist die Arbeit mit einem Unternehmen, das ein hohes Ma\u00df an Kontrolle, geringe Kompetenz und Kooperation aufweist, aber gleichzeitig eine hohe Kultur (cultivation) hat. Das bedeutet, dass es in der Firma viele Menschen gibt, die gerne dort arbeiten, und die Fluktuation der Mitarbeiter niedrig ist. <\/p>\n

    \"Sieben
    \n
    \n(Diese Illustration kann separat     unter diesem Link betrachtet werden<\/a><\/noindex>)<\/i><\/p>\n

    Ich glaube, dass Methoden mit strikten Vorgaben letztendlich dabei hindern, die Wahrheit zu finden. Besonders beim Value Stream Mapping gibt es viele Regeln, wie Informationen strukturiert werden m\u00fcssen. In den fr\u00fchen Phasen, von denen ich spreche, sind diese Regeln nicht hilfreich. Wenn jemand mit einem Marker in der Hand eine reale Situation auf einem Board beschreibt, ist das der beste Weg, um sich \u00fcber die aktuellen Gegebenheiten zu informieren. Solche Informationen erreichen die F\u00fchrungskr\u00e4fte nicht. In diesem Moment w\u00e4re es unklug, die Person zu unterbrechen und zu sagen, dass sie einen Pfeil falsch gezeichnet hat. In dieser Phase ist es besser, einfache Regeln zu nutzen, wie zum Beispiel: Eine mehrstufige Abstraktion kann einfach durch die Verwendung von farbigen Markern erstellt werden. <\/p>\n

    Ich wiederhole: keine Hightech. Mit einem schwarzen Marker wird die objektive Realit\u00e4t dargestellt, wie alles funktioniert. Mit einem roten Marker markieren die Leute, was ihnen an der aktuellen Situation nicht gef\u00e4llt. Wichtig ist, dass sie das schreiben und nicht ich. Wenn ich nach dem Meeting zum IT-Direktor gehe, schlage ich nicht eine Liste von 10 Dingen vor, die ge\u00e4ndert werden m\u00fcssen. Ich versuche, Verbindungen zwischen dem, was die Leute im Unternehmen sagen, und den bestehenden, bew\u00e4hrten Mustern zu finden. Schlie\u00dflich werden mit einem blauen Marker m\u00f6gliche L\u00f6sungen f\u00fcr das Problem vorgeschlagen. <\/p>\n

    \"Sieben
    \n
    \n(Diese Illustration kann separat     unter diesem Link betrachtet werden<\/a><\/noindex>)<\/i><\/p>\n

    Ein Beispiel f\u00fcr diesen Ansatz ist oben dargestellt. Zu Beginn dieses Jahres arbeitete ich mit einer Bank. Die Mitarbeiter der Sicherheitsabteilung waren \u00fcberzeugt, dass sie nicht zu \u00dcberpr\u00fcfungen von Anforderungen und Design (design and requirement reviews) kommen d\u00fcrften. <\/p>\n

    \"Sieben
    \n
    \n(Diese Illustration kann separat     unter diesem Link betrachtet werden<\/a><\/noindex>)<\/i><\/p>\n

    Dann sprachen wir mit Menschen aus anderen Abteilungen und fanden heraus, dass etwa vor 8 Jahren Softwareentwickler die Sicherheitsmitarbeiter ausgeschlossen hatten, weil sie die Arbeit verlangsamten. Das f\u00fchrte schlie\u00dflich zu einem Verbot, das als gegeben angesehen wurde. In Wirklichkeit gab es jedoch kein solches Verbot. <\/p>\n

    Unser Treffen verlief \u00e4u\u00dferst verworren: \u00fcber etwa drei Stunden hinweg konnten f\u00fcnf verschiedene Teams mir nicht erkl\u00e4ren, was zwischen dem Code und dem Build vor sich geht. Und das schien doch die einfachste Sache zu sein. Die meisten DevOps-Berater gehen davon aus, dass dies bereits allen bekannt ist. <\/p>\n

    Dann erwachte der Mann, der f\u00fcr die IT-Regulierung zust\u00e4ndig war und vier Stunden lang geschwiegen hatte, pl\u00f6tzlich zum Leben, als wir sein Thema ansprachen, und hielt uns noch eine betr\u00e4chtliche Zeit lang in Anspruch. Am Ende fragte ich ihn, was er \u00fcber das Treffen denkt, und ich werde seine Antwort nie vergessen. Er sagte: \u201eFr\u00fcher dachte ich, es gibt in unserer Bank nur zwei M\u00f6glichkeiten zur Softwarebereitstellung, und jetzt wei\u00df ich, dass es tats\u00e4chlich f\u00fcnf sind, von denen ich bei dreien nicht einmal wusste.\u201c <\/p>\n

    \"Sieben
    \n
    \n(Diese Illustration kann separat     unter diesem Link betrachtet werden<\/a><\/noindex>)<\/i><\/p>\n

    Das letzte Treffen in dieser Bank fand mit dem Team statt, das sich mit Investment-Software besch\u00e4ftigt. Dabei stellte sich heraus, dass es besser ist, Diagramme mit einem Marker auf einem Blatt Papier zu zeichnen, als auf einer Tafel, und sogar besser, als auf einem Smartboard. <\/p>\n

    \"Sieben
    \n
    \nDie Fotos, die Sie sehen, zeigen, wie der Konferenzraum des Hotels am vierten Tag unseres Treffens aussah. Und diese Diagramme verwendeten wir, um Muster, also Archetypen zu finden. <\/p>\n

    Ich stelle also Fragen an die Mitarbeiter, die ihre Antworten mit Markern in drei Farben (schwarz, rot und blau) aufschreiben. Ich analysiere ihre Antworten auf Archetypen. Lassen Sie uns jetzt alle Archetypen der Reihe nach besprechen. <\/p>\n

    1. Make All Work Visible: Die Arbeit sichtbar machen<\/h3>\n

    \nIn den meisten Unternehmen, mit denen ich arbeite, gibt es einen sehr hohen Anteil an unbekannter Arbeit. Zum Beispiel, wenn ein Mitarbeiter den anderen einfach um etwas bittet. In gro\u00dfen Organisationen kann der Anteil an ungeplanter Arbeit bei 60 % liegen. Bis zu 40 % der Arbeit ist nicht dokumentiert. W\u00e4re das Boeing, w\u00fcrde ich nie wieder in einen ihrer Flugzeuge steigen. Wenn nur die H\u00e4lfte der Arbeit dokumentiert wird, ist unklar, ob die Arbeit richtig erledigt wird oder nicht. Alle anderen Methoden erweisen sich als nutzlos \u2014 es hat keinen Sinn, irgendetwas zu automatisieren, weil die bekannten 50 % gerade der am besten abgestimmte und klarste Teil der Arbeit sein k\u00f6nnten, dessen Automatisierung keine gro\u00dfen Ergebnisse liefert, w\u00e4hrend alles Schlimme in der unsichtbaren H\u00e4lfte steckt. Ohne Dokumentation ist es unm\u00f6glich, allerlei Hacks und versteckte Arbeit zu finden oder Engp\u00e4sse, die sogenannten \"Brent-Points\", auf die ich bereits hingewiesen habe. Es gibt ein hervorragendes Buch von Dominica DeGrandis, \"Making Work Visible\"<\/a><\/noindex>. Es identifiziert f\u00fcnf verschiedene \"Zeitdiebe\"<\/b> (thieves of time):<\/p>\n