Category Archives for "Fiche Pratique"

La théorie des contraintes : augmenter son rendement, diminuer son lead-time

Une belle théorie enveloppée dans un roman sympathique

Une lecture aussi enrichissante que distrayante

Réduire radicalement ses encours de développement et augmenter sa productivité pour un investissement minimum : telle est la promesse de la théorie des contraintes. Si l’on ajoute que cette méthode est simple et particulièrement compatible avec une approche agile dans une équipe logiciel, cela fait suffisamment de raisons pour la regarder d’un peu plus près.

La théorie des contraintes (ou ToC pour les habitués) ne date pas d’hier. A la manière du Lean, elle est née dans l’industrie il y a plus de 30 ans et n’a été importée dans le monde du développement que récemment, notamment à l’initiative de partisans de l’Agile. La bible des aficionados de la ToC s’appelle « le But », un roman d’entreprise remarquablement construit qui explique avec une clarté peu commune ses principes et sa mise en oeuvre. Son auteur, Eliahu Goldratt, a ensuite perfectionné son modèle et étendu cette approche au monde des services dans une douzaine d’ouvrages.

Continuer à lire

1

Gestion de Projet Simple (GPS)

Introduction

Cet article vise à décrire un cadre méthodologique de gestion de projet simple. Il s’adresse à toute association de personnes (équipe) désireuses de mener un projet quel qu’il soit aboutissant à ce qu’on appellera par abus de langage un “Produit”. Les membres de l’équipe peuvent travailler à temps plein ou partiel, partager un même lieu de travail ou non et participer à l’ensemble des étapes du projet avec ou sans hiérarchie.

Étapes du projet

Définir la vision du “Produit”

Le projet débute par la formalisation de la vision du “produit fini” faisant l’objet du projet. Elle a pour principal objectif de mettre l’ensemble des acteurs sur la même longueur d’onde et de les guider dans les choix et les décisions qu’ils seront amenés à prendre tout au long du projet. Le travail sur la vision consiste principalement à répondre aux questions « Pourquoi réalise t’on ce produit ? », « A quel public s’adresse t’il ? », etc.

Construire et ordonnancer le “Product Backlog”

Une fois que la vision est partagée et claire pour tout le monde, il est temps de faire la liste de toutes les tâches – connues à date – nécessaires à la réalisation du “Produit”. Cette liste appelée “Product Backlog” peut être modifiée/complétée tout au long du projet.

Les éléments du Product Backlog sont ordonnancés de manière à mettre en haut de la liste – dans la mesure du possible (cf. dépendance entre les tâches) – les tâches bénéficiant du meilleur rapport « Valeur ajoutée au produit” / « Coût de mise en oeuvre ».

Diviser le temps

Afin de planifier le projet, la durée totale estimée du projet est divisée en blocs de temps successifs d’une durée fixe et courte appelés “Sprints” (en général 2 à 4 semaines).

Planifier le sprint

Les tâches prioritaires du Product Backlog (en haut de la liste) sont sélectionnées par l’équipe pour alimenter la liste des tâches du Sprint sur le point de commencer. Elle réalise cette sélection en fonction de sa capacité à les réaliser dans le délais du sprint (dès que l’équipe estime que ça ne rentre plus, elle arrête sa sélection).

Exécuter le sprint

Durant le sprint, chaque membre de l’équipe prêt à commencer une tâche, s’affecte cette dernière et la passe au statut “En cours”. Une fois terminée, il la passe au statut “Terminé”. Il peut alors s’affecter une nouvelle tâche de son choix au statut “A faire” jusqu’à épuisement des tâches du Sprint. Voir paragraphe : “Outil associé” pour plus d’explications et d’illustrations.

Revue de sprint et nouveau sprint

A la fin de chaque Sprint et quelque soit son avancement, l’équipe fait le bilan des travaux réalisés au cours de ce dernier et définit un plan d’action susceptible de rendre le prochain Sprint plus efficace, agréable, qualitatif et productif. De cette façon, le processus de réalisation du produit est sans cesse amélioré. La Planification du Sprint suivant s’enchaîne et ainsi de suite jusqu’au dernier Sprint aboutissant au “produit final” ou à sa nouvelle version.

Schéma du processus de gestion de projet simple

Schéma du processus de gestion de projet simple

Outil associé

Le principal outil associé est un “Tableau des tâches” virtuel composé à minima de 3 colonnes liées aux 3 statuts de base d’une tâche :

  • A Faire : La tâche n’est pas commencée et non affectée à un membre de l’équipe
  • En cours : Un membre de l’équipe s’est affecté la tâche et l’a commencé
  • Terminé : La tâche est terminée

Les tâches sont déplacées d’une colonne à une autre en fonction de leur avancement. Ce tableau permet à toute l’équipe de connaître en temps réel l’état des lieux du sprint en terme d’avancement.

Outil Trello

Tableau des tâches sur Trello dans le navigateur web

L’outil Trello a le mérite d’être simple, gratuit, web et utilisable sur un mobile sans rien installer. Son seul inconvénient est qu’il est en anglais mais le titre des colonnes reste personnalisable.

Reste à prévoir un outil pour gérer le Product Backlog. Un simple tableau Google Sheets peut faire l’affaire.

L’outil iceScrum est une autre alternative simple, complète, en français, gratuite et plutôt fun. Elle nécessite en revanche une installation sur un serveur.

Pour une équipe partageant un même espace de travail, un tableau des tâches physique mural avec un post-it par tâche peut être plus simple et efficace (l’informatique n’est pas toujours LA solution). Idem pour le Product Backlog qu’on rendra ainsi plus visuel, transparent et plus facile à ordonnancer (simples déplacements de postit).

Informations complémentaires

Ce n’est qu’un cadre méthodologique

Ce cadre méthodologique ne fait que définir les règles du jeu de base et n’a pas pour vocation de dicter à l’équipe la façon de réaliser les tâches et de s’organiser (ce qui est souvent spécifique au contexte de chaque projet). Il définit simplement un processus itératif offrant régulièrement à l’équipe l’occasion d’améliorer son organisation et de trouver elle même les solutions à ses éventuels obstacles (lors de la revue de sprint). Le projet peut ainsi démarrer très vite avec une organisation légère qui s’affinera au fil des sprints.

Tailles d’équipe

Ce cadre méthodologique s’adresse à des équipes de 2 à 9 personnes. Au delà, la coordination est plus compliquée, il est donc recommandé de former plusieurs équipes de 5 à 9 personnes. Chaque équipe disposant de son tableau des tâches de sprint alimentées à partir d’un Product Backlog commun à toutes les équipes du projet ou plusieurs. Par ailleurs, une synchronisation des sprints (commencent et se terminent en même temps quelque soit l’avancement) de chaque équipe offre pas mal d’avantages en terme de planification et d’intégration du travail de chaque équipe.

Origine et aide à la mise en oeuvre

Ce cadre méthodologique s’inspire ouvertement du cadre méthodologique préexistant Scrum créé pour le développement logiciel. Voir mini guide Scrum. Le livre électronique “Scrum & XP depuis les tranchées” (gratuit) – bien que venant du monde du développement logiciel – peut apporter des conseils précieux dans la mise en oeuvre de la présente méthodologie. Si vous souhaitez aller plus loin dans l’adoption de Scrum, j’ai pris soin de conserver le vocabulaire. Ainsi vous ne serez pas perdu en approfondissant le sujet. Pour vous accompagner dans cette démarche, je vous invite à lire le guide de démarrage Scrum.

Glossaire

  • Product Backlog : liste des tâches à réaliser pour aboutir au “Produit” ou au moins une première version de ce dernier.
  • Tâches du Sprint : liste des tâches à réaliser sur la durée du Sprint uniquement. Cette liste est donc un sous ensemble du Product Backlog.
  • Planification de Sprint : étape consistant à sélectionner des tâches prioritaires du Product Backlog à réaliser au cours du Sprint sur le point de commencer.
  • Produit : résultat auquel le projet aboutit (objet, film, logiciel, bâtiment,…)
  • Revue de Sprint : étape marquant la fin d’un sprint au cours de laquelle l’équipe inspecte son avancement, l’état du “Produit” et réfléchit aux moyens de s’améliorer.
  • Sprint : bloc de temps d’une durée fixe et courte (2 à 4 semaines) durant laquelle l’équipe réalise un sous ensemble des tâches à réaliser pour aboutir au “Produit” visé.
  • Vision : description du “Produit” final tel qu’imaginé par l’équipe pour guider cette dernière dans ses choix.

Devenir une Dream Team – Partie 2

Lors de l’épisode précédant, nous avons vu les différents principes qui entourent la culture d’une organisation ou tribu et en quoi la faire émerger peut libérer une énergie précieuse pour faire de cette dernière une Dream Team. Une tribu qui obtient des résultats encore jamais atteints grâce à davantage de sens et de motivation. Sens et motivation principalement alimentés par les valeurs fondamentales et la noble cause ou mission de cette tribu. Dans cette seconde partie, nous allons voir ensemble quelles sont les différentes techniques qui s’offrent à nous pour identifier ces valeurs.

La bonne nouvelle pour les organisations agiles

Le travail sur les valeurs fondamentales et la mission de la tribu nécessite un état d’esprit collaboratif dans lequel le « nous » domine dans le langage utilisé plutôt que le « je ». C’est ce qui correspond au stade 4 du tribal leadership. Si la tribu n’en est pas à ce stade, il sera sans doute préférable de commencer par utiliser les leviers permettant d’y parvenir (voir article « introduction au leadership tribal »). La bonne nouvelle, c’est que si les membres de votre tribu ont déjà adopté l’état d’esprit agile et Scrum en particulier, le stade 4 est potentiellement déjà acquis. Difficile en effet de faire de l’agilité sans esprit d’équipe.

Techniques d’émergence des valeurs

Il existe plusieurs techniques permettant de faire émerger ses propres valeurs fondamentales, celles d’une autre personne ou encore celles d’un groupe. Nous allons explorer ces différentes techniques selon ces trois cas de figure.

Rechercher ses propres valeurs

Voici deux techniques vous permettant d’identifier vos propres valeurs. Sachez que vos valeurs peuvent être différentes de celles de votre entreprise, cependant elles doivent être alignées avec ces dernières.

Technique des plaisirs et colères

Posez vous dans un endroit calme, prenez quelques respirations profondes et posez vous la question « qu’est ce qui me plait dans mon travail ? ». Si votre réponse manque de profondeur (au sens où elle ne révèle pas de valeur), répondez à votre réponse par la question : « Pourquoi ? » et recommencez autant de fois que nécessaire. Voici un exemple de dialogue intérieur : « Qu’est ce qui me plait dans mon travail ? Les challenges qu’il m’apporte. Pourquoi ? Parce que j’aime apprendre continuellement. ». Dans cet exemple, la valeur identifiée est de l’ordre du développement personnel.

Inversement, vous pouvez faire une recherche en utilisant le levier de la colère avec une question du type : « Quelle situation me met en colère ou me frustre dans mon travail ? ». Après votre réponse, posez vous la question « Quel besoin fondamental n’a pas été couvert dans cette situation ? ». Il y a des chances pour que votre réponse vous mette sur la voie d’une valeur.

Technique des montagnes et vallées

Tony Hsieh Mountains and Valleys

Montagnes et vallées de Tony Hsieh (créateur de Zappos). Chaque numéro rouge fait référence à une valeur (voir légende).

La technique des montagnes et vallées consiste à se remémorer les fait marquants positifs et négatifs vécus sur la période explorée et en déduire les valeurs associées.

Prenez une feuille de papier A4 en mode paysage et tracez un axe de temps horizontal qui coupe la page en deux par le milieu. Réfléchissez maintenant aux évènements marquants de votre vie personnelle et professionnelle. Positionnez les évènements positifs au dessus de l’axe de temps et les négatifs en dessous. Plus un évènement sera positif, plus il sera haut et plus un évènement sera négatif, plus il sera bas. Poursuivez ensuite votre introspection pour identifier la ou les valeurs associées à chaque évènement. Dans le cas d’un évènement négatif, il s’agit de la valeur associée à un besoin non respecté.

