Les traducteurs agiles

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 Introduction

Fri, 05 May 2023 00:00:00 +0000

Introduction to LeSS

layout: post title: “Introduction à LeSS (en cours)” date: 2024-05-05 00:01 published: false tags:

less
agile
scrum

Introduction à LeSS

(this is chapter 2 of the book “Large-Scale Scrum: More with LeSS”)

(Le présent texte constitue le chapitre 2 de l’ouvrage “Large-Scale Scrum: More with LeSS” )

There are two ways of constructing a [design]:
One way is to make it so simple that there are obviously no deficiencies,
and the other way is to make it so complicated that there are no obvious deficiencies.
C.A.R. Hoare

Il existe deux manières de faire une conception : La première consiste à la faire de manière si simple que de manière évidente il ne manquerait rien et l’autre manière qui s’avère si compliquée qu’il n’y a aucun manque visible à priori. C.A.R. Hoare

One-Team Scrum

Une équipe Scrum

Scrum is an empirical-process-control development framework in which a cross-functional self-managing Team develops a product in an iterative incremental manner. Each timeboxed Sprint, a potentially shippable product increment is delivered and, ideally, shipped. A single Product Owner is responsible for maximizing product value, prioritizing items in the Product Backlog, and adaptively deciding the goal of each Sprint based on constant feedback and learning. A small Team is responsible for delivering the Sprint goal; there are no limiting single-specialized roles. A Scrum Master teaches why Scrum and how to derive value with it, coaches the Product Owner, Team, and organization to apply it, and acts as a mirror. There is no project manager or team lead.

Scrum est un cadre de développement avec le contrôle du processus est empirique au sein de laquelle une équipe autogérée développe un produit d’une manière itérative et incrémentale. Lors de chaque Sprint qui est limité dans le temps, un incrément du produit potentiellement livrable, est réalisé et idéalement livré. Un seul et unique Product Owner est responsable pour maximiser la valeur de ce produit, en priorisant les items du Product Backlog, et en décidant d’adapter le but de chaque Sprint en fonction des retours d’informations obtenus. Une petite équipe est responsable pour atteindre l’objectif du Sprint ; il n’existe pas en tant que tels de rôles spécialisés limitant le champ d’action de chacun. Un Scrum Master enseigne pourquoi Scrum et comment Scrum permet de produire de la valeur, il coache le Product Owner, l’Équipe et l’organisation dans l’application de Scrum et agit comme le fait un miroir. Il n’y a pas de chef de projet ou de responsable d’équipe.

Empirical process control requires transparency, which comes from short-cycle development and review of shippable product increments. It emphasizes continuous learning, inspection, and adaptation about the product and how it’s created. It’s based on understanding that in development things are too complex and dynamic for detailed and formulaic process recipes, which inhibit questioning, engagement, improvement.

Le contrôle des processus étant empirique, cela demande de la transparence ; cette dernière se produit grâce d’une part aux cycles courts de développement et d’autre part aux revues des incréments livrables du produit. Scrum met l’accent sur l’apprentissage en continu, l’inspection et l’adaptation non seulement sur le produit mais également sur la manière dont il est créé. Il se base sur le postulat que le développement de produits est quelque chose de trop complexe et trop dynamique pour l’utilisation de recettes de processus détaillées ou formelles et que cela nuirait au questionnement, à l’engagement et à l’amélioration.

In the Scrum Guide and Scrum Primer, the emphasis is for one Team; the focus is not many Teams working together. And that naturally leads to thinking about large-scale Scrum.

Dans le Scrum Guide et dans le Scrum Primer, l’accent est mis sur une et une seule équipe et non sur plusieurs équpes travaillant ensemble. Ce qui conduit naturellement à s’interroger sur Scrum à grande échelle

LeSS

LeSS is Scrum applied to many teams working together on one product.

LeSS est Scrum appliqué à plusieurs équipes travaillant ensemble sur un même produit

LeSS is Scrum—Large-Scale Scrum (LeSS) isn’t new and improved Scrum. And it’s not Scrum at the bottom for each team, and something different layered on top. Rather, it’s about figuring out how to apply the principles, purpose, elements, and elegance of Scrum in a large-scale context, as simply as possible. Like Scrum and other truly agile frameworks, LeSS is “barely sufficient methodology” for high-impact reasons.

LeSS, c’est Scrum … — Large-Scale Scrum (LeSS) ou Scrum à grande échelle n’est un Scrum nouveau et amélioré. Et ce n’est pas Scrum au niveau de chaque équipe en bas de la hiérarchie, et quelque chose de différent à des niveaux hiérarchiques plus élevés. Il s’agit plutôt de déterminer comment appliquer aussi simplement que possible les principes, les buts, les éléments et l’élégance de scrum dans un contexte à grande échelle. À l’image de Scrum et d’autres cadres de travail vraiment agile, LeSS est une « méthodologie minimale juste ce qu’il faut » et pour de bonnes raisons.

Scaled Scrum is not a special scaling framework that happens to include Scrum only at the team level. Truly scaled Scrum is Scrum scaled.

Scrum mis à grande échelle n’est un cadre de travail dédié à la mise à grande échelle qui au final n’incluerait uniquement Scrum au niveau des équpes et pas ailleurs. Un véritable Scrum mis vraiment à grande échelle est Scrum mis à grande échelle.

…applied to many teams—Cross-functional, cross-component, full-stack feature teams of 3–9 learning-focused people that do it all—from UX to code to videos—to create done items and a shippable product.

… appliqué à plusieurs équipes — autrement dit des équipes pluridisciplinaires, pluricomposants, composées de 3 à 9 personnes focalisées qui gèrent l’ensemble des fonctionnalités de la pile technique qui font l’ensemble des travaux - de l’UX au code en passant par les vidéos — pour réaliser les items, les terminer et en faire un produit livrable.

…working together—The teams are working together because they have a common goal to deliver one common shippable product at the end of a common Sprint, and each team cares about this because they are a feature team responsible for the whole, not a part.

… où les personnes travaillent ensemble — les équipes travaillent ensemble parce qu’elles ont le but commun de livrer un produit livrable à la fin du Sprint qu’elles ont en commun, et chaque équipe a cette préocuppation parce qu’elles sont une équipe feature responsable de la totalité, et non d’une partie.

…on one product—What product? A broad complete end-to-end customer-centric solution that real customers use. It’s not a component, platform, layer, or library.

… sur un seul produit — Quel produit ? Une solution complète de bout-en-bout orienté client que des clients réels utlisent. Il ne s’agit pas d’un composant, d’une plateforme, d’une couche ou d’une bibliothèque.

• Background •

In 2002, when Craig wrote Agile & Iterative Development, many believed that agile development was only for small groups. However, we both (Craig and Bas) became interested in—and got increasing requests—to apply Scrum to large, multi-site, and offshore development. So, since 2005 we have teamed up to work with clients to scale up Scrum. Today, the two LeSS frameworks (smaller LeSS and LeSS Huge) have been adopted in big groups worldwide in disparate domains:

telecom equipment — Ericsson & Nokia Networks
investment and retail banks — UBS
trading systems — ION Trading
marketing platforms and brand analytics — Vendasta
video conferencing — Cisco
online gaming (betting) — bwin.party
offshore outsourcing — Valtech India

In terms of large, what’s a typical LeSS adoption case? Perhaps five teams in one or two sites. We’ve been involved in adoptions of that size, of a few hundred people, and up to a LeSS Huge case of well over a thousand people, far too many development sites, tens of millions of lines of C++, with custom hardware.

More LeSS Learning

To help people learn and based on our experiences with clients, in 2008 and 2010 we published two books on scaling agile development with the LeSS frameworks:

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum — explains the thinking, leadership, and organizational design changes.
Practices for Scaling Lean & Agile Development: Large, Multi-site & Offshore Product Development with Large-Scale Scrum — shares hundreds of concrete experiments for LeSS, based on our experience with clients; experiments in product management, architecture, planning, multi-site, offshore, contracts, and more.

This book—Large-Scale Scrum: More with LeSS—is the third in the LeSS series, a prequel and primer. This book synthesizes, clarifies, and highlights what’s most important.

