Quelle métrique pour fédérerDev & Ops ?Think Tank Automic

Livre Blanc

DevOps : Retours d’expérience et bonnes pratiques issus du Think Tank Automic

Livre Blanc

Follow Us2

Quelle métrique pour fédérer Dev & Ops ?DevOps : Retours d’expérience et bonnes pratiques issus du Think Tank Automic

Texte établi parGérald AudenisFrançois BazenetEric BouvetThierry Falque-VertCharlotte GondreJosé MauricioJérôme MeyerFrédéric PoulainAlexandra Sommer

RédactionAlexandra Sommer

GraphismeEmilie Daboussy

Produit parAutomicTour Pacific11, cours Valmy92800 PuteauxFrance

Copyright © 2016 Automic Software S.A.S. Tous droits réservés. La copie, photocopie, reproduction,

traduction ou conversion de ce livre blanc sous quelque forme que ce soit, mécanique ou électronique,

est interdite sans autorisation préalable obtenue par écrit auprès de Automic Software S.A.S.

Livre Blanc

TABLE DES MATIÈRESPréface 4

Chapitre 1 : Un indicateur mutant pour fédérer Dev & Ops 8

Chapitre 2 : Le TRS, un KPI sans équivalent dans l’informatique 12

Chapitre 3 : Implémentation du TRS en environnement DevOps 15

Etape 1 : Intention 16

Etape 2 : Identification du périmètre d’application 16

Etape 3 : Implication 17

Etape 4 : Partage du vocabulaire 18

Etape 5 : Etat des lieux du système de mesure 19

Etape 6 : Collecte des points de mesure 21

Etape 7 : Premières mesures 22

Etape 8 : Analyse des gaspillages 22

Atelier Arbre des Gaspillages 23

Atelier TIMWOOD 26

Etape 9 : Système de pilotage 28

Etape 10 : Industrialisation 29

A propos du Think Tank Automic 31

Livre Blanc

Follow Us4

PréfaceDevOps est né en 2009 après qu’un administrateur système (sysadmin) du nom de Patrick Debois a fait le constat que l’Agile, pour être pleinement efficace, devait nécessairement embarquer toute les équipes de la DSI : Dev (développement) et Ops (opérations). Le mouvement DevOps a connu par la suite un essor rapide en rassemblant sous sa bannière un ensemble de technologies et de pratiques permettant des mises en production plus petites, plus fréquentes et moins risquées. En 2010, les valeurs essentielles de DevOps étaient résumées sous forme d’un acronyme : CAMS pour Culture, Automatisation, Mesure et Partage (Sharing, en anglais).

La mesure est ainsi, depuis ses débuts, l’un des piliers de DevOps*. C’est aussi l’un de ses territoires les moins explorés et les moins documentés. Le présent Livre Blanc cherche à répondre à une question simple : Comment mettre en place une mesure adaptée à DevOps, qui facilite le rapprochement entre équipes Dev et Ops et qui offre une vision objective et utile de la performance ?

Nous espérons que la réponse que nous proposons ici de manière très concrète retiendra votre attention et vous donnera envie de la mettre en pratique. Dans tous les cas, cette réponse n’aurait pas pu voir le jour sans un certain nombre de rencontres, incarnées par des personnes que nous tenons à remercier chaleureusement :

• Rencontre avec l’industrie, toujours à la pointe en matière de performance, en la personne de Christian Hohmann, expert en Lean Manufacturing de réputation internationale,

• Rencontre avec des managers de production informatique visionnaires, avec qui nous avons transposé depuis 2010 les standards de performance industrielle à la production informatique. C’est leur travail de tous les jours, dans leurs organisations, qui a permis d’apporter une réponse pratique tant sur le « quoi » de la mesure que sur le « comment » de sa mise en œuvre.

• Rencontre avec des managers de développement informatique, de la même étoffe, qui ont permis depuis 2014 d’établir une vision de bout en bout de la performance de la DSI tout en apportant une diversité bienvenue dans les approches.

En 2015, comme chaque année depuis 2010, ces rencontres ont eu lieu dans le cadre de la communauté du Think Tank Automic, dédiée à la mesure de la performance.

*Dans son enquête 2015 « Adoption et Enjeux de DevOps en France », IDC indique que la définition d’indicateurs communs pour Dev et Ops est un critère clé de succès pour 69% des organisations en cours d’adoption de DevOps.

Livre Blanc

Follow Us5

Nous tenons à remercier de tout cœur tous les managers qui y ont participé pour leur engagement, leur esprit de partage, leurs idées et leur capacité hors norme à les mettre en pratique et sommes très reconnaissants d’avoir pu travailler cette année avec :

• François BAZENET, CAISSE DES DEPOTS

• Patrice BENOIT, CCI PARIS ILE DE FRANCE

• Nicolas BOGUCKI, INSTITUT NATIONAL DE L’AUDIOVISUEL

• Pierre-Yves BOUCHARD, ANTEMETA

• Eric BOUVET, ARKEMA

• Didier CANITROT, EULER HERMES

• Cyrille CARTIER, ANTEMETA

• François GILLES, RECTORAT DE VERSAILLES

• Geneviève GLEIZES, CCI PARIS ILE DE FRANCE

• Charlotte GONDRE, RECTORAT DE VERSAILLES

• Gilles LAVIGNE, POLE EMPLOI

• José MAURICIO, BRED

• Frédéric POULAIN, EDENRED FRANCE

• Olivier SOULABAILLE, SECURITAS

• Etienne TAROT, LACTALIS

Merci tout particulièrement à Charlotte Gondre et Eric Bouvet pour l’animation des groupes de travail DevOps et ITIL dont les travaux, loin de s’opposer, se sont nourris mutuellement dans l’intérêt de tous.

Un grand merci également à tous ceux qui ont participé à la rédaction des publications antérieures du Think Tank Automic. L’expérimentation d’un indicateur synthétique en environnement DevOps n’aurait pas pu être aussi rapide sans s’appuyer notamment sur le “guide pratique d’implémentation du Taux de Rendement Synthétique (TRS)”, paru en 2015. Nous en reprenons ici les éléments indispensables pour que le lecteur n’ait pas besoin de s’y référer.

Merci, enfin, aux équipes Automic qui ont, année après année, œuvré à rendre toutes ces rencontres passionnantes, productives et conviviales. Merci à Jérôme Meyer et à Michel Enkiri pour la coordination métronomique des groupes de travail. Merci à Gérald Audenis, Thierry Falque-Vert et Nathan Srour pour l’animation experte des sessions de travail et ateliers. Merci à Alexandra Sommer pour l’organisation irréprochable des événements et la mise en forme impeccable des publications.

Livre Blanc

Follow Us6

LES MEMBRES DU THINK TANK TÉMOIGNENT...

« Membre du Think Tank depuis plusieurs années, j’ai pu bénéficier dans mon quotidien de l’immense travail de groupe tournant autour de l’idée qu’il est possible dans l’IT comme dans l’Industrie d’identifier la Performance de notre activité et de nos organisations. Trouver un moyen de Mesurer a été la toute première étape complétée avec succès par l’équipe initiale. Mais elle s’est rapidement complétée grâce à l’arrivée de nouveaux membres par la phase d’identification des gaspillages puis enfin par la phase de correction pour boucler par une nouvelle campagne de mesure… La roue de Deming avait fait un premier tour, il ne s’agissait plus que de consolider pour progresser et ce fut la rédaction des Livres Blancs. Encore bravo à tous et surtout un grand MERCI ! »

Pierre-Yves Bouchard – Directeur de Production Cloud - ANTEMETA