Liste des valeurs associées à l’illustration ci-dessus à titre d’exemple :

  1. Participer avec créativité à quelque chose qui nécessite non seulement vous mais également d’autres personnes pour réussir; le groupe est toujours meilleur que la somme de chacun des membres.
  2. Seek out tribal (level) connectedness; this is where the spiritual resides (non traduit pour éviter de perdre le sens de la phrase).
  3. Vivre avec passion.
  4. Avoir une vision.
  5. C’est seulement quand vous êtes complètement libre que vous êtes le meilleur de vous même.
  6. Combattre l’inertie – Chercher du sens dans chaque activité.
  7. Rencontrer et traiter les personnes avec la philosophie PLUR.
  8. L’expérience compte davantage que les biens matériels.

Voici le guide d’utilisation de la technique des montagnes et vallées (en anglais).

Retenez les valeurs fondamentales et donnez leur du sens

Réduisez ensuite le nombre de valeurs à une quantité de 3 à 5. Retenez celles qui comptent le plus pour vous. Et si ce n’est pas déjà fait, formulez une phrase qui clarifie cette valeur. Un mot seul ne suffit pas. La valeur Honnêteté par exemple peut être interprétée de plusieurs façons. Est ce qu’on entend par là l’idée de dénoncer toutes attitudes malhonnêtes ou de faire preuve de franchise. La phrase suivante donne davantage de sens : « Dire les choses telles qu’elles sont. Même quant elles vont mal et même si la personne a qui on s’adresse est un responsable ou client ».

Commencez par un verbe qui associe cette valeur à l’action.

Rechercher les valeurs d’une autre personne

Vous pouvez également être amené à vouloir identifier les valeurs d’une autre personne que vous. C’est d’ailleurs l’occasion d’établir une relation plus profonde avec cette personne. Voici une technique utile dans ce cas de figure. Etant donné qu’elle se base sur une conversation, à vous de la rendre la plus naturelle possible. Il ne s’agit pas d’un entretien formel.

Technique du click

La technique du click consiste à provoquer une conversation avec la personne de votre choix et elle seule afin d’identifier ses valeurs fondamentales. Inutile de préciser que l’écoute est primordiale. A vous de vous taire, à part bien sûr pour poser des questions ;-). Vos questions doivent être ouvertes. Vous pouvez par exemple entrer en matière avec « Peux tu me citer une chose que tu apprécies particulièrement dans ton travail ? ». Vous devez analyser la réponse et identifier un mot clef sur lequel vous allez « clicker » comme si c’était un lien hypertexte. Exemple de réponse « Les challenges que je dois relever ». Clickons sur le mot « challenge » : « Pourquoi les challenges sont importants pour toi ? »… Une fois que vous arrivez à une situation de rire nerveux, de silence prolongé ou de réponse du genre « Parce que c’est comme ça ». C’est que vous avez sans doute identifié la valeur associée.

Rechercher les valeurs d’un groupe

Il est également possible d’établir les valeurs fondamentales d’un groupe. L’expérience peut même être très rapide. Il faudra cependant laisser décanter le fruit de cette expérience quelques jours, voire davantage. Afin de s’assurer de ne pas être passé à côté d’autres valeurs et d’être certains que c’est sur ces valeurs que le groupe reposera à long terme. Ces valeurs serviront notamment à prendre des décisions conditionnant l’avenir du groupe.

Exemple d'utilisation de la technique des montagnes et vallées sur un groupe (en anglais)

Exemple d’utilisation de la technique des montagnes et vallées sur un groupe (en anglais)

La technique des montagnes et vallées peut servir dans ce cas de figure. Moyennant quelques adaptations puisque le travail d’introspection va impliquer le groupe dans son ensemble. Précisons également que le groupe impliqué dans cette expérience doit être de stade 4 (selon les stades du tribal leadership). Si ce n’est pas le cas, l’expérience risque de ne pas être suffisamment collaborative et fructueuse. Une fois votre groupe réuni (sur invitation et non pas sur ordre), utilisez un tableau blanc (ou tout support équivalent), tracez l’axe de temps représentant la période la plus appropriée (de la naissance du groupe ou de l’organisation à aujourd’hui par exemple) et demandez à chacun de faire appel à sa mémoire pour retrouver les évènements professionnels marquants vécus par chacun. Chacun peut noter les évènements en question sur des post-it (un par post-it) et les positionner sur le tableau blanc. Il peut y avoir des doublons d’une personne à une autre et un même évènement peut être vécu positivement par une personne (positionnement au dessus de l’axe du temps pour rappel) ou négativement par une autre (positionnement au dessous de l’axe de temps). Chacun peut s’exprimer sur sa perception de l’évènement soulevé. Cette technique est souvent utilisée en rétrospective sur une période généralement plus courte. Une fois cette première phase exécutée, vous pouvez inviter tout le monde à prendre une pause de quelques minutes. Après la pause, il s’agit d’identifier – selon les même leviers cités précédemment – les valeurs associées aux évènements recensés lors de la première phase.

Voir l’exemple ci contre.

Démarches possibles

Voyons maintenant comment mettre en musique ces techniques. Une approche consiste à partir du leader tribal. Supposons que ce soit vous. Vous allez commencer par déterminer vos propres valeurs fondamentales avec la ou les techniques appropriées déjà décrites. Une fois au clair avec vous même, vous allez vous rapprochez des personnes de votre réseau qui devraient selon vous partager vos valeurs. Pour vous en assurer, vous allez sans doute provoquer des conversations avec ces personnes en utilisant la technique du click. Vous allez peut être découvrir d’autres valeurs qui viendront compléter votre liste. Affinez cette dernière en limitant le nombre de valeurs, de façon à retenir uniquement les valeurs fondamentales, formulez des phrases complètes commençant par un verbe afin de clarifier le sens des valeurs (voir exemples et explications détaillées plus haut). Partagez cette liste avec les membres de votre tribu, demandez des feedbacks. Invitez les à participer à un atelier de discussion sur le sujet au besoin.

Une fois que ça vous semble mûr, il est temps de prendre l’engagement formel de respecter ces valeurs quoi qu’il arrive et d’aller de l’avant tous ensemble. Il ne s’agit pas d’un engagement à la légère. En tant que leader, si vous rompez par la suite cet engagement, c’est toute cette énergie tribale que vous aurez libéré que vous risquez de perdre quasi instantanément.

Une démarche plus directe peut consister à utiliser la technique des montagnes et vallées en groupe ou d’utiliser une rétrospective ayant pour objectif la définition des valeurs fondamentales du groupe. Cette rétrospective pourrait comporter une phase de recueil des valeurs de chacun  suivie d’une phase de pondération permettant de retenir les valeurs fondamentales communes.

Dernier conseil avant de se quitter. Déterminer une valeur fondamentale maîtresse peut contribuer à la cohérence des valeurs fondamentales retenues ou à retenir. De nos jours, un bon exemple de valeur fondamentale maîtresse pourrait être « Etre une organisation apprenante ».

Valeurs fondamentales de l’Agiliste

Au passage, voici les valeurs fondamentales de l’Agiliste :

[list icon= »star »] [list_item]Partage des connaissances : Partager les connaissances acquises pour que d’autres personnes en bénéficient et que l’usage des pratiques sous-jacentes se diffusent le plus largement possible afin d’améliorer la vie au travail et les résultats.[/list_item] [list_item]Open Source : Ouvrir les contenus éditoriaux de l’Agiliste grâce à une licence Creative Commons. Ce qui signifie que chacun est libre de les utiliser, modifier et communiquer à la seule condition de citer l’auteur avec le lien de la page de l’auteur. Le présent site internet repose lui même sur le CMS Open Source WordPress.[/list_item] [list_item]Transparence : Faire preuve de transparence. Les statistiques de fréquentation du site sont rendues publiques et peuvent être consultées sur la page dédiée. Le nombre d’abonnés à la newsletter est également visible dans le formulaire d’inscription.[/list_item] [list_item]Pas de bannières de publicité : Offrir un certain confort d’utilisation de ce site en renonçant notamment aux bannières de publicité.[/list_item] [list_item]Honnêteté : Communiquer de façon franche, honnête et sans dogmatisme. Ne se soumettre à aucune autorité ou influence de la part de qui que ce soit (éditeur, société de conseil/services, gourou ou autre).
[/list_item] [/list]

Ces valeurs servent la mission suivante : « Contribuer à augmenter le plaisir au travail et les résultats ».

Source : page « A propos ».

Vous allez peut être me trouver terriblement curieux et indiscret mais…

Et vous, quelles sont vos valeurs fondamentales ?

5

Devenir une Dream Team – Partie 1

Dans l’introduction au leadership tribal, nous avons vu les 5 niveaux d’évolution d’une tribu. Le niveau 5 permettant « d’écrire l’histoire » en obtenant des résultats encore jamais atteints. Les membres d’une telle Dream Team n’ont pas besoin d’un leader pour les motiver, leur dire quoi faire, comment le faire et se donner à fond. Ils se sentent partie prenante de l’organisation et puisent leur énergie dans la « noble cause » ou « mission » et les valeurs fondamentales qu’ils ont contribué à établir et contribuent à faire évoluer.

Leur environnement de travail est d’une si grande qualité que le turn-over est minime et que la qualité du travail est optimale. Ils travaillent dur et « jouent dur ». Le principe est simple, si on prend soin du personnel, le personnel prend mieux soin des clients de l’organisation. Comme dans la vie, si je prends soin de moi, je m’occupe mieux de mes proches. Pensez aux consignes de sécurité en avion : « Mettez d’abord votre propre masque à oxygène avant de vous occuper des autres, sinon vous risquez de ne pas être d’un grand secours ».

Très bien, mais comment parvenir à une telle culture ? Comment devenir une Dream Team ? C’est justement l’objet de cette série d’articles. Largement inspirée d’une digestion lente des livres « The Culture Blueprint » de Robert Richman, de « Tribal Leadership » de Dave Logan et d’expériences personnelles vécues auprès d’équipes de développement logiciel.

Les leviers du tribal leadership

Si vos souvenirs sont lointains ou si vous n’avez pas encore lu mon article d’introduction au leadership tribal, je vous invite à le faire maintenant. Vous y trouverez les leviers associés au passage d’un niveau à un autre. Et rappelez vous bien, il s’agit d’accompagner chaque personne individuellement en adoptant un langage qu’elle peut comprendre (de son niveau ou supérieur) et de ne pas sauter un niveau car chaque niveau s’appuie sur les acquis du précédant.  Vous y trouverez aussi la « stratégie » mettant en musique les valeurs fondamentales de la tribu, sa noble cause, les résultats qu’elle vise ainsi que ses actifs et actions.

La suite de cette fiche décrit une approche sensiblement différente et complémentaire au tribal leadership pour comprendre les principes liés à la culture poser les bases. Elle est davantage orientée sur le « comment faire ». On la doit à Robert Richman ayant travaillé sur la culture de Zappos. Pour l’anecdote, Robert Richman a également fait parti de l’équipe à l’origine du Tribal Leadership. C’est aussi ce qui explique la complémentarité.

Par où commencer ou par qui ?

Vous vous dite peut être qu’un tel changement ne peut venir que d’un responsable que vous devrez convaincre. De celui de votre équipe, de votre département, de votre entreprise ou de votre organisation. En réalité, il y a de fortes chances pour que la meilleure personne pour entreprendre cette expérience, ce soit vous. Ce n’est sans doute pas par hasard si vous êtes en train de lire cet article, si son titre vous a attiré dans les résultats d’un moteur de recherche ou qu’une personne vous en ai parlé. Toutefois, vous aurez peut être à convaincre un responsable ou sponsor afin d’avoir le champ libre pour agir. Vous aurez peut être aussi besoin d’un mentor pour vous aider à prendre du recul et vous ressourcer.