Besides these books, see less.works for online learning resources (including book chapters, articles, and videos), courses, and coaching.

• Experiments, Guides, Rules, Principles •

The first two LeSS books emphasized: There are no such things as best practices in product development. There are only practices that are adequate within a certain context.

Practices are situational; blithely claiming they are “best” disconnects them from motivation and context. They become rituals. And pushing so-called best practices kills a culture of learning, questioning, engagement, and continuous improvement. Why would people challenge best?

Therefore, the earlier LeSS books shared experiments we and our clients have tried, and we encouraged—and encourage—this mindset. But over time we noticed two problems with the only-experiments mindset:

Novice groups made unskillful decisions to their detriment, adopting LeSS in ways not intended, with obvious problems; e.g. groups created Requirement Areas with one team each. Ouch!
Novice groups asked, “Where do we start? What’s most important?” They understandably couldn’t see the key basics.

Based on this feedback we reflected and returned to the Shu-Ha-Ri model of learning: Shu—follow rules to learn basics. Ha—break rules and discover context. Ri—mastery and find your own way. In a Shu-level LeSS adoption, there are a few rules for a barely sufficient framework to kick-start empirical process control and whole-product focus. These rules define the two LeSS frameworks that are introduced soon.

To summarize and build on these points, LeSS includes:

Rules—A few rules to get started and form the foundation. They define the key elements of the LeSS frameworks that should be in place to support empirical process control and whole-product focus. e.g. Hold an Overall Retrospective each Sprint.
Guides—A moderate set of guides to effectively adopt the rules and for a subset of experiments; worth trying based on years of experience with LeSS. Guides contain tips. Usually helpful and are an area for continuous improvement; e.g. Three Adoption Principles.
Experiments—Many experiments that are very situational and may not even be worth trying; e.g. Try… Translator on Team.
Principles—At the heart, a set of principles—extracted from experience with LeSS adoptions—that inform the rules, guides, and experiments; e.g. whole-product focus.

The LeSS guides and experiments are optional. Guides will probably be helpful and are recommended trying. But bypass or drop those that limit further improvement or just don’t fit.

A good way to look at LeSS is visualized in the LeSS complete picture:

[Download PDF]

[Download PNG]

The LeSS complete picture will order the way we introduce LeSS:

LeSS principles, up next
LeSS frameworks (defined by the rules), in the rest of this chapter
LeSS guides, in the following chapters of this book
LeSS experiments, already available in the first two LeSS books

• LeSS Principles •

The LeSS rules define the LeSS framework. But the rules are minimalistic and don’t answer how to apply LeSS in your specific context. The LeSS principles provide the basis for making those decisions.

[Download PDF]

[Download PNG]

Large-Scale Scrum is Scrum—It isn’t new and improved Scrum. Rather, LeSS is about figuring out how to apply the principles, rules, elements, and purpose of Scrum in a large-scale context, as simply as possible.

Transparency—Based on tangible “done” items, short cycles, working together, common definitions, and driving out fear in the workplace.

More with less—We don’t want more roles because more roles leads to less responsibility to Teams. We don’t want more artifacts because more artifacts leads to a greater distance between Teams and customers. We don’t want more process because that leads to less learning and team ownership of process. Instead we want more responsible Teams by having less (fewer) roles, we want more customer-focused Teams building useful products by having less artifacts, we want more Team ownership of process and more meaningful work by having less defined processes. We want more with less.

Whole-product focus—One Product Backlog, one Product Owner, one shippable product, one Sprint—regardless if 3 or 33 teams. Customers want valuable functionality in a cohesive product, not technical components in separate parts.

Customer-centric—Focus on learning the customers real problems and solving those. Identify value and waste in the eyes of the paying customers. Reduce wait time from their perspective. Increase and strengthen feedback loops with real customers. Everyone understands how their work today directly relates to and benefits paying customers.

Continuous improvement towards perfection—Here’s a perfection goal: Create and deliver a product almost all the time, at almost no cost, with no defects, that delights customers, improves the environment, and makes lives better. Do endless humble and radical improvement experiments toward that goal.

Lean thinking—Create an organizational system whose foundation is managers-as-teachers who apply and teach lean thinking, manage to improve, promote stop-and-fix, and who practice Go See. Add the two pillars of respect for people and continuous challenge-the-status-quo improvement mindset. All towards the goal of perfection.

Systems thinking—See, understand, and optimize the whole system (not parts), and use systems modeling to explore system dynamics. Avoid the local sub-optimizations of focusing on the efficiency or productivity of individuals and individual teams. Customers care about the overall concept-to-cash cycle time and flow, not individual steps, and locally optimizing a part almost always sub-optimizes the whole.

Empirical process control—Continually inspect and adapt the product, processes, behaviors, organizational design, and practices to evolve in situationally-appropriate ways. Do that, rather than follow a prescribed set of so-called best practices that ignore context, create ritualistic following, impede learning and change, and squash people’s sense of engagement and ownership.

Queuing theory—Understand how systems with queues behave in the R&D domain, and apply those insights to managing queue sizes, work-in-progress limits, multitasking, work packages, and variability.

• Two Frameworks: LeSS & LeSS Huge •

Large-Scale Scrum has two frameworks:

LeSS. 2–8 Teams
LeSS Huge. 8+ Teams

The word LeSS is overloaded to mean both Large-Scale Scrum in general and the smaller LeSS framework.

The Magic Number Eight

Actually, eight isn’t a magic number, and if your group can successfully apply the smaller LeSS framework with more than eight teams, great! But we haven’t seen that… yet. It’s just an upper-limit empirical observation. And in some cases, such as varied complex goals with multi-site inexperienced foreign-language-only teams, it could be less than eight.

In any event, at some point, (1) the single Product Owner can no longer grasp an overview of the entire product, (2) the Product Owner can’t balance an external and internal focus, and (3) the Product Backlog is so large that it becomes difficult for one person to work with.

When the group hits that tipping point, it may be time to change from the smaller LeSS framework to LeSS Huge. On the other hand, we suggest first trying to get better, smaller, and simpler, before getting huger.

Common Across the Frameworks

The LeSS and LeSS Huge frameworks share common elements:

one Product Owner and one Product Backlog
one common Sprint across all teams
one shippable product increment

The following two sections of this chapter explain the frameworks; the smaller LeSS framework is next, and LeSS Huge starts further on.

LeSS Framework

• LeSS Framework Summary •

[Download PDF]

[Download PNG]

The smaller LeSS framework is for one (and only one) Product Owner who owns the product, and who manages one Product Backlog worked on by teams in one common Sprint, optimizing for the whole product. The LeSS framework elements are about the same as one-team Scrum:

Roles—One Product Owner, two to eight Teams, a Scrum Master for one to three Teams. Crucially, these Teams are feature teams—true cross-functional and cross-component full-stack teams that work together in a shared code environment, each doing everything to create done items.

Artifacts—One potentially shippable product increment, one Product Backlog, and a separate Sprint Backlog for each Team.

Events—One common Sprint for the whole product; it includes all teams and ends in one potentially shippable product increment. Details are explained in the upcoming stories, and in separate chapters.

Rules & Guides—Rules for a barely sufficient scaling framework for empirical process control and whole-product focus. Guides may help.

• LeSS Stories •

Learning LeSS—One way to learn is by reading in-depth exposition, and readers preferring that can comfortably skip ahead to the introduction to LeSS Huge, and then on to following chapters. Others who like stories, keep on reading.

Simple stories—These stories don’t explore the complexities of large-scale development—from politics to prioritization—that we experience when consulting. Later chapters unpack those boxes. Here are intentionally plain and simple stories just to introduce the basics of a LeSS Sprint. If you want thrilling dialog and drama, read a Lean book.

Rules & guides—In the stories you will notice that the margins refer to related LeSS rules and guides, to clarify and make connections.

Two perspectives—Following are two related stories focusing separately on two key perspectives, to introduce some flows more simply:

LeSS Story: Flow of Teams

