Les trois principes pour une production agileLe point de vue d’experts DevOps, avec notamment Gene Kim

2

DevOps et production agile : le point de vue d’experts du secteur

Quasiment toute discussion sur les DevOps met en évidence la transformation que subissent les équipes de développement lorsqu’elles passent de la conception séquentielle des méthodes en cascade à l’approche itérative et agile des méthodes Scrum. Et ce n’est pas étonnant, car il s’agit d’une transformation radicale et fascinante, qui offre des résultats impressionnants. Toutefois, le tournant tout aussi radical que doivent négocier les équipes de production IT est plus rarement évoqué. Traditionnellement associé à une stabilité prévisible, il peut sembler inapproprié de suggérer qu’il existe un nombre croissant de pratiques connues sous le terme de « production Agile ». Cela change cependant si nous considérons à quel point le Cloud Computing, les micro-services, les applications conteneurisées et autres bouleversent la définition même des infrastructures. Ces nouvelles infrastructures agiles et les concepts associés, tels que les défaillances planifiées, suscitent, voire imposent, une collaboration entre les équipes de développement (Dev) et les équipes de production (Ops).

Cela semble parfait sur le papier, mais pour une équipe de production IT traditionnellement évaluée, outillée et même rémunérée sur le maintien de la résilience au détriment du changement, comment faire pour adapter la discipline de production fondamentale sans exposer l’entreprise à un risque accru de fragilité technique ?

Quel que soit notre héritage technique, la réalité absolue du monde d’aujourd’hui est que le succès du commerce électronique impose un développement plus agile et des cycles de livraison plus rapides, ce qui implique que les exigences opérationnelles, les connaissances, les compétences, les processus et les outils doivent être définis bien plus tôt dans le cycle de développement des logiciels. Et pour parvenir à cela, une nouvelle approche est nécessaire, à savoir : une production agile.

La production agile ne résume plus à assurer le fonctionnement quotidien des technologies, mais implique de mettre en avant l’activité métier ; travailler en étroite collaboration avec l’équipe de développement en appliquant une approche système pour visualiser et accélérer un flux constant de valeur ajoutée pour les clients. Cela implique également d’adopter une automatisation, des outils et des méthodes pour amplifier la rétroaction interfonctionnelle, si importante pour améliorer la qualité et l’expérience client. Enfin, il s’agit de préparer l’entreprise pour l’avenir, en gérant les technologies à une autre échelle, bien sûr, mais sans surcharger l’organisation avec des coûts, des éléments et une complexité inutiles.

Modérateur

Kieran Taylor possède 20 ans d’expérience dans le marketing des produits high-tech, avec une expertise particulière en matière

de gestion des performances des applications, de Cloud Computing, de réseaux de distribution de contenu et de technologies de réseau étendu.

Il est actuellement Directeur principal Marketing produits et solutions chez CA Technologies et responsable du leadership d’opinion et de l’aide à la vente pour les solutions APM et CA qui aident les entreprises à mettre en œuvre les méthodologies DevOps.

Auparavant, il a dirigé des équipes de marketing produit chez Adobe, Akamai, DataPower/IBM et Nortel Networks. Il a commencé sa carrière en tant qu’éditeur de publications high-tech chez Mc-Graw Hill.

Pour mieux comprendre pourquoi tout le monde, y compris les équipes de production IT, doit s’impliquer dans l’approche DevOps, nous avons rencontré quatre leaders d’opinion et experts DevOps pour en discuter. Grâce à leurs connaissances approfondies du sujet, ils offrent un plaidoyer argumenté en faveur de la production agile et proposent des conseils pratiques pour s’y mettre immédiatement. Nous espérons que vous apprécierez cette lecture.

Gene Kim est directeur de la technologie, chercheur et auteur primé à de multiples reprises. Il est également fondateur et ancien directeur de la technologie de Tripwire. Auteur de trois ouvrages, il a également coécrit « The Phoenix Project ».

Benjamin Wootton est le cofondateur et conseiller principal de Contino, un cabinet de conseil britannique dont la mission est d’aider les entreprises à adopter les outils, les pratiques

et les approches DevOps et de livraison continue. Il a travaillé avec plus de 30 organisations sur des initiatives DevOps et de livraison continue, aidant les entreprises à proposer de meilleurs logiciels, plus rapidement et plus souvent. Avant cela, Benjamin s’est forgé une expérience de plus de dix ans en tant qu’ingénieur logiciel, responsable d’équipe, architecte et conseiller en transformation agile.

Steve Thair a cofondé DevOpsGuys en 2013, après une carrière de plus de 20 ans dans le domaine de la production et des infrastructures IT. Steve simplifie la gestion des applications en ligne en

faisant appel aux pratiques DevOps, en améliorant la livraison des applications, les performances et le délai de mise sur le marché sur l’ensemble de l’activité de développement logiciel. Steve écrit régulièrement dans ses blogs sur DevOps et a animé divers webinaires, rencontres Meetup et conférences pour présenter les avantages de DevOps. Il a également organisé la rencontre Meetup London Web Performance et lancé WebPerfDays London en collaboration avec VelocityConf, pour « accélérer l’évolution du Web ». Il organise depuis plus de trois ans le comité de suivi des performances Web pour Velocity EU.

Matthew Skelton conçoit, déploie et exploite des systèmes logiciels commerciaux depuis 1998. Cofondateur et consultant principal chez Skelton Thatcher Consulting, il aide les

