Développement de projet guidé par le comportement – Printemps agile 2015

David et Pierre, de KNP Labs à Nantes, nous ont présenté le technique du développement de projet guidé par le comportement, Behavior Driven Development (BDD), lors du Printemps agile 2015.

Les 3 grandes questions qu’ils se posent sont les suivantes :

  • Comment décrire les besoins d’un projet en évitant un énorme cahier des charges exhaustif ?
  • Comment utiliser le même langage entre l’équipe du marketing et l’équipe de développement afin d’éviter les incompréhensions ?
  • Comment accélérer le début du projet afin de développer et tester une fonctionnalité le plus tôt possible ?

C’est notamment suite à cette conférence que je me suis intéressé à RSpec, celui-ci se définissant comme un framework de test guidé par le comportement pour Ruby.

La vidéo de leur présentation est disponible sur le site de KNP : KNP au Printemps Agile : La BDD expliquée à Michel, le maçon

Les TDD en toute agilité, par Julien et Pierre-Olivier – Printemps agile 2015

Notre équipe a été invitée à faire une présentation durant ce Printemps agile 2015. Julien et Pierre-Olivier se sont lancés et ont proposé d’aborder la technique du TDD, ou Test Driven Development (développement piloté par les tests en français), technique que l’équipe pratique quotidiennement.

Juste après avoir (peu) mangé, Pierre-Olivier et Julien ont donc présenté la technique du développement piloté par les tests. Ils ont montré l’intérêt de cette technique et ont, à travers un live-coding, expliqué la façon dont nous la pratiquons au sein de l’équipe.

Les TDD en toute agilité
Pierre-Olivier et Julien nous présentent le contenu de leur présentation.

La qualité des questions posées à la fin de la présentation a montré l’intérêt porté par l’assistance à cette présentation. Les questions ont permis d’approfondir quelques points abordés succinctement et d’élargir le dialogue aux tests d’intégration, sujet qui n’avait pas été développé durant la présentation, et au développement de tests automatiques pour des applications existantes non testées. Ne pratiquant pas les tests d’intégration, Pierre-Olivier et Julien ont laissé la parole à Frédéric, présent dans l’assemblée, qui a évoqué les deux solutions Selenium et Nagios. La personne s’étant questionnée sur la refonte d’applications non testées a été invitée à suivre la présentation de Mathieu Sadouni et Pierre-Emmanuel Fringant intitulée « Sécuriser une refonte avec le Golden Master Testing » se déroulant juste à la suite de celle-ci.

Les slides de la présentation « Les TDD en toute agilité » sont disponibles à l’adresse : http://slide.julien-anne.fr/les-tdd-en-toute-agilite

Systémique, par Rémy Génin – Printemps agile 2015

Rémy Génin nous a présenté la « Systémique », une séance riche voir très riche. La systémique est une approche au même titre que l’agilité. Il a donc tout au long de la présentation fait un parallèle entre ces 2 approches similaires mais pas identiques, et cependant compatibles. La systémique a été élaboré en 1958.

Premier point commun, ce sont toutes deux des approches empiriques, elles se pratiquent en faisant, on teste, on essaie, on change, on revient en arrière, …

Qui dit systémique dit système. Un système est un ensemble d’éléments en interaction pour un objectif commun.

Les fondations sont la relation entre les différents éléments, la qualité individuelle des personnes passe après la relation.

Il y a toujours une finalité positive à toute action réalisée, mais on ne la voit pas toujours de notre point de vue. Il faut alors recadrer sa vision pour trouver cette finalité positive et ainsi pouvoir discuter avec la personne a l’origine de l’action, si celle-ci est négative pour le système.

La systémique lutte contre les procédures, pas contre les processus. Les procédures sont les chemins qui permettent d’atteindre un objectif, ils n’ont pas besoin d’être définis. Les individus savent quel chemin prendre et ils peuvent même le modifier pour le rendre plus efficace. Le processus quant à lui indique un but, un objectif. Ce dernier est suffisant pour les éléments du système.

Le principe de totalité nous indique que le tout est supérieur à la somme des partis, lors du binômage, certains disent que 1+1=3. L’interaction des 2 premiers individus génère les idées qui auraient pu être apporté par une 3e personne, ce qui est un gain énorme de productivité. Lorsque vous êtes 6 répartis en 3 binômes, vous pouvez quasiment atteindre la productivité de 9 personnes travaillant seules.

