{"id":34157,"date":"2019-10-31T21:56:43","date_gmt":"2019-10-31T18:56:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-nachat-devops-transformatsiyu\/"},"modified":"2019-10-31T21:56:43","modified_gmt":"2019-10-31T18:56:43","slug":"kak-nachat-devops-transformatsiyu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-nachat-devops-transformatsiyu","title":{"rendered":"Comment commencer une transformation DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Si vous ne comprenez pas ce qu'est DevOps, voici un bref rappel. DevOps est un ensemble de pratiques qui r\u00e9duisent les craintes des ing\u00e9nieurs<\/strong> et diminuent le nombre de pannes dans la production de logiciels. En g\u00e9n\u00e9ral, elles r\u00e9duisent le temps de mise sur le march\u00e9<\/strong> \u2014 la p\u00e9riode entre l'id\u00e9e et la livraison du produit final aux clients, ce qui permet d'effectuer rapidement des exp\u00e9riences commerciales.<\/strong>.<\/p>\n

Comment commencer la transformation DevOps ? En bref : choisissons le service \u00e0 partir duquel nous allons entamer le processus, identifions ceux qui sont concern\u00e9s par le service, construisons une carte de flux de valeur, formons une \u00e9quipe temporaire qui s'occupera de la transformation pendant un certain temps et lui fixons une t\u00e2che. R\u00e9p\u00e9tons le cycle autant de fois que n\u00e9cessaire.<\/p>\n

\"Comment<\/p>\n

Un plan d\u00e9taill\u00e9 de la transformation DevOps avec des exemples et des instructions est disponible sous le spoiler \u2014 dans la transcription du rapport<\/a><\/noindex> Andrei Alexandrov<\/b> \u2014 d'un ing\u00e9nieur de l'entreprise Express42, qui conseille sur la mise en place de DevOps, en acc\u00e9l\u00e9rant ce processus, car elle a d\u00e9j\u00e0 construit une carte des \u00e9cueils. Si vous pensez que la transformation n'est pas n\u00e9cessaire, ou que votre sp\u00e9cificit\u00e9 fait que les pratiques DevOps ne conviennent pas, utilisez le rapport comme un guide pour identifier et r\u00e9soudre les contraintes.
\n<\/a><\/noindex>
\nSi la question de la transformation DevOps vous pr\u00e9occupe, c'est que vous avez une grande entreprise, et il est n\u00e9cessaire d'\u00e9largir progressivement ce processus \u00e0 toute la structure. Tant qu'il est n\u00e9cessaire de transformer l'\u00e9quipe ou de r\u00e9soudre une contrainte, l'algorithme ci-dessous peut \u00eatre r\u00e9p\u00e9t\u00e9.<\/p>\n

Choix du service<\/h2>\n

\nNous avons esquiss\u00e9 un plan, commen\u00e7ons par la premi\u00e8re \u00e9tape : choisir le service. Le premier crit\u00e8re est la dur\u00e9e de vie<\/strong>: il y a des anciens services \u2014 legacy, et des nouveaux. On peut commencer avec l'un ou l'autre.<\/p>\n

Choisir un service jeune est logique.<\/strong>Il est nouveau, il n'y a pas encore de processus \u00e9tabli au sein de l'\u00e9quipe qui s'en occupe. Il n'y a pas une montagne de dettes techniques, il n'est pas n\u00e9cessaire de le r\u00e9parer constamment. Nous pouvons faire tout ce que nous voulons avec.<\/p>\n

Dans le cas d'un ancien service, des probl\u00e8mes se posent, car le changement est toujours difficile.<\/strong>Il y a d\u00e9j\u00e0 un ensemble de contraintes s\u00e9rieuses, mais peut-\u00eatre que des personnes s'en occupent qui sont pr\u00eates \u00e0 tout reprendre \u2014 elles sont fatigu\u00e9es et veulent faire les choses diff\u00e9remment, parce qu'elles souffrent.<\/p>\n

Travailler avec un ancien service cr\u00e9e un puissant pr\u00e9c\u00e9dent<\/strong> dans votre entreprise \u2014 on peut changer quelque chose. Si vous avez modifi\u00e9 un nouveau service, qui est en production 100 fois par heure, et que tout va bien, alors les gens dans votre entreprise peuvent dire :<\/p>\n

\u2014 C'est un nouveau service ! C'\u00e9tait si simple avant, essayez de faire quelque chose avec notre vieux tas de ferraille.<\/em><\/p>\n

Un service legacy a du sens \u00e0 transformer, lorsque vous le faites avec quelqu'un, par exemple, si vous avez invit\u00e9 un consultant externe. Soyons honn\u00eates, la transformation va bouleverser tout ce qui peut l'\u00eatre.<\/strong>. Vous exp\u00e9rimentez et vous ne savez pas o\u00f9 vous allez, quelles technologies vous allez utiliser et pourquoi, o\u00f9 et quels pi\u00e8ges vous rencontrerez dans les processus. C'est pourquoi il est plus facile de changer pour un nouveau.<\/p>\n

Si vous faites tout vous-m\u00eame et qu'il n'y a pas de comp\u00e9tence s\u00e9rieuse dans l'entreprise \u2014 prenons un nouveau service. Si vous connaissez un consultant externe et avez des fonds \u2014 choisissez l'ancien.<\/p><\/blockquote>\n

\nIl y a des services qui ne sont qu'une interface pour les utilisateurs, comme un simple site web ou une application mobile. Mais il y a des choses s\u00e9rieuses comme la facturation. Si quelque chose va mal avec la facturation, il sera difficile de r\u00e9soudre le probl\u00e8me. Ici aussi, nous avons le choix.<\/p>\n

Nous travaillons soit avec un service critique<\/strong>, mais d\u00e9j\u00e0 \u00e0 cause de lui nous souffrons, il cr\u00e9e des limitations, soit nous travaillons avec une interface<\/strong>. C'est le deuxi\u00e8me crit\u00e8re de choix. De m\u00eame, il est possible de faire appel \u00e0 un consultant exp\u00e9riment\u00e9 \u2014 nous travaillons avec l'option la plus complexe.<\/p>\n

Mais m\u00eame dans ce cas, je ne recommanderais pas de le faire, car tant que nous n'avons pas compris sur quoi nous travaillons et dans quelle direction transformer, prendre quelque chose de critique et le chambouler \u2014 ce n'est pas une tr\u00e8s bonne id\u00e9e. C'est pourquoi dans ce cas nous pr\u00e9f\u00e9rons travailler avec une interface, dont la panne n'est pas critique.<\/p>\n

Ensuite, examinons l'\u00e9quipe de service<\/b>. Avec ceux qui s'occupent de ce service, nous devrons travailler constamment et interagir dans un contact tr\u00e8s \u00e9troit.<\/p>\n

Les gens dans l'\u00e9quipe se divisent en deux cat\u00e9gories : les conservateurs<\/strong> \u2014 ils vivent dans l'ancien monde, ou ne savent tout simplement rien sur le DevOps, et les innovateurs<\/strong>, qui tirent toutes les pratiques \u00e0 la mode. Les seconds ne comprennent pas toujours le sujet, mais au moins ils sont pr\u00eats \u00e0 s'y attaquer.<\/p>\n

D'un c\u00f4t\u00e9, les conservateurs \u2014 ce sont des gens exp\u00e9riment\u00e9s : ils sont dans l'entreprise depuis longtemps, ils comprennent de bout en bout, mais ne connaissent pas vraiment les pratiques. D'un autre c\u00f4t\u00e9 \u2014 les innovateurs, qui ont entendu parler de certains sujets, mais qui travaillent probablement dans l'entreprise depuis pas tr\u00e8s longtemps. Avec qui est-il pr\u00e9f\u00e9rable de travailler ?<\/p>\n

Il faudra interagir avec les conservateurs de toute fa\u00e7on, car c'est leur service. Nous devrons communiquer avec eux, clarifier les sp\u00e9cificit\u00e9s du service, ce qui peut \u00eatre fait d'une mani\u00e8re ou d'une autre. Nous d\u00e9pendons de leurs conseils. Il est probable que nous devrons leur confier certaines t\u00e2ches, car ils connaissent leur service mieux que quiconque. Il est donc important de savoir avec quelle \u00e9quipe nous aurons finalement contact.<\/p>\n

Il est logique de choisir une \u00e9quipe d'innovaturs, car les conservateurs pourraient poser probl\u00e8me.\n<\/p><\/blockquote>\n

\nDans la pratique, il arrive souvent que les personnes conservatrices aient une exp\u00e9rience significative, mais qu'elles ne sachent pas comment avancer. Elles ont simplement peur qu'apr\u00e8s la transformation et la refonte du service, elles soient licenci\u00e9es par manque de besoin. Parfois, simplement par m\u00e9compr\u00e9hension de ce qui se passe, elles sabotent le travail.<\/p>\n

J'ai eu un cas o\u00f9 un gars de l'\u00e9quipe r\u00e9parait tout ce qui lui passait par la t\u00eate, car cela semblait plus critique que ce que nous faisions \u00e0 ce moment-l\u00e0. Nous avons une t\u00e2che : r\u00e9aliser cette partie aujourd'hui \u2014 non, il y a un incendie \u00e0 l'autre bout du monde, nous allons le r\u00e9parer. Travailler avec ce genre de personnes est difficile.<\/p>\n

Les gens de l'\u00e9quipe des conservateurs ont souvent tendance \u00e0 ignorer les t\u00e2ches, ou \u00e0 les remettre \u00e0 plus tard. Et si, par malheur, vous avez fait une erreur et leur avez impos\u00e9 des KPI en fonction du nombre de t\u00e2ches accomplies, et qu'une certaine partie n'est pas incluse dans les KPI pour une raison quelconque, alors ils ne feront absolument rien. En r\u00e9alit\u00e9, ils auraient raison, car ils perdraient alors leur prime.<\/p>\n

Avec les innovateurs, c'est plus simple \u2014 ils sont plus loyaux.<\/strong>. Ils ont d\u00e9j\u00e0 entendu parler de quelque chose, ils veulent aller de l'avant, donc ils aideront. Nous avons besoin de personnes pr\u00eates \u00e0 souffrir au d\u00e9but : si le service change, tous les probl\u00e8mes et emb\u00fbches seront ressentis par les innovateurs en tant que pionniers. Les innovateurs veulent le plus r\u00e9cent et le plus tendance, m\u00eame si cela implique de souffrir.<\/p>\n

Les conservateurs peuvent \u00eatre convertis plus tard \u00e0 notre vision. Lorsque vous montrerez qu'une petite partie a \u00e9t\u00e9 chang\u00e9e et que tout fonctionne bien, il est probable qu'ils voudront aussi essayer et accepter la nouvelle religion DevOps.<\/p>\n

\"Comment
\n<\/p>\n

En r\u00e9sum\u00e9. Si nous faisons toute la transformation dans notre entreprise nous-m\u00eames, alors nous choisissons : un nouveau service, de pr\u00e9f\u00e9rence avec une interface simple, afin de ne pas trop souffrir des pannes, et une \u00e9quipe d'innovateurs.<\/p><\/blockquote>\n

\nS'il est possible de faire appel \u00e0 un consultant externe, plut\u00f4t que de prendre un nouveau service, utilisons l'ancien service dont nous souffrons d\u00e9j\u00e0. Les personnes qui ont travaill\u00e9 sur des transformations pendant un certain temps dans diff\u00e9rentes entreprises ont vu divers cas et comprennent d\u00e9j\u00e0 comment faire les choses correctement et dans quelle direction aller.<\/p>\n

Qui est impliqu\u00e9 ?<\/h2>\n

\nNous devons trouver toutes les personnes ayant un lien avec le service : d\u00e9veloppeurs, testeurs, administrateurs, sp\u00e9cialistes de la s\u00e9curit\u00e9, gestionnaires et, peut-\u00eatre, Product Owners. Bien que les Product Owners ne soient pas des techniciens, ils ont un lien avec le service : ils prennent des d\u00e9cisions et d\u00e9finissent des t\u00e2ches.<\/p>\n

\"Comment
\n<\/p>\n

Nous devons trouver, rencontrer et discuter avec tous ceux qui prennent des d\u00e9cisions et influencent ce qui se passe avec le service.<\/p><\/blockquote>\n

\nPourquoi en avons-nous besoin ? Pour savoir avec qui n\u00e9gocier.<\/strong>. Pendant la transformation, lorsque le principe de fonctionnement habituel du service change, il sera in\u00e9vitable d'avoir des interruptions. Pendant un certain temps, il y aura des pannes pendant que nous testons de nouvelles approches. Les gens doivent \u00eatre pr\u00e9par\u00e9s \u00e0 cela et y consentir.<\/p>\n

Ensuite, il faudra construire une carte de flux de valeur et sans ces personnes, cela ne pourra pas \u00eatre r\u00e9alis\u00e9, car eux seuls connaissent l'ensemble du tableau de ce qui se passe. Une seule personne ne sait jamais tout ce qui se passe avec le service.<\/p>\n

Ils recommanderont des personnes pour l'\u00e9quipe. Plus tard, nous discuterons de la n\u00e9cessit\u00e9 d'une \u00e9quipe distincte. Il faudra prendre des personnes des d\u00e9partements existants. Ceux qui ont un lien avec le service pourront recommander des coll\u00e8gues pensant dans notre sens, qui peuvent nous aider et ont la comp\u00e9tence dont nous avons besoin.<\/p>\n

Ensuite, nous rassemblons toutes ces personnes de diff\u00e9rents d\u00e9partements dans une m\u00eame pi\u00e8ce et nous commen\u00e7ons \u00e0 construire la carte de flux de valeur.<\/p>\n

Construire une carte de flux de valeur<\/h2>\n

\nLa carte de flux de valeur est un sch\u00e9ma ou une carte qui montre le flux de valeur vers le client.<\/strong>C'est l'ensemble du processus, de l'id\u00e9e \u00e0 sa r\u00e9alisation, y compris toutes les \u00e9tapes interm\u00e9diaires et comment la valeur parvient finalement \u00e0 nos clients.<\/p>\n

La carte de flux de valeur est n\u00e9cessaire pour visualiser toutes les \u00e9tapes du d\u00e9veloppement,<\/strong>localiser les probl\u00e8mes \u00e0 travers les mesures existantes dans le processus actuel et commencer \u00e0 les r\u00e9soudre, et \u00e9tablir un objectif initial.<\/strong>. C'est l'endroit o\u00f9 nous allons r\u00e9ellement commencer \u00e0 agir.<\/p>\n

M\u00e9triques<\/h3>\n

\nDans la litt\u00e9rature sur la carte de flux de valeur, il existe de nombreuses m\u00e9triques diff\u00e9rentes, mais pour commencer, trois suffisent.<\/p>\n

Lead Time \u2014 d\u00e9lai \/ attente.<\/strong> \u2014 un moment o\u00f9 nous attendons quelque chose. Par exemple, un testeur attend qu'un stand soit disponible pour les tests, et pendant ce temps, il ne peut rien faire.<\/p>\n

Temps de valeur ajout\u00e9e \u2014 temps de travail utile<\/strong> \u2014 celui que nous avons pass\u00e9 \u00e0 une certaine \u00e9tape pour cr\u00e9er de la valeur finale pour l'utilisateur. Par exemple, le testeur a lanc\u00e9 son test et a commenc\u00e9 \u00e0 v\u00e9rifier quelque chose. C'est ce que l'on appelle le temps de travail utile, lorsque nous faisons r\u00e9ellement quelque chose pour le produit. C'est ce pour quoi les clients paient \u2014 pour un logiciel de qualit\u00e9.<\/p>\n

%C\/A \u2014 pourcentage de travail accept\u00e9. <\/strong>Nous avons une \u00e9tape \u2014 le d\u00e9veloppement, et une deuxi\u00e8me \u00e9tape \u2014 le test. Combien de fonctionnalit\u00e9s les testeurs ont re\u00e7ues des d\u00e9veloppeurs, et voici ce pourcentage.<\/p>\n

Voici \u00e0 quoi ressemble notre carte.<\/p>\n

\"Comment
\n
\nElle peut sembler diff\u00e9rente en fonction de la structure de l'organisation, du nombre de d\u00e9partements et de ce que vous faites. Mais dans l'ensemble, la carte aura deux \u00e9tapes : id\u00e9e <\/strong>et analyse<\/strong>. \u00c0 ce stade, des donn\u00e9es sont attendues, par exemple, un Lead Time de 2 semaines et un Temps de valeur ajout\u00e9e de 2 jours.<\/p>\n

Les m\u00e9triques couvrent absolument toutes les \u00e9tapes.<\/p><\/blockquote>\n

\nBacklog<\/strong> \u2014 combien de t\u00e2ches sont rest\u00e9es apr\u00e8s que les analystes les ont imagin\u00e9es.<\/p>\n

D\u00e9veloppement<\/strong> \u2014 combien de semaines les d\u00e9veloppeurs ont attendu des pr\u00e9cisions sur les t\u00e2ches, les stands ou l'\u00e9quipement \u2014 peu importe, mais ils attendent quelque chose. Par exemple, ils mettent 4 jours \u00e0 r\u00e9aliser une fonctionnalit\u00e9. Ici appara\u00eet la m\u00e9trique %C\/A. Les d\u00e9veloppeurs ont pris dans le Backlog seulement 80 % des t\u00e2ches. Ils estiment que pour les 20 % restants, le cahier des charges n'est pas assez clair, et les ont renvoy\u00e9es pour r\u00e9ajustement.<\/p>\n

Test<\/strong>. Dans le sch\u00e9ma, LT est fix\u00e9 \u00e0 4 jours. Par exemple, les testeurs ont attendu la lib\u00e9ration du stand de test, VA 2 jours ils testent r\u00e9ellement quelque chose, et %C\/A = 40 %. \u2014 seulement 40 % du code ou des fonctionnalit\u00e9s envoy\u00e9s par les d\u00e9veloppeurs ont \u00e9t\u00e9 jug\u00e9s ad\u00e9quats par les testeurs. Tout le reste ne leur a pas convenu pour une raison quelconque.<\/p>\n

Je ne vais pas entrer dans les d\u00e9tails sur la fa\u00e7on de r\u00e9aliser ces mesures, \u00e0 la fin de l'article, je recommanderai des lectures pour en apprendre davantage.<\/p>\n

La seule chose que je conseille \u2014 ne croyez pas les personnes qui vont \u00e9tablir avec vous une Value Stream Map. Elles \u00e9valuent combien de temps prennent diff\u00e9rents processus, mais ces estimations ne sont pas toujours correctes, il vaut donc mieux mesurer soi-m\u00eame.<\/p>\n

Il y a eu un cas o\u00f9 nous sommes all\u00e9s au service des op\u00e9rations et avons demand\u00e9 combien de temps il fallait pour d\u00e9ployer une nouvelle fonctionnalit\u00e9 en production. On nous a r\u00e9pondu 10 minutes, et nous avons pens\u00e9, pourquoi sommes-nous venus dans cette entreprise ? Il s'est av\u00e9r\u00e9 que 10 minutes, c'est le temps que met le script pour prendre le code et le d\u00e9ployer sur le serveur. Mais avant cela, la version reste trois jours sur le serveur sans rien faire \u2014 une t\u00e2che est en attente dans le Backlog, qu'il faut d\u00e9ployer. En fait, avant la phase de d\u00e9ploiement, il y a une phase d'attente o\u00f9 le projet reste inactif. Si nous n'\u00e9tions pas all\u00e9s avec un carnet, si nous n'avions pas remarqu\u00e9 la t\u00e2che dans Jira et commenc\u00e9 \u00e0 la suivre \u00e9tape par \u00e9tape, nous aurions cru que tout allait bien et qu'il n'y avait pas de probl\u00e8me.<\/p>\n

Il faudra donc faire des mesures vous-m\u00eame, de pr\u00e9f\u00e9rence pas qu'une seule fois, afin d'avoir une id\u00e9e proche de la r\u00e9alit\u00e9. Selon la Value Stream Map, vous prendrez la d\u00e9cision d'o\u00f9 commencer et quoi corriger en premier.<\/p>\n

\u00c9quipe temporaire<\/h2>\n

\nDe nombreuses entreprises qui ont d\u00e9cid\u00e9 d'impl\u00e9menter le DevOps cr\u00e9ent une \u00e9quipe, mais ce n'est pas temporaire, elle existe depuis plusieurs ann\u00e9es. Si vous consultez un service DevOps qui d\u00e9crit diff\u00e9rents mod\u00e8les de structures organisationnelles en DevOps, vous comprendrez que c'est un antipattern.<\/p>\n

Quand une \u00e9quipe DevOps existe de mani\u00e8re permanente pendant plusieurs ann\u00e9es, c'est une grande erreur, car DevOps concerne la communication entre les d\u00e9partements, la rapidit\u00e9 et l'efficacit\u00e9.<\/p><\/blockquote>\n

\nSi l'\u00e9quipe existe entre les d\u00e9partements seulement pour r\u00e9aliser quelque chose de s\u00e9par\u00e9 et dure longtemps, elle cr\u00e9e une barri\u00e8re inutile. Maintenant, au lieu que le programmeur aille directement voir l'administrateur pour r\u00e9soudre un probl\u00e8me, il doit d'abord passer par le service DevOps, et ce dernier s'en occupera ensuite.<\/p>\n

Donc, pour commencer, il faut cr\u00e9er une \u00e9quipe temporaire.<\/strong>. Elle existe en principe pendant six mois, au maximum un an, en fonction de l'objectif fix\u00e9, uniquement pour \u00e9liminer une restriction que nous avons choisie. Ensuite, elle mourra. Si nous d\u00e9terminons un autre point o\u00f9 nous \u00e9prouvons une grande douleur et que nous comprenons qu'une autre \u00e9quipe est aussi n\u00e9cessaire pour cela, nous la cr\u00e9erons \u00e0 nouveau. Mais de telles \u00e9quipes ne devraient pas exister en \u00ab permanence \u00bb \u2014 sinon, elles perturbent la communication et prennent en charge des t\u00e2ches distinctes juste pour faire quelque chose. Ces t\u00e2ches peuvent ne pas \u00eatre en rapport avec DevOps et la transformation. Pourquoi ne pas confier cette t\u00e2che aux d\u00e9partements existants ?<\/p>\n

Pourquoi une \u00e9quipe temporaire est n\u00e9cessaire<\/h3>\n

\nConflit avec les processus actuels<\/strong>. La transformation DevOps implique non seulement des changements dans les technologies et les outils que nous utilisons, mais aussi un changement dans le processus de travail, la pens\u00e9e et les valeurs. Si l'\u00e9quipe continue de travailler comme elle en a l'habitude, elle ne pourra pas explorer d'autres approches.<\/p>\n

Ces personnes doivent vivre selon d'autres r\u00e8gles : ignorer tous les KPI de l'entreprise, car elles tentent de travailler diff\u00e9remment. Les \u00e9quipes temporaires ne rempliront pas de demandes pour obtenir un serveur, mais iront directement au service responsable avec l'exigence de leur donner en premier ce qui est n\u00e9cessaire, car c'est une t\u00e2che prioritaire et parce qu'elles tentent de vivre diff\u00e9remment. L'\u00e9quipe est en plein conflit avec tous les processus en cours. Pour que les m\u00e9thodes de travail existantes ne leur posent pas probl\u00e8me actuellement, et qu'elles ne perturbent pas les autres, nous isolons ces personnes en les regroupant dans une \u00e9quipe distincte.<\/p>\n

\u00c9viter la bureaucratie dans les exp\u00e9rimentations<\/strong>. Dans les \u00e9quipes temporaires, il n'y a pas de bureaucratie, elles ne remplissent pas de rapports sur les heures de travail, elles ne rendent pas compte aux gestionnaires. C'est un monde absolument s\u00e9par\u00e9, o\u00f9 les gens vivent et pensent diff\u00e9remment, et s'occupent de choses totalement autres. Il ne faut pas les d\u00e9ranger inutilement.<\/p>\n

Travail continu sur le service<\/strong>. Dans le premier point, nous avons choisi quelque chose sur lequel nous allons exp\u00e9rimenter. Les exp\u00e9rimentations et la recherche de meilleures m\u00e9thodes de travail sont bonnes, mais nous voulons aussi cr\u00e9er des fonctionnalit\u00e9s. Si toute l'\u00e9quipe se consacre \u00e0 la transformation au lieu des fonctionnalit\u00e9s, nous commencerons \u00e0 perdre des revenus, les bugs resteront longtemps non r\u00e9solus \u2014 ce n'est pas ce que nous voulons. La cr\u00e9ation d'une \u00e9quipe temporaire permet d'exp\u00e9rimenter sans interrompre le travail sur le produit.<\/p>\n

Ne pas perdre de temps sur des t\u00e2ches de travail<\/strong>. C'est encore une fois au sujet du produit. Il faut beaucoup de temps pour que l'\u00e9quipe essaie d'autres outils, etc. Pour que les gens se familiarisent avec les outils, commencent \u00e0 les int\u00e9grer et \u00e0 les utiliser correctement, il faudra au moins six mois. Si en plus ils doivent s'occuper du produit, ces six mois s'\u00e9tireront ind\u00e9finiment. Si les gens s'occupent du produit, ils travaillent encore avec les anciens processus \u2014 ce n'est pas ce dont nous avons besoin.<\/p>\n

C'est pourquoi nous recrutons des personnes de diff\u00e9rents d\u00e9partements pour constituer une \u00e9quipe distincte qui s'occupera de la transformation du service. En cons\u00e9quence, le service fonctionne, continue de se d\u00e9velopper, et par ailleurs, nous faisons quelques exp\u00e9riences dessus.<\/p>\n

L'\u00e9quipe temporaire se concentre uniquement sur la transformation DevOps \u2014 sur l'\u00e9limination des limitations que nous avons identifi\u00e9es, et rien de plus.<\/p><\/blockquote>\n

\nL'\u00e9quipe se compose de personnes polyvalentes<\/strong>. Cela signifie que nous n'avons pas pris uniquement des d\u00e9veloppeurs. Nous ne sommes pas arriv\u00e9s dans le service en retirant la moiti\u00e9 de l'\u00e9quipe \u2014 non, nous avons pris des gens de diff\u00e9rents d\u00e9partements<\/strong>. Quelques points plus t\u00f4t, nous avons trouv\u00e9 diff\u00e9rents d\u00e9partements et diff\u00e9rents employ\u00e9s concern\u00e9s par le service en cours de transformation. Nous composons l'\u00e9quipe \u00e0 partir de ces personnes, car elle doit \u00eatre polyvalente \u2014 nous allons changer le processus de test, le processus de d\u00e9veloppement, et le processus de maintenance du service. Des comp\u00e9tences vari\u00e9es sont n\u00e9cessaires.<\/p>\n

En g\u00e9n\u00e9ral, nous prenons un d\u00e9veloppeur, un testeur et un ing\u00e9nieur \u2014 un de chaque, et avec eux, nous concevons une solution qui permet de fonctionner autrement.<\/p>\n

De pr\u00e9f\u00e9rence, ces personnes devraient avoir du poids dans l'organisation<\/strong>. Il peut \u00eatre n\u00e9cessaire de prendre un conservateur, m\u00eame si ce n'est pas id\u00e9al. Si nous avons une grande entreprise, tout le monde ne croira pas \u00e0 notre id\u00e9e, et certains peuvent mettre des b\u00e2tons dans les roues, par exemple en ne fournissant pas de stand. C'est l\u00e0 qu'intervient \u00ab l'autorit\u00e9 \u00bb \u2014 une personne respect\u00e9e avec une grande exp\u00e9rience, qui a gagn\u00e9 la confiance de ses coll\u00e8gues. L'autorit\u00e9 d'un collaborateur au sein de l'\u00e9quipe facilitera la t\u00e2che et le travail de l'\u00e9quipe temporaire. Les gens penseront :<\/p>\n

\u2014 Ah, ce mec g\u00e9nial que nous connaissons tous et aimons, il y est impliqu\u00e9 \u2014 il doit y avoir quelque chose \u00e0 voir avec DevOps !<\/em><\/p>\n

Nous fixons un objectif<\/h2>\n

\nNous avons r\u00e9uni des gens, choisi un service, examin\u00e9 les limitations, d\u00e9termin\u00e9 sur qui nous pouvons avoir une influence. Maintenant, nous devons d\u00e9finir un objectif et il doit \u00eatre clairement d\u00e9fini selon SMART<\/strong> \u2014 tout comme nous aimons.<\/p>\n

Sp\u00e9cifique \u2014 sp\u00e9cifique<\/strong>.<\/p>\n

Mesurable \u2014 mesurable<\/strong>. C'est un point tr\u00e8s important du SMART. Si vous ne pouvez pas mesurer quelque chose, vous ne pouvez pas le changer et comprendre ce que vous avez am\u00e9lior\u00e9 ou d\u00e9t\u00e9rior\u00e9.<\/p>\n

Atteignable \u2014 atteignable<\/strong>. Prenez en compte votre sp\u00e9cificit\u00e9. Si vous \u00eates une entreprise avec une longue histoire et beaucoup de responsabilit\u00e9s, qui sort une version de produit par an, vous ne pourrez pas atteindre la sortie de nouvelles versions chaque heure en six mois. Cela ne fonctionnera pas. Donc, fixez un objectif r\u00e9aliste qui peut \u00eatre atteint dans un d\u00e9lai acceptable.<\/p>\n

Pertinent \u2014 pertinent. <\/strong>Nous \u00e9liminons uniquement la contrainte qui affecte r\u00e9ellement nos objectifs actuels.<\/p>\n

Temporellement limit\u00e9 \u2014 limit\u00e9 dans le temps<\/strong>. S'il n'y a pas de d\u00e9lai, l'\u00e9quipe va faire n'importe quoi : essayer 15 technologies au lieu de 3, r\u00e9diger d'\u00e9normes rapports, mener des recherches inutiles, peaufiner leur impl\u00e9mentation \u00e0 la perfection alors que l'objectif est d\u00e9j\u00e0 atteint.<\/p>\n

Nous d\u00e9finissons l'objectif pr\u00e9cis\u00e9ment avec l'aide du Value Stream Map \u2014 nous rassemblons \u00e0 nouveau toutes les personnes et dessinerons. Mais cette fois, sur la base de la pr\u00e9c\u00e9dente Value Stream Map, nous allons dessiner ce que nous voulons obtenir.<\/p>\n

\"Comment
\n
\nNous identifions une contrainte que nous allons \u00e9liminer imm\u00e9diatement \u2014 c'est ce que l'\u00e9quipe va faire. Par exemple, j'ai pris l'attente entre la sortie d'une version finale et son d\u00e9ploiement en production \u2014 c'est la contrainte la plus fr\u00e9quente pour laquelle les gens font appel \u00e0 des consultants.<\/p>\n

\u00c0 partir de cela, nous formons la t\u00e2che : nous voulons que l'attente entre la version finale pr\u00eate et son lancement soit d'un maximum d'une heure.<\/p>\n

Exemples de t\u00e2ches.<\/p>\n