Les traducteurs agiles

Le MVP est un exercice marketing non un exercice technologique

Tue, 24 Mar 2026 00:01:00 +0000

Il s’agit peut-être du terme le plus à la mode et le plus mal utilisé de l’industrie informatique en ce moment. Et ce terme semble être d’ailleurs utilisé par certaines personnes pour en critiquer d’autres et réciproquement.

J’ai récemment entendu un coach Agile dire : « Si vous ajoutez seulement quelques fonctionnalités de plus alors vous aurez un MVP ». J’avais envie d’hurler « Faux, faux, faux ! », mais je me suis retenu en me mordant la langue (qui a dit que je ne savais pas faire preuve de diplomatie ?)

Le terme MVP (ou Produit Minimum Viable) semble être devenu la nouvelle manière de dire « Le système doit faire ceci », autrement dit le MVP est devenu la lettre M de la technique de priorisation MoSCoW¹ .

Une partie du problème provient du fait que le terme signifie différentes choses pour différentes personnes. À l’origine, il a été inventé pour décrire une expérience (« quelle est la plus petite chose que nous pouvons construire pour apprendre quelque chose du marché ? ») ; il s’avère aussi souvent utilisé pour décrire une version « réduite » du produit qui pourrait satisfaire les besoins des clients. Mais en poussant un peu plus loin de ce que pourrait être cette version réduite du produit, il s’avère qu’il n’est pas si réduit que ça. Et lorsque le terme MVP est utilisé dans le sens « enlever tout le superflu », cela veut dire pour cette personne qu’il reste encore beaucoup de gras sur l’os.

Je pense que les personnes non-techniques ayant entendu le terme de MVP l’ont interprété comme étant « un produit qui ne comporte pas tous ces éléments d’ingénierie logicielle superflus qui ralentissent l’équipe. ». Cela montre à quel point ces personnes ne comprennent rien au monde du numérique.

Les MVP n’ont rien à voir avec la technologie. Un MVP n’a rien à voir avec le fait de construire des choses.

Un MVP est un exercice marketing : pouvons-nous construire quelque chose que nos clients veulent ?

Pouvons-nous construire quelque chose que nos clients sont prêts à payer ?

Avant d’utiliser le terme de MVP, vous devriez partir du principe que :

La technologie permet de le faire
Votre équipe est capable de le construire

La question est : est-ce que cela vaut le coût de construire ce truc ? — et avant que nous ne gâchions de l’argent pour construire quelque chose dont personne ne veut, et a fortiori encore moins l’acheter, qu’est-ce que nous pouvons construire pour être certain que nous allons dans la bonne direction ?

La prochaine fois que vous devez faire l’ébauche d’un MVP, divisez tout par 10. C’est-à-dire partez du principe que sa valeur réelle ne correspond qu’à 10% de la valeur au départ évoquée, que vous n’avez que 10% des ressources et 10% du temps à votre disposition pour le construire. Maintenant repensez à ce que vous demandez avec ce MVP. Pouvez-vous le bâtir avec ce 1/10 dont vous disposez ?

Quoi qu’il en soit, la boîte de Pandore est ouverte, même si j’aimerais pouvoir le faire, je suis incapable d’effacer cette abréviation et les différentes significations qui y sont associées de la mémoire collective des gens. Mais peut être que je peux changer le débat en différenciant les différents types de MVP, c’est-à-dire les différentes manières dont le terme MVP est utilisé :

MVP-M: un produit marketing, conçu pour tester ce que les clients veulent et ce pour quoi ils sont prêts à payer.
MVP-T: un produit technologique conçu pour voir si quelque chose peut être réalisé techniquement — c’est-à-dire qu’il correspond aux termes historiquement utilisés que sont preuve de concept et prototype.
MVP-L: une liste des fonctionnalités INDISPENSABLES que le produit DOIT AVOIR
MVP-H: un MVP de type hippopotame, c’est une version spéciale d’un MVP-L, dont la liste des fonctionnalités est celle de la personne la plus payée dans l’organisation² , malheureusement pour vous, vous pourriez être amené à rencontrer plusieurs personnes qui considèrent avoir le droit de définir la liste des fonctionnalités
MVP-X: où X correspond à un numéro (1, 2, 3, …) utilisé par les équipes qui livrent des améliorations de leurs produits et/ou qui le font grandir. (Dans le monde pré-numérique nous appelions ceci un numéro de version). Toutefois je ne suis pas sûr de comprendre en quoi ce type de MVP est minimal mais si cela peut aider des gens … pourquoi pas ?

MVP-M est le terme d’origine alors que le MVP-L et le MVP-H sont les MVP les plus couramment entendus.

Alors la prochaine fois qu’une personne dit « MVP », vérifiez avec elle, qu’est-ce qu’elle entend par là ?

Auteur : Allan Kelly
Source : MVP is a marketing exercise not a technology exercise
Date de parution originale : 02 Octobre 2017

Traducteur : Nicolas Mereaux
Date de traduction : 24/03/2026

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

Traduction faite main sans IA.

Logo « Fait (Hu)Main » par Lazar Baruk

NdT - technique de priorisation indiquant respectivement ce qui Indispensable (Must have), Souhaitable (Should have), Accessoire (Could Have) et Dispensables (Won’t have) dont les premières lettres de chaque degré de priorité avec l’ajout de lettres o supplémentaires forment l’acronyme MoSCoW ↩
NdT - l’abréviation HIPPO en anglais est High Paid Person Opinon soit littéralement opinion de la personne la plus payée (dans l’organisation ou autour de la table) ↩

De la nature non linéaire et de toute première importance des êtres humains dans le développement logiciel

Mon, 26 Jan 2026 00:01:00 +0000

Préambule du traducteur : Même si le texte originel a été publié initialement en 1999 et malgré les avancées technologiques permettant de travailler à distance ainsi que dans d’autres domaines, il reste à mes yeux toujours d’actualité.

Rapport technique - Humans and Technology - Mars 1999

Présenté à la 4ème International Multi-Conference on Systems, Cybernetics and Informatics, Orlando, Floride en juin 2000.

Résumé

Nous autres, méthodologistes et concepteurs de processus avons pris l’habitude de concevoir des systèmes complexes sans toutefois prendre la peine de caractériser leurs composants actifs, bien que ceux-ci soient connus pour leurs caractères hautement non-linéaires et d’une très grande variété : les personnes.

Dans ce rapport, je mets en exergue des théories et des projets à la lumière de cette prodigieuse et notable découverte ainsi que quatre éléments caractérisant les personnes, et qui impactent toute conception de méthode et le résultat de tout projet. J’ai découvert que ces caractéristiques sont de bien meilleures sources de prévisions sur le déroulement d’un projet et la réussite d’une méthode que tout autre facteur méthodologique.

Mots-clés : conception de méthodologie, processus, facteurs humains, facteurs collectif

1 - Introduction

Ce rapport compile l’étude et l’expérience acquise s’étendant sur une période de 20 ans d’environ trois douzaines de projets et de méthodes différentes. Pour faire court, pendant toutes ces années, nous avons conçu des systèmes complexes dont les composants actifs sont variables et hautement non-linéaires (autrement dit les personnes), sans avoir pris le temps de caractériser ces composants ou avoir caractérisé leurs effets sur le système en question. Après réflexion, cela peut sembler absurde, mais étonnamment peu de gens dans notre métier se sont investis suffisamment pour vraiment comprendre comment ces choses qu’on appelle les personnes influent sur le développement logiciel.

Parmi les exceptions notables, citons Gerald Weinberg [Wei] and Tom DeMarco [Dm], dont les ouvrages viennent d’être réimprimés en édition spéciale anniversaire. Leurs travaux dans ce domaine sont d’ailleurs reconnus et bien des consultants s’accordent à dire que le facteur humain est un aspect essentiel dans le développement logiciel [B99], [Hi]. On pourrait s’attendre à trouver ici et ailleurs des recherches pour poursuivre leurs travaux. Toutefois, la communauté du développement logiciel a grandement ignoré les caractéristiques des personnes comme sujet d’étude. Il s’agit d’un oubli significatif, aussi significatif que d’ignorer l’acier dans les murs en béton armé et de s’interroger par la suite pourquoi les expériences radiophoniques ne donnent pas les résultats attendus.

Comme beaucoup de gens, lorsque j’étais amené à évoquer des personnes dans des projets, je le faisais uniquement superficiellement et c’est bien après des années de recherches et de pratiques en méthodologie que j’ai commencé à m’interroger sur pourquoi mes recommandations en terme de méthodologie ne correspondaient pas à mes expériences dans les projets informatiques. Le problème n’était pas, ce que mes différentes équipes faisaient (les projets en question avaient un fort taux de réussite). Le problème était que ce que j’écrivais ne correspondait pas à ce que nous faisions.

Ces cinq dernières années, j’ai découvert — et je continue à découvrir — combien il est difficile de déterminer “ce que je regarde”. Peu à peu il m’est apparu évident qu’une chose ne collait pas dans mon équation méthodologique, ou en fait, dans l’équation de n’importe qui d’autre, aussi loin que je puisse voir, c’est-à-dire l’effet des « personnes » sur les méthodologies.

Du moment où j’ai commencé à comptabiliser ces faits, j’ai trouvé que mes prédictions méthodologiques et mes résultats commençaient à concorder avec mes expériences. Je considère aujourd’hui que les caractéristiques des personnes sont le facteur dominant, de 1er ordre de tout projet.

En quoi cela diffère t’il de ce que DeMarco et Lister ont pu écrire dans leur ouvrage Peopleware ?

Dans leur ouvrage, DeMarco et Lister énoncent que les personnes sont déterminantes et nous livrent des clés de compréhension. De mon côté, je me suis plus particulièrement intéressé sur comment les caractéristiques des groupes et des individus influent sur la conception des pratiques de développement logiciel (autrement dit les méthodologies) au sein de différents groupes travaillant sur différentes sortes de missions.

Dans le chapitre « faire équipe » de l’ouvrage Psychology of Computer Programming, j’ai découvert quelque chose qui se rapproche de ce que je cherchais et plus particulièrement dans la partie gestion de « tâches » vs gestion de la « maintenance » à savoir : la notion de caractérisations et les recommandations qui découlent de celles-ci. Ces caractérisations et ces recommandations faites sur la bases d’entretiens dans les années 1960 s’avèrent toujours pertinentes et significatives 30 ans plus tard. Ceci valide la solidité et l’importance de ce type de question. Il est temps que nous étudiions ces questions qui sont au cœur de l’ingénierie logicielle et que nous arrêtions de les redécouvrir tous les 30 ans.

La rédaction de ce document, qui met en exergue l’ensemble de ces travaux, me permet d’affirmer que les « personnes » comme étant vraiment de toute première importance dans la réussite d’un projet et non de manière incidente ; j’en utilise les caractéristiques comme autant d’indicateurs prédictifs. Ce document est écrit à la première personne et non dans un style formel ou académique classique, parce qu’il relate une quête de quelque chose d’évident tout en restant non explicité, il me parait donc plus adapté de de la raconter sous la forme d’un récit.

2 – Ce qui ne fonctionnait pas

En 1987, lors du développement en méthode formelle d’un logiciel de communication, j’avais été encouragé à traiter le sujet suivant : « le problème lors du développement d’un logiciel, c’est qu’il y a trop d’ambiguïté dans l’explicitation du problème et dans la description de la conception. Les choses iront mieux si nous faisons en sorte que les personnes adoptent un formalisme mathématique ». Après avoir travaillé quelques temps dessus sur ce domaine, j’ai découvert que :

Problème 1 : Les personnes dans les projets ne sont pas intéressés par apprendre notre système
Problème 2: Elles ont réussi à nous ignorer et à livrer du logiciel tout de même.

J’ai arrêté le développement formel après avoir entendu l’un de mes collègues dans ce domaine dire : « En fait, le problème réside dans la formation. Les choses se passeraient mieux si nous commencions à donner aux étudiants une formation mathématique suffisante bien plus tôt — autrement dit dans le secondaire ». Compte tenu de ce que j’ai appris sur les personnes, je pense que son affirmation révélait en fait un désir frustré. Non pas que je doute de certains des avantages du développement formel, mais je doute de notre capacité à persuader 10**6 personnes à le maîtriser. La bonne question pourrait être : « En quelles circonstances et dans quel cadre, devrions-nous faire appel à un spécialiste en développement formel ? »

Je suis donc passé à la place au développement d’outils, travaillant autant que possible de manière ethnocentrique. J’ai donc observé des concepteurs de protocoles de communication et j’ai discuté avec eux sur quels pourraient être les problèmes auxquels ils faisaient face. Mes collègues et moi avons alors décidé que « Le problème est que les gens continuent de dessiner sur tableau blanc. Les choses se passeraient mieux si nous leur donnions des outils spéciaux afin qu’ils puissent dessiner directement sur ordinateur et qu’ils puissent voir au plus tôt leurs conceptions devenir rapidement un exécutable. »

Nous avons passé alors plusieurs années à développer un moteur d’inférence qui convertirait les diagrammes d’interactions en architecture logicielle et en système de règles [Ci]. Beaucoup d’équipes ont travaillé et travaillent encore sur des concepts similaires comme par exemple les machines à état fini exécutables de Harel [Ha].

Quelques années plus tard, nous avons terminé un prototype et l’avons montré à notre groupe d’utilisateurs potentiels, et nous avons été estomaqués de les entendre nous dire « Non merci, en fait nous, nous aimons dessiner sur les tableaux blancs. Nous ne voulons pas perdre du temps à mettre nos dessins sur ordinateurs. Hum, par contre pouvons-nous utiliser cette partie de l’éditeur de dessin de l’outil ? ». Nous avons entendu ce même récit de la part d’autres éditeurs logiciels qui se terminait immanquablement par « ils utilisent juste l’éditeur de dessin ». Autrement dit

Problème 1. Les personnes travaillant sur des projets n’étaient pas intéressées par apprendre notre système.
Problème 2. Elles étaient très fortes pour nous ignorer et être en capacité néanmoins à livrer du logiciel.

Troublé par tout cela, je suis donc passé à des méthodologies de développement logiciel, et j’ai conçu la méthodologie orientée-objet pour IBM Consulting Group entre 1992 et 1994. Ne voulant pas répéter la même erreur une troisième fois, je me suis entretenu avec des personnes d’une douzaine de projets basés sur l’objet tout autour du monde, puis j’ai tout couché par écrit. En étudiant ces notes, j’en ai conclu différentes choses :

Les équipes qui réussissent font du développement incrémental [Co95]
Toute technique de conception qui s’avère plus compliqué que des « cartes CRC » [B87] semblent trop complexes pour être utilisée
Les équipes de conception ont le privilège d’ignorer tout outil ou toute technique qu’elles n’apprécient pas. Tout ce qu’elles ont à dire à leur patron c’est : « Cela me ralentit — je ne tiendrai pas les délais si je l’utilise » et leur patron les laisse alors ne pas les utiliser. À cette époque, cela ne paraissait pas important de l’écrire, mais je l’avais noté en tant que « contrainte de conception » au niveau méthodologique.

J’ai alors conçu la méthodologie la plus palpable, la moins cérémonielle possible et je l’ai utilisée sur un projet. J’ai documenté notre expérience sous le nom de projet Winifred [Co98]. La technique de conception de base que j’y ai recommandé, que j’ai enseignée et sur laquelle j’ai guidée les gens sur ce projet se base sur les cartes CRC.

Quelques mois plus tard, j’ai enlevé mon chapeau de consultant pour le remplacer par celui d’ethnographe et j’ai étudié les manières dont une équipe se comporte réellement. Ce que j’ai pu observer m’a sidéré :

Le processus que l’équipe suivait d’un instant à un autre était si intriqué qu’il m’était impossible de le mettre par écrit et même si j’avais été en mesure de le faire, personne n’aurait été capable de le suivre [Co98p]. Cela correspondait de manière très superficiel à mon propre processus.
Pas une personne parmi la douzaine de concepteurs orienté-objets que j’avais accompagné n’utilisait les cartes CRC.

En d’autres mots, même si j’avais utilisé ce que je pensais être une approche ethnographique pour concevoir cette méthodologie :

Problème 1. Les personnes travaillant sur les projets n’étaient pas intéressées par apprendre notre système.
Problème 2. Elles étaient très fortes pour nous ignorer et livrer néanmoins du logiciel.

Ce processus s’est répété encore et encore plusieurs fois, jusqu’à que je sois contrarié de mon incapacité à « voir réellement ce qui se passait ». La meilleure chose que je pouvais dire était qu’il y avait des choses importantes sur le projet que nous n’avions pas su nommer. Pour résoudre cela, j’ai fait alors équipe avec un ethnographe pour avoir de l’aide pour mettre un nom sur ce qu’il se passait [Ho]. Un consultant plus un ethnographe, ça faisait un bon duo, mais à peine venions tout juste de commencer que nous nous sommes rendus compte que nous étions incapables de décrire ce que nous voyions et que nous ne pourrions le faire tant que nous n’aurions pas les mots pour ce que nous étions en train de voir. Et manifestement, notre vocabulaire actuel s’avérait inadéquate.

Depuis, j’ai discuté, et j’ai lu des récits détaillés provenant de trois douzaine de projets différents (certains d’entre eux sont évoqués dans le tableau 1).

Tableau 1 : Revue des projets et des méthodologies utilisées. Le tableau ci-dessous liste l’ensemble projets passés en revue classés par ordre chronologique. Chaque projet comporte un index de référence bibliographique abrégé permettant de le retrouver dans le reste du rapport et pour certains d’entre eux des informations complémentaires.

1980. “CT5”. Réussite. 26 personnes, 3 ans (1 année de retard), projet stratégique. Montée en compétence par apprentissage, présence d’un processus macro bien défini, absence de processus micro.

1986. Projets “Cleanroom” [Mi]. Réussite. IBM Federal Sector, projets avec des équipes de taille importante. Succès répétés grâce à une méthodologie lourde et très rigoureuse.

1986. “Projets de Sherr” [Br] Réussite. Processus du genre « faites que ça marche, mais ne faites pas d’heures supplémentaires » ayant forcé à trouver des solutions créatives, absence de processus défini.

1980. “Broooklyn Union Gas” [Co98]. Réussite. Nouvelle technologie orienté-objet, 150 personnes, projet stratégique.

1992. “Tracy” [Co98]. Échec. Petite équipe suivant aveuglément une méthodologie dite « modélisez le monde, puis codez-le ». Accès occasionnel aux utilisateurs et à du personnel non qualifié.

1992. “BlackKnight”. Réussite. Petite équipe avec notes repositionnables reliées par des fils en laine.

1992. “Manfred” [Co98]. Échec. Petite équipe, peu rigoureuse. « Nous ferons la conception plus tard » — échec du prototypage en continu

1992. “CSPITF”. Réussite. Petite équipe suivant scrupuleusement des itérations. Processus léger, assis les uns à côté des autres. Bonne synergie entre le responsable technique et le responsable projet. Le responsable technique est resté sur le projet pour restructurer la conception interne du code pour l’équipe ayant succédé à la sienne.

1992. “OTI” [Co98]. Réussite. Petites équipes. « Donnez aux bonnes personnes les bons outils, et laissez-les tranquille. » Réussites répétées avec une méthodologie légère centré sur l’humain.

1993. “Reginald” [Co98]. Échec. Une équipe de 2 personnes ayant grossi pour devenir 3 équipes réparties sur 2 comtés. L’une des équipes suivait aveuglement une méthodologie lourde à base de documentation papier, et n’a jamais produit un seul morceau de code avant que le projet ne soit annulé.

1993. “Ingrid” [Co98]. Réussite. 26 personnes, 2 ans. Présence d’un processus macro incrémental, absence de processus micro. Échec du premier incrément. L’ensemble des développeurs a été remplacé, passage à une méthodologie légère orientée communication au fil du temps.

1993. “Synon in NZ”. Réussite. Lors de notre entretien le responsable du projet a indiqué que la réussite était due au fait que « les 4 personnes travaillaient dans la même pièce en cycle itératif très rapide » et que dorénavant il ne prendrait plus en charge de projets dans lesquels les personnes ne pourraient plus se parler entre eux facilement.

1994. “Udall” [Co98]. Réussite. Le projet fut au départ un échec avec une équipe de taille importante. Le projet fut après une réussite en « recommençant tout depuis le début, en reprenant une partie des personnes de l’équipe précédente pour former une petite équipe performante » .

1995. “Winifred” [Co98]. Réussite. Équipe de 45 personnes, durée de 20 mois. La réussite est due à la présence « d’une manière de réaliser incrémentale, d’une bonne communication, d’un nombre réduits de bonnes personnes ». Présence d’un processus macro et absence de processus micro. Méthodologie orientée communication.

