Last update: 29-01-2022 16:09
57'32"

DevOps

Une équipe de développement typique dans le monde de L(i)VID : 7
        personnes + experts pour des besoins ad hoc (DBAs, Sécurité,
        Architectes, …)
Une équipe de développement typique dans le monde de L(i)VID : 7 personnes + experts pour des besoins ad hoc (DBAs, Sécurité, Architectes, …)

La notion de DevOps dans le contexte Agile est encore nouvelle et peu d'entreprises ont encore adopté ce paradigme. Ce n'est qu'à partir de 2008 que cette notion a commencé à se frayer un chemin dans les services IT. En 2011, ceux qui étaient investis dans l'Agilité ont contribué à répandre le concept. Depuis 2012-2013, il s'est propagé linéairement pour percoler dans toutes les entreprises qui ont entamé des transitions agiles et donc souvent aussi digitales. Pourtant, nous manquons encore de matériel objectif et concret pour théoriser le concept, même si, au demeurant, la théorie est beaucoup plus mature que la pratique. Les succès techniques et commerciaux de géants du secteur technologique apportent néanmoins la démonstration de la validité des idées défendues par DevOps dont plus personne ne peut ignorer qu'il est à l'œuvre dans la réussite de Netflix, dans le triomphe d'Amazon, dans la fortune de Google, dans les outils notamment enfichés dans la suite Azure de Microsoft. C'est un raz-de-marée qui rend enthousiastes tous les thuriféraires de l'intelligence DevOps.

DevOps est une notion importante dans L(i)VID, aussi cardinale que les 5 piliers, que la colonne vertébrale digitale, que le mode Kanban.

Cette notion DevOps est à l'œuvre dans toutes les Transformations Digitales car, comme j'aime le rappeler, toutes s'arcboutent sur la … digitalisation [1] . Parler des aspects théoriques et d'organisation est certes utile, fondamental même, mais si l'on ne met pas en place les actions concrètes de terrain rien ne se cristallise ce qui réduit les transformations digitales à un ensemble de schémas et de PowerPoint qui n'atteignent ainsi aucun objectif tangible. J'aime renvoyer les organisations au tableau de Magritte, Ceci n'est pas une pipe dont le sens général est de distinguer un objet de sa représentation. Ainsi donc, pour L(i)VID, les schémas, les textes et les slides PowerPoint illustrent les transformations digitales mais ne peuvent être pris pour elles. Toute représentation trahit l'objet représenté et aucune ne peut en donner le goût véritable.

Les méthodes Agiles habituelles ont pris le contrepied des méthodes traditionnelles en rassemblant les métiers appelés à collaborer en vue de la réalisation d'un objectif final. Là où la division scientifique du travail a séparé les métiers, les méthodes Agiles les réassemble. En cela, elles sont le résultat d'un papier parfaitement fondateur signé par Takeuchi et Nonaka : The New New Product Development Game, article qui est le tout premier à présenter le rugby comme une analogie intéressante s'appliquant aux projets qu'ils ont étudiés. C'est aussi dans cet article qu'apparaît pour la première fois le terme Scrum dans l'acception qu'il revêt dans l'arsenal Agile.

Les méthodes Agiles rassemblent les programmeurs, les testeurs (AQ globale) et les utilisateurs. C'est déjà une grande amélioration par rapport aux méthodes plus traditionnelles, mais cela n'englobe pas encore l'ensemble du système. Le problème à résoudre — et il est tellement répandu qu'on peut presque affirmer qu'il est totalement généralisé — c'est le fossé qui est apparu entre ceux qui créent les solutions et ceux qui les font vivre, qui les maintiennent et les réparent, le fossé entre Construction / Développement [2] et Maintenance / Opérations.

Il y a 30 ans, beaucoup des métiers de l'informatique n'existaient pas de manière différenciée : on était programmeur, analyste et … opérateur tout à la fois. C'est avec la multiplication des machines qu'il n'a plus été possible pour les informaticiens de tout faire avec des casquettes différentes. La tendance n'a fait que se renforcer avec le temps donnant ainsi lieu au métier d'opérateur. Ce fut le moment de la grande césure entre Développement d'un côté et Opérations de l'autre. La césure a sécrété un problème majeur : la ségrégation des préoccupations des uns et des autres. Désormais, les informaticiens s'occupaient de créer et les opérateurs de maintenir sans se préoccuper des soucis de l'autre groupe.

C'est cet exact problème qu'il est nécessaire d'adresser avec le JTBD (Job To Be Done) en tête, avec le ravissement des clients en bille, avec le souci de cohésion et l'esprit d'équipe nécessaire à l'épanouissement de la force de travail . C'est la raison pour laquelle L(i)VID fait belle place à la notion de DevOps considéré comme un moyen de pousser le concept d'Agilité à inclure les Opérations dans la vue d'ensemble, ce qui permet de combler le fossé avec la Production (au sens informatique) et de mettre fin aux équipes isolées.

DevOps étend l'horizon de l'Agilité
DevOps extends the horizon of Agility