Les systèmes sont toujours englobés par un système plus grand, l’objectif du système le plus englobant prime sur l’objectif du système englobé. Si une action apporte un bénéfice à un service mais devient négatif pour une entreprise cette action doit être annulée.

La systémique se base aussi sur le concept de rétroaction. Le postulat comme quoi une cause entraîne un effet puis une fin est faux. Pour la systémique, une cause entraîne un effet qui entraîne un effet qui entraîne un effet … de façon infinie.

Le « Pour quoi ? » (dans quel but ?) est important, le « Pourquoi ? » (la cause) l’est moins.

Pour résoudre un problème, il faut un mouvement dans le système, cela entraînera un changement qui peut permettre de résoudre un souci.

Mais attention, un système répond au principe de l’homéostasie : Il cherche toujours un équilibre et se stabilise. Si le changement est trop superficiel, il sera absorbé par le système et celui-ci reviendra à son état d’origine.

Un autre principe est que la réalité est construite environ 30% provient des sens (réalité de première ordre commune à tous) et 70% environ provient de nos souvenirs et expériences passées (réalité de second ordre propre à chaque individu). Le but est d’agir sur cette réalité de second ordre en élargissant notre vision en changeant de pont de vue et en agissant sur ce que perçoivent les individus et non ce qu’ils sont.

La systémique donne aussi des retours rapides. Si le message n’est pas compris il faut le reformuler pour s’adapter à son interlocuteur. Cela présume que l’interlocuteur ce sente assez en confiance pour indiquer qu’il n’a pas compris certaines choses.

Afin de mieux comprendre ce que perçoit notre interlocuteur, nous devons changer notre façon de penser grâce à un recadrage en ouvrant. Il faut éviter les prophétie auto-réalisatrice négative, si on dit à une personne « tu es mauvais », elle le sera.

Rémy nous a ensuite invités à regarder une conférence TED sur l’éducation positive.

Il indique que la systémique n’est pas un système binaire bien ou mal mais un système ou cela peut être bien et mal.

Afin de modifier un système, il existe deux types de changements :

  • Le type 1 : Adapter les règles existantes. Il est simple et indolore.
  • Le type 2 : Plus contraignant : remplacer les fondamentaux. Cela nécessite de l’apprentissage.

Cela doit toujours se passer dans le respect et l’écoute de l’avis de chacun des éléments du système.

Les outils pour mettre en mouvement le système et ses acteurs sont divers et variés :

  • Le questionnement
  • La réflexion
  • Le silence permet de prolonger sa réflexion

Ces outils permettent aux acteurs de trouver LEURS solutions et non pas les miennes. Elles seront donc plus facilement acceptées, manipulation positive.

Il faut susciter le désir. Être convaincant ne suffit pas, il faut montrer en quoi le progrès est positif. Il faut montrer le chemin et non pas l’emprunter à la place des personnes. Il faut se donner rendez-vous à un point (objectif – vision). L’important n’est pas le moyen de s’y rendre mais bien de s’y rendre.

Il faut, à intervalles réguliers, faire un état des lieux des points qui fonctionnent bien et un ce qu’il faut améliorer.

Explorer les solutions dans les expériences de chaque éléments du système pour voir si elles peuvent répondre au besoin du moment.

Ne pas hésiter à faire rêver, cela aide les personnes à passer le pas du changement. Recadrer en utilisant le « et » pas le « ou ». Imagine le pire est aussi un moyen de sauter le pas du changement, si le pire n’est pas trop atroce ;). Dire que l’on a une solution sans la dire, cela invite les gens à réfléchir en se disant qu’une solution existe, et qu’ils leur faut la trouver. Cela retourne de la manipulation bienveillante car réalisée pour les autres et non uniquement soi. Il faut cependant toujours s’adapter au contexte et non partir d’une base inexistante.

La finalité est le maître mot de la systémique : sans vision les personnes ne pourront comprendre l’intérêt du changement.

Les bonnes intensions ne suffisent pas, il faut réaliser les actions qui vont avec. Il n’y a pas forcément 1 ou 2 solutions mais peut être une 3e. Essayer d’aller dans le sens de l’interlocuteur pour comprendre son point de vue et voir comment ce point de vue peut s’intégrer dans le système.

C’est par le système auquel il appartiennent que les individus se définissent, il est donc important que celui-ci soit bâti avec eux (ex: un service).

Voici pour la présentation sur la systémique, forte intéressante et effectivement, elle partage pas mal de notions avec l’agilité.