1996. “Reel”. Échec. Équipe de 150 personnes à laquelle il avait été dit de documenter chaque changement de conception. Le projet fut abandonné. L’un des participants au projet le résuma de la manière suivante : « L’utilisation de mauvaises habitudes avec diligence reste quelque chose de mauvais » .

1997. “Caliper”. Échec. Équipe de 90 personnes, projet stratégique. Incapacité à faire une livraison majeure au bout de 6 ans : attentes élevées, nouvelles technologies, absence d’incréments, absence de personnel qualifiés à tous les niveaux.

1997. “NorgesBank”. Entretiens avec les 6 équipes projets. Une phrase revenait dans tous les entretiens : « le succès est au rendez-vous lorsqu’il y a de bonnes communications entre l’équipe et les utilisateurs ».

1998. “C3” [C3]. Réussite. Une équipe de 8 personnes remplaçant une équipe de 26 personnes après un premier échec. Extreme Programming [EP] : petite équipe, très rigoureuse, méthodologie orientée communication.

1998. “NB Banking”. Réussite. Initialement il s’agissait d’une équipe de 3 personnes pour un projet de 2 mois qui est passé du jour au lendemain à une équipe de 10 personnes sur 14 mois. Détestation de la visioconférence. Présence de processus macro et absence de processus micro. La réussite était due aux « aux incréments, aux bonnes personnes et à de la communication ».

1998. “M.A.D.” [Ch]. Réussite. Petite équipe ayant étudié les utilisateurs finaux dans leur contexte et ayant utilisé des prototypes. Utilisation réussie d’une méthodologie orientée communication et prototypage.

1998. “Insman”. Réussite. Équipe de 6 personnes utilisant « Crystal (Clear) »[Co00]. Réussite due à la « focalisation sur de la communication rapprochée, le moral de l’équipe, des incréments de 3 mois avec de l’auto-apprentissage au niveau de l’équipe ».

1999. “Cinch”. En cours. Équipe de 40 personnes colocalisées mais continuant d’exiger des livrables écrits formels. L’équipe reconnaissait le coût engendré par la rédaction d’écrits, mais elle était dans l’incapacité de passer sur un mode davantage informel (traits de caractère, habitudes, culturel ?)

1999. “Hill AFB TSP1” [Web]. Réussite. Équipe de 7 personnes ayant atteint le niveau 5 CMM en utilisant des processus logiciels individuels (PSP-Personal Software Process) et d’équipes (TSP — Team Software Process). La réussite de cette petite équipe était notamment due à l’utilisation d’une méthodologie très rigoureuse.orientée processus

Ce que je trouve le plus étonnant dans ces projets est qu’ils démontrent que :

presque n’importe quelle méthodologie peut faire fonctionner des projets
n’importe quelle méthodologie peut faire échouer des projets
les projets menés avec des méthodologies lourdes peuvent s’avérer être couronnés de succès
les projets menés avec des méthodologies légères sont plus souvent couronnés de succès et plus important encore, que les personnes ayant travaillés sur ces projets créditent cette réussite à la légèreté de ces méthodologies.

Je n’ai trouvé aucune théorie pour expliquer ce taux élevé de réussite de projets ayant utilisés des méthodologies légères comportant peu de cérémonies, ni pour expliquer le faible taux de réussite de projets ayant utilisés des méthodologies comportant beaucoup de cérémonies à l’exception notable de Cleanroom et de PSP/TSP. Il m’apparait évident qu’un management médiocre est un facteur non-méthodologique qui y est pour beaucoup, mais même en essayant de normaliser ça, je me retrouve dans l’incapacité de donner des éléments de prévisions significatifs.

J’en ai finalement conclu qu’il y a quelque chose d’autre qui joue ici, qui est juste sous nos yeux à chaque instant et que nous ne voyons pourtant pas : les personnes. Les caractéristiques des personnes sont le facteur de réussite primordial de la réussite et non un facteur de second ordre. En fait, en renversant l’ordre des choses, je considère désormais les facteurs liés aux processus comme des éléments de second ordre.

D’après mon expérience tout peut être réduit à juste quelques caractéristiques essentielles concernant les personnes. En les appliquant sur des projets plus récents, j’ai pu prédire de manière plus pertinente leurs résultats et j’ai pu donner des recommandations plus pertinentes. Je crois que le temps est venu, de manière formelle et officielle, de conduire des recherches sur « quelles sont les caractéristiques des personnes qui peuvent impacter le développement logiciel et quelles sont leurs implications dans la conception des méthodologies ? ».

3 – Quatre caractéristiques

Les personnes, comme tout système actif, ont des modes de réussite et d’échec. Voici les principaux modes que j’ai pu trouver et dénommer jusqu’à présent :

Les personnes sont des êtres communicants, qui fonctionnent le mieux en face-à-face, avec des échanges en temps réel
Les personnes ont du mal à agir de manière constante au fil du temps
Les personnes sont très versatiles, d’un jour à l’autre et d’un lieu à l’autre
Les personnes veulent être de bons citoyens, sont plutôt bons pour percevoir leur environnement, prendre des initiatives et faire « ce qu’il faut » pour qu’un projet fonctionne.

Il existe d’autres caractéristiques sur lesquelles je ne m’étendrai pas ici :

Les personnes ont besoin à la fois de temps de réflexion et d’opportunités de communication (cf. [Co98], [Cs], [Dm]).
Les personnes travaillent mieux à partir d’exemples (un sujet à approfondir) (cf. [J-L]).
Les personnes préfèrent échouer de manière conservatoire plutôt que de devoir risquer à réussir différemment [Pi]; elles préfèrent inventer plutôt que faire des recherches ; elles peuvent conserver seulement une faible quantité d’informations en têtes, elles font des erreurs et elles trouvent difficiles de changer d’habitudes.
Des personnalités individuelles peuvent facilement dominer un projet.
Le profil de personnalité d’un individu affecte fortement la réalisation de missions spécifiques

Les personnes sont des êtres communicants

Le facteur unique et le plus significatif est la « communication ». Le diagramme 1 représente la courbe de l’information que j’utilise désormais pour évoquer mes réflexions en termes de méthodologie. Ce diagramme démontre que l’efficacité de la communication baisse en fonction des modalités de communication et de synchronicité. Quelques recherches sur ce sujet (cf. [Pl] et [Si]) corroborent les expériences relatées par Weinberg il y a plus de 30 ans (cf. [Wei].)

La manière la plus efficace de communiquer est la communication en tête-à-tête, face à face, à côté d’un tableau blanc. Si nous enlevons l’une de ces caractéristiques, nous voyons une baisse d’efficacité de la communication. Les caractéristiques que nous perdons sont :

la proximité physique : je suis bien en peine d’expliquer pourquoi, mais se trouver proche physiquement d’une autre personne a un effet sur la communication. Que ce soit par l’aspect tridimensionnel, temporel, à l’odeur, ou bien encore par tout un ensemble d’éléments visuels, la proximité physique compte.
la variabilité des modalités possibles. Les personnes communiquent aussi bien avec des mots qu’à travers des gestes, marquant souvent un point à l’aide d’un geste, avec les sourcils ou en montrant avec le doigt
les inflexions de la voix et le débit. En accélérant, en ralentissant, en faisant des pauses ou en changeant le ton de la voix, l’intervenant accentue soit pour souligner l’importance d’une phrase soit pour surprendre son interlocuteur.
les questions-réponses en temps réel. Les questions permettent de révéler les ambiguïtés dans le discours de l’intervenant ou dans la manière dont le discours n’atteint pas l’auditeur dans son contexte. La séquence des questions dessine un schéma de communication entre les interlocuteurs.

Figure 1. Modes de communication

Que se passe t’il quand nous enlevons ces caractéristiques l’une après l’autre ?

Commençons par supprimer uniquement la proximité physique. Mettez deux personnes aux deux extrémités d’un échange vidéo. En principe, cet échange présente les mêmes caractéristiques qu’une présence physique. Toutefois, lorsque nous essayons, l’effet n’est pas exactement le même. Les membres d’une équipe travaillant respectivement à Oslo et à Lillehammer se sont aperçus après coup, que là où ils avançaient le mieux dans leurs travaux de conception, c’était lorsqu’ils étaient assis les uns à côté des autres dans le train. Même le fait de marcher ensemble en partant de la gare s’avérait plus efficace qu’une réunion en distanciel.
Puis supprimons la possibilité de voir les gestes, tout en conservant l’inflexion de la voix et le direct (par exemple en utilisant un téléphone). La plupart des gens parlent tout en dessinant. En effet, tout en dessinant une ligne reliant deux rectangles, une personnes pourra souligner oralement ce qui est important de retenir. Cette information simultanément visuelle et auditive permet d’ancrer l’information. Si vous avez deux personnes au téléphone, cet aspect de la transmission de l’information est supprimé, de même que les expressions faciales, les gestes dont celui de pointer quelque chose avec le doigt.
Ensuite en supprimant la voix et l’inflexion en direct, mais en conservant la capacité à poser des questions (courriel). Sans la voix en temps réel, il est impossible de faire une pause, de vérifier s’il y a besoin de s’interrompre, d’accélérer ou de ralentir pour préciser un point. Sans l’inflexion vocale, il est impossible d’élever notre ton ou la force de notre voix pour indiquer la surprise, l’ennui ou l’évidence d’une idée que nous souhaitons transmettre.
Après en supprimant la capacité à poser des questions (mais en laissant la possibilité de remettre en place une des caractéristiques précédemment supprimées). En l’absence de questions, la personne émettrice doit deviner ce que la personne destinataire sait, ne sait pas, ce qu’elle souhaiterait poser comme question, et quelle serait la réponse appropriée à cette question hypothétique sans avoir de retour si c’est pertinent ou pas. Dans ce cadre de communication, nous pouvons considérer l’ajout d’éléments visuels (enregistrement vidéo) ou vocaux (enregistrement audio).
Enfin en supprimant tout élément visuel, vocal, direct et de questionnement, et nous obtenons … une documentation papier. Dans le diagramme ci-dessus, la documentation se révèle être le moyen de communication le moins efficace. Le rédacteur doit faire des postulats par rapport à ses futurs lecteurs, et ne bénéficiera pas du direct, de signaux empathiques, de l’inflexion de la voix ou des gestes.

Si ce modèle s’avérerait être d’une quelconque utilité, il devrait nous suggérer comment mieux travailler. Et c’est bien ce qu’il fait, et nous nous apercevons d’ailleurs que les projets qui avancent le mieux utilisent d’ores et déjà ce que ce modèle suggère.

« Mettez tout le monde dans une seule pièce. », « Je ne veux pas plus de 4 personnes, c’est le nombre de personnes maximum qu’il est possible de mettre dans une pièce pour qu’elles discutent ensemble dans de bonnes conditions. ».

Ces recommandations, sont les recommandations habituelles des chefs de projets qui arrivent à faire avancer leurs projets. Dès le départ, ils prévoient d’utiliser le mode de communication ayant la bande-passante la plus élevée, c’est-à-dire des personnes en face-à-face.

« Assurez-vous qu’il y ait des tableaux blancs et des espaces-café dans tout l’immeuble ».

Très tôt, Hewlett-Packard et IBM ont pu observer l’efficacité des « lieux de réunions informels » ; cette expression de « lieux de réunions informels » et leurs mises en place est désormais bien répandue dans notre secteur d’activité à tel point qu’un environnement de travail bien conçu se doit d’encourager la possibilité pour des petits groupes de se réunir de manière ad hoc. Weinberg a documenté plusieurs cas où des conversations ayant pu se dérouler dans un cadre détendu ont eu un effet significatif sur la productivité générale [Wei]. On assiste à des avancées importantes lorsque des personnes « parlent simplement ensemble ».

Trois méthodologies récentes mettent en avant le fait de réunir les personnes dans une même pièce ou très proches les unes des autres : Adaptive Software Engineering [Hi], Extreme Programming [B99], [EP], Crystal(Clear) [Co00]

Le modèle que nous avons évoqué précédemment nous incite à faire la recommandation suivante quant à l’archivage de la documentation produite :

Demandez à un concepteur de faire une brève description (5 à 20 minutes) de sa conception à un ou deux collègues qui ne sont pas familiers du sujet. Ils agiront comme des médiateurs pour les futures spectateurs de la vidéo. Laissez-les simplement avoir une discussion sur la conception, avec ces collègues posant des questions et enregistrez-les en vidéo. À la fin de l’enregistrement, reproduisez les schémas des exemples ou les schémas de conceptions utilisés, lors de la discussion, pour servir d’ancres mémorielles à la discussion

J’ai été agréablement surpris d’apprendre que Lizette Velasquez de l’entreprise Lucent Technologies avait non seulement pu tirer bénéfice de cette technique mais que j’avais oublié d’évoquer également quelque chose d’important. Elle a dit qu’il était important de marquer et d’indexer les moments où « quelque chose d’intéressant se passe ». Même si la plus grande partie de la discussion se passe sur un rythme plutôt lent, il arrive de manière occasionnelle qu’une question déclenche tout un emballement au niveau des échanges, et il ne fait aucun doute que les spectateurs voudront se référer et retrouver ces moments-là.

De nos jours, il est possible de mettre cet enregistrement vidéo en ligne accompagné de liens hypertextes.

Pour les personnes qui pensent qu’un livre est mieux, je les incite à lire cet excellent et difficile ouvrage qu’est celui des Design Patterns. Imaginez un instant qu’à la place de soutirer la signification du pattern¹ « Decorator » du livre, vous pouviez cliquer sur la page et voir l’un des auteurs expliquer ce pattern en vidéo. Bien entendu, cet auteur ou un autre devrait utiliser les inflexions de la voix, faire des gestes pour mieux transmettre l’idée.

La leçon à tirer de cette caractéristique humaine est que nous devrions tirer les communications de l’équipe aussi haut que possible sur la courbe en fonction de la situation.

Les personnes ont tendance à ne pas agir de manière constante

Nous devons être prudent lorsque nous évoquons les types d’échecs d’origine humaine. « Si vous donnez à un chien un mauvais nom, autant vouloir le tuer » est un vieux proverbe anglais. En effet, comme nous allons le voir dans les deux exemples suivants, changer simplement le style de management et la culture locale peut changer profondément les comportements. Et en même temps, en me référant à mes expériences sur les projets passés, il existe une espèce de fil rouge montrant à quel point il est difficile de s’attendre à de la cohérence en terme d’actions. Jim Highsmith l’a très bien écrit [Hi] :

« … ce sont des personnes, pas des rouages, à l’intérieur de la boîte. Les gens peuvent faire des choses similaires de manière répétée, mais jamais la même chose. À l’aide d’un processus étape-par-étape, nous pouvons nous attendre aux même résultats à partir des mêmes éléments en entrée, mais la réaction des gens à ces éléments peuvent varier considérablement de jour en jour en fonction de tout un ensemble de conditions, dont certaines qui n’ont aucun rapport avec la tâche en cours. »

Les personnes se satisfont d’un certain degré de souplesse quant à leur propre comportement. Je me souviens d’une des deux demandes les plus difficiles qui ait pu m’être faite, à savoir rendre une personne capable de faire quelque chose soigneusement et de manière constante jour après jour (l’autre demande la plus difficile étant de demander aux gens de changer leurs habitudes). Voici ci-dessous l’extrait d’une conversation dont j’ai été témoin récemment qui illustre ce propos :

« Comment est-ce que je peux gérer tout ce flux de paperasses qui arrivent sur mon bureau » a demandé une personne. Une autre personne répondit : « C’est facile. Garde ton bureau propre, net, sans rien dessus, avec 4 bannettes d’un côté et quelques dossiers dans des chemises dans le tiroir du haut … » et sa réponse s’arrêta là. « Garder le bureau sans rien dessus !? » se sont écriées les personnes dans l’auditoire à l’unisson. « Je ne peux pas faire ça ! »

Remarquez que la suggestion de bureau net leur demandait de changer à la fois leurs habitudes et d’appliquer cette nouvelle habitude de manière constante.

Si les personnes pouvaient agir simplement de manière constante, ils garderaient leurs bureaux nets, éviteraient les aléas, perdraient du poids, joueraient d’un instrument de musique, et pourraient même produire du logiciel de manière régulière et dans les délais.

Comme Karl Wiegers nous le souligne avec malice « Nous ne sommes pas en manque de pratiques, nous sommes en manque de pratique ». En voici quelques unes. Dans son ouvrage « The Science of Programming » [Gr], David Gries nous donne des consignes détaillées pour dériver² correctement des programmes. Les cartes CRC (Classes-Responsabilités-Collaboration) sont un bon moyen d’exploration pour la conception [B87]. De son côté, Extreme Programming [EP] utilisent des pratiques connues et très efficaces : la programmation en binôme et les tests unitaires de régression automatisés [Je]. Les pratiques mises en avant par la méthode Cleanroom³ sont quant à elles bien connues et documentées [Mi]. Dans Personal Software Process⁴, Watts Humphrey nous donne des préconisations détaillées sur comment les programmeurs pourraient devenir plus efficients. Appliquer de manière constante toute ou partie des idées susmentionnées devrait permettre d’améliorer les projets que j’ai pu voir.

Tout le problème réside dans le mot « constant ». Les approches PSP et Extreme Programming perdent du sens si elles sont appliquées de manière sporadique. Un fragment de code à moitié dérivé n’est pas un fragment de code sans erreur. De la même manière que la technique du bureau propre et net, elles doivent être appliquées de manière complète, constante, quotidienne.

Le manque de constance est un type d’échec répandu chez les humains. Certaines méthodologies exigent une constance dans l’action, je les appelle des méthodologies à « haute discipline ». Les entretiens que j’ai fait sur les projets, indiquent que les méthodologies à haute discipline sont fragiles, même si elles sont déjà présentes dans ces projets. Ce qui suit est extrait d’une entreprise de niveau 5 en CMM⁵ est assez instructif :

« Durant l’été 1996, TIS a introduit la méthode PSP chez un petit groupe d’ingénieurs informatiques. Même si la formation a été plutôt bien reçue, l’utilisation de PSP chez TIS a commencé à décliner dès la fin de la formation. Et peu après, il s’est avéré qu’aucun des ingénieurs qui avaient été formés aux techniques PSP ne les utilisaient pas dans leur travail. Lorsqu’il leur a été demandé pourquoi, la raison a été unanime : “La méthode PSP est une méthode extrêmement rigoureuse et si personne ne me demande mes données, c’est plus facile de faire comme avant.”. »

Pour rester utilisée, une méthodologie à haute discipline se doit d’offrir une certaine forme de support aux gens pour qu’ils puissent agir de manière constante. La méthode Cleanroom comporte des règles dites de « non-compilation » qui s’accompagnent de pratiques de gestion de projets et d’ingénierie logicielle. Extreme Programming requière à ce qu’un coach soit présent pour maintenir la pratique des pratiques. PSP n’a pas de support aussi explicite, et il n’est pas surprenant que dans ces conditions PSP ne soit plus utilisée par le groupe de personnes susmentionné par manque de structure de support. L’adjonction de TSP à PSP est censée offrir ces éléments manquants [Web].

Nonobstant les commentaires précédents, il y a vraiment des gens qui sont très disciplinés, de manière constante et quotidiennement (ceci pour illustrer qu’il existe une grande variabilité dans les comportements des gens). Quelques fois le simple changement de responsable d’une équipe peut modifier la constance de leurs actions. Je tiens à remercier Trygve Reenskaug pour l’anecdote qui suit - elle permet d’illustrer à quel point le style de management et l’alchimie personnel comptent beaucoup :

Ici, avant, il y avait une boutique assez affreuse qui vendait tout un bric-à-brac. L’endroit était en désordre, et les vendeuses étaient occupées soit à se faire les ongles soit à parler au téléphone, et elles n’accordaient que très peu de temps aux clients. La boutique ferma, et une autre boutique du même genre s’ouvrit au même endroit. Cet endroit était tout simplement merveilleux ! Elle était propre, organisée et les vendeuses étaient attentives aux clients. Le seul point commun entre ces deux boutiques étaient … les vendeuses … qui étaient les mêmes !

En effet, il est bien connu que le style personnel de management a un énorme effet. Le projet Chrysler Comprehensive Compensation⁶ s’est déroulé aux alentours de 1997 [C3]. Au départ, l’équipe valorisait le fait de « réfléchir à l’avance », de « faire de la conception de manière fine mais extensible » et « que mon code soit privé ». L’équipe, collectivement, mais largement sous l’impulsion de Kent Beck, s’est reconstruite autour de valeurs cœurs « faire les choses simplement et clairement, nous pourrons ajouter la finesse plus tard », « tout le code est public, n’importe quel binôme peut se constituer et peut changer n’importe quel bout de code ». Ces mêmes personnes ont donc adoptées des valeurs cœurs différentes et sont passées du désarroi, de la non-communication, de la non-livraison à une application constante d’un ensemble de pratiques à haute discipline, à des livraisons régulières sur une période de trois ans.