« J’ai participé aux travaux du Think Tank dès sa création en 2010. Débattre sur l’intérêt de transposer à l’Informatique un indicateur de performance issu de l’Industrie fut passionnant. Expérimenter puis industrialiser la démarche sur le Service Desk et des processus clefs (gestion des mises en production, gestion des événements) pour piloter la performance, parfois dans un contexte international, le fut encore davantage.Aujourd’hui, les entreprises et les administrations disposent, au travers des livres blancs, d’une méthodologie et des retours d’expérience documentés. De quoi faciliter l’adoption et accélérer la mise en œuvre en quelques semaines seulement, alors que plusieurs mois étaient requis lors des premières expérimentations. »

Eric Bouvet, Responsable IT Operations - ARKEMA

« Le groupe de travail DevOps est une bonne illustration de l’intelligence collective. Les échanges sympathiques et riches nous ont permis de mieux penser nos processus de travail transverse, de les améliorer et de s’initier aux indicateurs synthétiques. Thanks Think Tank ! »

Geneviève Gleizes, Responsable technologies transverses et Développement Web DPMA - DPSI - CCI PARIS ILE DE FRANCE

« En appliquant simplement la méthode et grâce aux échanges avec les participants, j’ai pu mettre en place rapidement un indicateur pertinent pour mesurer la performance de notre nouvelle chaine de déploiement pour une application stratégique, dans un esprit DevOps. »

Frédéric Poulain, Responsable Système & Réseaux - EDENRED

« Un partage très riche et unique d’expériences avec nos pairs actuels (OPS) et futurs (DEV). Des échanges constructifs en toute transparence intégrant les besoins et contraintes de chacun. Et du concret, un indicateur de référence pour mesurer l’impact de la mise en œuvre de DevOps en terme de valeur Business. »Didier Canitrot, Head of GIP Process and Service Design - EULER HERMES

Livre Blanc

Follow Us7

« La direction des systèmes d’information de Météo France est soumis à des contraintes de marché et d’adaptation aux normes qui nécessitent des mises en production rapideset sûres. La mise en oeuvre d’indicateurs de bout en bout, caractéristique du DevOps est en cours. C’est en suite des réunions et présentations du Think Tank Automic que ces idées on pris de la substance et sont devenues plus concrètes. »

Daniel Dure, Directeur des Systèmes d’Information - METEO FRANCE

« Nouveau Think Tank, nouvelles rencontres et toujours des résultats à forte valeur ajoutée. Le partage des réussites et des difficultés de chacun permet au groupe de progresser … Besoin d’un TRS pour mesurer ces progrès ? »

Gilles LAVIGNE, Directeur Adjoint des Opérations - POLE EMPLOI

« Travailler à définir, puis à évaluer, des points de mesures de qualité, de disponibilité et de performance d’une chaine de production logicielle en mode « DevOps » a permis de confronter la théorie d’un modèle synthétique, celui du TRS, à la réalité opérationnelle. Le résultat a dépassé nos attentes . Il s’avère en effet qu’une définition et une analyse concertée des mesures favorisent la cohésion des équipes DEV (Etudes) et OPS (Exploitation). Ceci contribue à rendre de fait les équipes acteurs de la conduite du changement DevOps et à en mesurer de façon factuelle les gains pour servir l’objectif premier de la DSI à savoir la satisfaction des clients. »Charlotte Gondre, Chef du Service Etudes & Développement - RECTORAT DE VERSAILLES

Livre Blanc

Follow Us8

Chapitre 1 : Un indicateur mutant pour fédérer Dev & OpsUne affaire non résolue : DevOps & la mesureDevOps a connu un essor fulgurant depuis son apparition au tournant des années 2010. En l’espace de cinq ans, près d’un tiers des organisations informatiques se sont lancées dans l’aventure DevOps, au moins sur un pilote. Le principal moteur de cette transformation est l’ambition affichée de réduire le délai entre l’expression d’une idée et son activation en environnement de production (Time to Production).

Mais au fait, quel est aujourd’hui votre Time to Production ? De combien s’est-il amélioré ?La question peut sembler provocatrice à l’heure où la Mesure est affichée comme l’un des quatre piliers de DevOps. Pourtant, l’expérience montre que la pression continuelle portée sur la livraison de projets toujours plus urgents empêche les organisations de réfléchir à leur système de mesure et de répondre à ces questions basiques. Le développement enchaine les sprints et puis, un beau jour, les features finissent bien par arriver en production. Mais quand ? Avec quel impact ? Et à quel prix ?

La mesure dans DevOps est bel et bien une affaire non résolue. Il suffit d’évoquer la question avec des personnes confrontées au sujet pour que reviennent les questions suivantes :

• Comment contrôler le fonctionnement et mesurer les progrès d’une chaîne de delivery Agile ?

• Comment mesurer la Performance de bout en bout plutôt que celles des Dev et des Ops en silo ?

• Comment éviter les indicateurs toujours verts qui masquent les problèmes (l’effet “Dev-Oups”) ?

• Comment amener Dev et Ops à mieux prendre en compte leurs contraintes respectives ?

• Comment gagner en lisibilité et ne pas se laisser submerger par une information surabondante (Dashboard Everything) ?

La vérité est ailleurs : Un standard industriel, le TRS Les mesures existantes apparaissent inopérantes pour fédérer Dev et Ops car elles sont en décalage profond avec les enjeux collaboratifs de DevOps. Les KPIs reflètent le cloisonnement des organisations. Les Opérations ne se retrouvent pas dans les métriques Agiles. Les Etudes ne se retrouvent pas dans les SLAs. Les outils fonctionnent « en silo » et ne permettent pas une vision de bout en bout.

Livre Blanc

Follow Us9

Il fallait donc chercher la vérité ailleurs que dans l’informatique. En l’occurrence, nous avons trouvé l’inspiration dans l’industrie, confrontée depuis des décennies aux enjeux d’agilité et de fiabilité au point d’avoir établi un standard de mesure de la performance : le Taux de Rendement Synthétique (TRS). Largement répandu dans les environnements industriels, cet indicateur n’est pas un indicateur de plus mais bien la clé de lecture principale de la performance pour les directeurs d’usine.

Notre démarche a simplement consisté à appliquer ce standard industriel à un nouveau type d’usine : la digital factory. Nous avons voulu transposer le TRS en environnement DevOps et valider sa pertinence en environnement réel. Nous avons voulu en faire un indicateur commun qui permette de gagner en lisibilité et de piloter la Performance globale de la chaîne de delivery de la DSI, plutôt que les performances locales au niveau des Dev et des Ops. Nous avons voulu également nous inspirer des méthodes d’analyse et d’amélioration continue qui sont utilisées dans le sillage du TRS comme l’arbre des gaspillages ou la méthode TIMWOOD.

Des résultats concrets : Bonnes pratiques & Retours d’expérience Les résultats présentés dans ce Livre Blanc sont le fruit d’un travail d’équipe. Pour garantir des résultats concrets, chaque membre du Think Tank Automic s’est engagé personnellement à produire une mesure dans son propre environnement. L’approche communautaire et collaborative a fait le reste : le fait d’avancer de concert et de confronter l’expérience de chacun à chaque étape a permis d’aller plus vite et d’aborder la mise en œuvre avec confiance.

