Category Archives for "Fiche Pratique"

Conduite du changement Agile

L’adoption des méthodes agiles est indéniablement porteuse de changement, or l’être humain à naturellement tendance à résister à ce dernier. Consciemment ou inconsciemment. Le changement implique la perte de repères suivi d’une période chaotique jusqu’à la mise en place des nouveaux repères. Plus il est profond, plus la période de transformation peut s’avérer chaotique. Voir l’Agilité comme un processus ou une méthodologie, sans considérer sa dimension culturelle (cf. manifeste Agile), peut se révéler dangereux et provoquer l’échec de sa mise en oeuvre en sein d’organisations dont la culture est trop éloignée de la philosophie Agile et trop conservatrice. C’est pour cette raison que réussir sa transformation Agile peut faire l’objet d’un véritable défi. Cet article donne quelques outils pour faire face à ce défi.

Sources de résistance au changement

Distinguons deux grandes catégories de résistances au changement. Les résistances humaines et les résistances organisationnelles.

Voici quelques facteurs de résistances humaines :

  • Renoncer à la croyance que l’on peut spécifier intégralement un logiciel à l’avance.
  • Renoncer à la croyance que l’on peut élaborer un plan précis à l’avance sans revenir excessivement dessus.
  • Accepter de piloter par les délais et considérer le périmètre comme la principale variable d’ajustement.
  • Parler quotidiennement debout devant ses collègues de son travail et de ses difficultés.
  • Renoncer à l’illusion de l’efficacité du mode de management classique (« command and control ») sur des projets complexes.
  • Peur de perdre ses responsabilités dans le cadre d’un changement de son rôle.
  • Peur de ne pas être à la hauteur face aux nouvelles façons de travailler.

Ces facteurs peuvent générer des comportements sceptiques voire saboteurs, au mieux suiveurs.

Photo du saut en Fosbury illustrant le changement Agile

Malgré l’efficacité flagrante du saut en Fosbury, il a fallut attendre plus de 10 ans avant que cette technique se généralise. Le temps que les athlètes changent leur façon de sauter et s’approprient la technique.

Côté organisationnel, nous pouvons notamment avoir à faire face aux résistances suivantes :

  • Processus d’évaluation annuel et système de prime privilégiant la performance individuelle plutôt que collective.
  • Le règlement intérieur empêchant l’aménagement de l’espace de travail (disposition des bureaux, affichage sur les murs, etc) ou l’utilisation d’un logiciel de tchat.
  • Services Achats qui refuse de renoncer au contrat au forfait classique fixant périmètre, délais et coût, rendant obligatoire la validation de l’intégralité des spécifications du logiciel avant le démarrage des développements.

Principes

« haut vers le bas » et « bas vers le haut »

La transformation vers l’agilité peur venir de deux sources différentes. Elle peut venir des tranchées; d’une équipe de développement par exemple; (le « bas ») ou de la direction (le « haut »). Chacune a ses avantages et limites. Un mouvement venant du bas permet une meilleure appropriation des changements opérationnels mais peut vite se heurter à une MOA qui ne veut pas jouer le jeu ou un service achat qui ne veut pas entendre parler de contractualisation Agile. A l’inverse, une approche par le haut peut déverrouiller une MOA ou un service achat, financer du coaching et des formations Agile mais aura du mal à ancrer durablement le changement en raison de la résistance naturelle au changement dont feront preuve les individus « soumis » à ce dernier. L’idéal est donc de trouver un équilibre entre une approche du « haut vers le bas » qui lève les blocages organisationnels et du « bas vers le haut » qui s’approprie le changement.

Commencer petit

On le sait, les changements apportés par l’approche Agile sont nombreux. L’objectif est d’ancrer durablement de nouvelles pratiques et faire naître de nouveaux réflexes. Pour cela, il faut accorder aux individus concernés le temps nécessaire à l’assimilation et appropriation de ces nouveautés. L’idéal est donc d’avancer pas à pas plutôt que d’adopter d’un coup l’ensemble des principes et pratiques Agiles. Ou à plus grande échelle de faire basculer progressivement en approche Agile les projets de l’organisation plutôt que tous d’un coup.

Amélioration continue

On peut penser que le voyage de transformation a une destination. Mais d’une certaine façon, ce voyage ne se termine jamais en raison du principe d’amélioration continue. A partir du moment où l’on cesse d’améliorer son processus de développement d’une itération sur l’autre, on cesse d’être Agile. Le contexte d’une organisation ou d’un projet est en perpétuel changement et le processus de développement ainsi que l’organisation en soi doivent suivre. Une fois que ce principe est acquis, le changement devient naturel et indolore (car on passe à une série de petits changement plutôt qu’à un gros) pour le bien de l’organisation et des individus qui la composent.