This story focuses on the flow of teams through a Sprint, rather than the flow of items. In reality the majority of time in the Sprint is working on development tasks, not meetings. However, this story emphasizes meetings and interactions, as the goal is an understanding of how multiple teams work together during LeSS events, and how they coordinate day by day.

Mark walks into the room where his team (Trade) works and sees Mira, who says, “Good morning! Just a reminder, we’re the team representatives for this Sprint, and Sprint Planning One starts in 10 minutes.” “Right,” says Mark, “Meet you in the big room.”

Sprint Planning One

It’s time for a common Sprint Planning One. Around the big room are 10 team representatives from the five teams in this product group. They all work on their flagship product for trading bonds and derivatives. Sam, the Scrum Master of teams Trade and Margin, is also there. He’s planning to observe and coach as needed. (RULE: There is one product-level Sprint, not a different Sprint for each Team.)

Many Sprints earlier, everyone from all the teams attended Sprint Planning One. That was more useful when the group was not very good at getting items clear and ready, nor at creating broad knowledge across the teams. Back then, Sprint Planning One was used to answer a lot of major questions that everyone needed to hear. But lately that’s been much improved, and so now the group is experimenting with using rotating representatives, in what has become a simple and quick meeting with only a few minor questions that tend to pop up. If the new approach doesn’t work well, it will probably be raised in an Overall Retrospective, and another experiment for Sprint Planning will be created. (RULE: Sprint Planning consists of two parts: Sprint Planning One is common for all teams while Sprint Planning Two is usually done separately for each team. Do multi-team Sprint Planning Two in a shared space for closely related items.)

[Download PDF]

[Download PNG]

Paolo walks in and says “Hi!” He’s the Product Owner and also the lead product manager. Paolo lays out 22 cards on a table and says, “Here’s the big themes: German market, order management, and some regulatory reports. I’ve laid them out in my priority order. I think everyone here understands why these are the priorities, since we’ve been discussing this a lot in Product Backlog refinement. But please ask again, if it’s not clear.” (RULE: Sprint Planning One is attended by the Product Owner and Teams or Team representatives. They together tentatively select the items that each team will work on for the next Sprint.)

Mira and Mark walk over to the table (along with the other representatives) and pick two cards for items related to German-market bonds. Over the last two Sprints their team clarified these items in detail, in single-team Product Backlog refinement (PBR) workshops.

And they pick two more items related to order management that both Team Trade and Team Margin understand quite well. Both teams worked together in multi-team PBR workshops on these items. Why? The teams wanted to decide as late as possible the choice of team-to-item, during some future Sprint Planning. This increases the group’s agility—easily responding to change—and their broader whole-product knowledge fosters self-organized coordination.

A minute later, Mary from Team Margin, on scanning another team’s cards, asks their representatives, “Do you mind if we do that report? We did something very similar last Sprint and I bet we can get it done quickly. Could you swap for this German-market item?” They agree.

[Download PDF]

[Download PNG]

After a few minutes, the teams finish choosing and swapping based on their interests, strengths, and desire to group related items for focus.

Sam (the Scrum Master) says, “I notice that Team Margin has the top four priority items. Could that become a problem?” A quick discussion ensues in which the group realizes there’s a chance that one of the highest-priority items for the product could get dropped if things don’t go smoothly for Team Margin. They decide to distribute a few of the highest-priority items across more teams (constrained by which teams know which items), making it more likely that top items will get done.

The representatives have chosen a total of 18 cards, leaving four lowest priority items on the table. Paolo looks over the unchosen item cards, picks up two of them, and says, “These two are pretty important to me this Sprint. Maybe I should have given them a higher priority to begin with, but I didn’t, and now I’d like to change my mind. Let’s find a way to swap them with some items you’ve already chosen. And of course, if a team gets lucky and finishes early, please pick up the unchosen items.”

After that’s resolved, Paolo says, “Okay, let’s spend some time wrapping up lingering questions. As you know, I’ve been focusing more on figuring out prioritization, and most of you know these item details a lot better than me, but let’s see what we can do together to clear up minor stuff.” (RULE: In Sprint Planning, Teams identify opportunities to work together and final questions are clarified.)

In parallel, Mira, Mark, and the others think hard about final minor points to clear up for their items, and write some questions on flip-chart papers on the walls around the room. Paolo roams around to different areas, discussing. Everyone mingles and contributes. After about 30 minutes, all the minor questions that could be answered have been.

The group forms a standing circle to wrap up. No one raises any coordination topics, so eventually Sam says, “I notice that Teams Trade and Margin and NotDerivative have picked up strongly related order-management items.” Mira says, “Hey, let’s get Trade, Margin, and NotDerivative together for a multi-team Sprint Planning Two. We’ve got opportunities to work together.” That’s agreed. The meeting ends.

Team and Multi-Team Sprint Planning Two

After a break, two of the five teams hold their own single-team Sprint Planning Two meetings to create their own Sprint Backlogs, designing and planning their work for the Sprint. (RULE: Each Team has its own Sprint Backlog.)

In contrast, Teams Trade, Margin, and NotDerivative hold a multi-team Sprint Planning Two together in a big room, since they are implementing strongly related items—which were also previously clarified together in multi-team PBR—and they foresee value in working closely. (RULE: Do multi-team SP2 in a shared space for closely related items.)

They talk together in a 10-minute session to set the stage, identifying shared work (common tasks) and design issues. Then they start the clock for a timeboxed 30-minute design session, agreeing to visualize: more sketching on the whiteboard, less talking without drawing. During this time, more shared work is also discovered and written on the board.

Ding! After 30 minutes lots of unexplored details remain, but the teams move on anyway. Each team heads to a different corner of the big room where each starts its own focused Sprint Planning Two, talking more about detailed design issues and creating their own Sprint Backlog with cards. Further coordination is handled by an advanced variation of the just talk technique in LeSS: just scream.

During the talking, the teams realize the need for an in-depth multi-team Design Workshop. They agree to hold one later that day.

Multi-Team Design Workshop

After Sprint Planning and another break, Mira and Mark from Team Trade, and a few people from Team Margin and Team NotDerivative hold a timeboxed one-hour multi-team Design Workshop for a deeper dive into a common and consistent design for their work. Around a large whiteboard they sketch and talk together towards some clarity and agreement on a design approach and common technical tasks. Fortunately, the conclusions don’t seriously impact their existing Sprint plans, but they feel uncomfortable with their process, recognizing they could have predicted the need to resolve these big design questions earlier.

Development Activities Supporting Coordination and Continuous Delivery

After Sprint Planning, the teams dive into developing items, with an emphasis on communicating in code. All the teams are integrating continuously. The continuous integration of all code across all teams creates the opportunity to cooperate by checking who else made changes in the component being worked on. That’s useful, because the group uses integration as a way to inform and support their coordination.

For example, early during the second day of the Sprint, Mark, a developer on Team Trade, pulls the latest version locally and quickly checks the latest changes related to the component they are working on now. He discovers changes related to code added by Maximilian from Team Margin. He knows that team is working on a strongly related item, so he is not especially surprised. Since the code has communicated that now there’s a need to coordinate and who he needs to talk with, he immediately visits Team Margin down the hall. They just talk about how to work together to benefit from one another’s work. (RULE: Prefer decentralized and informal coordination over centralized coordination.)

For the item that Team Trade is developing, and in fact for every item in every team, they have written the automated acceptance tests before starting to develop the solution code. Thus, in addition to integrating the code continuously, they’re also integrating the automated tests. These acceptance tests are run frequently by team members, and so when any of them fails, the teams are immediately signaled to coordinate. The code is telling them, “Hey! There’s a problem! You need to talk and work it out.”

Naturally, another major benefit of the group’s practice of integrating continuously, automated testing, and stopping-and-fixing whenever the build breaks, is that their product is more or less continuously ready to deliver into production. There’s no separate integration team or testing team that would add delay, handoff, and complexity. (RULE: The perfection goal is to improve the Definition of Done so that it results in a shippable product each Sprint, or even more frequently.)

Overall Retrospective