Peut être que vous vous dites aussi que vous n’êtes pas un leader. Que vous n’avez pas le charisme nécessaire, etc. Détrompez vous, un leader est simplement une personne qui rassemble d’autres personnes et des ressources autour d’un objectif motivant. Trouvez ces personnes, parlez leur de votre projet (en triade idéalement) et prenez la température. Il ne s’agit pas d’un projet planifié dans le temps, ni d’une stratégie, mais d’une expérience. Et pour le charisme, dites vous bien que ça ne vient pas forcément du physique, de la stature, de la capacité à communiquer mais plutôt de vos valeurs, de votre intégrité et du profond respect pour les personnes qui vous suivent.

Evidemment, bien que l’aventure soit passionnante, ce ne sera probablement pas un long fleuve tranquille. La performance risque même de baisser à court terme (comme lorsqu’on met en place l’agilité d’ailleurs).

Alors toujours partant ?

Commençons par un peu théorie si vous voulez bien. C’est vraiment utile pour mieux comprendre la logique sous-jacente et adapter la démarche lorsque c’est nécessaire. Je vous rassure, il s’agit de théorie pragmatique comme dans l’agilité.

Les 7 principes de la culture

La culture est co-créée

Une culture ne peut être créée par une personne. Quoi que vous fassiez, ce qui fera la culture de votre organisation sera le fruit du comportement conscient ou non des membres de cette organisation. Il s’agit ici de créer cette culture AVEC ces membres et de le faire consciemment. D’autant plus que nous donnons de l’importance à ce à quoi nous participons. Par exemple, nous prenons  bien plus de plaisir à déguster un repas auquel nous avons participé en groupe, qu’un repas entièrement préparé pour nous.

Voici un exemple de processus de co-création :

  1. Rassembler le groupe.
  2. Prendre du recul est définir clairement ce que vous êtes en train de faire et POURQUOI.
  3. Demander à tout le monde ce que cette initiative provoque en eux sur le plan émotionnel.
  4. Demander leur idées pour créer cette expérience. Les laisser parler plus que vous.
  5. Noter les idées qui apportent beaucoup avec peu d’effort.
  6. Demander qui est emballé par quelle idée et serait prêt à s’engager sur une prochaine action devant ses pairs.

Partagez ce que vous voulez garder

Partagez sa culture est un bon moyen de renforcer votre intégrité et responsabilité. Vous craigniez de divulguer vos secrets de fabrique en divulguant votre culture. Rassurez vous, la culture est une question d’individus et les individus ne peuvent être copiées. Vous pouvez ainsi générer de l’appréciation du monde extérieur qui vous rappelle à quel point vous avez de la chance de vivre votre culture. Ce qui est plutôt galvanisant. De plus, partager quelque chose et en faire une habitude génère une culture du don.

La culture se nourrit de la culture

Vous allez vivre des moment forts au cours de votre expérience sur la culture. Enregistrez ces moments (photos, vidéos, etc) et partagez ces enregistrements. Il y a un amateur de montage vidéo dans votre groupe ? proposez lui de faire un montage pour l’occasion. Il y a une personne qui s’y connait en blog ? proposez lui d’en créer un sur votre tribu/culture et d’y poster les photos et vidéos. Cet échange autour de votre culture redonne de l’énergie à votre culture.

La culture mange de la stratégie au petit déjeuner

Cette formule n’est pas de moi. Elle signifie qu’un patron ou leader peut disposer de la meilleure stratégie au monde pour atteindre les objectifs qu’il s’est fixé, elle ne pourra jamais porter ses fruits si elle n’est pas alignée avec la culture de l’organisation. Je parle bien sûr de la vraie culture souvent invisible et non pas des valeurs « Marketing » affichées sur le site internet de l’entreprise.

La culture est un jeu

On se demande parfois pourquoi une équipe ne se donne pas à fond. Il arrive même qu’on la juge faignante ou de génération Y. Ou en tant que manager, on se dit qu’on inspire pas assez. Et si on faisait de notre culture un jeu ? Changeant ainsi notre rapport au travail.

Un jeu bien défini comporte :

  • Un objectif clair (exemple : « devenir l’équipe agile de référence au sein de l’entreprise »),
  • Des règles du jeu claires (exemple : les valeurs fondamentales de l’équipe),
  • Un moyen de connaître son score/feedback (ex : indicateurs de performance, indicateur d’épanouissement au travail, indicateur de satisfaction des utilisateurs),
  • La possibilité de « passer » (ex : les personnes qui ne veulent pas jouer le jeu peuvent demander à travailler sur un autre projet).

Petite parenthèse agile au passage : le cadre méthodologique Scrum se prête également bien à une approche par le jeu. La définition du rôle des joueurs est claire ainsi que les règles du jeu, la mesure du score (indicateurs d’avancement de sprint et de release) et les objectifs (de sprint et de release).

La monnaie de la culture

Imaginez que vous travailliez dans mon équipe sous ma responsabilité et que je vous dise que le support production (activité de « dépannage » des utilisateurs finaux en difficulté avec la solution livrée) est très important. Que ressentez vous ? Vous sentez vous sensibilisé(e) et prêt(e) à vous donner à fond pour que le support production soit optimal ? Pas vraiment. Peu de personnes apprécient qu’on leur dise quoi faire.

Si par contre je vous raconte l’histoire d’un utilisateur qui n’est pas parvenu à utiliser la solution, s’est retrouvé ainsi bloqué plusieurs heures au travail alors qu’il devait amener sa fille malade chez le médecin. Et que je voudrai faire tout ce qui est en notre pouvoir pour éviter que cette situation se re-nouvelle. Y compris de réfléchir avec vous aux améliorations qu’on peut mettre en oeuvre.

Cette fois, que ressentez vous ? Il y a de fortes chances pour que l’histoire de cet utilisateur et sa fille malade vous touche et vous pouvez également ressentir les valeurs humaines qui m’animent. Vous pouvez aussi sentir que je ne cherche pas de coupable ou à vous dire quoi faire. N’est ce pas plus motivant ?

La monnaie de la culture, ce sont ces histoires qui véhiculent des valeurs et donnent du sens à ce que nous faisons au quotidien.

Nouvelle parenthèse agile : Il est intéressant de noter que les pratiques des Personnas et User Stories peuvent utiliser ce même levier pour donner plus de sens à notre travail sur un projet de développement logiciel. Je sors bien sûr du registre du travail sur la culture pour cette parenthèse.

Le secret de l’innovation

Dans un monde qui bouge, l’innovation est quasi incontournable. Quel risque prenez vous à innover en proposant une nouvelle idée, en essayant une nouvelle technologie, en proposant une nouvelle méthodologie ou algorithme ? Vous pouvez vous tromper et craindre le jugement ! Par conséquent, quelle est la condition indispensable à l’innovation ? Une culture du droit à l’erreur.

Une erreur apporte avec elle un enseignement. Une piste de plus à éliminer pour nous rapprocher davantage de la solution. Célébrez vos erreurs ! Montrez que l’erreur est permise.

Poser les bases

Définir votre mission

Trouvez la mission de votre organisation. La mission doit répondre à la question « Pourquoi je vais travailler chaque jour ? ». Elle doit s’adresser à la fois au monde extérieur et à l’intérieur de votre organisation ou tribu. Elle doit également véhiculer une émotion. Prenons deux exemples. La mission de Zappos (vendeur de chaussures et autres articles annexes sur internet) est « Live and deliver WOW! » (« vivre et fournir du Wouah ! »). Autre exemple inventé par mes soins : “Fournir du logiciel que les gens adorent. Et prendre du plaisir à le faire”.

Si je prends le second exemple, la partie « prendre du plaisir à le faire » est essentielle. L’idée déjà évoqué un peu plus haut, est que pour prendre soin des autres, il faut avant tout prendre soin de soi. Par conséquent, pour que les membres d’une organisation prennent soin de ses clients (ou utilisateurs du logiciel), ils doivent prendre soin d’eux en prenant du plaisir à travailler en plus d’une vie personnelle épanouie.

Ce point est également valable pour le leader souhaitant travailler sur la culture. Il devra veiller à ne pas faire cette démarche pour compenser un vide dans sa vie personnelle. Si tel était le cas, il devra d’abord prendre soin de lui sur le plan personnel avant de travailler sur la culture avec les membres de son organisation. S’il ne le fait pas, ces derniers vont sentir ce vide à combler et ne seront pas réellement impliqués.

Définir votre vision

Une vision permet aux membres de l’organisation de s’y projeter. Pour cela, elle doit pouvoir se concrétiser sur un horizon relativement court de 2 à 5 ans. Une fois qu’une vision s’est concrétisée, il ne reste plus qu’à en trouver une autre.
Reprenons l’exemple de Zappos dont les visions successives et atteintes furent :

  • Vision 1 : Plus gros magasin de chaussures au monde
  • Vision 2 : Meilleur service au monde

La vision se construit sur les acquis de la précédente, elle est courte, facile à mémoriser et elle inspire. Autre exemple au passage : la vision des auteurs du livre Tribal Leadership était devenir un best seller (et ils ont atteint cette vision).

Pour identifier cette vision, voici une question qui peut vous mettre sur la voie : “Que ferions nous si nous pouvions faire l’impossible ?”.

Les valeurs fondamentales

Geyser erruption. IcelandVous ignorez quelles sont les valeurs fondamentales de votre tribu ou organisation (là encore, je ne parle pas des valeurs “marketing” de votre entreprise) ? Pourtant elles sont déjà là comme une source sous vos pieds prête à jaillir. Chacun est guidé au quotidien par ses propres valeurs. Reste à les faire émerger, découvrir les valeurs en commun. Certes, vous découvrirez peut être quelques conflits de valeurs d’une personne à une autre, d’une personne vis à vis de la majorité du groupe ou de l’entreprise. Mais après tout, mieux vaut tard que jamais, plutôt que de vivre dans l’illusion.

Ok mais pourquoi établir ses valeurs ?

Parce que les valeurs émergeant de ce travail collectif offrent un cadre de travail souple qui aide à la prise de décision, favorise l’auto-organisation, donne du sens. Un cadre ouvert à l’interprétation qui considère les gens comme des adultes qui ont besoin d’inspiration plutôt que de micro-management. Ces valeurs donnent une identité au groupe, un ADN qui renforce le sentiment d’appartenance. En contrepartie, certaines décisions peuvent être rendues difficiles. Comme renoncer à un business juteux en décalage avec les valeurs de l’organisation ou se séparer d’une personne en conflit avec ces dernières. Dans ce dernier cas, rien ne nous empêche d’accompagner cette personne dans une autre voie, en l’aidant financièrement, en lui offrant d’autres pistes d’évolution dans une autre équipe ou département (dans le cas d’une grosse entreprise). Inversement, ces valeurs vont attirer les bonnes personnes pour votre organisation. Des personnes qui se reconnaissent à travers ces valeurs que vous véhiculez et qui sont sans doute prêtes à se donner à fond.

Mettre en action vos valeurs

Mais encore faut’il mettre en action ces valeurs. L’approche qui a fonctionné pour Zappos se déroule 3 étapes :

  1. Définir un « standard » basé sur la valeur que vous voulez offrir sans compromis. Pour Zappos, il s’agit de mettre en place le standard « Wouah ! » en offrant une qualité de service exceptionnelle.
  2. Faire une promesse audacieuse à la fois aux clients ou commanditaires et aux membres de l’organisation. Pour Zappos il s’agissait d’expédier la commande dès le lendemain.
  3. Tenir cette promesse quelque soit l’état du marché.

