{"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 den Prinzipien von DevOps.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die Frage, wie man DevOps bei sich selbst implementiert, besteht schon seit Jahren, aber es gibt nicht allzu viele gute Materialien dazu. Manchmal wird man Opfer von Werbung durch weniger kluge Berater, die nur ihre Zeit verkaufen wollen, egal wie. Manchmal handelt es sich um vage und \u00e4u\u00dferst allgemeine Aussagen dar\u00fcber, wie die Schiffe von Megakonzernen durch das Universum segeln. Die Frage ist: Was haben wir davon? Sehr geehrter Autor, k\u00f6nnten Sie Ihre Ideen bitte klar in einer Liste formulieren?<\/p>\n

Das liegt daran, dass es nicht viel praktische Erfahrung und Verst\u00e4ndnis f\u00fcr die Ergebnisse der transformativen Kulturver\u00e4nderungen gibt. Ver\u00e4nderungen in der Unternehmenskultur sind langfristige Prozesse, deren Ergebnisse nicht in einer Woche oder einem Monat sichtbar werden. Wir ben\u00f6tigen jemanden mit genug Erfahrung, der gesehen hat, wie Unternehmen \u00fcber viele Jahre hinweg gegr\u00fcndet und wieder zerst\u00f6rt wurden.<\/p>\n

\"Sieben
\n
\nJohn Willis<\/b> ist einer der V\u00e4ter von DevOps. John kann auf jahrzehntelange Erfahrung mit einer Vielzahl von Unternehmen zur\u00fcckblicken. In letzter Zeit hat John spezifische Muster festgestellt, die in der Zusammenarbeit mit jedem einzelnen Unternehmen auftreten. Mit diesen Archetypen leitet John Unternehmen auf den wahren Weg der DevOps-Transformation. Mehr \u00fcber diese Archetypen finden 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 Vorg\u00e4ngers von OpenCloud bei Canonical, beteiligte sich an 10 Startups, von denen zwei an Dell und Docker verkauft wurden. Derzeit ist er Vice President of DevOps and Digital Practices bei SJ Technologies.<\/p>\n

Nun folgt die Erz\u00e4hlung aus der Perspektive von John.<\/b><\/p>\n

Mein Name ist John Willis, und man kann mich am einfachsten auf Twitter erreichen, @botchagalupe<\/a><\/noindex>. Den gleichen Nickname benutze ich bei Gmail und GitHub. Au\u00dferdem \u00fcber diesen Link<\/a><\/noindex> k\u00f6nnen Sie Videomitschnitte meiner Vortr\u00e4ge und die entsprechenden Pr\u00e4sentationen dazu finden.<\/p>\n

Ich habe viele Meetings mit CIOs verschiedener gro\u00dfer Unternehmen. Sie beschweren sich sehr oft, dass sie nicht verstehen, was DevOps ist, und alle, die es ihnen erkl\u00e4ren m\u00f6chten, sprechen \u00fcber etwas ganz anderes. Eine weitere h\u00e4ufige Beschwerde ist, dass DevOps nicht funktioniert, obwohl die Direktoren scheinbar alles tun, was ihnen erkl\u00e4rt wurde. Es handelt sich um gro\u00dfe Unternehmen, die seit \u00fcber einhundert Jahren bestehen. Nach Gespr\u00e4chen mit ihnen kam ich zu dem Schluss, dass f\u00fcr viele Probleme nicht die Hochtechnologien, sondern relativ niedrigtechnologische L\u00f6sungen am besten geeignet sind. Wochenlang habe ich einfach mit Menschen aus verschiedenen Abteilungen kommuniziert. Das, was Sie auf dem allerersten Bild im Post sehen \u2014 mein letztes Projekt, der Raum sah nach drei Tagen Arbeit so aus.<\/p>\n

Was ist DevOps?<\/h2>\n

\nTats\u00e4chlich, wenn man 10 verschiedene Personen fragt, werden sie 10 verschiedene Antworten geben. Aber das Interessante ist: Alle zehn Antworten werden richtig sein. Es gibt hier keine falsche Antwort. Ich besch\u00e4ftige mich schon seit etwa 10 Jahren intensiv mit DevOps, war der erste Amerikaner beim ersten DevOpsDay. Ich will nicht sagen, dass ich kl\u00fcger bin als all jene, die sich mit DevOps besch\u00e4ftigen, aber es ist kaum jemand da, der so viel M\u00fche und Kraft investiert hat. Ich denke, DevOps entsteht, wenn menschliches Kapital und Technologie aufeinandertreffen. Oft vergessen wir die menschliche Dimension, obwohl wir viel \u00fcber verschiedene Kulturen sprechen. <\/p>\n

\"Sieben
\n
\nHeute haben wir viele Daten, f\u00fcnf Jahre akademische Forschung, und die \u00dcberpr\u00fcfung der Theorien ist im industriellen Ma\u00dfstab etabliert. Diese Studien zeigen uns Folgendes: Wenn man in der Unternehmenskultur bestimmte Verhaltensmuster kombiniert, kann man eine 2000-fache Beschleunigung erreichen. Diese Beschleunigung entspricht einer \u00e4hnlichen Verbesserung in der Stabilit\u00e4t. Dies ist eine quantitative Messung des Vorteils, den DevOps jedem Unternehmen bieten kann. Vor ein paar Jahren erz\u00e4hlte ich einem CEO eines Fortune 5000-Unternehmens von DevOps. Als ich mich auf die Pr\u00e4sentation vorbereitete, war ich sehr nerv\u00f6s, weil ich in 5 Minuten meine jahrelange Erfahrung pr\u00e4sentieren musste. <\/p>\n

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

\"Sieben
\n
\n(Diese und weitere Diagramme sind nicht als Referenzmaterial gedacht, sondern zur Veranschaulichung. Ihr Inhalt wird f\u00fcr jedes neue Unternehmen unterschiedlich sein. Dennoch kann das Bild separat betrachtet und vergr\u00f6\u00dfert werden \u00fcber diesen Link.)<\/a><\/noindex><\/i><\/p>\n

Eine der erfolgreichsten Praktiken ist Value Stream Mapping<\/b>. Dazu sind mehrere gute B\u00fccher geschrieben worden, das bekannteste 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 Gesch\u00e4ftsf\u00fchrer fragt, warum sein Unternehmen nicht auf neue Gleise wechseln kann, ist es noch zu fr\u00fch, \u00fcber Value Stream Mapping 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 besteht, dass sie dem Unternehmen einfach eine Anleitung mit f\u00fcnf Punkten geben und dann nach sechs Monaten zur\u00fcckkommen, um zu sehen, was passiert ist. Selbst ein gutes Diagramm wie Value Stream Mapping hat, sagen wir, blinde Flecken. Nach Hunderten von Interviews mit Direktoren verschiedener Unternehmen habe ich ein bestimmtes Muster entwickelt, das es erm\u00f6glicht, das Problem in seine Komponenten 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. K\u00fcrzlich habe ich mit einem Investmentfonds gearbeitet, und am Ende hatte ich 100-150 solcher Diagramme.<\/p>\n

Eine schlechte Kultur isst gute Ans\u00e4tze zum Fr\u00fchst\u00fcck.<\/h2>\n

\nDie Hauptbotschaft ist folgende: Lean, Agile, SAFE und DevOps helfen nicht, wenn die Kultur der Organisation schlecht ist. Es ist so, als w\u00fcrde man in die Tiefe ohne Tauchausr\u00fcstung eintauchen oder ohne R\u00f6ntgenaufnahme operieren. Anders ausgedr\u00fcckt, um Peter Drucker und W. Edwards Deming umzuformulieren: Eine schlechte Unternehmenskultur wird jedes gute System verschlingen und dabei nicht einmal schlucken. <\/p>\n

Um dieses Hauptproblem zu l\u00f6sen, m\u00fcssen folgende Schritte unternommen werden:<\/p>\n

    \n
  1. Aller Arbeit Sichtbarkeit verleihen:<\/b> wir m\u00fcssen die gesamte Arbeit sichtbar machen. Nicht im Sinne, dass sie unbedingt auf einem Bildschirm angezeigt werden muss, sondern in dem Sinne, dass sie beobachtbar sein sollte.<\/li>\n
  2. Arbeitsmanagementsysteme konsolidieren:<\/b> Es ist notwendig, die Managementsysteme zu konsolidieren. Bei dem Problem des \u201etribalen\u201c 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 genau einer einzigen Person, Brent, der daf\u00fcr sorgte, dass das Projekt drei Jahre im Verzug war. Und auf solche \u201eBrents\u201c sto\u00dfe ich \u00fcberall. Um diese Engp\u00e4sse zu l\u00f6sen, verwende ich die folgenden zwei Punkte aus unserer Liste. <\/li>\n
  3. Theorie der Einschr\u00e4nkungen Methodologie:<\/b> Theorie der Einschr\u00e4nkungen.<\/li>\n
  4. Zusammenarbeits-Hacks:<\/b> Hacks zur Zusammenarbeit. <\/li>\n
  5. Toyota Kata (Coaching Kata<\/a><\/noindex>):<\/b> \u00fcber Toyota Kata werde ich nicht viel sagen. Wenn 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-Pr\u00fcfer:<\/b> Pr\u00fcfungen in fr\u00fchen Phasen des Zyklus.<\/li>\n<\/ol>\n

    \"Sieben
    \n
    \nIch beginne meine Arbeit mit der Organisation ganz einfach: Ich gehe ins Unternehmen und spreche mit den Mitarbeitern. Wie wir sehen, sind keine Hochtechnologien erforderlich. Alles, was ben\u00f6tigt wird, ist etwas, um darauf zu schreiben. Ich versammle mehrere Teams in einem Raum und analysiere, was sie mir sagen, aus der Perspektive meiner 7 Archetypen. Dann gebe ich ihnen einen Marker und bitte sie, alles, was sie bis jetzt laut gesagt haben, schriftlich an die Tafel zu bringen. Normalerweise gibt es bei solchen Treffen eine Person, die alles aufschreibt, und im besten Fall kann sie 10 % der Diskussion festhalten. Bei meiner Methode gelingt es, diesen Wert auf etwa 40 % zu steigern. <\/p>\n

    \"Sieben
    \n
    \n(Diese Illustration kann     unter dem Link<\/a><\/noindex>)<\/i><\/p>\n

    Mein Ansatz basiert auf der Arbeit von William Schneider (William Schneider, The Reengineering Alternative<\/a><\/noindex>). Der Ansatz beruht auf der Idee, dass jede Organisation in vier Quadranten zerlegt werden kann. Dieses Schema ist in der Regel das Ergebnis meiner Arbeit mit den hunderten anderen Diagrammen, die bei der Analyse der Organisation entstehen. Nehmen wir an, wir haben eine Organisation mit hohem Kontrollniveau, aber gleichzeitig mit niedriger Kompetenz. Das ist eine \u00e4u\u00dferst unerw\u00fcnschte Situation: Wenn alle in einer Reihe gehen, aber niemand wei\u00df, was zu tun ist. <\/p>\n

    Eine deutlich bessere Variante mit hohem Ma\u00df an Kontrolle und Kompetenz. Wenn ein Unternehmen profitabel ist, ben\u00f6tigt es m\u00f6glicherweise DevOps nicht. Am interessantesten ist die Zusammenarbeit mit einem Unternehmen, das einen hohen Kontrollgrad, niedrige Kompetenz und Kooperation aufweist, aber gleichzeitig eine hohe Kultur (cultivation) pflegt. Das bedeutet, dass es im Unternehmen viele Leute gibt, die gerne dort arbeiten und die Fluktuation gering ist. <\/p>\n

    \"Sieben
    \n
    \n(Diese Illustration kann     unter dem Link<\/a><\/noindex>)<\/i><\/p>\n

    Ich denke, dass Methoden mit strengen Vorgaben letztendlich der Wahrheit im Wege stehen. Insbesondere im Value Stream Mapping gibt es viele Regeln, wie Informationen strukturiert werden m\u00fcssen. In den fr\u00fchen Phasen der Arbeit, von denen ich spreche, sind diese Regeln niemandem von Nutzen. Wenn eine Person mit einem Marker in der Hand die tats\u00e4chliche Situation im Unternehmen an die Tafel beschreibt, ist das der beste Weg, um zu verstehen, wie der Stand der Dinge ist. Solche Informationen erreichen die Direktoren nicht. In diesem Moment w\u00e4re es dumm, die Person zu unterbrechen und zu sagen, dass sie einen Pfeil falsch gezeichnet hat. In dieser Phase ist es besser, einfache Regeln zu verwenden, zum Beispiel: Eine mehrstufige Abstraktion kann einfach erstellt werden, indem man verschiedene Marker in unterschiedlichen Farben verwendet. <\/p>\n

    Ich wiederhole, keine Hochtechnologie. Mit einem schwarzen Marker wird die objektive Realit\u00e4t dargestellt, wie alles funktioniert. Mit einem roten Marker kennzeichnen die Menschen, was ihnen an der bestehenden Situation nicht gef\u00e4llt. Wichtig ist, dass sie es schreiben und nicht ich. Wenn ich nach dem Meeting zu dem IT-Direktor gehe, biete ich keine Liste mit 10 Dingen an, die verbessert werden m\u00fcssen. Ich versuche, Verbindungen zwischen dem, was die Menschen im Unternehmen sagen, und 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     unter dem Link<\/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 aus der Sicherheitsabteilung waren \u00fcberzeugt, dass sie nicht zu den Pr\u00fcfungen der Anforderungen und des Designs (design and requirement reviews) kommen d\u00fcrften. <\/p>\n

    \"Sieben
    \n
    \n(Diese Illustration kann     unter dem Link<\/a><\/noindex>)<\/i><\/p>\n

    Dann sprachen wir mit Mitarbeitern aus anderen Abteilungen und fanden heraus, dass vor etwa 8 Jahren die Softwareentwickler die Sicherheitsmitarbeiter ausgeschlossen hatten, weil diese die Arbeit verlangsamt hatten. Und dann verwandelte sich dies in ein Verbot, das als gegeben hingenommen wurde. Obwohl es tats\u00e4chlich kein Verbot gab. <\/p>\n

    Unser Treffen nahm einen \u00e4u\u00dferst verworrenen Verlauf: \u00dcber etwa drei Stunden hinweg konnten f\u00fcnf verschiedene Teams mir nicht erkl\u00e4ren, was zwischen dem Code und dem Build geschieht. Und das sollte eigentlich die einfachste Sache sein. Die meisten DevOps-Berater gehen davon aus, dass dies bereits jedem bekannt ist. <\/p>\n

    Dann bemerkte die Person, die f\u00fcr die IT-Governance zust\u00e4ndig war und die vier Stunden lang geschwiegen hatte, pl\u00f6tzlich, als wir sein Thema erreichten und besch\u00e4ftigte uns noch l\u00e4ngere Zeit. Am Ende fragte ich ihn, was er von dem Treffen h\u00e4lt, und ich werde seine Antwort nie vergessen. Er sagte: \u201eFr\u00fcher dachte ich, es g\u00e4be in unserer Bank nur zwei Softwarebereitstellungsmethoden, aber jetzt wei\u00df ich, dass es insgesamt f\u00fcnf sind, von denen ich drei noch nicht einmal geahnt hatte.\u201c <\/p>\n

    \"Sieben
    \n
    \n(Diese Illustration kann     unter dem Link<\/a><\/noindex>)<\/i><\/p>\n

    Das letzte Treffen in dieser Bank war mit dem Team, das sich mit Software f\u00fcr Investitionen besch\u00e4ftigte. Dabei stellte sich heraus, dass es besser ist, Diagramme mit einem Marker auf 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 haben wir verwendet, um Muster, also Archetypen, zu suchen. <\/p>\n

    Also stelle ich Fragen den Mitarbeitern, sie notieren die Antworten mit Markern in drei Farben (schwarz, rot und blau). Ihre Antworten analysiere ich auf Archetypen. Lassen Sie uns nun 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 nicht dokumentierter Arbeit. Zum Beispiel, wenn ein Mitarbeiter einen anderen einfach um etwas bittet. In gro\u00dfen Organisationen kann das 60 % ungeplante Arbeit ausmachen. Und bis zu 40 % der Arbeit sind \u00fcberhaupt nicht dokumentiert. Wenn es Boeing w\u00e4re, w\u00fcrde ich niemals wieder in eines ihrer Flugzeuge steigen. Wenn nur die H\u00e4lfte der Arbeit dokumentiert wird, ist unklar, ob diese Arbeit richtig ausgef\u00fchrt wird oder nicht. Alle anderen Methoden sind somit nutzlos \u2014 es macht keinen Sinn, irgendetwas zu automatisieren, da die bekannten 50 % gerade der am besten organisierten und pr\u00e4zisesten Teil der Arbeit sein k\u00f6nnten, deren Automatisierung keine gro\u00dfen Ergebnisse liefert, w\u00e4hrend das Schlimmste in der unsichtbaren H\u00e4lfte verborgen ist. Ohne Dokumentation ist es unm\u00f6glich, alle m\u00f6glichen Hacks und verdeckte Arbeiten zu finden, oder Engp\u00e4sse wie die \u201eBrent\u2019s\u201c, von denen ich bereits gesprochen habe. Es gibt ein hervorragendes Buch von Dominica DeGrandis. \u201eMaking Work Visible\u201c<\/a><\/noindex>. Es analysiert f\u00fcnf verschiedene \u201eZeitdiebe\u201c<\/b> (thieves of time):<\/p>\n