DevOps est un moyen de créer la boucle de rétroaction nécessaire entre la production et la conception / construction. Il s'agit de l'unification du développement, de la livraison et de la maintenance / support, mettant fin à ce mur qui sépare les deux mondes : les logiciels ne doivent plus être jetés par-dessus le mur et laissés à d'autres personnes pour qu'elles les fassent fonctionner. DevOps est l'incarnation de la loi du karma : tout ce que vous avez fait de mal ou de bien vous reviendra à un moment donné. Pour les développeurs, c'est l'occasion de s'approprier réellement leur code et de faire avancer le point final (jusqu'aux opérations).

En ayant une équipe agile qui prend soin de ce qu'elle a produit, non seulement en le construisant, mais aussi en le livrant et, plus tard, en le rendant plus mature (maintenance perfective) et plus robuste (opérationnalité accrue), nous jetons les bases du principe de responsabilité de bout en bout.

Pour paraphraser Melinda Ballou, il ne suffit pas de faire des bébés et de les mettre au monde, il faut aussi les élever, les éduquer. C'est le sens de la parenté. C'est ce que je mets en avant avec les équipes de développement de type DevOps avec L(i)VID.

La théorie du jeu postule que 2 joueurs ont intérêt à collaborer lorsque la probabilité qu'ils se rencontrent à nouveau est élevée, ce qui s'exprime par le facteur ω (ou défini plus poétiquement comme l'ombre du futur — shadow of the future).

Lorsque tous les membres de l'équipe se trouvent dans une seule grande pièce, les informations de quelqu'un deviennent les vôtres, sans même essayer. Vous commencez alors à réfléchir en termes de ce qui est le meilleur pour le groupe dans son ensemble, ou en termes d'alternatives, et pas seulement pour vous-même. Si chacun comprend la position de l'autre, alors chacun d'entre nous est plus disposé à céder, ou du moins à essayer de se parler. Des initiatives peuvent alors émerger. — When all the team members are located in one large room, someone's information becomes yours, without even trying. You then start thinking in terms of what's best or second best for the group at large and not only about where you stand. If everyone understands the other person's position, then each of us is more willing to give in, or at least to try to talk to each other. Initiatives emerge as a result.

Hirotaka Takeuchi and Ikujiro Nonaka in The New New Product Development Game

Il me vient plusieurs exemples personnels très réels dans lesquels il eut mieux valu être organisés en mode DevOps. Je vous en livre deux issus du même contexte.

Cas 1

Développant la plateforme Internet & Mobile Banking d'un groupe bancaire français, l'équipe était particulièrement satisfaite de ce grand moment qui visait la mise en production généralisée de la solution, un grand moment préparé avec soin pour que la nouvelle solution soit disponible sans aucune interruption de service. Les meilleurs spécialistes de Paris avaient convié les meilleurs spécialistes de Bruxelles et tout ce beau monde était prêt à poser les actes qui avaient été souvent répétés avant le moment fatidique. La seconde du grand basculement arrive et … tout se passe comme espéré ! C'est formidable. Le champagne coule et l'anxiété fait place au soulagement. Gavés de petits fours, la bouche pleine de sourires, l'équipe de Bruxelles se met tout doucement en ordre de retourner vers la Belgique quand une alerte se fait entendre après 1h ou 2h de fonctionnement fluide. C'est un opérateur de Paris qui s'étonne d'une forme de ralentissement d'une des fermes de serveurs. Tout le monde fait mine de s'y intéresser de manière affairée mais au fond parfaitement distraite. Quel est ce grain de sable qui grippe la machine ? Le phénomène échappe à la reconnaissance d'un problème classique; il est inexplicable et … il commence maintenant à se répercuter sur la deuxième ferme de serveurs ce qui commence à sérieusement inquiéter ceux qui étaient restés fêter le digne événement. Il ne faut qu'une partie du temps pour que le problème infecte maintenant la troisième ferme (il y en avait 4 pour un total de 84 serveurs) et avant qu'on ne connaisse la nature du problème la 4ème ferme est à son tour touchée, tombe et fait s'effondrer tout l'édifice. Nous sommes à ce moment-là sans plateforme bancaire pour le grand public, une situation parfaitement gênante. Les plans de rollback sont déroulés ce qui permet de rétablir le service, l'ancien banking. La perturbation aura été réelle, certes, mais temporaire. La cause ? Des traces / logs qui ont complètement rempli l'espace disque ! Ni plus, ni moins ! L'espace disque devenu rare, les activités de garbage collection étaient devenues singulièrement plus lentes jusqu'à rendre indisponible la première ferme. La charge étant alors repartie sur 3 fermes au lieu de 4, chacune était maintenant sollicitée davantage générant le même comportement que celui observé pour la ferme #1 mais plus vite. Le reste de l'histoire se devine aisément : une deuxième ferme tombe et le problème se reporte sur celles qui restent, accélérant de plus belle.

Quel est le lien avec DevOps ? C'est très simple : si nous avions embarqué les opérateurs dans le processus de développement, le problème se serait présenté bien avant, et sur des environnements de test au lieu de la production. À l'heure H, nous n'aurions pas connu cette déconvenue assez frustrante.

[…] si nous avions embarqué les opérateurs dans le processus de développement, le problème se serait présenté bien avant, et sur des environnements de test au lieu de la production.

Cas 2

Le cas 2 est finalement la suite du cas 1. Les traces étaient générées par des appels à une fonction unique : le code en était truffé. Il y avait bien une paramétrisation possible, on ou off, mais sans aucune autre granularité que celle d'un système binaire. L'équipe de développement s'est alors saisie du sujet et a fait œuvre de finesse dans la manière de générer des traces en utilisant une sorte d'Error Level. Plus le niveau était élevé, plus les traces étaient abondantes. Parfait.

Un nouveau jour J a alors été décidé entre Paris et Bruxelles, un nouveau déploiement, bien moins festif que le premier, question de mauvaise expérience passée j'imagine. Ce nouveau déploiement a été un succès. Aucun doute là-dessus. Cependant…

La nouvelle plateforme est donc disponible et est maintenant active depuis 1 ou 2 mois quand nous recevons un message inquiétant ramené au support technique parisien par un client qui a vu des mouvements affichés dans son relevé d'opérations n'appartenant pas à son compte (juste l'affichage, heureusement). Que s'était-il passé ? C'est justement dans cette enquête que je puise mon deuxième exemple DevOps [3] : les opérateurs parisiens voulant retracer les opérations effectuées par le client pour déterminer la cause du problème en étaient réduits à consulter 84 fichiers de logs différents, 1 par serveur, si bien que suivre la totalité d'une opération de A à Z impliquait des recherches archéologiques synchronisées sur 84 sites différents, avec le début de l'opération sur la machine X, la suite en ordre dispersé sur d'autres machines et la fin sur la machine Z. L'enfer ! Là encore, aurions-nous été structurés en mode DevOps que nos opérateurs nous auraient tout de suite informés de la complexité du suivi des logs. Nous aurions évité une nouvelle frustration et une frayeur peu commune qui a d'ailleurs nécessité un retour temporaire à l'ancienne plateforme et à une forme de compromission de la confiance de Paris à l'égard de Bruxelles !

Conclusion

En incorporant les opérateurs dès le développement de la solution, c'est-à-dire dès la collecte des exigences, vous vous épargnez bien des frustrations et désillusions ultérieures parce que vous aurez pu anticiper les problèmes qui ne seraient finalement jamais apparus, du moins pas en production, là où ils coûtent jusqu'à 500 fois plus chers à résoudre.

C'est ce qu'Yves Morieux et Peter Tollman ont exprimé dans leur excellent livre Six Simple Rules, How to Manage Complexity without Getting Complicated. La règle numéro cinq : Extend the Shadow of the Futrure. Cette règle crée des boucles de rétroaction en exploitant l'effet du temps. C'est une observation sacrément simple pour comprendre l'importance de ce qui se passera demain suite à ce que nous faisons aujourd'hui. Par conséquent, nous devons créer les boucles qui font que les gens ressentent les conséquences de la façon dont ils gèrent les choses aujourd'hui. J'aime cette façon de le représenter : faire en sorte que les gens marchent dans les chaussures qu'ils fabriquent pour les autres.

En incorporant les opérateurs dès le développement de la solution, c'est-à-dire dès la collecte des exigences, vous vous épargnez bien des frustrations et désillusions ultérieures parce que vous aurez pu anticiper les problèmes qui ne seraient finalement jamais apparus, du moins pas en production, là où ils coûtent jusqu'à 500 fois plus chers à résoudre.

Selon Morieux et Tollman, ces boucles de rétroaction sont bien plus préférables et efficaces que l'utilisation de la supervision, des métriques et des incitants. C'est ce que DevOps apporte à l'organisation et le sentiment d'accomplissement dans L(i)VID.

Tout cela est ce qu'on appelle Shift Left, comme décrit ci-dessous :

DevOps étend l'horizon de l'Agilité en rapatriant des préoccupations
des opérateurs dès les premières étapes du développement
Le paradigme « Shift Left » : les préoccupations des opérations migrent vers la gauche pour désormais s'intégrer à la conception / construction

You Build It; You Run It!

Werner Vogels, Amazon, l'a dit en des mots simples et parfaitement efficaces :You build it, you run it (Enterprise DevOps: Why You Should Run What You Build | AWS Cloud Enterprise Strategy Blog).

Il s'agit là pourtant d'une véritable difficulté de mise en oeuvre pour nombre de grosses entreprises organisées sur une informatique plus traditionnelle.

Vertues attendues

Production-ready

Lorsque les équipes doivent opérer elles-mêmes les solutions qu'elles développent et lorsqu'elles sont secondées par des ingénieurs de l'exploitation le code informatique produit contient d'emblée les éléments qui vont faciliter les opérations de maintenance et de contrôle. Ce sont les cas #1 et cas #2 dont je parlais ci-avant. Les considérations principales des Ops sont prises en compte dès la collecte des besoins, et elles font l'objet de tests. Elles sont donc éprouvées d'abord dans des environnements où les dégâts occasionnés sont mineurs. Le temps agit également comme révélateur et lisseur : plus le cérémonial se répète, plus de problèmes sont révélés, souvent d'ailleurs de manière notablement fortuite, sont adressés et résolus et ensuite contribuent à immuniser les développements futurs.

Résolution AVANT problème

Quand les problèmes de production deviennent aussi les problèmes de l'équipe qui a développé les solutions, on assiste à une forme de créativité préventive : on crée des procédures qui vérifient l'espace disque, la mémoire disponible, la charge sur l'application, on invente des messages de service, … Les programmeurs ADORENT ça ! Ils ont l'impression de créer des objets vivants. À l'utilité ils joignent l'agréable.

Transparence

Personne ne veut que son temps personnel soit interrompu. Celui qui prend les appels fera tout son possible pour éviter de les recevoir en premier lieu. Vos équipes souhaiteront naturellement une plus grande transparence dans l'environnement et mettront en place un suivi proactif afin de pouvoir identifier les problèmes ou les tendances inquiétantes avant qu'ils ne se généralisent. En plus de permettre de détecter les problèmes avant qu'ils ne se produisent, ce type de transparence devrait permettre de trouver beaucoup plus facilement les causes profondes des problèmes qui persistent.

Autonomie et sens

Être au contact direct du client est une expérience dont bien des informaticiens n'ont jamais fait l'apprentissage. C'est très enrichissant et très responsabilisant. Cela donne du sens au travail réalisé et fait prendre conscience que le code informatique produit est un objet vivant dont le client se saisit pour effectuer un travail qui, pour lui, est important. C'est son JTBDJob To Be Done à lui. Cela augmente aussi l'autonomie de chaque membre de l'équipe, ce qui n'est pas sans rappeler le concept MAPMastery, Autonomy, Purpose.

Dev et Ops : le mur tombe

La compréhension des problèmes des autres (utiliser soi-même les chaussures qu'on fabrique pour les autres) c'est faire tomber le mur entre les Ops et les Devs. La compréhension va dans les deux sens et ne se limite pas à l'entendement des objectifs des autres mais aussi de leurs contraintes. Les gens se parlent et continuent à se parler par la suite, pour d'autres activités. La communication quitte de plus en plus le formel et migrent vers l'informel.

Qualité opérationnelle; problèmes en baisse, satisfaction et confiance en hausse

Comme le disait Adrian Cockcroft, les développeurs détestent être dérangés à 3 heures du matin. Les problèmes sont anticipés avant leur apparition (alertes générées en console avec interventions préventives) ce qui diminue sensiblement le nombre d'incidents.

La satisfaction de l'utilisateur final s'en trouve améliorée et avec elle sa confiance dans l'entreprise. Une autre confiance est en hausse : celle du Business vis-à-vis de l'IT.

Automatisation

Les développeurs détestent les tâches manuelles répétitives, donc s'ils découvrent qu'ils doivent faire quelque chose encore et encore en production pour résoudre un problème, ils ont l'envie d'en trouver la cause et d'automatiser la solution. J'ai même vécu l'expérience d'un groupe qui, au contact d'un API de virtualisation, s'est trouvé à engager des appels pour … augmenter la mémoire dévolue à la machine virtuelle sur laquelle leur appli tournait, à augmenter la puissance des processeurs, leur nombre, l'espace disque, etc. puis à relâcher les ressources quand elles n'étaient plus nécessaires. Les développeurs ADORENT automatiser et, soyons de bon compte, les ordinateurs sont des machines à automatiser !

Qui est de garde ?

Le succès de Netflix est planétaire. Ce succès, la société le doit à sa grande maîtrise technologique qui lui a permis de migrer d'une entreprise de location de vidéos pour être aujourd'hui l'une des plateformes leader de services de streaming. En matière de Transformation Digitale, je pense que nous avons là l'exemple archétypal !

Un des architectes, sinon THE Architect, qui a été mis à contribution pour entamer la grande migration d'une infrastructure dédiée, avec ses propres centres de données, vers une architecture Cloud est Adrian Cockcoft. Il s'exprime ici sur le mouvement DevOps et ce qui a été le positionnement de Netflix sur le sujet :

Systems for Innovation - Adrian Cockcroft, at USI

Voici la traduction de transcription de ce que dit Cockcroft entre 38min 45sec et 40min 37sec dans la présentation, :

Je travaillais sur la migration de Netflix dans le cloud et, en 2006, […] les développeurs créaient des produits et les utilisaient en production. C'est ce que la plupart des gens appellent maintenant DevOps. Il y a deux versions de DevOps, mais la façon dont Netflix a abordé le problème était que les développeurs sont les propriétaires de leur code en production, donc nous avons construit un système qui était supporté par tout le monde. Cela signifie que vous pouvez faire plusieurs modifications par jour et que la personne qui connaît l'état actuel du système de production est le développeur qui le modifie. Il n'y a donc pas de silos, pas de réunions, pas de tickets à remplir, et tout le monde est propriétaire de tout, tout au long du processus. Alors, mettez les développeurs on call et comment faites-vous pour que les développeurs soient on call parce qu'ils disent je ne suis pas devenu développeur pour être on call ? C'est souvent la réponse ! Eh bien, demandez au vice-président de l'ingénierie qui dirige le développement, vous le mettez on call, et vous mettez tous les directeurs en garde et vous mettez tous les managers en garde et ensuite vous mettez les développeurs on call et vous dites au programmeur si vous ne décrochez pas le téléphone quand le système subit une panne à 3 heures du matin comme c'est toujours le cas, la prochaine personne dans la cascade est votre manager et s'il ne décroche pas le téléphone, on continue l'escalade jusqu'au plus haut niveau. Vous avez donc maintenant un système qui fait que les gens (1) écrivent du code qui ne se casse pas à 3 heures du matin et il s'avère que les développeurs sont très bons pour écrire du code qui ne se casse pas quand ils sont on call. C'est une boucle de rétroaction très puissante et l'autre chose que vous trouvez, c'est que les gens n'aiment pas réveiller les supérieurs, le management, parce qu'ils ont « merdé ». Il y a donc une très forte incitation à suivre cette voie.

Pas de solution miracle

Il est naïf de penser que le rapprochement entre les ingénieurs d'exploitation et les programmeurs est la réponse à tous les problèmes. Ce n'est évidemment pas le cas.

L'immersion temporaire, ou de plus longue durée, des Ops parmi les Dev est par contre une vertu qui n'a jamais été prise en défaut, du moins lorsque les groupes ainsi formés ne devenaient pas à leur tour des silos.

Ce cas de nouveaux silos peut se présenter lorsque les Ops deviennent plus préoccupés par le succès de l'équipe dont ils font maintenant partie que par leurs préoccupations de la bonne gestion de moyens mutualisés. Les silos qui sont tombés réapparaissent alors, ce qui est un comble.

L(i)VID, pour éviter cet écueil, recommande des tournantes de Ops parmi les Dev de telle sorte que les équipes puissent garder le contact avec des infrastructures partagées, ne fût-ce qu'au niveau physique et cela même si la tendance, comme en tout, est de dématérialiser le … matériel. L'apport régulier de nouveaux points de vue permet de garder l'équilibre souhaité entre Dev et Ops.

Énoncé de mission

L'énoncé d'une mission est affaire délicate et souvent excessivement théorique, une forme de compromission aveugle à des théories de Management désincarnées. C'est tout un art de pouvoir synthétiser en quelques mots une série d'images porteuses d'une direction avec suffisamment de garde-fous de telle sorte que cela permette à chacun de savoir ce qu'il y a à faire sans nécessiter de détails. C'est tout le sens du POMPrinciple Of Mission qui aide à diriger une équipe sans avoir à la manager, en lui donnant l'autonomie de trouver par elle-même comment arriver au but.

To be continued

La formation d'une équipe DevOps

Si vous pouviez faire en sorte que tous les membres d'une organisation rament dans la même direction, vous pourriez dominer n'importe quelle industrie, sur n'importe quel marché, contre n'importe quelle concurrence, à tout moment. — The Five Dysfunctions of a Team A Leadership Fable par Patrick Lencioni parlant d'un de ses amis entrepreneur.

Dans un monde idéal, les membres de l'équipe travaillent ensemble en douceur dès le premier jour. Ils se concentrent sur la mission de l'équipe, ils s'entraident en cas de besoin, chacun portant sa charge, etc. Malheureusement, ce n'est JAMAIS le cas, je le crains. Il faut du temps avant que l'équipe puisse fonctionner en tant que véritable équipe, et encore plus de temps pour avoir une équipe performante. Bruce Tuckman a introduit un modèle de développement de groupe en 1965 dans lequel il dit qu'une équipe passera par 4 étapes de développement : Forming, Storming, Norming, Performing. Regardez les vidéos suivantes pour voir ce qu'il faut pour former une équipe :

Team development stages- Remember the titans
The five stages of team development

Il est important de savoir à quelle étape du modèle de Tuckman se trouve une équipe avant de la prendre en charge afin de l'aider à se développer et à franchir avec succès chaque étape jusqu'au niveau le plus haut, performing.

  • Déterminer l'étape à laquelle se situe l'équipe actuellement
  • Observer les relations interpersonnelles et détecter les conflits latents

Les 4 étapes du modèle de Tuckman

Le modèle de Tuckman sur Wikipedia : Tuckman's stages of group development

Forming

La formation d'une équipe est presque l'étape la plus facile du processus. La composition de l'équipe n'est que très rarement optimale. En général, les membres de l'équipe sont attribués plutôt que choisis; ils le sont souvent sur le critère de leur disponibilité et non sur leur apport adapté potentiel à la tâche à réaliser. Pour ces raisons, et d'autres inhérentes au fait que les hommes et les femmes sont des êtres imparfaits, une équipe est presque toujours intrinsèquement dysfonctionnelle.

Néanmoins, à ce stade, il règne une atmosphère en général positive et polie, les gens sont agréables les uns avec les autres et ils ont des sentiments différents d'excitation, d'enthousiasme et de positivité. Ils font bonne figure comme on le fait dans une soirée où un premier contact est établi : chacun veut donner bonne impression, il faut se montrer sous un bon angle et gagner la confiance des autres.

L'équipe se réunit et apprend à connaître les opportunités, les dangers et les défis qui sont les siens. Les objectifs sont présentés mais chacun s'en fait une représentation propre sauf si les membres de l'équipe se sont côtoyés et entendus pour des missions précédentes et qu'ils ont pu apprécier leurs contributions personnelles avec justesse. La compréhension partagée est donc souvent un leurre même si l'équipe déclare le contraire. L'équipe n'est à ce stade guère plus qu'une collection d'individualités indépendantes tournées sur ses propres problèmes et objectifs. Le projet dont il faut se saisir est considéré comme une opportunité personnelle par chaque individu. En revanche, il peut arriver que certaines personnes, intégrées dans le groupe par obligation, se désintéressent d'emblée du sujet qu'ils trouvent absurde.

Les membres matures de l'équipe ont quant à eux un comportement différent dès cette phase initiale. Ils engagent à la cohésion du groupe. Ceux qui ont été exposés aux principes de l'Agilité tentent d'en insuffler l'esprit aux novices. FROCCFocus, Respect, Openness, Courage, Commitment est répété aussi souvent que possible :

Les valeurs défendues par l'Agilité (Scrum) : FORCE en
                    français … Focalisation, Ouverture, Respect, Courage,
                    Engagement — FROCC en anglais … Focus, Respect, Openness,
                    Commitment, Courage
Les valeurs défendues par l'Agilité (Scrum) : FORCE en français … Focalisation, Ouverture, Respect, Courage, Engagement — FROCC en anglais … Focus, Respect, Openness, Commitment, Courage

  • Exposer le pourquoi du projet et les objectifs du groupe (OKR — Objectives and Key Results)
  • Établir une charte (périmètre, mission + objectifs, rôles, règles, critères de succès, …)
  • Définir les rôles personnels et les objectifs de chacun
  • Placer la charte à un endroit visible par tous pour que personne ne puisse l'ignorer et qu'elle imprègne toutes les actions menées.
  • Exposer les contraintes circonstancielles (budget, timeline, défis, …)
  • Être le chef d'orchestre des tâches qui doivent être menées
  • Identifier les besoins, tant matériels qu'humains. Cela va jusqu'à identifier les besoins de formation.

Storming

C'est la deuxième étape du développement de l'équipe. Lorsque les membres du groupe commencent à travailler ensemble, ils sont mis au contact des styles de travail individuels et ce que c'est que de travailler ensemble en équipe. Les membres se testent les uns les autres; celle ou celui qui est le plus "testé" est le chef d'équipe.

Chacun se fait une opinion sur le caractère et l'intégrité des autres participants. Les circonstances portent les membres à exprimer leurs opinions s'ils trouvent quelqu'un qui se soustrait à ses responsabilités / obligations ou qui tente de dominer. Des sentiments de suspicion, de peur et d'anxiété, latents ou non, se développent.

Les membres de l'équipe placent leurs intérêts personnels au-dessus de ceux du groupe. Les positions de statut redistribuent prestige et influence.

Plus l'équipe est dysfonctionnelle, plus les participants remettent en question les actions ou les décisions des autres membres mais de manière singulière celles du chef (tester la solidité).

Les désaccords et les conflits de personnalité doivent être résolus avant que l'équipe puisse sortir de cette phase. Certaines équipes n'en sortent jamais ou y reviennent souvent et facilement si de nouveaux défis ou différends surgissent.

Cette phase peut devenir destructrice pour l'équipe et réduira la motivation si on la laisse s'emballer.

  • Travailler la motivation des membres du groupe
  • Adresser les problèmes et ne pas les éviter
  • Comprendre plutôt que juger; comprendre les enjeux personnels
  • Insister sur l'importance des objectifs du groupe vs. objectifs et ambitions personnels
  • Marteler le Pourquoi du groupe
  • Exposer les forces (et faiblesses, mais insister sur les atouts) des membres du groupe
  • Décrire la manière de traiter et de gérer les plaintes
  • Être accessible et disponible
  • Adapter si nécessaire le mode d'interaction et les comportements et obtenir l'approbation du groupe
  • Souligner la nécessité de tolérance et accepter les différences
  • Prendre les décisions à la place du groupe s'il ne parvient pas à dégager un concensus

Norming

Les désaccords résolus et les conflits de personnalité entraînent une plus grande intimité, et un esprit de coopération émerge — Rob Chatfield in Leadership The Outward Bound Way: Becoming a Better Leader in the Workplace, in the Wilderness, and in Your Community. C'est ce qui se produit lorsque l'équipe partage un objectif commun et que chacun contribue à la réussite de cet objectif plutôt qu'à la réussite de ses objectifs personnels ou plutôt quand chacun prend conscience que l'objectif commun participe à la réalisation de ses objectifs personnels. Ils commencent à tolérer les caprices et les fantaisies des autres membres de l'équipe. Ils acceptent les autres tels qu'ils sont et font un effort pour aller de l'avant. Le danger ici est que les membres peuvent être tellement concentrés sur la prévention des conflits qu'ils en deviennent réticents à partager des idées qui pourraient apparaître controversées qu'ils estiment être de nature à les refaire tomber dans la phase de Storming.

  • Insister sur l'importance de l'aide : demander et donner de l'aide. Demander de l'aide n'est pas un aveu de faiblesse; c'est avant tout une connaissance éclairée de ses propres limites.
  • Positiver les différences entre les membres de l'équipe et détecter en quoi ces différences sont des atouts plutôt que des entraves.
  • Instiller une démocratie : remettre les clefs des décisions à l'équipe
  • Ne pas etouffer les conflits; aider les membres de l'équipe à les affronter tout en respectant les règles en vigueur pour les résoudre.
  • Instiller la confiance : chaque membre de l'équipe doit pouvoir compter sur les autres membres.

Performing

Une fois les normes et les rôles du groupe établis, les membres du groupe se concentrent sur la réalisation d'objectifs communs, atteignant souvent un niveau de réussite étonnamment élevé — Rob Chatfield in Leadership The Outward Bound Way: Becoming a Better Leader in the Workplace, in the Wilderness, and in Your Community. Les membres de l'équipe sont maintenant compétents, autonomes et capables de gérer le processus de prise de décision sans supervision. La dissidence est considérée comme normale et autorisée tant qu'elle est canalisée selon les règles érigées et acceptées par l'équipe.

L'équipe prend la plupart des décisions. Le chef d'équipe participe au processus mais plus en qualité d'arbitre que comme dirigeant de la manœuvre. Même les équipes les plus performantes reviendront à des étapes antérieures dans certaines circonstances. De nombreuses équipes de longue date passent par les 4 cycles à maintes reprises, car elles réagissent à l'évolution des circonstances. Par exemple, un changement de direction peut entraîner un retour à la tempête, les nouveaux membres remettant en question les normes et la dynamique de l'équipe.

  • Faciliter mais ne plus diriger; viser un objectif d'auto-direction (self-organizing team)

Expériences personnelles

À titre personnel j'ai connu 4 expériences notables des phases du modèle de Tuckman, chacune avec des résultats différents mais toutes confirmant la justesse du modèle.

Banque — Projets de réparation de messages de paiement (Swift) et de Compliance Filter

J'arrivais comme nouveau chef d'équipe dans un projet Web traitant des messages de paiement Swift. Je devais remplacer le chef en place au caractère bien trempé qui était renvoyé à la position de programmeur-analyste ce qu'il avait pris pour un désaveu de ses compétences. Il a fallu 5 mois pour sortir de la phase tempétueuse avec une équipe de 6 personnes et pour établir des règles d'engagement et d'interactions acceptables. L'équipe dont j'avais la charge a pu rapidement évoluer par la suite pour finalement devenir celle qui après 2 ½ ans a donné la cadence au reste de l'organisation (± 55 personnes) et atteindre d'ailleurs l'excellence à l'international en gagnant des marchés très enviés par les plus grandes entreprises du secteur. J'estime à une durée de 1 an le passage par les phases de Norming et Performing de l'équipe qui a inventé et développé X- Stream labellisé Gold par Swift en 2002, l'EAI financier le plus rapide au monde. Voilà donc une phase Performing finale bien atteinte avec des gens qui s'appréciaient les uns les autres, fiers des résultats atteints. Chacun était fortement engagé dans son travail personnel et dans les objectifs de groupe.

Banque — L'arrivée d'un nouveau patron

Cette expérience fait suite à la première. Nous voilà dans une entreprise avec une équipe bien soudée mais où des adversités et jalousies minent diverses équipes qui forment ainsi des clans. La Direction prend la décision d'envoyer tout le management en cours de résolution de conflits. Chacun en ressort avec un arsenal de méthodes qui permettent d'apaiser les tensions. Malheureusement, cela ne permet pas de désamorcer la situation et manipulé par un de ses membres le Management se retourne contre la Direction en place, laquelle finit par annoncer son départ. Le nouveau patron, issu du Management en place, se livre à une forme de nettoyage et élimine les postes doublons ainsi que les personnes qui s'étaient opposées à lui antérieurement. D'une situation globale où l'ensemble de l'entreprise se trouvait en phase Performing, nous sommes retombés à une phase Storming. Cette dégradation a été observée en 6 mois et l'entreprise n'a plus jamais retrouvé son niveau de performance antérieur. Elle a finalement été acquise par le groupe Temenos. Retomber à des niveaux antérieurs peut se faire singulièrement plus vite que gravir les échelons.

Énergie — Business Intelligence

J'arrivais comme nouveau chef d'équipe dans un contexte difficile où le chef de projet en place, un homme charmant, avait subi un putsch de la part du Solution Architect qui souhaitait endosser aussi la responsabilité de chef de projet. L'ambiance était détestable et l'équipe était connue pour n'avoir rien livré d'utile en 4 années d'existence.

Handicapée par une réputation difficile et mêlant à cela des conflits interpersonnels lourds, il a fallu 7 mois (de juillet à janvier) pour sortir de la phase de Storming. Cette sortie de phase a coïncidé avec les premiers (difficiles) déploiements en production mais aussi avec une "altercation" avec l'architecte putschiste qui n'avait jamais abandonné son combat. 1 ½ mois après la toute première livraison en production, l'équipe en était arrivée à pouvoir effectuer des déploiements réguliers amorçant ainsi sa phase de norming. 1 mois plus tard encore, déployer en production chaque vendredi se faisait sans effort et faisait l'objet d'un rituel bien rodé : la durée d'un sprint était passée de 1 mois à 2 semaines puis à 1 semaine. L'équipe était alors devenue parfaitement autonome. Il avait fallu tout juste 1 an pour aller du S au P avec une équipe de 14 personnes.

Syndicat — Programme de modernisation et transformation digitale

Le quatrième cas de figure que je souhaite évoquer est mon entrée comme Transformation Manager du programme Genesis auprès d'un grand syndicat belge. Appelé par le CIO fraîchement nommé, ma mission était de moderniser l'IT du syndicat en adressant 3 problèmes cruciaux. Parmi eux, le manque d'esprit d'équipe dans l'ensemble du département IT. En 18 mois, et après avoir consommé 3 directeurs IT successifs, l'organisation IT de 27 personnes était toujours embourbée dans la phase de Storming où l'avaient enfoncée certains individus fragiles et parfois caractériels. La solution au problème était évidente et consistait à se poser la question que Jim Collins a popularisée dans son livre Good to Great : First Who … Then What. We expected that good-to-great leaders would begin by setting a new vision and strategy. We found instead that they first got the right people on the bus, the wrong people off the bus, and the right people in the right seats […] People are not your most important asset. The right people are.. Situation particulièrement embarrassante pour un syndicat lorsqu'on évoque les termes the wrong people off the bus et qui exige, pour le bien du groupe, une sacrée dose de courage.

Membres de l'équipe DevOps

En termes simples, une équipe DevOps comprend tous les rôles quotidiens nécessaires pour mettre en production des logiciels de qualité de la manière la plus sûre et la plus appropriée possible, dans le respect des règles établies par l'organisation (parfois en renversant le statu quo). C'est la phrase clé pour résumer la composition de l'équipe. Elle ne se limite donc pas aux seuls développeurs et aux opérations : testeurs, middleware, sécurité, base de données … [4] .

Bien sûr, il ne sert à rien d'assembler des équipes DevOps si l'organisation n'a pas rendu possible le déploiement en production par les équipes, le cas échéant avec quelques étapes supplémentaires (sécurité, vérification, …), peut-être sous-optimales, mais constituant déjà une nette avancée dans le paradigme DevOps. Cela implique de repenser en profondeur plusieurs processus de base, ce qui est plus un changement culturel que technique, donc beaucoup plus difficile à mettre en place.

Le Product Owner

La personne chargée de maintenir le backlog de l'équipe (ou Team Backlog en L(i)VID) en représentant les intérêts des parties prenantes, et en assurant la valeur du travail de l'équipe de développement — Wikipedia

Le Product Owner représente TOUS les acteurs du projet :

  • les sponsors du projet (généralement le Business dans une entreprise)
  • les utilisateurs finaux du système qui sera construit dans le sens le plus large possible : consommateurs, administrateurs, voire développeurs, etc.

Le Product Owner (PO) est une des parties prenantes, ou a l'autorité et la responsabilité de décider en leur nom (ce qui est clairement ma préférence).

Le Product Owner est donc le mandataire et non la passerelle vers le propriétaire légitime. Les "passerelles" transmettent des messages d'un bout à l'autre et ralentissent en fait le processus comme dans l'exemple Bonne question, je vous rappellerai, je dois demander au Business. Pour L(i)VID, le Product Owner est la partie représentant les utilisateurs finaux mais ne peut se substituer à eux : l'accès le plus direct aux clients / utilisateurs est toujours souhaitable.

Scrum Master

Pour L(i)VID, il n'y a pas d'obligation d'avoir un Scrum Master. C'est un rôle qui est condamné à disparaître à plus long terme, lorsqu'une équipe a atteint un niveau de maturité suffisant.

Nous adoptons exactement la même philosophie que celle exprimée par Nic Ferrier, un consultant de ThoughtWorks spécialisé dans les DevOps. Il dit :

Il y a une comme une forme de religiosité chez les thuriféraires de Scrum : vous avez besoin d'un Scrum Master et il doit être ce genre de personne qui aide les développeurs et qui ne code pas lui-même. […]

Tout cela n'est que balivernes. Sans équivoque. Vous n'avez pas besoin d'un Scrum Master pour une équipe, en fait cela décourage activement l'équipe de s'occuper d'elle-même. Mais dans une situation où vous avez des développeurs qui ont été étroitement gérés au jour le jour, peut-être qu'un type de Scrum Master qui est plus un leader-serviteur qu'un chef de projet aiderait les équipes à apprendre à s'occuper un peu d'elles-mêmes.

Longévité

Il y a une confusion apparente entre la longévité d'une équipe DevOps et la durée des contrats passés avec les personnes de l'équipe. J'y reviens avec le point ci-dessous.

Il faut voir cela comme un club de football (l'équipe 'DevOps) et les joueurs qui composent l'équipe : le club existera très probablement bien après qu'un individu soit transféré vers un autre club. L'équipe DevOps existe aussi longtemps que les produits ou technologies qu'elle crée et soutient sont utilisés et maintenus dans l'organisation.

Les contrats

L'équipe DevOps existe aussi longtemps que les produits ou technologies qu'elle crée et soutient sont utilisés et maintenus dans l'organisation.

L'équipe peut et doit évoluer mais son noyau doit rester stable. Cette réflexion nous amène à considérer avec attention les contrats qui sont établis avec les collaborateurs externes.

La majorité des personnes qui travaillent pour une organisation peuvent encore être des employés de l'organisation. Mais une minorité très importante et en constante augmentation — bien que travaillant pour l'organisation — ne sont plus ses employés, et encore moins ses employés à plein temps.

Drucker, Peter F. in Management Challenges for the 21st Century

Les membres d'une équipe DevOps doivent être « signés » pour une longue période, généralement entre 1 et 2 ans au moins, mais certainement pas pour 3 ou 6 mois ce qui est le signe d'une organisation qui ne comprend pas que le travail d'équipe, et que c'est la qualité des femmes et des hommes qui est devenu aujourd'hui le moyen le plus sûr de générer des avantages compétitifs. Cette recommandation vise avant tout les collaborateurs externes mais le principe vaut pour tous les collaborateurs, ce qui met d'ailleurs à mal le principe d'organisation autour de … projets [5] .

Ce n'est pas la finance, pas la stratégie, pas plus la technologie mais bien le travail d'équipe qui reste l'avantage compétitif ultime, parce qu'il est à la fois si puissant et si rare. — Patrick Lencioni in The Five Dysfunctions of a Team — A Leadership Fable

Le texte qui suit est temporaire

C'est un malfonctionnement que de ne pas intégrer la dimension travailleurs externes dans les politiques de ressources humaines et d'achats. Expliquer cela. Dire que c'est nécessaire de prendre cette problématique à bras le corps ce qui peut d'ailleurs commencer assez simplement par une déclaration de principe : «nous prenons le même soin avec les travailleurs externes qu'avec nos employés" ... puis évidememnt vivre pleinement ladite déclaration sans quoi nous serions dans la schizophrénie en annançant une oersonnalité et en en vivant une autre.

TEXTE A RECASER

a besoin d'apprendre les uns des autres et que chaque membre a besoin pour adapter %-% c'est vraiment à double sens%-%et cela ne va pas se faire du jour au lendemain. Il faut du temps pour que la pâtisserie se forme. Comment cela se fait-il déjà ? Nous avons en viennent à valoriser les individus et les interactions plutôt que les processus et les outils. Ce Une simple déclaration implique une sorte de chaîne de réactions. Par exemple, si une équipe est composé de personnes extérieures, comment la banque devra-t-elle s'y prendre pour garantir l'engagement des partenaires de sourcing ? Comment cela affecte-t-il Change and Run ? etc.

Inversement, il faut savoir qu'une escouade de DevOps doit rassembler toutes les compétences nécessaire à la réussite du projet au sens propre du terme. équipe fonctionnelle est. Cela pose la question des compétences qui peuvent ne pas être présentes (parce qu'elles n'ont pas été détectées lors de la mise en place, par exemple) ou des compétences qui ne sont plus nécessaire à un certain moment. L(i)VID réagit à ces deux cas avec bon sens : les faire monter à bord en cas de besoin et les libérer si ce n'est plus nécessaire. Malgré ce que diront la plupart des anciens d'Agile, cela nécessite un peu de la planification et donc certaines compétences en matière de gestion de projet.

La raison pour laquelle L(i)VID recommande cette pratique est que les membres du groupe ont besoin de se dompter les uns les autres avant de pouvoir prétendre à une forme d'excellence. C'est un processus lent et organique que Bruce Tuckman a modélisé avec la construction de la cohésion d'équipes en 4 phases (petits groupes). On mise sur l'humain et sur ses interactions. Disposer d'un noyau stable de long terme est un élément substantiel de la mise en place des équipes DevOps.

Il n'y a pas de montée en puissance soudaine (ramp-up) (nous le savons depuis Frederick P. BrooksThe Mythical Man-Month — Pearson Education) et pas de descente en pente raide (ramp-udown), sauf à vouloir connaître la phase de Storming à chaque recomposition d'équipe, sauf à s'exposer à chaque fois aux coûts des courbes d'apprentissage, sauf à […]

Nous en sommes venus à valoriser les individus et les interactions plus que les processus et les outils […] — Manifeste pour le développement Agile de logiciels

Il y a un véritable dysfonctionnement à travailler avec des départements Procurement complètement détachés des réalités du Management du 21ème siècle. Il est nécessaire de revoir ce fonctionnement tout en dépouillant le principe général — et idéal — des formes de naïveté qui lui sont préjuciables. Il faut un modèle équilibré où la réalité économique de l'entreprise n'est pas oblitérée. Voilà un sujet significatif des politiques de Sourcing qui rendent souvent nécessaire de revoir les positions globales. Là encore, il s'agit d'un chantier qui n'est pas mince.

The Contract

VOIR SI CE CONTENUI A ETE TRADUIT

The individuals of a DevOps Team are « signed » for a long period, typically between 1 and 2 years at least. The reason why L(i)VID recommends this practice is because a group needs to learn from each other and each member needs to adapt%-% it is really two-way%-%and this is not going to happen overnight. Time is needed for the pastry to come together. How is that again? We have come to value individuals and interactions over processes and tools. This simple statement implies a sort of chain of reactions. For example, if a team is composed by externals, how does the bank will have to try to secure a long term commitment of sourcing partners? How does that affect Change and Run? etc.

Conversely, one must know that a DevOps Squad must gather all the skills necessary for the project to succeed in the true sense of what a cross- functional team is. This brings the question of skills that may not be present (because for example they were not detected during setup) or skills that are no longer necessary at a certain point in time. L(i)VID reacts to these two cases with common sense: bring them aboard when needed and release them if no longer needed. Despite what most alumni of Agile will say, this requires a bit of planning and therefore some Project Management skills.

How Many?

Metcalfe's Law and Project Teams — Keep the team as small as possible. Metcalfe's Law, that « the value of a communication system grows at approximately the square of the number of users of the system, » has a corollary when it comes to project teams: The efficiency of the team is approximately the inverse of the square of the number of members in the team. I'm beginning to think three people is optimal for a 1.0 product release…Start out by reducing the number of people you plan to add to the team, and then reduce some more. Marc Hedlund, entrepreneur-in-residence at O'Reilly Media https://gettingreal.37signals.com/ch03_The_Three_Musketeers.php

Being agile means keeping the size of teams small. Why? Small teams do not have a lot of communication overhead. A team of 5 for instance has 5 * (5 - 1) / 2 = 10 communication lines. A team of 9 has 9 * (9 - 1)/ 2 = 36 ! So, aligning 9 people already starts taking important amounts of time. That's why L(i)VID, unsurprisingly, recommends teams of 7 to 9 people, with a clear preference for 7 [6] (see %FORMULA%, %IPC% and %IPI% for more information). That being said, %-XP% recommends other limits: 12 (Team) or 150 (Team of teams). Across these thresholds XP says that you will have hard time keeping the necessary trust for good collaboration. We hold with our number of 7, which we also called the %MAGIC-7%! [7]

The first step was to change the composition of teams. Existing teams were organized around functions; the new teams would be interdisciplinary teams of about seven peopleMary and Tom Poppendieck in The Lean Mindset: Ask the Right Questions

Réduction de l'équipe

Une équipe DevOps, assemblée pour un terme long (au moins 1 à 2 ans, voire 3), s'occupe de la mise au point de produits et services ainsi que de leur maintenance et support, en accord avec le principe You build it, you run it institué par Amazon.

Cependant, un produit ou service n'échappe pas à son cycle de vie habituel : les produits / services naissent, vivent et meurent [8] .

L'équipe DevOps existe aussi longtemps que les produits ou technologies qu'elle crée et soutient sont utilisés et maintenus dans l'organisation.

Cycle de vie générique d'un produit / service
Cycle de vie générique d'un produit / service

Il ne faut donc pas s'étonner qu'aux étapes FSNP (Forming, Storming, Norming, Performing) s'ajoute une autre phase qui en est le démantèlement, mais aussi cette autre phase, intermédiaire elle, qui existe tout au long de la vie de l'équipe : sa réduction [9] .

Cette phase de réduction s'explique par le simple fait qu'en phase de maturité du produit / service il y a généralement moins de choses à faire. En période de maturité, le produit / service est dans cette phase où il est le plus profitable (ratio coûts / bénéfices). Le marketing et la direction stratégique de l'entreprise ont tendance à investir le strict minimum dans le produit / service, entendez de quoi prolonger sa période de maturité le plus possible, tout en gardant la concurrence à distance. Dans cette période donc, le travail de l'équipe diminue, du moins habituellement, sauf à préparer de nouvelles moutures.

Plusieurs stratégies existent pour prolonger la vie de l'équipe dont l'atout essentiel est d'avoir pu démontrer sa capacité à travailler ensemble et à créer et maintenir des produits / services. Il est par exemple possible d'ajouter d'autres produits / services au portefeuille de l'équipe, surtout ces produits / services qui requièrent des compétences similaires. Une autre stratégie consiste à faire varier la taille de l'équipe dans le temps et lentement pour ne pas la déstabliser. C'est de cette stratégie-là dont je traite ici.

Au fur et à mesure que l'équipe DevOps gagne en maturité, essayez de réduire légèrement et progressivement sa taille (pas plus de 2 membres à la fois maximum). Cela rend les personnes disponibles pour d'autres équipes, en particulier celles qui commencent leur transition (voir aussi le 5e principe du Knowledge Management promu par l'Agilité). N'essayez pas d'occuper l'équipe de manière à ce que tous les membres aient la même charge de travail car c'est simplement, par analogie, une manière de devenir un gaz parfait, un gaz qui occupe tout le volume qui lui est donné. Essayez de déterminer qui peut et veut faire passer le message ailleurs dans l'organisation. Voyez à cet égard ce que j'en dis avec SARASend Ambassadors; Receive Ambassadors

LA SECTION SUIVANTE N'EST PAS DU TOUT A SA PLACE

Le Pipeline de déploiement

Trop souvent, on entend dire que le souci des entreprises dans la mise en place des équipes de développement est la seule automatisation du pipeline de déploiement. C'est bien sûr important, mais ce n'est PAS, comme nous l'avons démontré dans les premiers paragraphes de cette page, le paradigme le plus important de DevOps, ou pour altérer un peu ce que nous prétendons, le seul paradigme à aborder. Il y a le principe du « Shift Left ». Maintenant que nous avons clarifié les choses, voyons un peu ce qu'implique l'amélioration et l'automatisation du pipeline.

Le point que nous voulons faire valoir maintenant est qu'une organisation ne fournit aucune valeur réelle et tangible avant que le logiciel qui a été construit n'atteigne les %USER%s, les utilisateurs finaux que nous voulons dire, donc avant que les solutions n'aboutissent en production.

Il s'agit d'un paradigme Agile selon lequel la valeur doit être délivrée dès que possible, éventuellement à la fin de chaque itération. Ce point a été fortement débattu dans de nombreux articles de la communauté Agile, ce qui a conduit à l'utilisation de termes telles que "incrément potentiellement livrable", "incrément logiciel libérable", "code déployable", etc. J'ai abordé ces sujet dans les pages %S-REALLY% et %FRR%.

L'essentiel du paradigme DevOps est d'avoir du code déployable à tout moment, ce qui nécessite le recours à l'automatisation, et c'est précisément là que nous avons besoin de la rationalisation du pipeline de déploiement.

TOUT LE RESTE EST A CASER GENTIMENT POUR UN FLUX DE LECTURE AGREABLE ET LOGIQUE

Release Train

As a Release Train is the gathering of all the DevOps Squads, it is perfectly normal that it acts in the longer term also. No confusion here with the longevity o ou f a train: the train will exist as long as the DevOps Squads that compose it exist but, please, bear in mind that the train may need some maintenance from time to time! (see %TH%)

Access to Production Environment

There is a lot of paranoia and sensitivity about that very subject. Agilists require access; governance prohibits such accesses. Who is right? L(i)VID suggests that access should be given, at least in read-only mode and that all data related to incidents are available without any restriction to all members of the DevOps Team.

It's amazing how the walls between developers and testers melt away when developers automatically have everything they need to re-create the failure — Gary Gruver, Mike Young, and Pat Fulghum in A Practical Approach to Large-Scale Agile Development %-% How HP Transformed LaserJet FutureSmart Firmware

The more info is available, with the less friction, the better. After all, you have DevOps Squads in place, not cowboys. After all you have chosen to trust people, and a trust culture goes hand in hand with responsibility and accountability.

Infrastructure as Code

ICI, IL FAUT PARLER DE CELA CAR C'EST LA CLEF DE LA MAITRISE DES ENVIRONNEMENTS DE MANIERE AUTOMATISEE.

Some Practices (and basis of a DevOps Maturity Assessment)

When it comes to define what a DevOps Team should do, or should be able to do, it is interesting to go through 2 illustrations:

DevOps extends the horizon of Agility
The “Shift Left” principle of DevOps illustrated
Deployment Route
Phases of the Deployment Pipeline Automation

This first view shows how DevOps fit the end-to-end picture. This is the view above. The complementary view comes from Deployment Pipeline:

This second view shows how DevOps is supposed to streamline development and release, or at least this is what is triggering our interest here.

Let's synthetize these two views:

DevOps - span of activities
Span of activities for a DevOps organization

Given the picture above, some practices may be considered as important in your journey towards DevOps. Here is an attempt to list such practices, in no particular order, so that you can judge by yourself how DevOps you are, probably leading to a sort of scale of maturity (which should be no more than a hint for a possible next target condition %-% see %TK%):

  1. Develop, Test
    • DevOps can create sandboxes that are similar to production systems
    • DevOps Teams are able to to request automated machine provisioning for development and test purposes.
    • DevOps can simulate service requests/responses for dependent systems.
    • DevOps seamlessly integrate with %TT%s
    • %-TT%s share their %HLTLS% and all mechanisms to validate the software
    • Aspiration Layer (Business), Engineering (DevOps and Operations have a set of Non-Functional Requirements related to global performance, uptime, MTBF, MTTR … and all parties know about such requirements.
    • DevOps backlogs include Change and Run types of work. Product Owners take both concerns into consideration (include operational requirements in the Team Backlog and %IBL%).
    • DevOps Teams use automated testing all across the development lifecycle
    • DevOps Teams incorporate "cardio" code in their code as to check that the system operates in normal conditions.
    • Customers/users feedback loops are included in application design.
    • DevOps and Operations agree on the structure and content of the log files.
    • DevOps and Operations agree the way the log files are purged.
    • Operations concerns can be taken into consideration for websites and mobile applications alike.
  2. Deploy, Release
    • Deployments and Releases are highly visible and closely monitored operations.
    • Deployments and Releases are audited and provide reporting.
    • DevOps are responsible for application deployments (manual or automated).
    • Releases are automated at the max in function of their "distribution" method (e.g. "web based" software vs. "shrink- wrapped" software)
    • Fine-grained deployment is possible
    • Fine-grained activation is possible
    • Fine-grained rollback is possible
    • DevOps Teams can have on-demand provisioning for live environments
    • Releases can be coordinated with external partners if need be.
    • Release decisions are based on cost vs. benefits analysis taking into consideration the optimization of the full value stream of the company. Transaction and coordination costs are taken into consideration.
    • DevOps Teams can release on demand.
  3. Operate, Maintain
    • DevOps Teams are on-call as first line support.
    • DevOps Teams monitor application performance (and understand system performance).
    • DevOps Teams together with %TT%s can easily reproduce the conditions that cause problems in the real live environment.
    • DevOps Teams have reserved capacity to guarantee swift reaction in case of incidents.
    • DevOps Teams and Operations are quickly capable to restore services; fine-grained rollback is possible.
    • Operations and DevOps monitor constantly the state of the the Information System.
    • Log files provide the mechanisms for alerting. DevOps and Operations have agreed on the structure and content of such log file and understand their intention.
    • Alerts are generated to the attention of Operations and DevOps Teams. All alerts reaching a DevOps Team are understood by the members of the team.
  4. Organizational
    • Ops representatives immerged in the Agile Teams (hence … DevOps!)
    • Operations participate at the Sprint Planning
    • Operations participate at the %Sprint% %RETRO%
    • A regular meeting (%OR%) takes place between Operations and Engineering whose goal is to assess how both did and what can be improved (special emphasis on outages)
    • DevOps have access to any incident detail in order to conduct the %-OR% meeting.
    • The DevOps backlogs are organized in such a way that both Change and Run types of items are visible and prioritized at any given time.
    • DevOps Teams and Operations share goals and responsibilities for key, highly visible metrics.
    • The metrics cover the set of Non-Functional Requirements related to global performance, uptime, MTBF, MTTR … that all parties agreed with
    • DevOps Teams and Operations mentor other teams' members.
    • The organization organizes trainings and provides coaching to help foster the DevOps Culture.
    • The organization organizes regularly an Operations Game Day exercise whose goal is to compromise the systems in use as to see how the company, and more particularly DevOps Teams and Operations, will need to collaborate in order to solve the problems at hand. Both groups share their learnings, which feed the appropriate backlogs of the respective teams (cfr. Chaos Monkey).

See Also

/happy-workforce/

Footnotes

[1] … On peut parler des aspects stratégiques, importants bien évidemment, mais le code informatique est souvent le grand absent des réflexions. C'est pourtant par lui que passent toutes les transitions digitales.

[2] … Développement à comprendre au sens de 'programmation'

[3] … L'erreur n'était pas due à notre code : il s'agissait d'un bug de cache dans SpringBoot

[4] … Le fait de s'appuyer sur des experts à certaines occasions ne signifie pas que ces rôles soient inclus à tout moment dans l'équipe

[5] … Un projet commence et termine à des dates déterminées. Il en découle que les équipes sont assemblées au début du projet et démantelées à la fin, ou du moins c'est censé fonctionner comme cela.

[6] … The L(i)VID formula uses a threshold of 7, after which it incurs some sort of penalty.

[7] … L(i)VID includes the %-PO% and the Scrum Master in that magical 7 simply because they heavily participate to the communication happening in the team

[8] … Ce cycle de vie n'est d'ailleurs pas sans impact sur la manière d'aborder le financement des initiatives. C'est la question qui se pose dans les approches projets vs. les approches produits.

[9] … Le modèle de Tuckman a été amendé en 1977 en lui adjoignant la phase «Adjourning» : désengagement du personnel, en particulier pour les organisations fonctionnant en mode projet.