Zappos a du renoncer à des parts de marché importantes en renonçant à travailler avec certaines marques qui souhaitaient expédier eux même, à leur rythme, les commandes. A court terme, les revenus ont baissé de façon très significative. Mais à long terme la situation s’est inversée. Le client est prêt à payer le prix fort pour un « standard » sur lequel il peut compter.

Encore une fois, Zappos n’est qu’un exemple pour illustration. Vous pouvez éprouver quelques difficultés pour vous projeter selon votre contexte. Vous ne vendez peut être pas de chaussures ni quoi que ce soit de ce genre. Mais votre équipe, département ou organisation a bien des clients, des utilisateurs, des personnes qui utilisent vos services.

Avant de faire votre promesse audacieuse, vous devez connaître vos valeurs fondamentales. Comment les faire émerger sera l’objet du prochain article.

 

J’espère que cette fiche vous a été utile. Maintenant il y a quelque chose que je voudrai que vous fassiez si vous voulez bien.

Dites moi, dans la partie commentaire ci dessous, quelles réactions ou réflexions vous inspire cette lecture.

Vos réponses seront une source d’inspiration pour la rédaction de la ou des prochaines parties.

Par ailleurs, vous pouvez être immédiatement averti par email de la parution de la seconde partie. Pour cela, abonnez vous à la newsletter.

6

L’art de la Rétrospective

Dans le cadre de Scrum, la rétrospective est une réunion positionnée à la fin de chaque sprint (sprint = itération) pendant laquelle l’équipe Scrum met à profit son vécu sur le sprint écoulé pour améliorer son organisation afin d’être plus efficace. La rétrospective est donc un élément clef du principe d’amélioration continue rendant une équipe auto-apprenante.

Comment exploiter au maximum ce levier d’amélioration ? Comment faire en sorte que chacun exprime son point de vue, que la rétrospective porte ses fruits avec des améliorations notables, qu’elle reste vivante malgré sa répétition. C’est à ces questions que je propose de répondre dans cette fiche pratique. J’y aborde également d’autres usages de la rétrospective.

Je tiens à rendre à César ce qui est à César en précisant que le contenu de cet article est bien évidemment issu de ma propre expérience mais aussi des enseignements donnés par le livre « Agile Retrospectives – Making Good Teams Great » de Esther Derby et Diana Larsen.

Récolter les points de vue de chacun

Il y a autant de vérités que de points de vue. Autant de points de vue que de personnes. Chaque vision permet de voir un problème ou une idée sous un angle différents pour mieux le résoudre ou la faire grandir. C’est ce qu’on peut appeler l’intelligence collective et différents facteurs permettent de favoriser cette dernière.

La posture de coach

Qu’est ce qu’un coach ? Voici ma définition personnelle : un coach est quelqu’un qui va aider une personne à trouver elle même les réponses à ses questions pour lui permettre d’atteindre un résultat qu’elle s’est fixé. Cette activité repose sur une croyance fondamentale : « la personne coachée dispose des ressources nécessaires pour atteindre le résultat visé« . On utilise souvent la métaphore de la graine qui contient toutes les informations nécessaires pour grandir et devenir un arbre. Pour l’anecdote, étymologiquement parlant, « coach » vient de « cocher » (l’ancêtre du chauffeur de taxi) qui amène une personne d’un point A à un point B.

L’animatrice ou animateur de la rétrospective doit adopter une posture de coach vis à vis de l’équipe et renoncer ainsi à la tentation de dire à cette dernière quoi faire en apportant des solutions toutes faites. C’est un exercice qui peut se révéler particulièrement difficile pour un ex-chef de projet habitué à dire aux membres de son équipe quoi faire, comment le faire et quand le faire. Surtout si cet ex-chef de projet a une formation d’ingénieur avec un cerveau « câblé » pour apporter des solutions à des problèmes.

Sans cette posture de coach, on n’aide pas l’équipe à trouver elle même des solutions, à prendre des initiatives et à innover. On fragilise son engagement à mettre en oeuvre les actions d’amélioration (puisque les actions ne viennent pas d’elle). On peut passer à côté d’idées et de solutions pertinentes. On multiplie nos chances de mettre en place des actions inefficaces voire contre-productives.

Si l’animatrice ou animateur dispose d’une expérience ou expertise particulière qui mérite d’être mise à profit en cours de la rétrospective (le Scrum Master porte par exemple l’expertise Scrum). Elle ou il peut s’impliquer dans la recherche de solution à condition de quitter temporairement le rôle d’animatrice ou animateur et de ne pas décider d’une action d’amélioration, mais plutôt de la proposer à l’équipe. En lui laissant clairement le droit de la juger inopportune. Elle ou il peut influencer mais pas décider.

Pas de jugement ni de recherche de coupable

Il est toujours recommandé d’introduire la rétrospective en mentionnant le fait que l’objectif de la rétrospective n’est en aucun cas de porter des jugements sur ce qui sera dit, en particulier à propos des idées proposées. Ni de rechercher des coupables lorsqu’on mettra sur la table les problèmes rencontrés.

Ce rappel est d’autant plus important si un responsable hiérarchique est présent pendant la rétrospective. Si c’est le cas, l’animatrice ou animateur devra briefer cette personne pour s’assurer qu’elle joue le jeu de la posture de coaching. Cette personne peut même participer à l’introduction est préciser : « Je ne suis là qu’en observateur et en position d’écoute, sentez vous libre de parler de tout, y compris de choses qui, selon vous, pourraient me déplaire ».

Un seul mot suffit parfois

Tout le monde n’est pas à l’aise pour parler devant les autres, proposer des idées, etc. C’est normal et il ne s’agit pas de forcer qui que ce soit à s’exprimer. Par contre, il faut lui en donner l’occasion. De simples tours de table peuvent aider. Et parfois le simple fait qu’une personne réservée ai prononcé un « je passe » peut la débloquer dans la suite des échanges.

L’animatrice ou animateur doit également être attentif aux dynamiques de groupe, notamment lorsqu’une personne monopolise trop souvent la parole. Au quel cas, on peut déclencher une pause et faire observer à cette personne que les autres ont rarement eu l’occasion de s’exprimer, alors que leur point de vue est sans doute intéressant.

La force du silence

Il faut parfois compter jusqu’à 10 dans sa tête après avoir posé une question à l’équipe. Le silence ainsi créé génère un espace libre qui aide l’équipe à réfléchir plus en profondeur pour y chercher une idée ou réflexion difficile à trouver.

Obtenir de véritables améliorations

Obtenir des idées, puis un plan d’actions d’amélioration est une chose. Transformer l’essai en implémentant ces actions en est une autre. Là encore la posture de coach a son importance car l’animatrice ou animateur doit résister à la tentation d’affecter arbitrairement les actions aux membres de l’équipe. Ou inversement, elle ou il doit résister à la tentation de prendre à sa charge les actions (en tant que Scrum Master par exemple). En participant activement aux actions d’amélioration, l’équipe s’habitue à s’auto-organiser et devenir « maître de son destin » au sein du cadre donné par Scrum et l’entreprise ou organisation.

Voici quelques moyens de transformer l’essai :

  • Privilégier la qualité des actions à la quantité. 2 ou 3 bonnes actions à mettre en oeuvre d’ici la rétrospective suivante peuvent suffire.
  • Rendre les actions SMART (Spécifique, Mesurable, Acceptable, Réalisable, Temporellement définie). Les questions du genre « Comment saurons nous que notre action a porté ses fruits ? » peuvent aider à alimenter la réflexion collective.
  • Favoriser l’appropriation des actions par l’équipe en demandant qui serait prêt à prendre en charge telle ou telle action. Prendre la responsabilité d’une action devant le reste de l’équipe favorise l’engagement.
  • Transformer les actions en tâches qui se rajoutent au tableau des tâches, kanban ou sprint backlog et sont ainsi estimées et suivies au même titre que les autres.

Garder la rétrospective vivante

Varier les objectifs

L’objectif « générique » de la rétrospective est du genre « Améliorer notre processus de développement pour le rendre plus efficace et plus agréable à vivre ». Il s’agit aussi d’améliorer la qualité du produit et d’adapter en conséquence la définition de « terminé ».

Mais selon l’actualité du projet, rien n’empêche de varier l’objectif d’une rétrospective à l’autre. Voici quelques exemples d’objectifs un peu plus ciblés :

  • Améliorer notre réactivité vis à vis des utilisateurs.
  • Améliorer notre relation et nos interactions avec le métier et le service marketing.
  • Comprendre les raisons pour lesquels l’objectif du sprint n’a pas été atteint.

Attention cependant à ne pas basculer dans le « trop ciblé » et occulter ainsi des sujets qui méritent d’être instruits en rétrospective.

Varier les activités

Les activités d’animation de rétrospective sont nombreuses et variées. Testez en des nouvelles. Vous apporterez ainsi du renouveau à vos rétrospectives et peut être que vous découvrirez une activité qui fonctionne mieux qu’une autre.

A ce sujet, je vous invite à lire la fiche de livre « Agile Retrospectives – Making Good Teams Great » de Esther Derby et Diana Larsen.

Changer d’animatrice ou d’animateur

Après plusieurs rétrospectives, certains membres de votre équipe se sentiront peut être à l’aise – voire se porteront volontaire – pour animer une rétrospective. Profitez en, car c’est également une bonne source de renouveau et vous serez peut être positivement étonné par les résultats. Si personne ne se propose, faite un appel à volontaire. Si la ou le volontaire a besoin de conseils avant de se lancer, rendez vous disponible pour les lui transmettre.

Faire émerger « code » de conduite de l’équipe

Avez vous pensé à utiliser des activités de brainstorming en petits groupes pour définir ensemble le code de conduite de l’équipe lui permettant de rester efficace (un peu à la Dexter pour ceux qui connaissent la série) ? Le « code » qui s’applique à la rétrospective par exemple (exemples d’accords collectifs formant le fameux « code » : « Ne pas prendre de PC portable pendant la rétro et mettre les téléphones en mode silencieux », « chacun parle à tour de rôle », etc). Mais aussi dans le quotidien des itérations (exemple subjectif : « Pas de modification du code source commun à partir de X heures avant la revue de sprint ou livraison. A l’exception de correctifs ciblés et maîtrisés par du pair programming »). Attention, ne dépassez pas 7 ou 8 accords collectifs, sinon c’est impossible à retenir.

La rétrospective de rétrospective

La rétrospective AgileOn ne pense pas toujours à améliorer un outil d’amélioration. Pourtant, c’est peut être la meilleure façon d’optimiser le retour sur investissement de la rétrospective. Vous pouvez ainsi façonner des activités spécifiques à votre contexte pour aboutir à VOTRE rétrospective, à une rétrospective sur mesure.

Pour y parvenir il existe différentes activités. L’une d’entre elles est appelée le « +/Delta » et prends seulement 10 à 20 minutes selon la taille du groupe. Elle peut servir pour une rétrospective d’itération, de release ou de projet.

Voici comment procéder :

  1. Présentez l’activité en disant: « Avant de terminer, nous allons identifier ce que nous voulons garder et ce que nous voulons changer pour notre prochaine rétrospective. ».
  2. Divisez votre feuille de paper board ou tableau blanc en deux colonnes (une ayant pour titre « + » pour les choses à garder et l’autre « Δ » pour les changements à apporter). Ajouter un titre au dessus (ex : Processus d’amélioration de la rétrospective). Annoncer le temps maximum disponible (cinq à quinze minutes).
  3. Demandez au groupe de prononcer les forces (choses à garder) et les changements. Capturez-les mot pour mot en remplissant les colonnes. Arrêtez-vous lorsque les idées se tarissent, ou à la fin du temps imparti. Attendez quelques secondes. Souvenez vous de la force du silence.
  4. Remercier le groupe pour leur participation franche. Comparez les éléments recueillis avec ceux des précédentes rétrospectives pour voir si des « schémas » (patterns) apparaissent.