On the second day of the Sprint, Sam and the other Scrum Masters, the Product Owner Paolo, a site manager, and a representative from most of the teams, all get together for a maximum 90-minutes Overall Retrospective related to the last Sprint. (RULE: An Overall Retrospective is held after the Team Retrospectives to discuss cross-team and system-wide issues, and to create improvement experiments.)

Why didn’t they hold this Overall Retrospective before this new Sprint started? They could have, but they normally end a Sprint on a Friday and start a new one on Monday (in contrast to Sam’s suggestion that they try a Wednesday–Thursday boundary). And on the last Friday, they held both the Sprint Review and the team-level Retrospectives. After that they didn’t have the energy to hold an engaged Overall Retrospective at the end of the day. So they’ve opted for an early next Sprint. Sam privately thinks this delay is not a great idea—he’d rather they started Sprint Planning a little later after this meeting—but he wants the group to discover that for themselves.

They focus on a system-wide issue and improvement: how to coordinate, share information, and solve problems across the entire group during the Sprint? Previously they have tried Scrum-of-Scrum meetings and didn’t find them very effective. Sam explains the technique of Open Space, and they agree to try it this Sprint.

Activities for Coordination

(RULE: Cross-team coordination is decided by the teams.)

The fourth day demonstrates a variety of coordination ideas in LeSS:

In LeSS, each Team holds a Daily Scrum as usual. To support coordination between Teams Trade and Margin, Mira goes as a scout to observe Team Margin’s Daily Scrum and then returns and updates her team on what she learned. And someone from Team Margin does the opposite.

As agreed in the Overall Retrospective, the group holds a 45-minute Open Space meeting for coordination and learning, preceded by drinks and snacks. Sam acts as facilitator to teach the group how to hold an Open Space meeting. Everyone is welcome, but most teams decide to send only a few representatives. Mira and Mark from Team Trade join in. The group plans to try an Open Space once a week.

The Test community, with volunteers from most teams, gets together for a half-hour to hear Mary’s proposal to try a new automated acceptance-testing tool. They enthusiastically agree, and Mary volunteers her Team Margin to do the actual experimental work next Sprint, since they are really interested in learning this.

Mira is a member of the Design/Architecture community. There’s no design workshop needed this Sprint related to overall architecture, but she wants to hold a half-day spike in the next Sprint for a new technology. She posts her idea on the community collaboration tool, and suggests the community do the spike together with mob programming to increase their shared learning.

The build system seems to have a weird bug. Time to stop and fix! This Sprint, Team Trade is responsible for it, and it’s one of Mark’s secondary specialties, so he volunteers to fix it and asks another team member to pair up with him to help his colleague learn more about it.

Later, Mira and a few other team members visit the customer support and training group, who work closely with hands-on users. Her team has finished their first item and they want to get early feedback from people closer to customers. One of the trainers is free and he plays with the new feature. Team Trade leaves with a few ideas to make it better.

Later in the day Mark and the rest of Team Trade are doing tasks for their second item. Mark has just completed a 10-minute TDD cycle and has clean stable code after a micro-change. Once again—about every 10 minutes—he pushes the tiny change to the central shared repository (to “head of trunk”), to integrate continuously with his team and all others. He glances over to their big visible red-green screen on the wall and sees that the build system is passing all the tests for the entire group.

(RULE: Do multi-team and/or overall PBR to increase shared understanding and exploiting coordination opportunities when having closely related items or a need for broader input/learning.)

On the fifth day, Mark and Mira join an overall PBR workshop, with representatives from each team, and Paolo, the Product Owner. Paolo starts by sharing his current thinking on product direction and where to go next in the short term and, most importantly, why. To help them understand his reasoning, he reviews his prioritization model with the group, that factors in profit impact, customer impact, business risk, technical risk, cost of delay, and more.

Paolo asks for feedback and ideas from the group for upcoming direction, and the group discusses what items to refine next. Although he knows that he’ll make the final priority calls, Paolo works hard to engage the teams in understanding his thinking, and also to learn from their thinking. He wants the teams to also be involved in owning the product.

The group then splits a few big new items, doing lightweight clarification (more will follow later), and planning poker estimation as a way to learn more about the items—rather than to create estimates.

The representatives from three teams (including Trade and Margin) decide to later do multi-team PBR together for some items to increase their shared understanding and because they are strongly related. And representatives from two other teams choose items to focus on separately in team PBR sessions.

Multi-Team PBR and Team PBR

(RULE: All prioritization goes through the Product Owner, but clarification is as much as possible directly between the Teams and customer/users and other stakeholders.)

On the sixth day, everyone in three of the teams gets together for a multi-team PBR workshop in the big room.

Although their main business is creating and selling their trading solution, the company has a small group of bond traders that use it, with relatively small positions that keep them engaged but without high risk. This way the company has better insight into market trends as well as some expert users that can easily talk with the development teams.

Tanya and Ted are the traders who told Paolo about a trend that led to the items being refined in the multi-team PBR session. So they both join, as experts to help the teams learn and clarify the new items.

The other two teams, in discussion with some other traders, hold separate PBR workshops to complete clarification of some items already under refinement and to start on some new ones. Also, one of the company’s three lawyers specializing in financial regulations and compliance joins one of these teams to help them in clarification.

As a last step in the PBR meetings, people take photos of everything on the walls and whiteboards. They add those to the wiki pages that are used to record everything for each item. Plus they update and clean up the text and tables in the wiki pages that were quickly added during discussions.

A Chat About Team-Level Backlogs and Product Owners

After the multi-team PBR workshop, Mike (who just joined the company) sees Sam by the coffee machine and walks over to talk. Mike says, “Hey Sam. I’m interested in your opinion on something. In the refinement workshop we just finished, of course I noticed that we were working directly with some of the traders to clarify together. But isn’t that inefficient? In my last company, every team had its own Product Owner who did the story writing, wireframes, and specifications, and then gave them to us to implement. Then we could just focus on the programming. And each team had its own Product Backlog that the team’s Product Owner prioritized. But I don’t see that here. Why is it different?”

Sam says, “Interesting questions. Do you mind if I ask you a few questions to explore this?”

“Sure, go ahead.”

“Let’s first consider one Product Backlog versus many team-level backlogs. Suppose each team had its own backlog. How easy and effective is it for one truly overall Product Owner to have an overview? And how much knowledge will a team have of the requirements and designs of items in a different team’s backlog?”

Mike replies, “I can answer that pretty clearly from my last company. Not much.”

Sam continues. “Now suppose there are eight teams and eight team backlogs. What if, from the higher company or product perspective, for some reason, the items in two of the eight team backlogs are actually by far the most important or highest priority. Maybe there’s some change in the market so that this situation comes up. So some questions for you: Can the six teams working in the lower-priority backlogs easily shift to start working on the high-priority items in the other two backlogs? And is it likely that the group will even see this problem, given that they are locked in to each team having their own backlog and local priorities?”

Mike answers, “Our teams at my old place only worked on their own team item backlog. They couldn’t shift to others. But why would they want to? Isn’t that inefficient?”

Sam responds, “Well, from a company perspective, the teams are only working ‘efficiently’ on low-priority stuff because of their narrow knowledge created by each focusing in a different team backlog and because the overall priority and overview isn’t visible. Let me ask you some questions: Does that seem inflexible or flexible—agile? And does that optimize people working on the highest-impact stuff from the company perspective?”

Mike pauses, “Oh! I think I get it. It’s actually not being agile, even though our group said they were doing agile. We weren’t responsive to the highest-value changes overall. And my old team Product Owner said she was prioritizing for highest value in our team backlog. But now I see that my team was just busy efficiently working on what could be low-value stuff when you look at it from a higher level.” (RULE: There is one Product Owner and one Product Backlog for the complete shippable product.)

Sam says, “Exactly. So that’s one of several reasons why we have one Product Backlog here, and no team backlogs, even though there are many teams. In short, it supports whole-product focus, system optimization, and agility. And of course it’s simpler, and it’s easy to see what’s going on across the group.”

“Also,” Mike comments, “I noticed it was much harder in my prior company for all the teams to really work together at the same time, since we were working on very different goals in asynchronous Sprints. Here it feels like all the teams have more of a common focus and direction in one Sprint together.”