Mesurer

Mesurer est important pour deux principales raisons. Pour savoir d’où on part, se fixer des objectifs concrets, puis savoir régulièrement où nous en sommes. Et pour « faire la preuve » de l’agilité. Parfois, il sera nécessaire de fournir la preuve de l’efficacité de la nouvelle démarche adoptée afin de lever un blocage, passer un cap, étendre l’agilité au reste de l’organisation. Volumes d’anomalies, volume d’appels au support technique, nombre de jalons non respectés (et de combien de jours), volume de fonctionnalités délivrées en fonction du temps, délais de transformation d’une idée en fonctionnalité disponible pour les utilisateurs finaux, etc. Autant d’indicateurs qu’il est possible de mesurer.

Processus de changement

Lorsqu’on s’intéresse à la conduite du changement, on tombe généralement sur un acteur quasi incontournable dans ce domaine : John Kotter. John Kotter propose 8 étapes pour mener le changement :

  1. Instaurer un sentiment d’urgence;
  2. Constituer une coalition directrice;
  3. Élaborer une vision et une stratégie;
  4. Communiquer la vision du changement;
  5. Habiliter le personnel en vue d’une action suivant la vision;
  6. Générer des gains à court terme;
  7. Consolider les gains et introduire d’autres changements;
  8. Ancrage de nouvelles approches dans la culture de l’organisation.
Ces étapes peuvent vous guider dans votre transformation Agile. La création d’un sentiment d’urgence peut par exemple s’obtenir en utilisant les événements de votre projet ou organisation (jalons décisif non respectés, surcharge des appels au support technique, fort turn-over des équipes, budget d’avenants disproportionné, fonctionnalités inutilisées, démotivation/faible engagement, etc.). Vos mesures (cf. paragraphe précédent) peuvent vous aider à faire prendre conscience du sentiment d’urgence. Vous allez ensuite identifier les individus moteurs qui partagent ce sentiment d’urgence, fédérer ces derniers en sein d’une équipe (coalition) et définir avec eux votre vision et stratégie que vous allez ensuite diffuser. Etc.

Pratiques

Projet Pilote

Expérimenter l’approche Agile sur un projet Pilote avant de généraliser sur le reste de l’organisation est une pratique courante. Il faut cependant veiller à ce que les enjeux de ce projet ne soit ni trop élevés (au point de risquer d’échouer pour d’autre raisons que le choix d’une approche Agile), ni trop modestes (au point de ne pas pouvoir s’appuyer sur son succès pour généraliser ensuite). Le choix de l’équipe est également important afin de s’assurer que cette dernière jouera bien le jeu dans l’application des principes et pratiques Agile. D’autre part, en cas de succès, les membres de cette équipe prennent généralement le rôle de « coach » ou leader du changement vis à vis des équipes qui se lanceront à leur tour. C’est aussi pour cette raison que le casting est important.

Essaimage

Basculer d’un coup toute une organisation comptant plusieurs équipes et projets, voire plusieurs centaines de personnes peut se révéler risqué. Afin de sécuriser l’ancrage des changements méthodologiques, il est recommandé de procéder par essaimage. Cela consiste à former une première équipe (de volontaires idéalement) et leur laisser 3 itérations environ pour s’approprier le processus et pratiques Agile. Puis à répartir les membres de cette équipe dans de nouvelles équipes. Ces dernières bénéficieront ainsi d’une personne sur laquelle s’appuyer en cas de difficulté. La diffusion du « courant » Agile se fait alors horizontalement pour une meilleure appropriation. Une personne sceptique aura plus facilement tendance à écouter un de ses pairs.

Backlog de Transformation

Scrum peut également s’avérer utile dans le cadre de la conduite du changement. Notamment à travers, la mise en place d’un Backlog contenant la liste des actions concrètes de transition vers l’approche Agile. Ce Backlog peut être construit et ordonnancé par l’équipe de coaching Agile et les représentants de chaque équipe. Vous pouvez ensuite, par exemple, planifier les actions au rythme des itérations et releases de votre projet.

Jeu de cartes

Exemple de Backlog de transformation Agile

Exemple de backlog de transformation Agile composé des cartes LeanPizza

Les auteurs du site LeanPizza ont mis à profit le travail de John Kotter pour faciliter le changement organisationnel vers l’Agile. La technique est simple et repose sur un jeu de cartes. Chaque carte est porteuse d’une action de « transformation » numérotée et appartenant à un thème. Par exemple, la carte n°46 du jeu de carte de transition vers Scrum est porteuse de l’action « Un meeting de Démo / Revue de Sprint est plannifié à la fin de chaque Sprint et ce dès le début du projet » et appartient à la catégorie « Démo / Revue de Sprint ». Ces cartes peuvent servir à la fois de check list et de mesure d’avancement de votre transformation. Elle peuvent alimenter votre « Backlog de Transformation ».