Lorsqu’il n’y a plus de place pour écrire dans chacune des colonnes, c’est également le signe que vous pouvez vous arrêter. Au pire, les idées qui ne rentrent pas pourront être évoquées lors de la prochaine rétrospective de rétrospective.

Autres usages de la rétrospective

Définir ses valeurs, façonner sa culture et son organisation

La rétrospective peut également être un formidable outil pour définir les valeurs fondamentales de votre équipe. Des valeurs qui peuvent ensuite évoluer dans le temps, d’où l’intérêt de faire de telles rétrospectives régulièrement, tous les trimestres par exemple. Vous l’aurez compris, dans ce genre de rétrospective on détourne les activités de recherches collective d’idées ou d’actions en recherches de valeurs et principes. Evidemment, le nombre de personnes peut être bien plus grand, ce qui peut influencer la durée et la technique d’animation. Tout comme les rétrospectives de release ou de projet qui sont également possibles.

Pour ces dernières, on peut ainsi identifier des améliorations susceptibles de toucher l’organisation toute entière plutôt que le processus de développement seul.

Premier pas vers l’agilité

La rétrospective est également une bonne façon d’introduire l’agilité dans une organisation. On permet ainsi à l’équipe de s’exprimer librement sur ce qui fonctionne bien aujourd’hui, ce qui mérite d’être amélioré et des actions qu’on peut mettre en oeuvre à court terme. L’équipe est ainsi impliquée dès le début et partie prenante sur les décisions de changements. Au coach agile ou Scrum Master de savoir proposer ce que l’agilité a à offrir.

Message de soutien

Si vous lisez ces mots, c’est qu’il y a de grandes chances pour que vous ayez lu cette fiche jusqu’au bout et je tiens à vous féliciter pour ça car nous prenons de moins en moins le temps de faire des lectures approfondies. Si vous débutez dans l’agilité, cet article pourrait vous décourager d’animer une rétrospective. C’est pourquoi je tiens à vous rassurer en vous disant ou vous rappelant que : « Vous n’avez pas besoin d’être parfait » et je dirai même plus « vous avez droit à l’erreur ». C’est un des grands atouts d’une approche agile.

Vous trouvez que votre première rétrospective manquait de quelque chose ? de fluidité ? d’idées ? d’améliorations concrètes ?… Ce n’est pas grave. Vous venez d’apprendre des choses que vous pourrez mettre à profit lors de la prochaine rétrospective. La seule chose que vous devez vous « obliger » à faire, c’est de renouveler cette rétrospective à la fin de chaque sprint ou itération et d’y consacrer le temps nécessaire. Même lorsque toute l’équipe se dit « je pense qu’on est rôdé, il n’y a plus grand chose à améliorer ». Les choses changent ou évoluent en permanence, il y a toujours des choses à améliorer. Et quand bien même ce ne serait pas le cas, ça ne fait jamais de mal de se poser tous ensemble quelques heures après une période d’effort soutenu.

 

Les spécifications agiles

La documentation du projet est sans doute l’élément dont la durée de vie est la plus longue. Les technologies peuvent aller et venir dans le temps mais la documentation demeure l’héritage du projet. Pourtant nous échouons ou luttons souvent dans la maintenance de cette dernière. Les enjeux sont clairs : réaliser des spécifications compréhensibles à la fois par un utilisateur et par un développeur, à jour – donc fiables, donc faciles à maintenir – et non ambiguës afin de pouvoir vérifier objectivement la couverture du besoin. Cet article traite de différentes pratiques de spécification utilisées sur des projets Agile pour répondre à ces enjeux.

Partons du constat

Les principes et pratiques abordés par cet article ont pour point de départ les constats suivants :

  • Les utilisateurs ne savent ce qu’ils veulent qu’après avoir vu une première version du logiciel (Principe d’incertitude du besoin de Humphrey).
  • Les besoins changent souvent durant le processus de développement du logiciel (Principe d’incertitude de Hadar Ziv – 1996).
  • Spécifier intégralement un système interactif est impossible (Lemme de Peter Wegner – 1995).
Comparaison de l'efficacité des moyens de communication

Comparaison de l’efficacité des moyens de communication (Source : Alistair Cockburn)

Un autre constat important concerne les limites de la communication par écrit (cf. schéma ci contre). L’écrit peut être interprété de différentes façons, en particulier lorsque le sujet traité est complexe. Inutile de rappeler que, de nos jours, la réalisation d’un logiciel est une tâche particulièrement complexe tant fonctionnellement que techniquement. D’autre part, ce mode de communication n’offre pas d’interaction directe permettant de vérifier que le message porté est compris. Enfin, il fait l’objet d’un délais de réponse rarement maîtrisé (mode guichet).

Par ailleurs, sur des projets classiques menés en cascade, il arrive que le rédacteur du cahier des charges ne soit pas la même personne que le rédacteur des spécifications fonctionnelles générales, qui n’est pas la même personne que le rédacteur des spécifications fonctionnelles détaillées, qui n’est pas la même personne que celle qui développe, qui n’est pas la même personne que celle qui teste. Sur des projets longs à fort turn-over, il arrive même que ces différents acteurs ne se rencontrent jamais. Comment garantir une bonne couverture du besoin dans ces cas là ?

 

Forts de ces constats, il s’agit de renoncer à l’illusion de pouvoir spécifier à l’avance l’intégralité d’une solution logicielle. Et au contraire de spécifier, tester et développer au fil de l’eau. De communiquer le plus possible en face à face et d’utiliser l’écrit pour capitaliser l’essence du comportement applicatif visé.

Principes directeurs

  • Spécifions ensemble : Acteurs métiers et techniques élaborent ensemble les spécifications. Le métier est indispensable pour communiquer les objectifs et la valeur ajoutée visée à travers la fonctionnalité à réaliser. Les développeurs pour tirer parti de l’infrastructure sous-jacente et de la technologie émergente. Les testeurs pour identifier les cas d’usage aux limites. Les idées de chacun sont ainsi mises à profit pour parvenir à la meilleure solution possible. La responsabilité des spécifications et l’engagement associé sont alors collectifs.
  • Identifier les tests en amont afin de lever les ambiguïtés et pouvoir ainsi vérifier objectivement la couverture du besoin. La notion de “test” s’invite dès l’analyse du besoin et la conception. Le test ne sert plus seulement à vérifier l’absence de bug et la bonne couverture du besoin mais également à guider non seulement les développements en soi mais aussi la conception et l’architecture de la solution logicielle.

Règles d’or de rédaction

  • Exclure toute connotation technique et détails d’IHM de la spécification écrite. La documentation technique de type architecture (logicielle ou matérielle) trouvera sa place dans un dossier d’architecture si le projet le nécessite ainsi que dans le code source. La procédure technique d’installation est automatisée autant que possible (cf. Livraison Continue). Les détails d’IHM peuvent être portés par des maquettes au fil de fer (type Balzamiq). La charte graphique pourra être portée par la fonctionnalité de référence (cf. paragraphe « Balle Traçante »). Quant aux détails tels que les libellés (les messages d’erreurs et de confirmation de saisie d’un formulaire par exemple) coûtent si peu cher à modifier par la suite qu’on pourrait presque se passer de les « tracer » dans les spécifications. Au pire si certaines personnes ont besoin d’être rassurées, on peut les centraliser dans un document annexe (un fichier « properties » idéalement avec des clef parlantes pour les acteurs métier).
  • Privilégier le vocabulaire de l’utilisateur, le langage naturel (plutôt que télégraphique), au présent (plutôt qu’au futur) et décrire l’expérience utilisateur.

Pratiques

Spécification par l’exemple

Qui n’a pas eu naturellement recours à un exemple pour faire comprendre le comportement complexe d’une solution logicielle à concevoir ou l’expérience utilisateur associée ? La pratique décrite ici repose sur ce levier.

Terminologie

TDD (Test Driven Development) , A-TDD (Acceptance Driven Development), BDD (Behavior Driven Development) et autres sont toutes des pratiques pertinentes et efficaces. Leur multiplication et leur terminologie ont cependant contribué à semer la confusion auprès de leur utilisateurs. Plus grave encore, elles rendent difficile l’implication cruciale des acteurs métier dans le processus de spécification. Afin de couper court à cette confusion, le terme plus parlant de “Spécification par l’exemple” est proposé pour englober ces pratiques. Remarquons que ce terme est également dépourvu du mot “Agile”.

Processus

Processus piloté par les user stories

Exemple de processus de réalisation piloté par les User Stories. Schéma traduit à partir de celui de David Peterson et icônes de chapeaux de Anthony Piraino.

La notion de User Story (ou « Story ») utilisée ici se limite à la simple formalisation d’un besoin associé à une fonctionnalité à réaliser (exemple : « Paiement d’une commande d’articles »). L’utilisation étendue de la pratique des User Stories est abordée plus loin.

Le présent processus est piloté par les User Stories. Autrement dit, au sein de l’itération, chaque User Story passe individuellement à travers les étapes mentionnées. Elles n’ont pas à passer ensemble chaque étape à la façon d’un mini processus en cascade (ou V) au sein de l’itération.

Pour précision, la « Story » illustrée par le schéma ci-contre (en haut à droite) est sélectionnée à partir du Product Backlog (centralisant la liste ordonnancée des besoins ou fonctionnalités à réaliser) lors de la planification d’itération. En mode flux (Kanban), on pourra appliquer les même étapes sans notion d’itération.

Etape « Discuter »

Un testeur, développeur et expert métier s’assoient avec le product owner et discutent de la Story, décomposent et distillent progressivement le comportement visé en un ensemble de spécifications simples. La conversation (ou atelier de spécification) pourra dans un premier temps se concentrer sur 3 exemples clefs. En commençant généralement par l’exemple « heureux » selon lequel tout se passe bien. Il est généralement facile à identifier et permet d’éclairer la voie.

Point d’attention : A ce stade, il arrive que le porteur du besoin soit déjà dans la solution, court-circuitant ainsi la valeur ajoutée du développeur qui pourrait proposer une meilleure solution (potentiellement moins coûteuse, plus simple, etc) grâce à une technologie que lui seul connaît. La bonne pratique consiste donc à dériver la fonctionnalité à partir de l’objectif de fond. Quitte à remonter en arrière lorsque le porteur du besoin est déjà dans la solution. Dans ce cas de figure le recours au « Pourquoi ? » peut aider (« Pourquoi réalisons nous cette fonctionnalité ? »). Ou de façon plus diplomate « Quels objectifs devons nous atteindre à travers cette fonctionnalité ? ». Ces objectifs guideront les acteurs.

Pour illustrer ce point d’attention, un exemple nous vient de monde de l’aviation. L’expression de besoin associé à la réalisation de l’avion de combat F-16 consistait notamment à atteindre une vitesse de mach 2-2.25. Le concepteur a alors demandé pourquoi. La réponse fut « pour pouvoir échapper au combat ». Le concepteur n’a jamais atteint mach 2. En revanche il a apporté plusieurs innovations permettant d’échapper au combat. Cet avion a eu un tel succès que 30 ans après sa fabrication il est toujours en production.

Etape « Décider »

Le product owner décide que les spécifications couvrent suffisamment le comportement visé pour cette itération et le périmètre est verrouillé. Après ce verrouillage, tout comportement que l’équipe a oublié de spécifier est noté pour la prochaine itération dans laquelle il peut être priorisé de façon appropriée.

Point d’attention : Le principe évoqué en début d’article consistant à dire que l’utilisateur ne connaît pas son besoin tant qu’il n’a pas essayé une première version de l’application ne doit pas servir d’excuse pour ne pas verrouiller le périmètre puis défaire et refaire des développements d’une itération sur l’autre. Grâce à un tel processus, le délais entre la conversation sur le besoin et la fin du développement associé est si court que ce principe d’incertitude n’est pas valable.

Etape « Développer »