“Exactly!” Sam replies, then continues.

“Here’s another question: If there’s only one Product Backlog and one real Product Owner who prioritizes it, but each team still had its own so-called Product Owner who per definition is not prioritizing a team backlog—since there isn’t one—then what do they do all day long? “

Mike replies, “Well, in my last company it was the job of the team-level Product Owner to talk to the users and write the stories for the team, so they could focus on efficiently programming while the team Product Owner worked on gathering and writing requirements.”

Sam asks, “Mike, before you learned about Scrum terms such as ‘Product Owner’, what would you have called middlemen in between the developers and real customers—the ones collecting requirements and then giving them to developers?”

“I joined my last company before we adopted Scrum there.” Mike answers, “And back in the day, there was a group of business analysts who did that. After we adopted Scrum, we were asked to call them the Product Owners.”

“Today in your PBR workshop,” Sam asks, “Did you talk with the traders who were there?”

“Let me think back.” Mike replies, “Yeah, I was talking with Tanya about her idea to analyze trading Russian corporate bonds. It seemed a little confusing so I asked her, why? She explained it was because of concerns around money laundering in offshore accounts. Now, she didn’t know that we’ve been recently working on some other features that integrate with new EU and USA regulatory databases to assess this. So I proposed to her a different approach, which I think—and she agrees—will better solve the problem.

“Now that I think about it,” he reflects, “that probably wouldn’t have happened in my last company, since we rarely talked directly with users.”

(RULE: The Product Owner shouldn’t work alone on Product Backlog refinement; she is supported by the multiple Teams working directly with customers/users and other stakeholders.)

(RULE: All prioritization goes through the Product Owner, but clarification is as much as possible directly between the Teams and customer/users and other stakeholders.)

More Development

Minute by minute and day by day the teams develop code, integrating continuously combined with full test automation. They stop and fix when the build breaks, working towards their perfection goal of having a done shippable product they can continuously deliver to customers. Therefore, when the Sprint is nearly over and the teams are preparing to join the Sprint Review, there’s no late mad rush of effort to integrate and test a big batch of code—it’s been integrated and tested all along.

Sprint Review

(RULE: There is one product Sprint Review; it is common for all teams.)

Finally it’s the last day and time for an all-together Sprint Review. Who’s there? Paolo (the Product Owner, lead product manager), all the internal bond traders, a few trainers and customer service representatives, a few people from Sales, and four users from external clients who pay lower annual rates in exchange for participating regularly in these reviews. Also, there’s all the team members.

[Download PDF]

[Download PNG]

Because there are many items to explore, the group starts with a one-hour bazaar—something like a science fair—with many devices set up in the room, each available for exploring different sets of items. Some team members stay at fixed areas to collect feedback while everyone else uses and discusses the new features.

[Download PDF]

[Download PNG]

After an hour, the group comes together to discuss the questions and feedback, in a session led by Paolo. After that, they discuss future direction. Paolo shares what’s going on in the market and with competitors, and his thoughts on where to go next, and asks for advice.

Team Retrospectives

(RULE: Each Team has its own Sprint Retrospective.)

After a break, Team Trade (and all other teams) hold separate team-level Sprint Retrospectives. They decide that holding a multi-team Design Workshop with Team Margin after Sprint Planning (rather than earlier) was far from ideal in this case, because major issues were left unexplored until the last minute—issues which could have seriously blocked or complicated development. So for the next Sprint they decide that during their PBR sessions they will strive to identify items that have major design issues worth discussing with other teams. And if so, hold a multi-team Design Workshop as soon as possible.

The End

Sprint done! Sam invites Team Trade to join Mira and him at the Belgian-beer pub down the street—Mira’s favorite—to celebrate her birthday. (RULE: Beer is Belgian Tripel Karmeliet.)

Summary

Some key points from the story:

it emphasized flow of people and teams through a Sprint in LeSS
it connected story elements to specific LeSS guides and rules
for a reader who knows Scrum, the events should be familiar
the story shows whole-product focus, even with many teams
the activities emphasized team-based learning and coordination
develop items by integrating continuously so that communicating in code supports decentralized coordination and just talking, in addition to continuous delivery
teams clarify directly with users and customers, to reduce handoff and increase understanding, empathy, and ownership

LeSS Story: Flow of Items

This story focuses more on the flow of items (features) through part of a Sprint, primarily during refinement and development.

Portia wraps up her meeting with the government regulator and heads to the airport, and home. She’s another product manager; she helps Paolo, and specializes in regulatory and audit trends.

[Download PDF]

[Download PNG]

Later, Portia meets with Paolo. Writing on cards, she summarizes the new rules that are going to impact their product, and what clients she thinks are going to want certain features first. Paolo points to the five cards and asks, “So this covers all the work, as far as you know?” Portia smiles and says, “This is regulatory. It’s never finished or clear.”

Paolo asks, “Can you put these in the Product Backlog for me, unordered at the bottom for now?”

“Sure.”

A week later Paolo tells Portia, “Soon, I want to start delivering some parts of the big regulatory requirement for bond derivatives. In the next Sprint’s Product Backlog refinement workshops, I’m going to ask for some teams to focus on that. You know the most about it, so please be at the overall PBR and at whatever team refinement workshops where they want you. Also, can you set up a wiki page with links to the new regulatory docs, to share with the teams?”

“Already done,” answers Portia.

Overall PBR

Paolo kicks off a quick overall PBR workshop, “We’ve got lots of work around new regulations. Soon we need to deliver related items because of a legal deadline end of fiscal year. We’ll know better after some splitting and estimation, but I wouldn’t be surprised if it ultimately involves three or more of the teams for implementation, and lots of time.”

The group splits the new giant item into only a few large parts, to learn major elements. More splitting will happen later in a single-team or multi-team PBR session. Portia heads to the whiteboard; on the left side she writes “regulations for bond derivatives.” Then in conversation with the group, they sketch a tree diagram with four arms representing a splitting into four major sub-items. But they don’t go any deeper—they’re avoiding over-analysis.

Next, the group creates four cards for the new items, and everyone together estimates them with planning poker and relative-size points, baselining the points against existing well-known items in the Product Backlog. Their main goal is not to create estimates but to surface questions and drive more discussion, which they do with Portia.

Next, Paolo asks, “So Portia, of these four big ones, which one first?”

She points to the second card. “Over-the-counter exotic bond derivatives.”

Paolo says, “We need to start delivering some of that as soon as possible. It’s moving way up the Product Backlog. So I’d like one team to take a bite into this, next Sprint. Who’s interested?”

Team Trade volunteers.

Finally, team members from three other teams decide to hold a multi-team PBR workshop for related items.

Team PBR: Biting In

The next day Team Trade holds a team PBR workshop with Portia. They have only one of the four giant items to focus on: New regulations for over-the-counter (OTC) exotic bond derivatives. Sam (their Scrum Master) is also there. Portia says, “This is a gigantic complex item, in an area that frankly nobody is really clear about. It’s going to take us a long time to split this up, really understand it, and specify it well.”

Sam asks, “Do we really need to understand all of it? And will all that analysis teach us more, or could it actually delay our learning?”

He reviews with them the idea of Take a Bite: to just split off one tiny fragment, really understand that, and implement it quickly. Sam concludes, “You know, diagrams don’t crash and documents don’t run.”

With Portia, the team splits off one tiny bite of a thin customer-centric end-to-end item.

From now on they will focus on that tiny bite, clarifying and implementing it. Only after implementation and feedback will they return much later to more splitting and refinement. Using specification by example Portia and Team Trade spend the rest of the day chewing on their bite.

One outcome of overall PBR was the decision to take a bite with Team Trade. Another was the decision for three teams to hold a multi-team PBR workshop for related items, to increase learning and the agility of multiple teams knowing and thinking about the same items.

In addition to everyone from the three teams, the internal traders Tanya, Ted, and Travis join to help the teams start clarifying about a dozen new items. (RULE: All prioritization goes through the Product Owner, but clarification is as much as possible directly between the Teams and customer/users and other stakeholders.)