organisations à adopter et à maintenir de bonnes pratiques pour développer et exploiter des systèmes logiciels : livraison continue, DevOps, aspects d’ITIL et opérabilité des logiciels. Fondateur et directeur du groupe d’échanges London Continuous Delivery (1 000 membres), Matthew est l’instigateur de la première conférence européenne axée sur la livraison continue, la conférence PIPELINE. Il a également contribué à populariser la célèbre série d’ateliers Experience DevOps et il est coéditeur de « Build Quality In », un livre de rapports d’expériences sur la livraison continue et la méthodologie DevOps.

3

Les experts

4

Question 1

Pour les compagnies qui souhaitent adopter des méthodes de développement et de déploiement agiles, quel sera le nouveau profil des personnes engagées pour diriger ces équipes ?

En laissant les « licornes » DevOps de côté pour examiner les « pur-sang » d’entreprise traditionnels,

prévoyez-vous (ou percevez-vous) un changement dans la culture des équipes de production ?Le stéréotype de la production IT est celui d’équipes stables au point d’être réticentes à toute prise de risque. Ces équipes assurent la maintenance d’infrastructures principalement statiques, exigent des outils de sécurité onéreux et imposent une mise en conformité, tout en offrant une faible flexibilité.

5

Question 1 : RÉPONSES

«  Les personnes qui s’épanouiront dans leur carrière de développement logiciel ou de production IT dans les cinq années à venir seront celles qui auront su briser ces silos pour tout optimiser. »

Je pense que cette image des équipes de production IT comme étant un frein à la prise de risque et au changement est parfois un peu surfaite. Les équipes de production IT ont toujours tenté de mettre sur la table des problématiques d’opérabilité valides et travaillent généralement en collaboration avec les équipes de développement pour mettre en œuvre avec succès les changements souhaités. Si ce stéréotype aussi négatif était une réalité, ces organisations auraient tout simplement fait faillite.

Le problème qui survient généralement est que l’équipe de production IT est impliquée trop tard dans le processus et n’a tout simplement pas son mot à dire au début ; cela donne alors l’impression qu’elle freine des deux pieds ou refuse tardivement toute initiative. Une implication plus précoce et plus active de l’équipe de production IT pourrait éviter cette situation et amener à une meilleure transition de service.

Heureusement, j’ai observé que cette dynamique entre la production IT et le reste des équipes IT était en train de changer. La nécessité de réduire les temps de cycle impose une relation plus collaborative pour faire face aux exigences en termes de rapidité et de normes de qualité. Les tendances telles que le Cloud et l’« Infrastructure As Code » font également remonter les préoccupations des équipes de production en amont du cycle de livraison. D’un autre côté, les développeurs doivent également s’intéresser davantage à l’ensemble de leur pile, et à l’environnement de production, car leurs piles d’applications deviennent de plus en plus complexes. Toutes ces tendances font évoluer naturellement la culture des équipes de production IT et la manière dont elles interagissent avec les équipes de développement.

Comme pour toute autre fonction IT, je pense que les compétences et les profils des acteurs de la production IT doivent évoluer, afin de s’éloigner de la spécialisation approfondie et de la pensée en silos qui était les leurs, pour adopter une approche plus généraliste, en collaborant sur la totalité du cycle de développement logiciel (SDLC, Software Development LifeCycle) pour optimiser le cycle de livraison dans son ensemble, plutôt que leurs responsabilités locales. Une équipe de développement hors pair et une équipe de production IT de classe mondiale, aussi excellentes soient-elles, ne peuvent en aucun cas fonctionner seules et doivent impérativement collaborer. Les personnes qui s’épanouiront dans leur carrière de développement logiciel ou de production IT dans les cinq années à venir seront celles qui auront su briser ces silos pour tout optimiser.

Wootton

6

Question 1 : RÉPONSES

«  La culture des équipes de production IT doit évoluer, afin de ne plus être un frein à la prise de risque. »

La culture des équipes de production IT doit évoluer, afin de ne plus être un frein à la prise de risque, car les entreprises elles-mêmes doivent aller dans ce sens. En 1960, la durée de vie moyenne d’une entreprise était de 60 ans. Aujourd’hui, elle est de 20 ans. Le temps dont une entreprise dispose pour croître et prospérer s’est donc réduit, et vous devez prendre plus de risques pour atteindre vos objectifs.

La culture interne des équipes de production IT doit étendre sa mission et se demander « comment pouvons-nous aider l’entreprise à atteindre ses objectifs ? ». Nous, en tant que membres de la production IT, ne pouvons pas poursuivre ce mode de fonctionnement cloisonné, que ce soit dans notre façon de penser, nos objectifs ou notre culture. Quel est l’intérêt de bénéficier d’une plate-forme d’applications Web avec une disponibilité de « cinq neuf » s’il est quasiment impossible d’appliquer des modifications dans cet environnement ? Et cela a encore moins de sens si votre entreprise fait faillite parce qu’elle n’a pas pu rester à la hauteur de la concurrence.

Heureusement, je pense que nous sommes aujourd’hui à un tournant très intéressant pour la production IT, car nous disposons désormais d’une nouvelle gamme d’outils extraordinaires qui nous permettent de réduire les risques et d’améliorer la conformité, tout en offrant un meilleur service à notre organisation en réduisant les temps de cycle de changement. C’est une situation gagnant-gagnant.