Cessons les estimations ! par Frédéric Leguédois – Printemps Agile 2015

Frédéric Leguédois est un agiliste évangéliste, libriste et geek humaniste. Au quotidien, il anime des équipes de développement logiciel.

Premier rappel : les coûts d’un projet sont les charges, le délai de réalisation et la qualité de finition. Un coût peut être modulé à condition d’affecter les deux autres. En Agilité, la qualité est le coût non négociable d’un projet, ce qui se traduit le plus souvent par un étalement dans le temps afin de conserver des charges raisonnables.

Cet étalement est d’ailleurs préconisé par l’intervenant, au travers d’un modèle économique basé sur l’abonnement, rendu possible par des livraisons fonctionnelles fréquentes.

Ce modèle raisonne sur la nature du métier et s’oppose à la rédaction préalable de cahier des charges pour les raisons suivantes :

  • Un cahier des charges est rédigé en amont du projet, par des personnes qui ne sont bien souvent pas développeurs, qui ne peuvent ni estimer le travail à réaliser, ni anticiper la complexité d’une création nouvelle
  • Un cahier des charges comporte en conséquence des estimations de coûts et de temps imaginaires, qui sont néanmoins acquis comme Vérité
  • Par la contractualisation des pénalités de retard, l’équipe de développement reçoit une pression anti-qualitative qui génère la dette technique
  • Annoncer un délai annihile la capacité des développeurs à prendre des initiatives, pour automatiser, refactoriser, optimiser, et à être moteurs
  • L’équipe réalise le projet, mais si elle est considérée en retard sur la prévision arbitraire qui lui est appliquée, elle se démotive (cercle vicieux)
  • Ce type de projet entraine automatiquement un perdant : le prestataire ou le client arnaque l’autre, car la prévision de délai est fausse

Pour Frédéric Leguédois, le Planning Poker permet bien d’estimer à 15j la complexité des tâches à réaliser mais demande plusieurs itérations. Cette méthode ne permet toujours pas d’annoncer une prévision de coût ni de temps en amont du projet, qui sont la raison même de consommer du temps et de l’argent à réaliser des estimations.

En revanche, les estimations mesurent si les gens travaillent, ce qui est biaisé et faux à la fois. Tenir un délai n’est pas synonyme de travailler proprement, mais ne pas tenir un délai permet de désigner un ou plusieurs coupables.

L’intervenant constate que s’il est impossible d’estimer quelque chose qu’on fait pour la première fois, on peut mesurer ce qui est reproductible et en déduire une estimation, bien que cette méthode ne soit pas réceptive au changement.

Si Frédéric n’aime pas les estimations, c’est qu’il estime qu’elles créent du retard là où il y a des gens qui travaillent, alors que prendre du temps est un investissement dans l’amélioration continue pour gagner en efficacité au fil du temps. Estimer est donc contre-productif.

Une constatation simple est ce qu’attend le client : être livré. Dès lors, des estimations non fiables suffisent, réalisables non pas en amont mais tout au long du projet, en prenant des mesures sur le travail réalisé.

L’intervenant présente ainsi différentes approches pour amener le client à dévoiler ses motivations de délai : est-ce une contrainte financière ? Légale ? Arbitraire ? Quelle serait la gravité de ne pas tenir le délai face au gain de fonctionnalités dans le MVP ?

Coopérer avec ses partenaires évite de créer des conflits qui servent notamment la concurrence, en lui laissant le temps de prendre de l’avance.

La solution avancée repose donc sur un modèle itératif, par exemple mensuel, où l’équipe rencontre le client pour lui présenter l’évolution du produit en production et recueillir ses nouvelles demandes.

La vision du client évolue avec son produit, ce qui lui offre de la flexibilité mais aussi la possibilité de contrôler le travail livré : le client et le prestataire ont un intérêt convergent à collaborer.

Dans ce modèle par abonnement, le prestataire doit tout faire pour conserver un client satisfait. En lui offrant la possibilité de rompre le contrat à tout moment, il créé la confiance nécessaire pour que le client se sente d’égal à égal, et que ce dernier puisse faire pression (suspension du contrat) si le travail ne correspond pas à ses attentes.

La création de logiciel est souvent illimitée dans le temps, il peut être judicieux d’offrir ou d’avancer la première semaine de travail au client afin de le mettre en confiance. Le prestataire conserve la possibilité de rompre à tout moment avec un client qui serait malhonnête.

Sophrologie et pensée Agile, par Loïc Rabault – Printemps Agile 2015