« Just Do It »

Trouver des raisons de ne pas adopter une nouveau changement, tel que l’adoption d’une nouvelle pratique par exemple, est plutôt facile. Si bien que, le porteur du changement doit souvent faire preuve d’une grande patience, écoute et diplomatie. Face à des personnes « sceptiques », plutôt que d’argumenter ardemment sur les bénéfices que peut apporter ce changement, proposez de simplement l’essayer. L’un des gros avantages des itérations est de pouvoir essayer un changement le temps d’une ou deux itérations et d’en faire le bilan. Libre aux acteurs du projet d’ancrer ce changement ou de revenir dessus. C’est le droit à l’essai et à l’erreur.

Communautés

La création de communautés transverses aux équipes et projets peut faire l’objet d’un bon support sur lequel s’appuyer pour diffuser et favoriser l’appropriation de nouvelles pratiques. On peut ainsi favoriser la création de communautés de pratiques (exemple : « Développement Agile ») ou de technologies (exemple : « Android » ou « Java »). Cette approche horizontale peut être complétée par un soutien venant du haut via l’allocation de budget d’animation de ces communautés (exemple : évènementiel, mise en place d’un logiciel de Réseau Social d’Entreprise ou d’un Wiki), de l’aménagement du temps de travail, etc.

Mode sous-marin

Jouer carte sur table en communiquant à l’ensemble des acteurs du projet ou de l’organisation une transformation vers l’Agile peut aussi bien faciliter les choses que les compliquer. D’un côté cette approche peut faciliter le changement car on pourra s’appuyer sur cette décision de passer en Agile pour surmonter les éventuelles résistances. D’un autre côté, on peut se retrouver face à une levée de boucliers visibles ou non qui rendront le changement difficile. Lorsque ce second scénario a plus de chance de se produire (selon le contexte), il peut être plus prudent d’avancer en sous marin en mettant en place progressivement les nouveaux principes et nouvelles pratiques.

Liens utiles

Livres

Retours d’expérience

Outillage

Jeu de carte Lean Pizza et manuel d’utilisation.

Processus d'élaboration de la stratégie de la tribu

Introduction au leadership tribal

Motiver une ou plusieurs équipes a toujours été un challenge pour un manager ou leader. Un challenge d’autant plus grand avec les nouvelles générations qui exigent – à juste titre – davantage du sens. Plus question d’exécuter une tâche – en particulier répétitive – sans savoir pourquoi. Plus question d’avoir le sentiment de n’être que l’engrenage d’une « machine », sans latitude pour exprimer sa créativité.

Dans cet article, nous ne traitons pas de management au sens strict (gérer un budget, un planning, un client, des « ressources humaines », etc) mais de leadership.

Le fruit d’une étude

Le Leadership Tribal nous vient d’une étude menée pendant plus de 10 ans sur plusieurs entreprises diverses. Entreprises américaines seulement mais nous allons voir que ce détail a peu d’importance car les principes qui en résultent sont universels. Cette étude ne s’intéresse pas à la dimension psychologique, sociologique (origine des personnes observées, culture, etc), ni même environnementale. Elle se focalise plutôt sur l’observation et l’analyse du langage, comportement et type de relation adopté. Elle part d’un principe simple : les mots qu’on utilise influencent notre comportement. Par exemple, face à une difficulté, se répéter à soi même « je ne vais pas y arriver » augmente nos chances de ne pas y arriver. Et c’est également valable à l’échelle d’un groupe de personnes (d’une tribu).

Qu’est ce qu’une tribu ?

Une tribu est un groupe de 20 à 150 personnes qui se connaissent suffisamment pour se saluer lorsqu’elles se croisent dans la rue. Une petite entreprise est une tribu, une grosse entreprise est une tribu de tribus.

5 stades, 5 discours

Cette étude a permis d’identifier 5 stades. A chaque stade est associée une façon de parler, un comportement et un type de relation.

Stade Discours Comportement Type de relation Population concernée
1 « La vie est nulle » Sabotage Exclu 2%
2 « Ma vie est nulle » Victime passive Isolée 25%
3 « Je suis génial (et pas toi) » Guerrier solitaire Domination personnelle 49%
4 « Nous sommes géniaux (et pas les autres) » Fierté tribale Partenariat stable 22%
5 « La vie est géniale » Émerveillement innocent Equipe Moins de 2%
Tableau de synthèse des 5 stades de tribu.

Leviers d’évolution

Ce paragraphe résume brièvement les principaux leviers permettant de passer d’un stade à un autre. Chaque stade s’appuyant sur les acquis du précédent, on ne peut « sauter » un stade. Pour vérifier si une personne ou tribu a atteint un nouveau stade, il suffit d’observer le langage, comportement et type de relation adoptés.