Dans un premier temps, le groupe a convergé sur la définition d’un TRS transposé à la chaine de delivery logiciel. Cette définition est intervenue à deux niveaux. Le niveau général définit ce qui doit être mesuré (le quoi). Le niveau détaillé propose différents indicateurs permettant de le mesurer (le comment). Il existe en effet différents moyens de mesurer le TRS selon la capacité d’une organisation à produire certaines mesures. Certaines mesures, plus simples, sont suffisantes dans une première approche et permettent de franchir un premier pas significatif en matière de pilotage. Cette définition flexible a permis de construire une boite à outils générique adaptable aux contextes des différents membres.

Dans un second temps, le groupe a mesuré le TRS à partir de cette définition. Les premiers résultats ont été suivis mensuellement. Ils ont permis de valider la pertinence de la mesure et son intérêt tant pour l’identification de pistes d’amélioration que pour sa capacité à fédérer équipes Etudes et Production. Des ateliers spécifiques ont été conduits durant cette phase pour rentrer dans l’analyse des gaspillages et identifier des plans de remédiation. Les retours d’expérience ont été partagés entre membres

Livre Blanc

Follow Us10

que ce soit pour l’adoption ou pour l’usage du TRS.En fin d’année, les membres sont revenus sur les bonnes pratiques qu’ils souhaitaient partager suite à leur propre expérience de la mise en place du TRS. Ces conseils sont présentés dans le tableau ci-dessous.

Les enseignements : La mesure est un outil collaboratif très efficaceAu-delà des résultats détaillés dans les chapitres suivants, il est ressorti de cette année de travail en communauté que la mesure était un outil collaboratif extrêmement puissant.

La mesure aide à fédérer et à faire adhérer. On réduit trop souvent DevOps à l’automatisation et à la technologie et on oublie par la même occasion la dimension du partage qui est essentielle. A la base DevOps est une question de culture, de communication, de confiance, de collaboration. Au sein des organisations qui l’ont mis en place, la mesure a amené Dev et Ops à travailler ensemble sur des indicateurs communs et a contribué à transformer la culture. La volonté de s’améliorer ensemble en est ressortie renforcée.

Expérimentation du TRS : Bonnes pratiques

1 Assimiler la méthode

• Avoir une vision claire du TRS et une bonne compréhension du modèle• Développer une certaine curiosité• Partager les retours d’expérience à travers des Think Tank par exemple

2 Procéder par étape

• Cibler et définir un périmètre d’application restreint et maîtrisé• Se remettre en cause continuellement• Ne pas hésiter à adapter le périmètre ou les définitions au fur et à mesure que l’on comprend mieux le modèle

3 Partager / Impliquer

• Communiquer autour du TRS, privilégier la collaboration et le partage des besoins• Partager les mesures et en conséquence les processus• Réfléchir aux modalités d’analyse des écarts en impliquant les équipes

4 Démontrer la valeur• Impliquer les acteurs du terrain• Proposer des plans d’actions pragmatiques et priorisés• Capitaliser sur les quick-wins

5 Pérenniser

• Penser à la gestion du cycle de vie du TRS et son maintien en condition opérationnelle• Penser à revoir et à réactualiser les objectifs et critères de mesure• Inscrire l’ensemble des indicateurs dans les standards

Livre Blanc

Follow Us11

Un moyen pratique d’établir un dialogue. La Mesure ne doit pas être imposée mais présentée comme un moyen d’établir un dialogue. La Mesure ne doit pas être un projet uniquement Dev ou uniquement Ops mais être conçue de façon concertée. La Mesure ne doit pas se focaliser sur le chiffre mais apporter une discussion entre équipes. Les membres du Think Tank ont construit leur TRS ensemble, avec leurs équipes dans une approche résolument Bottom-up.

Le TRS permet d’aller vite à l’essentiel. Tout le monde veut mesurer mais rares sont ceux qui prennent le temps de mettre les mesures en place. Le TRS présente l’intérêt de pouvoir être implémenté rapidement, quitte à ce que la mesure soit embryonnaire dans un premier temps. Le cadre de définition général permet d’aller vite sans rien oublier d’essentiel. La valeur vient ensuite en marchant : On commence avec ce qu’on sait faire et on progresse au fur et à mesure. Les résultats sont apparus comme très pertinents même à partir de mesures partielles. Par ailleurs, la méthode en 10 étapes présentée au Chapitre 3 est une aide précieuse pour avancer pas à pas et franchir des étapes clairement identifiées.

Cultiver un état d’esprit collaboratif. L’avantage des mesures, c’est qu’elles sont factuelles, objectives, transparentes, honnêtes et partagées. Pour en tirer le meilleur parti, il faut se mettre en position d’écoute de l’autre et accepter que l’on ait des choses à améliorer. Par ailleurs, la discussion sur les mesures à mettre en place nécessite de s’écouter pour se comprendre : Dev et Ops ne mettent pas toujours la même chose derrière un même terme. Du point de vue du manager, il importera d’être bienveillant et de ne pas mettre en place la mesure dans un objectif de sanction. Compte-tenu que le TRS est un indicateur de progrès, sa valeur est par définition non optimale (c’est-à-dire loin de 100% !) et il est recommandé de s’axer sur la variation de l’indicateur, et non sur sa valeur absolue. En tout état de cause, la communication est clé !

L’essayer c’est l’adopter ! Dans un premier temps, le principe d’un indicateur unique permettant de mesurer la « performance de DevOps » a laissé certains membres dubitatifs. Les mêmes sont aujourd’hui les premiers convaincus que « ça marche ». La mesure leur a en effet permis de cimenter une culture de collaboration. Ils ont pu constater que la recherche de l’amélioration continue est bel et bien partagée par les équipes Ops & Dev. A partir du moment où ils se sont mis d’accord pour définir des indicateurs factuels et objectifs et les analyser ensemble, le dialogue s’est établi ainsi que la confiance. Du point de vue des managers, la valeur la plus importante a été trouvée dans le travail mené en commun avec les équipes. Le TRS est un moyen efficace d’y parvenir en un temps record !

Livre Blanc

Follow Us12

Chapitre 2 : Le TRS, un KPI sans équivalent dans l’informatiquePlusieurs années d’expérimentation dans le cadre des activités du Think Tank Automic ont permis de révèler que deux indicateurs standards en environnements industriels apportaient une réponse pratique efficace aux besoins de partage et de pilotage des organisations informatiques :

• Le Taux de Rendement Synthétique (TRS), qui mesure la performance d’une unité de production,

• Le Taux de Rendement Global (TRG), qui intégre la charge effective de ce moyen de production.

Ces indicateurs présentent plusieurs caractéristiques originales en environnement informatique :

• Lisibilité : Ce sont des indicateurs synthétiques, obtenus par la multiplication d’autres indicateurs, permettant de suivre en un coup d’œil l’évolution de la performance. Cela permet de mieux partager objectifs et résultats avec les clients, les équipes de la DSI ou la Direction Générale.

• Amélioration : Ce sont des indicateurs de progrès, qui n’ont pas vocation à atteindre 99,9% ou 100%. Des taux de 60% ou 70% sont fréquents, même en fonctionnement normal. Cela permet d’analyser les dysfonctionnements et de constater les améliorations.

• Bout-en-bout : Ce sont des indicateurs composites qui intègrent d’une part la qualité de la production (vue client) et d’autre part l’efficacité du processus (vue fournisseur). Cela permet un pilotage équilibré et une implication de l’ensemble des équipes.

Qu’est-ce que le TRS ?L’Industrie recourt habituellement pour le pilotage de sa Performance au Taux de Rendement Synthétique (TRS) correspondant en anglais à l’Overall Equipment Effectiveness (OEE). Cet Indicateur Clé de Performance permet d’évaluer sur un axe unique l’efficacité opérationnelle, les objectifs de Performance et le résultat des initiatives de productivité.