Après des années de pratique des nombreuses méthodes de relaxation, Loïc Rabault les décrit comme les multiples traductions d’un même livre. C’est de cette manière que son choix s’est arrêté sur la sophrologie, la plus complète selon lui.

La sophrologie développe la conscience de façon à harmoniser le corps et l’esprit, en chassant peurs, stress et tensions.
Source : Doctissimo

La sophrologie est une science de développement de la conscience positive. Le médecin psychiatre Alphonso Caycedo a élaboré la sophrologie en 1960, à partir des connaissances occidentales en relaxation, en hypnose et des techniques traditionnelles asiatiques (yoga, bouddhisme, méditation zen).
Source : Zen Conseil (Loïc Rabault)

L’intervenant évoque le stress comme une notion n’étant ni positive, ni négative : c’est un état de fait qui est spécifique à l’individu, relatif aux évènements vécus, qui évolue sans être toujours reproductible dans des situations semblables. Le stress est finalement nocif sur la durée et dans son intensité, et peut être généré par le changement.

La sophrologie fait parti des thérapies psychocorporelles qui agissent sur 3 dimensions : les sens, les sensations corporelles et les émotions.

Accompagner la transition agile d’un grand projet agile par Christophe Addinquy – Printemps Agile 2015

L’intervenant de cette conférence, Christophe Addinquy,  a abordé 12 leçons apprises lors de la transition agile du grand projet Linky, en y associant des conseils.

      1. L’immersion agile
        • pas facile, pas naturel
        • une journée d’immersion : ateliers, jeux, discussions pour appréhender les mécanismes de l’agilité
      2. Commencer lentement et délibérément
        • qualité = les bons gestes, du code testé
        • les premières itérations : focaliser l’attention sur la qualité et pas le nombre de stories réalisées
        • /!\ équipes cherchent à aller vite quand même
      3. Le droit à l’erreur
        • rassurer, logique d’expérimentation
        • erreur = opportunité d’apprendre quelque chose
        • laisser l’erreur arriver car on apprend par nous-même
      4. Les tests d’acceptation
        • avant de coder
        • spécifications avec de vraies valeurs
        • permet de trouver des bugs en les écrivant
        • créer des compréhensions partagées avec les équipes fonctionnelles, développeurs…
      5. La posture du management
        • pas le droit de dire aux personnes comment elles doivent faire
        • manager : porteur de l’objectif, de la vision et du sens. Il est responsable du cadre (moyens, motivation)
      6. Veiller à l’auto-organisation
        • écouter et surveiller les phrases comme « on m’a demandé que »
      7. Craftmanship
        • la qualité du code = pré-requis de l’agilité
        • 3 axes : facteurs externes (coding dojo), injecter du savoir-faire dans les équipes (binômage, refactoring) et créer de la masse critique pour la qualité du code (augmenter le nombre de personnes agiles pour faire basculer la balance de l’autre côté)
      8. Le fond et non la forme
        • « Comment » (=folklore) : post-it, rôles, cérémonies
        • « Pourquoi » : collaboration, feedback, implication, transparence
      9. Apprendre à s’améliorer
        • amélioration continue
        • rétrospective : actions faisables, review des actions précédentes
        • pendant l’intégration : action n’importe quand
      10. L’architecture compte !
        • importance du feedback
        • ne pas regarder seulement les fonctionnalités, mais comment travailler avec au jour le jour, qu’on peut le tester
      11. Off/on : comment faire la transition agile ?
        • par petits pas : apporte une confusion j’y suis / j’y suis pas
        • bien si brutale
        • autonomie de l’équipe
        • terminer un sprint avec un livrable, des tests dans l’itération
        • pas de challenges trop élevés
      12. Parfois il faut plonger pour mieux réussir
        • quand on a compris, on ne fait plus appel à l’aide
        • on ne peut pas forcer les gens à écouter
        • phase de dégradation après la mise en place mais on remonte toujours, elle est plus ou moins longue, c’est plus facile à expliquer après cette phase

// Une interface doit être facile à bien utiliser et difficile à mal utiliser.

// Faites attention à ce que vous demandez, vous risquez de l’obtenir

        • pas de mesure de vélocité car sinon rapidité au lieu de la qualité
        • nombre d’indicateurs le plus limité possible (=1), ils doivent permettre de prendre une décision (=indicateur actionnable)

Outils et pratiques pour mieux travailler ensemble ! par Simon Jaillais & Aurélien Morvant – Printemps Agile 2015