Être un bon citoyen⁷ et être bon à fouiller un peu partout

Trois facteurs de réussites permettent de contrer le problème de constance :

les personnes veulent, en général, être de « bons citoyens »,
les personnes prennent l’initiative
les personnes sont douées pour fouiller un peu partout

Lorsque je fais un entretien sur un projet, je pose toujours la question qu’est ce qui leur a permis de réussir en fin de compte. La seule réponse qui revient régulièrement : « Une poignée de bonnes personnes arrivent à points nommés et font ce qu’il faut pour que le travail soit fait ». C’est exactement une phrase similaire à celle-ci qui fût écrite dans le manuel de la NASA intitulé « Leçons apprises sur le logiciel de vol de désorbitage » [NASA]:

« [L’élément] peut être le plus important pour le long terme, pendant toute la durée du projet, est d’avoir une équipe cœur pour le développement rapide du nouveau système de guidage, navigation et contrôle (GN&C). Cela implique de trouver des personnes compétentes : de les former et de les faire monter en compétences sur les outils, sur les processus et les méthodologies, et de les intégrer dans une équipe soudée.

« Après les avoir fait travailler ensemble sur le langage de définition d’enregistrements (ou RDL pour Record Definition Language - NdT) pendant un an, les membres de l’équipe auront acquis l’expertise nécessaire sur les méthodes, outils et domaines. Une atmosphère aidante, coopérative est encouragée, ce qui a permis d’organiser des formations interdisciplinaires. Une volonté commune de la part des membres de l’équipe d’affronter tous les problèmes de toute nature pendant le projet s’est avéré inestimable plus d’une fois … » (j’ai ajouté la partie en italique pour mettre en valeur cette partie de phrase).

… cette équipe peut s’avérer être un atout sur le long terme que ce soit au niveau de sa division qu’à celui de l’agence.

Qu’est ce qui provoque ce type de comportement chez les gens ? Une réponse possible est : « être de bons citoyens » en terme professionnel.

Il se peut que nous puissions augmenter le taux de réussite des projets en augmentant le « sentiment d’appartenance à une communauté et le sens civique associé » au sein d’une équipe. En réalité, je ne mets pas cette recommandation en haut de la liste parce que je trouve que le sens civique est généralement suffisamment élevé, et que certains managers profitent déjà trop de ce sentiment (voir par exemple, le texte Death March [Yo]).

Toutefois, cette idée révèle un élément rarement mentionné dans la conception de méthodologie.

“Communauté et citoyenneté professionnel”

Cette activité devrait faire partie à part entière au sein des activités principales d’un projet et de ses indicateurs, au moins au même niveau que la « revue de code et le test ». Je suis heureux de dire que plusieurs des projets que j’ai pu voir ont ce type d’activité de manière explicite. Ils les utilisent pour garder des canaux de communication de personne-à-personne en bonne position (il est inutile de dire que ces projets maximisent aussi la communication en face-à-face). Toutefois, je ne l’ai pas encore vu mentionnée par écrit en tant que tel dans une quelconque méthodologie ou dans un quelconque processus.

Le second facteur de réussite est lorsque les personnes prennent des initiatives. Cela va de concert avec la bonne citoyenneté et être bon à fouiller un peu partout, pour produire un facteur de réussite bien connu à savoir « une poignée de bonnes personnes arrivent à points nommés ».

« Bon à fouiller un peu partout » est une phrase un petit peu vague mais qui comporte de grands effets. Les personnes qui trient des papiers créées souvent de petits tas non triés, avec la technique du tri par insertion. Ce qui est surprenant en les observant c’est qu’assez souvent elles ne trient jamais les petits tas. L’a-peu-près est suffisant. En effet, ces personnes savent qu’elles peuvent rapidement chercher dans ce tas à la demande et elles se rappellent souvent où est « approximativement » l’élément recherché (de futures études devraient traiter des techniques d’ancrage mémorielles).

Nous essayons généralement de créer des documents de conception qui soient bons, précis et à jour. Étant donné que la non constance en terme d’action est un facteur d’échec, nous pouvons prédire de manière quasi-certaine que la documentation ne sera pas à jour. En fait, je n’ai pas encore vu de projets ayant réussi qui ait une documentation à jour, à moins que le code ou la documentation ait été générée automatiquement. J’ai toutefois vu un projet échoué parce qu’il avait été demandé aux développeurs de mettre à jour tous leurs documents de conception chaque fois qu’ils devaient changer quelque chose. Le coût du développement s’avéra tout simplement trop élevé, et l’avancement du projet trop lent, et peu de temps après, le projet fût abandonné.

J’ai demandé aux personnes de la maintenance comment ils géraient la mise à jour des programmes informatiques avec de la documentation obsolète. Leur réponse a été qu’ils « fouillaient un peu partout » et qu’ils ne faisaient pas confiance à la documentation de toute façon — ils regardaient le code tout simplement.

J’en suis venu moi aussi à m’appuyer sur ce facteur humain de réussite « être bon à fouiller un peu partout » dans les projets ainsi que dans la conception de méthode.

La traçabilité des documents est très couteuse à mettre en place et à maintenir, particulièrement en raison de la faiblesse des humains en matière de constance comme évoqué plus haut, je recommande donc d’avoir un niveau de traçabilité et de documentation de conception « juste suffisant » afin que la personne qui cherche quelque chose soit en mesure de savoir approximativement où chercher. Leurs yeux et leur intelligence feront la suite. Même s’il est peu probable que le niveau de traçabilité et de documentation soit maintenu sur la plupart des projets (et cela n’est pas très important, parce que les gens font leur travail davantage à partir de ce qu’ils ont appris en discutant avec les personnes sachantes qu’à travers la lecture des documents).

Trygve Reenskaug m’a donné un autre exemple. Il avait proposé un système de conception assisté par ordinateur à un ingénieur concevant des plate-formes d’extraction de pétrole en mer. Trygve lui a évoqué que le système pouvait apporter de la plus-value en retraçant tous les changements faits au niveau de la plateforme. L’ingénieur a répliqué « faites juste en sorte que votre système enregistre les numéros de téléphone des personnes qui ont travaillé sur chaque partie. Je les appellerai en cas de besoin pour en savoir plus ».

Le terme méthodologique officiel que j’utilise est « basse précision » (NdT - ou à grosse mailles à la préférence de la lectrice ou du lecteur) [Co98]. J’ai découvert que la plupart des projets fonctionnent correctement avec des descriptions de basses précisions : les plans projets de basse précision sont plus faciles à lire, à modifier et à négocier. Les diagrammes d’architecture de basse précision sont plus faciles à se souvenir, les tables d’exigence de basse précision sont plus faciles à prioriser et peuvent être évaluer plus tôt dans le projet, la documentation de conception de basse précision sont plus faciles d’accès pour un lecteur pour avoir uniquement une « idée » de la conception — puis en le laissant regarder autour.

Les artefacts de basse précision utilisent les forces des gens pour réduire les coûts de développement. Ils se basent sur leurs capacités à « fouiller un peu partout » et sur la communication en face-à-face, tout en étant permissif sur la non constance de mise à jour. Je les ai utilisés et j’ai obtenu de bons résultats dans les projets depuis 1994, et je les recommande désormais en tant qu’élément central méthodologique.

Tout le monde n’est pas pareil

Certaines personnes aiment faire des listes et d’autres non. Certaines personnes travaillent mieux le soir, d’autres mieux le matin. Certaines personnes aiment les dates butoirs, d’autres non. Certaines cultures valorisent l’autocritique publique, d’autres protègent les gens de toute forme d’embarras, et ainsi de suite.

Les méthodologies sont grosso modo un ensemble de règles de coordination de groupe, et par conséquent, une recommandation qui s’avère appropriée pour une personne ou un groupe sera rejeté par un autre. Dans le même ordre d’idée, ce qui s’applique à un groupe habitué à faire des consensus pourrait ne pas s’appliquer à une culture dans laquelle les personnes attendent que le patron prenne position.

Parmi les projets listés dans le tableau précédent, j’ai remarqué que deux exemples réussis de processus à haute discipline avaient été faits au sein de IBM Federal Sector Division et dans l’Air Force. Je n’ai pas encore vu de réussite de processus à haute discipline dans des contextes marchands. Je suis tenté d’en conclure qu’il existe certains facteurs de réussite dans les contextes gouvernementaux ou militaires qui permettent à des méthodologies plus contraignantes de survivre. Il y a une phrase qui revient dans les quelques groupes que j’ai pu interroger dans ces contexte :« nous aimerions travailler de manière plus légère, plus efficace, mais … » suivi d’une référence soit à un processus militaire standard soit à une difficulté de pouvoir contrôler les prestataires. Il serait intéressant de savoir s’il s’agit de facteurs intrinsèques ou culturels qui « tolèrent » simplement cette lourdeur.

Les méthodologies actuelles sont écrites pour imposer des cultures professionnelles et des manières de travailler dans une organisation cible. Comme cela a pu être écrit précédemment, un groupe peut la rejeter, et souvent le fait purement et simplement.

Les variations sur le plan culturel sont souvent pour les méthodologistes encore plus difficiles à incorporer que les variations individuelles quotidiennes. Au jour d’aujourd’hui, il n’existe aucune méthodologie (y compris la mienne) à ma connaissance qui prennent en compte les problèmes culturels, même si je connais des personnes qui sont suffisamment sensibles aux cultures locales pour formuler des recommandations particulières dans les projets.

Autres caractéristiques

Je me repose aussi sur certaines autres caractéristiques sur lesquelles je ne m’attarderai pas. Voici celles que je retiens en priorité :

Apprentissage. Les gens apprennent en regardant et en faisant. C’est un principe social et cognitif bien connu de certains cercles [La], mais pas encore très bien utilisé en développement logiciel. J’ai cherché différentes occasions pour l’appliquer mais je n’ai pas encore créé une structure méthodologique pouvant le faire pour l’instant.

Flux. Le « flux⁸ » dans un contexte de développement logiciel fait référence à un moment de production intellectuelle silencieuse et efficace [Dm], [Cs], [Co98]. Les temps de flux doivent être contrebalancés avec des moments de communication. Comment équilibrer ces différents moments dans un projet est au-delà de ma compréhension actuelle. Toutefois, un certain nombre de personnes interrogées l’ont signalé comme étant un facteur de réussite notable dans les projets.

Travailler à partir d’exemples. Certains psychologues cognitifs affirment avec conviction que nos mécanismes déductifs se construisent à partir d’exemples de problèmes spécifiques [J-L]. Les cartes CRC et les cas d’utilisation sont deux mécanismes de développement logiciel orienté exemples qui sont cités systématiquement par leurs utilisateurs comme étant deux outils efficaces. Les « diagrammes d’instance » sont souvent les diagrammes préférés des nouveaux venus en conception orienté objet, et sont d’ailleurs toujours utilisés régulièrement par les concepteurs chevronnés. Par contre, la documentation basée sur des exemples n’a pas encore eu l’attention qu’elle mérite de la part des méthodologistes ; elle est l’objet d’un prochain travail d’études.

Approche kinesthésique ou multi-sensoriel. Que ce soit les cartes CRC, les jeux de rôle, la conception sur tableau blanc, le prototypage papier d’interface utilisateur, toutes ces techniques tirent profit de l’aptitude des personnes de parler, de se mouvoir, ou de jouer un rôle tout en réfléchissant. Il y a peu ou pas de recherches sur ce sujet, mais je trouve l’utilisation de ces techniques comme étant très significative dans la conception logiciel.

Type de personnalité. Nous avons vu précédemment qu’une non-communication de la part du concepteur en chef peut aliéner son équipe, et qu’en même temps, il est demandé de manière répétée aux programmeurs de développer leurs compétences en matière de communication. Nous avons rencontré des responsables de projets qui sont incapables de prendre des décisions. L’adéquation du type de personnalité d’un individu avec le poste qui lui est attribué a un large effet au niveau des résultats d’un projet. Cette adéquation devrait être ajustée par rapport à ce qu’il y a de mieux concernant le développement personnel de l’individu, mais il arrive souvent que se voir attribuer un poste de manager constitue la seule voie de progression de carrière pour une personne.

Échec conservateur. Il a été clairement établit que les gens préfèrent échouer de manière conservatrice plutôt que réussir en prenant un risque [Pi]. Ceci peut expliquer pourquoi le développement en cascade continue toujours à être utilisé après toutes ces décennies de problèmes et l’avènement progressif des techniques de développement en spirale, incrémental et itératif.

Changement d’habitudes. Faire changer les gens d’habitudes est la chose la plus dure que je connaisse. Et en même temps, les gens peuvent changer d’habitudes quasi instantanément, et changer du tout au tout au niveau de leurs systèmes de valeurs. J’ai été témoin de tels changements, faits de manière délibérée et en toute conscience peut être deux fois en 20 ans, et c’est impressionnant. Nous aurions besoin de mieux connaître ce type de phénomène.

Petites têtes. Même les concepteurs experts le répètent régulièrement « J’arrive uniquement à me souvenir d’une petite quantité d’informations ». Différentes techniques de documentation ont essayé de palier cette faiblesse, mais aucune n’est arrivée à combiner l’utilisation d’artéfact de basse-précision avec une communication interpersonnelle élevée.

Je suis certain qu’il existe d’autres caractéristiques relatives aux personnes qui affectent en profondeur à la fois la manière dont fonctionnent les projets et la manière dont nous devrions faire des recommandations. En tout cas, vous savez lesquelles j’utilise actuellement.

4 — Conclusion

Les caractéristiques fondamentales des « personnes » ont un effet de tout premier ordre sur le développement logiciel, pas un effet de second ordre. En conséquence, comprendre les effets de premier ordre devrait devenir un élément de recherche de première importance, et ne pas être négligé, relégué en sujet de moindre importance. Je propose que ce champ d’étude devienne un sujet primordial dans le domaine de « l’ingénierie logicielle » pour les 20 à 50 prochaines années.

J’ai présenté plusieurs caractéristiques qui ont des effets notables sur la conception de méthodologie.

La première est que nous sommes sensibles aux rythmes et aux modalités de communication. La prédiction que je fais est que la proximité physique et la facilité de communication a un effet majeur.

La seconde est que les personnes ont tendance à ne pas faire preuve de constance. La prédiction que je fais est que les méthodologies exigeant une forme de constance disciplinée s’avèrent fragiles en pratique.

La troisième est que les gens changent, pas simplement quotidiennement mais aussi lorsqu’ils passent de groupes en groupes. Les méthodologies ne prennent pas en compte les variations culturelles et elles devraient être en mesure de les gérer.

La quatrième est que les personnes aiment être de bons citoyens, qu’elles sont douées à fureter partout et qu’elles prennent l’initiative. Le tout forme le facteur de réussite « une poignée de bonnes personnes arrivent à points nommés ».

Être bon en communication et à fureter partout permettent de contrebalancer l’inconstance, ce qui conduit à faire la prédiction que les méthodologies peuvent faire bon usage des artéfacts de basse précision dont l’imprécision est couverte par la communication personnelle. L’étude des projets évoquée dans ce rapport permet d’étayer cette prédiction, elle-même sujette à une certaine forme de montée en compétence du personnel, y compris la chaîne managériale.

Dans le titre de cet article, je fais référence aux personnes comme étant des « composants ». Effectivement, dans la littérature de conception de processus/méthodologie, c’est ainsi que les personnes sont qualifiées. L’erreur dans cette approche est que les « personnes » (au contraire d’un composant - NdT) font preuve d’une grande variabilité et d’une grande non-linéarité qui s’accompagnent d’une ensemble de facteurs-clés de succès et d’échecs uniques. Ces facteurs sont primordiaux et ne sont pas à négliger. Le fait de ne pas prendre en compte de ces éléments par les concepteurs de processus et de méthodologies expliquent en partie les trajectoires imprévisibles que nous pouvons constater sur certains projets.

Pour finir, il devrait être claire que nous pourrions faire davantage de recherches sur ce sujet. J’espère qu’il y aura davantage de chercheurs pour relever ce défi qu’il y en a eu depuis la rédaction, il y a 30 ans, par Weinberg de sa version du présent article. J’attends avec impatience, en particulier, de nouvelles recherches en psychologie et en ethnographie pour découvrir d’autres effets de premier ordre que ceux mentionnés ici.

Références

[B87] Beck, K. and Cunningham, W., “A laboratory for teaching object-oriented thinking”, Proceedings of the OOPSLA Conference, 1987, ACM Sigplan Oct., 1987, pp.1-7.

[B99] Beck, K., Extreme Programming Explained: Embrace Change, Addison Wesley Longman, 1999.

[Br] Britcher, R., The Limits of Software, Addison Wesley, 1999.

[Ch] Christensen, M., et al., “The M.A.D. experience: multiperspective application development in evolutionary prototyping”, in the ECOOP’98 proceedings, Lecture Notes in Computer Science, Vol. 1445, Goos, G., Hartmanis, J, van Leeuwen, J., eds., 1998, pp. 13-41.

[Ci] Citrin, W., Cockburn A., von Kaenel, J., Hauser, R., “Using formalized temporal message†‘flow diagrams,” Software Practice and Experience, 1995.

[Co94] Cockburn A., “In search of methodology,” Object Magazine, July 1994.

[Co95] Cockburn A., “Unraveling incremental development,” Object Magazine, Jan. 1995.

[Co98] Cockburn A., Surviving Object-Oriented Projects, Addison Wesley, 1998.

[Co98p] Cockburn A., Position statement for “Software development and process” panel, ECOOP ‘98, online at http://members.aol.com/acockburn/papers/Ecoop98panel.htm

[Co00]Cockburn A., Crystal(Clear): A human-powered software development methodology for small teams, Addison Wesley, in prep. Online at http://members.aol.com/humansandt/crystal/ clear.

[Cs] Csikszentmihalyi, M., Flow: The Psychology of Optimal Experience, Harper Perennial, 1990

[C3] The C3 Team, “Chrysler goes to ‘Extremes’”, in Distributed Object Computing, October, 1998, pp. 24-28.

[Dm] DeMarco, T., Lister, T., Peopleware 2nd Edition, Dorset House, 1999.

[EP] Extreme Programming, web notes, start from www.extremeprogramming.com.

[Gr] Gries, D, The Science of Programming, Springer Verlag, 1987.

[Ha] Harel, D., Politi, M., Modeling Reactive Systems with Statecharts, McGraw-Hill, 1998.

[Hi] Highsmith, J., Adaptive Software Development, Dorset House, 1999.

[Ho] Hovenden, F., “An ethnographic account of writing use cases on an IT project”, Humans and Technology Technical Memo, 1999.10.30, online at http://members.aol.com/humansandt/papers/ethno1.htm.

[Hu] Humphrey, W., A Discipline for Softwrae Engineering, Addison Wesley, 1995.

[Je] Jeffries, R., “Extreme testing”, in Software Testing and Quality Engineering, March/April, 1999, pp. 23-26.

[J-L] Johnson-Laird, P. and Byrne, R. Deduction, Lawrence Erlbaum Associates, 1991.

[La] Lave, J., Situation Learning: Legitimate Peripheral Participation, Cambridge Press, 1991.

[Mi] Mills, H., Dyer, M., Linger, R., “Cleanroom Software Engineering,” IEEE Software Vol 2 (1984) No. 9, 19-24.

[NASA] JSC38609, “Deorbit flight software lessons learned”, NASA Johnson Space Center, Jan 19, 1998 online at

[Pi] Piatelli-Palmarini, M., Inevitable Illusions : How Mistakes of Reason Rule Our Minds, Wiley & Sons, 1996.

[Pl] Plowman, L., “The interfunctionality of talk and text”, Computer Support of Cooperative Work, vol. 3, 1995, pp.229-246.

[Si] Sillince, J.A., “A model of social, emotional and symbolic aspects of computer-mediated communication within organizations”, Computer Support of Cooperative Work vol. 4, 1996, pp. 1-31.

[Web] Webb, D., Humphrey, W., “Using TSP on the TaskView Project”, in CrossTalk, The Journal of Defense Software Engineering, Feb 1999, pp. 3-10, online at http://www.stsc.hill.af.mil/crosstalk/1999/feb/webb.asp

[Wei] Weinberg, J., The Psychology of Computer Programming, Silver Edition, Dorset House, 1998.

[Yo] Yourdon, E., Death March Projects, Prentice Hall, 1997.

Auteur : Alistair Cockburn
Source : Characterizing people as non-linear, first-order components in software development
Date de parution originale : 21 octobre 1999

Traducteur : Nicolas Mereaux
Date de traduction : 26/01/2026

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