To start, they form three temporary mixed groups with people from each team. The mixed groups start clarifying different items in separate areas in the room, each with a whiteboard, big wall space, laptop, and projector. Tanya is with one group, Ted another, and Travis, the third.

Then they do rotation refinement: After 30 minutes, a timer goes ding! One group walks over to the other’s area, and vice versa, but Tanya, Ted, and Travis don’t move. The timer is restarted, the traders explain the current results to the incoming groups, and they continue clarifying.

[Download PDF]

[Download PNG]

Throughout the day, as different items become relatively clear—or are left with hanging questions that will have to be explored later—new items are introduced at a work area. Some of the bigger items are split into two or three new smaller ones.

A few times during the day, the groups stop their clarification and do some estimation, mostly to learn and to prompt conversation. They’re using relative (story) points; to remain synchronized against a common baseline, they calibrate against some already completed and well-known items in the Product Backlog.

Updating the Product Backlog and Product Owner

The day after the PBR workshops, Portia and a few team members

update the Product Backlog with the new split items derived from the original ones, and delete the originals
add links to the new wiki pages of item details, created in the PBR workshops
record new estimates, and items ready for implementation

Later, Portia and those team members meet with Paolo to review the Product Backlog changes and to answer his questions.

The End

Some key points from the story:

Take a Bite on a giant item to learn from delivery of something small and to avoid premature and excessive analysis.
Do multi-team PBR for items, for shared knowledge across teams, which increases organizational agility, broadens whole-product knowledge, and fosters self-organized coordination.
Strive for whole-product focus, even with many teams.

Next—The next section shifts to the LeSS Huge framework, used for large groups of many teams.

LeSS Huge Framework

• Requirement Areas •

With 1000 or even just 100 people on one product, divide-and-conquer seems unavoidable because of the complexity of so many requirements and people. Traditional large-scale development divides these ways:

single-function groups (analysis group, test group, …)
architectural-component groups (UI-layer group, server-side group, data-access component group, …)

This organizational design yields slow inflexible development with (1) high levels of waste (inventory, work-in-progress, handoff, information scatter, …), (2) long-delayed ROI, (3) complex planning and coordination, (4) more overhead management, and (5) weak feedback and learning. And it is organized inward around single-skills, architecture, and management, rather than outward around customer value.

But in the LeSS Huge framework when above about eight teams, division is around major areas of customer concerns called Requirement Areas. This reflects the customer-centric LeSS principle.

Size—A Requirement Area is big, usually with between four and eight teams, not one or two. The following Area Feature Teams section explains why.

Dynamic—Requirement Areas are dynamic. Over time an area will change in importance, and then it grows or shrinks with teams joining or departing—most likely to or from another existing area.

Example—For example, in a Securities product (to trade stocks), these could be some major areas of customer interest—Requirement Areas:

trade processing (from pricing to capture to settlement)
asset servicing (e.g. handling a stock split, dividends)
new market onboarding (e.g. Nigeria)

Conceptually in the one Product Backlog, a Requirement Area attribute is added, and each item is classified into one and only one area:

Item

Requirement Area

market onboarding

trade processing

asset servicing

market onboarding

…

Then people can focus on one Area Product Backlog (conceptually, a view onto one Product Backlog), such as the market onboarding area:

Item

Requirement Area

market onboarding

Common Sprint—Does each Requirement Area work separately in its own Sprint, with delayed integration until a far-future date? No.

In LeSS Huge, Integrate Continuously in One Common Sprint
There is one product-level Sprint, not a different Sprint for each Requirement Area. It ends in one integrated whole product, and all the teams across all the Requirement Areas are striving to integrate continuously across the entire product.

• Area Product Owners •

In LeSS Huge one new role is introduced. Each Requirement Area has an Area Product Owner who specializes in that area and focuses on its Area Product Backlog.

Large product groups usually have several supporting product managers specializing in different customer areas, and some of these are likely to serve as the Area Product Owners. Sometimes the Product Owner also serves double duty as an Area Product Owner for one area; that’s more likely in small less huge LeSS Huge groups!

• Area Feature Teams •

Area feature teams work within one Requirement Area (e.g. asset servicing), with one Area Product Owner focusing on the items in one Area Product Backlog. From a team’s perspective, working in the area is like working in the smaller LeSS framework—they interact with their Area Product Owner as though she were the Product Owner, and so on.

The team members come to know the customer domain of that area well. And fortunately, the items of one Requirement Area tend to cover a semi-predictable subset of the entire code base, thereby reducing the scope of what they have to learn well within a vast product.

Key point about size: Many feature teams work in a Requirement Area.

A Requirement Area normally has four to eight teams.
An implication is that a Requirement Area is big.

The Magic Number Four

First, why does a Requirement Area have a suggested upper limit of eight teams? See The Magic Number Eight.

What about the lower limit of four teams? Why not one or two teams? Naturally, four isn’t a magic number, but it strikes a balance so that the product group is not composed of many tiny Requirement Areas.

What’s the problem with many tiny areas? They reduce visibility into overall product-level priorities, increase local optimizations, increase coordination complexity, require more positions, and create teams that are too narrowly specialized and lack the flexibility (agility) to take on the emerging highest-value items from a company perspective. Furthermore, in a tiny area the Area Product Owner is increasingly likely to act as a business analyst between the users and one or two teams.

Are there any reasonable exceptions to the lower limit of four? Yes:

An early transitional situation when the group is incrementally growing a new area that is fully expected to ultimately have four or more teams. Then, start small and simple with one team.
When re-balancing teams from an area with a decreasing demand to one with an increasing demand causes an area to go from four to three teams. Ultimately, merge two reduced small areas back into a new larger area.

Example Requirement Areas and Teams

In summary, a Securities product could have

one Product Owner and three Area Product Owners, all together forming the Product Owner Team
six feature teams in the trade processing area
four feature teams in the market onboarding area
four feature teams in the asset servicing area

• LeSS Huge Framework Summary •

[Download PDF]

[Download PNG]

Each Requirement Area works as a (smaller framework) LeSS implementation, each working in parallel in one overall Sprint. We sometimes summarize a Sprint in LeSS Huge as a stack of LeSS.

From the viewpoint of a team in one area,
LeSS Huge looks like (smaller) LeSS regarding events.

As with LeSS, there are rules and optional guides for LeSS Huge; those are introduced in the following stories and fleshed out in later chapters.

Roles—Same as LeSS, plus two or more Area Product Owners, and four to eight Teams in each Requirement Area. The one Product Owner (who focuses on overall product optimization) and the several Area Product Owners form the Product Owner Team.

Artifacts—Same as LeSS, plus a Requirement Area attribute in the one Product Backlog and thus an Area Product Backlog view for each area.

Events—There is still only one common Sprint for the product; it includes all the teams and ends in a common potentially shippable product increment.

• LeSS Huge Stories •

Learning LeSS Huge—Readers who prefer exposition can comfortably skip ahead to following chapters, bypassing these stories.

Simple stories—These are intentionally plain and simple stories just to introduce basics in LeSS Huge.

Two topics—Following are two stories with distinct topics:

• LeSS Huge Story: A New Requirement Area •

Priti welcomes Portia to her first day in her new job. As a mid-level Operations manager in the Securities division of the large trading company as well as Product Owner for their internal Securities system, Priti is also responsible for finding and retaining talent for her Product Owner Team of Area Product Owners. And she thinks Portia is a fantastic find, as her expertise is exactly what is required for dealing with some new huge requirements.

During the recent job interview—when Portia was still a product manager specializing in regulatory issues at a company that made a system for trading bonds—Priti had laid out the situation. “Portia, after the last crash, the regulators are coming down hard and they require us to be compliant with Dodd-Frank. Right now, we don’t know what it exactly means or how it will impact our system. You’ve got incredible knowledge of this space, and a great professional network with the regulators. I would love it if you would join our group and help us figure out how to deal with this.”

A Big Surprise

A few days later… Priti welcomes Portia, Peter, and Susan into her office. Peter is Area Product Owner for market onboarding, and Susan is a Scrum Master from the trade processing area.