Livre Blanc

Follow Us13

Il s’agit d’un indicateur sans grandeur, consistant en la multiplication de trois taux :

• Le Taux de Disponibilité « Td » (capacité de l’unité de production à être utilisée),

• Le Taux de Performance « Tp » (variant en fonction des cadences),

• Le Taux de Qualité « Tq » (ratio entre le nombre de pièces non défectueuses et le nombre de pièces produites).

Le TRS peut donc être défini comme suit : TRS = Td * Tp * Tq

Qu’est-ce que le TRG ?L’industrie recourt également au Taux de Rendement Global (TRG) pour piloter sa performance, correspondant en anglais à l’acronyme TEEP, Total Effective Equipment Performance. Cet indicateur dont les caratéristiques sont similaires à celles du TRS, consiste en la multiplication de quatre taux :

• Le Taux de Disponibilité « Td » (capacité de l’unité de production à être utilisée),

• Le Taux de Performance « Tp » (variant en fonction des cadences),

• Le Taux de Qualité « Tq » (ratio entre le nombre de pièces non défectueuses et le nombre de pièces produites),

• Le Taux de Charge « Tc » (mesure de la charge productive réelle, ratio entre temps requis et temps d’ouverture).

Le TRG peut donc être défini comme suit : TRG = Td * Tp * Tq * Tc

Apport du TRS à la DSIL’apport principal de cette approche industrielle est de fournir un système de pilotage permettant d’appréhender globalement la performance au travers d’un indicateur synthétique.

L’identification d’un indicateur unique de performance, différencié des indicateurs de gouvernance existants est jugée comme un apport déterminant au management des directions informatiques :

• En termes de gouvernance et de communication externe avec les clients, la DSI et la Direction Générale,

• En termes de pilotage et de décision interne visant à l’amélioration de la productivité,

• En termes de benchmark et de possibilité de se comparer en interne dans le temps, voire en externe.

Le TRS apporte une aide particulièrement pertinente pour les DSI qui mettent en œuvre une démarche collaborative DevOps, par l’adoption d’un indicateur commun entre équipes Etudes et Production habituées à travailler chacune de leur côté en silos en matière de méthodes, d’outils et de mesure de la performance.

Livre Blanc

Follow Us14

Application du TRS à la Digital FactoryLe principe du TRS s’inscrit de manière naturelle en environnement DevOps. En premier lieu, la mesure est un pilier du mouvement DevOps. En second lieu, le concept de Digital Factory rejoint la dimension industrielle propre au TRS. Enfin, avec le TRS, l’accent est mis sur la chaine de delivery logiciel et sur la capacité de la DSI, comme moyen de production, à allier vélocité et fiabilité.

Plusieurs approches ont été envisagées pour transposer le TRS en environnement DevOps selon que l’on considère la chaine de delivery logiciel de manière globale ou par segments. Les travaux du Think Tank Automic présentés dans le cadre de ce livre blanc, se sont intéressés à l’approche de bout-en-bout du processus (TRS end-to-end) depuis la validation des demandes (Plan) jusqu’à l’activation du service en production (Operate).

Il est à noter que d’autres travaux complémentaires ont été menés par Automic pour mesurer le TRS uniquement sur la partie aval de ce processus (TRS release pipeline). La méthode pourrait également être appliquée à d’autres segments (gestion des demandes, synchronisation SPRINT / RELEASE) si ces derniers répondent à des enjeux et des contraintes prioritaires des organisations.

Plan Code Build Test Release Deploy Operate

TRSGestion des demandes

TRSSynchronisation SCRUM/RELEASE

TRSRelease Pipeline

TRSend-to-end

Livre Blanc

Follow Us15

Chapitre 3 : Implémentation du TRS en environnement DevOpsLa méthode proposée ci-après est issue des premiers cas de mise en œuvre du TRS. Cette méthode est la capitalisation de retours d’expérience et non un exercice théorique : à mesure que les membres pionniers trouvaient les moyens d’appliquer le TRS dans leurs environnements propres, les bonnes pratiques étaient communiquées au sein de la communauté du Think Tank et des jalons étaient posés pour permettre aux autres membres de suivre leur trace. En passant par les mêmes étapes, ces membres ont permis de challenger la méthode et de l’améliorer.

Progressivement, une méthodologie s’est dégagée avec l’objectif affiché de multiplier les cas d’adoption sur un même périmètre, et d’accélérer le temps de mise en application. En définitive, l’application de la méthode a permis de constater un gain de temps important dans la mise en œuvre en évitant pièges et fausses pistes pour aller droit à l’essentiel.Cette méthodologie est organisée en 10 étapes, permettant de suivre la progression des membres de 1 à 10 et d’identifier les blocages. Elle s’est enrichie des feedbacks des différents groupes de travail pour aboutir à un consensus dans l’identification des étapes, leur contenu et leur ordre.

Les étapes sont présentées succintement dans le tableau ci-dessous et décrites dans la suite du document.

Méthode d’adoption du TRS en 10 étapes

Etape 1 Intention Identifier le besoin d’amélioration de la performance justifiant la mise en place d’une approche « TRS »

Etape 2 Identification du périmètre d’application

Identifier précisément le périmètre d’application du TRS et partager si nécessaire le périmètre en plusieurs lots

Etape 3 Implication Assurer le bon niveau de sponsorat et mobiliser les parties prenantes

Etape 4 Partage du vocabulaireS’assurer que le vocabulaire est compris et partagé pour chacune des composantes du TRS (disponibilité, performance, qualité) appliqué au périmètre choisi

Etape 5 Etat des lieux des systèmes de mesure

Identifier l’aptitude du système de mesure à remonter les éléments entrant dans le calcul du TRS

Etape 6 Collecte des points de mesure

Mettre en place les moyens de mesure du TRS à partir de l’outillage existant

Etape 7 Premières Mesures Produire une première mesure du TRS sur le périmètre choisi

Etape 8 Analyse des gaspillages Analyser les écarts de performance à partir du TRS et utiliser l’arbre de gaspillage pour en identifier les causes

Etape 9 Systèmes de Pilotage Inscrire le pilotage de la performance opérationnelle dans une démarche d’amélioration continue

Etape 10 Industrialisation Mettre en place l’organisation et l’outillage permettant de pérenniser la mesure

Livre Blanc

Follow Us16

La méthode proposée n’est pas un cadre normatif, chaque nouvel adoptant pouvant adapter la démarche à son contexte, à ses spécificités, ainsi qu’à son système de mesure. Nous pensons toutefois que les modèles présentés vous permettront de gagner du temps et que l’application des mêmes principes pourra faciliter la comparaison entre les organisations adoptant le TRS.

Etape 1 : IntentionLa première étape consiste à apporter des éléments de réponse à la question suivante : Quel objectif recherchez-vous dans la mise en place d’un TRS ?

On cherche ici à identifier et à valider les enjeux opérationnels ou transformationnels qui seront facilités par cet indicateur. Attention ! On parle bien ici de l’objectif recherché dans la mise en place du TRS et non de l’objectif recherché dans la mise en place de DevOps.

Les objectifs suivants sont généralement à l’origine de la mise en place du TRS en environnement DevOps :

• Partager un indicateur commun entre Dev et Ops,

• Partager de bout-en-bout une même vision de la performance de la chaine de delivery logiciel,

• Partager des objectifs communs d’amélioration globale,

• Mesurer la performance dans ses différentes dimensions sans la réduire au Time-to-Market,