Stade 1 vers stade 2

Pour faire passer une personne du stade 1 (exclue et dont le discours est « la vie est nulle ») au stade suivant, on l’encourage à aller là ou l’action se déroule. Par exemple en déjeunant avec ses collègues, en participant aux réunions, etc. Par ailleurs, elle devra rompre ses liens avec les autres personnes du type « la vie est nulle ». On lui montrera également que la vie « fonctionne » pour d’autres et qu’elle aussi (la personne qu’on accompagne) peut donc avoir sa chance.

Stade 2 vers stade 3

Le discours des personnes de stade 2 tourne autour du thème « ma vie est nulle » et sont généralement isolées. Leur niveau d’implication est minimal et le signe d’un tel état d’esprit est souvent la présence d’affiches de « Dilbert » dans les locaux. Elles savent cependant que la vie peut réussir à d’autres.

Pour l’aider à évoluer vers le stade 3, on peut notamment :

  • L’encourager à créer des relations dyadiques (2 personnes), en particulier avec des personnes de « stade 3 avancé » qui ne demandent qu’à remplir un rôle de mentor et façonner des « mini-elle ».
  • Souligner ses compétences, ses forces et son potentiel à développer.
  • Lui proposer des projets qu’elle peut réussir à court terme et qui nécessitent peu de suivi ou surveillance.

Stade 3 vers stade 4

Une personne au stade 3 a pris confiance en ses capacités a travers plusieurs victoires et adopte un discours du type « je suis génial » avec pour sous-entendu « et pas toi ». Ses relations sont dyadiques afin de cloisonner. Il maîtrise ainsi la connaissance et les informations dont il dispose, qui constituent son « pouvoir ».

Pour l’aider à évoluer, on peut :

  • L’encourager à former des relations tryadiques (3 personnes) autour de valeurs fondamentales communes.
  • A travailler sur des projets dont le succès nécessite du partenariat et l’aider à prendre conscience à l’issue de ce projet que ce dernier n’aurait pas pu réussir sans l’aide des autres membres de l’équipe.
  • Lui montrer que le vrai pouvoir ne provient pas de la connaissance et la détention d’informations mais des réseaux.
  • L’encourager à user de transparence en communiquant à outrance plutôt qu’en communiquant uniquement les informations dont les autres ont besoin (stade 3).

L’épiphanie

La plupart des personnes interrogées dans le cadre de cette étude se positionnent généralement à 1 ou 2 stades au dessus de la réalité. La prise de conscience de l’existence de ces stades et de leur caractéristiques (langage, type de relation et comportement) aident à ouvrir peu à peu (ou brutalement) les yeux sur soi. L’aboutissement de cette phase d’introspection; cette « révélation » qui changera définitivement sa façon de parler, de se comporter et d’établir ses relations; est appelée « épiphanie ».

Stade 4 vers stade 5

Le stade 4 consiste à ne plus raisonner selon le « je » mais selon le « nous ». Le passage au stade 5 consiste à aller plus loin, à déplacer les montagnes, à « écrire l’histoire » en accomplissant des exploits qui n’avaient encore jamais été atteints au sein de l’entreprise ou au delà.

Processus d’élaboration de la stratégie de la tribu

Pour cela on met en place la « stratégie de la tribu » autour de valeurs fondamentales et une noble cause. Cette stratégie doit émerger de la tribu dans son ensemble et du contexte (économique, technologique, etc) plutôt que de la vision seule du leader. La définition de cette stratégie se fait en 4 temps :

  1. Identifier les valeurs fondamentales et la noble cause de la tribu qui fédérera les membres.
  2. Définir les résultats concrets visés (et non pas un objectif du genre « devenir numéro 1 mondial »).
  3. Faire l’inventaire des actifs de la tribu (atouts, compétences, ressources, etc) et vérifier que ces actifs permettent d’atteindre les résultats visés.
  4. Recenser les comportements à adopter pour atteindre les résultats visés et vérifier que les actifs permettent d’accomplir ces comportements.

Si les vérifications mentionnées révèlent des limites (pas assez d’actifs pour atteindre les résultats visés, ou comportements inappropriés), on révise les résultats ou définit des résultats intermédiaires et on ajuste les comportements.

Le leader devra toujours respecter les valeurs identifiées et la noble cause quitte à faire des renoncements (renoncer à un marché par exemple). Dans le cas contraire, la confiance est rompue, les valeurs et noble causes bafouées et plus rien n’a de sens. On régresse alors vers les stades inférieurs.

Changer d’huile régulièrement