Le testeur affine les exemples. Le développeur instrumente les spécifications, créé des fixtures (éléments permettant de créer l’environnement propre à l’exécution des tests associés aux exemples) échouant (on vérifie d’abord que le test alerte correctement en cas d’erreur en passant au « rouge ») et implémente ensuite la fonctionnalité (passage « au vert »). Nous aborderons plus en détail dans le paragraphe suivant la notion de « spécification exécutable » associée.

Etape « Démontrer »

Une fois que tous les tests passent avec succès, la Story peut être démontrée au product owner. Les testeurs pourront également tester manuellement. Le passage au vert des tests permet d’affirmer objectivement que la fonctionnalité est « terminée ».

Les spécifications exécutables

Définitions et principe

On appelle « spécification exécutable », une spécification directement connectée au code source de la solution logicielle spécifiée. Chaque exemple porté par cette spécification est directement reliée à un test fonctionnel automatisé. L’ensemble des spécifications rassemblées forment une « documentation vivante ».

Exemple de spécification

Voici ci dessous un exemple de spécification exécutable réalisée avec l’outil Concordion.

Exemple de spécification exécutable réalisée avec l'outil Concordion

Exemple de spécification exécutable réalisée avec l’outil Concordion

A première vue, nous sommes face à une spécification statique. En réalité il s’agit d’une page web générée à partir d’une spécification exécutable (qui se présente sous la forme d’un fichier HTML) interprétée par un outillage de test automatisé. Les tests réalisés avec succès sont indiqués en vert comme sur l’exemple ci dessous (cf. résultats de la recherche) ou en rouge en cas d’échec.

Usage par l’acteur métier

L’acteur métier participe à l’identification des exemples associés à une fonctionnalité qui alimenteront la spécification exécutable (cf. étape « Discuter » du processus). Ce sera généralement le testeur et/ou le développeur qui se chargeront de la rédiger. Après les développements, il pourra se reposer sur ces spécifications pour s’assurer qu’une nouvelle fonctionnalité est bien « terminée » (tests au « vert »).

Plus tard, lorsqu’il souhaitera apporter un changement à un comportement existant de l’application, il pourra là encore se reposer sur elles pour retrouver les règles sous-jacentes à ce comportement. Il le pourra dans la mesure où ces spécifications sont fiables, car intrinsèquement connectées au code source. Dans le cas de spécifications classiques non fiables, nous devons nous reposer sur le code en faisant appel à un développeur pour retrouver les règles dictant le comportement de l’application (avec tous les désagréments que cela implique).

Usage par le testeur

Nous l’avons vu, le testeur participe à l’élaboration des spécifications et à leur affinage en ajoutant notamment les cas de test aux limites (comme les cas d’erreur par exemple). Ce travail peut se faire en binôme avec un développeur. Idéalement, le testeur aura un minimum de connaissances en HTML (rien de bien méchant) nécessaires à l’appropriation de la syntaxe de test afin de rédiger et affiner lui même les spécifications exécutables. Grâce à ces spécifications, il pourra contribuer à la qualité de la solution le plus en amont possible et vérifier en temps réel le bon comportement ou régression de la solution en fonction des évolutions du code. Les cas particuliers non automatisables feront l’objet de tests manuels.

Usage par le développeur

Le développeur participe à la rédaction des spécifications exécutables. Dans le pire des cas, il fait parti des relecteurs avant le démarrage des développements. Ses compétences pourront lui permettre de compléter les exemples et tests dérivés, ou réorienter la structure des exemples afin de rendre les tests associés automatisables. Il implémentera ensuite les tests automatisés associés à la spécification. Ces tests guideront ses développements. Ils vont l’obliger à respecter une architecture permettant l’automatisation des tests. Dans le cadre d’un modèle MVC, la couche front (ou Vue) ne comportera aucune logique métier sujette aux tests automatisés. Ces derniers se glisseront « sous la peau » de l’application organisée en composants à faible couplage. Les bonnes pratiques d’architectures logicielle deviennent alors incontournables. La logique métier se présentera sous la forme d’une « API » facilement testable.

Le développeur pourra se reposer sur cette « ceinture de sécurité » de tests automatisés quant il s’agira de réaliser des évolutions ou de réusiner des volumes de code plus ou moins importants.

Outillage

Seuls Cucumber et Concordion ont été expérimentés pour la rédaction de cet article. Cucumber a été rapidement mis de côté face à la lourdeur de préparation de l’environnement de travail associé. Concordion bénéficie d’une documentation claire, synthétique et illustrée par l’exemple en parfaite cohérence avec la pratique de spécification associée. Par ailleurs sa prise en main est rapide (moins d’une heure). D’autres outils existent tels que Fitnesse (qui a inspiré Concordion). Tous ceux cités ici sont gratuits.

Bénéfices

  • La documentation fonctionnelle est fiable (car nativement en phase avec le code).
  • L’analyse d’impact des changements et l’accomplissement de ces derniers sont facilités.
  • La compréhension commune des besoins entre acteurs métiers et techniques est assurée.
  • Les spécifications sont précises limitant ainsi le « faire et défaire » lié aux ambiguïtés autour du besoin.
  • La définition de « terminée » d’une fonctionnalité objective et partagée.
  • Les efforts de mise à jour des spécifications et d’exécution de tests manuels répétitifs sont limités.
  • La Livraison Continue est rendu possible.
  • La qualité est élevée et la relation entre client et fournisseur est ainsi améliorée.

Ne pas oublier le travail en amont

Il existe de nombreux principes, pratiques et astuces pour faire en sorte que les bénéfices de notre automatisation des tests fonctionnels soient supérieurs à l’investissement lié à leur mise en oeuvre et maintenance. Les maîtriser nécessite un apprentissage.

Ne perdons donc pas de vue les autres pratiques qui contribuent quant à elles à éradiquer le défaut à la source :

  • Test Driven Developpement qui permet de couvrir très exactement le besoin sans code superflu, de concevoir nativement une solution ouverte aux tests, de réusiner le code afin de rendre ce dernier facilement maintenable.
  • Programmation en binôme qui permet de limiter les erreurs humaines et de trouver des solutions plus simples, faciles à maintenir (deux cerveaux valent mieux qu’un). Mieux vaut privilégier la programmation en binôme obtenant ainsi un feedback immédiat de la part de son pair (comme un pilote et copilote d’avion qui vérifient réciproquement leurs opérations) que la revue de code dont le feedback intervient après coup.
  • L’Intégration Continue qui permet de détecter et traiter au plus tôt les éventuelles régressions.
  • Energie et motivation : Une équipe se donne a fond lorsqu’elle est motivée. Cette motivation peut s’obtenir par une bonne utilisation du temps passé en dehors du boulot et une forte concentration au travail. Rentrer chez soi chaque jour à l’heure, passer du temps avec ses amis et/ou sa famille et avoir des activités permettant d’éviter de penser au travail. Faire de l’exercice, avoir une alimentation saine et bien dormir. Au travail, rester concentré, mettre son téléphone en mode silencieux et désactiver les alertes mail et tchat. Définir ensemble une vision, une « noble cause » (« Pourquoi on fait ce boulot ? ») et des valeurs fondamentales qui fédèrent. Les objectifs quant à eux doivent permettre de libérer la créativité des membres de l’équipe. Cf. article « The Art of Agile Development: Energized Work » et celui sur le Leadership Tribal.

User Stories et Cas d’Utilisation Textuels

User Stories

Commençons par un exemple de User Story.

[alert type= »info » show_close= »false »]

Exemple de User Story

ID : #33
Titre : Paiement par carte bleue

Résumé : En tant que client du site internet FoireAuLivre.com je peux payer ma commande par carte bleue afin de me simplifier la vie.

Notes :…

Tests d’acceptations :

  • Tester avec une carte bleue mastercard : OK
  • Tester avec une carte sofinco : KO
  • Tester avec une carte expirée : KO
  • Tester avec un numéro de carte incorrect : KO
  • Tester avec un montant supérieur à 100 € : OK
[/alert]

Notons l’absence de connotation technique et de détails d’IHM ainsi que l’utilisation d’un template de phrase permettant de se concentrer sur l’essentiel : « En tant que … je peux … afin de ».

Par ailleurs, une User Story se veut « INVEST » :

[list icon= »ok »] [list_item]Indépendante des autres User Story de façon à ce qu’on puisse les développer dans n’importe quel ordre. Evidemment, ce n’est pas toujours possible, mais il faut garder cet objectif à l’esprit pour savoir saisir ou créer les opportunités de rendre indépendante une User Story (des techniques de découpage peuvent aider).[/list_item] [list_item]Négociable au sens où elle n’est pas orientée « solution ». Autrement dit l’acteur métier porteur du besoin et le développeur ont toute latitude pour parvenir à la meilleure solution possible selon les ressources du moment.[/list_item] [list_item]Valeur : elle doit être porteuse de valeur métier.[/list_item] [list_item]Estimable par l’équipe de développement.[/list_item] [list_item]Small : une User Story doit être suffisamment petite pour être réalisée au cours d’une seule itération. D’autre part, plus une User Story est petite, plus l’estimation est précise et la planification aisée.[/list_item] [list_item]Testable afin de pouvoir vérifier la bonne couverture du besoin. Ces tests doivent être rédigés en amont des développements afin de piloter au mieux ces derniers.[/list_item] [/list]

Le recours à un support physique (format bristol A5 par exemple) présente des avantages notables :

  • Simplicité : en cours d’itération, le développeur souhaitant travailler sur une User Story, prend le carton associé et va voir (idéalement accompagné de son binôme de développement et d’un testeur) l’acteur métier pour discuter avec lui du besoin. Ce dernier se remémore rapidement le sujet en lisant le résumé de 1 à 3 lignes. Sans avoir besoin d’un PC, ils annotent le bristol pour par exemple ajouter sous la forme d’un test supplémentaire une règle de gestion découverte au cours de leur conversation. Le développeur repart avec son bristol qu’il pose à côté de son clavier. Pendant ses développements, en un coup d’oeil, il pourra trouver l’information dont il a besoin pour implémenter ses tests et la fonctionnalité.
  • Taille limitée : le format A5 est une bonne taille car elle oblige les rédacteurs à se concentrer sur l’essence du besoin. Si il n’y a plus assez de place, c’est peut être un bon indicateur révélant la nécessité de découper la User Story.
  • Planification plus facile : Pendant la réunion de planification d’itération, c’est plus simple de prioriser les User Story en étalant les cartons sur une table ou sur le sol et en les déplaçant de gauche (priorité haute) à droite (priorité faible). La encore, pas besoin de PC et vidéo-projecteur.

Comme dans le cadre de la spécification par l’exemple, les tests portés par la User Story permettent de piloter les développements par les tests. Laissant peu de place aux ambiguïtés et mauvaises interprétations du besoin. Là aussi, une fonctionnalité n’est pas considérée comme terminée tant que les tests inscrits sur la User Story ne sont pas tous passants. La technique des User Stories peut être utilisée seule selon le contexte du projet. Le processus associé ne sera pas très différent de celui déjà décrit.

Pour aller plus loin, l’ouvrage de référence est « User Stories applied » de Mike Cohn.

Cas d’Utilisation Textuels

Dans certains contextes exigeants, les User Stories ne peuvent pas être considérées comme des spécifications mais simplement comme un support transitoire et éphémère permettant de planifier plus facilement les itérations et piloter les développements par les tests. Dans ce cas, on peut utiliser les cas d’utilisation textuels en complément pour formaliser davantage les choses et apporter la cohérence d’ensemble. Le cas d’utilisation textuel n’est pas par définition un cas d’utilisation UML. L’UML est généralement considéré comme trop difficile d’accès pour un utilisateur ou le client (parfois même pour les développeurs non initiés).

Là encore, commençons par un exemple.

[alert type= »info » show_close= »false »]

Exemple de cas d’utilisation
Titre : Commande d’article(s)
ID : 45
Résumé : Ce cas d’utilisation décrit le processus de commande d’un ou plusieurs articles en partant de la recherche jusqu’à la confirmation du paiement.
Acteur concerné : Internaute
Pré-condition : L’internaute s’est authentifié sur FoireAuLivre.com.