• Faciliter l’analyse de la performance et l’identification de leviers d’amélioration continue,

• Facilier la gouvernance d’un programme de mise en œuvre de DevOps,

• Obtenir une valeur de référence (baseline) et valoriser les bénéfices d’un pilote DevOps,

• Améliorer la satisfaction client et l’efficience de l’organisation,

• Benchmarker les résultats obtenus en interne ou avec des pairs.

Etape 2 : Identification du périmètre d’applicationA cette étape, il s’agit d’identifier le périmètre pour lequel on mesurera le TRS. Afin de progresser efficacement, il est conseillé de partager le périmètre d’application en plusieurs lots.

Livre Blanc

Follow Us17

Ces lots peuvent être a minima :

• Un lot « pilote » correspondant à un périmètre restreint, qui permettra de tester la méthode,

• Un deuxième lot qui peut être le périmètre cible, et où l’on passera en mode « industriel » avec potentiellement, un outillage plus performant.

Le domaine des applications et portails web a été le pilote le plus fréquemment choisi pour l’implémentation du TRS en environnement DevOps. Le TRS a pu également être généralisé sur l’ensemble des domaines applicatifs dans le cadre d’un programme de transformation DevOps.

Etape 3 : ImplicationIl s’agit à ce stade de s’assurer du bon niveau de sponsorat et de mobiliser les parties prenantes. Le niveau d’implication dépendra bien entendu de l’approche adoptée (expérimentation par un opérationnel, déploiement par une entité transverse) et de l’avancement du projet.Dans un premier temps, il convient de s’assurer d’avoir :

• Identifié le niveau de sponsorat,

• Justifié de l’approche et de l’investissement,

• Obtenu validation de la démarche.

Il est fondamental d’impliquer les Etudes et la Production dès le début. Constituer un binôme avec un manager Dev et un manager Ops en co-responsabilité du sujet s’est révélé être très efficace pour conduire le changement. Le sujet peut également être porté uniquement par un responsable Dev ou un responsable Ops à condition de s’être assuré du soutien de l’autre partie prenante. La présentation de la présente méthode en 10 étapes lors de sessions d’information a permis de familiariser les organisations avec le concept et d’accélérer son appropriation.

Par ailleurs, il faut s’assurer que les personnes amenées à mettre en place le TRS et les leviers d’amélioration associés sont disponibles a minima. Le nombre de personnes à impliquer est fonction :

• Du périmètre d’application (cf. Etape 2),

• De la difficulté à mesurer,

• Du niveau d’industrialisation souhaité pour la mesure,

• Du temps dont on dispose pour mettre en place la mesure.

Livre Blanc

Follow Us18

Etape 4 : Partage du vocabulaireAvant de commencer à définir et mesurer les différents taux du TRS et du TRG, Il faut s’assurer que le vocabulaire est bien compris et partagé pour chacune des trois composantes de l’indicateur de TRS (Disponibilité, Performance, Qualité) et chacune des quatre composantes de l’indicateur de TRG (Charge, Disponibilité, Performance, Qualité).

Ces notions sont ici utilisées dans leur définition industrielle. L’application à DevOps du TRS et/ou du TRG nécessite de s’accorder sur ce que sont la Charge, la Disponibilité et la Performance de la chaine de delivery elle-même (l’efficacité opérationnelle des activités) et ce qu’est la Qualité en bout de cette chaine de production (ce qui est produit). Une traduction de ce vocabulaire industriel appliqué à la chaine de delivery logiciel est proposée ci-dessous :

• Charge : Utilisation efficiente des ressources,

• Disponibilité : Disponibilité de la plateforme ou des environnements à chaque étape,

• Performance : Ponctualité des Mises en Service par rapport à la date prévue,

• Qualité : Niveau de qualité d’expérience utilisateur et de respect des exigences non-fonctionnelles des packages livrés en production.

Le schéma ci-dessous associe les différentes composantes du TRS et du TRG aux différentes étapes d’une chaine de delivery logiciel et aux différents niveaux d’activités (applicatif, plateforme, infrastructure) qui y contribuent. La qualité apparait bien comme la qualité du produit en bout de chaine. A l’inverse, la Charge, la Disponibilité et la Performance mesurent l’efficacité de l’ensemble de la chaine à un niveau d’activité donné.

Agile Coding Cont. Integration Cont. Delivery Cont. Deployment

Application-level

ActivitiesPerformance

Plateform-level

ActivitiesDisponibilité

Infra-level

ActivitiesCharge

Qua

lité

Livre Blanc

Follow Us19

Ce sont ces définitions qu’il convient de partager avec les équipes Etudes et Production. Il ne faut pas confondre ces notions avec les notions habituelles de Charge, Disponibilité, Performance et Qualité telles qu’elles sont utilisées dans l’informatique. Au contraire, il faut regarder ces notions avec un regard neuf et définir quels critères représentent le mieux, dans son environnement DevOps propre, les différents axes constitutifs du TRS et/ou du TRG.

Etape 5 : Etat des lieux du système de mesureCette étape identifie l’aptitude du système de mesure à remonter les éléments entrant dans la mesure du TRS. La réponse à cette question doit tenir compte de la capacité à mesurer simplement ces différentes composantes.

Pour cela, chaque organisation peut s’appuyer sur la check-list présentée dans la figure ci-dessous. Cette check-list est un outil permettant de choisir parmi dix indicateurs proposés les mesures qui sont les plus pertinentes et les plus faciles à obtenir dans un contexte donné. Dans un premier temps, il suffit de cocher au moins un indicateur par composant. Le taux de Charge n’est utile que pour les organisations souhaitant mesurer le TRG. Le taux de Qualité sera d’autant plus équilibré qu’il associera un indicateur correspondant aux exigences non fonctionnelles et un indicateur correspondant à l’expérience utilisateur.

Taux de Performance

Taux de Disponibilité

Taux de Charge

Taux de Qualité TRG

Taux de Performance

Taux de Disponibilité

Taux de Qualité TRS

Utilisation e�iciente des

ressources

C1 - Taux d’utilisation des ressources / plateformes

Exigeances non fonctionnelles

�

�

Q1 - Qualité du codeQ2 - Préparation de la MEP

Expérience utilisateur

�

�

Q3 - Performance applicative ressentie par l’utilisateurQ4 - Incidents suite à MEP

Disponibilité de la plateforme à chaque étape

D1 - Rapidité de mise à disposition des environnementsD2 - Disponibilité des environnements

�

�

Ponctualité des Mises en

Production

PA - Respect des dates de MEPP2 - Cadence des MEP par rapports aux spintsP3 - Profondeur des décalages de date de livraison

�

�

�

�

Livre Blanc

Follow Us20

Un bref descriptif des indicateurs de la check-list est présenté dans le tableau ci-dessous :

Une fois les indicateurs choisis dans la check-list, les questions suivantes doivent être considérées :

• Pouvez-vous mesurer chacun des taux définis ?

• Quels sont les points de mesure ?

Indicateurs de la check-list Descriptif

C1. Taux d’utilisation des ressources / plateformes

Mesurer le taux d’utilisation des ressources pour valider le bon dimensionnement des ressources des environnements de la chaine de production DevOps.

D1. Rapidité de mise à disposition des environnements

Mesurer le taux des demandes d’environnement traitées en respectant l’accord de service. L’enjeu est d’accélérer les temps de déploiement des environnements et de réduire le délai de prise en charge des demandes d’environnement.

D2. Disponibilité des environnements