Thair

7

Question 1 : RÉPONSES

«  … le responsable de la production agile mettra en place une « ouverture aux changements » consciente des risques, basée sur les mesures et les métriques. »

Le responsable d’une production IT agile au XXIème siècle doit comprendre et trouver l’équilibre nécessaire entre, d’une part, la sécurité et la stabilité et, d’autre part, le développement, le déploiement et la distribution de nouvelles fonctionnalités, en mettant celles-ci en corrélation avec les besoins métier. En particulier, les équipes de production IT doivent distinguer les profils de risque distincts des différentes applications logicielles, en évitant une approche uniforme des changements.

Au lieu de parler de « gestion des changements », le responsable de la production agile mettra en place une « ouverture aux changements » consciente des risques, basée sur les mesures et les métriques.

Skelton

8

Question 1 : RÉPONSES

«  La personne responsable de la transformation DevOps doit toujours surmonter l’obstacle d’une bureaucratie de commande et de contrôle pesante et bien établie, ainsi qu’une culture de méfiance. »

Je trouve particulièrement intéressant que les principes DevOps soient actuellement appliqués à des organisations complexes et de grande taille, possédant souvent des décennies d’infrastructures et d’applications héritées. Cela démontre que les principes DevOps transcendent les technologies et peuvent s’appliquer à quasiment tous les types d’organisations dont le succès repose sur la technologie.

J’ai étudié les pratiques de grandes organisations telles que Disney, Nordstrom, CSG, Target, Blackboard, Raytheon et les US Citizen and Immigration Services. À mon sens, les histoires qui circulent à leur sujet sont aussi héroïques et inspirent autant le respect que tout ce qui peut se dire au sujet de Google, Amazon, Twitter ou Etsy.

J’ai été particulièrement interpellé par le fait que la personne responsable de la transformation DevOps doit toujours surmonter l’obstacle d’une bureaucratie de commande et de contrôle pesante et bien établie, ainsi qu’une culture de méfiance.1

J’ai aussi appris qu’il existe un but ultime : que la technologie devienne partie intégrante des équipes, avec une collaboration de tous les acteurs de la chaîne de valeur (par exemple, les équipes de développement, de test, de production, de sécurité des informations, etc.), pour aider l’organisation à prospérer sur son marché. Pour atteindre cet objectif, nous devons changer de culture, tout particulièrement les équipes de production IT, afin de ne plus nous considérer comme des « preneurs d’ordres » qui ne font qu’exécuter le travail demandé, mais devenir des membres de l’équipe à part entière, travaillant tous ensemble pour réaliser les objectifs de l’organisation.2

(1) Source : http://www.infoq.com/articles/interview-gene-kim-devops-enterprise

(2) Source : http://rewrite.ca.com/us/articles/devops/itil-and-devops-better-together.aspx

Kim

9

L’ouvrage « The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win » présente les trois principes de la pensée DevOps. Le premier principe met l’accent sur la valeur de l’ensemble du système, en soulignant particulièrement le flux de valeur métier généré par les processus, les procédures et les pratiques DevOps.

Copyright 2015 IT Revolution

Le premier principe : le flux

Question 2

L’IT étant traditionnellement organisée par fonction technologique, quels sont, selon vous, les changements nécessaires pour supporter cette nouvelle pensée plus rationnelle et orientée système ?

10

«  Une collaboration efficace, au cœur de DevOps, est essentielle pour réaliser des passages de relais rationalisés et efficaces. »

Comme vous l’avez dit, l’IT est traditionnellement organisée autour des technologies ou des domaines d’architecture, avec par exemple des équipes base de données, frontale et niveau intermédiaire. Nous observons aujourd’hui de nombreuses entreprises qui se réorganisent en équipes transverses composées de développeurs, de testeurs et d’ingénieurs production, centrées sur des produits ou des fonctions métier spécifiques. Cette collaboration interfonctionnelle réduit les passages de relais, favorise la responsabilisation et permet à l’équipe de fournir plus rapidement les logiciels, avec une réactivité accrue face au client. C’est ainsi que fonctionnent généralement les grandes entreprises de l’ère numérique, telles qu’Amazon et Netflix, et l’évidence d’un tel changement est souvent claire.

Par ailleurs, j’ai tendance à penser que la clé pour améliorer le temps de cycle est souvent de cibler les passages de relais entre les équipes de développement, de test et de production. Il est effectivement important de travailler efficacement lors d’une phase de cycle donnée, mais la pensée rationnelle montre que les pertes d’informations, les retards et les surcoûts ont lieu généralement au moment des passages de relais. Une collaboration efficace, au cœur de DevOps, est essentielle pour réaliser des passages de relais rationalisés et efficaces.

L’automatisation est également cruciale pour optimiser le flux de gauche à droite. L’automatisation des builds, de l’intégration, des tests et du déploiement permet d’accélérer la livraison, d’accroître la qualité et de rendre plus efficace le processus de livraison de logiciels. Bien entendu, l’automatisation à elle seule ne suffit pas, mais il s’agit souvent du critère le plus facile à modifier pour réduire le temps de cycle sans avoir recours à des changements majeurs et perturbants du mode de travail.