Traduction faite main sans IA.

Logo « Fait (Hu)Main » par Lazar Baruk

Les design patterns ou patron de conception sont un ensemble de solutions standards ou de bonnes pratiques pour répondre à des besoins récurrents en terme de programmation - pour en savoir plus, vous pouvez consulter cet article Wikipedia ↩
L’expression est difficile à rendre en français. Le terme original est “for deriving correct programs” fait référence, via l’ouvrage de David Gries, à une méthode préconisée par Edsger W. Dijkstra d’obtenir un exécutable à travers la dérivation d’une spécification écrite avec un langage formel (c’est-à-dire utilisant une notation mathématique) d’un programme informatique en spécification technique - NdT ↩
La métaphore dont s’inspire cette méthodologie est celle de la salle blanche en électronique où tout est fait en terme de prévention des anomalies, pour en savoir davantage, vous pouvez consulter cet article Wikipedia ↩
Le Personal Software Process ou Processus personnel informatique est un processus de développement logiciel ↩
Il s’agit du projet qui fût le terrain de jeu d’Extreme Programming, qui consistait à refondre la gestion de la paye de l’entreprise Chrysler ↩
CMM - Capability Maturity Model est un modèle permettant de mesurer le degré de maturité d’un projet en terme de compétences, processus et techniques ↩
le concept de « bon citoyen » en entreprise va au-delà de la conscience professionnelle. La dénomination complète du concept est celle de « comportement de citoyenneté organisationnelle », pour en savoir plus, vous pouvez consulter cet article Wikipedia en anglais ou cet autre c’est par ici en anglais ou par là en français ↩
Le flux ou le flow (le terme anglais se retrouve aussi utilisé en français) est un état mental particulier décrit par Mihaly Csikszentmihalyi dans son ouvrage Flow: The Psychology of Optimal Experience ; pour en savoir plus sur cet état mental, vous pouvez consulter cet article sur Wikipedia. ↩

Une autre manière de visualiser le modèle du changement de Satir

Sun, 26 May 2024 00:01:00 +0000

Some years back I had a conversation with Bas Vodde about the graphical way that the Satir Change Model is usually represented. If you search on the internet, you’ll likely to end up at Steve Smith’s description, which is very good but shows “performance” as if it’s a measurable thing. While at the UNC Satir Summer Intensive workshop in 2018, I thought about a different way to view the process of change. This view is less from an external point of view, and more from the point of view of the person going through the change. Rather than a graph, it’s a map of the journey from the Old Status Quo to the New Status Quo.

Il y a quelques années, je discutais avec Bas Vodd sur la manière dont est habituellement représenté graphiquement le modèle du changement de Satir. Si vous cherchez sur internet, il est fort probable que vous finirez par arriver sur la représentation et la description proposée par Steve Smith (vo,vf) qui est en soi très bonne mais qui montre la « performance » comme quelque chose de mesurable. En 2018, lors d’un atelier UNC Satir Summer Intensive, j’ai réfléchi sur une autre manière de le représenter. Cette représentation l’est moins d’un point vue externe et davantage du point de vue de la personne qui vit ce changement. Plutôt qu’un graphique, il s’agit d’une carte d’un voyage de l’Ancien Status Quo au Nouveau Status Quo.

Late Status Quo

Imagine you’re sitting at home, minding your own business. It may not be the life of your dreams; it may not even be without pain and annoyances, but you’re accustomed to the way things have been going.

Dernier Status Quo

Imaginez que vous êtes assis chez vous, réfléchissant sur à vos sujets de préoccupations. Vous n’avez peut être pas complètement la vie dont vous rêviez ; elle n’est peut-être pas sans douleurs ni peines, mais vous êtes habitué à la manière dont les choses se passent

Foreign Element

Élément étranger

Then something happens that upsets the apple cart and drives you out of your recent status quo. This may be an internal event, such as deciding that your status quo isn’t good enough, but it’s most often externally triggered. Something may have happened that revealed your status quo wasn’t good enough for you any more. Something may have happened that destroyed your status quo–perhaps you were let go from your job, a loved one rejected you, or, as shown here, your house was struck by lightning and burned down with all your possessions.

Puis quelque chose se passe qui bouscule les habitudes et qui vous sort de votre status quo. Il peut s’agir d’un évènement interne, où vous décidez que votre status quo n’est plus satisfaisant, mais il s’agit le plus souvent d’un élément extérieur. Quelque chose qui s’est produit qui fait que votre status quo ne vous satisfait plus. Quelque chose s’est passé qui a détruit votre status quo — peut-être que vous avez été licencié, qu’un de vos proches vous a rejeté, ou comme le montre ce dessin, votre maison a été frappé par un éclair et a provoqué un incendie qui a tout brûlé.

Chaos

Whatever the cause, your accustomed routine is disrupted, and you have to do something different. Your available choices may seem unpalatable. Should you head into the deep woods, or wade through the swamps? The desire to turn around and go back to the way things were is very strong, even if impossible.

Quelle qu’en soit la cause, votre routine habituelle est bousculée et vous devez faire quelque chose de différent. Les choix à votre disposition peuvent être à première vue peu agréables. Devriez-vous vous enfoncez dans cette forêt obscure ou traversez ces marais ? Le désir de faire demi-tour et de revenir à la situation d’avant est très forte même si cela est impossible.

At this point you may be tempted to turn back to the remains of your old status quo, no matter how uncomfortable that might be. Camping next to your charred house? That could seem preferable to pushing ahead into the unknown, even if it’s sure to lead to a depressing future.

À ce stade, vous pouvez être tenté de revenir vers ce qui reste de votre ancien status quo, aussi inconfortable que cela puisse paraître. Faire du camping à côté de votre maison carbonisée ? Cela pourrait sembler être préférable plutôt que de s’enfoncer dans l’inconnu, même si c’est certain que cela vous mène vers un futur déprimant.

Transforming Idea

Idée transformante

If you continue to push forward through the chaos, crossing the river into new territory and climbing up the steep ridge, you’re likely to reach the Transforming Idea and lets you see the situation in a different light. In this map, the Transforming Idea is represented as a ridge line that lets you see further than you have been, and perhaps see new possibilities for the future. With a vision of a New Status Quo, you can focus on moving forward rather than back to your lost past.

Si vous continuez à vous enfoncez à travers le chaos, après être arrivé dans un nouveau territoire en traversant la rivière et grimper un sommet escarpé, vous atteindrez probablement une Idée Transformante et vous verrez la situation avec un éclairage différent. Sur cette carte, l’Idée Transformante est représentée par une ligne de crêtes qui vous laisse voir au-delà de tout ce que vous connaissiez avant, et peut être voir de nouvelles possibilités pour le futur.

Practice and Integration

Pratique et intégration

You’re not completely out of the woods, yet. There’s still work to do before reaching that vision. You may have to learn new skills and techniques to make it possible. You need to practice those skills and integrate them into your sense of normal life. The Transforming Idea may have shown you that you need to detour to reach the place you desire.

Vous n’êtes pas encore sorti complètement de la forêt. Il y a encore du travail à faire avant d’atteindre cette vision. Vous devrez apprendre peut-être de nouvelles compétences et de nouvelles techniques pour rendre cela possible. Vous devez mettre en pratique ces compétences de telle sorte qu’elle fasse partie intégrante de votre vie quotidienne. L’Idée Transformante vous a peut être montré que vous auriez à faire un détour pour atteindre l’endroit que vous souhaitez

New Status Quo

Nouveau Status Quo

Finally you reach a place where your rate of change slows down and you can settle into a New Status Quo. The Practice and Integration has made this a more comfortable place to rest until the next Foreign Element propels you onward. The New Status Quo is not guaranteed to be better than the Late Status Quo, but it is different.

Note that smaller changes are generally easier to accommodate. Also, more frequent changes tend to be smaller. And foreign elements that you’ve chosen are more likely to lead to an improved status quo than are externally imposed ones, if only because conscious choice tends to prefer better over worse.

Ayez à l’esprit que de petits changements sont généralement plus facile à appréhender. Et aussi, que plus les changements sont plus ils ont tendance à être de plus petite taille. Et aussi que les éléments étrangers que vous avez choisis (d’intégrer - NdT) vous amèneront vers un meilleur status quo que ceux qui vous sont imposés, ceci en raison que vous avez fait le choix conscient de préférer le meilleur au pire.

Auteur : George Dinwiddie
Source : Another Visualization of the Satir Change Model Date de parution originale : 17 Mai 2024

Traducteur : Nicolas Mereaux
Date de traduction : 31/12/2023

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

3 éléments clés pour un coaching agile efficace : niveau, empathie et expérience

Wed, 24 Apr 2024 00:01:00 +0000

Lors de la réunion d’Agile New England (ANE) de la nuit dernière, un coach agile a posé ces questions « Quel est mon avenir en tant que coach agile ? Qu’est-ce que je vais pouvoir faire ensuite ? »

Ce sont de très bonnes questions, que chaque coach pourrait (se) poser pour être certain de continuer à apporter de la valeur à leurs clients (qu’ils soient internes ou externes, tous les coachs ont des clients).

J’ai déjà évoqué le fait que si un coach voulait monter dans la hiérarchie d’une entreprise, il se devait d’avoir une certaine expérience du management.

J’avais seulement en partie raison. L’expérience nous apprend à voir et à ressentir la pression que nos clients eux-mêmes peuvent avoir. Cela peut aider les coachs, mais tous les coach en entreprise n’ont pas besoin d’avoir exactement la même expérience que leurs clients.

Mais tous les coachs doivent :

Comprendre le(s) niveau(x) au(x)quel(s) le client veut que le coach intervienne
Faire preuve d’empathie vis-à-vis du client quant à la pression qu’il subit en lien avec sa position dans la hiérarchie
Être focalisé sur des résultats professionnels en lien avec l’entreprise, ce qui ne veut pas forcément dire agile

Commençons par les niveaux.

À quel niveau êtes-vous supposé influencer ?

Les coachs utilisent leur influence pour accompagner un changement chez le client. Même s’ils pourraient être en capacité de transmettre des savoirs via un enseignement formel dans le cadre de leur travail, l’enseignement ne fait pas partie de l’activité principale d’un coach.

Si vous n’avez pas l’expérience dans une fonction similaire à celle de votre client, vous pourriez avoir quelques difficultés à montrer votre compétence (vo), à établir avec lui la confiance (vo) et à vous découvrir des intérêts communs (vo). (En tant que coach, vous pourriez très bien représenter d’autres personnes aux yeux de votre client.)

Ne pas faire ses preuves sur l’un de ces niveaux (compétence, confiance, et intérêts communs) signifie, pour un coach censé coacher à différents niveaux, échouer tout simplement sur tout ou partie de ces niveaux.

Même si tout le monde est en mesure de se sentir sous pression lorsque quelqu’un dit « faites-en plus !!! », tout le monde ressent la pression différemment.

Les équipes peuvent se sentir sous pression à la vue d’un backlog trop gros ou d’une feuille de route trop grande. Les coachs peuvent être en mesure de soutenir localement voire un peu plus loin des actions pour alléger cette pression
Les personnes qui facilitent des actions sur des périmètres plus importants, comme les responsables produits, les responsables de portefeuilles, et la plupart des cadres intermédiaires ressentent la pression de « livrer » ou de « performance ». Trop souvent, ces personnes s’entendent dire « Je me fiche de la manière dont vous le faites, faites-le. »
Les cadres supérieurs ressentent la pression à livrer, mais trop souvent, cette pression se porte à un niveau davantage individuel. Autrement dit, les postes des cadres supérieurs se retrouvent sur un siège éjectable s’ils ne « livrent » pas.

Lorsqu’il m’est arrivé d’être dans cette position, ma première pensée fût : « Pendant combien de mois encore dois-je rembourser l’emprunt de ma maison (ou si vous n’avez pas d’emprunt immobilier, vous pouvez le remplacer par n’importe quelle autre dépense d’argent importante à vos yeux) ? »

C’est la raison pour laquelle je ne vois pas beaucoup de coachs réussir lorsqu’ils se retrouvent à travailler soit avec des équipes sur la manière de faire un certain travail, soit avec des cadres intermédiaires sur la manière de gérer toutes les initiatives qu’ils doivent gérer (surtout si celles-ci n’aboutissent pas), soit avec les cadres supérieurs sur l’entreprise elle-même. Je suis certain que certaines personnes peuvent réussir à ces différents niveaux. La plupart ne le peuvent pas. Et tout spécialement si vous avez seulement l’expérience du travail d’équipe et celle de la facilitation d’équipe, comme c’est le cas pour un Scrum Master.

Être en capacité de gérer plusieurs niveaux pour des coachs est un problème identique à celui que rencontre des responsables hiérarchiques lorsque ceux-ci doivent spécifier à la fois les niveaux tactiques et stratégiques (vo) d’une fiche de poste. Cela ne fonctionne pas car c’est trop difficile pour la plupart des gens.

Les coachs peuvent réussir lorsqu’ils ont l’expérience et qu’ils limitent le nombre de niveaux sur lesquels ils sont censés intervenir. À condition qu’ils y mettent de l’empathie.

Faites preuve d’empathie vis-à-vis de vos clients

J’ai pu constater, avec le temps, que les organisations engendrent un niveau de pression à peu près identique sur des personnes situées à des niveaux similaires dans la hiérarchie. En effet, l’organisation engendre son propre système. Ou comme le dit Paul Batalden :

« Chaque système est parfaitement conçu pour obtenir les résultats qu’il obtient »

C’est pourquoi des personnes a des niveaux similaires ressentent un niveau de pression à peu près identique. Non pas parce que les gens sont méchants, stupides ou ont tort d’une manière ou d’une autre. Mais parce qu’ils travaillent au sein d’un système que le coach est supposé aider à changer.

C’est un défi de taille.

C’est pourquoi tous les coachs doivent être en mesure de comprendre les résultats qu’ils aident à atteindre à travers le client.

Définir les résultats

Personne ne veut « être agile ». Les gens veulent les résultats que l’agilité leurs offre.

À quoi peuvent bien ressembler ces résultats ? Cela dépend de votre organisation, mais voici certains résultats que mes clients veulent :

Des livraisons plus fréquentes et plus rapides d’un produit ayant de la valeur afin que leurs clients soient en mesure de voir en quoi leur abonnement actuel est plus intéressant que d’aller chez la concurrence
Une capitalisation plus rapide pour des raisons financières
Des expérimentations plus fréquentes au niveau des backlogs et de la stratégie
Une meilleure prévisibilité sur ce qu’ils seront en mesure de livrer, même s’ils ne savent pas encore quoi.

L’agilité peut aider à atteindre ces résultats. Mais si le coach ignore que son client veut atteindre ces résultats, le coach dira d’eux : « Ça c’est agile » ou encore pire « Ça c’est pas agile ».

Tout le monde se moque de votre degré d’agilité. Tout le monde.

Mais personne se moque des résultats que l’agilité est supposé permettre d’atteindre.

C’est pourquoi les chemins à suivre pour les coachs dépendent de ce que vous voulez faire dans votre carrière.

Votre parcours de coach dépend des résultats que vous voulez atteindre

Quels sont les résultats que vous voulez atteindre au cours de votre carrière ? Je suis une généraliste du développement produit. C’est pourquoi j’ai des clients en tant que coach et en tant que consultante experte, mais je ne me limite pas à ces rôles. J’utilise la plupart des rôles présentés dans le tableau précédent avec mes clients.

Décidez de votre parcours de coach en réfléchissant aux résultats que vous voulez atteindre. (Oui, coachez-vous vous-même.)

Puis, évaluez votre expérience, le ou les niveaux sur lesquels vous souhaitez travailler et comment vous pouvez établir de l’empathie avec vos clients pour atteindre ces résultats. Que devez-vous changer pour devenir un coach agile encore meilleur ?

Auteur : Johanna Rothman
Source : Three Keys for Successful Agile Coaching: Level, Empathy, and Experience
Date de parution originale : 02 Décembre 2022

Traducteur : Nicolas Mereaux
Date de traduction : 24/04/2024

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

L'architecture hexagonale

Sun, 31 Dec 2023 00:01:00 +0000

Ou comment créer votre application de telle manière pour qu’elle puisse fonctionner sans interface utilisateur ou sans base de données vous donnant ainsi la possibilité d’y exécuter des tests de régression, pour qu’elle puisse fonctionner même en cas d’indisponibilité de la base de données, et enfin pouvoir l’interconnecter avec d’autres applications sans que l’utilisateur ait à faire quoi que ce soit

Avant-propos du traducteur : certains mots ou certaines expressions ont été laissées en anglais dans la présente traduction de part un usage plus répandu dans le langage courant. Toutefois pour satisfaire tous les lectorats possibles, des traductions françaises de ces mêmes mots ou expressions sont présentes en notes de bas de page.

Ce texte est aussi disponible :

en japonais http://blog.tai2.net/hexagonal_architexture.html
en espagnol http://academyfor.us/posts/arquitectura-hexagonal par Arthur Mauricio Delgadillo

L’article d’origine mis à jour est disponible à cette adresse http://wiki.c2.com/?HexagonalArchitecture et là http://wiki.c2.com/?PortsAndAdaptersArchitecture

Vous pouvez aussi consulter la FAQ sur l’architecture hexagonale (EN) (discussion: Re: Hexagonal Architecture FAQ)

Le modèle : Ports & Adapters¹ (« Structure de l’objet »)

Nom alternatif : « Ports & Adapters »
Nom alternatif : « Architecture hexagonale »

But recherché

Permettre à une application de pouvoir :

être pilotée indifféremment par des utilisateurs, des programmes, des tests automatisés ou par des traitements batchs,
être développée et testée de manière isolée de tout dispositif éventuel pouvant l’exécuter et de toute base de données.

Lorsqu’un pilote, quel qu’il soit, veut utiliser l’application sur un port donné, il envoie une requête qui sera convertit grâce à un adaptateur spécifique à la technologie utilisée par le pilote, en procédure d’appel ou en message utilisable, qui à son tour sera passé au port de l’application. Il est à noter que l’application est complètement ignare de la technologie du pilote.

Lorsque l’application a quelque chose à envoyer, elle le fait à travers le port vers l’adaptateur, qui à son tour créé le signal approprié attendu par la technologie réceptrice (humaine ou non). L’application a, sémantiquement parlant, des échanges avec les adaptateurs de tous côtés, sans vraiment connaître la nature des choses avec lesquelles elle communique de l’autre côté des adaptateurs.

Illustration 1 : L’architecture hexagonale

Motivation

L’un des plus grands écueils de ces dernières années dans le domaine informatique a été l’immixtion de la logique métier dans le code de l’interface utilisateur. Le problème engendré est de trois ordres :

Tout d’abord, il est impossible de tester le système de manière exhaustive avec des logiciels de tests automatisés car la partie de la logique qui doit être testée est dépendante de la partie visuelle dont les éléments sont amenés à changer régulièrement, comme, par exemple, la taille d’un champ de saisie ou le placement d’un bouton ;
Pour la même raison, il est impossible de remplacer une interaction humaine sur le système par des batchs ;
Et toujours pour la même raison, il est difficile voire impossible de permettre au programme d’être piloté par un autre programme si cela s’avérait intéressant.

La solution tentée dans beaucoup d’entreprises est de créer une nouvelle couche au niveau de l’architecture, avec la promesse que cette fois-ci, si pour de vrai, qu’aucune logique métier ne viendra fourrer son nez dans la nouvelle couche. Toutefois, comme il n’existe aucun mécanisme permettant de détecter une violation de cette promesse, l’entreprise découvre quelques années plus tard que cette nouvelle couche se retrouve parsemée de logique métier et le vieux problème refait surface.

Imaginez maintenant que « chaque » morceau de fonctionnalité que l’application offre soit rendue disponible à travers une API (interface d’application programmable) ou un appel de fonction. Dans ce type de situation, le département Test ou Assurance Qualité est en mesure d’exécuter des scripts de tests automatisés pour détecter que rien de nouveau n’est venu casser une fonction qui fonctionnait auparavant. Les experts métiers peuvent créer des cas de test automatisés, avant que les détails de l’interface utilisateurs soient finalisés, ce qui permettra de dire aux développeurs qu’ils ont fait leur travail correctement (et ces tests deviennent ceux exécutés par le département Assurance Qualité). L’application peut être déployée en mode « headless »², dans laquelle seule l’API est disponible. Dans ce cas de figure, seuls d’autres programmes peuvent utiliser les fonctionnalités de l’application — cela simplifie la conception générale des suites d’applications complexes, et cela permet aussi aux applications offrant des services B2B de faire appels à leurs fonctionnalités réciproques à travers la Toile sans interventions humaines. Enfin, cela permet aux tests de régression automatisés de détecter les violations faites à cette promesse de garder en dehors de la couche de présentation la logique métier. L’entreprise peut alors détecter, puis corriger cette infiltration.