Mesurer le taux de disponibilité des environnements, obtenu en divisant la durée durant laquelle l’environnement est opérationnel par la durée totale durant laquelle on a exprimé un souhait qu’il le soit (hors plage de maintenance convenue au préalable).

P1. Respect des dates de MEPMesurer le nombre de MEP à date prévue par rapport au nombre total de MEP pour valider la capacité de l’organisation DevOps à accélérer le Time to Market.

P2. Cadence des MEP par rapport aux sprints

Mesurer la capacité des organisations à synchroniser SPRINT et RELEASE en suivant le rapport du nombre de MEP / nombre de Sprints.

P3. Profondeur des décalages de date de livraison

Identifier les écarts de livraison en nombre de jours par rapport à la date de livraison initialement prévue.

Q1. Qualité du code Evaluer la qualité du code pour pouvoir mesurer la dette technique en s’appuyant sur la méthode SQALE.

Q2. Préparation de la MEP

Mesurer la qualité de la préparation des MEP selon 4 axes :- l’anticipation des besoins d’infrastructures,- l’anticipation des besoins d’exploitation,- la bonne mise en place d’un PCA et/ou PRA,- la bonne mise en place de la supervision.

Q3. Performance applicative ressentie par l’utilisateur

Evaluer la performance applicative ressentie par l’utilisateur - Mesure de la satisfaction de l’utilisateur en fonction des temps de réponse d’un ensemble de requêtes sur une période de temps donnée (cf. Application Performance Indexer - http://www.apdex.org).

Q4. Incidents suite à MEPMesurer l’impact des MEP sur la qualité de service en suivant le rapport du nombre d’incidents post MEP / nombre d’incidents moyen.

Livre Blanc

Follow Us21

• Où se trouve la donnée relative à ces points de mesure (solution/outil, …) ?

• Quelle est la fiabilité de cette donnée ? Dispose-t-on de suffisamment de points de mesure ?

• Quelle est la fréquence de mise à jour de cette donnée ? Quelle en sera la fréquence de mesure ?

• Par quel moyen de collecte (automatique, manuelle, …) pouvez-vous récupérer cette donnée ?

• Quelle équipe / personne en a la responsabilité ?

Le tableau ci-dessous présente un modèle simple qui peut être utilisé pour présenter les réponses à ces questions.

Etape 6 : Collecte des points de mesureDans cette étape, les moyens de mesure du TRS sont mis en place : paramétrage de nouveaux rapports, mise en place de traçabilité, etc.

Compte tenu des contraintes liées au système de Mesure, il est in fine nécessaire d’identifier, pour chaque composant, les données et les formules de calcul correspondant au mieux à la définition de celui-ci.

Les discussions communes entre Dev et Ops sur les points de mesure sont un bon moyen de constater les manques et les doublons, les erreurs et les opportunités. Dans un premier temps, une mesure en première approximation s’avère généralement suffisante.

QUALITE PERFORMANCE DISPONIBILITE

Mon TRS

Taux de Qualité : Nombre d’incidents en période de Vérification de Service Régulier (VSR) post MEP

Taux de MEP à date prévueTaux de Disponibilité des environnements de Dev / Recette

DonnéesNombre de tickets > au nombre de tickets moyen sur 2 jours après les MEP

Nombre de MEP planifiées réalisées à date / mois

Durée d’indisponibilité / mois

Acteurs Equipe Support (Outil ITSM) Equipe Dev (Outil ALM) Equipe Ops (Supervision)

Livre Blanc

Follow Us22

Etape 7 : Premières mesuresUne première mesure du TRS est produite.Dans un premier temps, une mesure permettant une première approximation des indicateurs peut suffire. Ce qui importe, c’est de fédérer les personnes autour d’une démarche et de progressivement affiner et automatiser la mesure (cf. étapes suivantes). Nous préconisons donc de commencer le calcul et l’analyse du TRS même si toutes les données ne sont pas disponibles, ou qu’elles n’ont pas encore le « niveau de précision » souhaité.Dans certains cas, des données sur les derniers mois ou les dernières semaines sont disponibles dans les systèmes de mesure. Dans ce cas, calculez le TRS a posteriori sur les derniers jours / semaines / mois afin de voir si le TRS est stable ou s’il varie en fonction de la période.

Etape 8 : Analyse des gaspillagesLe but ultime du TRS n’est pas de mesurer mais bien d’analyser la performance et de rentrer dans une démarche d’amélioration continue. L’atelier « arbre des gaspillages » présenté ci-après est une manière pragmatique d’initier un telle analyse en trois phases :

• Identifier les gaspillages, c’est-à-dire les causes de défaillance potentielles des Taux élémentaires du TRS : Performance, Disponibilité, Qualité,

• Identifier les leviers d’amélioration, c’est-à-dire les moyens d’action potentiels qui permettent d’agir sur les causes des gaspillages,

• Identifier les indicateurs d’amélioration, c’est-à-dire les moyens de contrôle qui permettent de s’assurer que nous avons bien agi sur les causes au moyen des leviers.

Une fois l’analyse terminée, des actions d’amélioration (leviers) seront implémentées, et leur effet sur les activités sera contrôlé / mesuré.

L’atelier « TIMWOOD » est une approche complémentaire à l’atelier « arbre de gaspillages » en ce qui concerne la première phase d’identification des gaspillages.

MOIS TAUX DE QUALITE TAUX DE DISPONIBILITE

TAUX DE PERFORMANCE TRS

Avril 90% 80% 81,25% 58,5%

Mai 95% 90% 87,65% 74,94%

Juin 95% 85% 97,65% 78,85%

Livre Blanc

Follow Us23

Atelier Arbre des Gaspillages

L’arbre des gaspillages est une bonne pratique issue du monde industriel. Les gaspillages sont pré-cartographiés, et associés a priori à chaque dimension du TRS. L’arbre facilite l’identification des gaspillages et l’exhaustivité de l’identification. Il permet d’analyser le travail et de comprendre les obstacles qui empêchent d’accomplir le travail au rythme voulu.

TRS Disponibilité

Qualité

Performance

Composant

Savoir-faire

Synchronisation

Planning / Ordonnancement

Capacité

Pannes Techniques

Attentes

Arrêts (humain)

Approvisionnements

Méthode

Procédures

Surconsommation

Productivité

Rapidité

Facteur humain

Livre Blanc

Follow Us24

La réussite d’ateliers d’amélioration s’appuyant sur l’arbre des gaspillages repose principalement sur les participants et l’interactivité des échanges. Ces ateliers d’amélioration ont une durée de deux heures et ont pour but :

• D’impliquer les acteurs et de les sensibiliser au calcul de l’indicateur et à son utilisation,

• De définir le système de mesure qui permet de calculer cet indicateur et de mettre en place les premières mesures,

• D’identifier les gaspillages et les leviers d’amélioration,

• De suivre la mise en place des leviers d’amélioration et l’évolution du TRS dans le temps.

L’atelier d’amélioration est piloté par le responsable de la mise en place du TRS. Les participants à l’Atelier sont les personnes qui mesurent le TRS, accompagnées de deux ou trois personnes qui travaillent sur le processus mais qui ne mesurent pas. Elles n’ont, de ce fait, pas été associées préalablement à la démarche. Ces deux ou trois personnes vont donc avoir un angle d’approche légèrement décalé par rapport au reste du groupe, ce qui peut être bénéfique dans l’apport de solutions. Le déroulement type d’un atelier d’amélioration est décrit ci-après.

Livre Blanc

Follow Us25

Déroulement type d'un atelier d'amélioration

�

�

�

2nde identification des gaspillages(avec l’arbre des gaspillages)

Objectif  : Utiliser l’arbre des gaspillages IT pour consolider la liste des gaspillages identifiésCorréler les gaspillages identifiés pendant l’Atelier avec les natures de gaspillages présentés sur l’arbreSusciter de nouvelles propositions

�

�

�

Partage des premières mesures

Objectif  : Partager une vision objective de la Performance (factualiser) Présenter le TRS global, accompagné des Taux obtenus pour la Disponibilité, la Qualité, et la PerformanceRappeler les grands principes de base appliqués pour le calcul de ces trois taux afin que les participants qui ne mesurent pas comprennent ce que représentent ces résultats.

Introduction

Objectif : Rappeler l’enjeu de l’AtelierLes di�icultés perçues sur le processus,L’intérêt de mettre en place un TRS et les gains escomptés, L’intérêt de définir collégialement les gaspillages et les améliorations, en associant les acteurs du processus

�

�

�

�

1ère Identification des gaspillages(sans l’arbre des gaspillages)

Objectif  : Apporter des réponses par le biais d’échanges interactifs, où chacun s’exprime librement par rapport à son expérience. Commencer par l’axe dont le taux est le plus en retrait (la Qualité par exemple). Quelles sont les raisons pour lesquelles la Qualité est insu�isante ?  Continuer axe par axe en suivant cet ordre de prioritéParmi les réponses apportées, certaines peuvent concerner un autre axe. Peu importe, la proposition est notée pour être abordée un peu plus tard, lorsque l’axe en question sera étudié.

�

�

�

�

Identifier les leviers d’amélioration

Objectif : Définir un plan d’actions prioritaires Identifier une ou plusieurs actions pour chaque gaspillage Répertorier les quick-wins en fonction de la complexité de mise en œuvre de chaque action et de la plus-value apportéeProposer un premier plan d’amélioration (la finalisation et la mise en œuvre nécessiteront des réunions complémentaires)

�

�

�

�

Livre Blanc

Follow Us26

Atelier TIMWOOD

Une approche alternative consiste à organiser un atelier d’identification des gaspillages en s’appuyant sur la méthode TIMWOOD, issue du Lean Management. Le Lean Management suggère en effet, pour optimiser les processus de l’entreprise et créer efficacement de la valeur, d’identifier systèmatiquement toutes les sources de gaspillages afin de les éliminer ou les réduire. L’industrie distingue sept types de gaspillages appelés Muda. L’acronyme TIMWOOD correspond en anglais aux initiales de ces sept gaspillages.Cette méthode a été appliquée par les membres du Think Tank pour identifier les gaspillages au sein du flux DevOps “Idea to Production”. Le résultat de l’atelier est illustré en page suivante.

TIMWOOD

TransportationFait référence aux déplacements des produits finis ou semi-finis soumis à des risques de détériorations, de pertes, de délais supplémentaires et de charges de travail supplémentaires.

InventoriesFait référence aux stockages intermédiaires et aux inventaires effectués en cours de processus. Ceux-ci ne contribuent pas à la transformation du produit et générent des surcoûts n’apportant aucune valeur ajoutée.

MotionFait référence aux déplacements inutiles des moyens humains et matériels en cours du processus de fabrication et qui peuvent avoir des impacts de détérioration, d’usure et de sécurité inutiles.

WaitingFait référence au temps d’attente de l’activité ou de la tâche suivante pour les produits ou services qui ne sont pas en cours de transport, de fabrication ou de transformation dans leur processus.

Over-production Fait référence à la surproduction de produits fabriqués par rapport à la demande / commandes clients.

Over-processing

Fait référence aux activités et tâches inutiles et/ou qui n’apportent pas de valeur ajoutée au client ainsi qu’aux outils d’utilisation (logiciels, procédures, instructions de travail) qui sont trop précis, trop complexes, ou plus coûteux que nécessaire.

DefectsChaque fois que des défauts et rejets des produits finis et semi-finis arrivent, des coûts supplémentaires sont supportés pour retravailler les produits, détruire les défectueux, reprogrammer la production, ...

Livre Blanc

Follow Us27

Le Lean Management suggère, pour créer eff icacement de la valeur, d’identifier les sources de gaspillages et de les éliminer ou les réduire afin d’optimiser les processus de l’entreprise. L’industrie distingue 7 types de gaspillages issus de la méthode Lean et appelés Muda qui peuvent être transposés en DevOps selon le moyen mnémotechnique TIMWOOD.

• Incapacité du modèle de transport des packages applicatifs à atteindre les objectifs de volumétrie, fréquence, délai et productivité

• Inaptitude de fournisseurs de code (ex. TMA) à s’aligner sur les objectifs• Hétérogénéité des outils et procédures utilisées, nombreuses tâches manuelles

• Surcapacité des environnements hors production• Environnements créés mais non utilisés ou non décommissionnés• Environnement de développement ou de tests surdimensionnés

• Doublonnement et non fiabilité des référentiels nécessaires au fonctionnement de la chaine d’automatisation

• Chaque outil, chaque équipe de la chaîne de déploiement possède son référentiel propre• Les référentiels des versions applicatives et des infrastructures ne sont pas à jour

• Hétérogénéité des pratiques agiles des équipes de développement impliquant une perte d’eff icacité aux interfaces avec la production et les métiers

• Impossibilité pour les équipes Ops d’industrialiser leurs activités• MOA et Métiers en décalage avec ces pratiques

• Réalisation de tâches humaines répétitives et systèmatiques• Tests (non regression, performance, techniques)• Déploiements applicatifs, mise à disposition des environnements

• Mobilisation excessive des contributeurs par manque de capitalisation de l’information• Allers-retours entre équipes de développement et métiers pour qualifier le besoin• Réunions d’analyse d’impact et de validation

• Mauvaise priorisation : les fonctionnalités à forte valeur ajoutée attendent la fin du développement des stories moins critiques

• Membres du comité de priorisation non représentatifs, manque de connaissance du métier• Retard dans la mise à disposition d’environnements de recette ou de production

• Manque d’anticipation, de communication et d’automatisation du provisionning• Fonctionnalités validées en attente de mise en production

• Les packages attendent une fenêtre de livraison• Un ou plusieurs incidents en cours bloquent toute mise en production• Blocage de l’ensemble d’une mise en production en raison d’éléments défectueux

• Manque de réactivité aux étapes clés du cycle de développement• Sprint reviews, recette fonctionnelle, validation• Manque de disponibilité des équipes métiers, des experts, du management

• Fréquence de livraison non alignée avec les besoins réels du métier• Livraison applicative trop fréquente sans valeur pour le métier• Fréquence de livraison trop basse impactant le business des métiers

• Gestion des changements et gestion des projets trop bureaucratiques• Automatisation locale n’améliorant pas la performance de bout-en-bout

• Automatisation avancée de l’intégration continue alors que la contrainte est sur les tests ou le déploiement

• Mise à disposition de fonctionnalités non demandées• Mise à disposition de fonctionnalités demandées ne correspondant pas à un besoin réel• Rédaction de documentations utilisateur qui ne sont pas lues• Blocage de production avec impact sur les clients finaux

• Régression majeure non identifiée lors de l’analyse d’impact du changement• Erreur manuelle lors du déploiement

• Régressions fonctionnelles dans l’application mise à jour ou dans les systèmes connexes• Introduction d’une dette technique générant un surcoût de maintenance

• Non respect des exigences non fonctionnelles

T ransportation

M otion

O verprocessing

I nventories

W aiting

O verproduction

D efects

Lean IT : Cartographie des GaspillagesDevOps

automic.com

Livre Blanc

Follow Us28

Etape 9 : Système de pilotageIl convient à ce stade de définir et mettre en place les modalités et les instances de gouvernance associées au TRS :

• Répondant à l’intention initiale de pilotage de la Performance (cf. Etape 1),

• Conforme à la culture de pilotage de l’organisation.

Cette étape vise à s’assurer qu’un certain nombre de préalables sont rassemblés pour que l’analyse de cause s’inscrive dans une boucle d’amélioration continue efficace :

• Inscrire la démarche dans un cadre de pilotage de la Performance,

• Identifier un sponsor et mobiliser les ressources nécessaires,

• Partager le vocabulaire et former les contributeurs de la démarche aux nouveaux concepts,

• Communiquer sur les modalités de mise en œuvre et les résultats attendus.

Le sponsor de l’initiative devra clairement établir la cible de l’amélioration de la Performance attendue ainsi que le périmètre des acteurs et contributeurs concernés (organisation interne, infogérants, tiers identifiés, etc.).

La conduite du changement peut s’effectuer à travers des séances de sensibilisation à la démarche, des formations à partir de cas concrets. Le mode de pilotage ciblé est à expliciter versus une démarche classique selon les objectifs poursuivis : partage d’un objectif d’amélioration continue commun, mesure de l’efficacité opérationnelle, etc.

Des objectifs peuvent être également fixés aux contributeurs de la démarche en terme d’amélioration du TRS et ce afin de renforcer l’intégration de ces pratiques dans les activités courantes. Différentes modalités de pilotage sont présentées ci-après au travers de différents cas. Ces cas illustrent différentes orientations que peut recouvrer le pilotage de la Performance à travers l’utilisation du TRS. Par ces différents exemples, on constate que le TRS peut être utile dans le pilotage d’une ou plusieurs entités opérationnelles, d’un ou plusieurs fournisseurs, d’un ou plusieurs streams. Le point commun à ces différents systèmes est d’inscrire le pilotage de la Performance opérationnelle dans une démarche d’amélioration continue.

Livre Blanc

Follow Us29

Etape 10 : IndustrialisationL’Industrialisation consiste à mettre en place l’organisation et l’outillage adapté à la collecte et au traitement des données.

Elle se justifie :• Lors d’une extension de périmètre : passage du périmètre pilote au périmètre cible,

• Et/ou si la pérennisation de la mesure a été actée, l’objectif étant d’inscrire le TRS dans une gouvernance ad hoc ou préexistante.

L’organisation comprend :(1) Un responsable du TRS, clairement identifié dont la mission est de :

• Veiller à la réalisation des mesures selon la fréquence convenue et à la publication du tableau de bord,

• Animer l’identification de leviers potentiellement nécessaires en cas de dérive du TRS,

Intention initiale Culture de pilotage

Cas 1 : Atelier d’Amélioration

Améliorer l’efficacité opérationnelle d’un projet pilote DevOps incluant Dev et Ops

Culture de l’amélioration continue encourageant la prise d’initiative

Cas 2 : Organisation en

domaines applicatifs

Améliorer le pilotage des différents domaines en utilisant des indicateurs de progrès

Gouvernance centralisée en charge du pilotage de la performance

Cas 3 :Programme de transformation

Fédérer les différents streams d’un programme de transformation DevOps autour d’objectifs de progrès partagés

Revues individuelles des objectifs des streams mais difficulté à démontrer l’efficience globale de la démarche

Cas 4 :Relation avec les sous-traitants et partenaires

Piloter les actions d’amélioration des fournisseurs en mesurant leur contribution à la performance d’ensemble

Comités stratégiques et comités de pilotage sur la base d’engagements contractuels

Livre Blanc

Follow Us30

• Contrôler l’application des leviers d’amélioration définis,

• Exprimer les éventuels besoins liés à un outillage plus automatisé pour la mesure.(2) Une ou plusieurs équipes impliquées dans la mesure (collecte et traitement), l’analyse et l’arbitrage.

L’outillage adapté à la collecte et au traitement des données peut s’appuyer sur :• Les systèmes de métrologie existants (ex. BI),

• Les systèmes de métrologie propres à des outils spécifiques au périmètre cible (ex. APM, Qualité de Code, Release Automation, Orchestration, IT Service Management, etc...),

• Les outillages internes à une entreprise basés sur des tableurs ou des bases de données.

Le tableau ci-dessous propose une typologie d’outils sources permettant de recueillir les données nécessaires au calcul du TRS et du TRG :

Pour terminer, le TRS peut être utilisé à des fins de benchmark. Dans ce cas précis, l’industrialisation doit prévoir de normaliser les mesures et d’obtenir des valeurs qui pourront être comparées entre pairs. L’usage d’outils partagés peut faciliter cette démarche.

CHARGE DISPONIBILITE PERFORMANCE QUALITE

• Capacity Management• Performance Management

• Monitoring• Service Request Management• Orchestration

• Release Management• Release Automation

• Incident Management• Code Quality• Application Performance Management

Livre Blanc

Follow Us31

A propos du Think Tank AutomicCréé en 2010, le Think Tank Automic est un groupe de réflexion constitué d’une vingtaine de décideurs informatiques issus de différents secteurs d’activités, privés ou publics, et consacré au pilotage de la performance.

En 2011, le Think Tank Automic met l’accent sur un indicateur innovant issu des méthodes industrielles : le Taux de Rendement Synthétique (TRS).

En 2012, les membres passent de la théorie à la pratique et appliquent le TRS dans leurs organisations : mesure et pilotage, normalisation des concepts et identification de nouveaux besoins.

En 2013 et 2014, le Think Tank étend la communauté d’adoption de l’approche TRS et propose un guide pratique d’implémentation du TRS incluant fiches pratiques et méthodologie.

En 2015 et 2016, le groupe propose de mobiliser les équipes Etudes et Production autour d’un même objectif en transposant à DevOps le Taux de Rendement Synthétique (TRS). Le résultat de ces travaux est présenté dans ce nouveau guide “Quelle métrique pour fédérer Dev & Ops ?”.

Pour plus d’information ou démonstration des solutions Automic, visitez notre site www.automic.com

Automic, leader de l’Automatisation des processus d’entreprise, aide les organisations à gagner en compétitivité en automatisant leur informatique d’entreprise, de l’hébergement sur site au Cloud, en passant par le Big Data et l’Internet des Objets. Avec ses bureaux dans le monde entier, le groupe

soutient les activités de 2 600 clients parmi lesquels Bosch, Netflix, eBay, AMC Theatres, Carphone Warehouse, ExxonMobil, BT Global Services, Société Générale, NHS SBS, General Electric et Swisscom. Automic est une société privée détenue par EQT. Pour plus d’informations : http://www.automic.com/fr

A propos d’Automic InstituteAutomic Institute a pour mission de promouvoir l’expertise du groupe Automic en s’appuyant sur l’ensemble des savoirs de l’entreprise pour partager convictions, connaissances et expériences en Management des Opérations Informatiques.

• Les Publications alimentent la communauté des managers des Opérations Informatiques en faits et en opinions,

• Les Communautés et Think Tank sont des réunions de décideurs informatiques décidés à faire émerger les idées qui seront la réalité de demain en matière de Management des Opérations Informatiques,

• Les Trivial Pursuit™ Edition IT sont des outils pédagogiques innovants pour sensibiliser les équipes informatiques : Lean IT, Cloud, Management de Projet, ITIL®, …

Contacter Automic

AutomicTour Pacific11, cours Valmy 92800 Puteaux, France

Webwww.automic.com