Pour revenir un peu en arrière, je pense que l’IT a eu tendance, par le passé, à privilégier la rigueur, la stabilité, la robustesse et la prévisibilité, au détriment de la rapidité et de l’agilité. Je suis convaincu que nous devons faire de la rapidité une priorité, sans, espérons-le, nuire à la qualité. Ce n’est que comme cela que nous saurons répondre aux demandes croissantes auxquelles doivent faire face les fonctions IT aujourd’hui.

Wootton

Question 2 : RÉPONSES

11

Question 2 : RÉPONSES

«  Nombre d’entre nous, malheureusement, continuons à parler de l’« IT » et du « métier » comme deux organisations distinctes. »

Deux principaux obstacles bloquent le « flux » au sein d’une organisation IT traditionnelle : les silos (la structure organisationnelle) et le modèle de financement par projet. Il est nécessaire de changer ces deux éléments pour pouvoir concrétiser véritablement la valeur métier de DevOps.

Le premier silo provient du fait que nombre d’entre nous, malheureusement, continuons à parler de l’« IT » et du « métier » comme deux organisations distinctes. Je suspecte que cette distinction date d’il y a bien longtemps, dans les années 50, lorsque le personnel IT travaillait encore en blouse blanche sur des ordinateurs monumentaux. Les ordinateurs étaient alors des machines mystérieuses, ésotériques, voire effrayantes. Les gens ne comprenaient pas leur fonctionnement et ne voulaient pas s’en approcher. Quant aux « grands prêtres de l’informatique », ils n’hésitaient pas à accentuer cette aura mystique qui leur donnait du prestige.

En revanche, aujourd’hui, les ordinateurs sont omniprésents. Le PDG de GE, Jeff Immelt, l’a d’ailleurs très bien expliqué : « Vous pouvez parfaitement vous coucher le soir en étant une société industrielle et vous réveiller le lendemain en étant un éditeur de logiciels. » Nous devons donc cesser de considérer l’IT comme étant séparée de l’activité métier de l’entreprise. Nous ne considérons jamais que le marketing ou les finances sont des entités distinctes de l’entreprise, alors pourquoi utiliser encore ce langage pour l’informatique ?

Le deuxième niveau de silo est celui que nous créons pour nous-mêmes en basant notre structure organisationnelle sur la fonction technologique, généralement dans un souci d’efficacité ou d’économies d’échelles.

Nous avons désormais compris que ce type de silo détruisait la productivité, la collaboration et le flux d’une manière telle qu’elle annule toute économie d’échelles. Les (plus que nombreux) passages de relais formels et lents entre les silos génèrent tant de friction dans ce processus qu’il est même étonnant qu’il donne malgré tout des résultats. Il semble parfois que 40 % des effectifs de l’organisation passent leur temps à empêcher 40 % d’autres effectifs de faire leur travail, laissant seulement 20 % d’entre nous travailler réellement.

Thair

Suite

12

«  Si nos employés ne peuvent pas faire le lien entre leur travail et une « vue d’ensemble » de l’entreprise, ils perdent pied. »

«  Pour résumer, créez des équipes et non des projets. »

Les silos ont également un impact sur le moral et la motivation du personnel. L’historien français Alexis de Tocqueville l’explique ainsi : « Il n’y a rien qui tende plus que la grande division du travail à matérialiser l’homme et à ôter de ses œuvres jusqu’à la trace de l’âme ». L’économiste Adam Smith avait averti que les travailleurs « devenaient ignorants et isolés si leur vie professionnelle se résumait à une même tâche répétitive ».

Si nos employés ne peuvent pas faire le lien entre leur travail et une « vue d’ensemble » de l’entreprise, ils perdent pied. C’est pour cette raison que nous pensons que la solution réside dans la création d’équipes DevOps pluridisciplinaires, organisées autour des services ou produits clients clés. Ces équipes transverses qui franchissent la barrière métier/IT, ainsi que les silos au sein de l’organisation IT, permettent aux membres du personnel de faire le lien entre leur travail et le succès du produit, jusqu’à la valeur ajoutée pour l’entreprise dans son ensemble et ses clients.

Le second obstacle qui entrave le flux est le modèle de financement par projet. Ce modèle présente trois inconvénients majeurs. En premier lieu, dans la plupart des organisations, pour justifier la mise en œuvre d’un projet, il est nécessaire de définir des exigences préalables, de prévoir les coûts et le calendrier, ainsi que de faire une vague estimation du retour sur investissement. Cela génère des ralentissements dans le flux de travail, sur l’ensemble du cycle de développement logiciel (SDLC). Deuxièmement, ces estimations, calendriers, plans, etc. deviennent bientôt leur propre raison d’être. Et vous vous retrouvez à livrer un plan plutôt que de la valeur métier.

James Smith, cofondateur de @DevOpsGuys, a parfaitement résumé cette situation après une visite à l’un de ses clients. Il a déclaré : « Je vois de nombreux PLANS affichés au mur, mais je ne vois pas beaucoup de TRAVAIL. » Quantités de murs sont couverts de diagrammes de Gantt indiquant le suivi par rapport aux plans prévus, mais la visibilité sur le travail en cours reste faible. Qui fait quoi, maintenant, et quelle valeur ajoutée cela apporte à l’organisation : voilà ce qui est important. La première étape de toute transformation rationnelle (ou DevOps) de l’organisation consiste à rendre le travail effectué visible et à comprendre quelle partie de ce travail offre une valeur ajoutée et quelle partie ne fait que brasser de l’air.