Régulièrement, tous les 2 ou 3 mois par exemple, la tribu se réunit et prends le temps de faire le point. Elle fait l’inventaire de ce qui fonctionne et qu’il faut cultiver, de ce qui fonctionne moins bien et identifie les améliorations à apporter. Au besoin elle ajuste sa stratégie.

Notre société cultive le stade 3

Un livre de stade 3 parmi tant d’autres.

C’est triste à dire mais notre société – à travers notamment son système éducatif, le milieu du travail et les médias – cultive des personnalités de stade 3. Dès les bancs de l’école, les « bon points » nous poussent à l’individualisme et à la compétition, à conserver l’information qui permettra d’obtenir ce bon point (plutôt que de la partager pour aider les autres à progresser), à se comparer aux autres. La sonnerie nous dit quand nous devons changer de classe, faire une pause ou finir sa journée. De quoi nous préparer au monde du travail (surtout en usine). Les bons points cèdent ensuite la place aux notes, aux classements, etc. Puis la compétition au sein des grandes écoles prend le relais avec le bizutage illustrant l’état d’esprit suivant : « dans la vie, il faut en baver et c’est chacun pour soi. Ne fait confiance à personne. ».

Une fois dans le monde du travail, la culture « stade 3 » se poursuit avec à minima les évaluations et notes annuelles, les primes. Mais le pire concerne le secteur commercial au sein duquel la loi de la jungle atteint son paroxysme.

Le monde de l’édition quant à lui n’est pas en reste d’ouvrages de stade 3 prônant la compétition, l’individualisme et le dépassement des autres.

Aujourd’hui, des voix s’élèvent pour revoir notre système éducatif. Proposent un système au sein duquel les enfants ne sont pas infantilisés mais responsabilisés, écoutés et auto-disciplinés. Un système plus démocratique faisant participer les élèves aux décisions qui définissent le programme et la vie de l’établissement scolaire. La pédagogie est révisée pour enseigner selon des principes de coopération plutôt que de compétition. Un système dont le programme s’adapte aux passions de l’enfant sans juger que l’étude de l’anatomie d’une grenouille est plus importante que la construction d’un cerf volant. Un système au sein duquel l’enfant qui a compris un enseignement peut transmettre ce dernier avec ses propres mots aux autres élèves qui parlent le même langage (en complément de l’enseignant).

Bénéfices à partir du stade 4

Voici la liste des principaux bénéfices constatés sur les tribus de stade 4 :

  • Meilleure collaboration (autour de la noble cause).
  • Moins de peur et de stress grâce à l’absence de friction avec les autres (absence de compétition).
  • Basculement de la résistance au leadership vers son suivi par l’ensemble de la tribu.
  • Turn-over limité et conservation des talents.
  • Davantage d’engagement des membres de la tribu.
  • Formation sans effort grâce à l’enseignement apporté par la tribu à ses membres sur les dernières réflexions et pratiques.
  • Meilleurs indicateurs de santé : moins de blessure et d’arrêts maladie.
  • Meilleure compétitivité : créativité, connaissances, aspirations libérées.
  • Épanouissement des membres de la tribu (fun).

Conclusion

En guise de conclusion, voici un extrait du livre « Tribal Leadership » de Dave Logan, John King et Halee Fischer-Wright:

Alors que les leaders tribaux travaillent pour le bien du groupe, non pas pour eux même, ils sont récompensés par la loyauté, le travail acharné, l’innovation et la collaboration. La tribu produit un travail de la plus grande qualité en moins de temps. […] L’avenir de l’entreprise est le stade 5.

Pour aller plus loin

La vidéo de la session d’introduction au Tribal leadership tournée au Scrum Day 2013 (en français – 45′) :

Ci dessous, le support de présentation. Il est libre de droit, et peut par conséquent être utilisé, copié, projeté dans votre organisation sans compte à rendre à personne en dehors de me citer en tant qu’auteur.

Livraison Continue

Cet article décrit les principes et pratiques associés au Continous Delivery qui permettent d’appliquer concrètement le premier principe Agile : « Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée ». Pour éviter toute confusion, précisons qu’il ne traite pas du processus de réalisation (Scrum ou Kanban par exemple) mais du processus de « déploiement » convertissant le code source produit par une ou plusieurs équipes de développement en une application utilisable en production. L’essentiel des notions abordées sont issues du livre Continuous Delivery de Jez Humble et David Farley.

Enjeux

L’objectif premier est la satisfaction du client. Cette satisfaction s’obtient en offrant bien sûr un logiciel qui répond aux attentes des utilisateurs en termes de fonctionnalités, ergonomie, performance et robustesse. Mais elle s’obtient également en réduisant autant que possible le délais entre l’idée (ou la demande) et la mise à disposition de la nouvelle fonctionnalité (ou évolution ou correctif) associée.