Conférence présentée par Simon Jaillais et Aurélien Morvant ayant pour but de nous montrer des ateliers pour accompagner les gens dans le changement.

Fonctionnement

Pour commencer, ils nous ont présenté le fonctionnement des ateliers. Voici quelques idées à retenir pour une bonne organisation :

Innovation game

  • commencer et terminer à l’heure
  • respecter celui qui parle
  • une conversation à la fois
  • l’opinion de chacun compte

Pratique des 7P

Peu d’espoir quand on est dans l’improvisation, un bon atelier demande 70% de préparation.

  • Product : qu’est-ce que j’attend à la fin de l’atelier ?
  • Purpose : quels sont les objectifs ?
  • People : qui va participer (rôles, préparation, déléguer – time keeper, scribe) ?
  • Practices : quelles sont les pratiques ?
  • Preparation : préparations (post-it, vidéoprojecteur…)
  • Process : que doit-on mettre en œuvre ?
  • Pitfalls : quels sont les risques associés (distances géographiques des participants) ?

Ensuite, Simon et Aurélien ont proposé aux participants de choisir un atelier parmi ceux proposés. Pour l’atelier sélectionné, ils nous ont proposé un déroulé composé d’un certain nombre de pratiques collaboratives. Voici deux ateliers choisis.

Résolutions des problèmes par la créativité

Ice breaker : alphabet des concepts

  • une question à poser au groupe et chacun répond avec un mot correspondant à une lettre en donnant la définition de ce mot
  • phase de réflexion individuelle avant celle de réflexion en groupe
  • prendre la température du groupe

Techniques de créativité

  • Purge : sortir toutes les idées sur un post-it ou sur des grandes feuilles avec des dessins
  • Analogies : donner des contextes pour lesquels on peut rencontrer le même problème (=phase de projection). Pour chaque environnement, ramener à notre contexte (=phase de convergence)

QQOQCP : plan d’actions

  • Quoi ? Qui ? Où ? Quand ? Comment ? Pourquoi ?
  • caractériser les actions avec les questions / réponses
  • une action (=ce que je peux faire) non portée = une discussion
  • chaque personne qui ressort à une action

Cohésion d’équipe

L’arbre à personnages (=15 min)

  • plusieurs personnages dans un arbre situés à des hauteurs différentes, dans des diverses positions (de dos, seul, par groupe, en train de sourire, de tomber…)
  • chaque personne cherche sa position dans l’arbre
  • chacun vient se positionner sur l’arbre (gommettes) et explique pourquoi devant le groupe
  • caractériser l’état d’esprit pour l’animation
  • /!\ poser une question avant d’utiliser l’arbre

La crevasse (=30 min)

  • jeu en binôme, les personnes s’appuient sur les mains de l’autre en face à face (pour faire un pont) et on doit avancer le long de deux lignes droites
  • l’un sans l’autre c’est difficile de travailler
  • confiance aille dans les deux sens

Conclusion

La co-construction + cohésion est une motivation pour les équipes. Les pratiques collaboratives apportent beaucoup de valeurs, sont des bons moyens de polliniser et restent des moments privilégiés.

Software Craftsmanship, par Antoine Vernois – Printemps agile 2015

Antoine Vernois a commencé la journée par une présentation nommée « Software Craftsmanship », une session sur le développement mais le développement bien fait et sur le mouvement de l’artisanat logiciel. Cette même conférence a été filmée lors de l’agile tour de Montpellier en 2013.

Antoine se définit comme un artisan développeur, une notion très intéressante au sein de laquelle la qualité n’est pas une option.

Antoine aborde ensuite la métaphore de la dette technique, qui par analogie explique que si on ne fait pas bien les choses dès le début on prend plus de temps par la suite (comparable aux intérêts en finance) et que si ce point n’est pas corrigé rapidement on se retrouve très vite à ne payer que des intérêts ou à un figement de l’application pour éviter de payer ces intérêts. Cette analogie est un concept bien connu dans notre service. D’ailleurs, nous essayons de nous améliorer en permanence afin de ne pas être prisonnier de cette dette technique.

Antoine a ensuite évoqué le principe de Peter et le fait que cela n’est pas immuable. Il n’appartient qu’à nous d’éviter ce principe mauvais pour les entreprises.

Il a également parlé du fait que les artisans choisissent eux même leurs outils selon le contexte, et du fait qu’il faut investir un peu de temps chaque jour pour accélérer le quotidien en automatisant les tâches automatisables. Le retour sur investissement est alors rapide.