Un autre problème analogue et tout aussi intéressant, existe dans ce que l’on désigne habituellement par le terme « l’autre côté » de l’application, autrement dit quand la logique applicative se retrouve assujettie à une base de données ou à un autre service externe. Lorsque le serveur de la base de données tombe, est en cours de maintenance ou est remplacé par un autre, les développeurs se retrouvent alors dans l’impossibilité de travailler en raison de cet assujettissement. Ce qui a pour conséquence d’engendrer des coûts liés au retard pris accompagnés souvent par des ressentiments entre certaines personnes.

Il n’est pas sûr que les deux problèmes évoqués de « chaque côté » soient liés, mais il y a une certaine symétrie entre les deux qui apparaît quant à la nature de la solution.

De la nature de la solution

En réalité, les problèmes du côté utilisateur et du côté serveur ont pour origine une même erreur de conception et de développement à savoir — l’enchevêtrement des logiques métier et des interactions avec des entités externes. L’asymétrie à exploiter n’est pas entre le côté « gauche » ou « droite » de l’application mais entre l’ « intérieur » et l’ « extérieur » de l’application. La règle à laquelle se plier est que le code qui s’occupe de la partie « intérieure » ne devrait pas déborder sur la partie « extérieure ».

Mettons de côté pour l’instant l’asymétrie gauche-droite ou haut-bas, nous voyons alors que l’application communique avec des agents externes à travers des « ports ». Le mot « port » est supposé vous évoquer, par analogie, le concept de ports des systèmes d’exploitation, dans lesquels tout périphérique respectant les protocoles d’un port peut y être branché ; il en est de même pour tout appareil électronique où là aussi tout périphérique compatible avec les protocoles mécaniques et électroniques d’un port peut y être branché.

Le protocole d’un port est défini par le but de la conversation entre deux appareils.

Le protocole prend la forme d’une interface de programmation d’application (API).

Pour chaque périphérique externe existe un « adaptateur » qui convertit la définition de l’API en signaux nécessaires à la bonne communication avec le périphérique et vice versa. Un interface homme-machine (IHM) est un exemple d’adaptateur qui convertit grâce à l’API du port les mouvements de la souris faits par un utilisateur. Parmi les autres adaptateurs qui peuvent se brancher sur le même port, citons les outils de tests automatisés tels que FIT ou Fitness, les outils de gestion de batchs, et bien sûr tout code permettant de faire communiquer différentes applications entre elles au sein ou à l’extérieur de l’entreprise.

Passons à une autre partie de l’application, imaginons que celle-ci communique avec une entité externe pour obtenir des données. Le protocole utilisé est généralement un protocole de base de données. Du point de vue de l’application, si la source de données change d’une base de données SQL à un fichier plat ou à n’importe quel autre type de base de données, la conversation qui se fait avec elle à travers l’API ne devrait pas changer. Des adaptateurs supplémentaires pour ce même port devraient donc inclure un adaptateur SQL, un adaptateur fichier plat et plus important encore un adaptateur vers une base de données « mock ³» (comme par exemple une base de données résidente en mémoire) et ne devraient donc pas dépendre de l’existence d’une vraie base de données.

La plupart des applications possèdent seulement deux ports : le premier permettant de dialoguer du côté utilisateur, le second du côté base de données. Cela leurs donne une apparence asymétrique ; il est donc logique, du moins en apparence, de vouloir mettre en place une architecture à une, deux, trois, quatre voire cinq couches.

Il existe deux problèmes avec ces représentations. Le premier et sans doute le pire est que les gens ont tendance à ne pas prendre au sérieux les « frontières » qui figurent sur la représentation des couches de l’architecture. Ils ont tendance à laisser la logique applicative empiéter au-delà de ses propres frontières, provoquant ainsi les problèmes mentionnés précédemment. Le deuxième, c’est qu’il y a peut-être, en réalité, plus que deux ports pour l’application, de telle sorte que l’architecture telle qu’imaginée au départ ne tient pas dans une représentation à une dimension.

L’architecture hexagonale, ou architecture ports et adaptateurs, résout ces problèmes simplement en faisant le constat de l’existence de cette symétrie dans ce genre de situation : à savoir que l’application à l’intérieure communique avec le monde extérieur à travers un certain nombre de ports. Les éléments figurant à l’extérieur de l’application peuvent être gérés de manière symétrique.

La forme de l’hexagone a été choisie car elle permet visuellement de mettre en avant

(a) l’asymétrie intérieure-extérieure et la nature similaire des ports de telle sorte que cela permet de s’affranchir des représentations en couche à une dimension et de ce que cela induit

(b) la présence d’un nombre défini de ports - deux, trois, ou quatre (quatre étant le nombre le plus fréquent que j’ai pu observer jusqu’à présent)

L’hexagone a été choisi non pas parce que le nombre six est important, mais plutôt parce qu’il permet aux gens de faire une représentation avec suffisamment d’espace pour y faire figurer les ports et les adapteurs dont ils ont besoin, de ne pas être restreint par une représentation à une dimension. L’expression « architecture hexagonale » provient de cette volonté d’avoir cet effet visuel.

Le terme « ports et adapteurs » s’appuie sur la nature même des « finalités » représentées sur le dessin. Un port représente une conversation définie. Il y a en général plusieurs adaptateurs pour un port donné, différentes technologies peuvent être branchées sur ce port, comme par exemple un répondeur téléphonique, une voix humaine, un téléphone fixe, une interface homme-machine, une suite de tests, un outil de gestion des traitements batchs, une interface http, une interface directe programme-à-programme, une base de données « mock » (en mémoire), une « vraie » base de données (peut-être même plusieurs bases de données, l’une en environnement de développement, une autre pour l’environnement de test et une autre encore pour l’environnement de production).

Dans l’application Notes que nous verrons après, l’asymétrie gauche-droite sera remise en évidence. Toutefois, l’objectif premier de ce pattern ⁴ est de mettre en avant l’asymétrie interne-externe en évoquant brièvement que tous les éléments externes sont identiques du point de vue de l’application.

Structure

Illustration 2 : Architecture hexagonale avec adaptateurs.png

L’illustration 2 représente une application avec deux ports actifs et pour chacun d’eux plusieurs adaptateurs. Ces deux ports représentent respectivement le côté relatif au contrôle de l’application et celui relatif à la récupération de données. Cette représentation démontre que l’application peut être pilotée indifféremment par un automate, par une suite de tests de non-régression au niveau système, par un être humain, par une application à distance en mode http, ou par une autre application en local. Du côté données, l’application peut être configurée pour s’exécuter découplée de toute base de données externes en utilisant une base de données en mémoire (un « mock »), ou encore une base de données de remplacement ; elle peut s’exécuter aussi avec une base de données de test ou de production. Les spécifications fonctionnelles de l’application, qui peuvent être faites sous la forme de cas d’utilisations, décrivent les interfaces de la partie interne de l’hexagone et non les technologies externes pouvant être utilisées.

Illustration 3 : Image de l’architecture hexagonale architecture dite de la porte de grange.gif

L’illustration 3 représente la même application selon une architecture en 3 couches. Pour simplifier l’illustration, seuls deux adaptateurs sont montrés pour chacun des ports représentés. Cette représentation illustre comment un ensemble d’adaptateurs s’intègrent dans les couches hautes et basses de l’application ainsi que la séquence d’utilisation des adaptateurs lors du développement du système. Les flèches numérotées montrent l’ordre dans lequel une équipe pourrait développer et utiliser une telle application :

À l’aide d’une suite de tests FIT pilote l’application et utilise une base de données « mock » (c’est-à-dire en mémoire) qui se substitue à la vraie base de données ;
Puis en ajoutant une IHM à l’application tout en continuant d’utiliser la « fausse » base de données ;
Lors des tests d’intégration, des scripts de tests automatisés (à l’aide par exemple de Cruise Control) pilotent l’application connectée à la vraie base de données qui contient de données de tests ;
En condition d’utilisation réelle, avec une personne utilisant l’application connectée à la vraie base de données avec de vraies données

Exemple de code

L’exemple d’application de calcul de remise commerciale ci-dessous, illustre de la manière la plus simple possible ce qu’est concrètement l’architecture ports et adaptateurs. Elle est accompagnée de la documentation FIT qui va bien.

discount(amount) = amount * rate(amount);

Dans notre adaptation, le montant est fourni par l’utilisateur et le taux par une base de données, il y a donc deux ports. Nous les implémentons en plusieurs étapes :

D’abord avec des tests sur la base d’un taux constant à la place d’une base de données « mock »,
ensuite avec une IHM,
ensuite avec une base de données « mock » qui pourra être remplacée par une véritable base de données.

Je tiens à remercier Gyan Sharma d’IHC de m’avoir fourni le code de cet exemple.

Étape 1: FIT App un-taux-constant-à-la-place-d’une-base-de-données

D’abord nous créons le cas de test sous la forme d’une table HTML (cf. documentation FIT pour plus d’informations à ce sujet)

TestDiscounter
amount	discount()
100	5
200	10

Il est intéressant de remarquer que les noms des colonnes deviendront les noms des classes et des fonctions dans notre programmes. Il existe différentes manières de faire dans FIT pour ne pas avoir à faire ces « programmeries », mais pour cet article nous mettrons cela de côté.

Sachant dorénavant ce que vont être les données de tests, nous allons créer l’adaptateur côté utilisateur et utiliser la fixture³ ColumnFixture disponible dans FIT :

import fit.ColumnFixture; 
public class TestDiscounter extends ColumnFixture 
{ 
   private Discounter app = new Discounter(); 
   public double amount;
   public double discount() 
   { return app.discount(amount); } 
}

C’est tout ce qu’il y a à faire pour l’adapteur. Nous allons ensuite exécuter les tests à partir de la ligne de commande (consultez la documentation FIT pour adapter cette commande à votre environnement). Dans notre cas, voici ce que nous allons utiliser :

set FIT_HOME=/FIT/FitLibraryForFit15Feb2005
java -cp %FIT\_HOME%/lib/javaFit1.1b.jar;%FIT\_HOME%/dist/fitLibraryForFit.jar;src;bin
fit.FileRunner test/Discounter.html TestDiscount_Output.html

FIT produit un fichier comportant des codes couleurs nous montrant les tests ayant réussis (ou échoués au cas où nous aurions fait une erreur de frappe en cours de route.)

À ce stade, le code est prêt à être enregistré dans votre processus d’intégration continue (Cruise Control ou autre), et à être ajouté à votre chaîne de compilation et de test.

Étape 2 : IHM App un-taux-constant-à-la-place-d’une-base-de-données

Le code étant un peu long à faire figurer ici dans son intégralité, je vais vous laisser créer votre propre IHM pour l’application Discounter. Pour vous aider, voici quelques-uns éléments-clés que doit contenir votre code :

...
 Discounter app = new Discounter();
public void actionPerformed(ActionEvent event) 
{
    ...
   String amountStr = text1.getText();
   double amount = Double.parseDouble(amountStr);
   discount = app.discount(amount));
   text3.setText( "" + discount );
   ...
 }

À ce stade, une démonstration de l’application peut être faite ainsi qu’un test de régression. Les adaptateurs du côté utilisateurs sont tous opérationnels.

Étape 3 (FIT ou IHM) APP fausse base de données

Pour créer un adaptateur remplaçable du côté base de données, nous créons une « interface » vers un dépôt, et plus précisément vers un générateur de dépôt (« RepositoryFactory ») qui produira soit une base de données de type « mock » soit une véritable base de données.

public interface RateRepository 
{
   double getRate(double amount);
 }
public class RepositoryFactory 
{
   public RepositoryFactory() {  super(); }
   public static RateRepository getMockRateRepository() 
   {
      return new MockRateRepository();
   }
}
public class MockRateRepository implements RateRepository 
{
   public double getRate(double amount) 
   {
      if(amount &lt;= 100) return 0.01;
      if(amount &lt;= 1000) return 0.02;
      return 0.05;
    }
 }

Pour insérer cet adaptateur dans l’application Discounter, nous devons mettre à jour l’application elle-même afin qu’elle puisse prendre en compte l’utilisation de l’adaptateur repository et que l’adaptateur côté utilisateur (que ce soit FIT ou une IHM) passe le dépôt (« repository ») en paramètre à utiliser (la vraie ou la fausse (« mock ») base de données) au constructeur de l’application. Vous trouverez ci-dessous l’application mise à jour ainsi qu’un adaptateur FIT qui passe un faux dépôt (le code de l’adaptateur FIT permettant de choisir de passer l’adapteur vers le vrai ou le faux dépôt est lui aussi trop long tout en n’apportant pas grand-chose en terme d’informations, je ne l’ai donc pas inclus dans la version ci-dessous).

import repository.RepositoryFactory;
import repository.RateRepository;
public class Discounter 
{
   private RateRepository rateRepository;
   public Discounter(RateRepository r) 
   {
      super();
      rateRepository = r;
    }
   public double discount(double amount) 
   {
      double rate = rateRepository.getRate( amount ); 
      return amount * rate;
    }
}
import app.Discounter;
import fit.ColumnFixture;
public class TestDiscounter extends ColumnFixture 
{
   private Discounter app = 
       new Discounter(RepositoryFactory.getMockRateRepository());
   public double amount;
   public double discount() 
   {
      return app.discount( amount );
   }
}

Ceci conclut l’implémentation de la version la plus simple possible de l’architecture hexagonale.

Vous pouvez consulter sur cette page une implémentation différente de l’architecture hexagonale à base de Ruby et de Rack

Notes de l’application

L’asymétrie gauche-droite

Le pattern ports & adapters est écrit délibérément en partant du postulat que tous les ports sont foncièrement similaires. Ce postulat est utile à un niveau architectural. En termes d’implémentation, les ports et les adapters peuvent être de deux ordres, que j’appellerai respectivement « primaire » et « secondaire » pour des raisons qui vous paraîtront bientôt évidentes. Il est également possible de les appeler adapters « pilote » et « piloté »

Le lecteur avertit aura remarqué que dans tous les exemples donnés des fixtures FIT sont utilisés pour les ports côté gauche et des mocks côté droit. Dans une architecture en 3 couches, FIT se situe au niveau le plus haut alors que le mock est au niveau le plus bas.

Ceci est à rapprocher de l’idée d’« acteurs primaires » et d’« acteurs secondaires » issues des cas d’utilisation. Un « acteur primaire » est un acteur qui pilote l’application (autrement dit de la faire sortir de son état de veille pour exécuter une des fonctions présentes). Un « acteur secondaire » quant à lui se voit piloté par l’application, soit pour en obtenir des informations soit pour simplement émettre une notification. La distinction entre « primaire » et « secondaire » repose sur qui va déclencher ou qui est en charge de la conversation.

L’adaptateur de test pour substituer un acteur « primaire » est tout naturellement FIT, ce framework étant conçu pour lire un script et piloter l’application. L’adaptateur de test pour substituer un acteur « secondaire » comme, par exemple, une base de données est tout naturellement un mock, étant donné qu’il est conçu pour répondre à des requêtes ou pour enregistrer les évènements de l’application.

Ces observations nous conduisent à suivre le diagramme de contexte des cas d’utilisation du système et à dessiner les « ports primaires » et les « adaptateurs primaires » du côté gauche (ou en haut) de l’hexagone et les « ports secondaires » et les « adaptateurs secondaires » sur le côté droit (ou bas) de l’hexagone.

Les relations entre ports & adapters primaires et secondaires et leurs implémentations respectives avec FIT ou à l’aide de mocks est quelque chose d’important à garder à l’esprit, mais elles devraient être utilisées comme étant une conséquence de l’utilisation de l’architecture ports & adapters, et non pour prendre un raccourci. Le bénéfice ultime d’une implémentation ports & adapters est la capacité d’exécuter l’application en mode isolé.

Cas d’utilisation et frontières de l’application

L’utilisation du pattern de l’architecture hexagonale permet de réaffirmer sur quelle est la manière privilégiée de rédiger les cas d’utilisation.

Une erreur assez répandue dans l’écriture des cas d’utilisation est de vouloir y mettre une connaissance implicite de la technologie utilisée en dehors des ports. Ces cas d’utilisations ont gagné à juste titre une mauvaise réputation dans l’industrie informatique comme étant trop longs, difficiles à lire, ennuyeux, peu fiables et coûteux à maintenir.

Si l’on réfléchit bien à l’architecture ports & adapters , nous pouvons voir que les cas d’utilisation devraient être écrit à l’intérieur des limites de l’application (autrement dit la partie interne de l’hexagone) pour spécifier les fonctions et les évènements supportés par l’application, et ce, quel que soit la technologie externe derrière. Dans ces conditions, les cas d’utilisations peuvent être plus courts, plus facile à lire, moins coûteux à maintenir et pérenne.

Combien de ports ?

Qu’est-ce qu’exactement un port ou ce qu’il n’est pas est largement une question de goût. D’un côté du spectre, chaque cas d’utilisation pourrait avoir son propre port, ce qui donnerait des centaines de ports pour différentes applications. De l’autre côté, on pourrait imagine fusionner tous les ports primaires et tous les ports secondaires de telle sorte qu’il n’y ait plus que deux ports, l’un du côté gauche et l’autre de côté droit.

Aucun de ces deux extrêmes ne s’avèrent optimal.

Le système météo, décrit dans cette partie des cas d’usages connus, possède quatre ports dits naturels : le flux météo, l’administrateur, les souscripteurs notifiés, la base de données souscriptrice. Un contrôleur de machine à café a quatre ports naturels : l’utilisateur, la base de données contenant les recettes et les prix, les distributeurs et le monnayeur. Un système pharmaceutique dans un hôpital pourrait en avoir trois : un pour l’infirmière, un pour la base de données des prescriptions, et un pour l’ordinateur pilotant la distribution de médicaments

À priori, il n’y a aucun risque particulier à se tromper à faire un « mauvais » choix du nombre de ports, cela reste une question d’intuition. J’ai tendance à favoriser un petit nombre de ports, deux, trois ou quatre ports comme évoqué précédemment et également ci-dessous dans les cas d’usages connus.

Cas d’usages connus

Illustration 4 : Exemple complexe de l’architecture hexagonale.png

L’illustration n°4 montre une application comportant quatre ports et pour chacun d’eux plusieurs adaptateurs. Cette illustration a été faite sur la base d’une application de surveillance relative aux alertes sismiques, tornades, incendies et inondations provenant du service de météorologie nationale, et qui, lorsqu’elles se produisent, notifie les populations sur leur téléphone ou sur leur répondeur. À l’époque où nous discutions de ce système, les interfaces de celui-ci étaient identifiées et abordées par « technologie, liées à leur objectif premier ». Autrement dit, il y avait une interface pour le déclencheur de données arrivant par le réseau filaire, une pour les données de notification à envoyer aux répondeurs, une interface pour l’IHM d’administration et une interface pour la base de données stockant les données des abonnés.

Les gens se tiraient les cheveux parce qu’ils devaient ajouter une interface http pour le service météorologique ainsi qu’une interface pour les courriels à destination des abonnés, et ils devaient aussi trouver une manière d’empaqueter et de désempaqueter leur suite applicative qui grossissait pour satisfaire les préférences de ses différents clients. Ils craignaient d’être bloqués lors d’une maintenance sans compter que les tests des nouvelles fonctionnalités devenaient un véritable cauchemar car ils devaient implémenter, tester et maintenir toutes les différentes versions demandées par leurs clients.

Les changements apportés en termes de conception a été d’une part d’élaborer les interfaces du système « par objectif » plutôt que par technologie, et d’autre part de faire en sorte que les technologies soient substituables (peu importe le côté) au niveau de chaque adaptateur. Ils ont alors immédiatement eu la possibilité d’inclure le flux http et la notification par courriel (les nouveaux adaptateurs sont identifiables sur l’illustration avec les lignes en pointillés). En rendant chaque application exécutable en mode headless à travers des API, ils ont pu à la fois ajouter un adaptateur « application-prêt-à-ajouter » et désempaqueter la suite applicative, permettant ainsi d’y connecter des sous-applications à la demande. Enfin, en rendant chaque application exécutable de manière isolée, à l’aide adaptateurs de tests, de mocks et de scripts de tests automatisés autonomes, ils ont ainsi acquis la capacité de faire des tests de non-régression de leurs applications.

Mac, Windows, Google, Flickr, Web 2.0

Au début des années 90, les applications Macintosh telles que les applications de traitement de texte devaient avoir des interfaces pilotables par API, afin que d’autres applications ou des scripts faits par des utilisateurs puissent accéder à l’ensemble des fonctionnalités des applications. Les applications de bureau sur Windows ont depuis évolué pour avoir les mêmes possibilités (à défaut de connaissances historiques suffisantes, j’ignore laquelle de ces deux plateformes a eu cette possibilité en premier, mais ce n’est pas important dans le cadre de cet article).