Et troisièmement, les projets sont, par définition, temporaires. Vous mettez une équipe sur pied, vous engagez des frais pour faire en sorte que cette équipe fonctionne bien, puis vous mettez tout cela à la poubelle pour recommencer à zéro. C’est un véritable gâchis. Au contraire, si vous choisissez de créer des équipes produit stables, optimisées pour le flux, dont les membres parviennent à voir le fruit de leur travail (boucle de feed-back), vous pouvez éviter ce gâchis inhérent au modèle par projet.

Pour résumer, créez des équipes et non des projets, et donnez à ces équipes du travail à la tâche, suivant les principes de la pensée rationnelle, en hiérarchisant ces tâches selon les bénéfices métier attendus.

Question 2 : RÉPONSES

Thair

13

Question 2 : RÉPONSES

Le changement organisationnel le plus important pour un fonctionnement DevOps efficace est d’organiser les équipes et de définir leurs responsabilités en fonction du flux de changements des produits et services, par exemple en « équipes service » ou « équipes produits ».

Cela modifie alors l’architecture des systèmes et des logiciels, afin de dissocier les logiciels d’une équipe de ceux d’une autre équipe ; excepté quelques stockages de données clés de coordination (référentiel d’artefacts, file d’attente de messages, agrégation de journaux, métriques), la plupart des infrastructures d’une équipe sont séparées d’une manière ou d’une autre de celles des autres équipes. Selon la loi de Conway, les logiciels des différentes équipes ne sont pas mélangés sur la même machine ou même sur un groupe de machines, mais isolés par équipe, afin de clarifier les frontières système.

Skelton

«  Organiser les équipes et définir leurs responsabilités en fonction du flux de changements des produits et services. »

14

Question 2 : RÉPONSES

«  Les éléments livrés sont donc la conséquence directe de la culture de l’organisation. »

La loi de Conway stipule que l’organisation dicte la manière dont le travail est effectué, car elle produit des conceptions qui reflètent sa propre structure de communication. Ainsi, si l’organisation dit que le travail sera organisé en mode cascade, alors le département Développement créera du code qu’il transmettra au département Test, qui lui-même le transmettra au département Production. Il en résulte des livraisons de très grande ampleur, associées à une faible capacité à identifier et à corriger rapidement les défauts, ce qui donne lieu à de graves problèmes de déploiement. Les éléments livrés sont donc la conséquence directe de la culture de l’organisation.

Dans les organisations DevOps, les équipes sont bien plus petites et le personnel de développement et de production travaille ensemble, si ce n’est dans la même équipe, au moins en étroite collaboration, afin non seulement de faire le travail correctement, mais de s’assurer que le produit est intégré, puis déployé de manière sûre et continue, dans l’environnement de production. L’organisation qui en résulte n’a pas du tout le même visage.

Une question très concrète se pose alors à ce sujet : à quoi ressemblera la prochaine génération de production centralisée dans une organisation complexe de grande ampleur ? L’un des modèles possibles consiste à regrouper les ingénieurs de production IT dans un même groupe, en tant qu’équipe fonctionnalité ou service. C’est là une configuration très intéressante du fait que, désormais, l’équipe de production a les mêmes objectifs que l’équipe service. Autre modèle possible, les équipes de production délaissent la prise en charge des systèmes d’émission de tickets pour créer à la place des outils automatisés qui permettent à d’autres personnes d’assurer ce travail en mode self-service. Un exemple concret de ce modèle est la notion de groupe partagé, qui permet avant tout d’augmenter la productivité. Comment faire pour rendre disponibles des environnements à la demande pour toute équipe fonctionnalité ou service qui le souhaite, et quels sont les mécanismes de déploiement qu’elles peuvent utiliser pour accéder à l’environnement de production ? Pour simplifier, il s’agit d’offrir aux équipes de développement le chemin le plus court vers une productivité et une fiabilité accrue.

https://enterprisersproject.com/article/2015/4/conversation-gene-kim-devops-waterfall-development-and-containers

Kim

Que faut-il que les équipes de production IT fassent différemment pour faciliter le feed-back droite-gauche ?

15

Question 3

Le deuxième principe : le feed-backLe deuxième principe suggère aux organisations d’« amplifier les boucles de rétroaction » et, en particulier, le feed-back droite-gauche ou aval-amont, autrement dit de la production vers le développement. Quels sont alors les changements de processus nécessaires pour créer et optimiser ces boucles de feed-back ?

Copyright 2015 IT Revolution

16

J’ai souvent observé des équipes de production IT qui semblaient ne pas avoir mis en place, ni même connaître, de processus pour faire en sorte que leurs exigences soient inscrites à l’ordre du jour. Elles avaient parfois essayé de le faire, mais sans résultat, et finalement abandonné l’idée de faire entendre leur voix. Cela est particulièrement dommage, car les équipes de production IT sont les plus proches du système et des utilisateurs. Elles devraient clairement être entendues et servir de guide pour les changements à appliquer. Mettre en place un processus de feed-back suffit généralement à lancer la machine pour atteindre l’objectif souhaité.