En complément des processus de réalisation Agile (Scrum ou Kanban par exemple), les principes et pratiques abordés dans cet article rendent possible l’adoption d’un rythme de livraison aux utilisateurs en production fréquent et rapide. Un rythme hebdomadaire par exemple avec une durée de livraison de quelques seconde à moins de 2 heures y compris dans des contextes complexes. Comme le vivent déjà certaines entreprises.

Principes

Tout repose sur 2 principes fondamentaux :

  • Automatiser la livraison avec pour objectif la mise au point d’une procédure « pousse bouton » permettant de rendre le processus de déploiement fiable et répétable (sans risque d’erreur humaine).
  • Livrer fréquemment afin d’éprouver, fiabiliser la procédure, mais surtout nous donner un feedback au plus tôt afin de réduire autant que possible les coûts d’ajustement et par la même occasion la frustration (aussi bien celle des développeurs obligés de retravailler leur code alors qu’ils sont déjà passés à autre chose et les utilisateurs obligés de patienter trop longtemps).

Le pipeline de déploiement

Livraison Continue ou Continuous Delivery - Pipeline de déploiement de base

Pipeline de déploiement de base. Source : Livre « Continuous Delivery » de Jez Humble et David Farley.

Le circuit que parcourent les changements apportés au code à partir du commit du développeur jusqu’à sa livraison en production est appelé le « pipeline de déploiement ».

Le schéma ci contre illustre les principales étapes d’un pipeline de base (dont certaines sont parallélisables). On peut voir ce dernier comme une extension de l’Intégration Continue.

 

Pour l’anecdote, le choix du terme « Pipeline » n’est pas inspiré des canalisations de type oléoduc mais du fonctionnement des microprocesseurs.

Pratiques

Les pratiques suivantes permettent d’appliquer concrètement les principes évoqués plus haut.

Builder ses binaires une seule fois

Des changements ou erreurs humaines peuvent s’inviter entre différents build portant sur une même version du code source. Un changement de paramètre de compilation ou une erreur de tag par exemple. Changements qui peuvent rendre l’investigation difficile en cas de problème. C’est pourquoi, une fois que les binaires générés sont réputés fonctionner sur le premier environnement, ce sont eux qu’on utilisera sur les suivants. Par la même occasion, le délais de build est autant de temps de gagné pour les autres étapes du pipeline (ce qui est fait n’est plus à faire).

Même procédure pour chaque environnement

Afin d’utiliser et donc tester des centaines de fois la procédure de déploiement et ainsi la fiabiliser, nous avons intérêt à faire en sorte que ce soit la même pour l’ensemble des environnements. Ce qui va nous obliger – pour notre plus grand bien – à externaliser toutes les variables d’environnement. Ces dernières trouveront généralement leur place dans un fichier de configuration type « properties » qui lui même trouvera sa place dans le gestionnaire de version (ce qui permettra de faciliter les investigations en cas de problème).

Tests de fumée sur les déploiements

Livrer en production ou autre environnement à enjeu n’est pas suffisant. Nous devons aussi vérifier que le tout fonctionne. Les tests de fumée remplissent ce rôle. Connexion à la page d’accueil de l’application web, vérification de la disponibilité de la base de données, ping du web-service d’une application tierce, etc.

Déployer sur une copie de la production

L’un des pièges courant concernant les problèmes de mise en production est celui issu des différences entre les environnements du projet. Différence de compilateur, de version d’OS (voire pire d’OS tout court), de stack, de patchs de l’OS, de système de répartition de charge, de configuration réseau (ex : emplacement par rapport au proxy), etc.

Nous avons tout intérêt à uniformiser tous les environnements et suivre avec rigueur le moindre changement apporté. Le recours à des serveurs virtuels peut faciliter les choses et accélérer au passage le délais de mise en disposition des environnements.

Chaque changement se propage sur tout le pipeline

Livraison Continue ou Continuous Delivery - Mouvement des changements

Mouvement des changements au sein du pipeline de déploiement. Source : livre « Continuous Delivery » de Jez Humble et David Farley

Chaque commit est candidat à traverser les étapes du pipeline. Le diagramme ci contre décrit le mouvement d’un changement de code à travers le pipeline de déploiement.

Il ne décrit cependant pas le cas de figure assez fréquent selon lequel de nombreux commits successifs sont réalisés avant que l’Intégration Continue ai eu le temps de vérifier le premier. Dans ce cas, une fois qu’elle a terminé, elle prendra la dernière version du code et recommencera. Ce qui peut rendre l’analyse difficile en cas d’échec de l’intégration continue (lequel des commits est coupable ?). Dans ce cas, on pourra demander manuellement à l’outil d’Intégration Continue de tester chaque commit un à un jusqu’à rencontrer l’échec et donc identifier le commit fautif.

