{"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\/fr\/blog\/sem-arhetipov-prevrashheniya-po-princzipam-devops","title":{"rendered":"Sept arch\u00e9types de transformation selon les principes de DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La question \u00ab comment implanter DevOps chez soi \u00bb est pos\u00e9e depuis des ann\u00e9es, mais il n'existe pas beaucoup de bonnes ressources. Parfois, vous devenez une victime de la publicit\u00e9 de consultants pas tr\u00e8s \u00e9clair\u00e9s, qui cherchent \u00e0 vendre leur temps, peu importe comment. Parfois, ce sont des paroles vagues et tr\u00e8s g\u00e9n\u00e9rales sur la mani\u00e8re dont les grandes entreprises naviguent dans l'univers. La question se pose : qu'est-ce que cela signifie pour nous ? Cher auteur, pourriez-vous \u00e9noncer clairement vos id\u00e9es sous forme de liste ?<\/p>\n

Tout cela provient du fait qu'il n'y a pas encore beaucoup de pratique r\u00e9elle et de compr\u00e9hension des r\u00e9sultats des transformations culturelles dans les entreprises. Les changements culturels sont des processus longs dont les r\u00e9sultats ne se manifestent pas en une semaine ou un mois. Nous avons besoin de quelqu'un d'assez ancien, qui a vu les entreprises se construire et s'effondrer au fil des ans.<\/p>\n

\"Sept
\n
\nJohn Willis<\/b> \u2014 l'un des p\u00e8res du DevOps. Avec des dizaines d'ann\u00e9es d'exp\u00e9rience dans un grand nombre d'entreprises, John a r\u00e9cemment remarqu\u00e9 des mod\u00e8les sp\u00e9cifiques qui se manifestent dans le travail avec chacune d'elles. En utilisant ces arch\u00e9types, John guide les entreprises sur le v\u00e9ritable chemin de la transformation DevOps. Plus d'informations sur ces arch\u00e9types se trouvent dans la traduction de sa pr\u00e9sentation lors de la conf\u00e9rence DevOops 2018.
\n<\/a><\/noindex>
\n

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

\u00c0 propos du conf\u00e9rencier :<\/b><\/p>\n

Plus de 35 ans dans la gestion IT, a particip\u00e9 \u00e0 la cr\u00e9ation du pr\u00e9curseur d'OpenCloud chez Canonical, a \u00e9t\u00e9 impliqu\u00e9 dans 10 startups, dont deux ont \u00e9t\u00e9 vendues \u00e0 Dell et Docker. Actuellement Vice-Pr\u00e9sident des pratiques DevOps et num\u00e9riques chez SJ Technologies.<\/p>\n

Ensuite, un r\u00e9cit de la part de John.<\/b><\/p>\n

Je m'appelle John Willis, et vous pouvez plus facilement me trouver sur Twitter, @botchagalupe<\/a><\/noindex>. C'est aussi mon pseudonyme sur Gmail et GitHub. Vous pouvez \u00e9galement trouver des enregistrements vid\u00e9o de mes conf\u00e9rences et leurs pr\u00e9sentations. ici<\/a><\/noindex> vous pouvez trouver des vid\u00e9os de mes conf\u00e9rences et les pr\u00e9sentations qui y sont associ\u00e9es.<\/p>\n

J'ai beaucoup de r\u00e9unions avec des CIO de grandes entreprises. Ils se plaignent souvent de ne pas comprendre ce qu'est le DevOps, et ceux qui essaient de leur expliquer parlent de quelque chose de leur propre domaine. Une autre plainte fr\u00e9quente est que le DevOps ne fonctionne pas, bien que les directeurs semblent faire tout ce qu'on leur a recommand\u00e9. Il s'agit de grandes entreprises qui existent depuis plus de cent ans. Apr\u00e8s avoir discut\u00e9 avec eux, je suis arriv\u00e9 \u00e0 la conclusion que pour de nombreux probl\u00e8mes, des solutions relativement simples sont souvent plus adapt\u00e9es que des technologies avanc\u00e9es. Pendant des semaines, j'ai simplement dialogu\u00e9 avec des personnes de diff\u00e9rents d\u00e9partements. Ce que vous voyez sur la premi\u00e8re image de ce post est l'apparence de ma salle apr\u00e8s trois jours de travail sur le dernier projet.<\/p>\n

Qu'est-ce que le DevOps ?<\/h2>\n

\nEn effet, si vous demandez \u00e0 dix personnes diff\u00e9rentes, elles donneront dix r\u00e9ponses diff\u00e9rentes. Mais ce qui est int\u00e9ressant, c'est que toutes ces r\u00e9ponses seront correctes. Il n'y a pas de mauvaise r\u00e9ponse ici. J'ai \u00e9tudi\u00e9 le DevOps en profondeur pendant environ dix ans et j'ai \u00e9t\u00e9 le premier Am\u00e9ricain \u00e0 participer au premier DevOpsDay. Je ne dirais pas que je suis plus intelligent que ceux qui s'occupent du DevOps, mais il est peu probable qu'il y ait quelqu'un qui y ait consacr\u00e9 autant d'efforts. Je consid\u00e8re que le DevOps \u00e9merge lorsque le capital humain et la technologie se combinent. Nous oublions souvent la dimension humaine, m\u00eame si nous parlons beaucoup de diverses cultures. <\/p>\n

\"Sept
\n
\nNous disposons actuellement de nombreuses donn\u00e9es, cinq ann\u00e9es de recherche acad\u00e9mique et nous avons \u00e9tabli un processus de v\u00e9rification des th\u00e9ories \u00e0 une \u00e9chelle industrielle. Ces recherches nous disent ceci : si l'on combine certains sch\u00e9mas comportementaux dans la culture organisationnelle, on peut obtenir une acc\u00e9l\u00e9ration de 2000 fois. Cette acc\u00e9l\u00e9ration correspond \u00e0 une am\u00e9lioration similaire de la r\u00e9silience. C'est une mesure quantitative de l'avantage que le DevOps peut offrir \u00e0 toute entreprise. Il y a quelques ann\u00e9es, j'ai parl\u00e9 du DevOps \u00e0 un directeur g\u00e9n\u00e9ral d'une entreprise figurant sur la liste Fortune 5000. Lorsque je me pr\u00e9parais pour la pr\u00e9sentation, j'\u00e9tais tr\u00e8s nerveux, car je devais r\u00e9sumer mes ann\u00e9es d'exp\u00e9rience en cinq minutes. <\/p>\n

En fin de compte, j'ai donn\u00e9 la d\u00e9finition du DevOps<\/b>: c'est un ensemble de pratiques et de mod\u00e8les permettant de transformer le capital humain en capital organisationnel \u00e0 haute performance. Un exemple est la fa\u00e7on dont Toyota fonctionne depuis les 50 ou 60 derni\u00e8res ann\u00e9es.<\/p>\n

\"Sept
\n
\n(Ces sch\u00e9mas et les suivants ne servent pas de r\u00e9f\u00e9rence, mais d'illustration. Leur contenu variera pour chaque nouvelle entreprise. N\u00e9anmoins, vous pouvez voir l'image s\u00e9par\u00e9ment et l'agrandir via ce lien.)<\/a><\/noindex><\/i><\/p>\n

L'une des pratiques les plus r\u00e9ussies de ce type est la cartographie de flux de valeur<\/b>. Plusieurs bons livres ont \u00e9t\u00e9 \u00e9crits \u00e0 ce sujet, l'un des auteurs les plus connus \u00e9tant Karen Martin. Cependant, au cours de la derni\u00e8re ann\u00e9e, j'en suis arriv\u00e9 \u00e0 la conclusion que m\u00eame cette approche est trop technologique. Elle a, sans aucun doute, de nombreux avantages, dont j'ai beaucoup profit\u00e9. Mais quand le directeur g\u00e9n\u00e9ral vous demande pourquoi son entreprise ne peut pas passer \u00e0 de nouveaux rails, il est encore trop t\u00f4t pour parler de la cartographie de flux de valeur. Il existe de nombreuses questions fondamentalement plus importantes auxquelles il faut d'abord r\u00e9pondre. <\/p>\n

Il me semble que l'erreur de nombreux coll\u00e8gues est qu'ils se contentent de donner \u00e0 l'entreprise un guide en cinq points, puis reviennent apr\u00e8s six mois pour voir ce qui s'est pass\u00e9. M\u00eame une bonne m\u00e9thode comme la cartographie de flux de valeur a, disons, des zones mortes (blind spots). Apr\u00e8s des centaines d'entretiens avec des directeurs de diverses entreprises, j'ai d\u00e9velopp\u00e9 un certain sch\u00e9ma permettant de d\u00e9composer le probl\u00e8me en \u00e9l\u00e9ments constitutifs, et nous allons maintenant discuter de chacun de ces \u00e9l\u00e9ments. Avant d'appliquer des solutions technologiques, j'utilise ce sch\u00e9ma, et au final, tous mes murs se retrouvent couverts de sch\u00e9mas. R\u00e9cemment, j'ai travaill\u00e9 avec un fonds mutuel, et j'ai fini par avoir 100 \u00e0 150 de ces sch\u00e9mas.<\/p>\n

Une mauvaise culture dig\u00e8re de bonnes approches au petit d\u00e9jeuner<\/h2>\n

\nL'id\u00e9e principale est la suivante : aucune m\u00e9thode Lean, Agile, SAFE ou DevOps ne pourra aider si la culture de l'organisation elle-m\u00eame est mauvaise. C'est comme plonger en profondeur sans bouteille de plong\u00e9e ou op\u00e9rer sans radiographie. En d'autres termes, pour paraphraser Drucker et Deming : une mauvaise culture organisationnelle absorbera tout bon syst\u00e8me et ne crachera pas. <\/p>\n

Pour r\u00e9soudre ce probl\u00e8me majeur, il est n\u00e9cessaire d'entreprendre les \u00e9tapes suivantes :<\/p>\n

    \n
  1. Rendre tout le travail visible :<\/b> il faut rendre tout le travail visible. Pas dans le sens o\u00f9 il doit obligatoirement appara\u00eetre sur un \u00e9cran quelconque, mais dans le sens o\u00f9 il doit \u00eatre observable.<\/li>\n
  2. Consolider les syst\u00e8mes de gestion du travail :<\/b> Il est n\u00e9cessaire de consolider les syst\u00e8mes de gestion. Dans le probl\u00e8me des connaissances \u00ab tribales \u00bb et des connaissances institutionnelles, dans 9 cas sur 10, le goulot d'\u00e9tranglement est constitu\u00e9 par les personnes. Dans le livre \u00ab Projet Phoenix \u00bb<\/a><\/noindex> le probl\u00e8me se retrouvait chez un seul individu, Brent, au sujet duquel le projet accusait un retard de trois ans. Et je rencontre des \u00ab Brents \u00bb partout. Pour r\u00e9soudre ces goulots d'\u00e9tranglement, j'utilise les deux \u00e9l\u00e9ments suivants dans notre liste. <\/li>\n
  3. M\u00e9thodologie de la th\u00e9orie des contraintes :<\/b> th\u00e9orie des contraintes.<\/li>\n
  4. Astuces de collaboration :<\/b> hacks de collaboration. <\/li>\n
  5. Toyota Kata (Coaching Kata<\/a><\/noindex>):<\/b> Je ne vais pas parler beaucoup de Toyota Kata. Si cela vous int\u00e9resse, sur mon GitHub il y a des pr\u00e9sentations<\/a><\/noindex> presque sur chacun de ces th\u00e8mes. <\/li>\n
  6. Organisation orient\u00e9e march\u00e9 :<\/b> organisation ax\u00e9e sur le march\u00e9.<\/li>\n
  7. Auditeurs shift-left :<\/b> audit pr\u00e9coce dans le cycle.<\/li>\n<\/ol>\n

    \"Sept
    \n
    \nJe commence \u00e0 travailler avec l'organisation de mani\u00e8re tr\u00e8s simple : je vais dans l'entreprise et je parle avec les employ\u00e9s. Comme on le voit, aucune haute technologie. Tout ce qu'il faut, c'est d'avoir quelque chose pour \u00e9crire. Je regroupe plusieurs \u00e9quipes dans une m\u00eame pi\u00e8ce et j'analyse ce qu'elles me disent du point de vue de mes 7 arch\u00e9types. Ensuite, je leur donne un marqueur et leur demande de transcrire au tableau tout ce qu'elles ont d\u00e9j\u00e0 exprim\u00e9 \u00e0 voix haute. En g\u00e9n\u00e9ral, lors de ce type de r\u00e9unions, il y a une personne qui prend des notes, et dans le meilleur des cas, elle parvient \u00e0 enregistrer 10 % de la discussion. Gr\u00e2ce \u00e0 ma m\u00e9thode, ce taux peut atteindre environ 40 %. <\/p>\n

    \"Sept
    \n
    \n(Cette illustration peut \u00eatre     consult\u00e9e via le lien<\/a><\/noindex>)<\/i><\/p>\n

    Mon approche est fond\u00e9e sur le travail de William Schneider (William Schneider, The Reengineering Alternative<\/a><\/noindex>). Au c\u0153ur de cette approche se trouve l'id\u00e9e que toute organisation peut \u00eatre d\u00e9compos\u00e9e en quatre quadrants. Ce sch\u00e9ma r\u00e9sulte g\u00e9n\u00e9ralement de mon travail avec les nombreuses autres sch\u00e9mas qui \u00e9mergent lors de l'analyse de l'organisation. Supposons que nous ayons une organisation avec un haut niveau de contr\u00f4le, mais avec une faible comp\u00e9tence. C'est un sc\u00e9nario extr\u00eamement ind\u00e9sirable : quand tout le monde agit de mani\u00e8re rigide, mais que personne ne sait ce qu'il faut faire. <\/p>\n

    Une option nettement am\u00e9lior\u00e9e avec un haut niveau de contr\u00f4le et de comp\u00e9tence. Si une entreprise est rentable, peut-\u00eatre que DevOps n'est pas n\u00e9cessaire. Travailler avec une entreprise ayant un bon niveau de contr\u00f4le, une comp\u00e9tence faible mais une collaboration \u00e9lev\u00e9e et une culture forte est le plus int\u00e9ressant. Cela signifie qu'il y a beaucoup de personnes qui aiment travailler l\u00e0-bas et que le turnover est faible. <\/p>\n

    \"Sept
    \n
    \n(Cette illustration peut \u00eatre     consult\u00e9e via le lien<\/a><\/noindex>)<\/i><\/p>\n

    Je pense que les m\u00e9thodes avec des recommandations strictes finissent par obstruer la recherche de la v\u00e9rit\u00e9. En particulier, dans le value stream mapping, il existe de nombreuses r\u00e8gles concernant la mani\u00e8re de structurer l'information. Au d\u00e9but du processus, dont je parle, ces r\u00e8gles ne sont pas n\u00e9cessaires. Si quelqu'un, avec un marqueur \u00e0 la main, d\u00e9crit sur un tableau la situation r\u00e9elle de l'entreprise, c'est le meilleur moyen de comprendre les choses. Cette information n'atteint pas les directeurs. \u00c0 ce moment-l\u00e0, il est absurde d'interrompre une personne et de dire qu'elle a mal dessin\u00e9 une fl\u00e8che. \u00c0 ce stade, il vaut mieux utiliser des r\u00e8gles simples, par exemple : une abstraction multi-niveaux peut \u00eatre cr\u00e9\u00e9e simplement en utilisant des marqueurs de diff\u00e9rentes couleurs. <\/p>\n

    Je r\u00e9p\u00e8te, pas de haute technologie. La r\u00e9alit\u00e9 objective est repr\u00e9sent\u00e9e par un marqueur noir, montrant comment tout fonctionne. Avec un marqueur rouge, les gens indiquent ce qu'ils n'aiment pas dans la situation actuelle. Il est important que ce soit eux qui l'\u00e9crivent, pas moi. Lorsque, apr\u00e8s la r\u00e9union, je me rends chez le directeur des technologies de l'information, je ne propose pas une liste de 10 points \u00e0 corriger. Je cherche \u00e0 \u00e9tablir des liens entre ce que disent les gens de l'entreprise et les mod\u00e8les \u00e9prouv\u00e9s existants. Enfin, avec un marqueur bleu, des solutions potentielles au probl\u00e8me sont propos\u00e9es. <\/p>\n

    \"Sept
    \n
    \n(Cette illustration peut \u00eatre     consult\u00e9e via le lien<\/a><\/noindex>)<\/i><\/p>\n

    Un exemple de cette approche est visible ci-dessus. Au d\u00e9but de cette ann\u00e9e, j'ai travaill\u00e9 avec une banque. Les employ\u00e9s du d\u00e9partement de s\u00e9curit\u00e9 \u00e9taient convaincus qu'ils ne devaient pas assister aux \u00e9valuations des exigences et \u00e0 la conception (design and requirement reviews). <\/p>\n

    \"Sept
    \n
    \n(Cette illustration peut \u00eatre     consult\u00e9e via le lien<\/a><\/noindex>)<\/i><\/p>\n

    Puis nous avons parl\u00e9 avec des personnes d'autres d\u00e9partements et il s'est av\u00e9r\u00e9 qu'il y a environ 8 ans, les d\u00e9veloppeurs de logiciels avaient \u00e9vinc\u00e9 les employ\u00e9s de s\u00e9curit\u00e9 parce qu'ils ralentissaient le travail. Cela s'\u00e9tait ensuite transform\u00e9 en une interdiction qui \u00e9tait per\u00e7ue comme un fait \u00e9tabli. Pourtant, il n'y avait en r\u00e9alit\u00e9 aucune interdiction. <\/p>\n

    Notre r\u00e9union a pris un tour tr\u00e8s confus : pendant environ trois heures, cinq \u00e9quipes diff\u00e9rentes n'ont pas pu m'expliquer ce qui se passe entre le code et la compilation. Et c'est pourtant la chose la plus simple. La plupart des consultants DevOps partent du principe que cela est d\u00e9j\u00e0 connu de tous. <\/p>\n

    Puis la personne en charge de la gouvernance IT, qui \u00e9tait rest\u00e9e silencieuse pendant quatre heures, s'est soudainement anim\u00e9e lorsque nous avons abord\u00e9 son sujet, et nous a occup\u00e9s encore longtemps. \u00c0 la fin, je lui ai demand\u00e9 ce qu'il pensait de la r\u00e9union, et je n'oublierai jamais sa r\u00e9ponse. Il a dit : \u00ab Auparavant, je pensais qu'il n'y avait que deux mani\u00e8res de livrer des logiciels dans notre banque, maintenant je sais qu'il y en a cinq, et je ne soup\u00e7onnais m\u00eame pas trois d'entre elles \u00bb. <\/p>\n

    \"Sept
    \n
    \n(Cette illustration peut \u00eatre     consult\u00e9e via le lien<\/a><\/noindex>)<\/i><\/p>\n

    La derni\u00e8re r\u00e9union dans cette banque a eu lieu avec l'\u00e9quipe qui s'occupe des logiciels d'investissement. C'est avec elle que j'ai d\u00e9couvert qu'il est pr\u00e9f\u00e9rable d'\u00e9crire des sch\u00e9mas avec un marqueur sur une feuille plut\u00f4t que sur un tableau, et m\u00eame mieux que sur un tableau interactif. <\/p>\n

    \"Sept
    \n
    \nLes photos que vous voyez montrent \u00e0 quoi ressemblait la salle de conf\u00e9rence de l'h\u00f4tel le quatri\u00e8me jour de notre r\u00e9union. Et ces sch\u00e9mas ont \u00e9t\u00e9 utilis\u00e9s pour rechercher des patterns, c'est-\u00e0-dire des arch\u00e9types. <\/p>\n

    Ainsi, je pose des questions aux employ\u00e9s, ils notent les r\u00e9ponses avec des marqueurs de trois couleurs (noir, rouge et bleu). J'analyse leurs r\u00e9ponses en qu\u00eate d'arch\u00e9types. Maintenant, discutons de tous les arch\u00e9types dans l'ordre. <\/p>\n

    1. Make All Work Visible: Rendre le travail visible<\/h3>\n

    \nDans la plupart des entreprises avec lesquelles je travaille, un pourcentage tr\u00e8s \u00e9lev\u00e9 du travail est inconnu. Par exemple, c'est lorsque qu'un employ\u00e9 demande \u00e0 un autre de faire quelque chose. Dans de grandes organisations, jusqu'\u00e0 60 % du travail peut \u00eatre non planifi\u00e9. Et jusqu'\u00e0 40 % du travail n'est pas du tout document\u00e9. Si c'\u00e9tait Boeing, je ne prendrais plus jamais leur vol. Si seule la moiti\u00e9 du travail est document\u00e9e, on ne sait pas si ce travail est fait correctement ou non. Tous les autres moyens deviennent inutiles - il n'est pas pertinent d'essayer d'automatiser quoi que ce soit, car les 50 % connus peuvent pr\u00e9cis\u00e9ment \u00eatre la partie la plus harmonieuse et structur\u00e9e du travail, dont l'automatisation ne donnera pas de grands r\u00e9sultats, tandis que le pire se trouve dans la moiti\u00e9 invisible. En l'absence de documentation, il est impossible de trouver toutes sortes de hacks et de travaux cach\u00e9s, de d\u00e9celer les goulets d'\u00e9tranglement, ces fameux \u00ab Brents \u00bb dont j'ai d\u00e9j\u00e0 parl\u00e9. Il y a un excellent livre de Dominica DeGrandis. \u00ab Making Work Visible \u00bb<\/a><\/noindex>. Elle identifie cinq diff\u00e9rents \u00ab voleurs de temps \u00bb<\/b> (thieves of time):<\/p>\n