Lorsque les processus ne sont pas bien calibrés pour l’obtention des exigences et du feed-back de la production, de droite à gauche, j’ai observé que les préoccupations de la production IT étaient parfois perdues en chemin ou ne bénéficiaient pas de la priorité adéquate dans le backlog de produit, par rapport aux demandes de nouvelles fonctionnalités. Les nouvelles fonctions ont systématiquement préséance car elles ont un impact immédiat sur le chiffre d’affaires, tandis que les demandes non fonctionnelles et des équipes de production IT sont constamment placées en fin de liste. La conséquence, dans le temps, est que le système se dégrade, que la dette technique s’accentue et que les pratiques de travail au sein des équipes de production IT se retrouvent loin derrière les meilleures pratiques du secteur.

Comme pour tous les silos fonctionnels, je pense que la production IT a également son propre rôle proactif à jouer dans l’amélioration de la collaboration sur l’ensemble du cycle de développement logiciel. Impliquez les individus dans leur processus. Expliquez ce sur quoi vous travaillez et pourquoi ; partagez vos métriques, vos activités, vos problèmes et vos victoires. Les équipes de production IT doivent communiquer au reste de l’entreprise en quoi consiste leur rôle. Cela permettra à d’autres ingénieurs de développer de l’empathie pour le travail qu’elles effectuent. La transparence est toujours gagnante si vous souhaitez faire entendre votre voix.

Wootton

Question 3 : RÉPONSES

«  Les équipes de production IT devraient clairement être entendues et servir de guide pour les changements à appliquer. »

17

Voici également un exemple très concret qui explique pourquoi nous encourageons vivement le « feed-back droite-gauche », tout particulièrement dans le domaine de la supervision. Dans une organisation, il existe souvent une solution de supervision d’entreprise déployée uniquement en production. Nous recommandons à nos clients de mettre en place la même solution de supervision dans les environnements de développement et de test. De cette façon, le code développé est plus facile à superviser et cette supervision est testée avant que l’application passe en production. Conséquence, les problèmes de production sont détectés bien plus tôt dans le cycle de vie et tout le monde peut s’aligner dessus. C’est simple, mais efficace.

Question 2 : RÉPONSES

Wootton

Application d’une stratégie de supervision plus précoce

18

Question 3 : RÉPONSES

«  Assurez-vous que le personnel technique de production est impliqué dans la conception du produit, dès le début. »

Cette question est en réalité assez simple de mon point de vue (Ops) :

1. Assurez-vous que les « exigences opérationnelles » (appelées auparavant « exigences ou demandes non fonctionnelles ») sont clairement énoncées lors de la phase de conception et non pas reléguées au second plan par rapport aux exigences fonctionnelles (« métier »). Notez que le langage de séparation entre les exigences métier et les exigences IT ressurgit une fois de plus. L’activité IT fait partie intégrante de l’activité métier, et les exigences opérationnelles (de la production) correspondent à tout ce qui est nécessaire pour gérer le produit en toute sécurité, en production. Il ne s’agit pas d’exigences isolées ou accessoires par rapport à la livraison de la solution finie.

2. La façon la plus simple de réussir la première étape ci-dessus est d’éliminer le silo entre le développement et la production, et de garantir que le personnel technique de production est impliqué dans la conception du produit, dès le début, et par la suite systématiquement impliqué dans la planification des sprints, les réunions régulières, les rétrospectives et toutes les autres phases de la livraison agile (Scrum). Cela garantit une boucle de feed-back droite-gauche constante, de la production vers le développement.

3. Partagez le résultat des mesures effectuées. Le modèle DevOps C.A.L.M.S (Culture-Automation-Lean-Measurement-Sharing, Culture-Automatisation-Rationalisation-Mesure-Partage) met en lumière l’importance des mesures et des métriques pour suivre la progression de notre amélioration. Trop souvent cependant, les équipes de production IT ont la mauvaise habitude de masquer ces données dans des outils et des systèmes auxquels elles seules ont accès. Nous devons apprendre à mieux partager ces informations (le partage étant un autre des piliers clés du modèle C.A.L.M.S). Donnez aux équipes de développement accès au système de supervision, à la suite APM ou à l’outil d’analyse des journaux ; créez des tableaux de bord ; créez des filtres ; créez une API, etc. Donnez-leur accès aux informations, puis allez en discuter avec elles pour déterminer ce que ces données veulent dire, quelles sont les métriques clés et dans quelle direction vous souhaitez qu’elles évoluent. Donnez-leur les informations dont elles ont besoin pour prendre de meilleures décisions et améliorer vos logiciels.

Thair

19

Question 3 : RÉPONSES

Les groupes de production IT doivent apprendre à énoncer leurs exigences opérationnelles, d’une manière qui soit utile pour les équipes de développement : droits d’accès minimaux, connexion de première classe, traceurs pour les performances de code critique et diagnosticabilité, pour ne citer que ces exemples. Les équipes de production agile comprennent également la valeur des techniques agiles/rationnelles, telles que les rétrospectives, les réunions régulières informelles, la limitation des travaux en cours et le suivi du débit.

Skelton«  Les groupes de

production IT doivent apprendre à énoncer leurs exigences opérationnelles, d’une manière qui soit utile pour les équipes de développement. »

20

Question 3 : RÉPONSES

«  Plus le délai d’exécution est court, plus les résultats sont bons. »

L’un des meilleurs outils de prédiction en fabrication et en DevOps est le délai d’exécution (en termes de qualité et de satisfaction des clients/employés), c’est-à-dire dans quel délai pouvez-vous passer du code à la production, en passant par les tests. En général, plus ce délai est court, plus les résultats sont bons.