Scénario nominal :

  1. L’internaute lance une recherche d’article.
  2. Il sélectionne l’article de son choix parmi les résultats affichés et l’ajoute à son caddie.
  3. L’internaute affiche son caddie, vérifie le montant à payer et choisit de payer sa commande.
  4. Il opte pour le paiement par carte bleue.
  5. Il saisit son numéro, la date d’expiration ainsi que le cryptogramme de sa carte bleue.
  6. Un message affiché sur le site interne lui confirme que le paiement a été accepté.
  7. L’internaute reçoit un email lui confirmant que sa commande est enregistrée et résumant le contenu de cette dernière.

Scénarios alternatifs :

  • 3.a L’internaute répète l’étape 2 ou 1 puis 2.
  • 4.a.1 L’internaute opte pour le paiement par Paypal.
  • 4.a.2 L’internaute saisit ses identifiants Paypal.
  • 4.b.1 L’internaute opte pour le paiement par chèque.
  • 4.b.2 Un message indique à l’internaute l’adresse à laquelle envoyer le chèque ainsi que le numéro de commande à joindre à ce dernier.
  • 6.a Le paiement à échoué, l’internaute en est informé.
[/alert]

Cet exemple est un cas d’utilisation plutôt « haut niveau ». On peut au besoin descendre un peu plus et détailler certaines étapes. Dans ce cas, on souligne généralement dans le cas d’utilisation « haut niveau » le mot clef de l’étape en question illustrant le plus le sous cas d’utilisation lié (exemple : « payer », « recherche »,…). On établit ainsi un lien hiérarchique entre le cas d’utilisation et ses sous cas d’utilisation. On peut ainsi établir une cartographie des cas d’utilisation sous forme d’arborescence afin de faciliter la recherche d’information.

Le périmètre fonctionnel d’une User Story est la plupart du temps inférieur à celui d’un cas d’utilisation « haut niveau ». Autrement dit, un cas d’utilisation peut contenir plusieurs User Story mais l’inverse est rare (à moins de rédiger des cas d’utilisation bas niveau décrivant des mécanismes invisibles pour l’utilisateur).

Pour aller plus loin, l’ouvrage de référence est « Rédiger des cas d’utilisation efficaces ».

Balle traçante

A défaut de trouver une métaphore moins morbide, la pratique suivante reprend les principes de la balle traçante.

Définition Wikipedia : Une munition traçante est un type de munition muni d’un dispositif pyrotechnique émettant de la lumière tout au long de la trajectoire vers la cible. L’ogive étant très visible à l’œil nu, elle permet au tireur de suivre la trajectoire de la balle par rapport à la cible afin d’apporter des corrections à sa visée.

Dans le cadre d’un projet de développement logiciel, la pratique de la « balle traçante » consiste à réaliser de A à Z au démarrage du projet une fonctionnalité clef. On réalise la conception graphique et ergonomique ainsi que les développements jusqu’à obtenir un feedback d’utilisateurs (ou représentants d’utilisateurs) à partir de la fonctionnalité concrète terminée. Nous adaptons ensuite cette fonctionnalité en fonction de ces feedbacks et utilisons cette dernière comme fonctionnalité de référence « éclairante ». C’est donc cette fonctionnalité qui porte les spécifications graphiques et ergonomiques. C’est a partir d’elle que l’on va dériver les autres subtilités graphiques et ergonomique des autres fonctionnalités.

Par la même occasion, cette pratique permet de valider ou affiner l’architecture et les technologies choisies. Par ailleurs, la pratique de la balle traçante peut s’étendre au processus de déploiement. A partir de cette fonctionnalité « terminée », nous pouvons dès maintenant automatiser la procédure de déploiement et l’éprouver sur tous les environnements dont on dispose. Nous réduisons ainsi très tôt les risques liés à l’architecture et au déploiement et réduisons par la même occasion le stress reposant sur l’équipe.

Pour aller plus loin

 

Exemple d’organisation projet Agile

Cet article n’a pas pour vocation de servir de référence mais plutôt d’inspiration. D’autant plus qu’une organisation projet Agile part généralement d’un cadre méthodologique tel que Scrum et mûrit empiriquement d’itération en itération. Chacun aboutit ainsi à une méthodologie sur mesure adaptée à son contexte. A aucun moment cette dernière n’est considérée comme finale.

Organisation

Rôles

Product Owner

Le Product Owner est le représentant du client, il :

  • Définit les fonctionnalités du produit.
  • Décide des dates de livraison et de leur contenu.
  • Est responsable de la rentabilité du produit (ROI).
  • Priorise les fonctionnalités en fonction de la valeur métier.
  • Ajuste les fonctionnalités et leur priorité avant chaque planification d’itération.
  • Accepte ou rejette les fonctionnalités réalisées.
  • Anime la réunion de planification de sprint.

Le rôle du Product Owner est assuré par un membre de l’équipe métier (MOA) et au besoin une assistance (AMOA).

Equipe d’assistance au Product Owner

Elle assiste le Product Owner et à ce titre peut intervenir dans le cadre des activités associées aux responsabilités de ce dernier.
Plus concrètement, elle :

  • Alimente et maintient le Product Backlog, et pré priorise les éléments de ce dernier.
  • Ajuste les fonctionnalités prioritaires du Product Backlog (candidates au périmètre du prochain sprint) et s’assure que les pré-requis aux développements associés seront disponibles en temps voulu (exemples : décisions métier, jeux de données du SI amont,…).
  • Rédige les User Stories associées aux fonctionnalités prioritaires et dessine au besoin des maquettes d’écran.
  • Répond aux questions soulevées par l’équipe de développement en cours de Sprint et complète au besoin les User Stories associées.
  • Vérifie en cours de Sprint la bonne couverture du besoin des fonctionnalités terminées en collaboration avec l’équipe de développement.
  • Rédige les plans de tests.
  • Participe à la réunion de revue de sprint au cours de laquelle, elle aide le Product Owner à accepter ou rejeter les fonctionnalités présentées.
  • Teste avant mise en production la conformité du produit dans son ensemble.

Scrum Master

Le Scrum Master appartient à l’équipe de développement (MOE), il :

  • S’assure que l’équipe est pleinement opérationnelle et productive.
  • Établit une collaboration étroite entre l’ensemble des rôles et fonctions.
  • Supprime les obstacles rencontrés par l’équipe de développement.
  • Protège l’équipe des interférences extérieures.
  • Assure le suivi du processus.

Equipe de développement

L’équipe de développement :

  • Réalise les fonctionnalités du produit.
  • Présente au Product Owner les résultats de son travail sous forme de démonstrations.
  • Maintient à jour les spécifications détaillées du produit.
  • Package et livre le produit.

Processus

Processus global

Vue d'avion du processus global

Vue d’avion du processus global

Processus de la méthode Scrum

Zoom sur le processus Scrum (sources des icônes des personnages : Mike Cohn)

Résumé

Le processus itératif et incrémental du projet structure le développement du produit en cycles de travail appelés « Sprints ». La durée de ces sprints est fixée à 2 semaines dans le cadre de ce projet. L’objectif générique associé à chaque sprint consiste à transformer les exigences constituant le périmètre de ce dernier en fonctionnalités utilisables.

Juste avant de démarrer un sprint, l’équipe de développement sélectionne les éléments de la liste ordonnancée des exigences (Product Backlog) qu’elle pense pouvoir réaliser dans le délais associé au sprint. Au cours de ce dernier, le Product Owner et l’équipe de développement collaborent étroitement pour atteindre les objectifs fixés. Chaque jour, l’équipe de développement se coordonne et mesure son avancement. A la fin du Sprint, elle présente les résultats de son travail au Product Owner et aux utilisateurs finaux sous la forme d’une démonstration des nouvelles fonctionnalités réalisées. Les feedbacks sont recueillis.

Juste après le Sprint, l’équipe de développement se réunit afin de tirer les leçons du sprint écoulé et étudie les moyens de s’améliorer. S’enchaine ensuite la planification du sprint suivant.

Processus détaillé

Le paragraphe suivant décrit dans l’ordre chronologique les étapes du processus.

Préparation

Avant le démarrage d’un Sprint, le Product Owner doit s’assurer que le Product Backlog (Liste des exigences attendues) est correctement ordonnancé en fonction de la valeur métier et du coût de chaque exigence. Pour les exigences dépourvues de coût, il peut solliciter l’équipe de développement afin de procéder à des séances d’estimation. Il participe à ces séances – assisté par son équipe – en répondant aux questions de l’équipe de développement. Il doit également s’assurer que le besoin associé aux exigences prioritaires du Product Backlog (candidates au périmètre du prochain Sprint) est suffisamment mûr (décisions métiers structurantes prises, besoin formalisé sous forme de User Stories,…).

Planification de Sprint

Le Product Owner et l’équipe de développement se réunissent afin de partager ou repartager ensemble la vision du projet ainsi que les objectifs associés aux éléments du Product Backlog. L’équipe de développement sélectionne ensuite les éléments du Product Backlog en commençant par le haut (exigences prioritaires) en fonction de sa capacité à faire. Enfin l’équipe de développement, découpe chaque exigence en tâches et estime le temps nécessaire à la réalisation de chacune d’entre elles. Ces tâches sont enregistrées dans le Sprint Backlog.

Sprint

Le sprint englobe les activités d’analyse, de conception, de test et de développement. Au cours de ce dernier l’équipe de développement soulève des questions métiers. L’AMOA répond aux questions (se retourne vers d’autres acteurs tels que la MOA si nécessaire) et complète les User Stories associées. L’AMOA vérifie en cours de sprint la bonne conformité de la fonctionnalité développée, émet au besoin des feedbacks qui permettront d’adapter la fonctionnalité.

L’équipe de développement se réunit chaque jour lors de la mêlée quotidienne afin d’évoquer le travail réalisé la veille, celui de la journée et soulever les obstacles rencontrés. Chaque membre de l’équipe actualise son « Reste A Faire » sur ses tâches en cours de manière à actualiser le graphique d’avancement du sprint. Ce point est limité à 15 minutes, d’autres acteurs du projet peuvent être présents mais seuls les membres de l’équipe de développement ont la parole.

Revue de Sprint

A la fin du sprint, l’équipe de développement présente au Product Owner accompagné par l’AMOA (et autres acteurs intéressés) les nouvelles fonctionnalités produites sous la forme d’une démonstration. Le Product Owner – avec l’aide de l’AMOA – accepte ou rejette les fonctionnalités présentées. Les feedbacks sont notés. En fonction des résultats présentés, le Product Owner peut demander une livraison du produit pour réaliser des tests de l’ensemble du produit en prévision d’une mise en production. Auquel cas, quelques jours de consolidation du produit en fonction des résultats de ces tests peuvent être nécessaires. Si le Product Owner ne demande pas de livraison, une nouveau sprint est planifié (cf. paragraphe « Planification de Sprint »).

Rétrospective de Sprint

Après la revue du Sprint, l’équipe de développement ainsi que le Product Owner se réunissent afin d’identifier les adaptations susceptibles d’augmenter sa productivité. Les choses qui fonctionnent, celles qui ne fonctionnent pas ainsi que les améliorations à apporter, sont identifiées dans cette réunion. Elle s’inscrit dans une démarche d’amélioration continue. Les idées de chacun sont mises à profit.

Synthèse des réunions

NB : les comités de pilotage ne sont pas décrits dans cette organisation. Ils diffèrent généralement assez peu d’une approche traditionnelle (exemple : comité de suivi hebdo et comité de pilotage mensuel). Il peut cependant être intéressant de se caler sur le rythme des sprints, voire de mutualiser les revues de sprint avec un comité de pilotage par exemple.