En cas d’échec sur une section du pipeline, on s’arrête

Nous l’avons vu, l’un des principes fondamentaux est d’obtenir un feedback au plus tôt afin de limiter les coûts et le stress associés à un défaut. Coût et stress qui ne font que grossir avec le temps. Dès qu’un voyant s’allume, nous avons donc tout intérêt à réagir au plus vite. Il ne s’agit pas forcément de mobiliser toute l’équipe mais à minima une personne doit arrêter ce qu’elle est en train de faire pour retirer le « grain de sable » de l’engrenage. Nous devons par exemple être vigilant le soir lors du dernier commit de la journée en vérifiant que ce dernier a bien passé toute la chaîne automatisée du pipeline avant de partir.

Etape de commit

La première étape du pipeline, celle du commit, est peut être celle qui comporte le plus d’enjeux. L’objectif de cette étape est d’éliminer les build impropres à une livraison en production et de nous avertir au plus tôt en cas de build cassé.

C’est pour cette raison qu’elle couvre généralement les vérifications suivantes :

  • Compilation du code
  • Tests de commit (sous ensemble de tests unitaires automatisés réputés rapides à exécuter et permettant de détecter un maximum de régressions. Ce sous ensemble s’affine au fil de l’eau.)
  • Création des binaires (qui seront utilisés plus tard)
  • Analyse du code (taux de couverture de test, taux de code dupliqué, complexité cyclomatique, nombre de warnings, formatage du code, etc)
  • Préparation des artéfacts (bases de données de test par exemple)
Toutes ces vérifications sont généralement automatisables par les outils d’Intégration Continue.
A chaque modification du code, une nouvelle instance du pipeline est créée. Le paragraphe Outils comporte la capture d’écran d’un outil de Continuous Delivery qui illustre bien ce principe (chaque ligne correspond à une instance du pipeline et donc à un build distinct).

Etape de tests d’acceptation

Cette étape a également une grande importance. Plutôt que de vérifier très localement le bon fonctionnement du code (rôles des tests unitaires automatisés), elle contrôle la bonne couverture du besoin et la non régression fonctionnelle. Elle repose généralement sur des « spécifications par l’exemple » et outils associés (Cucumber, Fitnesse ou Concordium par exemple). Ces tests sont sous la responsabilité collective du métier, des analystes, testeurs et développeurs.

Recourir aux branches avec modération

L’idéal est d’avoir un code constamment livrable malgré les changements constants apportées par l’équipe de développement. Le recours aux branches est tentant. Cependant, il implique une charge de travail importante et des risques élevés même avec les meilleurs outils du monde. L’effort de fusion (merge) et la gestion des conflits (sans avoir forcément les développeurs concernés sous la main) ainsi que la déconnexion à l’Intégration Continue sont de bons exemples de charge de travail et de risques occasionnés par les branches. Plus la durée de vie des branches est longue plus ces contraintes grossissent.

Voici quelques pratiques permettant d’éviter autant que possible le recours aux branches :

  • Nouvelle fonctionnalité : Que faire pour réaliser une nouvelle fonctionnalité ou un nouvel ensemble de fonctionnalités dont le développement peut durer plus d’une semaine alors que notre rythme de livraison en production est hebdomadère ? En commitant sur le trunk les modifications de code (sans branche donc) tout en rendant la nouvelle fonctionnalité invisible pour l’utilisateur tant qu’elle n’est pas terminée (avec une URI dédiée par exemple dans le cas d’un site web).
  • Gros Refactoring : En cas de gros refactoring, découper dans la mesure du possible le travail en petits incréments et faire le refactoring pas à pas sur le trunk en s’appuyant sur la ceintures de tests automatisés. Le découpage demande un peu de créativité mais c’est plus sûr. Cela permet également de pouvoir s’arrêter en cours de route au besoin. Ce qui est très risqué/stressant en cas d’utilisation d’une branche car on vit alors avec la peur d’avoir un trunk qui évolue trop vite et qui rendra le merge douloureux et risqué.
  • Refactoring à grande échelle : Mettre en place une couche d’abstraction au dessus de la zone à refactorer puis réaliser une nouvelle implémentation sous cette couche à côté de l’implémentation existante.

Il est recommandé d’utiliser les branches uniquement dans le cas où ces dernières n’auront pas à être fusionnées. Les branches de release ou de spike (dont le code est jetable) par exemple. Lorsque la fréquence des livraisons en production est élevée (par exemple de l’ordre de la semaine), les branches de release deviennent inutiles. C’est souvent moins coûteux et plus simple d’attendre la prochaine version plutôt qu’avoir recours à un patch et sa branche.