L’une des meilleurs façons de savoir comment les équipes de production peuvent aider avant la mise en production est d’effectuer une supervision de la production avant que celle-ci ait lieu, grâce à l’application de tests de performances réalistes dans un environnement de préproduction.

John Allspaw a affirmé un jour que, si vous prenez deux équipes, la première composée de développeurs et d’ingénieurs production qui travaillent chacun de leur côté et la seconde des mêmes personnes mais travaillant ensemble vers un objectif commun, la seconde sera plus performante dans tous les cas de figure.

https://channel9.msdn.com/Shows/Edge/Edge-Show-118-Gene-Kim-DevOps-Interview#time=11m54s

https://channel9.msdn.com/Shows/Edge/Edge-Show-118-Gene-Kim-DevOps-Interview#time=14m03s

Kim

Les équipes de production IT doivent-elles mettre en œuvre ce troisième principe et que peuvent-elles/doivent-elles faire différemment ?

21

Question 4

Le troisième principe introduit le concept d’expérimentation continue, dans un objectif d’optimisation continue. Suivant l’équipe concernée, l’expérimentation peut être déconseillée par la production ou présente uniquement au sein des équipes de développement.

Le troisième principe : l’expérimentation continue

Copyright 2015 IT Revolution

22

L’ensemble de l’organisation doit adopter ce troisième principe, et pas uniquement les équipes de production IT, avec une approche plus expérimentale, davantage d’innovation et d’optimisation continue dans les processus de travail. Dans le monde d’aujourd’hui, moderne, concurrentiel, numérique et logiciel, cette approche est essentielle pour rester dans la course, avec les meilleures pratiques IT. Dans le cas contraire, vous vous retrouvez rapidement à la traîne de la concurrence, qui arrive sur le marché sans technologies ni processus hérités.

Conséquence de cette situation, l’ensemble de la fonction IT a besoin de temps, d’espace et de ressources pour optimiser ses plates-formes, ses outils et son mode de fonctionnement. L’organisation IT est souvent sous la pression permanente de l’équipe « métier », qui lui demande constamment de livrer de nouvelles fonctionnalités. Toutefois, un département IT est comme une voiture, il a besoin d’entretien et de réparations pour pouvoir fonctionner avec une efficacité optimale. Les organisations et les dirigeants intelligents accepteront cet état de fait et investiront dans la plate-forme et dans des méthodes de travail, outre la pile d’applications visible.

Les équipes de production IT doivent être en charge de cette activité autant que celles de développement. Elles sont sous pression du fait du volume d’infrastructures croissant qu’elles doivent supporter, ainsi que des piles d’applications et des changements plus complexes qui leur arrivent plus fréquemment. Si ces équipes ne continuent pas à innover et à évoluer, leur travail deviendra de plus en plus difficile jusqu’à ce qu’elles deviennent au final un obstacle à l’innovation. Les équipes de production IT ont besoin de dirigeants forts, qui clarifient ces problématiques pour les parties prenantes et informent toute l’organisation lorsque leurs initiatives sont couronnées de succès et apportent une valeur ajoutée.

Wootton

Question 4 : RÉPONSES

«  Un département IT est comme une voiture, il a besoin d’entretien et de réparations pour pouvoir fonctionner avec une efficacité optimale. »

23

Question 4 : RÉPONSES

«  Les équipes de production IT doivent commencer leurs propres expérimentations. »

Le coût de l’expérimentation a toujours été élevé par le passé. Il était nécessaire de provisionner l’infrastructure pour effectuer ces expériences et le coût de déploiement de celles-ci (et d’annulation) était important du fait de la charge de travail manuel requis. La virtualisation, le Cloud Computing et les outils d’automatisation DevOps ont cependant totalement changé la donne. Nous pouvons désormais provisionner rapidement et facilement les infrastructures et déployer des applications d’un simple clic, et nous payons uniquement pour ce que nous utilisons selon le modèle Cloud de tarif basé sur la consommation.

Vous souhaitez savoir comment se comporteront votre application et vos systèmes de supervision avec 200 serveurs Web frontaux ? Rien de plus simple : lancez l’expérimentation dans le Cloud, en simulant une charge, puis fermez tout une fois l’expérience terminée. Le coût total est quasiment nul comparé à ce qu’il aurait été il y a 10 ans.

La situation commence également à bouger de façon intéressante dans le domaine de la virtualisation de bases de données (clonage de base de données instantané avec déduplication des données, afin de provisionner rapidement de nouvelles instances de test complètes de la base de données, avec données de test de qualité) et de la virtualisation de services (afin de pouvoir virtualiser facilement des services Web back-end tiers, pour les utiliser dans des expériences), augmentant ainsi les économies réalisées. Nous disposons aussi aujourd’hui d’une large gamme de nouveaux outils permettant de mesurer l’application et la plate-forme sous-jacente lors des expériences.

Les équipes de production IT doivent adopter ces nouvelles approches économiques et commencer leurs propres expérimentations. Dans sa présentation lors de la conférence QCON London 2014, Dave Farley (coauteur de l’ouvrage « Continuous Delivery ») a comparé ce phénomène à l’application de la méthode scientifique. Nous devons commencer à mettre nos opinions à l’épreuve à l’aide de faits et de données consolidées, au lieu de nous contenter d’hypothèses et de suppositions.

Thair

24

Question 4 : RÉPONSES