Priti says, “As you know, Dodd-Frank is coming, and it’s huge. What you don’t know is that this morning the regulators called us and they want us to take action now. I’d been working under the assumption we could start next year. So we’re going to have to adapt, big time.

“I don’t think anyone is clear what it means in detail—even the regulators. And we don’t know how it will impact our system and how much work this is going to take, other than, a lot! But now Portia’s joined us and she has a better understanding of this than anyone, although she’s totally new to our systems. So, how can we help her start tackling this mountain of work?”

Susan asks, “You guys understand the Dyslexic Zombies, right?”

Peter and Priti nod. Everyone knows about them—and it isn’t just their name. The Dyslexic Zombies have probably the broadest experience of all the teams. They’ve been around for years and they were a true pain in the ass when they adopted LeSS. The team contained two former members of their now-abandoned architecture group and a couple of people who had been working on the system for over fifteen years. Those people’s resistance to the LeSS adoption was legendary as they were afraid they’d lose their “system perspective.” To their surprise, the opposite happened! Because of their deep knowledge they continuously get tough items to develop. And they regularly participate as expert-teachers in current-architecture-learning workshops with newcomers, and Mario—one of the former PowerPoint architects—is now coordinator for the architecture community. When fed enough beer, he’ll admit that working closer with code and tests has increased his real understanding of the system.

Susan continues, “If any team can quickly help Portia get a better understanding of the size and impact of Dodd-Frank, it’ll be the Zombies. And they led the work on Sarbanes-Oxley a few years ago. Tomorrow is their PBR session. They are just about wrapped up on a new feature. Why don’t we re-direct the meeting to include them in a discussion on Dodd-Frank, and soon after, ask them to focus full-time on it?”

Refining with Zombies

Next day at the refinement meeting with the Zombies, Portia explains the situation, “You’ve probably all heard about the Dodd-Frank legislation. But here’s the surprise: We’ve just been told by the regulators that they want us to take action ‘now’ and demonstrate significant compliance by the end of the year. Otherwise they might restrict our trading.”

The Zombies are visibly surprised. They had heard rumors but didn’t expect such a rush!

Mario says, “OK Portia, give us a quick summary of what this means. And how is it different from Sarbanes-Oxley?”

[Download PDF]

[Download PNG]

Portia picks up a pen and starts sketching on a whiteboard. After about 45 minutes, she is finished with the overview and the Zombies looked a little stunned.

“End of the year, they said?” says Mario. “If the whole group started today, it wouldn’t get finished. This is huge!”

He takes a pen and at the whiteboard starts a rough sketch of their system, talking with the other Zombies about the impact it might have.

He says, “Portia, let’s also use this as a chance to help you understand the system better. Ask away.”

Portia says, “Can you hold on for a second? Let me start a video recording to help me remember this.”

Michelle, a veteran in the team, says, “We’d better start on some real development soon and learn more as we go because otherwise we’ll end up analyzing forever. I’ve seen this story before.”

Susan, their Scrum Master, says, “Reminds me… Tom DeMarco once said that the reason for every failed project is that it started too late.” Everyone laughs. She continues, “So here’s a suggestion: take a bite.”

Creating a New Requirement Area

The next day, Portia, Priti, and rest of the Product Owner Team meet. Portia shares a summary of the scope as she understands it now.

Priti says, “This is even bigger than I expected, and we need to show some tangible progress to the regulators within a few months, and major progress before fiscal year end—seven months from now. To state the obvious, they’re now authorized to require more from us, and with the power to shut us down. As you know, just last month the CEO made it crystal clear that new regulatory requests take priority over any other concern. It’s my experience that our goodwill and flexibility with the regulators goes up if we can give them something early, and be transparent and responsive. So that’s what we’re going to do.”

Priti continues, “It seems to me that we’ll need a new area for this big surprise. And of course that’s probably going to impact some of our existing high-priority goals, since we’ll have to shift some teams. Let’s prepare for a deeper discussion of overall prioritization impact in a couple of days. But for now, I’d like your input about spinning up a new area.”

After a short discussion, it’s clear that everyone recognizes the importance of creating a new area.

Priti then says, “Portia, I know you are new to us, but do you think you would be able to handle the Area Product Owner responsibility for this?”

Portia nods.

Priti continues, “Peter, do you think the Zombies could start work on this? And we’ll need them to learn more Dodd-Frank and figure out the impact on our system before we can add more teams to this.”

Peter says, “I don’t think we’ve got any choice.”

Priti says, “OK Portia, so currently we’ve got a few items in Peter’s Area Backlog, the one huge item I think you called “remainder of Dodd-Frank” and the tiny item which the Zombies and you split off of it. Please ask Peter to show you how to set up a new area in the Product Backlog and move the items over to it.”

Priti continues addressing the group, “The next Sprint starts in three days. Let’s move the Zombies into your area and get started on this monster. Probably in a couple of Sprints we’ll be ready to—and need to—grow your area by moving in another team. Folks, please think about two major concerns: First, preparing for a serious prioritization impact meeting in a few days. And second, what other teams will be good candidates for the new area.”

Sprint Planning in the New Requirement Area

Each Requirement Area holds its own Sprint Planning meetings, all more or less in parallel. In Portia’s new area, she starts her Sprint Planning by introducing two unfamiliar faces to the Zombies.

She says, “Gillian and Zak have been in contact with the regulators regularly and will help us flesh this thing out. They’ve agreed to help us now in Planning, during our PBR sessions, and as much as they can spare daily during upcoming Sprints.”

She continues, “Here’s my tentative plan of attack for the next two Sprints. First, together we need to learn more about Dodd-Frank, and also split it into some major and manageable pieces so we can start to clear the fog and get a better sense of priorities.

“Second, we implement the smaller bite we’ve taken, starting this Sprint. That’ll give us better information about the real work and the impact on our product. And we’ll have some concrete visible progress.

“Third, we prepare for more teams to join our area. What do you think of this approach? Other suggestions?”

During the short discussion, Mario says to his team, “Let me give a bit more context, because I represented our team in the recent Product Owner Team meeting with all the Area Product Owners and Priti. To start with, it’s just us to start. We’re going to take the lead on early implementation, and getting the big picture of the item, and understanding the overall impact on our architecture.”

Michelle interrupts, “Like a tiger team working on a new product?”

“Yes, like that,” says Mario. “Think of Dodd-Frank support as a new product that needs to be continuously integrated into the rest of the product. But we’re in a hurry and it’s a ton of work, so in a few Sprints one more team will join us and shortly after, probably two more teams. We keep developing too, but we’ll be the leading team, which means we’ll need to bring the other teams up to speed and make sure we keep the overall product in mind.”

Michelle says, “It’s starting to sound to me like we’re going to become the architecture and project management team!”

Mario laughs, “No. I’m done with that. We’re still a normal feature team, but besides development we’ll focus on mentoring and bringing the new teams up to speed as fast as possible. But let’s be clear: team coordination and management is still the responsibility of each team.”

The First Sprint in the New Requirement Area

Their first Sprint is an unusual balance of clarification versus development, but nevertheless quite useful in this extreme situation. They spend almost half the Sprint in clarification with Portia, Gillian, and Zak. That’s because even for this extremely small bite, trying to understand what is wanted in the obscure realm of new government regulations—with no direct access to the politicians and policy writers—required a lot of investigation, reading, discussion, and communicating with outsiders. They expect that in future Sprints, the amount of time needed for clarification will soon drop down to a more common 10% or 15% of their Sprint.

And so they also only spend about half the Sprint developing one small item. But the discussion and the learning from coding pays off. Slowly but surely they start to split Dodd-Frank apart—at least the parts that any of them can understand.

While implementing the small item they had bitten off first, they spend much of the time together at whiteboards to discuss the overall design implications on the system. The team moves frequently back and forth between the code and the wall.

Sprint Review in the New Requirement Area

The overall Securities product group works together in one Sprint, with one final shippable product increment. But each Requirement Area holds its own Sprint Review, all more or less in parallel.