La tendance actuelle (en 2005) pour les applications web est de mettre à disposition une API et de permettre à d’autres applications web ainsi d’y accéder directement. Par exemple, il est possible de diffuser des données relatives aux crimes locaux sur une carte Google ou de créer des applications web qui incluent les fonctionnalités de Flickr d’archivage et d’annotations de photos.

Tous ces exemples portent sur le fait de rendre visible les API des « ports primaires ». Ils n’évoquent en rien l’existence de ports secondaires.

Sorties stockées

L’exemple ci-dessous a été écrit par Willem Bogaerts sur le wiki C2 :

« J’ai déjà été confronté par le passé à quelque chose de similaire, mais à l’époque c’était dû principalement à ma couche applicative qui avait fini à gérer des choses qu’elle n’avait pas vocation à gérer - en gros elle ressemblait à un véritable central téléphonique à l’ancienne. Mon application générait la sortie, la montrait à l’utilisateur et avait aussi la possibilité de la stocker. Le problème … mon problème étant qu’il n’était pas toujours nécessaire de la stocker. Donc mon application générait la sortie vers un tampon et la présentait à l’utilisateur. Celui-ci décidait alors s’il voulait la stocker, l’application la récupérait alors du tampon et la stockait pour de vrai.

En fait, cette situation ne me plaisait pas du tout. Puis je suis arrivé à une solution : mettre en place un contrôle de la (couche de) présentation avec des capacités de stockage. Aujourd’hui l’application n’oriente plus la sortie vers tel ou tel endroit, mais elle l’envoie au contrôle de la présentation. C’est ce dernier qui met en tampon la réponse et donne à l’utilisateur la possibilité de la stocker.

L’architecture traditionnelle en couche insiste pour que « l’IHM » et le « stockage » soient différents. L’architecture Ports & Adapters est en mesure restreindre la sortie de telle manière à ce qu’elle redevienne à nouveau simple « sortie » ».

Exemple anonyme extrait du wiki C2

« Sur l’un des projets que j’ai travaillés, nous avons utilisé le _SystemMetaphor_ pour un composant système stéréo. Chaque composant comportait des interfaces définies, chacune ayant un but spécifique. Nous avons été alors en mesure d’y connecter plusieurs composants ensemble pour ainsi dire de manière quasi-illimitée en utilisant simplement des câbles et des adaptateurs. »

Développement avec des équipes de grande taille distribuées

Ce cas d’usage de l’architecture hexagonale est en cours d’évaluation et ne peut donc pas être tout à fait considéré comme une utilisation éprouvée de ce pattern. Toutefois, il est intéressant de regarder en quoi il consiste.

Dans ce cas d’usage, les équipes sont réparties sur différents lieux géographiques, elles élaborent ensemble une solution logicielle à l’aide de l’architecture hexagonale à l’aide de FIT et de mocks afin que les applications ou les composants puissent être testés de manière indépendante. La compilation avec CruiseControl est faite toutes les demi-heures sur l’ensemble des applications à l’aide de la combinaison FIT + mock. Au fur et à mesure que le sous-système applicatif et les sous-systèmes de bases de données sont terminés, les mocks sont remplacés par de « vraies » bases de données de test.

Séparer le développement de l’IHM et de la partie applicative.

Ce cas d’usage de l’architecture hexagonale en est au tout début de son évaluation et ne peut donc pas vraiment être considéré comme une utilisation éprouvée de ce pattern. Regardons, lui aussi, en quoi il consiste.

Dans celui-ci, aucune décision n’avait été prise (au lancement du projet - NdT) tant au niveau de la technologie à utiliser qu’au niveau de la métaphore de navigation, par conséquent la conception de l’IHM s’avère pour l’instant immature. L’architecture des services côté back-end n’est non plus décidée pour l’instant et il y a de fortes chances que tout cela changera plusieurs fois dans les 6 mois à venir. Toutefois, le projet est officiellement lancé et l’horloge tourne.

L’équipe du côté logique applicative a créé des tests FIT et des mocks pour isoler l’application et créer des fonctionnalités testables et démontrables à ses utilisateurs. Lorsque les décisions concernant l’IHM et les services seront finalement prises, cela « ne devrait être qu’une formalité » d’ajouter ces éléments à l’application. Tenez-vous au courant en venant lire ici pour savoir comment cela avance (ou essayez vous-même de votre côté et écrivez-moi). Je vous invite à revenir régulièrement consulter cette partie si vous désirez savoir comment elle avance (ou vous pouvez aussi essayer de votre côté et m’écrire par la suite pour m’informer de vos propres travaux).

Patterns liés

Adapter

L’ouvrage « Design Patterns » comporte la description d’un pattern « Adapter » générique : « Convertir l’interface d’une classe en une autre interface que les clients attendent ». Le pattern Ports & Adapters est une utilisation spécifique du pattern « Adapter ».

Modèle - Vue - Contrôleur

L’implémentation la plus ancienne connue du pattern MVC a été en 1974 dans un projet Smalltalk. Il a connu au cours des années différentes variations, comme les patterns Model-Interactor et Model-View-Presenter. Toutes ces variations implémentent l’idée des ports primaires du pattern Ports & _Adapters_ mais pas celle des ports secondaires.

Objects Mocks et Loopback (rebouclage)

« Un objet mock est un “ agent double ”, il est utilisé pour tester le comportement d’autres objets. Tout d’abord un objet mock se comporte comme une fausse implémentation d’une interface ou d’une classe et en imite son comportement extérieur. Ensuite, un objet mock observe comment les autres objets interagissent avec ses méthodes et comparent le comportement observé avec le comportement attendu pré paramétré. Lorsqu’une divergence apparaît, un objet mock peut interrompre le test et rapporter l’anomalie. Si la divergence ne peut être rapportée lors des tests, un appel de méthode de vérification effectué par le testeur s’assurera alors que tous les attendus aient été atteints ou que les anomalies aient été rapportées » — extrait de la page http://MockObjects.com

Si les mocks sont implémentés conformément à ce qui avait été prévu, ceux-ci peuvent être utilisés (à part entière - NdT) au sein de l’application, et pas uniquement en tant qu’interfaces externes. Le périmètre initial des objets mock est de se conformer au protocole spécifié au niveau d’une classe donnée ou d’un objet donné. Je me suis permis d’emprunter leur mot mock car il s’agit de la description qui correspond le mieux à un substitut en mémoire pour un acteur secondaire externe.

Le pattern Loopback est un pattern explicite pour remplacer en interne un périphérique externe.

Pattern Pedestals (piédestal)

Dans son ouvrage « Patterns for Generating a Layered Architecture », Barry Rubel décrit un pattern permettant de créer un axe de symétrie pour contrôler un logiciel très similaire au pattern Ports & Adapters. Le pattern Pedestal incite à implémenter un objet représentant un périphérique matériel au sein du système et à lier ces objets ensemble dans une couche de contrôle. Le pattern Pedestal peut être utilisé pour décrire les deux côtés (interne et externe) de l’architecture hexagonale, mais il n’insiste pas sur la similarité au niveau des adapters. De plus, il a été écrit dans le cadre d’un environnement de contrôle industriel, il n’est pas évident de prime abord de voir comment il peut s’appliquer à des applications informatiques.

Vérifications

Le langage de pattern développé par Ward Cunningham pour détecter et gérer les erreurs de saisies des utilisateurs s’avère particulièrement bien adapté pour gérer les erreurs traversant les frontières de l’hexagone interne.

Inversion de dépendance (injection de dépendance) et SPRING

Le principe d’inversion de dépendance de Bob Martin (appelé également injection de dépendance par Martin Fowler) définit que « les modules de haut niveau ne devraient pas dépendre de modules de bas niveau. Les deux devraient dépendre d’abstractions. Les abstractions ne devraient pas dépendre de détails. Les détails devraient dépendre d’abstractions ». Le pattern d’ « injection de dépendance » de Martin Fowler donne quelques exemples d’implémentations. Ces derniers montrent comment créer des adaptateurs d’acteurs secondaires interchangeables. Le code peut être saisit directement, tel que cela est fait dans l’exemple de code dans cet article, ou utilisé via des fichiers de configuration puis le code équivalent est généré via le framework SPRING.

Remerciements

Je tiens à remercier Gyan Sharma d’Intermountain Health Care pour m’avoir fourni les exemples de code présents dans cet article. Je remercie également Rebecca Wirfs-Brock pour son ouvrage « Object Design » qui conjugué à la lecture du pattern « Adapter » dans l’ouvrage « Design Pattern » m’a aidé à comprendre ce qu’était l’architecture hexagonale. Merci aussi à toutes les personnes qui via le wiki de Ward m’ont donné de précieux commentaires sur ce pattern ces dernières années (et tout particulièrement Kevin Rutherford).

Bibilographie et lectures recommandées

FIT, A Framework for Integrating Testing: Cunningham, W., disponible en ligne à l’adresse suivante http://fit.c2.com, ainsi que l’ouvrage « Fit for Developing Software », aux éditions Prentice-Hall PTR, 2005 par Mugridge, R. et Cunningham, W.,

Le pattern « Adapter » figure dans l’ouvrage « Design Patterns », Addison-Wesley, 1995, pp. 139-150. par Gamma, E., Helm, R., Johnson, R., Vlissides, J.,

Le pattern « Pedestal » évoqué par Rubel, B. évoqué dans son ouvrage , et aussi dans « Patterns for Generating a Layered Architecture » écrit par , par Coplien, J., Schmidt, D., « PatternLanguages of Program Design », Addison-Wesley, 1995, pp. 119-150.

Le pattern « Checks » de W. Cunningham, W., disponible en ligne à l’adresse suivante http://c2.com/ppr/checks.html

Le « Principe d’inversion de dépendance » évoqué dans l’ouvrage « Agile Software Development Principles Patterns and Practices » de Robert C. Martin, Prentice Hall, 2003, dans le chapitre 11 « The Dependency-Inversion Principle » ainsi qu’en ligne sur la page http://www.objectmentor.com/resources/articles/dip.pdf

Le pattern d’ « Injection de dépendance » de M. Fowler disponible en ligne à l’adresse suivante http://www.martinfowler.com/articles/injection.html

Le pattern « Mock Object » de S. Freeman, S. disponible en ligne à l’adresse suivante http://MockObjects.com

Le pattern « Loopback » d’A. Cockburn disponible en ligne à l’adresse suivante http://c2.com/cgi/wiki?LoopBack

Les « cas d’utilisation » expliqués en détail dans « Rédiger des cas d’utilisation efficaces » par A. Cockburn, Addison-Wesley, 2001, ainsi que dans Cockburn, A.,« Structurer les cas d’utilisation à l’aide de buts », disponible en ligne à l’adresse suivante http://alistair.cockburn.us/crystal/articles/sucwg/structuringucswithgoals.htm

Commentaires provenant de l’ancien site :

Dans un de ses articles sur son blog While True André Boonzaaijer évoque une application élaborée avec l’ architecture hexagonale (discussion: Re: Hexagonal architecture)

Kevin Rutherford a écrit plusieurs articles sur l’architecture hexagonale que vous pouvez retrouver sur les pages suivantes :

Gravity and software adaptability
Hexagonal architecture
Databases as life-support for domain objects
Hexagonal soup

Timo a écrit ce bref article intitulé Wrap it thinly sur l’utilisation de l’architecture hexagonale conjointement avec le développement piloté par les tests.

Dans son ouvrage traitant des patterns Xunit Gerard Meszaros y évoque l’architecture hexagonale que vous pouvez retrouver à l’adresse suivante : http://xunitpatterns.com/Hexagonal%20Architecture.html.

Brian Anderson a écrit plusieurs articles de blog sur le sujet de l’architecture hexagonale dont voici les liens :

Success! - lien introuvable NdT
Problems with Smart Clients today - lien introuvable NdT
compile time vs runtime views - lien introuvable NdT
the use of symmetry in the hexagonal approach
Back to Hexagonal Architecture
some thoughts on the “Design Pattern” pattern
http://www.brianmandersen.com/blog/page/2/

La page d’origine sur l’architecture hexagonale est disponible sur le wiki de Ward Cunningham à l’adresse suivante http://c2.com/cgi/wiki?HexagonalArchitecture

Utah Code Camp Sept 19, 2009 : mission codage

L’application de calcul de remise commerciale,illustre de la manière la plus simple possible ce qu’est concrètement l’architecture ports et adaptateurs. Il est fourni avec la documentation FIT qui va bien.

discount(amount) = amount * discountRate(amount);

La variable amount est saisie par l’utilisateur ou provient du framework de test (ou d’un fichier)
La variate rate provient d’une base de données ou d’une base de données mock en mémoire

L’implémentation suit les étapes suivantes :

Les données en entrée proviennent du framework de test, une constante est utilisée pour le taux discountRate.
Les données en entrée sont saisies via une IHM, le taux discountRate est toujours une constante.
Les données en entrée proviennent soit des tests soit d’une IHM, le taux discountRate provient d’une base de données mock qui peut être dans le futur échangée avec une vraie base de données.

Implémentation en Ruby / Rack (sans Rails)

J’ai fait une petite version web de cette application que vous pouvez consulter à l’adresse suivante https://github.com/totheralistair/SmallerWebHexagon

Celle-ci utilise du côté gauche un navigateur, un pilote Rack ou simplement un pilote de test et du côté droit une constante, du code ou un fichier de base de données. Je l’ai écrite en 2014 pour montrer une implémentation simple mais concrète de cette architecture.

Autres discussions et implémentations

Vous pouvez bien sûr trouver d’autres ressources à propos de l’architecture hexagonale en cherchant via Google ou via Twitter notamment. Vous pouvez aussi consulter :