Petit bémol tout de même : Les gestionnaires de version distribués comme GIT changent la donne car ils occasionnent un changement de paradigme. Ce dernier réconcilie peut être le recours aux branches et le Continuous Delivery.

Outils

Exemple d'outil de livraison continue ou continuous delivery

Outil permettant de suivre et gérer les différentes instances du pipeline de déploiement.

Le Continuous Delivery est une démarche très transverses qui touche – directement ou indirectement – à la fois le processus de réalisation, la gestion des tests, les pratiques de développement et la gestion des environnements. Il n’est donc pas surprenant de trouver une grande quantité d’outils en tout genre gratuits ou payants pour atteindre les objectifs visés.

Voici un bref article qui répertorie de tels outils.

Bénéfices

  • Feedback rapide : Plus un défaut est corrigé tard, plus il coûte cher (investiguer, reproduire le défaut, revenir sur du code qui n’est pas forcément le sien, qualifier/estimer/arbitrer/planifier/livrer/tester la correction, etc). Le pipeline de Continuous Delivery offre un feedback rapide et évite ainsi des gaspillages parfois considérables. Un feedback quasi immédiat au niveau de l’Intégration Continue et à la semaine au niveau de l’utilisateur final.
  • Meilleure qualité : Il n’est pas surprenant d’apprendre que les équipes ayant mis en place l’intégralité d’un pipeline de Continuous Delivery en plus de piloter les développements par les tests parviennent aux termes de 6 mois de développement avec une quantité d’anomalies se comptant sur les doigts d’une main. A tel point qu’un outil de suivi d’anomalie ou même un indicateur de volume d’anomalies deviennent tout bonnement inutiles. Le Graal de toute équipe de développement en somme.
  • Moins de stress : Le stress porte principalement sur 2 aspects. Les jalons à tenir qui maintiennent un niveau de stress dans la durée et croissant. Et la livraison qui repose sur une procédure généralement très manuelle et porteuse de nombreux changements (le fruits de plusieurs semaines ou mois de travail). En cas de livraison hebdomadaire avec des procédures automatisées, ces facteurs de stress sont considérablement réduits.
  • Bouton « Retour en arrière » : L’automatisation complète de la livraison à partir d’un binaire déjà construit (identique pour chaque environnement) rend la procédure de livraison rapide quelque soit la version visée. En cas de problème avec la livraison de la dernière version, on pourra revenir en arrière facilement grâce à cette même procédure qui aura alors pour cible les binaires de la version précédente.
  • Week-end pour soi : L’automatisation complète et la fiabilisation de la procédure de livraison rendent cette dernière rapide et presque anecdotique. Si rapide qu’il devient inutile de mobiliser une équipe entière tout un samedi pour assurer la livraison avant que les utilisateurs reprennent le travail.
  • Meilleure relation client – fournisseur : Nous l’avons évoqué en introduction l’objectif premier est la satisfaction du client (et des utilisateurs). Une fois atteint, le principal bénéfice qui en découle est l’acquisition d’une relation de confiance voire de « réel plaisir à travailler ensemble » entre l’équipe de développement, le client et les utilisateurs.
  • Possibilité d’audit de la livraison : Comment auditer une procédure de livraison manuelle qui s’est mal déroulée ? On ne peut pas se reposer sur la procédure papier car elle ne nous dit pas où une erreur humaine à pu se glisser. En revanche une procédure automatique est auditable.

Oui mais…

Beaucoup d’entre nous connaissent sans doute un contexte bien cloisonné au sein duquel l’équipe de développement jette son build ainsi que la procédure d’installation associée par dessus le mur qui la sépare des exploitants (ceux qui mettent l’application en production). Avec toutes le contraintes que ça implique. Que faire dans pareille situation ? Faut il attendre le changement culturel tant attendu qui cessera d’isoler les compétences ? Le risque est d’attendre longtemps – surtout dans une grosse entreprise – même si les courants DevOps prendront sans doute de plus en plus d’ampleur (après tout c’est du bon sens, une fois de plus).

Au lieu d’attendre, c’est sans doute à l’équipe de développement de faire le premier pas. En fournissant avec ses binaires une procédure de livraison ad hoc automatisée type « pousse bouton ». En échange de cette promesse de « don » aux exploitants (heureux de ne pas avoir une centaine de gestes à exécuter avec le risque de se tromper), l’équipe de développement peut légitimement demander un environnement iso-prod (non pas en termes de puissance mais d’architecture technique avec les même version d’OS, même systèmes de répartition de charge, etc) à sa main. C’est cet environnement qui leur permettra de réaliser, utiliser et fiabiliser cette procédure « pousse bouton ». Si le budget d’automatisation est limité, elle automatisera petit bout par petit bout, réduisant toujours un peu plus le délais de livraison et les risques d’erreur.

Pour aller plus loin