Une culture de l’apprentissage et de l’expérimentation guidée au sein des équipes de production IT est essentielle si celles-ci souhaitent offrir une valeur ajoutée réelle à leur organisation. Les priorités doivent être guidées par un sens aigu d’amélioration continue des services : l’équipe de production IT se voit créer et améliorer des éléments clés dans les systèmes logiciels. Les efforts d’expérimentation et d’amélioration en production doivent être joints à ceux des équipes de développement.

Skelton

« Une culture de l’apprentissage et de l’expérimentation guidée est essentielle. »

25

Question 4 : RÉPONSES

«  Une amplification continue du processus de création d’une culture de sécurité, d’expérimentation et d’apprentissage. »

Le troisième principe consiste en une amplification continue du processus de création d’une culture de sécurité, d’expérimentation et d’apprentissage. Dans l’espace DevOps, j’estime que cette philosophie est parfaitement mise en pratique par Adrian Cockcroft. Réputé dans de nombreux domaines, il a récemment défrayé la chronique avec son travail pour Netflix, en transformant l’architecture J2EE encapsulée de Netflix, fonctionnant en data center, pour la remplacer par un fonctionnement totalement Cloud. Il a déclaré à cette occasion : « Notre objectif est de frapper plus fréquemment là où ça fait mal, pour que cela soit moins douloureux à l’avenir. Alors, même si nous faisons parfois vivre aux développeurs un véritable enfer, ils nous répondent toujours : « Merci. Merci beaucoup, car nous savons que ce que nous faisons aujourd’hui nous simplifiera la vie dans le futur. »

Et la meilleure preuve de l’efficacité de cette philosophie et de cette approche, à mon sens, a été la première interruption de service d’Amazon EC2 en 2011. Tous ceux qui utilisaient EC2 à cette époque se souviendront parfaitement de ce jour, où ils se sont tous retrouvés à l’arrêt. Tous à une exception près : Netflix. Pendant des semaines, tout le monde s’est demandé comment le personnel de Netflix avait pu éviter cette interruption. Et la réponse a été dévoilée quelques semaines plus tard, avec la diffusion d’un billet de blog historique qui a révélé deux éléments majeurs : le premier était la décision qu’ils avaient prise très tôt de ne jamais dépendre d’Amazon pour assurer leur disponibilité, ce qui revient à affirmer qu’Amazon ne répondrait jamais présent au moment où ils en auraient le plus besoin ; le second était que, s’ils souhaitaient pouvoir survivre à une défaillance, ils devaient subir des défaillances en permanence. Et c’est là qu’ils ont dévoilé ce que nous connaissons tous aujourd’hui sous le nom de « Chaos Monkey ».

Kim

Copyright © 2015 CA. Tous droits réservés. Tous les noms et marques déposées, dénominations commerciales, ainsi que tous les logos référencés dans le présent document demeurent la propriété de leurs détenteurs respectifs.

Ce document est fourni à titre d’information uniquement. CA décline toute responsabilité quant à l’exactitude ou l’exhaustivité des informations qu’il contient. Dans les limites permises par la loi applicable, CA fournit le présent document « tel quel », sans garantie d’aucune sorte, expresse ou tacite, notamment concernant la qualité marchande, l’adéquation à un besoin particulier ou l’absence de contrefaçon. En aucun cas, CA ne pourra être tenu pour responsable en cas de perte ou de dommage, direct ou indirect, résultant de l’utilisation de ce document, notamment la perte de profits, l’interruption de l’activité professionnelle, la perte de clientèle ou la perte de données, et ce même dans l’hypothèse où CA aurait été expressément informé de la survenance possible de tels dommages.

CA ne fournit pas d’assistance juridique. Ni ce document ni aucun produit logiciel CA référencé dans le présent document ne peuvent être substitués à l’obligation du lecteur de respecter la législation en vigueur, notamment sous forme de loi, règlement, réglementation, règle, directive, norme, mesure, politique, instruction administrative, décret-loi, ou autre (désignés collectivement sous le nom de « Lois »), évoquée dans le présent document. Le lecteur doit consulter un conseiller juridique compétent pour toute information concernant lesdites Lois.

CS200-140656_0715

CA Technologies (NASDAQ : CA) fournit les logiciels qui aident les entreprises à opérer leur transformation numérique. Dans tous les secteurs, les modèles économiques des entreprises sont redéfinis par les applications. Partout, une application sert d’interface entre une entreprise et un utilisateur. CA Technologies aide ces entreprises à saisir les opportunités créées par cette révolution numérique et à naviguer dans « l’Économie des applications ». Grâce à ses logiciels pour planifier, développer, gérer la performance et la sécurité des applications, CA Technologies aide ainsi ces entreprises à devenir plus productives, à offrir une meilleure qualité d’expérience à leurs utilisateurs, et leur ouvre de nouveaux relais de croissance et de compétitivité sur tous les environnements : mobile, Cloud, distribué ou mainframe. Pour en savoir plus, rendez-vous sur ca.com/fr.

Comme nous pouvons le constater, l’impact de la production agile est majeur. Alors lançons-nous dans l’aventure.

Découvrez le point de vue de vos pairs et d’experts du secteur sur la façon dont les méthodes de production agile peuvent améliorer la rapidité et la portée du déploiement d’applications, tout en garantissant une haute qualité et une excellente expérience utilisateur.