Cet article de Thierry Pierrain http://tpierrain.blogspot.fr/2013/08/a-zoom-on-hexagonalcleanonion.html
Le support de la présentation que j’ai pu donner à l’Utah Code http://alistair.cockburn.us/Hexagonal+Architecture+Keynote+at+Utah+Code+Camp+September+2009.pps
une autre axe de présentation de l’architecture hexagonale fait par Duncan Nisbet sous l’angle de prises de notes faites à sa propre intention [http://www.duncannisbet.co.uk/hexagonal-architecture-for-testers-part-1](https://web.archive.org/web/20220517045625/https://www.duncannisbet.co.uk/hexagonal-architecture-for-testers-part-1
Une courte vidéo d’une présentation que j’ai donné lors de la conférence Mountain West Ruby en 2010: Video of Alistairs hexagonal architecture CQRS lightning talk Mountain West Ruby Conference 2010 (discussion: Re: Video of Alistairs hexagonal architecture CQRS lightning talk Mountain West Ruby Conference 2010)
en recherchant directement sur Twitter à l’aide de ce lien https://twitter.com/search?q=%22hexagonal%20architecture%22
ce tweet http://twitter.com/andrzejkrzywda/status/267420878487310336
ce minuscule CMS implémentant l’architecture hexagonale (avec uniquement un port du côté utilisateur) https://github.com/totheralistair/SmallWebHexagon
Pat Maddox a fait un autre exemple intégrant architecture hexagonale, programmation évènementielle et le pattern CQRS https://github.com/patmaddox/hexarch2. Jetez-y un coup d’œil.
Un très bel échange vidéo sur l’architecture hexagonale et Rails entre BadrinathJanakiraman et Martin Fowler: http://thoughtworks.wistia.com/medias/uxjb0lwrcz
le récit d’une réflexion sur https://github.com/Lunch-box/SimpleOrderRouting/wiki/Logbook-4#day-15-october-27th-2014

Dépendances configurables, acteurs primaires et secondaires

(Lorsque j’ai imaginé ce pattern - NdT) j’ai essayé de faire en sorte que ce pattern soit vraiment symétrique, d’où l’hexagone. Toutefois en regardant plusieurs de ses implémentations, il est devenu clair avec le temps qu’il existe une asymétrie (ce qui rend l’architecture hexagonale fondamentalement différentes des autres patterns comme l’architecture en oignon). Cette asymétrie décrite précédemment (cf. l’asymétrie gauche-droite) rejoint le concept d’Ivar Jacobson d’acteurs primaires et secondaires et impacte la manière dont la Dépendance Configurable peut être implémentée comme nous pouvons le deviner sur ce dessin :

Configurable Dependency illustrated1-800pxV.jpg (discussion: Re: Configurable Dependency illustrated1-800pxV.jpg)

Cette différence entre acteur primaire et secondaire repose uniquement sur lequel des deux acteurs initie la conversation. Un acteur primaire connait le propos de cette conversation et l’initie avec le système ou l’application ; pour un acteur secondaire, c’est le système ou l’application qui connait le propos et qui initie la discussion avec autrui. C’est en réalité la seule différence entre les deux, du moins, au pays des cas d’utilisation en tout cas.

Au niveau de l’implémentation, cette différence est importante : quiconque initiera la conversation doit passer le relais à l’autre.

Dans le cas des ports de l’acteur primaire, le constructeur macro devra passer le relais à l’IHM, le framework de test ou au pilote de l’application et lui dire « allez, parle-lui ». L’acteur primaire parlera alors à l’app et l’app ne saura probablement jamais qui l’a appelé. (Ce qui est normal du point de vue des destinataires d’un appel).

En contraste, dans le cas des ports de l’acteur secondaire, le constructeur macro devra passer le relais à l’IHM, le framework de test ou au pilote à l’acteur secondaire identifié passé en paramètre à l’application, et c’est l’application qui saura désormais qui/quel est le destinataire de l’appel sortant. (Ce qui est là aussi normal lorsque l’on émet un appel).

Par conséquent, le système ou l’application sera construite différemment pour les ports des acteurs primaires et secondaires : d’une part ignorante et initialement passive pour les acteurs primaires et d’autre part avoir une manière de stocker et d’appeler les ports des acteurs secondaires.

Ces deux types de ports implémentent la Dépendance Configurable (discussion: Re: Configurable Dependency), mais de manière différente.

Voici un exemple simple d’un système à 3 ports comme une machine à café, une unité médicale de distribution par intraveineuse (cela paraît vraiment étrange d’ailleurs que les deux partagent la même architecture)

L’acheteur, l’harnais de test ou l’administrateur de l’hôpital est l’acteur primaire qui pilote le système
La base de données de recettes ou la base de données médicale est l’acteur secondaire qui délivre ses informations
Le système de distribution (café ou médicamenteux) est dans les deux cas des acteurs secondaires.

En conclusion : l’aspect primaire / secondaire d’un port ne peut pas être ignoré

Vous pouvez aussi vous reporter à la FAQ Architecture hexagonale (discussion: Re: Hexagonal Architecture FAQ)

Auteur : Alistair Cockburn
Source : Hexagonal architecture
Date de parution originale : 04 Janvier 2005

Traducteur : Nicolas Mereaux
Date de traduction : 31/12/2023

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

Ports et adaptateurs ↩
littéralement sans tête c’est-à-dire sans interface utilisateur ↩
un mock simule l’existence d’un véritable service comme une base de données, on peut employer en français le terme de simulacre ↩ ↩²
un pattern est une structure, un modèle permettant de répondre à certaines problématiques connues ↩

LeSS - Automatisation des tests

Sun, 06 Nov 2022 00:01:00 +0000

« Portail LeSS < Portail Excellence Technique

Tests manuels

Les développeurs agiles mettent en avant l’importance des tests automatisés. En effet, avec des cycles courts, l’exécution manuelle des tests de régression s’avère quasiment impossible. Cela signifie t-il qu’il n’y a pas du tout de tests manuels ? Non. Certains tests manuels sont toujours recommandés, même si ces tests diffèrent quelque peu des tests manuels faits à l’aide de scripts.

Automatiser les tests manuels

Les affirmations « Il est impossible d’automatiser des tests de pertes de connexion réseau » ou « Il est impossible d’automatiser des tests portant sur un problème matériel » reviennent souvent de la part des groupes produits. Notre réponse est généralement « Non ce n’est pas vrai » ou « Oui, vous pouvez faire ces types de tests. »

Elisabeth Hendrickson, l’auteur du mini-livre (vo) Exploratory Testing in an Agile Context ose d’ailleurs dire

Je pense que si vous êtes en mesure d’écrire un script de test manuel, c’est que vous êtes aussi en mesure de l’automatiser.

Il peut s’avérer difficile d’automatiser un test exactement de la même manière que s’il était fait manuellement. Par exemple, il est quasiment impossible de débrancher automatiquement un câble réseau pour un cas de test de perte de connexion. Par conséquent, un test automatisé se fait généralement de manière différente. À la place de débrancher physiquement un câble, le test automatisé va instruire le pilote réseau de répondre comme si le câble réseau avait été débranché.

Est-ce que ça vaut le coup d’automatiser tous les tests ? Selon Elisabeth Hendrickson :

Si un test est suffisamment important pour être scripté, et exécuté, il est alors suffisamment important pour être automatisé.

Pourquoi cela ? Le développement itératif et incrémental implique que le code ne soit pas figé en fin d’itération mais qu’il ait, à la place de cela, le potentiel d’être changé à chaque itération. Par conséquent, faire du test de régression manuel signifierait ré-exécuter la majorité des tests manuels à chaque itération. Il va sans dire que l’automatisation s’avère rentable rapidement.

Cela s’avère être particulièrement vrai sur le développement à grande échelle qui prône, entre autres, des équipes features et la propriété collective du code, et pour lequel le filet de sécurité offert par les tests automatisés est d’une importance capitale.

Faire quelques tests manuels

Automatiser tous les tests pourrait ne pas valoir le coût voire même ne pas être possible. Certains tests tels que ceux évoqués ci-dessous devront alors être faits manuellement :

Les tests nécessitant une appréciation et de la créativité de la part de quelqu’un, c’est-à-dire d’une personne capable de juger si l’interface s’apprête bien à des tests d’utilisabilité. Les tests exploratoires, par définition, ont besoin de quelqu’un pour décider de la prochaine étape à explorer.
Les tests nécessitant une action physique, par exemple dans le cas de tests d’un système ayant des configurations matérielles différentes. Cela peut être automatisé par le biais de la simulation, mais la vraie configuration matérielle pourrait s’avérer nécessaire pour l’exécution du test final.
Des tests coûteux par nature. Par exemple, exécuter des tests de capacité en environnement de production peut s’avérer trop coûteux et par conséquent ne sont exécutés tout au plus qu’une ou deux fois au cours de la vie du produit. Toutefois, ces tests ne font que retarder le risque. Il est nécessaire de s’attaquer à ces risques le plus tôt possible avec des tests moins coûteux - par exemple, en exécutant des tests de capacité sur une simulation de l’environnement cible - cela permettra que l’exécution du vrai test, qui lui est coûteux, ne soit que la vérification finale.

Pas de fausse dichotomie : essayez d’automatiser tous les tests, mais n’oubliez pas de faire des tests manuels lorsque c’est nécessaire.

Faire des tests exploratoires

Dans son ouvrage Perfect Software and Other Illusions about Testing, Gérald Weinberg évoque : « l’idée reçue quant à l’exhaustivité des tests, autrement dit il est possible de tout tester ! ». Ce n’est pas le cas. Le nombre de scénarios possibles à tester est pour ainsi dire infini et par conséquent automatiser tous les tests demanderait un effort d’automatisation infini. Essayez donc plutôt d’automatiser les tests déjà envisagés et consacrer du temps aussi efficacement que possible sur les tests exploratoires pour trouver des cas de tests non envisagés.

Vue globale du test exploratoire :

Qu’est-ce que le test exploratoire ? Dans un de ses articles, James Bach le définit comme étant « la combinaison de l’apprentissage, de la conception de tests et de l’exécution de tests en simultané » – Bach03(vo). Cela vient en contraste avec le test scripté traditionnel dans lequel la conception des cas de tests et l’exécution se font de manière séparée et séquentielle avec d’abord la conception et après l’exécution. Le test exploratoire a pour objectif d’utiliser le plus possible la créativité humaine lors de l’exécution des tests, d’en tirer des informations et de les utiliser pour prendre des décisions relatives à la conception des tests. Cela sera plus clair à l’aide de l’exemple suivant :

Imaginons que Gina soit en train de tester une application de modélisation 2D. Tout d’abord, elle commence par définir l’objectif de sa session de test exploratoire que l’on appelle une mission ou une charte. Sa charte est d’ « Explorer les changements de formes en déplaçant les points de contrôle ». Elle sélectionne une forme, la place sur le canevas, et y ajoute deux points de contrôle. Elle déplace l’un d’entre eux et observe ce qu’il se passe. En se basant sur ses observations (apprentissage), elle détermine quelle sera la prochaine étape (conception) et la réalise (exécution). La forme prend un nouvel aspect même si elle remarque que lors du déplacement des points de contrôle la forme a pris temporairement un nouvel aspect qu’elle n’aurait probablement pas dû avoir. Aussi, elle continue à les déplacer et à les déplacer jusqu’à ce qu’elle arrive à reproduire ce type de transformation accidentelle.

Dans cet exemple, il n’y a pas de script détaillé préconçu ou de cas de test mais plutôt un périmètre de test — une charte. La première étape est d’observer le système et à partir de cette observation de déterminer l’action suivante à savoir la conception des tests. Toutes les techniques traditionnelles de tests et toutes les heuristiques traditionnelles de tests sont utilisées lors de cette phase de conception.

Tests exploratoires

Tests automatisés

Créer des tests maintenables

« Les tests automatisés vont augmenter notre charge de maintenance des tests » est une objection que nous entendons régulièrement. Il est certain que la maintenance des tests vous coûtera un peu mais quelques techniques simples peuvent minimiser ce coût :

supprimer toute duplication à l’intérieur et à l’extérieur des tests
supprimer les tests
ne pas tester à travers une IHM
exécuter les tests fréquemment

Supprimer toute duplication à l’intérieur et à l’extérieur des tests

La duplication du code engendre un niveau de complexité, d’incertitude et d’anomalies supplémentaires — ayant pour conséquence un effort de maintenance supplémentaire. C’est vrai tout autant pour le code de test que pour le code en production. Vous pouvez vous éviter cela en supprimant toute duplication de code qui serait présente.

Les flux de travail de tests sont une forme répandue de duplication. Ils se présentent le plus souvent sous la forme d’un scénario parent avec tout un ensemble de cas de tests dérivés avec par ici ou par là quelques légères variations. Tous ces flux de travail de tests doivent être mis à jour. Ce type de duplication peut être évité avec des tests pilotés par les données qui se focalisent sur les règles métiers ou en séparant les éléments dans des bibliothèques de tests ou des fixtures.

Nous avons accompagné une équipe qui avait fait une erreur assez répandue au sein de beaucoup d’équipes — elle avait repoussé l’automatisation des tests à la fin de son itération. Il lui restait 4 jours avant la fin de l’itération et uniquement des tâches d’automatisation à faire. Lors de son itération précédente, ces tâches avaient été faites par un spécialiste des tests mais ces tâches devaient être faites dorénavant par l’ensemble de l’équipe.

Nous avons fait démarrer l’équipe avec un atelier d’une journée au cours duquel un spécialiste a formé et accompagné les différents membres de l’équipe. Après cet atelier, l’équipe s’est scindée en plusieurs groupes de deux personnes plus un groupe de trois personnes pour travailler sur l’automatisation des tests. Quelque chose d’intéressant s’est produit : les développeurs expérimentés de l’équipe se sont plaints du surcroit de travail nécessaire à cause de la duplication présente dans les tests. Avant ça, aucun d’entre eux ne l’avaient remarqué et le spécialiste des tests — qui n’avait pas beaucoup d’expérience en programmation — ne s’en était jamais soucié. Maintenant que toute l’équipe était impliquée, tout le monde s’en souciait et la qualité des tests s’est alors grandement améliorée.

Supprimer des tests lorsqu’ils n’apportent aucune valeur

Les tests servent plusieurs objectifs. Ils servent d’exigences, de vérifications et font aussi office de filet de sécurité pour prévenir la régression du système.

Lorsqu’un test existant n’est plus nécessaire — sachant qu’il n’est qu’une sous-partie d’un autre test — supprimez-le. Ne pas supprimer les tests superflus n’apporte rien mais augmentent par contre le travail de maintenance et diminuent la vitesse d’exécution des tests.

Éviter de tester à travers une IHM

Les interfaces utilisateurs (ou IHM) ont tendance à changer fréquemment. Exécuter vos tests à travers une IHM les rend vulnérables à ces changements, même s’il n’y a aucun changement dans la logique du test, cela augmente la charge de maintenance des tests.

Par conséquent, éviter de tester à travers une IHM et faites plutôt appel directement à la logique applicative à travers une API. Un autre avantage de faire cela est d’accélérer la vitesse d’exécution de vos tests car tester à travers une IHM s’avère généralement toujours très lent.

Exécuter les tests fréquemment

Il y a longtemps, nous avons travaillé avec une grosse équipe travaillant selon une approche en cascade. Le conseil habituel en automatisation de test est de sélectionner et d’automatiser uniquement les cas de tests les plus importants — par une équipe dédiée à l’automatisation des tests — après la livraison. Ils ont donc fait ça. À la fin de la livraison suivante, ils ont alors exécuté les tests et ... ils ont tous échoués. Mettre à jour tous les tests aurait pris trop de temps, alors ils ont décidé de tout tester manuellement.

Exécuter les tests une ou deux fois par livraison peut sembler efficace — car il y a moins de cycles CPU utilisés — mais entre deux livraisons beaucoup de choses auront changé, et par conséquent beaucoup de tests échoueront, ce qui aura pour conséquence de générer un gros travail de maintenance. Alternativement, exécuter les tests fréquemment — en utilisant un système d’intégration continue — utilisera davantage de cycles CPU mais il y aura moins de maintenance étant donné que la charge de correction des tests sera moindre. Si vous avez une forte charge de maintenance de tests, c’est probablement que vous ne les exécutez pas assez fréquemment.

Traiter les tests non fonctionnels comme des tests fonctionnels

Automatiser et exécuter de manière continue les tests non fonctionnels est quelque chose d’essentiel. Les retarder jusqu’au dernier moment signifie c’est prendre de très gros risques là où ça peut faire le plus mal. Par exemple, s’il est exigé que le système doit avoir un certain niveau de performance, il est nécessaire de le tester le plus tôt possible pour déterminer s’il atteint le niveau exigé, et de le tester de manière continue au fur et à mesure que de nouvelles fonctionnalités sont ajoutées pour s’assurer que le système ne régresse pas par rapport au niveau de performance exigé.

Les exigences non fonctionnelles sont souvent traitées de manière assez exotique - les gens croient qu’elles ne peuvent être ni spécifiées ni testées. C’est dramatique. Dans un atelier d’exigences, les exigences non fonctionnelles sont considérées de la même manière que les tests fonctionnels, et des tests d’exemples sont créés pour aider à la compréhension.

Exécuter de manière continue des tests qui prennent du temps à s’exécuter

Il est fréquent que les tests non fonctionnels ne puissent s’exécuter dans un cycle normal d’intégration continue parce qu’ils prennent trop de temps à s’exécuter - un test de stabilité peut prendre jusqu’à deux semaines. Certains groupes produits les retardent pour ainsi dire juste avant la livraison — créant ainsi un cycle de boucle de rétroaction à retardement. Ce n’est pas une bonne idée de procéder de cette manière.

Exécutez plutôt les tests qui prennent du temps de manière continue dans un cycle d’intégration continue plus lent. Traitez-les comme n’importe quel autre test. Lorsqu’ils échouent, informez les personnes ayant implémenté le code. Après qu’ils aient fait le nécessaire, récupérez le dernier exécutable et exécutez à nouveau les tests.

Utiliser la virtualisation ou les conteneurs

Afin d’accélérer les tests et de maintenir l’investissement matériel à un niveau raisonnable, maximiser l’utilisation de la virtualisation en utilisant VirtualBox ou VMWare. Une alternative à l’utilisation d’une machine virtuelle (qui n’est pas toujours très rapide à mettre en place ou à maintenir) est l’utilisation d’un conteneur virtuel linux tel que Docker.

Éviter d’utiliser des outils de tests commerciaux

Une fois nous avons accompagné une entreprise qui développait un outil commercial d’ « automatisation de tests » - et pour être plus précis un outil de test IHM. Quel avait été l’accompagnement demandé ? D’apprendre comment faire des tests automatisés pour l’aider à développer son outil de tests automatisés...

Une multitude d’outils commerciaux de tests existent. Nous avons rarement rencontré des gens qui en aient été réellement satisfaits. La plupart d’entre eux sont bien trop complexes, se focalisent davantage sur la production de tableaux de bord et la gestion plutôt que sur une automatisation robuste et satisfaisante des tests. Privilégiez plutôt les outils libres et dont le code source est ouvert, faits par des développeurs pour résoudre de vrais problèmes - plutôt que des outils commerciaux.

Voici une liste d’outils d’automatisation de tests communément utilisés :

Il en existe bien plus encore. La liste ci-dessus porte uniquement sur les outils les plus répandus, de nouveaux outils voient le jour régulièrement.

Auteur : The LeSS Company B.V.
Source : Test Automation

Traducteur : Nicolas Mereaux
Relecture : Fabrice Aimetti
Date de traduction : 06/11/2022

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

LeSS - Tests unitaires

Wed, 29 Jun 2022 00:01:00 +0000

« Portail LeSS < Portail Excellence Technique

Que sont les tests unitaires ?

Les tests unitaires sont des programmes informatiques écrits pour éprouver d’autres programmes (qui peuvent être désignés sous l’appellation Code sous tests, ou Code en Production) à l’aide de pré-conditions spécifiques et ainsi en vérifier le comportement attendu.

Les tests unitaires sont généralement écrits dans le même langage de programmation que le code testé.

Chaque test unitaire devrait être de taille réduite et ne devrait tester qu’une fraction du code de la fonctionnalité. Les cas de tests sont souvent regroupés en Groupes de tests ou en Suites de tests. Il existe de nombreux frameworks de tests unitaires. Les plus populaires, comme par exemple JUnit pour le langage Java et CppUTest pour les langages C/C++, suivent un schéma dénommé xUnit inventé par Kent Beck.

Les tests unitaires devraient aussi s’exécuter très rapidement. Généralement, on s’attend à ce qu’une centaine de cas de tests unitaires s’exécutent en quelques secondes.

Pourquoi faire des tests unitaires ?

L’objectif du test unitaire n’est pas de trouver des anomalies. Le test unitaire est une spécification des comportements attendus du code sous test. Le code sous test est l’implémentation de ces comportements attendus. Donc les tests unitaires et le code sous test sont utilisés pour vérifier l’exactitude de l’un par rapport à l’autre, ils se protègent ainsi mutuellement. Si quelqu’un change le code sous test, et que cela change le comportement attendu par l’auteur originel, le test échouera. Si votre code est couvert par un test unitaire cohérent, vous pouvez maintenir le code sans casser la fonctionnalité existante. C’est la raison pour laquelle Michael Feathers définit le code hérité/patrimonial comme étant du code sans test unitaire.

Le but du test unitaire est donc avant tout de protéger ce que nous avons implémenté plutôt que de trouver des anomalies, tout comme les pitons posés par un grimpeur le long de son ascension. Ces pitons sont là pour l’aider à sécuriser le parcours qu’il a déjà accompli.

Objectif du test unitaire

L’objectif du test unitaire peut être résumé ainsi :

Faciliter les changements
- Le test unitaire fait en sorte de protéger les comportements décidés par les développeurs qui se sont succédé afin qu’il soit possible de changer le code sans casser les fonctionnalités existantes.
Simplifier l’intégration
- Le test unitaire teste les unités de base du programme, autrement dit les fonctions et les classes. Le test unitaire fait en sorte de sécuriser les briques élémentaires pour qu’elles fonctionnent comme prévu. Lorsque ces unités de base sont intégrées ensemble, nous pouvons séparer ainsi les problèmes d’intégration (les problèmes de couplage) des problèmes internes des unités de base (les problèmes de cohésion).
Documentation
- Des tests unitaires bien écrits peuvent servir de documentation de la fonctionnalité du code sous test. Le test unitaire contient des informations que vous ne pouvez pas trouver dans le code testé, comme par exemple, l’objectif de la conception du développeur à l’origine du code, et de quelle manière le code est censé se comporter à l’exécution. Le test unitaire, à la différence de la documentation traditionnelle, ne "ment" pas. Parce que si le test unitaire ment, le test viendrait à échouer. Et dans ce cas, cela indique que le test ou le code est erroné.
Outil de conception
- Le test unitaire est aussi un outil de conception. Le test unitaire exige que le code soit testable dès sa conception. "Facile à tester" veut généralement dire "facile à utiliser". Cela signifie que le test unitaire peut être utilisé pour que la conception soit faite du point de vue de l’utilisation et non uniquement du point de vue de l’implémentation. Un code testable doit être davantage modulaire et avoir moins de dépendances. Ainsi, le test unitaire peut facilement ne concerner qu’une petite partie du code testé (un "unitaire") sans avoir à se soucier de la quantité impressionnante de dépendances qu’il pourrait y avoir. Par conséquent, le test unitaire peut être utilisé pour s’assurer que la conception ait comme caractéristique "une forte cohésion, un faible couplage".

Pourquoi à un niveau « unitaire » ?

"Oui, il est important d’utiliser des tests automatisés pour protéger les fonctionnalités existantes. Mais pourquoi cela doit-il être fait au niveau unitaire ?"

Il est légitime de vous poser cette question. Pourquoi n’utilisons-nous tout simplement pas de manière rigoureuse des tests fonctionnels automatisés ou des tests systèmes automatisés pour protéger le programme ?

Le coût total de possession — Le test unitaire se base sur le niveau d’abstraction du langage de programmation utilisé. Il s’agit juste d’un bout de code qui va tester un autre bout de code. Il n’a pas besoin de s’exécuter sur le même environnement que celui en production. Pour un langage compilé, il n’est même pas nécessaire d’utiliser le même compilateur que celui en production. Le coût de la création et l’exécution est très faible. S’il est conçu correctement, le coût de maintenance est aussi très faible. Vous pouvez ne pas avoir le même niveau de confiance pour un cas de test unitaire qui s’est exécuté avec succès que pour un cas de test fonctionnel. Vous pourriez avoir besoin de plusieurs cas de test unitaire pour avoir le même niveau de confiance. Mais le coût de tous ces petits cas de test unitaire reste malgré tout plus faible que celui de plusieurs cas de test fonctionnel.

Si le code source n'a bénéficié d'aucun test unitaire depuis les deux dernières années, il y aura un coût supplémentaire pour lui en appliquer un. Ce coût a deux origines principales :

Le coût d’application d’un framework de test sur le code du projet. C'est relativement plus facile pour des langages de programmation dynamique comme Python, Ruby ou Javascript. De manière générale, c’est aussi relativement trivial pour des projets Java ou C#. Cela peut être toutefois assez compliqué pour un projet C/C++. Que ce soit facile ou difficile, c’est un investissement à ne faire qu’une seule fois.
Le code source existant n’est pas testable car le code a été conçu au départ sans prendre en compte l’aspect testabilité. Appliquer des tests unitaires à ce type de code source implique souvent de devoir améliorer la conception existante. Mener cette amélioration implique non seulement une augmentation du coût concernant la création des tests, mais a potentiellement un autre coût qui est lié à l'introduction de nouvelles anomalies en changeant ladite conception. Par conséquent, l’introduction de tests unitaires pour un code source existant se doit d’être combinée avec d’autres types de travaux qui nécessiteront des modifications dans le code sous test — autrement dit lorsque le moment sera venu de changer ce morceau de code.

Qualité interne vs. Qualité Externe — Les tests automatisés de haut niveau comme les tests fonctionnels et les tests systèmes contrôlent la qualité externe du logiciel. La qualité externe permet de connaître le niveau de fonctionnement du logiciel par rapport aux exigences. En effet, les tests unitaires ne sont pas aussi efficaces que les tests fonctionnels pour protéger la qualité externe. Par contre, les tests unitaires s’assurent de la qualité interne du logiciel. La qualité interne veut dire ici la testabilité du code et permet de savoir jusqu’à quel niveau le code est protégé. Une conception testable est synonyme en général de bonne conception. D’autres types de tests automatisés ne remplissent pas ce rôle aussi bien que les tests unitaires.

Qualité du feedback — Après avoir passé un test fonctionnel, vous pouvez être confiant vis-à-vis de la fonctionnalité testée. Mais lorsque vous vous apercevez que le test échoue, vous devez généralement faire du déboggage pour trouver ce qui est erroné. Les tests unitaires peuvent vous donner une information plus précise sur ce qui fonctionne ou ne fonctionne pas.

Les tests unitaires étant sur le même niveau d’abstraction que le langage de programmation employé, tout devrait s’exécuter au niveau du micro-processeur et de la mémoire lors de l’exécution du test unitaire. Et comme chaque cas de test devrait être de petite taille, il devrait donc s’exécuter très rapidement. Ainsi, vous devriez être en mesure d’exécuter plusieurs centaines de tests unitaires en quelques secondes. En prenant en compte le temps de compilation ou de préparation, l’ensemble du processus d’exécution d’un test unitaire devrait prendre moins d’une minute.

Les tests unitaires devraient aussi être répétables. Si rien ne change d’une fois sur l’autre, l’exécution d’un test unitaire devrait toujours retourner le même résultat.

Si un test unitaire est très rapide et répétable, les développeurs peuvent l’exécuter aussi souvent qu’ils le veulent, par exemple toutes les deux minutes. Le test unitaire fournira en permanence aux développeurs des retours d’informations liés à la qualité. Cela permettra ainsi aux développeurs d’avancer à un rythme régulier et de se focaliser sur des choses plus importantes plutôt que de passer trop d’énergie sur des choses triviales.

Une structure de test automatisé acceptable devrait ressembler à une pyramide. À la base de la pyramide, il y a un grand nombre de cas de tests unitaires. Au milieu, des cas de tests d’intégration en moins grand nombre. En haut, seulement quelques cas de tests fonctionnels ou systèmes.

Idées fausses à propos du test unitaire

Le test unitaire n’est pas aussi vital que le code en production

Il est vrai qu’en fin de compte, c’est le code en production qui donne vraiment vie au produit. Mais la plupart des produits logiciels ont des cycles de vie évolutif. Le code n’est pas statique. Il change avec le temps. Un code sans test unitaire n’est pas suffisamment protégé lorsqu’une modification est faite. Le test unitaire contient aussi des informations importantes qui ne sont pas présentes dans le code en production.

Par conséquent le test unitaire est tout aussi important que le code en production. Il devrait être stocké dans le même dépôt de gestion du code source. Le test unitaire devrait d’ailleurs suivre les mêmes conventions de codage que le code en production.

Le test unitaire est fait par des ingénieurs tests

L’objectif du test unitaire n’est pas de trouver des anomalies. Techniquement, il vérifie plutôt que teste si le code sous test a implémenté le comportement voulu par le développeur qui l’a conçu. Donc le choix logique est de simplement laisser la même personne écrire à la fois le test et le code sous test.

Il est aussi encouragé d’avoir deux ou plusieurs personnes travaillant de concert pour programmer à la fois le test et le code sous test. Il existe plusieurs manières sympas pour programmer en binôme. Vous trouverez davantage d’informations à ce sujet dans la section développement piloté par les tests.

Vous pouvez écrire des tests unitaires sans changer le code sous test

Ce n’est pas toujours le cas. Si le code n’a pas une bonne testabilité, vous pourriez tout de même être capable techniquement d’écrire le test unitaire qui va avec. Mais un test unitaire qui a été écrit pour un code non-testable est généralement très difficile à maintenir et à comprendre. Par conséquent, il n’y a pas vraiment de raison d’en avoir un.

Le secret du test unitaire n’est pas d’écrire du test, mais d’écrire un code testable sous test. Nous voulons du code testable et facile à tester, ce qui s’avère une démarche gagnant-gagnant. Nous ne voulons pas de code non-testable et difficile à maintenir, ce qui serait une démarche perdant-perdant.

Je peux ajouter les tests unitaires plus tard

Eh bien, essayez donc de demander à des grimpeurs de mettre leurs pitons plus tard.

Schéma pour de bons tests unitaires

Pas de nouvelles, bonnes nouvelles

Si le test passe, il devrait afficher seulement OK (voire quelques points pour afficher son avancement). Aucune autre information n'est nécessaire.

Règle empirique :

Aucune intervention humaine ne devrait être nécessaire pour préparer l’exécution du test, exécuter les cas de tests ou en vérifier les résultats.

Et lorsqu’un test unitaire échoue, il devrait nous fournir toutes les informations nécessaires. L’objectif est de limiter la durée pendant laquelle vous êtes occupé à débogguer le code concerné.

Arranger, Agir, Auditer (Arrange, Act, Assert)

Un bon schéma à suivre en ce qui concerne les tests unitaires est "AAA" : Arrange (dans le sens de mettre en place), Act (dans le sens d’une action faite sur quelque chose) et Assert (dans le sens de contrôler).

Si vous pouvez repérer ce schéma dans chacun de vos cas de tests, vos tests devraient être facile à comprendre, et ils devraient s’avérer suffisamment spécifiques et aller droit au but. Un cas de test unitaire devrait tester une seule et unique chose. Par conséquent, il devrait y avoir un seul AAA dans un cas de test. Un cas de test ne devrait pas être très prolixe (c’est-à-dire plus de 10 lignes de code) s’il suit le schéma AAA.

import unittest class TestGroupForTextWrapping(unittest.TestCase):

def test\_pas\_de\_retour\_à\_la\_ligne\_lorsque\_longueur\_de\_la\_chaîne\_de\_caractères\_de\_5\_et\_largeur\_de\_la\_ligne\_de\_10(self):
     \# Arrange :  Mettre en place toutes les préconditions nécessaires ainsi que les entrées.
     wrapper = TextWrapper(width=10)

     \# Act :  Agir sur l'objet ou sur la méthode sous test.
     wrapped = wrapper.wrap(&quot;a&quot; * 5)

     \# Assert :  Contrôle que le résultat attendu s'est bien produit.
     self.assertEqual(\[&quot;a&quot; * 5\], wrapped)

Développement piloté par le comportement (BDD)

Identique au schéma AAA, le BDD utilise trois mots-clés différents pour spécifier chaque cas de test : Étant donné, Lorsque et Alors. (Vous pouvez aussi utiliser Et comme mot-clé supplémentaire)

Given / Étant donné que la longueur du texte pour le retour à la ligne
est défini à 10  

And / Et que le caractère \'-\' est utilisé comme
connecteur entre deux mots

When / Lorsque la longueur du texte est
inférieure à 10

Then / Alors le texte ne devrait pas être retourné à la
ligne`

Comme vous pouvez le constater, le triptyque "étant donné - lorsque - alors" s'allie plutôt bien avec le triptyque "Arrange - Act - Assert". Ils définissent tous les deux un état transition d’une machine à état finie. Vous pouvez en savoir plus en consultant cet article d’Oncle Bob. Voici quelques différences entre les deux :

Le BDD est davantage orienté "dehors vers dedans", cela veut dire qu’il met davantage l’accent sur le comportement externe
Avec le BDD, vous devez définir un langage spécifique au domaine pour écrire vos spécifications de tests. À cause de cela, vous aurez besoin généralement d’un framework supplémentaire. Par exemple, pour Python vous pourrez utiliser behave.

La règle d’or du test unitaire

De manière générale, une bonne règle d’or pour des tests unitaires serait :

Chaque cas de test unitaire devrait comporter un périmètre très restreint.

De telle manière que … :

Lorsque le test échoue, qu’il ne soit pas nécessaire de faire du déboggage pour localiser le problème.
Les tests soient stables car les dépendances sont limitées.
Il y ait moins de duplications, que ce soit plus facile à maintenir.

Il n’existe pas de secrets pour écrire un bon test unitaire. Afin d’écrire un bon test unitaire, vous devez créer une conception qui soit facile à tester.

Auteur : The LeSS Company B.V.
Source : LeSS - Unit Testing

Traducteur : Nicolas Mereaux
Relecteur : Fabrice Aimetti Date de traduction : 29/06/2022

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

Quelques heuristiques pour une organisation efficace : une liste en constante évolution(*)

Mon, 30 May 2022 00:00:00 +0000

Note du traducteur : une première traduction de cette liste d’heuristiques existe sous la forme d’un commentaire dans l’article originel. La liste ayant changé depuis cette 1ère traduction, des différences existent donc avec la présente traduction.

En l’absence de sécurité psychologique, de respect et de confiance, aucun des éléments suivants n’est possible.
La manière dont nous travaillons, le travail que nous faisons, et les organisations au sein desquelles nous travaillons font partie d’un système connecté. Vous ne pouvez rien changer sans tout changer. Vous ne pouvez pas améliorer un système en bricolant sur des parties dudit système.
Les processus existent pour être au service des individus ; les individus viennent avant tout. Les processus, qui ne sont pas développés par les personnes qui les utilisent, fonctionnent rarement si ce n’est pas du tout.
Les meilleures façons de travailler sont collaboratives. La négociation n’est pas de la collaboration. Des personnes seules qui déploient des efforts héroïques pour réussir ne seront jamais aussi efficaces que des groupes collaboratifs. Nous obtenons les meilleurs résultats lorsque les clients, les gens du métier et les développeurs travaillent littéralement ensemble.
Accueillez le changement – au sein des organisations, des processus, des produits, des plans – n’importe quand. Vous ne pouvez pas être simultanément rigide et agile.
Les résultats finaux comptent plus que le volume produit. Être concentré uniquement sur le volume produit conduit à des résultats médiocres.
Le travail intellectuel a des préoccupations qui lui sont propres, qui n’ont rien à voir avec celles d’une usine ou d’un chantier de construction.
Les organisations les plus efficaces sont des organisations apprenantes. Apprendre — à la fois sur les produits que nous produisons et sur la manière dont nous les produisons — se fait de manière continue. Apprendre n’est pas seulement une activité normale dans le cadre du travail, il s’agit de l’essence même du travail.
Nous nous améliorons continuellement en observant la manière dont nous travaillons et en corrigeant les problèmes que nous rencontrons. L’amélioration est une activité continuelle, et non périodique. Lorsque quelque chose se passe mal, nous faisons une pause et nous trouvons une manière d’améliorer notre processus afin que le problème ne se produise pas à nouveau. Nous nous focalisons sur le système, non sur les individus. Occasionnellement, nous nous arrêterons et réfléchissons sur notre travail pour faire des améliorations proactives.
La simplicité est essentielle. Cette règle s’applique à tout, de la structure organisationnelle et des processus jusqu’aux plus infimes détails des produits que nous développons. Nous ne perdons pas de temps en construisant (des produits ou des organisations ou d’autres choses) dans le cadre d’un futur que nous sommes incapable à prédire.
La nature même du travail est impermanente. Nous nous attendons à changer, voire même à rejeter, tout ce que nous avons construit, des produits aux organisations en passant par les processus. Tout n’est qu’expérimentation.
Nous travaillons à rendre meilleure la vie de nos clients et leur travail plus facile. Nous faisons cela en fournissant un flux régulier d’artéfacts et d’assistance qu’ils trouvent utiles.
Nous réfléchissons de manière holistique. Nous visons à réaliser des produits, non à travailler sur des projets. Si vous n’avez pas de projets, vous n’avez pas besoin de gestion de projets.
Au cœur de notre manière de travailler se trouve la boucle de retour d’informations dite de rétroaction. Nous faisons un petit changement, nous livrons le résultat dans les mains de nos clients, nous obtenons un retour d’informations et nous ajustons notre action en fonction de ce retour d’informations. Ce cycle est aussi court que possible — en minutes, en heures, ou de manière occasionnelle de l’ordre de quelques jours — et non en semaines. Cette boucle d’inspection et d’adaptation s’applique à la fois au processus d’amélioration qu’à celui du développement produit. Les changements que nous livrons sont de grande qualité (par exemple dans le code, il n’y a aucune anomalie connue, il est prêt pour être mis en production, il est sûr, etc.).
La qualité est non négociable (cette règle s’applique à tous les aspects de la qualité, et non simplement lors des tests).
Les meilleurs plans sont stratégiques, non tactiques.
Les prédictions ne sont pas fiables. Les estimations ne sont pas des promesses.
Notre seule mesure d’avancement, c’est livrer entre les mains de nos clients les choses qu’ils trouvent utiles. Il est tout à fait correct qu’ils puissent changer d’avis.
L’encadrement donne uniquement l’orientation stratégique ainsi que son appui. Indiquez aux équipes ce dont vous avez besoin, faites-leur confiance pour trouver comment le mettre en œuvre.
Fournissez aux individus l’environnement et le soutien dont ils ont besoin, puis écartez-vous du chemin. Nous faisons confiance aux équipes autonomes pour maîtriser la manière dont elles travaillent et l’environnement dans lequel elles travaillent. Les équipes sont autoorganisées et autogérées. Elles choisissent leurs propres outils et leurs propres méthodes. Nous attendons de leur part qu’elles changent à la fois le produit ainsi qu’elles-mêmes pour autant qu’elles le jugent nécessaire. Si toutes les équipes travaillent de la même manière — en utilisant le même processus ou le même cadre de travail par exemple — alors vous n’avez pas d’autonomie.
L’autonomie ne signifie pas que les équipes ne se coordonnent pas les unes avec les autres et avec le reste de l’organisation. L’alignement allant des objectifs stratégiques aux technologies d’implémentation est essentiel.
Les meilleures équipes sont des équipes stables. Apportez du travail aux équipes ; ne constituez pas des équipes pour faire le travail. Financez les équipes, pas les travaux.
Des équipes qui dépendent d’autres équipes sont dans l’incapacité de réagir suffisamment vite, il est donc nécessaire que les membres de l’équipe aient toutes les compétences nécessaires pour donner vie à une idée et la mettre entre les mains des clients. Les compétences des uns et des autres se recoupent, afin que nul ne soit une personne-clé.
Les personnes doivent pouvoir démarrer chaque nouvelle journée en étant fraîches, disposes et capables de donner le meilleur d’elles-mêmes (ou de s’arrêter lorsque les conditions ne s’y prêtent plus).
Interactions sociales, autonomie, maîtrise et but sont des motivations essentielles. Les récompenses autant que les sanctions s’avèrent de nature destructrice.
La communication est centrale pour obtenir des résultats efficaces. L’efficacité de la communication s’améliore avec le degré de proximité physique et la richesse du média de communication utilisé. La communication en face à face en temps réel est ce qu’il y a de mieux, toutefois elle n’est pas toujours possible, donc nous devons, quand nous le pouvons, nous en rapprocher du mieux que nous le pouvons.
Une grande partie des dysfonctionnements en terme de management vient d’une forme de peur, qui à son tour vient d’un manque de transparence. Nos processus doivent être aussi transparents que possible.

Cette liste résulte d’une réflexion qui m’est complètement personnelle. Elle a vu le jour afin de présenter les valeurs et les principes du Manifeste Agile d’une manière qui se veut plus claire et plus contemporaine même si j’y ai ajouté des petites choses ici ou là. Elle représente un instantané de ma réflexion, et non un ensemble de vérités irréfutables.

Auteur : Allen Holub
Source : Heuristics for Effective (~~Software Development~~) Organizations: A continuously evolving list.
Date de parution originale : 24 Juillet 2021

Traducteur : Nicolas Mereaux
Relectrice : Cidalia De Bastos
Date de traduction : 30/05/2021

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

Gestion du changement agile en résumé

Wed, 18 May 2022 00:01:00 +0000

(Cliquez sur l’image pour télécharger le fichier pdf correspondant 😉)

Alors que les méthodologies de gestion du changement contiennent pour la plupart des éléments connus depuis longtemps, se basant sur le fruit d’expériences et d’importants travaux de recherches, peu d’entre elles sont faites pour traiter ce qui relève de la nature très complexe de certains changements dans lesquels il n’est pas possible d’uniquement « planifier et mettre en œuvre » puis d’obtenir ce qui est attendu du premier coup. Une approche itérative avec des boucles de rétroactions rapides et d’apprentissages graduels est davantage appropriée pour ce genre de cas.

De manière similaire, les méthodes agiles et lean risquent de ne pas aller suffisamment en profondeur si elles ne font que survoler le cycle PDCA. Nous avons donc souhaité inclure les meilleures pratiques possibles de définition du problème à résoudre tout en permettant en même temps d’évaluer la capacité à changer des personnes et de l’organisation au cours de ce même changement. Pour évaluer que telle ou telle amélioration s’est produite sans l’ombre d’un doute dans un environnement très changeant, des éléments statistiques entre l’avant et l’après devrait être établis.

À Dandy People, nous avons combiné le meilleur de ces deux approches dans ce que nous avons appelé la gestion du changement agile et l’avons condensé en un seul poster. Au centre se trouvé le processus de changement agile constitué d’un cercle extérieur représentant un changement. Il contient à la fois une piste personne et une piste système, ces deux dimensions étant nécessaires pour qu’un changement se produise rapidement et avec un retour sur investissement intéressant. Le cercle intérieur est celui de la découverte itérative sur ce qui se passe réellement en termes d’amener les gens et le système à travailler d’une meilleure et manière de travailler. Ce poster est basé sur différents concepts provenant du Lean, d’Agile, du DMAIC¹ et du Standard de l’ACMP².

Auteurs : Mia Kolmodin, Joel Stahl
Source : Agile Change Management in a Nutshell – Free Poster
Date de parution originale : 28 Août 2017 mis à jour 03 Octobre 2019

Traducteurs : Cidalia De Bastos, Nicolas Mereaux
Date de traduction : 18/05/2022

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

NdT - Six Sigma - Définir, Mesurer, Analyser, amélIorer, Contrôler ↩
NdT - ACMP - Association of Change Management Professionals ↩

Réussir avec les OKR en Agile (le livre)

Fri, 01 Apr 2022 00:01:00 +0000

Est-ce que votre équipe agile est perdue dans la fumée et occupée à éteindre des incendies un peu partout ? Luttez-vous pour garder votre équipe agile focalisée ? Ressentez-vous le besoin de faire mieux et davantage que d’exécuter toutes les deux semaines le haut du backlog ? Utilisez-vous, ou voulez-vous utiliser, les OKR avec une équipe agile ?

C’est à ces questions que Allan Kelly tente de répondre dans son ouvrage “Réussir avec les OKR en Agile” à découvrir la suite ici.

Auteur : Allan Kelly
Source : Succeeding with OKRs in Agile
Date de parution originale : 13/09/2021

Traducteur : Nicolas Mereaux & Fabrice Aimetti
Date de traduction : 01/04/2022

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

Les traducteurs agiles

Le MVP est un exercice marketing non un exercice technologique

De la nature non linéaire et de toute première importance des êtres humains dans le développement logiciel

Rapport technique - Humans and Technology - Mars 1999

Résumé

1 - Introduction

2 – Ce qui ne fonctionnait pas

3 – Quatre caractéristiques

Les personnes sont des êtres communicants

Les personnes ont tendance à ne pas agir de manière constante

Être un bon citoyen7 et être bon à fouiller un peu partout

Tout le monde n’est pas pareil

Autres caractéristiques

4 — Conclusion

Références

Une autre manière de visualiser le modèle du changement de Satir

Late Status Quo

Dernier Status Quo

Foreign Element

Élément étranger

Chaos

Transforming Idea

Idée transformante

Practice and Integration

Pratique et intégration

New Status Quo

Nouveau Status Quo

3 éléments clés pour un coaching agile efficace : niveau, empathie et expérience

À quel niveau êtes-vous supposé influencer ?

Faites preuve d’empathie vis-à-vis de vos clients

Définir les résultats

Votre parcours de coach dépend des résultats que vous voulez atteindre

L'architecture hexagonale

Le modèle : Ports & Adapters1 (« Structure de l’objet »)

But recherché

Motivation

De la nature de la solution

Structure

Exemple de code

Étape 1: FIT App un-taux-constant-à-la-place-d’une-base-de-données

Étape 2 : IHM App un-taux-constant-à-la-place-d’une-base-de-données

Étape 3 (FIT ou IHM) APP fausse base de données

Notes de l’application

L’asymétrie gauche-droite

Cas d’utilisation et frontières de l’application

Combien de ports ?

Cas d’usages connus

Mac, Windows, Google, Flickr, Web 2.0

Sorties stockées

Exemple anonyme extrait du wiki C2

Développement avec des équipes de grande taille distribuées

Séparer le développement de l’IHM et de la partie applicative.

Patterns liés

Adapter

Modèle - Vue - Contrôleur

Objects Mocks et Loopback (rebouclage)

Pattern Pedestals (piédestal)

Vérifications

Inversion de dépendance (injection de dépendance) et SPRING

Remerciements

Bibilographie et lectures recommandées

Utah Code Camp Sept 19, 2009 : mission codage

Implémentation en Ruby / Rack (sans Rails)

Autres discussions et implémentations

Dépendances configurables, acteurs primaires et secondaires

LeSS - Automatisation des tests

Tests manuels

Automatiser les tests manuels

Faire quelques tests manuels

Faire des tests exploratoires

Tests automatisés

Créer des tests maintenables

Supprimer toute duplication à l’intérieur et à l’extérieur des tests

Supprimer des tests lorsqu’ils n’apportent aucune valeur

Éviter de tester à travers une IHM

Exécuter les tests fréquemment

Traiter les tests non fonctionnels comme des tests fonctionnels

Exécuter de manière continue des tests qui prennent du temps à s’exécuter

Utiliser la virtualisation ou les conteneurs

Éviter d’utiliser des outils de tests commerciaux

Être un bon citoyen⁷ et être bon à fouiller un peu partout

Le modèle : Ports & Adapters¹ (« Structure de l’objet »)