In Portia’s area, during their Review, she, Gillian, and Zak explore the one “done” item that the Zombies have managed to complete and integrate into the overall product. They had originally forecast two items, but Portia is impressed that they got even one done, given how fast this new work was thrown at them.

The Second Sprint

In the second Sprint they’re able to make slightly better progress on items, though they once again spend a lot of time clarifying together with Portia, Gillian, and Zak.

In the middle of the Sprint they hold a multi-team PBR session with the second team that is planned to soon join the area, teaching them about Dodd-Frank. They hold a current-architecture learning workshop to introduce the team to the major design elements already in place.

The Zombies know how big the work is and look forward to more help.

Product Owner Team Meeting

A few Sprints later… It’s time once more for the per-Sprint Product Owner Team meeting. They use it to align and coordinate between the different Area Product Owners, and for Priti to give guidance.

The Area Product Owners each share in turn their situation and upcoming goals. When it’s her turn, Portia says, “To none of our surprise, the progress is little and the surprises are big. But the fog is clearing and the teams and I are getting our heads around the work. Gillian and Zak have been tremendous help.”

Pablo, the Area Product Owner of asset servicing, comments on some close item relationships he now sees between their areas. Portia agrees to meet with Pablo and some team representatives later.

Priti asks, “Portia, about our upcoming Sprint. What are your goals?”

Adding a Third Team

Two Sprints later… At the Product Owner Team coordination meeting, Priti says, “As you know, Portia’s area still has only two teams. I know that Pablo would like to keep his six teams in asset servicing, but Dodd-Frank is just too important to me this year. So we’re going to move one team from Pablo’s area into Portia’s. Pablo, please ask for a volunteer team from your group and let me and Portia know.”

The End

Some key points from the story in LeSS Huge:

The Product Owner is responsible for finding Area Product Owners and developing their talents.
The Product Owner is responsible for deciding to start, grow, or wind down Requirement Areas.
Requirement Areas are large, normally requiring four to eight teams, but during initial startup they may be smaller, especially if initiated with one team using a Take a Bite approach.
A Leading Team works solo to tackle a gigantic item until they understand the domain and development, and then they coach more incoming teams to help with the vast work.

• Multi-Site Teams: Terms & Tips •

Next is a LeSS Huge story involving multi-site teams. But first, some clarifying definitions, because the common term distributed teams confusingly means several things. The clarifying terms are as follows:

dispersed team—One team of (e.g. seven) people spread out in different locations; either different rooms, buildings, or cities
co-located team—One team working literally at the same table
multi-site teams—One co-located team working at one site, and another co-located team working at another site

Second, an observation and guidance:

A dispersed team is rarely a real team; it is much more likely a loosely connected groups of individuals. The communication and coordination frictions are higher, and they seldom jell as a team.
When your product group is 50 or 500 people, dispersed teams aren’t necessary. Each team of seven-ish people can easily be co-located. However, some teams may be in different sites, so that the product group has multi-site teams. Dispersed teams are usually the result of bad organizational decisions and ignorance about the cost of not having co-located teams. (Rule: Each team is (1) self-managing, (2) cross-functional, (3) co-located, and (4) long-lived.)

• LeSS Huge Story: Multi-Site Teams •

Portia is the Area Product Owner for a new Requirement Area in a Securities trading system. The new area started with just one team for focus and simplicity. A few Sprints later Portia’s area adds a third team. Her first two teams are based in London with her. But her third new team, HouseDraculesti, is based in Cluj Romania at a major development site for the company.

Why not add a third team from the London site? That would have avoided the many aggravations and efficiency penalties that can come from multi-site development within one area—costs potentially so high that adding a team can effectively result in deleting a team.

But on the positive side in this case, Cluj is only two time zones from London, and everyone there speaks English well. And they are all strong developers with Computer Science degrees, in a city that values long-term and hands-on engineering mastery. Also, this is a dedicated internal development site for the company, so these are experienced internal teams that have in-depth knowledge of the product and domain.

And bottom line, Priti (the Product Owner) didn’t want any of the other London teams to shift from their current areas.

Priti knows that multi-site teams are a new situation for Portia, and so at their next meeting, she says, “Please ask your Scrum Master to talk with Sita, and also ask Sita to coach some of your events. She’s a Scrum Master in asset servicing, and she’s observed their multi-site situation for a few years. She knows the importance of Scrum Masters co-located with their teams, and she’s helped facilitate many multi-site meetings.”

Priti continued, “Also, we’ve had a super profitable year, so I’m providing funding for you and the Zombies team—at least those that can travel—to spend a Sprint in Cluj as soon as possible. Work closely with them, all in one room. The Cluj team could come here to London, but you want to send a strong signal that they are important, at their site. Try to avoid making them feel that London is more important than Cluj. Oh—and you’ll want to regularly visit every few months.”

Multi-Site Sprint Planning Part One

A few Sprints later, Portia walks into the room. There’s a computer projector attached to a laptop, displaying via video a room in Cluj. The whole team in Cluj are sitting and waiting. Sita suggested it would improve learning and engagement if the entire Cluj team participated in multi-site meetings for the first few months of their addition to the area.

All the team representatives have tablets or laptops with them.

Portia begins. “Welcome and let’s get started. My offer of items this Sprint are highlighted in the shared spreadsheet. Can you all see it? I think you all understand why these are the themes and priorities, since we’ve been discussing this in PBR and it reflects your input and mine. But please ask again if you’d like clarification. Other than that, you’re invited to enter your team names beside the items you want.”

That done, the group enters a Q&A phase to wrap up lingering questions about the items. The London representatives tape up some flip-chart papers and start writing questions. The Cluj team members enter their questions in separate sheets of a shared spreadsheet. Portia spends some time at the different paper flip charts, discussing answers and sketching on the paper. And she spends some time at the spreadsheet, typing in answers for the Cluj team, while also talking with them face-to-face via the video session.

After about 30 minutes the separate questions have been resolved, and Portia asks everyone to come back together. She says, “Any issues or questions that you want to discuss together, before we wrap up?”

Multi-Site Overall PBR

People enter the workshop room in London for multi-site PBR. Two projectors are set up. One shows a video session of the workshop room in Cluj. The other displays a browser on Portia’s computer.

Portia says, “Let’s get started. I want to focus on splitting some items. I’ve invited Zak to join us because he knows quite a lot about this.”

Using a mind-mapping, browser-based graphics tool, Zak starts to create some branches, while discussing with the group.

[Download PDF]

[Download PNG]

Afterwards, they use a shared spreadsheet to discuss and write a single example for each of the new split items, so that the people at both sites gain a lightweight but concrete understanding of the details. Later, the group does estimation of the new items, using especially big planning poker cards that can be easily seen by the cameras and video when held up.

The End

Some key points from the multi-site story in LeSS Huge:

Multi-site teams frequently create both obvious and subtle frictions and costs that are surprisingly large in their negative impact.
Qualities that reduce the friction of another site include similar time zone, internal dedicated site (not outsourced), developers that are fluent in the same spoken language, a location and culture that highly values long-term hands-on developer excellence.
A Scrum Master must be co-located with their teams.
Each site must feel like a peer, not a second-class citizen.
Sites must be visited regularly and cross-pollinated.
In meetings, strive for face-to-face with video tools.
The use of shared-document tools make it easy for everyone to modify artifacts together and at the same time.

Onwards

Rather than asking, “How can we do agile at scale in our complex and awkward organization?”, ask a different and deeper question, “How can we simplify the organization, and be agile rather than do agile?” And since truly scaling Scrum starts with changing the organization rather than changing Scrum, the next major section focuses on understanding and adopting a simpler customer-focused LeSS organization.

This is followed by major sections on a more customer-focused product and Sprint in a simpler LeSS organization.

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

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 Introduction

Introduction to LeSS

scrum

Introduction à LeSS

One-Team Scrum

Une équipe Scrum

LeSS

• Background •

More LeSS Learning

• Experiments, Guides, Rules, Principles •

• LeSS Principles •

• Two Frameworks: LeSS & LeSS Huge •

The Magic Number Eight

Common Across the Frameworks

LeSS Framework

• LeSS Framework Summary •

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

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