Planification de sprint

  • Objectif(s) : définir le périmètre et les objectifs du sprint puis découpage en tâches de développement.
  • Responsable : Product Owner.
  • Participants : Product Owner, ScrumMaster, équipe de développement.
  • Fréquence : Avant le sprint.
  • Durée maximale : 4 heures.
  • Document(s) en entrée : Product Backlog priorisé.
  • Document(s) en sortie : Sprint Backlog.

Mêlée quotidienne

  • Objectif(s) : coordination de l’équipe de développement, identification des obstacles qu’elle rencontre, mesure de l’avancement du Sprint.
  • Responsable : ScrumMaster.
  • Participants : équipe de développement, ScrumMaster, Product Owner/AMOA (optionnel).
  • Fréquence : quotidienne.
  • Durée maximale : 15 minutes.
  • Document(s) en entrée : Sprint Backlog.
  • Document(s) en sortie : Sprint Backlog et graphique d’avancement mis à jour.

Revue de Sprint

  • Objectif(s) : présentation des fonctionnalités produites au cours du Sprint au Product Owner et utilisateurs finaux, réception des feedbacks.
  • Responsable : Equipe de développement.
  • Participants : équipe de développement, Product Owner, ScrumMaster, utilisateurs finaux, invités.
  • Fréquence : A la fin du Sprint.
  • Durée maximale : 2 heures.
  • Document(s) en sortie : Liste des feedbacks.

Rétrospective de Sprint

  • Objectif(s) : améliorer la productivité (vélocité) de l’équipe de développement.
  • Responsable : ScrumMaster.
  • Participants : équipe de développement, ScrumMaster, Product Owner/AMOA (optionnel).
  • Fréquence : Après la revue de Sprint.
  • Durée maximale : 1h30.
  • Document(s) en sortie : compte rendu de réunion (bilan de Sprint + plan d’actions).

Artefacts

Product Backlog

Le Product Backlog centralise la liste des exigences attendues (fonctionnalités, exigences non fonctionnelles, défauts à corriger). Le Product Owner s’approprie ce Product Backlog et priorise ses éléments en fonction de la valeur métier et du coût estimé de chacun. L’unité de coût est le « point ». Le choix d’une telle unité permet d’éviter la confusion entre délais et coût, souligne le caractère « estimatif » (imprécis) et facilite la planification de release et de sprint. Ces estimations sont réalisées dans un premier temps à partir d’un besoin peu détaillé, il peut être révisé au cours de la planification d’itération en cas d’écart par rapport aux hypothèses établies lors de la première estimation.

Sprint Backlog

Le Sprint Backlog comporte la liste des tâches du Sprint (son périmètre donc) ainsi que la charge de travail associée à ces dernières. Chaque jour, le Reste A Faire de chaque tâche est actualisé par l’équipe de développement afin de tracer le graphique d’avancement de Sprint.

Tableau des tâches

Ce tableau comporte la liste des tâches du Sprint Backlog, il permet à l’équipe de développement de se coordonner. Il comporte généralement 4 colonnes : « A faire », « En cours », « A vérifier », « Terminé ». Il est mural et simple à interpréter, permettant à n’importe quel acteur du projet de connaître en un coup d’œil l’avancement « temps réel » du Sprint.

Graphique d’avancement de Sprint

Tout au long du Sprint, n’importe quel acteur du projet peut consulter la progression de l’équipe de développement grâce au graphique d’avancement actualisé quotidiennement. Ce graphique indique l’évolution du Reste A Faire (généralement exprimé en heures) en fonction du temps.

Spécifications

Introduction

Partant des constats suivants :

  • Les besoins ne sont pas complètement connus tant qu’un projet n’a pas débuté
  • Les utilisateurs savent ce qu’ils veulent uniquement après avoir vu une première version du logiciel (Principe d’incertitude du besoin de Humphrey).
  • Les besoins changent souvent durant le processus de développement du logiciel (Principe d’incertitude de Hadar Ziv – 1996)
  • Spécifier intégralement un système interactif est impossible (Lemme de Peter Wegner – 1995)

L’approche du projet, concernant les spécifications, consiste à lisser le travail de rédaction des spécifications tout au long du projet et à leur accorder une valeur contractuelle faible. Privilégiant plutôt la réalisation au plus tôt d’un logiciel qui fonctionne à la fin de chaque sprint grâce à une collaboration client/fournisseur (métier/technique, MOA/MOE) étroite.

Processus

Liste des besoins

Le Product Owner établit et maintient la liste des exigences attendues (fonctionnalités, exigences non fonctionnelles ou défauts à corriger). A ce stade, le niveau de précision du besoin est faible. Chaque exigence peut se résumer à 1 à 3 phrases en moyenne. La liste des exigences vient alimenter le Product Backlog.

Besoins prioritaires

Avant la planification d’un nouveau Sprint, le Product Owner approfondit le besoin associé aux fonctionnalités prioritaires (en tête de liste du Product Backlog). Une bonne pratique consiste à rédiger pour chaque fonctionnalités attendue une User Story (le verso décrit le besoin et le recto énumère les conditions ou test d’acceptation permettant de vérifier la couverture du besoin). A l’issue de la réunion de planification de Sprint, le périmètre de ce dernier est fixé. Il correspond à la liste d’exigences sélectionnées par l’équipe de développement matérialisées par un ensemble de User Stories.

Conception/Développement

Une fois le Sprint démarré, le développeur s’approprie la User Story qui servira de support de communication entre lui et le rédacteur de la User Story (Product Owner, AMOA ou utilisateur). Au fil des questions soulevées et des réponses apportées, la User Story se complètera jusqu’à la fin des développements associés.

Mise à jour des spécifications

A l’issue du Sprint, l’équipe de développement, met à jour la documentation du produit.

Gestion des changements

Le besoin peut changer tout au long du projet (y compris tardivement).
Notamment dans les cas de figure suivants :

  • Découverte d’un nouveau besoin correspondant une nouvelle fonctionnalité à réaliser.
  • Modification d’une fonctionnalité déjà réalisée.
  • Retrait d’un besoin finalement inutile ou infaisable.

Principe de troc

Principe de troc d'exigence pour la gestion des changements

Principe de troc d’exigence pour la gestion des changements

Pour rappel, le Product Backlog centralise l’ensemble des exigences (ou besoins) attendues du projet. Chaque élément de ce dernier comporte une estimation de coût en points. La somme des estimations permet donc de déterminer le coût du projet (estimation).

Si les contraintes de budget voire de délais du projet sont fortes ; en cas de découverte d’un nouveau besoin ou de modification d’une fonctionnalité déjà réalisée ; un nouvel élément est ajouté au Product Backlog en échange du retrait d’un autre de même coût et de valeur métier plus faire (cf. bas de la liste). Inversement dans le cas d’une disparition d’un besoin finalement inutile, l’élément associé est retiré du Product Backlog libérant ainsi une provision pour de nouveaux besoins ou futures modifications.

Changement pendant un Sprint

Le périmètre d’un sprint fixé à l’issue de la réunion de planification ne doit pas changer. En cas de force majeure, le Product Owner peut annuler le Sprint en cours, ce qui peut engendrer des conséquences coûteuses. Les développements en cours sont stoppés, l’équipe de développement est coupée dans son élan. Un nouveau sprint doit alors être planifié.

Gestion des défauts

Processus de gestion des défauts

Un défaut qui n’a pas pu être corrigé pendant le Sprint est enregistré dans le « Bug Tracker » par le testeur. L’AMOA et l’équipe de développement qualifient ensemble les défauts constatés afin de savoir si une correction et réellement nécessaire et possible en fonction des informations renseignées par le testeur.

Les défauts confirmés sont ensuite priorisés par le Product Owner assisté par l’AMOA. Le Product Owner identifie la liste des défauts à corriger dans le prochain sprint. Il communiquera cette liste à l’équipe de développement lors de la réunion de planification de sprint au même titre que les exigences prioritaires à réaliser. Les défauts critiques (bloquant le travail de test AMOA ou présentant un risque majeur dans l’utilisation du produit prochainement mis en production) peuvent être ajoutés au besoin au périmètre du sprint en cours.

Processus de gestion des incidents de production

Les incidents de production peuvent être pris en compte par l’équipe de développement dans le Sprint en cours.

Planning

Macro Planning Agile

Macro planning Agile : « Une Release par trimestre »

Le projet est piloté par la valeur et les délais. Chaque année compte 4 releases de 3 mois afin de créer un rythme régulier, favoriser la naissance des automatismes projet, réduire l’effort de planification du projet et de coordination des acteurs internes et partenaires du projet. Ce principe de release de même durée permet également de construire des indicateurs plus facilement comparables afin d’améliorer régulièrement le processus de développement et l’organisation.

Les releases peuvent donc être considérées comme des trains partant et arrivant à heure fixe sans décalage possible. Le périmètre est donc la seule variable d’ajustement, afin de sécuriser la qualité, le budget et les délais.

Bonnes pratiques

Planning Poker

Le Planning Poker est une technique d’estimation de coût d’exigences. Cette technique se pratique en équipe et permet de procéder à des estimations rapides et aussi précises que possible selon le niveau de précision du besoin disponible.

Au cours des séances d’estimation, le Product Owner (assisté de l’AMOA au besoin) soumet une à une à l’équipe de développement les exigences dont il souhaite connaître l’estimation de coût. Il répond aux questions de l’équipe de développement qui en cas d’absence de réponse (besoin encore flou) établie des hypothèses. Les estimations de coût (dont l’unité est le point) ainsi obtenues viennent alimenter le Product Backlog et aideront le Product Owner à prioriser ses exigences. La technique de Planning Poker peut également être utilisée pour estimer en équipe (Product Owner, AMOA, utilisateurs, marketing,…) la valeur métier en points des exigences du Product backlog.

En savoir plus

User Story

La User Story est une technique de spécification permettant de synthétiser le besoin lié à une fonctionnalité en quelques phrases courtes et simples utilisant exclusivement le vocabulaire métier (absence de connotation technique ou de description d’IHM). D’autre part, une User Story énumère les tests fonctionnels connus à date permettant de vérifier la couverture du besoin de la fonctionnalité associée.

Les avantages sont nombreux :

  • Une User Story est compréhensible rapidement aussi bien par un développeur que par un utilisateur,
  • Elle favorise les interactions entre développeur et rédacteur, favorisant ainsi une bonne compréhension du besoin (communication face à face),
  • Les tests énumérés renforcent la qualité des développements.

En savoir plus

Pratiques de développement

Intégration continue

L’intégration continue a pour rôle de détecter au plus tôt les défauts d’intégrité du code (plus un défaut est corrigé tôt moins il coûte cher).

Elle est matérialisée par un outillage logiciel récupérant le dernier code disponible sur le gestionnaire de version, compilant ce dernier et exécutant les tests unitaires existants. Il réalise cette tâche automatiquement à chaque modification du code soumise au gestionnaire de version ou plusieurs fois par jour. En cas de défaut détecté, une alerte est déclenchée (email, signal sonore ou visuel,…). Cet outil permet donc de renforcer la qualité des développements et de favoriser le travail indispensable de refactoring régulier du code.

En savoir plus

Développements pilotés par les tests

Le développement piloté par les tests consiste à sensibiliser le développeur sur les tests en amont de ses développements. Concrètement, la User Story associée à une fonctionnalité à développer liste les tests qui permettrons de confirmer que cette fonctionnalité couvre effectivement le besoin. Cette approche limite les erreurs d’interprétation du besoin du développeur.

Programmation en binôme

La programmation en binôme consiste à rassembler deux développeurs sur un même poste de travail pour accomplir une même tâche de développement. Cette approche apporte plusieurs avantages :

  • Permet de réaliser efficacement des développements pointus,
  • Meilleure qualité du code (peu de défauts, uniformité, maintenabilité),
  • Rapidité de développement,
  • Rapidité de montée en compétences (cf. nouveaux développeurs, en particulier junior).

En savoir plus

Annexes

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