Antoine a aussi évoqué un auteur et développeur américain Robert C. Martin, co-auteur du fameux Manifeste Agile. Voyant que certains interprété le Manifeste Agile de manière inexacte (« geule de bois agile »), il l’a étendu en créant le manifeste pour l’artisanat logiciel, ou « Manifesto for Software Craftsmanship ». Il a aussi publié des livres comme Clean code, au sein desquels il dit que « le seul moyen d’aller vite, c’est de faire bien », encore une fois la qualité n’est pas une option et ne peut pas en être une.

Antoine considère qu’il faut faire un code propre notamment pour les personnes qui passeront après nous sur les projets, cette notion me semble plus qu’indiqué lorsque l’on travaille de façon agile en équipe.

Il nous indique aussi que pour lui un développeur n’est pas juste une personne qui écrit du code, cela n’est pas le premier objectif de notre métier. L’objectif de notre métier et de créer des applications et pour cela nous écrivons du code mais si demain nous pouvons réaliser une application sans écrire du code il y a de forte chance que les développeurs n’écrivent plus de code.

Il a également repris différents points du manifeste agile pour les expliquer comme notamment les relations entre les individus et le partage de connaissance avec des rencontres entre professionnels et/ou passionnés autour d’évènement comme le Printemps agile 2015. Ceci dans le but de progresser ensemble en partageant les bonnes pratiques et les expériences de chacun.

Enfin, Il invite les développeurs à choisir leurs outils de travail et leur plan de carrière. Ils doivent être les plus à même de pouvoir le faire. Si ce n’est pas le cas, Antoine invitent clairement à regarder ailleurs, « changer de boîte ». En effet, dans notre domaine il y a des postes à pourvoir.

Antoine s’appuie sur des citations bien trouvées comme « la différence entre la théorie et la pratique, c’est qu’en théorie il n’y en a pas ». Il relativise la théorie et explique ainsi que les personnes ayant de l’expérience, terrain j’entends, sont plus à même de prendre des décisions dans la conception d’un logiciel qu’une personne qui écrit la théorie (« architecte logiciel »).

Il promeut le simple au lieu du complexe qui n’apporte rien, pour Antoine un professionnel fait simple.

Par la suite, il explique aussi que dans notre métier on ne s’entraîne plus, au sens où lorsque l’on code il y a toujours un but de production derrière, il pense que cela est négatif pour notre « art » dans le sens où on ne se donne jamais le droit à l’échec sans conséquence (financière, …).

Il termine sa présentation par expliquer que si l’on veut changer de boite par ce qu’il y a du code pourri dans celle où on se trouve et bien ce n’est pas une bonne raison car il y a du code « pourri » partout et c’est comme ça. Mais il ne faut pas avoir peur du code pourri car il fonctionne déjà mal donc on peut se permettre de rentrer dedans on ne fera sûrement pas pire. Ce code pourri a un potentiel énorme d’amélioration et est le lieu propice à l’expérimentation.

Ainsi se termine la présentation d’Antoine Vernois, très instructive et ça fait du bien de voir des personnes passionnées par ce métier et le goût du travail bien fait.

Sécuriser une refonte avec le Golden Master Testing – Printemps Agile 2015

Matthieu Sadouni et Pierre-Emmanuel Fringant nous ont présenté le principe du Golden Master Testing lors d’une présentation du Printemps agile 2015.

La problématique est la suivante : Comment assurer la refonte d’une application non testée (legacy code) réalisée par une autre équipe tout en assurant la maintenance de l’existant ?

L’idée du Golden Master est de vérifier que pour un ensemble de paramètres donnés en entrée, la sortie de l’application ne varie pas. L’application est alors vue comme une boite noire. L’état initial de la sortie  est appelé Golden Master. Une fois celui-ci défini, on peut  développer de nouvelles fonctionnalités ou factoriser le code existant sans souci : si la sortie reste identique au Golden Master, c’est qu’aucun effet de bord n’a été constaté. Il peut arriver que la sortie soit différente du Golden Master mais qu’elle soit tout de même valide (si l’application de base contient des bugs par exemple). Dans ce cas, la nouvelle sortie devient le Golden Master pour la suite du développement.

Pour mettre en place le Golden Master Testing, Pierre-Emmanuel et Matthieu utilisent rspec et capybara. Tout leur processus est expliqué sur github : https://github.com/mhcommunication/golden-master