Wiki Agile - Contributions [fr]

LeSS - Automatisation des tests

2022-11-06T17:55:53Z

Nicolas Mereaux : Création de la page LeSS - Automatisation des tests

[[Category: Nicolas Mereaux]]
[[Category: Portail LeSS]]
[[Category: Portail Equipe de développement]]
[[Catégorie:Tests]]
[[Catégorie:TDD]]
Auteur : The LeSS Company B.V. 
Source : [https://less.works/less/technical-excellence/test-automation.html Test Automation] 
----
Traducteur : Nicolas Mereaux 
Relecteur : Fabrice Aimetti
Date : 06/11/2022 
----
Traduction : 
 
[[LeSS - Portail Excellence technique]]

== Manual Tests ==

== Tests manuels ==

Agile developers emphasize the importance of automated tests. With short cycles, manual regression testing is nearly impossible. Does that mean there is no manual testing at all? No. Some manual testing is still recommended, though such testing differs from the traditional script-based manual testing.

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.

=== Automate your manual tests ===

=== Automatiser vos tests manuels ===

Product groups often claim “It is impossible to automate tests related to a lost network connection” or “You can’t automate tests related to hardware failure” Our answer usually is “No, it is not” or “Yes, you can.”

« 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 » sont des affirmations qui reviennent souvent de la part des groupes produit. Notre réponse est généralement « Non ce n’est pas vrai » ou « Oui, vous pouvez faire ces types de tests »

Elisabeth Hendrickson, the author of the mini-book [https://less.works/papers/et.pdf ''Exploratory Testing in an Agile Context''] , dares to state that:

Elisabeth Hendrickson, l’auteur du mini-livre (vo) [https://less.works/papers/et.pdf ''Exploratory Testing in an Agile Context''] ose d’ailleurs dire

<blockquote>I do think that if you can write a manual script for a test, you can automate it.
</blockquote>
<blockquote>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
</blockquote>
It may be difficult to automate a test in ''exactly the same way'' as it would be carried out manually. For example, it is nearly impossible to remove the network cable automatically in a connection-lost test case. Therefore, the automated test is usually done in a different way. Instead of the cable being physically detached, the automated test instructs the driver to respond ''as if'' the cable were removed.

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 cable 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 cable, le test automatisé va instruire le pilote réseau de répondre ''comme si'' le cable réseau avait été débranché.

Is automating all tests worth it? According to Hendrickson:

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

<blockquote>If it’s a test that’s important enough to script, and execute, it’s important enough to automate.
</blockquote>
<blockquote>Si un test est suffisamment important pour être scripté, et exécuté, il est alors suffisamment important pour être automatisé.
</blockquote>
Why is this? Iterative and incremental development implies that code is not frozen at the end of the iteration but instead has the potential to be changed each iteration. Therefore, manual regression testing would mean rerunning most of the manual test–every iteration. Automating the tests therefore pays back quickly.

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 re-exécuter la majorité des tests manuels à chaque itération. Il va sans dire que l’automatisation s’avère rentable rapidement.

Especially in large-scale development with feature teams and shared code-ownership, the safety net provided by automated tests is of paramount importance. Automating tests is well worth the effort.

Cela s’avère être particulièrement vrai sur le développement à grande échelle qui a, entre autres caractéristiques, 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.

=== Do some manual tests ===

=== Faire quelques tests manuels ===

Automating ''all'' tests might not be worthwhile or even possible. These tests may need to be done manually:

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

* ''Tests requiring human opinion and creativity'' –A person is needed to judge whether the interface looks good–usability testing. Exploratory testing by definition needs someone to decide the next step to explore.
* ''Tests requiring physical movement'' –For example, tests with the system in different physical configurations. These can be automated with simulation, but the real configuration might be needed for the final test run.
* ''Expensive tests'' –Running capacity tests on the production environment may be too expensive and is therefore done only once or twice. This delays risk. These risks should be tackled early with cheaper tests–for example, running capacity tests on a simulated environment–so that running the expensive test is merely a final check.
* ''Les tests nécessitant de l’attention 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.

No false dichotomy: Try to automate all tests, but do not forget to do the manual tests when needed.

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

=== Do exploratory testing ===

=== Faire des tests exploratoires ===

In [http://www.amazon.com/Perfect-Software-Other-Illusions-Testing/dp/0932633692 Perfect Software and Other Illusions about Testing], Gerald Weinberg calls it, “The Exhaustive Testing Fallacy, that it’s possible to test everything!” It is not. The number of possible scenarios to test is infinite and therefore automating all tests means infinite automation effort. Instead, automate all the anticipated tests and spend time as efficiently as possible on manual exploratory testing to find unforeseen cases.

Dans son ouvrage [http://www.amazon.com/Perfect-Software-Other-Illusions-Testing/dp/0932633692 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.

over-view of exploratory testing

Vue globale du test exploratoire

https://less.works/img/test_automation/xet.png.pagespeed.ic.JppUJEJMw2.png

[[Fichier:LeSS-Et-fr.png|800px|sans_cadre|centré|Tests exploratoires]]

What is exploratory testing? “Simultaneous learning, test design, and test execution” [http://www.satisfice.com/articles/what_is_et.shtml [Bach03]]. This is in contrast to traditional scripted testing where test-case design and execution are separated and sequential steps—first design then execution. Exploratory testing aims at fully utilizing human creativity during test execution, using feedback and observations rather than mindlessly following a script. In exploratory testing, the tester is exploring the system, learning about it and using that information to make test-design decisions. It is best explained by an example.

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)]](http://www.satisfice.com/articles/what_is_et.shtml). 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 :

Imagine that Gita is testing a 2D modeling application. First, she defines the goal of her test session—in exploratory testing this is called a mission or charter. Her charter is “Explore changing shapes by dragging the control points.” She takes a shape, drops it on the canvas, and creates a couple of control points on it. She drags one of them and observes what happens. Based on this observation (learning), she determines the next step (design) and performs it (execute). The shape takes its new form, though she notices—while dragging the control points—that the shape temporarily took a form that it probably should not have. Therefore, she continues dragging it and moving it around until she can reproduce the accidental transformation.

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.

In the example, there is no detailed preconceived script or test case but instead an area of focus—a charter. The first step is to observe the system, and the next action is determined from that observation—this is test design. All traditional test techniques and heuristics are applied during this design step.

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 tous les heuristiques traditionnels de tests sont utilisés lors de cette phase de conception.

https://less.works/img/test_automation/xet_scripted_difference.png.pagespeed.ic.X0uMS-HZ2g.png

[[Fichier:Less Et scripted difference-fr.png|800px|sans_cadre|centré|Tests exploratoires]]

== Automated Testing ==

== Test automatisé ==

=== Create maintainable tests ===

=== Créer des tests maintenables ===

“Automated tests will increase our test maintenance load” is a common objection we hear. Test maintenance will cost some effort, but a few straightforward techniques can minimize this cost:

« 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 :

* remove duplication in and between tests
* delete tests
* do not test through the UI
* run tests frequently
* 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

=== Remove duplication in and between tests ===

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

Code duplication causes extra complexity, obscurity, and defects—resulting in extra maintenance effort. This is as true for test code as it is for production code. Avoid this by removing the duplication.

La duplication du code engendre un niveau de complexité, d’incertitude et d’anomalies supplémentaires — ayant pour conséquent 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.

Workflow tests are a common cause of duplication. They often consist of one mother scenario and multiple derived cases with only slight variations in them. When one step changes, all these workflow tests need to be updated. This duplication can be avoided by data-driven tests that focus on business rules or by separating the duplication into test libraries or fixtures.

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''.

We coached a team that made a common mistake—they delayed their test automation until the end of the iteration. Four days remaining and only automation tasks left. In the previous iterations, these tasks were done by the test specialist, but now they had to be done by the whole team.

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.

They started with a one-day workshop in which the one specialist coached the other team members. After that, they split into two pairs and one triplet working in parallel on automating the tests. Something interesting happened: The team members who were experienced in programming complained about the extra effort needed because of the duplication in the tests. Previously, none of them had noticed it and the test specialist—who did not have much programming experience—never cared. Now that the whole team was involved, they cared and the quality of the tests improved immensely.

Nous avons fait démarré 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, tous le monde s’en souciait et la qualité des tests s’est alors grandement améliorée.

=== Delete tests when not adding value ===

=== Supprimer des tests lorsqu’ils n’apportent aucune valeur ===

Tests serve multiple purposes. They act as requirements, as verification, and as a safety net preventing system regression.

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.

When an existing test is not needed anymore—because it is a subset of another test—then delete it. Leaving unnecessary tests brings no benefit but still increases maintenance effort and lowers test execution speed.

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’apportent rien mais augmentent par contre le travail de maintenance et diminuent la vitesse d’exécution des tests.

=== Avoid testing through the UI ===

=== Éviter de tester à travers une IHM ===

User interfaces (UIs) tend to change frequently. Running your tests through the UI makes them vulnerable to these changes—even when there is no change in test logic. This increases the test maintenance effort.

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.

Therefore, avoid testing through the UI and instead call the application logic directly through an API. Another advantage of doing this is that it speeds up your test since testing through the UI is slow.

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.

=== Run tests frequently ===

=== Exécuter les tests fréquemment ===

Long ago, we worked with a large group following waterfall develop- ment. Traditional test automation advice is to select and automate only the most important cases—with a separate automation team— after the release. So they did. At the end of the next release, they executed the tests and… they all failed. Updating them would take much time, so they decided to do all testing manually.

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és 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.

Executing tests once or twice a release seems efficient—fewer CPU cycles are wasted—but much will have changed and therefore many fail and cause a large batch of maintenance work. Alternatively, exe- cuting tests frequently—using a continuous integration system— uses more CPU cycles but results in less maintenance work since the effort to fix failing tests is small and straightforward. If you have a high test-maintenance load, chances are you are not executing the tests frequently enough.

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 continu — 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.

=== Treat non-functionals the same as functionals ===

=== Traitez les tests non fonctionnels comme des tests fonctionnels ===

Automating and continuously running non-functional tests is essential. Delaying them to the end means moving one of the biggest risks to where they hurt most. For example, if the system needs a certain performance level, test early to reach it early, and continuously run the test while new functionality is added to ensure that the system does not regress from its performance target.

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é.

Non-functionals are often treated exotically—people believe they cannot be specified and cannot be tested. This is unfortunate. In a requirements workshop, non-functionals can be considered the same as functionals, and example tests are created for clarifying them.

Les exigences non fonctionnelles sont souvent traitées de manière assez exotique - les gens croient qu’ils ne peuvent être ni spécifiés ni testés. 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.

=== Continuously run long-running tests ===

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

Non-functional tests frequently cannot be run in the normal continuous-integration-system cycle because they may take too long to execute—a stability test might take two weeks. Some product groups delay them until near the release—creating a delayed feed-back cycle. Not a good idea.

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.

Run the long-running tests all the time in a slower continuous-integration-system cycle. Treat them as any other tests. When they fail, inform all people who checked in code. After they pass, get the latest build and immediately run them again. This way the feedback cycle is as short as it can be.

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.

=== Use virtualization or containers ===

=== Utilisation de la virtualisatoin ou des conteneurs ===

In order to speed up the tests and keep the investment in hardware low, maximize the use of virtualization using [https://www.virtualbox.org/ VirtualBox] or [http://www.vmware.com/ VMWare]. An alternative to virtual machines (which aren’t always fast to build and easy to maintain) are linux virtual containers such as [http://www.docker.io/ Docker]

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](https://www.virtualbox.org/) ou [http://www.vmware.com/ 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 [http://www.docker.io/ Docker].

=== Avoid using commercial test tools ===

=== Éviter d’utiliser des outils de tests commerciaux ===

We once coached at a company building a commercial “automated testing” tool—a GUI testing tool. The requested coaching? To learn how to do automated testing for developing their automated testing tool…

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 …

A gazillion commercial test tools are available. We rarely meet people who are actually satisfied with any of them. Most are overly complex and focus more on reporting and ‘management’ than on robust test automation. Favor free and open-source tools—made by developers solving real problems—over commercial tools.

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.

Example of common test automation tools:

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

* [http://www.robotframework.org/ RobotFramework]
* [https://cucumber.io/ Cucumber]
* [http://www.fitnesse.org/ Fitnesse]
* [http://www.seleniumhq.org/ Selenium]
* [https://github.com/jnicklas/capybara Capybara]

There are much more. The above is just a list of common tools, but new tools pop up all the time.

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.

Fichier:Less Et scripted difference-fr.png

2022-11-06T17:36:16Z

Nicolas Mereaux :

Fichier:LeSS-Et-fr.png

2022-11-06T17:33:49Z

Nicolas Mereaux :

Catégorie:Portail LeSS

2022-11-06T17:27:07Z

Nicolas Mereaux : Modification lien pour création page Automatisation des tests

<addthis />
[[Catégorie: Portails Thématiques]]
[[Category: Agilité à grande échelle]]
[[Category: Portail Framework]]
[[Fichier:LeSS-logo 72.png|link=]] À la découverte de LeSS, ce framework de mise à l'échelle de l'élégance de Scrum. 
[[Image:LeSS-overview-diagram_fr.png|LeSS-overview-diagram_fr.png|link=]] [http://less.works/less/framework/introduction.html introduction] '''''"Depuis 2005, nous avons travaillé avec des clients pour mettre en oeuvre le framework LeSS (Large-Scale Scrum) de mise à l'échelle du développement Scrum, agile et lean pour les groupes produit de grande taille. Nous partageons cette connaissance à travers LeSS pour que, vous aussi, vous puissiez réussir lorsque vous passez à l'échelle."''''' - Craig Larman & Bas Vodde '''Articles thématiques''' 
----

* '''[[LeSS%20-%20Portail%20Framework|Portail Framework LeSS (fr) - 95%]]'''
** [http://less.works/less/framework/introduction.html Introduction à LeSS]
** [[Pourquoi%20LeSS%20%3F|Pourquoi LeSS (fr)]]
** [[LeSS%20-%20Le%20Produit|Le Produit (fr)]]
** [[LeSS%20-%20Le%20Product%20Owner|Le Product Owner (fr)]]
** [[LeSS%20-%20Le%20backlog%20du%20produit|Le Backlog du Produit (fr)]]
** [[LeSS%20-%20Les%20%C3%89quipes|Les Équipes (fr)]]
** [[LeSS%20-%20Le%20Sprint|Le Sprint (fr)]]
** [[LeSS%20-%20La%20Planification%20du%20Sprint%20%281%C3%A8re%20partie%29|La Planification du Sprint (1ère partie) (fr)]]
** [[LeSS%20-%20La%20Planification%20du%20Sprint%20%282%C3%A8me%20partie%29|La Planification du Sprint (2ème partie) (fr)]]
** [[LeSS%20-%20Le%20Backlog%20du%20Sprint|Le Backlog du Sprint (fr)]]
** [[LeSS%20-%20La%20M%C3%AAl%C3%A9e%20Quotidienne|La Mêlée Quotidienne (fr)]]
** [[LeSS%20-%20Coordination%20%26%20Int%C3%A9gration|Coordination & Intégration (fr)]]
** [[LeSS%20-%20L%27Incr%C3%A9ment%20Produit%20Potentiellement%20D%C3%A9ployable|L'Incrément Produit Potentiellement Déployable (fr)]]
** [[LeSS%20-%20La%20D%C3%A9finition%20du%20Fini|La Définition du Fini (fr)]]
** [[LeSS%20-%20La%20Revue%20de%20Sprint|La Revue de Sprint (fr)]]
** [[LeSS%20-%20La%20R%C3%A9trospective|La Rétrospective (fr)]]
** [[LeSS%20-%20La%20R%C3%A9trospective%20Globale|La Rétrospective Globale (fr)]]
** [[LeSS%20-%20L%27Affinage%20du%20Backlog%20Produit|L'Affinage du Backlog Produit (fr)]]
** [[LeSS%20-%20L%27Affinage%20Initial%20du%20Backlog%20Produit|L'Affinage Initial du Backlog Produit (fr)]]
** [[LeSS%20-%20Le%20ScrumMaster|Le ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20Principes|Portail Principes (fr) - 72%]]'''
** [[LeSS%20-%20Pr%C3%A9sentation%20des%20principes|Présentation des principes (fr)]]
** [[LeSS%20-%20Scrum%20%C3%A0%20grande%20%C3%A9chelle%20reste%20du%20Scrum|Scrum à grande échelle reste du Scrum (fr)]]
** [[Less_-_Plus_avec_LeSS|Plus avec LeSS (fr)]]
** [http://less.works/less/principles/lean-thinking.html Pensée Lean]
** [[LeSS - Approche systémique|Approche systémique (fr)]]
** [[LeSS%20-%20Contr%C3%B4le%20du%20processus%20empirique|Contrôle du processus empirique (fr)]]
** [[LeSS%20-%20Transparence|Transparence (fr)]]
** [http://less.works/less/principles/continuous-improvement-towards-perfection.html Amélioration continue vers la perfection]
** [[Less_-_Centré_client|Centré client (fr)]]
** [[Less_-_Focus_sur_le_produit_global|Focus sur le produit global (fr)]]
** [https://less.works/less/principles/queueing_theory.html Théorie des files d'attente]
 

* '''[[LeSS%20-%20Portail%20Structure|Portail Structure (fr)]] - 100%'''
** [[LeSS%20-%20Equipes|Equipes (fr)]]
** [[LeSS%20-%20Organisation%20en%20fonction%20de%20la%20valeur%20client|Organisation en fonction de la valeur client (fr)]]
** [[LeSS%20-%20Equipes%20Feature|Equipes Feature (fr)]]
** [[LeSS%20-%20Structure%20organisationnelle|Structure organisationnelle (fr)]]
** [[LeSS%20-%20Communaut%C3%A9s|Communautés (fr)]]
** [[LeSS%20-%20ScrumMaster|ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20Excellence%20technique|Portail Excellence Technique (fr)]] - 60%'''
** [[LeSS%20-%20Sp%C3%A9cifications%20par%20l%27exemple|Spécifications par l'exemple (fr)]]
** [[Less - Intégration continue|Intégration Continue (fr)]]
** [https://less.works/less/technical-excellence/continuous-delivery.html Livraison Continue]
** [[LeSS - Tests d'Acceptation|Tests d'Acceptation (fr)]]
** [http://less.works/less/technical-excellence/architecture-design.html Architecture & Conception]
** [http://less.works/less/technical-excellence/clean-code.html Ecrire du Code Propre]
** [[LeSS - Tests unitaires|Tests unitaires (fr)]]
** [[Less - Développement piloté par les tests|Développement piloté par les tests (fr)]]
** [http://less.works/less/technical-excellence/thinking-about-testing.html Réflexions à propos des tests]
** [[LeSS - Automatisation des tests|Automatisations des tests (fr)]]
 

* '''[[LeSS%20-%20Portail%20Management|Portail Management (fr)]] - 100%'''
** [[LeSS%20-%20R%C3%B4le%20du%20Manager|Rôle du Manager (fr)]]
** [[LeSS%20-%20Enseigner%20la%20r%C3%A9solution%20de%20probl%C3%A8me|Enseigner la résolution de problème (fr)]]
** [[LeSS%20-%20Aller%20Voir|Aller Voir (fr)]]
** [[LeSS%20-%20Auto-gestion|Auto-gestion (fr)]]
** [[LeSS%20-%20Service%20d%27am%C3%A9lioration|Service d'amélioration (fr)]]
** [[LeSS%20-%20Le%20Manager%20en%20tant%20que%20ScrumMaster|Le Manager en tant que ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20LeSS%20Huge|Portail Less Huge (fr)]] - 100%'''
** [[LeSS%20-%20Domaines%20d%27exigences|Domaines d'Exigences (fr)]]
** [[LeSS%20-%20Backlog%20Produit%20de%20Domaine|Backlog Produit de Domaine (fr)]]
** [[LeSS%20-%20Product%20Owner%20de%20Domaine|Product Owner de Domaine (fr)]]
** [[LeSS%20-%20Structure%20organisationnelle%20pour%20LeSS%20Huge|Structure organisationnelle pour LeSS Huge (fr)]]
 

* '''[[LeSS%20-%20Portail%20Adoption|Portail Adoption (fr)]] - 100%'''
** [[LeSS%20-%20Les%20trois%20principes|Trois principes (fr)]]
** [[LeSS%20-%20D%C3%A9marrer|Démarrer (fr)]]
** [[LeSS%20-%20Coaching|Coaching (fr)]]
** [[LeSS%20-%20Am%C3%A9lioration%20continue|Amélioration Continue (fr)]]
** [[LeSS%20-%20Sch%C3%A9ma%20d%27adoption%20des%20%C3%A9quipes%20feature|Schéma d'adoption des équipes feature (fr)]]
** [[LeSS%20-%20Rester%20sain%20d%27esprit|Rester sain d'esprit (fr)]]
 

* '''LeSS Test'''
** [http://less.works/less/test/pre-course.html LeSS Test]
** [http://less.works/less/test/scrum.html Scrum Test]

LeSS - Tests unitaires

2022-07-03T19:01:37Z

Nicolas Mereaux : Ajout encadré

[[Category: Nicolas Mereaux]]
[[Category: Portail LeSS]]
[[Catégorie:Tests]]
Auteur : The LeSS Company B.V. 
Source : [https://less.works/less/technical-excellence/unit-testing.html Unit Testing - Large Scale Scrum (LeSS)] 
----
Traducteur : Nicolas Mereaux 
Relecteur : Fabrice Aimetti 
Date : 29/06/2022 
----
''Traduction :'' 
[[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 [http://c2.com/cgi/wiki?KentBeck 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''.

[[Image:Xunit_test_fr.png|Xunit_test_fr.png|border|link=|500px]]

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és 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 restent 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.

[[Image:Xtest_levels_fr.png|Xtest_levels_fr.png|border|link=|700px]]

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 sympa 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.

[[Image:Xunit_test_fr.png|Xunit_test_fr.png|border|link=|500px]]

== 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.

[[Image:unit_test_success.png|unit_test_success.png|border|link=|800px]]

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é.

[[Image:342xNxunit_test_fail.png|342xNxunit_test_fail.png|border|link=]]

=== 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.

<pre>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("a" * 5)

\# Assert : Contrôle que le résultat attendu s'est bien produit.
self.assertEqual(\["a" * 5\], wrapped)</pre>

=== 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)

<pre>
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</pre>

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’[https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd 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 utilisez [https://pypi.org/project/behave/ 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.

LeSS - Tests unitaires

2022-07-03T18:05:09Z

Nicolas Mereaux : Ajout relecteur

[[Category: Nicolas Mereaux]]
[[Category: Portail LeSS]]
[[Catégorie:Tests]]
Auteur : The LeSS Company B.V. 
Source : [https://less.works/less/technical-excellence/unit-testing.html Unit Testing - Large Scale Scrum (LeSS)] 
----
Traducteur : Nicolas Mereaux 
Relecteur : Fabrice Aimetti 
Date : 29/06/2022 
----
''Traduction :'' 
[[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 [http://c2.com/cgi/wiki?KentBeck 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''.

[[Image:Xunit_test_fr.png|Xunit_test_fr.png|border|link=|500px]]

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és 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 restent 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.

[[Image:Xtest_levels_fr.png|Xtest_levels_fr.png|border|link=|700px]]

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 sympa 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.

[[Image:Xunit_test_fr.png|Xunit_test_fr.png|border|link=|500px]]

== 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.

[[Image:unit_test_success.png|unit_test_success.png|border|link=|800px]]

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é.

[[Image:342xNxunit_test_fail.png|342xNxunit_test_fail.png|border|link=]]

=== 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.

<pre>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("a" * 5)

\# Assert : Contrôle que le résultat attendu s'est bien produit.
self.assertEqual(\["a" * 5\], wrapped)</pre>

=== 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</pre>

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’[https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd 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 utilisez [https://pypi.org/project/behave/ 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.

LeSS - Tests unitaires

2022-06-29T11:12:33Z

Nicolas Mereaux : Correction nom image

[[Category: Nicolas Mereaux]]
[[Category: Portail LeSS]]
[[Category:
[[Catégorie:Tests]]
Auteur : The LeSS Company B.V. 
Source : [https://less.works/less/technical-excellence/unit-testing.html Unit Testing - Large Scale Scrum (LeSS)] 
----
Traducteur : Nicolas Mereaux Date : 29/06/2022 
----
''Traduction :'' 
[[LeSS - Portail Excellence technique]] 

== What Is Unit Test? ==

== Qu’est-ce que les tests unitaires ? ==

'''Unit Test'''s are software programs written to exercise other software programs (called '''Code Under Test''', or '''Production Code''') with '''specific''' preconditions and verify the '''expected behaviour'''s of the CUT.

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

Unit tests are usually written in the same programming language as their code under test.

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

Each '''unit test''' should be small and test only limited piece of code functionality. Test cases are often grouped into '''Test Groups''' or '''Test Suites'''. There are many open source '''unit test framework'''s. The popular ones usually follow an '''xUnit''' pattern invented by [http://c2.com/cgi/wiki?KentBeck Kent Beck], for example, JUnit for Java and CppUTest for C/C++.

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 [http://c2.com/cgi/wiki?KentBeck Kent Beck].

Unit tests should also run very fast. Usually, we expect to '''run hundreds of unit test cases within a few seconds'''.

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'''.

== Why Unit Test ==

== Pourquoi faire des tests unitaires ? ==

The purpose of unit testing is not for finding bugs. It’s a '''specification''' for the expected behaviours of the code under test. The code under test is the implementation for those expected behaviours. So unit test and the code under test are used to check the correctness of each other, and protect each other. Later when someone changed the code under test, and it changed the behaviour that is expected by the original author, the test will fail. If you code is covered by reasonable unit test, you can maintain the code without breaking the existing feature. That’s why Michael Feathers define '''legacy code''' as ''code without unit test''.

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 et 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 du '''code hérité''' comme du ''code sans test unitaire''.

[[File:https://less.works/img/technical-excellence/xunit_test.png.pagespeed.ic.U9rHA2rtat.webp]]

[[Image:Xunit_test_fr.png|Xunit_test_fr.png]]

The purpose for unit testing is rather protect what we have implemented than to find any defects, just like the anchors set by a rock climber along his way up the rock. These anchors help him to protect what he has achieved.

Le but du test unitaire est donc plutôt de protéger ce que nous avons implémenté que de trouver des anomalies, tout comme les pitons mis 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.

=== Purpose of Unit Test ===

=== Objectif du test unitaire ===

The purpose of unit test can be summarised as:

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

* Facilitates changes
** It protects the behaviours decided by the previous programmers. So that people can change the code without breaking the existing features.
* Faciliter les changements
** Le test unitaire fait en sorte de protéger les comportements décidés par développeurs qui se sont succédés afin qu’il soit possible de changer le code sans casser les fonctionnalités existantes.
* Simplifies integration
** Unit test tests the basic units of the program, the functions and the classes. It makes sure the basic units are functioning as expected. When these units are integrated together, we can separate the integration problems (the coupling problems) from the unit internal problems (the cohesion problems).
* 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
** Well-written unit test can be used as documentation for the functionality of the code under test. Unit test contains information typically you cannot find from the code under test, for example, the design purpose of the original programming who wrote the code, and how the code is expected to be used. Unit test as documentation, unlike other traditional documentation, it doesn’t “lie”. Because if it lies, the test would fail. And that indicates either the test or the code is wrong.
* 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, quel est l’objectif de la conception du développeur à l’origine du code, 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é.
* Design tool
** Unit test is also an important design tool. Unit test requires testability from the code understand. Easy-to-test usually means easy-to-use. So unit test could be used to make sure the design has consideration from the perspective of use, rather than only from the perspective of implementation. Testable code needs better modularity and fewer dependencies. So that the unit test can easily take a small part of the code under test (a “unit”) without taking care of the overwhelming amount of dependencies. So unit test could be used to make sure the design has “high cohesion, low coupling”.
* Outil de conception
** Le test unitaire est aussi un outil de conception. Pour que le test unitaire remplisse son rôle, il est nécessaire d’appréhender la testabilité du code. 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. Par conséquence, le test unitaire peut donc 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 ».

=== Why on “Unit” Level? ===

=== Pourquoi à un niveau « unitaire » ? ===

“Yes, it’s important to use automated test to protect the existing functionalities. But why does it need to be on the unit level?”

« 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 ? »

You might wonder. Why don’t we just use thorough automated functional or system tests to protect the program?

Vous pourriez vous interroger. 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 ?

'''Total cost of ownership''' – Unit test is based on the abstraction level of the programming language. It’s just some code exercising other code. It doesn’t need to run in the same environment as the production. For compiled programming language, it doesn’t even need to use the same compiler as the production. The creating and running cost of unit test is very low. If designed properly, the cost of maintaining is also very low. You may not get the same level of confidence from one successful unit test case as you can get from a functional test. You will need many small unit test cases to get approximately the same level of confidence. But the cost of these small unit test cases is still much lower than owning a few functional test cases.

'''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 s’exécuter sur 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. Malgré tout, le coût de tous ces petits cas de test unitaire restent tout de même plus faible que celui de plusieurs cas de test fonctionnel.

If a software code base hasn’t got any unit test for the past 2 years, there will be extra cost for applying unit test to this code base. The cost comes mostly from two sources:

Si la base de code n’a eu aucun test unitaire dans les deux dernières années, il y aura un coût supplémentaire pour lui en appliquer un. Ce coût a deux sources principales :

# The cost of applying a test framework to the code project. This is relatively easier for dynamic programming languages like Python, Ruby or Javascript. Usually, it’s also trivial for Java and C# project. It can be quite tricky for C/C++ project. No matter easy or hard, this is just one-time investment.
# Le coût d’application d’un ''framework'' de test sur le code du projet. Cela 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 dans des projets Java ou C#. Cela peut être toutefois assez compliqué dans un projet C/C++. Que ce soit facile ou difficile, c’est un investissement à ne faire qu’une seule fois.
# The existing code base is not testable. The code was designed without considering the testability. Applying unit test to this kind of code base often involves improving the current design. Doing so doesn’t only increase the cost of creating test, but also has potential cost of introducing new bugs by changing the design. So applying unit test to existing code base should be combined with other works that need the change from the code under test – when you have to change that piece of code regardless.
# La base de code existante 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 base de code implique souvent de devoir améliorer la conception existante. Faire cette amélioration implique non seulement une augmentation du coût concernant la création des tests, mais a aussi potentiellement un coût d’introduire de nouvelles anomalies en changeant ladite conception. Par conséquent, l’introduction de tests unitaires à une base de code existante 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.

'''Internal Quality vs. External Quality''' – High level automated test like functional test and system test checks the external quality of the software. External quality means how well the software is functioning according to the requirement. Unit test is not as effective as the functional test in protecting the external quality. On the other hand, unit test ensures some of the internal qualities of the software. Internal quality here means the testability of the code and how well the code is protected. A testable design is in general a good design. Other levels of automated test cannot serve this purpose as well as unit test.

'''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 savoir 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 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.

'''Quality of feedback''' When you passed a functional test, you could be very confident about the functionality you just tested. But when you found it fail, usually you need to do some debugging to see what is wrong. Unit test might be able to give you more precise information about what is working and what is broken.

'''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.

Unit test is on the abstraction level of the programming language. When running unit test, everything should happen just within the CPU and memory. And each test case should be small. Therefore, it should run very fast. Typically, you should be able to run hundreds of unit tests within a few seconds. Including the compiling or other preparation time, the whole process of running unit test should take less than 1 minute.

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. Cela comprend 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.

Unit test should also be repeatable. If nothing changes, unit test runs should always return the same result.

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 retourner toujours le même résultat.

If the unit test is very fast and repeatable, programmers can run it as often as they want, e.g. every a few minutes. The unit test will continuously provide quality feedback to the programmer. So that the programmer can go with a steady progress and focus on more important things rather than spending too much energy on trivial issues.

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 quelques 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.

[[File:https://less.works/img/technical-excellence/xtest_levels.png.pagespeed.ic.-xbOy_tP-P.png]]

[[Image:Xtest_levels_fr.png|Xtest_levels_fr.png]]

A reasonable automated test structure should be like a pyramid. At the bottom are a lot of unit test cases. In the middle are much fewer integration level test cases. On the top, there are even fewer functional/system level tests.

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.

== Common Misconceptions of Unit Test ==

== Idées fausses à propos du test unitaire ==

=== Unit test is not as important as the production code ===

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

It is true that in the end, it’s production code that makes the product. But most software products have evolutionary life cycles. The code is not static. It changes over time. Code without unit test does not have the necessary protection when being changed. Unit test also contains important information that is not included in the production code.

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. Du code sans test unitaire n’est 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.

So unit test is just as important as the production code. They should be '''in the same SCM repository'''. They should follow the same coding standard as the production code.

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.

=== Unit Test is done by testing engineers ===

=== Le test unitaire est fait par des ingénieurs tests ===

The purpose of unit test is not for finding bugs. Technically, it ''checks'' rather than ''tests'' if the code under test has implemented the behaviour intended by the programmer who designed it. So the reasonable choice is just let the same programmer writes both the test and the code under test.

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.

It’s also encouraged to have two or more people pair up to do the programming together. They write the unit test and the code under test together. There are many fun ways of ''pair-programming''. You may find more information in the Test-Driven Development section.

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 sympa pour programmer en binôme. Vous trouverez davantage d’informations à ce sujet dans la section développement piloté par les tests.

=== You can write unit test without changing the code under test ===

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

This is often not true. If the code doesn’t have good testability, you might still be able to write unit test for it technically. But the unit test written for non-testable code is usually very hard to maintain and understand. Therefore, it doesn’t make much sense to have it.

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.

'''The secret of unit test is not about writing test, but writing testable code under test.''' We want testable code and easy test, which is a win-win. We don’t want non-testable code and hard-to-maintain code, which is a lose-lose.

'''Le secret du test unitaire n’est pas d’écrire du test, mais d’écrire du 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.

=== I can add unit test later ===

=== Je peux ajouter les tests unitaires plus tard ===

Well, try asking the rock climbers to set their anchors later.

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

[[File:https://less.works/img/technical-excellence/xunit_test.png.pagespeed.ic.U9rHA2rtat.webp]]

[[Image:Xunit_test_fr.png|Xunit_test_fr.png]]

== Good Unit Test Patterns ==

== Schéma pour de bons tests unitaires ==

=== No news is good news ===

=== Pas de nouvelles, bonnes nouvelles ===

If the test passes, it should just print OK (and perhaps some dots to show the progress). No other information.

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

[[File:https://less.works/img/technical-excellence/500xNxunit_test_success.png.pagespeed.ic.W3mg1FIwIC.png]]

[[Image:unit_test_success.png|unit_test_success.png]]

Rule of thumb:

En règle générale :

<blockquote>No human intervention should be needed to get ready for the test, running the test cases or checking the result.
</blockquote>
<blockquote>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.
</blockquote>
And when it fails, it should provide precise information. The goal is to limit the amount of time you spend on debugging when the test fails. 
[[File:https://less.works/img/technical-excellence/342xNxunit_test_fail.png.pagespeed.ic.eM-9actgRz.png]]

[[Image:342xNxunit_test_fail.png|342xNxunit_test_fail.png]]

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és à débogguer le code concerné.

=== Arrange, Act, Assert ===

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

A good pattern to follow in a unit test is “'''AAA'''”: '''Arrange''', '''Act''' and '''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)'''

If you can easily find this pattern in each of your test cases, your tests should be easy to understand, and they should be fairly specific and to the point. One unit test case should test only one thing. Therefore, there should be only one set of AAA in one test case. A test case shouldn’t be very long (longer than 10 lines of code) if it follows the AAA pattern.

Si vous pouvez repérer ce schéma dans chacun de vos cas de tests, vos tests devraient 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):

<pre>def test\_should\_have\_no\_wrapping\_when\_string\_length\_is\_5\_and\_line\_width\_is\_10(self):
\# Arrange: Arrange all necessary preconditions and inputs.
wrapper = TextWrapper(width=10)

\# Act: Act on the object or method under test.
wrapped = wrapper.wrap("a" * 5)

\# Assert: Assert that the expected results have occurred.
self.assertEqual(\["a" * 5\], wrapped)</pre>
import unittest class TestGroupForTextWrapping(unittest.TestCase):

<pre> def test\_ne\_devrait\_pas\_avoir\_de\_retour\_à\_la\_ligne\_lorsque\_la\_longueur\_de\_la\_chaîne\_de\_caractères\_est\_de\_5\_et\_que\_la\_hauteur\_est\_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("a" * 5)

\# Assert : Contrôle que le résultat attendu s'est bien produit.
self.assertEqual(\["a" * 5\], wrapped)</pre>
=== Behaviour Driven Development (BDD) Style ===

=== Développement piloté par le comportement (BDD) ===

Similar to the '''AAA''' pattern, the '''BDD''' style uses three other keywords to specify each test case: '''Given''', '''When''' and '''Then'''. (You can also use '''And''' as another keyword.)

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)

<pre>Given The Text Wrapper's Width Defined As 10
And Using '-' As Word Connector
When The Wrapper Wrap Text Length is Less Than 10
Then The Text Should Not Be Wrapped

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</pre>
As you can see, “given-when-then” maps to “arrange-act-assert” pretty well. They both simply define a state transition of a Finite State Machine (FSM). You can find more on this in the [https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd Uncle Bob’s article]. Some differences:

Comme vous pouvez le constater, le triptyque « étant donné - lorsque - alors » correspond 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’[https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd Oncle Bob]. Voici quelques différences entre les deux :

* BDD is more “outside-in”, which means that it emphasises more the external behaviour
* With BDD, you need to define a '''domain specific language''' to write your test specifications. Because of this, usually you’ll need a different framework. One example for Python is [http://pythonhosted.org/behave/ behave].
* Le BDD est davantage « dehors-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 utilisez [http://pythonhosted.org/behave/ behave].

=== The Golden Rule Of a Unit Test ===

=== La règle d’or du test unitaire ===

In general, a good rule for unit test case is:

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

<blockquote>'''Each unit test case should be very limited in scope.'''
</blockquote>
<blockquote>'''Chaque cas de test unitaire devrait comporter un périmètre très restreint.'''
</blockquote>
So that:

De telle manière que :

* When the test fails, no debugging is needed to locate the problem.
* Tests are stable because dependencies are simple.
* Less duplication, easier to maintain.
* 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

There is no secret to write good unit test. In order to write good unit test, you need to create easy-to-test design.

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.

Fichier:342xNxunit test fail.png

2022-06-29T11:12:01Z

Nicolas Mereaux :

LeSS - Tests unitaires

2022-06-29T11:10:24Z

Nicolas Mereaux : Ajout images

[[Category: Nicolas Mereaux]]
[[Category: Portail LeSS]]
[[Category:
[[Catégorie:Tests]]
Auteur : The LeSS Company B.V. 
Source : [https://less.works/less/technical-excellence/unit-testing.html Unit Testing - Large Scale Scrum (LeSS)] 
----
Traducteur : Nicolas Mereaux Date : 29/06/2022 
----
''Traduction :'' 
[[LeSS - Portail Excellence technique]] 

== What Is Unit Test? ==

== Qu’est-ce que les tests unitaires ? ==

'''Unit Test'''s are software programs written to exercise other software programs (called '''Code Under Test''', or '''Production Code''') with '''specific''' preconditions and verify the '''expected behaviour'''s of the CUT.

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

Unit tests are usually written in the same programming language as their code under test.

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

Each '''unit test''' should be small and test only limited piece of code functionality. Test cases are often grouped into '''Test Groups''' or '''Test Suites'''. There are many open source '''unit test framework'''s. The popular ones usually follow an '''xUnit''' pattern invented by [http://c2.com/cgi/wiki?KentBeck Kent Beck], for example, JUnit for Java and CppUTest for C/C++.

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 [http://c2.com/cgi/wiki?KentBeck Kent Beck].

Unit tests should also run very fast. Usually, we expect to '''run hundreds of unit test cases within a few seconds'''.

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'''.

== Why Unit Test ==

== Pourquoi faire des tests unitaires ? ==

The purpose of unit testing is not for finding bugs. It’s a '''specification''' for the expected behaviours of the code under test. The code under test is the implementation for those expected behaviours. So unit test and the code under test are used to check the correctness of each other, and protect each other. Later when someone changed the code under test, and it changed the behaviour that is expected by the original author, the test will fail. If you code is covered by reasonable unit test, you can maintain the code without breaking the existing feature. That’s why Michael Feathers define '''legacy code''' as ''code without unit test''.

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 et 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 du '''code hérité''' comme du ''code sans test unitaire''.

[[File:https://less.works/img/technical-excellence/xunit_test.png.pagespeed.ic.U9rHA2rtat.webp]]

[[Image:Xunit_test_fr.png|Xunit_test_fr.png]]

The purpose for unit testing is rather protect what we have implemented than to find any defects, just like the anchors set by a rock climber along his way up the rock. These anchors help him to protect what he has achieved.

Le but du test unitaire est donc plutôt de protéger ce que nous avons implémenté que de trouver des anomalies, tout comme les pitons mis 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.

=== Purpose of Unit Test ===

=== Objectif du test unitaire ===

The purpose of unit test can be summarised as:

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

* Facilitates changes
** It protects the behaviours decided by the previous programmers. So that people can change the code without breaking the existing features.
* Faciliter les changements
** Le test unitaire fait en sorte de protéger les comportements décidés par développeurs qui se sont succédés afin qu’il soit possible de changer le code sans casser les fonctionnalités existantes.
* Simplifies integration
** Unit test tests the basic units of the program, the functions and the classes. It makes sure the basic units are functioning as expected. When these units are integrated together, we can separate the integration problems (the coupling problems) from the unit internal problems (the cohesion problems).
* 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
** Well-written unit test can be used as documentation for the functionality of the code under test. Unit test contains information typically you cannot find from the code under test, for example, the design purpose of the original programming who wrote the code, and how the code is expected to be used. Unit test as documentation, unlike other traditional documentation, it doesn’t “lie”. Because if it lies, the test would fail. And that indicates either the test or the code is wrong.
* 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, quel est l’objectif de la conception du développeur à l’origine du code, 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é.
* Design tool
** Unit test is also an important design tool. Unit test requires testability from the code understand. Easy-to-test usually means easy-to-use. So unit test could be used to make sure the design has consideration from the perspective of use, rather than only from the perspective of implementation. Testable code needs better modularity and fewer dependencies. So that the unit test can easily take a small part of the code under test (a “unit”) without taking care of the overwhelming amount of dependencies. So unit test could be used to make sure the design has “high cohesion, low coupling”.
* Outil de conception
** Le test unitaire est aussi un outil de conception. Pour que le test unitaire remplisse son rôle, il est nécessaire d’appréhender la testabilité du code. 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. Par conséquence, le test unitaire peut donc 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 ».

=== Why on “Unit” Level? ===

=== Pourquoi à un niveau « unitaire » ? ===

“Yes, it’s important to use automated test to protect the existing functionalities. But why does it need to be on the unit level?”

« 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 ? »

You might wonder. Why don’t we just use thorough automated functional or system tests to protect the program?

Vous pourriez vous interroger. 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 ?

'''Total cost of ownership''' – Unit test is based on the abstraction level of the programming language. It’s just some code exercising other code. It doesn’t need to run in the same environment as the production. For compiled programming language, it doesn’t even need to use the same compiler as the production. The creating and running cost of unit test is very low. If designed properly, the cost of maintaining is also very low. You may not get the same level of confidence from one successful unit test case as you can get from a functional test. You will need many small unit test cases to get approximately the same level of confidence. But the cost of these small unit test cases is still much lower than owning a few functional test cases.

'''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 s’exécuter sur 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. Malgré tout, le coût de tous ces petits cas de test unitaire restent tout de même plus faible que celui de plusieurs cas de test fonctionnel.

If a software code base hasn’t got any unit test for the past 2 years, there will be extra cost for applying unit test to this code base. The cost comes mostly from two sources:

Si la base de code n’a eu aucun test unitaire dans les deux dernières années, il y aura un coût supplémentaire pour lui en appliquer un. Ce coût a deux sources principales :

# The cost of applying a test framework to the code project. This is relatively easier for dynamic programming languages like Python, Ruby or Javascript. Usually, it’s also trivial for Java and C# project. It can be quite tricky for C/C++ project. No matter easy or hard, this is just one-time investment.
# Le coût d’application d’un ''framework'' de test sur le code du projet. Cela 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 dans des projets Java ou C#. Cela peut être toutefois assez compliqué dans un projet C/C++. Que ce soit facile ou difficile, c’est un investissement à ne faire qu’une seule fois.
# The existing code base is not testable. The code was designed without considering the testability. Applying unit test to this kind of code base often involves improving the current design. Doing so doesn’t only increase the cost of creating test, but also has potential cost of introducing new bugs by changing the design. So applying unit test to existing code base should be combined with other works that need the change from the code under test – when you have to change that piece of code regardless.
# La base de code existante 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 base de code implique souvent de devoir améliorer la conception existante. Faire cette amélioration implique non seulement une augmentation du coût concernant la création des tests, mais a aussi potentiellement un coût d’introduire de nouvelles anomalies en changeant ladite conception. Par conséquent, l’introduction de tests unitaires à une base de code existante 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.

'''Internal Quality vs. External Quality''' – High level automated test like functional test and system test checks the external quality of the software. External quality means how well the software is functioning according to the requirement. Unit test is not as effective as the functional test in protecting the external quality. On the other hand, unit test ensures some of the internal qualities of the software. Internal quality here means the testability of the code and how well the code is protected. A testable design is in general a good design. Other levels of automated test cannot serve this purpose as well as unit test.

'''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 savoir 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 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.

'''Quality of feedback''' When you passed a functional test, you could be very confident about the functionality you just tested. But when you found it fail, usually you need to do some debugging to see what is wrong. Unit test might be able to give you more precise information about what is working and what is broken.

'''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.

Unit test is on the abstraction level of the programming language. When running unit test, everything should happen just within the CPU and memory. And each test case should be small. Therefore, it should run very fast. Typically, you should be able to run hundreds of unit tests within a few seconds. Including the compiling or other preparation time, the whole process of running unit test should take less than 1 minute.

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. Cela comprend 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.

Unit test should also be repeatable. If nothing changes, unit test runs should always return the same result.

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 retourner toujours le même résultat.

If the unit test is very fast and repeatable, programmers can run it as often as they want, e.g. every a few minutes. The unit test will continuously provide quality feedback to the programmer. So that the programmer can go with a steady progress and focus on more important things rather than spending too much energy on trivial issues.

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 quelques 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.

[[File:https://less.works/img/technical-excellence/xtest_levels.png.pagespeed.ic.-xbOy_tP-P.png]]

[[Image:Xtest_levels_fr.png|Xtest_levels_fr.png]]

A reasonable automated test structure should be like a pyramid. At the bottom are a lot of unit test cases. In the middle are much fewer integration level test cases. On the top, there are even fewer functional/system level tests.

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.

== Common Misconceptions of Unit Test ==

== Idées fausses à propos du test unitaire ==

=== Unit test is not as important as the production code ===

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

It is true that in the end, it’s production code that makes the product. But most software products have evolutionary life cycles. The code is not static. It changes over time. Code without unit test does not have the necessary protection when being changed. Unit test also contains important information that is not included in the production code.

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. Du code sans test unitaire n’est 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.

So unit test is just as important as the production code. They should be '''in the same SCM repository'''. They should follow the same coding standard as the production code.

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.

=== Unit Test is done by testing engineers ===

=== Le test unitaire est fait par des ingénieurs tests ===

The purpose of unit test is not for finding bugs. Technically, it ''checks'' rather than ''tests'' if the code under test has implemented the behaviour intended by the programmer who designed it. So the reasonable choice is just let the same programmer writes both the test and the code under test.

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.

It’s also encouraged to have two or more people pair up to do the programming together. They write the unit test and the code under test together. There are many fun ways of ''pair-programming''. You may find more information in the Test-Driven Development section.

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 sympa pour programmer en binôme. Vous trouverez davantage d’informations à ce sujet dans la section développement piloté par les tests.

=== You can write unit test without changing the code under test ===

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

This is often not true. If the code doesn’t have good testability, you might still be able to write unit test for it technically. But the unit test written for non-testable code is usually very hard to maintain and understand. Therefore, it doesn’t make much sense to have it.

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.

'''The secret of unit test is not about writing test, but writing testable code under test.''' We want testable code and easy test, which is a win-win. We don’t want non-testable code and hard-to-maintain code, which is a lose-lose.

'''Le secret du test unitaire n’est pas d’écrire du test, mais d’écrire du 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.

=== I can add unit test later ===

=== Je peux ajouter les tests unitaires plus tard ===

Well, try asking the rock climbers to set their anchors later.

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

[[File:https://less.works/img/technical-excellence/xunit_test.png.pagespeed.ic.U9rHA2rtat.webp]]

[[Image:Xunit_test_fr.png|Xunit_test_fr.png]]

== Good Unit Test Patterns ==

== Schéma pour de bons tests unitaires ==

=== No news is good news ===

=== Pas de nouvelles, bonnes nouvelles ===

If the test passes, it should just print OK (and perhaps some dots to show the progress). No other information.

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

[[File:https://less.works/img/technical-excellence/500xNxunit_test_success.png.pagespeed.ic.W3mg1FIwIC.png]]

[[Image:unit_test_success.png|unit_test_success.png]]

Rule of thumb:

En règle générale :

<blockquote>No human intervention should be needed to get ready for the test, running the test cases or checking the result.
</blockquote>
<blockquote>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.
</blockquote>
And when it fails, it should provide precise information. The goal is to limit the amount of time you spend on debugging when the test fails. 
[[File:https://less.works/img/technical-excellence/342xNxunit_test_fail.png.pagespeed.ic.eM-9actgRz.png]]

[[Image:342xNxunit_test_fail.png.pagespeed.ic.eM-9actgRz.png|342xNxunit_test_fail.png.pagespeed.ic.eM-9actgRz.png]]

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és à débogguer le code concerné.

=== Arrange, Act, Assert ===

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

A good pattern to follow in a unit test is “'''AAA'''”: '''Arrange''', '''Act''' and '''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)'''

If you can easily find this pattern in each of your test cases, your tests should be easy to understand, and they should be fairly specific and to the point. One unit test case should test only one thing. Therefore, there should be only one set of AAA in one test case. A test case shouldn’t be very long (longer than 10 lines of code) if it follows the AAA pattern.

Si vous pouvez repérer ce schéma dans chacun de vos cas de tests, vos tests devraient 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):

<pre>def test\_should\_have\_no\_wrapping\_when\_string\_length\_is\_5\_and\_line\_width\_is\_10(self):
\# Arrange: Arrange all necessary preconditions and inputs.
wrapper = TextWrapper(width=10)

\# Act: Act on the object or method under test.
wrapped = wrapper.wrap("a" * 5)

\# Assert: Assert that the expected results have occurred.
self.assertEqual(\["a" * 5\], wrapped)</pre>
import unittest class TestGroupForTextWrapping(unittest.TestCase):

<pre> def test\_ne\_devrait\_pas\_avoir\_de\_retour\_à\_la\_ligne\_lorsque\_la\_longueur\_de\_la\_chaîne\_de\_caractères\_est\_de\_5\_et\_que\_la\_hauteur\_est\_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("a" * 5)

\# Assert : Contrôle que le résultat attendu s'est bien produit.
self.assertEqual(\["a" * 5\], wrapped)</pre>
=== Behaviour Driven Development (BDD) Style ===

=== Développement piloté par le comportement (BDD) ===

Similar to the '''AAA''' pattern, the '''BDD''' style uses three other keywords to specify each test case: '''Given''', '''When''' and '''Then'''. (You can also use '''And''' as another keyword.)

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)

<pre>Given The Text Wrapper's Width Defined As 10
And Using '-' As Word Connector
When The Wrapper Wrap Text Length is Less Than 10
Then The Text Should Not Be Wrapped

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</pre>
As you can see, “given-when-then” maps to “arrange-act-assert” pretty well. They both simply define a state transition of a Finite State Machine (FSM). You can find more on this in the [https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd Uncle Bob’s article]. Some differences:

Comme vous pouvez le constater, le triptyque « étant donné - lorsque - alors » correspond 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’[https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd Oncle Bob]. Voici quelques différences entre les deux :

* BDD is more “outside-in”, which means that it emphasises more the external behaviour
* With BDD, you need to define a '''domain specific language''' to write your test specifications. Because of this, usually you’ll need a different framework. One example for Python is [http://pythonhosted.org/behave/ behave].
* Le BDD est davantage « dehors-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 utilisez [http://pythonhosted.org/behave/ behave].

=== The Golden Rule Of a Unit Test ===

=== La règle d’or du test unitaire ===

In general, a good rule for unit test case is:

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

<blockquote>'''Each unit test case should be very limited in scope.'''
</blockquote>
<blockquote>'''Chaque cas de test unitaire devrait comporter un périmètre très restreint.'''
</blockquote>
So that:

De telle manière que :

* When the test fails, no debugging is needed to locate the problem.
* Tests are stable because dependencies are simple.
* Less duplication, easier to maintain.
* 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

There is no secret to write good unit test. In order to write good unit test, you need to create easy-to-test design.

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.

Fichier:Unit test success.png

2022-06-29T11:06:50Z

Nicolas Mereaux :

LeSS - Tests unitaires

2022-06-29T06:39:47Z

Nicolas Mereaux : Correction date

[[Category: Nicolas Mereaux]]
[[Category: Portail LeSS]]
[[Category:
[[Catégorie:Tests]]
Auteur : The LeSS Company B.V. 
Source : [https://less.works/less/technical-excellence/unit-testing.html Unit Testing - Large Scale Scrum (LeSS)] 
----
Traducteur : Nicolas Mereaux Date : 29/06/2022 
----
''Traduction :'' 
[[LeSS - Portail Excellence technique]] 

== What Is Unit Test? ==

== Qu’est-ce que les tests unitaires ? ==

'''Unit Test'''s are software programs written to exercise other software programs (called '''Code Under Test''', or '''Production Code''') with '''specific''' preconditions and verify the '''expected behaviour'''s of the CUT.

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

Unit tests are usually written in the same programming language as their code under test.

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

Each '''unit test''' should be small and test only limited piece of code functionality. Test cases are often grouped into '''Test Groups''' or '''Test Suites'''. There are many open source '''unit test framework'''s. The popular ones usually follow an '''xUnit''' pattern invented by [http://c2.com/cgi/wiki?KentBeck Kent Beck], for example, JUnit for Java and CppUTest for C/C++.

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 [http://c2.com/cgi/wiki?KentBeck Kent Beck].

Unit tests should also run very fast. Usually, we expect to '''run hundreds of unit test cases within a few seconds'''.

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'''.

== Why Unit Test ==

== Pourquoi faire des tests unitaires ? ==

The purpose of unit testing is not for finding bugs. It’s a '''specification''' for the expected behaviours of the code under test. The code under test is the implementation for those expected behaviours. So unit test and the code under test are used to check the correctness of each other, and protect each other. Later when someone changed the code under test, and it changed the behaviour that is expected by the original author, the test will fail. If you code is covered by reasonable unit test, you can maintain the code without breaking the existing feature. That’s why Michael Feathers define '''legacy code''' as ''code without unit test''.

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 et 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 du '''code hérité''' comme du ''code sans test unitaire''.

[[File:https://less.works/img/technical-excellence/xunit_test.png.pagespeed.ic.U9rHA2rtat.webp]]

[[Image:Xunit_test_fr.png|Xunit_test_fr.png]]

The purpose for unit testing is rather protect what we have implemented than to find any defects, just like the anchors set by a rock climber along his way up the rock. These anchors help him to protect what he has achieved.

Le but du test unitaire est donc plutôt de protéger ce que nous avons implémenté que de trouver des anomalies, tout comme les pitons mis 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.

=== Purpose of Unit Test ===

=== Objectif du test unitaire ===

The purpose of unit test can be summarised as:

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

* Facilitates changes
** It protects the behaviours decided by the previous programmers. So that people can change the code without breaking the existing features.
* Faciliter les changements
** Le test unitaire fait en sorte de protéger les comportements décidés par développeurs qui se sont succédés afin qu’il soit possible de changer le code sans casser les fonctionnalités existantes.
* Simplifies integration
** Unit test tests the basic units of the program, the functions and the classes. It makes sure the basic units are functioning as expected. When these units are integrated together, we can separate the integration problems (the coupling problems) from the unit internal problems (the cohesion problems).
* 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
** Well-written unit test can be used as documentation for the functionality of the code under test. Unit test contains information typically you cannot find from the code under test, for example, the design purpose of the original programming who wrote the code, and how the code is expected to be used. Unit test as documentation, unlike other traditional documentation, it doesn’t “lie”. Because if it lies, the test would fail. And that indicates either the test or the code is wrong.
* 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, quel est l’objectif de la conception du développeur à l’origine du code, 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é.
* Design tool
** Unit test is also an important design tool. Unit test requires testability from the code understand. Easy-to-test usually means easy-to-use. So unit test could be used to make sure the design has consideration from the perspective of use, rather than only from the perspective of implementation. Testable code needs better modularity and fewer dependencies. So that the unit test can easily take a small part of the code under test (a “unit”) without taking care of the overwhelming amount of dependencies. So unit test could be used to make sure the design has “high cohesion, low coupling”.
* Outil de conception
** Le test unitaire est aussi un outil de conception. Pour que le test unitaire remplisse son rôle, il est nécessaire d’appréhender la testabilité du code. 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. Par conséquence, le test unitaire peut donc 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 ».

=== Why on “Unit” Level? ===

=== Pourquoi à un niveau « unitaire » ? ===

“Yes, it’s important to use automated test to protect the existing functionalities. But why does it need to be on the unit level?”

« 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 ? »

You might wonder. Why don’t we just use thorough automated functional or system tests to protect the program?

Vous pourriez vous interroger. 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 ?

'''Total cost of ownership''' – Unit test is based on the abstraction level of the programming language. It’s just some code exercising other code. It doesn’t need to run in the same environment as the production. For compiled programming language, it doesn’t even need to use the same compiler as the production. The creating and running cost of unit test is very low. If designed properly, the cost of maintaining is also very low. You may not get the same level of confidence from one successful unit test case as you can get from a functional test. You will need many small unit test cases to get approximately the same level of confidence. But the cost of these small unit test cases is still much lower than owning a few functional test cases.

'''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 s’exécuter sur 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. Malgré tout, le coût de tous ces petits cas de test unitaire restent tout de même plus faible que celui de plusieurs cas de test fonctionnel.

If a software code base hasn’t got any unit test for the past 2 years, there will be extra cost for applying unit test to this code base. The cost comes mostly from two sources:

Si la base de code n’a eu aucun test unitaire dans les deux dernières années, il y aura un coût supplémentaire pour lui en appliquer un. Ce coût a deux sources principales :

# The cost of applying a test framework to the code project. This is relatively easier for dynamic programming languages like Python, Ruby or Javascript. Usually, it’s also trivial for Java and C# project. It can be quite tricky for C/C++ project. No matter easy or hard, this is just one-time investment.
# Le coût d’application d’un ''framework'' de test sur le code du projet. Cela 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 dans des projets Java ou C#. Cela peut être toutefois assez compliqué dans un projet C/C++. Que ce soit facile ou difficile, c’est un investissement à ne faire qu’une seule fois.
# The existing code base is not testable. The code was designed without considering the testability. Applying unit test to this kind of code base often involves improving the current design. Doing so doesn’t only increase the cost of creating test, but also has potential cost of introducing new bugs by changing the design. So applying unit test to existing code base should be combined with other works that need the change from the code under test – when you have to change that piece of code regardless.
# La base de code existante 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 base de code implique souvent de devoir améliorer la conception existante. Faire cette amélioration implique non seulement une augmentation du coût concernant la création des tests, mais a aussi potentiellement un coût d’introduire de nouvelles anomalies en changeant ladite conception. Par conséquent, l’introduction de tests unitaires à une base de code existante 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.

'''Internal Quality vs. External Quality''' – High level automated test like functional test and system test checks the external quality of the software. External quality means how well the software is functioning according to the requirement. Unit test is not as effective as the functional test in protecting the external quality. On the other hand, unit test ensures some of the internal qualities of the software. Internal quality here means the testability of the code and how well the code is protected. A testable design is in general a good design. Other levels of automated test cannot serve this purpose as well as unit test.

'''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 savoir 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 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.

'''Quality of feedback''' When you passed a functional test, you could be very confident about the functionality you just tested. But when you found it fail, usually you need to do some debugging to see what is wrong. Unit test might be able to give you more precise information about what is working and what is broken.

'''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.

Unit test is on the abstraction level of the programming language. When running unit test, everything should happen just within the CPU and memory. And each test case should be small. Therefore, it should run very fast. Typically, you should be able to run hundreds of unit tests within a few seconds. Including the compiling or other preparation time, the whole process of running unit test should take less than 1 minute.

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. Cela comprend 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.

Unit test should also be repeatable. If nothing changes, unit test runs should always return the same result.

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 retourner toujours le même résultat.

If the unit test is very fast and repeatable, programmers can run it as often as they want, e.g. every a few minutes. The unit test will continuously provide quality feedback to the programmer. So that the programmer can go with a steady progress and focus on more important things rather than spending too much energy on trivial issues.

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 quelques 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.

[[File:https://less.works/img/technical-excellence/xtest_levels.png.pagespeed.ic.-xbOy_tP-P.png]]

[[Image:Xtest_levels_fr.png|Xtest_levels_fr.png]]

A reasonable automated test structure should be like a pyramid. At the bottom are a lot of unit test cases. In the middle are much fewer integration level test cases. On the top, there are even fewer functional/system level tests.

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.

== Common Misconceptions of Unit Test ==

== Idées fausses à propos du test unitaire ==

=== Unit test is not as important as the production code ===

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

It is true that in the end, it’s production code that makes the product. But most software products have evolutionary life cycles. The code is not static. It changes over time. Code without unit test does not have the necessary protection when being changed. Unit test also contains important information that is not included in the production code.

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. Du code sans test unitaire n’est 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.

So unit test is just as important as the production code. They should be '''in the same SCM repository'''. They should follow the same coding standard as the production code.

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.

=== Unit Test is done by testing engineers ===

=== Le test unitaire est fait par des ingénieurs tests ===

The purpose of unit test is not for finding bugs. Technically, it ''checks'' rather than ''tests'' if the code under test has implemented the behaviour intended by the programmer who designed it. So the reasonable choice is just let the same programmer writes both the test and the code under test.

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.

It’s also encouraged to have two or more people pair up to do the programming together. They write the unit test and the code under test together. There are many fun ways of ''pair-programming''. You may find more information in the Test-Driven Development section.

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 sympa pour programmer en binôme. Vous trouverez davantage d’informations à ce sujet dans la section développement piloté par les tests.

=== You can write unit test without changing the code under test ===

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

This is often not true. If the code doesn’t have good testability, you might still be able to write unit test for it technically. But the unit test written for non-testable code is usually very hard to maintain and understand. Therefore, it doesn’t make much sense to have it.

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.

'''The secret of unit test is not about writing test, but writing testable code under test.''' We want testable code and easy test, which is a win-win. We don’t want non-testable code and hard-to-maintain code, which is a lose-lose.

'''Le secret du test unitaire n’est pas d’écrire du test, mais d’écrire du 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.

=== I can add unit test later ===

=== Je peux ajouter les tests unitaires plus tard ===

Well, try asking the rock climbers to set their anchors later.

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

[[File:https://less.works/img/technical-excellence/xunit_test.png.pagespeed.ic.U9rHA2rtat.webp]]

== Good Unit Test Patterns ==

== Schéma pour de bons tests unitaires ==

=== No news is good news ===

=== Pas de nouvelles, bonnes nouvelles ===

If the test passes, it should just print OK (and perhaps some dots to show the progress). No other information.

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

[[File:https://less.works/img/technical-excellence/500xNxunit_test_success.png.pagespeed.ic.W3mg1FIwIC.png]]

Rule of thumb:

En règle générale :

<blockquote>No human intervention should be needed to get ready for the test, running the test cases or checking the result.
</blockquote>
<blockquote>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.
</blockquote>
And when it fails, it should provide precise information. The goal is to limit the amount of time you spend on debugging when the test fails. 
[[File:https://less.works/img/technical-excellence/342xNxunit_test_fail.png.pagespeed.ic.eM-9actgRz.png]]

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és à débogguer le code concerné.

=== Arrange, Act, Assert ===

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

A good pattern to follow in a unit test is “'''AAA'''”: '''Arrange''', '''Act''' and '''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)'''

If you can easily find this pattern in each of your test cases, your tests should be easy to understand, and they should be fairly specific and to the point. One unit test case should test only one thing. Therefore, there should be only one set of AAA in one test case. A test case shouldn’t be very long (longer than 10 lines of code) if it follows the AAA pattern.

Si vous pouvez repérer ce schéma dans chacun de vos cas de tests, vos tests devraient 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):

<pre>def test\_should\_have\_no\_wrapping\_when\_string\_length\_is\_5\_and\_line\_width\_is\_10(self):
\# Arrange: Arrange all necessary preconditions and inputs.
wrapper = TextWrapper(width=10)

\# Act: Act on the object or method under test.
wrapped = wrapper.wrap("a" * 5)

\# Assert: Assert that the expected results have occurred.
self.assertEqual(\["a" * 5\], wrapped)</pre>
import unittest class TestGroupForTextWrapping(unittest.TestCase):

<pre> def test\_ne\_devrait\_pas\_avoir\_de\_retour\_à\_la\_ligne\_lorsque\_la\_longueur\_de\_la\_chaîne\_de\_caractères\_est\_de\_5\_et\_que\_la\_hauteur\_est\_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("a" * 5)

\# Assert : Contrôle que le résultat attendu s'est bien produit.
self.assertEqual(\["a" * 5\], wrapped)</pre>
=== Behaviour Driven Development (BDD) Style ===

=== Développement piloté par le comportement (BDD) ===

Similar to the '''AAA''' pattern, the '''BDD''' style uses three other keywords to specify each test case: '''Given''', '''When''' and '''Then'''. (You can also use '''And''' as another keyword.)

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)

<pre>Given The Text Wrapper's Width Defined As 10
And Using '-' As Word Connector
When The Wrapper Wrap Text Length is Less Than 10
Then The Text Should Not Be Wrapped

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</pre>
As you can see, “given-when-then” maps to “arrange-act-assert” pretty well. They both simply define a state transition of a Finite State Machine (FSM). You can find more on this in the [https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd Uncle Bob’s article]. Some differences:

Comme vous pouvez le constater, le triptyque « étant donné - lorsque - alors » correspond 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’[https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd Oncle Bob]. Voici quelques différences entre les deux :

* BDD is more “outside-in”, which means that it emphasises more the external behaviour
* With BDD, you need to define a '''domain specific language''' to write your test specifications. Because of this, usually you’ll need a different framework. One example for Python is [http://pythonhosted.org/behave/ behave].
* Le BDD est davantage « dehors-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 utilisez [http://pythonhosted.org/behave/ behave].

=== The Golden Rule Of a Unit Test ===

=== La règle d’or du test unitaire ===

In general, a good rule for unit test case is:

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

<blockquote>'''Each unit test case should be very limited in scope.'''
</blockquote>
<blockquote>'''Chaque cas de test unitaire devrait comporter un périmètre très restreint.'''
</blockquote>
So that:

De telle manière que :

* When the test fails, no debugging is needed to locate the problem.
* Tests are stable because dependencies are simple.
* Less duplication, easier to maintain.
* 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

There is no secret to write good unit test. In order to write good unit test, you need to create easy-to-test design.

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.

LeSS - Tests unitaires

2022-06-29T06:39:12Z

Nicolas Mereaux : Ajout de la page tests unitaires

[[Category: Nicolas Mereaux]]
[[Category: Portail LeSS]]
[[Category:
[[Catégorie:Tests]]
Auteur : The LeSS Company B.V. 
Source : [https://less.works/less/technical-excellence/unit-testing.html Unit Testing - Large Scale Scrum (LeSS)] 
----
Traducteur : Nicolas Mereaux Date : 29/06/2012 
----
''Traduction :'' 
[[LeSS - Portail Excellence technique]] 

== What Is Unit Test? ==

== Qu’est-ce que les tests unitaires ? ==

'''Unit Test'''s are software programs written to exercise other software programs (called '''Code Under Test''', or '''Production Code''') with '''specific''' preconditions and verify the '''expected behaviour'''s of the CUT.

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

Unit tests are usually written in the same programming language as their code under test.

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

Each '''unit test''' should be small and test only limited piece of code functionality. Test cases are often grouped into '''Test Groups''' or '''Test Suites'''. There are many open source '''unit test framework'''s. The popular ones usually follow an '''xUnit''' pattern invented by [http://c2.com/cgi/wiki?KentBeck Kent Beck], for example, JUnit for Java and CppUTest for C/C++.

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 [http://c2.com/cgi/wiki?KentBeck Kent Beck].

Unit tests should also run very fast. Usually, we expect to '''run hundreds of unit test cases within a few seconds'''.

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'''.

== Why Unit Test ==

== Pourquoi faire des tests unitaires ? ==

The purpose of unit testing is not for finding bugs. It’s a '''specification''' for the expected behaviours of the code under test. The code under test is the implementation for those expected behaviours. So unit test and the code under test are used to check the correctness of each other, and protect each other. Later when someone changed the code under test, and it changed the behaviour that is expected by the original author, the test will fail. If you code is covered by reasonable unit test, you can maintain the code without breaking the existing feature. That’s why Michael Feathers define '''legacy code''' as ''code without unit test''.

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 et 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 du '''code hérité''' comme du ''code sans test unitaire''.

[[File:https://less.works/img/technical-excellence/xunit_test.png.pagespeed.ic.U9rHA2rtat.webp]]

[[Image:Xunit_test_fr.png|Xunit_test_fr.png]]

The purpose for unit testing is rather protect what we have implemented than to find any defects, just like the anchors set by a rock climber along his way up the rock. These anchors help him to protect what he has achieved.

Le but du test unitaire est donc plutôt de protéger ce que nous avons implémenté que de trouver des anomalies, tout comme les pitons mis 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.

=== Purpose of Unit Test ===

=== Objectif du test unitaire ===

The purpose of unit test can be summarised as:

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

* Facilitates changes
** It protects the behaviours decided by the previous programmers. So that people can change the code without breaking the existing features.
* Faciliter les changements
** Le test unitaire fait en sorte de protéger les comportements décidés par développeurs qui se sont succédés afin qu’il soit possible de changer le code sans casser les fonctionnalités existantes.
* Simplifies integration
** Unit test tests the basic units of the program, the functions and the classes. It makes sure the basic units are functioning as expected. When these units are integrated together, we can separate the integration problems (the coupling problems) from the unit internal problems (the cohesion problems).
* 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
** Well-written unit test can be used as documentation for the functionality of the code under test. Unit test contains information typically you cannot find from the code under test, for example, the design purpose of the original programming who wrote the code, and how the code is expected to be used. Unit test as documentation, unlike other traditional documentation, it doesn’t “lie”. Because if it lies, the test would fail. And that indicates either the test or the code is wrong.
* 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, quel est l’objectif de la conception du développeur à l’origine du code, 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é.
* Design tool
** Unit test is also an important design tool. Unit test requires testability from the code understand. Easy-to-test usually means easy-to-use. So unit test could be used to make sure the design has consideration from the perspective of use, rather than only from the perspective of implementation. Testable code needs better modularity and fewer dependencies. So that the unit test can easily take a small part of the code under test (a “unit”) without taking care of the overwhelming amount of dependencies. So unit test could be used to make sure the design has “high cohesion, low coupling”.
* Outil de conception
** Le test unitaire est aussi un outil de conception. Pour que le test unitaire remplisse son rôle, il est nécessaire d’appréhender la testabilité du code. 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. Par conséquence, le test unitaire peut donc 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 ».

=== Why on “Unit” Level? ===

=== Pourquoi à un niveau « unitaire » ? ===

“Yes, it’s important to use automated test to protect the existing functionalities. But why does it need to be on the unit level?”

« 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 ? »

You might wonder. Why don’t we just use thorough automated functional or system tests to protect the program?

Vous pourriez vous interroger. 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 ?

'''Total cost of ownership''' – Unit test is based on the abstraction level of the programming language. It’s just some code exercising other code. It doesn’t need to run in the same environment as the production. For compiled programming language, it doesn’t even need to use the same compiler as the production. The creating and running cost of unit test is very low. If designed properly, the cost of maintaining is also very low. You may not get the same level of confidence from one successful unit test case as you can get from a functional test. You will need many small unit test cases to get approximately the same level of confidence. But the cost of these small unit test cases is still much lower than owning a few functional test cases.

'''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 s’exécuter sur 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. Malgré tout, le coût de tous ces petits cas de test unitaire restent tout de même plus faible que celui de plusieurs cas de test fonctionnel.

If a software code base hasn’t got any unit test for the past 2 years, there will be extra cost for applying unit test to this code base. The cost comes mostly from two sources:

Si la base de code n’a eu aucun test unitaire dans les deux dernières années, il y aura un coût supplémentaire pour lui en appliquer un. Ce coût a deux sources principales :

# The cost of applying a test framework to the code project. This is relatively easier for dynamic programming languages like Python, Ruby or Javascript. Usually, it’s also trivial for Java and C# project. It can be quite tricky for C/C++ project. No matter easy or hard, this is just one-time investment.
# Le coût d’application d’un ''framework'' de test sur le code du projet. Cela 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 dans des projets Java ou C#. Cela peut être toutefois assez compliqué dans un projet C/C++. Que ce soit facile ou difficile, c’est un investissement à ne faire qu’une seule fois.
# The existing code base is not testable. The code was designed without considering the testability. Applying unit test to this kind of code base often involves improving the current design. Doing so doesn’t only increase the cost of creating test, but also has potential cost of introducing new bugs by changing the design. So applying unit test to existing code base should be combined with other works that need the change from the code under test – when you have to change that piece of code regardless.
# La base de code existante 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 base de code implique souvent de devoir améliorer la conception existante. Faire cette amélioration implique non seulement une augmentation du coût concernant la création des tests, mais a aussi potentiellement un coût d’introduire de nouvelles anomalies en changeant ladite conception. Par conséquent, l’introduction de tests unitaires à une base de code existante 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.

'''Internal Quality vs. External Quality''' – High level automated test like functional test and system test checks the external quality of the software. External quality means how well the software is functioning according to the requirement. Unit test is not as effective as the functional test in protecting the external quality. On the other hand, unit test ensures some of the internal qualities of the software. Internal quality here means the testability of the code and how well the code is protected. A testable design is in general a good design. Other levels of automated test cannot serve this purpose as well as unit test.

'''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 savoir 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 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.

'''Quality of feedback''' When you passed a functional test, you could be very confident about the functionality you just tested. But when you found it fail, usually you need to do some debugging to see what is wrong. Unit test might be able to give you more precise information about what is working and what is broken.

'''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.

Unit test is on the abstraction level of the programming language. When running unit test, everything should happen just within the CPU and memory. And each test case should be small. Therefore, it should run very fast. Typically, you should be able to run hundreds of unit tests within a few seconds. Including the compiling or other preparation time, the whole process of running unit test should take less than 1 minute.

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. Cela comprend 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.

Unit test should also be repeatable. If nothing changes, unit test runs should always return the same result.

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 retourner toujours le même résultat.

If the unit test is very fast and repeatable, programmers can run it as often as they want, e.g. every a few minutes. The unit test will continuously provide quality feedback to the programmer. So that the programmer can go with a steady progress and focus on more important things rather than spending too much energy on trivial issues.

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 quelques 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.

[[File:https://less.works/img/technical-excellence/xtest_levels.png.pagespeed.ic.-xbOy_tP-P.png]]

[[Image:Xtest_levels_fr.png|Xtest_levels_fr.png]]

A reasonable automated test structure should be like a pyramid. At the bottom are a lot of unit test cases. In the middle are much fewer integration level test cases. On the top, there are even fewer functional/system level tests.

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.

== Common Misconceptions of Unit Test ==

== Idées fausses à propos du test unitaire ==

=== Unit test is not as important as the production code ===

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

It is true that in the end, it’s production code that makes the product. But most software products have evolutionary life cycles. The code is not static. It changes over time. Code without unit test does not have the necessary protection when being changed. Unit test also contains important information that is not included in the production code.

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. Du code sans test unitaire n’est 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.

So unit test is just as important as the production code. They should be '''in the same SCM repository'''. They should follow the same coding standard as the production code.

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.

=== Unit Test is done by testing engineers ===

=== Le test unitaire est fait par des ingénieurs tests ===

The purpose of unit test is not for finding bugs. Technically, it ''checks'' rather than ''tests'' if the code under test has implemented the behaviour intended by the programmer who designed it. So the reasonable choice is just let the same programmer writes both the test and the code under test.

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.

It’s also encouraged to have two or more people pair up to do the programming together. They write the unit test and the code under test together. There are many fun ways of ''pair-programming''. You may find more information in the Test-Driven Development section.

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 sympa pour programmer en binôme. Vous trouverez davantage d’informations à ce sujet dans la section développement piloté par les tests.

=== You can write unit test without changing the code under test ===

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

This is often not true. If the code doesn’t have good testability, you might still be able to write unit test for it technically. But the unit test written for non-testable code is usually very hard to maintain and understand. Therefore, it doesn’t make much sense to have it.

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.

'''The secret of unit test is not about writing test, but writing testable code under test.''' We want testable code and easy test, which is a win-win. We don’t want non-testable code and hard-to-maintain code, which is a lose-lose.

'''Le secret du test unitaire n’est pas d’écrire du test, mais d’écrire du 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.

=== I can add unit test later ===

=== Je peux ajouter les tests unitaires plus tard ===

Well, try asking the rock climbers to set their anchors later.

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

[[File:https://less.works/img/technical-excellence/xunit_test.png.pagespeed.ic.U9rHA2rtat.webp]]

== Good Unit Test Patterns ==

== Schéma pour de bons tests unitaires ==

=== No news is good news ===

=== Pas de nouvelles, bonnes nouvelles ===

If the test passes, it should just print OK (and perhaps some dots to show the progress). No other information.

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

[[File:https://less.works/img/technical-excellence/500xNxunit_test_success.png.pagespeed.ic.W3mg1FIwIC.png]]

Rule of thumb:

En règle générale :

<blockquote>No human intervention should be needed to get ready for the test, running the test cases or checking the result.
</blockquote>
<blockquote>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.
</blockquote>
And when it fails, it should provide precise information. The goal is to limit the amount of time you spend on debugging when the test fails. 
[[File:https://less.works/img/technical-excellence/342xNxunit_test_fail.png.pagespeed.ic.eM-9actgRz.png]]

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és à débogguer le code concerné.

=== Arrange, Act, Assert ===

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

A good pattern to follow in a unit test is “'''AAA'''”: '''Arrange''', '''Act''' and '''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)'''

If you can easily find this pattern in each of your test cases, your tests should be easy to understand, and they should be fairly specific and to the point. One unit test case should test only one thing. Therefore, there should be only one set of AAA in one test case. A test case shouldn’t be very long (longer than 10 lines of code) if it follows the AAA pattern.

Si vous pouvez repérer ce schéma dans chacun de vos cas de tests, vos tests devraient 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):

<pre>def test\_should\_have\_no\_wrapping\_when\_string\_length\_is\_5\_and\_line\_width\_is\_10(self):
\# Arrange: Arrange all necessary preconditions and inputs.
wrapper = TextWrapper(width=10)

\# Act: Act on the object or method under test.
wrapped = wrapper.wrap("a" * 5)

\# Assert: Assert that the expected results have occurred.
self.assertEqual(\["a" * 5\], wrapped)</pre>
import unittest class TestGroupForTextWrapping(unittest.TestCase):

<pre> def test\_ne\_devrait\_pas\_avoir\_de\_retour\_à\_la\_ligne\_lorsque\_la\_longueur\_de\_la\_chaîne\_de\_caractères\_est\_de\_5\_et\_que\_la\_hauteur\_est\_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("a" * 5)

\# Assert : Contrôle que le résultat attendu s'est bien produit.
self.assertEqual(\["a" * 5\], wrapped)</pre>
=== Behaviour Driven Development (BDD) Style ===

=== Développement piloté par le comportement (BDD) ===

Similar to the '''AAA''' pattern, the '''BDD''' style uses three other keywords to specify each test case: '''Given''', '''When''' and '''Then'''. (You can also use '''And''' as another keyword.)

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)

<pre>Given The Text Wrapper's Width Defined As 10
And Using '-' As Word Connector
When The Wrapper Wrap Text Length is Less Than 10
Then The Text Should Not Be Wrapped

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</pre>
As you can see, “given-when-then” maps to “arrange-act-assert” pretty well. They both simply define a state transition of a Finite State Machine (FSM). You can find more on this in the [https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd Uncle Bob’s article]. Some differences:

Comme vous pouvez le constater, le triptyque « étant donné - lorsque - alors » correspond 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’[https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd Oncle Bob]. Voici quelques différences entre les deux :

* BDD is more “outside-in”, which means that it emphasises more the external behaviour
* With BDD, you need to define a '''domain specific language''' to write your test specifications. Because of this, usually you’ll need a different framework. One example for Python is [http://pythonhosted.org/behave/ behave].
* Le BDD est davantage « dehors-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 utilisez [http://pythonhosted.org/behave/ behave].

=== The Golden Rule Of a Unit Test ===

=== La règle d’or du test unitaire ===

In general, a good rule for unit test case is:

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

<blockquote>'''Each unit test case should be very limited in scope.'''
</blockquote>
<blockquote>'''Chaque cas de test unitaire devrait comporter un périmètre très restreint.'''
</blockquote>
So that:

De telle manière que :

* When the test fails, no debugging is needed to locate the problem.
* Tests are stable because dependencies are simple.
* Less duplication, easier to maintain.
* 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

There is no secret to write good unit test. In order to write good unit test, you need to create easy-to-test design.

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.

Fichier:Xtest levels fr.png

2022-06-29T06:31:24Z

Nicolas Mereaux :

Fichier:Xunit test fr.png

2022-06-29T06:29:02Z

Nicolas Mereaux :

Catégorie:Portail LeSS

2022-06-29T06:22:22Z

Nicolas Mereaux : Ajout de la page tests unitaires

<addthis />
[[Catégorie: Portails Thématiques]]
[[Category: Agilité à grande échelle]]
[[Category: Portail Framework]]
[[Fichier:LeSS-logo 72.png|link=]] À la découverte de LeSS, ce framework de mise à l'échelle de l'élégance de Scrum. 
[[Image:LeSS-overview-diagram_fr.png|LeSS-overview-diagram_fr.png|link=]] [http://less.works/less/framework/introduction.html introduction] '''''"Depuis 2005, nous avons travaillé avec des clients pour mettre en oeuvre le framework LeSS (Large-Scale Scrum) de mise à l'échelle du développement Scrum, agile et lean pour les groupes produit de grande taille. Nous partageons cette connaissance à travers LeSS pour que, vous aussi, vous puissiez réussir lorsque vous passez à l'échelle."''''' - Craig Larman & Bas Vodde '''Articles thématiques''' 
----

* '''[[LeSS%20-%20Portail%20Framework|Portail Framework LeSS (fr) - 95%]]'''
** [http://less.works/less/framework/introduction.html Introduction à LeSS]
** [[Pourquoi%20LeSS%20%3F|Pourquoi LeSS (fr)]]
** [[LeSS%20-%20Le%20Produit|Le Produit (fr)]]
** [[LeSS%20-%20Le%20Product%20Owner|Le Product Owner (fr)]]
** [[LeSS%20-%20Le%20backlog%20du%20produit|Le Backlog du Produit (fr)]]
** [[LeSS%20-%20Les%20%C3%89quipes|Les Équipes (fr)]]
** [[LeSS%20-%20Le%20Sprint|Le Sprint (fr)]]
** [[LeSS%20-%20La%20Planification%20du%20Sprint%20%281%C3%A8re%20partie%29|La Planification du Sprint (1ère partie) (fr)]]
** [[LeSS%20-%20La%20Planification%20du%20Sprint%20%282%C3%A8me%20partie%29|La Planification du Sprint (2ème partie) (fr)]]
** [[LeSS%20-%20Le%20Backlog%20du%20Sprint|Le Backlog du Sprint (fr)]]
** [[LeSS%20-%20La%20M%C3%AAl%C3%A9e%20Quotidienne|La Mêlée Quotidienne (fr)]]
** [[LeSS%20-%20Coordination%20%26%20Int%C3%A9gration|Coordination & Intégration (fr)]]
** [[LeSS%20-%20L%27Incr%C3%A9ment%20Produit%20Potentiellement%20D%C3%A9ployable|L'Incrément Produit Potentiellement Déployable (fr)]]
** [[LeSS%20-%20La%20D%C3%A9finition%20du%20Fini|La Définition du Fini (fr)]]
** [[LeSS%20-%20La%20Revue%20de%20Sprint|La Revue de Sprint (fr)]]
** [[LeSS%20-%20La%20R%C3%A9trospective|La Rétrospective (fr)]]
** [[LeSS%20-%20La%20R%C3%A9trospective%20Globale|La Rétrospective Globale (fr)]]
** [[LeSS%20-%20L%27Affinage%20du%20Backlog%20Produit|L'Affinage du Backlog Produit (fr)]]
** [[LeSS%20-%20L%27Affinage%20Initial%20du%20Backlog%20Produit|L'Affinage Initial du Backlog Produit (fr)]]
** [[LeSS%20-%20Le%20ScrumMaster|Le ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20Principes|Portail Principes (fr) - 72%]]'''
** [[LeSS%20-%20Pr%C3%A9sentation%20des%20principes|Présentation des principes (fr)]]
** [[LeSS%20-%20Scrum%20%C3%A0%20grande%20%C3%A9chelle%20reste%20du%20Scrum|Scrum à grande échelle reste du Scrum (fr)]]
** [[Less_-_Plus_avec_LeSS|Plus avec LeSS (fr)]]
** [http://less.works/less/principles/lean-thinking.html Pensée Lean]
** [[LeSS - Approche systémique|Approche systémique (fr)]]
** [[LeSS%20-%20Contr%C3%B4le%20du%20processus%20empirique|Contrôle du processus empirique (fr)]]
** [[LeSS%20-%20Transparence|Transparence (fr)]]
** [http://less.works/less/principles/continuous-improvement-towards-perfection.html Amélioration continue vers la perfection]
** [[Less_-_Centré_client|Centré client (fr)]]
** [[Less_-_Focus_sur_le_produit_global|Focus sur le produit global (fr)]]
** [https://less.works/less/principles/queueing_theory.html Théorie des files d'attente]
 

* '''[[LeSS%20-%20Portail%20Structure|Portail Structure (fr)]] - 100%'''
** [[LeSS%20-%20Equipes|Equipes (fr)]]
** [[LeSS%20-%20Organisation%20en%20fonction%20de%20la%20valeur%20client|Organisation en fonction de la valeur client (fr)]]
** [[LeSS%20-%20Equipes%20Feature|Equipes Feature (fr)]]
** [[LeSS%20-%20Structure%20organisationnelle|Structure organisationnelle (fr)]]
** [[LeSS%20-%20Communaut%C3%A9s|Communautés (fr)]]
** [[LeSS%20-%20ScrumMaster|ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20Excellence%20technique|Portail Excellence Technique (fr)]] - 40%'''
** [[LeSS%20-%20Sp%C3%A9cifications%20par%20l%27exemple|Spécifications par l'exemple (fr)]]
** [[Less - Intégration continue|Intégration Continue (fr)]]
** [https://less.works/less/technical-excellence/continuous-delivery.html Livraison Continue]
** [[LeSS - Tests d'Acceptation|Tests d'Acceptation (fr)]]
** [http://less.works/less/technical-excellence/architecture-design.html Architecture & Conception]
** [http://less.works/less/technical-excellence/clean-code.html Ecrire du Code Propre]
** [[LeSS - Tests unitaires|Tests unitaires (fr)]]
** [[Less - Développement piloté par les tests|Développement piloté par les tests (fr)]]
** [http://less.works/less/technical-excellence/thinking-about-testing.html Réflexions à propos des tests]
** [http://less.works/less/technical-excellence/test-automation.html Automatisation des tests]
 

* '''[[LeSS%20-%20Portail%20Management|Portail Management (fr)]] - 100%'''
** [[LeSS%20-%20R%C3%B4le%20du%20Manager|Rôle du Manager (fr)]]
** [[LeSS%20-%20Enseigner%20la%20r%C3%A9solution%20de%20probl%C3%A8me|Enseigner la résolution de problème (fr)]]
** [[LeSS%20-%20Aller%20Voir|Aller Voir (fr)]]
** [[LeSS%20-%20Auto-gestion|Auto-gestion (fr)]]
** [[LeSS%20-%20Service%20d%27am%C3%A9lioration|Service d'amélioration (fr)]]
** [[LeSS%20-%20Le%20Manager%20en%20tant%20que%20ScrumMaster|Le Manager en tant que ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20LeSS%20Huge|Portail Less Huge (fr)]] - 100%'''
** [[LeSS%20-%20Domaines%20d%27exigences|Domaines d'Exigences (fr)]]
** [[LeSS%20-%20Backlog%20Produit%20de%20Domaine|Backlog Produit de Domaine (fr)]]
** [[LeSS%20-%20Product%20Owner%20de%20Domaine|Product Owner de Domaine (fr)]]
** [[LeSS%20-%20Structure%20organisationnelle%20pour%20LeSS%20Huge|Structure organisationnelle pour LeSS Huge (fr)]]
 

* '''[[LeSS%20-%20Portail%20Adoption|Portail Adoption (fr)]] - 100%'''
** [[LeSS%20-%20Les%20trois%20principes|Trois principes (fr)]]
** [[LeSS%20-%20D%C3%A9marrer|Démarrer (fr)]]
** [[LeSS%20-%20Coaching|Coaching (fr)]]
** [[LeSS%20-%20Am%C3%A9lioration%20continue|Amélioration Continue (fr)]]
** [[LeSS%20-%20Sch%C3%A9ma%20d%27adoption%20des%20%C3%A9quipes%20feature|Schéma d'adoption des équipes feature (fr)]]
** [[LeSS%20-%20Rester%20sain%20d%27esprit|Rester sain d'esprit (fr)]]
 

* '''LeSS Test'''
** [http://less.works/less/test/pre-course.html LeSS Test]
** [http://less.works/less/test/scrum.html Scrum Test]

LeSS - Approche systémique

2020-11-01T19:23:22Z

Nicolas Mereaux :

[[Category: Nicolas Mereaux]]
[[Category: Portail LeSS]]
[[Category: Agilité à grande échelle]]
Auteur : The LeSS Company B.V. 
Source : [https://less.works/less/principles/systems-thinking.html Systems Thinking] 
----
Traducteur : Nicolas Mereaux [[Fichier:Nime.png|50px|link=https://twitter.com/__nime__]] 
Relecteurs : Christophe Gesché, Fabrice Aimetti 
Date : 01/11/2020 
----
Traduction : 
 
[[LeSS - Portail Principes]] 
 

== Approche systémique ==

''J’ai pris un cours de lecture rapide puis j’ai lu « Guerre et Paix » en vingt minutes. Cela parle de la Russie. — Woody Allen''

"Quoi que nous fassions, le nombre d’anomalie dans notre ''backlog'' reste identique." nous a dit un jour un manager en évoquant un produit de près de 15 millions de lignes de code écrites en C et C++ et sur lequel plusieurs centaines de développeurs étaient en train de travailler. Que pouvait-il bien se passer ? L’approche systémique peut s’avérer utile dans ce cas. En petits groupes, les forces en présence peuvent rapidement être identifiées et comprises de manière informelle, mais dans le cadre du développement d’un gros produit ou de n’importe quel gros système, c’est difficile. Gerry Weinberg met en avant deux facteurs décisifs dans ce genre de situation :

'''Loi de Weinberg-Brooks''' : De plus en plus de projets informatiques sont partis de travers après que le management ait pris des décisions basées sur des '''modèles systémiques incorrects''' plus que pour toutes autres combinaisons de causes.

'''Erreur de causalité''' : Chaque effet a une cause... et nous pouvons dire desquelles il s’agit. [http://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226 [Weinberg92]]

Ces deux facteurs reflètent bien l’impact de nos '''modèles mentaux''' sur le système, un sujet que nous reverrons plus tard dans cette partie.

Les problèmes résultant de nos modèles mentaux et de nos postulats sont un point à traiter. Un autre point est l’adoption à grande échelle de Scrum, de l’approche lean et des principes agiles en dehors du domaine du développement. Ce point est aussi présent dans la gestion de produit, les budgets, les tests, la commercialisation, la gouvernance et la politique RH. En conséquence, dans les adoptions agiles à grande échelle, il est utile de se réunir avec des collègues et de ''réfléchir en profondeur'' sur les modèles mentaux, les relations causales, les boucles de feedback et les mécanismes (ou les illusions) de contrôle dans un gros système qui va être sérieusement ''perturbé''. L’approche systémique est l’un de ces outils de réflexion.

En 1958 la ''Harvard Business Review'' a publié un article de Jay Forrestor, professeur à la MIT Sloan School, qui a fait date [https://kupdf.com/download/industrial-dynamics-a-major-breakthrough-for-decision-makers_5902479bdc0d603940959ed5_pdf “Industrial Dynamics: A Major Breakthrough for Decision Makers”]. Cet article a lancé le mouvement de l’approche systémique dans le domaine des formations en gestion d’entreprise et la MIT Sloan School of Management devint célèbre pour ses formations en '''dynamique des systèmes'''. Le terme de dynamique des systèmes est parfois utilisé comme synonyme de l''''approche systémique''', même si ce dernier est un terme beaucoup plus général.

Le MIT a également attiré d’autres chercheurs intéressés par la dynamique systémique tel que Peter Senge<ref>''La cinquième discipline'' écrit par Senge sur l’approche systémique et les organisations apprenantes a été nommé "l’un des livres les plus novateurs sur le management de ces 75 dernières années" par la ''Harvard Business Review.'' [Senge94].</ref>

En corrélation avec la loi de ''Weinberg-Brook'', Jay Wright Forrester a montré que les décideurs à qui il avait été donné des modèles dynamiques de systèmes opérationnels et à qui il avait été demandé d’améliorer la performance opérationnelle, ''n’avaient fait généralement qu’empirer les choses'' [https://www.amazon.fr/guide-lorganisation-apprenante-d%C3%A9velopper-lintelligence/dp/2212568711/ [SKRRS94]]. Il en est ressorti d’ailleurs que la plupart des personnes évaluaient mal la manière dont il faut améliorer les systèmes, et appliquaient généralement leur "bon sens", en mettant en place des solutions de contournement qui n’apportent aucune amélioration systémique à long terme.

Pourquoi le comportement d’un groupe de développement de grande taille (autrement dit un système) n’est-il pas compris ou guidé de manière compétente ? La réponse réside, en partie, dans le comportement des systèmes stochastiques avec les files et les variabilités comme nous avons pu l’évoquer avec le principe LeSS de la [https://less.works/less/principles/queueing_theory.html théorie des files d’attentes (en)]. Et c’est la même réponse qui est au coeur de la ''théorie du contrôle'' : la plupart des systèmes d’intérêt - tel qu’un groupe de développement de produit - ont des boucles de feedback positives et négatives ainsi qu’un comportement non linéaire. Le comportement de ces systèmes défient nos intuitions les plus profondes. Et puis il y a la question secondaire des ''gens''.

En résumé, les raisons expliquants l’incompétence à maîtriser ou à guider un gros système sont (liste non exhaustive) :

* le manque de connaissance des dynamiques des systèmes, des boucles de feedback, du comportement non linéaire des systèmes, et des conséquences inattendues dans les systèmes sur le lieu de travail.
* la mauvaise compréhension des causes racines des problèmes (et de comment les trouver)
** ''les causes'', pas ''la cause'' ; en approche systémique, nous savons que les causes des problèmes sont multiples, indirectes et dynamiques
* l’incapacité à savoir si ou pourquoi une solution de contournement ou une décision locale dégrade la performance globale opérationnelle.

Pour résumé, nous n'utilisons pas l’approche systémique<ref>Une autre raison : croire que plus de contrôle est possible qu’il ne l’est en réalité. La science de la complexité suggère qu’il existe des limites en termes de prédiction et de contrôle des systèmes sociaux semi-chaotiques [Stacey07]. C’est une énorme boîte de Pandore qui restera close dans ce livre.</ref>.

Ces raisons sont la conséquence de l’intersection du management et de l’adoption à grande échelle des principes lean et agile. L’équipe de direction fait partie du système qui est perturbé ; si elle n’applique pas l’approche systémique, elle pourrait ''vraiment'' le perturber - et pas de la bonne manière !

Les points-clés à retenir de l’approche systémique peuvent être résumé dans les [https://en.wikipedia.org/wiki/The_Fifth_Discipline#The_11_Laws_of_the_Fifth_Discipline 11 'lois'] décrites dans la [https://www.amazon.fr/cinqui%C3%A8me-discipline-organisations-apprenantes-dexemplaires-ebook/dp/B017WSYAHG Cinquième Discipline] :
* Les problèmes d’aujourd’hui viennent des 'solutions' d’hier.
* Plus vous poussez, plus le système pousse en retour.
* Le comportement va d’abord empirer avant de s’améliorer.
* La manière la plus facile de s’en sortir conduit souvent à faire quelques pas en arrière.
* Le médicament peut être pire que la maladie.
* Aller plus vite c’est aller plus lentement.
* Les causes et les effets ne sont pas étroitement liés dans l’espace et le temps.
* De petits changements peuvent produire de gros résultats... mais les zones où l’effet de levier est le plus important sont souvent les moins évidentes.
* Vous pouvez avoir votre gâteau et le manger aussi... mais pas en une seule bouchée.
* Couper un éléphant en deux ne produit pas deux petits éléphants.
* Il n’y a aucun reproche à faire.

La devise de Toyota en interne est [http://www.toyota-global.com/company/toyota_traditions/quality/may_jun_2005.html "Bien '''réfléchir''' permet d'avoir de bons produits"]. L’approche systémique est un ensemble d’outils de réflexion pour aider à :
* '''voir les dynamiques des systèmes''' : une organisation de développement est un système de personnes et de règles avec de subtiles boucles de feedback et des conséquences inattendues
** nous pouvons apprendre à voir et ainsi à améliorer le système avec des '''diagrammes de boucles causales''' réalisés lors d’un atelier
* '''percevoir les modèles mentaux''' : parmi les raisons derrière des décisions sous-optimales se trouvent des hypothèses erronées et des raisonnements incorrects
** les diagrammes de boucles causales et les cinq pourquoi permettent de révéler cela
* '''voir les optimisations locales''' : une autre source de décisions sous-optimales est '''l’optimisation locale''', autrement dit prendre la "meilleure" décision du point de vue d’une personne ou d’un département, au détriment d’une '''optimisation globale''' qui est l’objectif au niveau système ''lean'' et qui consiste à pouvoir ''livrer la plus grande valeur possible de très grande qualité avec un moral d’acier.''

Cette présentation de l’approche systémique est faite autour des domaines suivants : apprendre à voir (1) ''les dynamiques des systèmes'', (2) ''les modèles mentaux'', (3) ''les causes racines'', et (4) ''l’optimisation locale''.

== Voir les dynamiques des systèmes : introduction ==

=== Complexité statique versus complexité dynamique ===

La plupart d’entre nous, notamment les ingénieurs et les financiers, ont été formés pour maîtriser la '''complexité de détails statiques''', en apprenant à analyser et à gérer l’information (exigences, analyses financières, ...), à décomposer des structures complexes en structures simples, et ainsi de suite. C’est-à-dire, la complexité d’une information qui est par nature structurellement statique.

Pourquoi les gros systèmes informatiques ont-ils tendance à se dégrader malgré de plus en plus de temps passé sur les anomalies ? Qu’est-ce qui pourrait bien se passer si les États-Unis d’Amérique envahissait l’Irak ? Voir les dynamiques derrière ces questions implique d’analyser la '''complexité des dynamiques''' en jeu.

Au contraire d'une formation sur les détails statiques que la plupart d’entre nous avons suivie, peu d’entre nous ont reçu de formation sur l’étude des systèmes dynamiques et complexes<ref>Macro économie, psychologie, sociologie et biologie sont des exceptions parmi tant d’autres.</ref> et notamment dans le milieu professionnel. Peut-être parce que nous avons la croyance qu’il est suffisant de s’appuyer sur le bon sens en milieu professionnel. Jay Wright Forrester a démontré que le "bon sens" n’est pas suffisant dans des systèmes complexes et qu’il est possible de former des personnes pour leur permettre de mieux appréhender les '''modèles de dynamique des systèmes''' en milieu professionnel en utilisant notamment des ''diagrammes de flux'' [http://www.amazon.fr/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ [Forrester61]].

Les diagrammes de flux peuvent s’appliquer aussi bien aux flux matériels, financiers, d’informations, de stocks (n’importe quel type de stock quantitatif comme de l’argent ou des anomalies), aux conséquences des décisions et des politiques et des relations de causes à effet. Lorsque nous pensons aux diagrammes de flux, nous pensons souvent au seul ''diagramme de boucle causale'' dédié aux relations de cause à effets et aux boucles de rétroaction dans un système [http://www.amazon.fr/Business-Dynamics-Systems-Thinking-Modeling/dp/0071179895 [Sterman00]]. Il existe une grande variété d’autres diagrammes qui peuvent faire figurer les stocks (quels qu’ils soient), les liens de causalité, et les retards. Dans son ouvrage, [http://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226/ [Weinberg92]] Gerald Weinberg appelle cela un ''diagramme d’effet''.

=== La première loi de la réalisation d’un diagramme : nous modélisons pour avoir une conversation ===

Un outil très utile pour apprendre les dynamiques des systèmes est le diagramme de boucles causales : nous vous recommandons de l’utiliser sur un tableau blanc notamment lors des Rétrospectives Globales LeSS avec les collègues. Mais avant d’aller plus loin, voici la ''première loi de réalisation d’un diagramme''.

'''La première valeur d’un diagramme c’est la discussion qui se déroule lors de la réalisation du diagramme : nous modélisons pour avoir une conversation.'''

Lorsqu’un groupe se rassemble pour dessiner un diagramme de boucles causales sur un tableau blanc ("C’est l’acte de discuter et de réfléchir qui est le plus important lorsque nous dessinons", Valtech India.), la première valeur d’un diagramme c’est la conversation et la compréhension commune à laquelle les personnes arrivent lors de la création du modèle. Ce qu’il en résulte, à savoir un diagramme facile à comprendre, est important pour rendre les idées et les modèles mentaux concrets et non ambigües (sur le tableau blanc) parce que les mots seuls peuvent être imprécis et mal compris. Toutefois, le diagramme est secondaire par rapport à ce avec quoi les gens repartent : ils ont appris quelque chose et ont revu leur compréhension du monde à travers une discussion.

[[Fichier:Xgroup-cld-modeling.jpg|848px|border|link=]]

''Un atelier d’approche systémique : réalisation d’un diagramme de boucles causales à plusieurs - modéliser pour avoir une conversation.''

''Trucs et astuces de pro pour modéliser'' : nous commençons par écrire sur des petits post-its les noms des ''variables'', par exemple "vélocité des ''features''" ou "nombre d’anomalies". Nous les plaçons ensuite sur le tableau blanc. Puis nous dessinons les liens de causalités entre les post-its. Il y aura (ou il devrait y avoir) beaucoup de réécriture, d’effaçage, de redessin lors de la session de modélisation. Le résultat le plus important d’une telle session est la ''compréhension'' : il se peut qu’à l’issue de cet atelier, certains participants voudront prendre une photo du dessin du tableau blanc.

== Voir les dynamiques des systèmes : les diagrammes de boucles causales ==

Les diagrammes de boucles causales sont souvent utilisés en introduction à LeSS pour aider à voir les dynamiques de ce qu’il se passe lors du développement à grande échelle. Il est donc utile de comprendre ce type de diagrammes pour cette seule et unique raison. Et cela s’avèrera encore plus utile pour vous, si vous le faites avec vos collègues devant un tableau blanc. Vous modélisez pour avoir une conversation. Quand ? Plus probablement lors d’une rétrospective globale LeSS.

L’aspect pratique de cet exercice est bien plus important que ce qu’il peut paraître au premier abord. Notre conseil d’"être un pratiquant systémique" peut vous sembler vague et sans grand impact. Mais si vous et quatre de vos collègues prenez l’habitude de vous réunir devant un grand tableau blanc, en dessinant des diagrammes de boucles causales ensemble, alors vous arriverez à faire la connexion entre "''être'' un pratiquant systémique" avec "''faire'' de l’approche systémique".

Les exemples suivants peuvent paraître aseptisés car présentés dans un livre. Mais imaginez-vous à côté d’un tableau blanc avec d’autres personnes dessinant ensemble des diagrammes au cours d’une conversation animée. C’est de cette manière-là que nous suggérons de 'faire' de l’approche systémique.

=== Notation et exemples ===

Les diagrammes de boucles causales contiennent beaucoup d’éléments ; les éléments suivants sont les plus communément utilisés et sont vus en détail tout au long du scénario qui va suivre :
* variables
* liens de causalité
* effets opposés
* contraintes
* objectifs
* réactions ; solutions de contournement
* effets d’interaction
* effets extrêmes
* retards
* boucles de feedback positives

''Le scénario qui suit est un scénario simplifié pour une organisation spécifique. Il ne s’agit pas d’une généralisation.''

====Les variables====
Les diagrammes de boucles causales comportent des ''variables'' (ou des stocks) telle que la ''vélocité (taux de livraison) des features logicielles'' et le ''nombre d’anomalies''. Les variables ont une quantité mesurable.

[[File:Xsystems-thinking-4-fr.png|border|848px|link=]]

====Les liens de causalité====
Un élément peut avoir un effet sur un autre, par exemple si la vélocité des ''features'' augmente alors le nombre d’anomalies augmente ; autrement dit, plus de code, plus d’anomalies.

[[File:Xsystems-thinking-5-fr.png|border|848px|link=]]

Il est temps désormais de se jeter à corps perdu dans la ''loi de Weinberg-Brooks'' et dans la ''causalité fallacieuse''. Il est facile de dessiner un diagramme, ça l’est moins de modéliser en faisant preuve de clairvoyance comme par exemple, la relation entre le ''nombre de développeurs'' et la ''vélocité des features''.

Toute relation de cause à effets est par nature obscure, même si les gens ont l’habitude de sauter sur la première conclusion venue comme par exemple plus de développeurs égale plus de vélocité. Ajouter des personnes tard au cours du développement peut ''réduire'' la vélocité (il s’agit d’une composante de la "loi de Brooks" [Brooks95]). Ou, ''davantage'' de mauvais développeurs pourrait vraiment vous ralentir. Il pourrait être objecté qu’''enlever'' des développeurs exécrables peut permettre ''d’améliorer'' la vélocité.

[[File:Xsystems-thinking-6-fr.png|link=|848px|border]]

====Effets opposés====
L’effet d’un lien de causalité peut aller dans la même direction ou dans la direction opposée. Si A augmente alors B augmente, ou vice versa. L’effet opposé se souligne à l’aide d’un ‘O’ sur la ligne. Supposons que les anomalies ralentissent grandement le système, réduisant la vélocité des nouvelles features parce que les gens passent davantage de temps à corriger ou à trouver des solutions de contournement aux anomalies.

[[File:Xsystems-thinking-7-fr.png|border|848px|link=]]

====Contraintes====
À moins que vous ne trouviez des personnes prêtent à travailler gratuitement, il y a une contrainte sur le nombre de développeurs basé sur le budget disponible.

Les contraintes ne sont ''pas'' des liens de causalité. Lorsque le montant du budget disponible augmente, ce n’est pas le cas du nombre de développeurs.

[[File:Xsystems-thinking-8-fr.png|border|848px|link=]]

====Buts et réactions====
Les personnes, les départements et les systèmes ont des buts, comme par exemple avoir une ''vélocité des features plus élevée''. Les buts occasionnent souvent de la pression pour que les gens réagissent (ou agissent) dans l’intention de leur faire atteindre ce but. Mais étant donné qu’il y a la ''causalité fallacieuse'' et la ''loi de Weinberg-Brooks'' à laquelle il faut faire face, les gens devraient être prudents quant aux actions pertinentes à entreprendre. Voici un exemple de diagramme modélisant cela :

[[File:Xsystems-thinking-9-fr.png|border|848px|link=]]

Non seulement un but à atteindre avec une ''récompense'' au bout engendre une pression à agir, mais cela créé aussi une pression à ''faire semblant'' d’agir et à atteindre le but : les récompenses provoquent un '''dysfonctionnement des indicateurs'''. Le dysfonctionnement des indicateurs peut être proportionnel à la valeur perçue de la récompense parce que les personnes sont motivées pour avoir la récompense, non pour améliorer le système [http://www.amazon.fr/Measuring-Managing-Performance-Organizations-Dorset-ebook/dp/B00DY3KQX6/ [Austin96]]. Remarquez bien comment et de quelle manière les récompenses peuvent dégrader la performance du système. De manière visuelle, les dynamiques d’un tel système pourrait être...

[[File:Xsystems-thinking-10-fr.png|border|848px|link=]]

Il est assez intéressant de voir que toutes ces dynamiques ont été ajoutées par l’introduction d’une récompense et qu’il n’y pas de connexion entre le haut et le bas de cette modélisation.

Il n’y a aucune garantie que la vélocité des features s’améliore ou même que l’on y travaille.

Enlever le système de récompense est une solution à la cause racine de ce dysfonctionnement. Une autre contremesure de surface est le principe et le comportement managériale ''Aller voir'' (aller voir physiquement sur le lieu où le travail s’effectue) de l’approche lean :

[[File:Xsystems-thinking-11-fr.png|border|848px|link=]]

====Solutions de contournement====
Une solution payante à long terme pour atteindre une vélocité plus grande, mais qui n’est pas sans difficulté, consiste à : recruter des développeurs très qualifiés, faire davantage d’accompagnements et de formations, et à se séparer des moins bons éléments. L’alternative est ce que l’on appelle une ''solution de contournement'', c’est ce que l’on met en place dans l’espoir d’atteindre l’objectif en moins de temps et avec moins d’effort. Parfois, une solution de contournement se révèle payante aussi bien sur le court terme que sur le long terme, renforçant par la-même le système. D’autres fois cela ne fonctionne pas... d’où l’expression "aller plus vite c’est aller plus lentement". Par exemple, les gens peuvent ''croire'' qu’augmenter le nombre de développeurs permet d’augmenter la vélocité des features. Et ils peuvent par conséquent être amenés à espérer qu’en recrutant davantage de développeurs cela permettra de résoudre plus vite et plus facilement le problème de vélocité. La mention 'SC' sur le diagramme ci-dessous indique une solution de contournement.

[[File:Xsystems-thinking-12-fr.png|border|848px|link=]]

====Effets d’interaction====
La capacité à embaucher est contraint à la capacité budgétaire. Une solution de longue haleine non sans difficulté est d’obtenir davantage de budget. Une solution de contournement possible est de recruter un ''grand'' nombre de développeurs bon marché. Dans ce cas, le niveau du budget a un ''effet d’interaction'' avec les autres boucles causales. Un budget peu élevé aura tendance à renforcer le taux de développeurs bon marché si la pression pour recruter augmente.

Nous pourrions dessiner simplement un lien de causalité (opposé) de ''rentrée budgétaire'' à ''taux de recrutement de développeurs bon marché'', mais cela voudrait simplement dire qu’avoir un budget moindre aurait pour conséquence de recruter davantage de développeurs bon marché. Mais ce n’est pas tout à fait ce que nous voulons dire ; ce que voulons montrer en fait, c’est l’effet d’interaction, c’est-à-dire qu’un effet A influence un ''effet'' B. Cela se fait en montrant un lien de causalité heurtant un autre lien de causalité, par exemple en traçant une ligne de ''rentrée budgétaire'' vers la ligne représentant la solution de contournement qui va vers ''taux de recrutement de développeurs bon marché''.

[[File:Xsystems-thinking-13-fr.png|border|848px|link=]]

====Effets extrêmes====
Il nous est arrivé de travailler avec d’excellents développeurs très bon marché et avec d’autres développeurs hors de prix et très nuls, mais en moyenne, vous obtenez à hauteur de ce que vous payez ; lorsque vous recrutez au moins disant, le niveau moyen en terme de compétences sera plus faible. Dans le diagramme ci-dessous, nous avons voulu montrer que l’impact du recrutement de personnes bon marché en rapport avec le ''nombre de développeurs peu qualifiés'' à un impact sensiblement plus grand que la moyenne.

Pour montrer un ''effet extrême'' sur un modèle, faites un trait épais comme vous pouvez voir ci-dessous :

[[File:Xsystems-thinking-14-fr.png|border|848px|link=]]

====Retards====
Un problème courant au niveau du recrutement dans un projet de développement logiciel concerne ''l’erreur au niveau de la variance d’un développeur moyen'' ; autrement dit la croyance fausse que la variance d’un développeur à un autre (en terme de productivité, de qualité de code, etc.) est relativement faible. Toutefois, les études de la variance au sujet des développeurs montrent un rapport de 1 à 4 entre le 1er quartile et le dernier [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.4788 [Prechelt00]]. C’est plutôt quelque chose de significatif. De même des études - en long et en large - du modèle COCOMO montrent que la capacité du développement personnel est le facteur de loin le plus important quant à la productivité [http://www.amazon.com/Software-Cost-Estimation-Cocomo-II/dp/0130266922/ref=sr_1_1?ie=UTF8&qid=1413597244&sr=8-1&keywords=Software+Cost+Estimation+with+Cocomo+II [Boehm00]]. Et, en moyenne, il s’avère que les développeurs peu qualifiés font du code de mauvaise qualité (mauvaise conception) et de plus d’anomalies, ceci rajoute un autre frein au système.

Mais l’impact de ces effets ne sont pas visibles immédiatement. Par exemple, cela peut prendre un certain temps après un recrutement massif de développeurs peu qualifiés avant que les impacts négatifs ne se fassent sentir au niveau de la qualité du code ou de la conception. De manière similaire, la ''baisse'' moyenne de la vélocité des features (en raison de l’impact important de la variance des développeurs évoqué plus haut) ne se verra pas immédiatement.

Pour montrer ces ''effets à retardement'' dans le modèle, faites une double-ligne en travers de la ligne d’effet.

[[File:Xsystems-thinking-15-fr.png|border|848px|link=]]

Le retard a une influence intéressante sur le pouvoir ''pédagogique'' ou correctif sur un système. Si un impact ou une conséquence inattendue est retardé suffisamment longtemps, personne n’en voit ni l’effet (qu’il soit bénéfique ou néfaste) ni sur la façon dont A influence B ou plus subtilement comment ''A a influencé B qui a influencé A''.

Par conséquent, personne n’apprend de ses erreurs ni n’est en capacité de les corriger, que ce soit en terme de stratégie, d’actions d’encadrement, d’outils ou de quoi que ce soit. De la même manière, l’amélioration graduelle à travers l’application d’une démarche lean ''kaizen'', peut prendre un certain temps ; de la patience et de la perspicacité sont nécessaires pour voir si et comment les choses s’améliorent.

====Boucles de feedback positives====
Les boucles de feedback négatives ou positives<ref>''Les boucles de feedback'' sont parfois utilisées dans ce livre dans le sens littéral du terme, plutôt dans le sens des dynamiques des systèmes.</ref> et les retards sont le point de départ pour une approche plus subtile d’un système, et de sa compréhension. Par exemple, de quelle manière une personne peut-elle devenir un meilleur développeur ? En partie, en bénéficiant du mentorat de très bons développeurs et en jetant un oeil sur du très bon code. Mais il est impossible de trouver du bon code dans un endroit remplit de développeurs médiocres, il est impossible également d’y attirer ou de retenir le petit groupe de très bon développeurs qui pourraient prendre le rôle de mentors. Ils préfèrent largement aller travailler ailleurs.

Ce groupe de développeurs médiocres rentrent dans un cercle vicieux en raison d’un ensemble de ''boucles de feedback positives''. Fort heureusement, ce cercle vicieux est assujetti aux contraintes du budget.

Malheureusement de plus en plus des très bons développeurs, ceux en capacité d’élaborer du très bon code et de faire du mentorat auprès des autres développeurs, partent. Par conséquent, il y a de moins en moins de code de qualité à regarder et à partir duquel il est possible d’en tirer des enseignements. Le pourcentage de développeurs médiocres augmente de plus en plus et la vélocité au niveau des features continue à chuter. Le code devient de plus en plus brouillon, difficile, avec pleins de bouts de code dupliqués à gauche et à droite, le tout de telle manière que la capacité d’implémenter des features décline. Étant donné que la vélocité des features continue de chuter, il y a davantage de pression pour recruter des développeurs très bon marché. Tout cela conduit à de multiples boucles de renforcement positives dans le système comme l’illustre l’exemple ci-dessous :

[[File:Xsystems-thinking-16-fr.png|border|848px|link=]]

''Astuce'' : Vous pouvez trouver des boucles de feedback positives en cherchant des cycles ayant un ''nombre pair'' de relations. Vous en trouverez plusieurs exemples ci-dessus.

==== Conclusion ====

Le scénario donné à titre d’exemple est uniquement cela, un exemple. Une diagramme de boucle causale permet de visualiser la richesse de la dynamique dans le système dans un milieu professionnel. La meilleure manière de modéliser un tel système est de le faire en groupe face à un tableau blanc.

== Voir les modèles mentaux ==
Les précédents diagrammes de boucles causales reflètent les modèles mentaux de causalité des individus... qui peuvent s’avérer faux. Il est intéressant de remarquer que les modèles de causalité des individus sont influencés par la ponctualité (ou les retards) et la qualité des feedbacks dans le système.

Les "modèles mentaux" nous permettent d’améliorer nos compétences de méta-cognition pour voir et questionner nos propres postulats et l’enchaînement de nos raisonnements. Brûlons-nous des étapes de manière erronée ? Cette question implique aussi lorsque nous sommes en train de travailler avec des collègues de discuter avec eux (en s’enquérant plutôt qu’en reprochant) de leurs modèles mentaux.

''Voir'' les modèles mentaux n’est que la première étape ; les ''changer'' constitue une seconde partie bien plus difficile. Cet art est bien au-delà du sujet de cette introduction, même si une adoption réussie de LeSS implique des changements en terme d’état d’esprit et de prise de conscience au sein de très nombreuses équipes.

Une astuce pour mieux ''voir'' les modèles mentaux (croyances, échelle d’inférence, ...) en jeu au niveau des dynamiques des systèmes est de poser les questions suivantes lors d’un atelier de modélisation puis de tracer les éléments de réponse au tableau blanc. "Parlons donc des hypothèses derrière ce modèle. Que ''croyons''-nous ou tenons pour acquis en terme de faits et d’effets qui nous ont conduits ici ?"

Les éléments de réponse sont dessinés sur le tableau blanc. En voici un exemple :

[[File:Xsystems-thinking-17-fr.png|botrder|848px|link=]]
''Visualiser les postulats présents dans nos têtes... nos modèles mentaux.''

=== Exemple : La dynamique "Aller plus vite c’est aller plus lentement" ===
Dorénavant, avec notre vocabulaire enrichi des termes de solutions de contournement, de boucles de feedback positives et de modèles mentaux, il est fascinant de voir qu’il peut y avoir un semblant d’amélioration à court terme sur une variable donnée, mais que cela entraîne en même temps une ''dégradation à retardement'' de cette même variable, d’où la dynamique "Aller plus vite c’est aller plus lentement". Il s’agit d’une dynamique récurrente et d’une cause de vulnérabilité à terme. Voici un nouvel exemple illustrant cela :

''L'histoire de Microsoft Word et de'' '''''la boîte à outils secrète du développeur''''' : un exemple typique d’une ‘amélioration’ à court terme mais d’une dynamique de dégradation à long terme est le récit de la première livraison de Microsoft Word sur Windows [http://www.amazon.com/Joel-Software-Occasionally-Developers-Designers/dp/1590593898/ [Spolsky04]]. Le logiciel a été livré avec des ''années'' de retard par rapport à la date prévue. Pourquoi ? ''Parce que les managers ont essayé à tout prix de suivre le calendrier de départ et ont fait pression sur les développeurs pour le respecter''.

Cette histoire illustre pourquoi cet espoir illusoire de respecter une date souhaitée est bien identifié comme une source de gâchis dans l’approche lean. Dans le cas présent l’espoir illusoire consiste à insister (du moins apparemment) à suivre le calendrier, ce qui implique une idée fausse ou illusoire que les estimations ne sont pas de simples estimations mais des promesses, un mythe classique qui pousse à la dégradation d’un système.

Le modèle qui suit ''résume'' les dynamiques à l’oeuvre lorsque des managers poussent leurs équipes à respecter à tout prix les calendriers prévisionnels, et pourquoi cette solution de contournement qui freine pourtant l’avancement des travaux semblent les faire aller plus vite à court terme mais en réalité ''plus lentement'' à long terme. Par rapport à ce qui est décrit précédemment dans la dynamique de la pression du calendrier et de la boîte à outils secrète, certaines dynamiques ont été omises intentionnellement sur ce schéma et sont visibles sur le schéma des dynamiques avancées.

[[File:Xsystems-thinking-18-fr.png|border|848px|link=]]

''Dynamique de la pression sur le calendrier et de la boîte à outils secrète.''

En solution de contournement, les managers de Microsoft ont exhorté, ont corrompu (à l’aide de primes potentielles), et ont menacé les développeurs de Word pour leur faire respecter le calendrier prévisionnel. En conséquence, les développeurs ont, de manière tout à fait prévisible, sorti leur '''boîte à outils secrète de développeurs''', autrement dit tout un arsenal de pratiques pour pisser du code pourri (aucuns tests, aucunes revues, ignorance des anomalies connues, développement par copier-coller, mauvaise conception, ...) pour développer visiblement plus vite. Vous voyez bien, les développeurs ont aussi des solutions de contournement pour régler leurs problèmes.

Vu de l’extérieur, ces tactiques ont fonctionné à merveille. Au fur et à mesure que les managers mettaient la pression sur les développeurs, les ‘features’ étaient développées de plus en plus vite grâce à l’utilisation de la boîte à outils secrète, ce qui a renforcé la croyance en quoi mettre la pression sur les développeurs était quelque chose d’utile. Mais cette apparente accélération a eu en fait un effet à retardement qui a rendu les choses plus lentes (c’est ce que nous allons voir par la suite). Étant donné que le management n’a pas été assez rapide à voir l’effet à retardement de la boîte à outils, et parce que les managers pensent qu’ils n’ont pas besoin d’aller regarder fréquemment en détails le code source ou qu’ils n’ont pas besoin d’être eux-mêmes des développeurs très expérimentés, ils n’ont rien appris de cette dynamique.

Le schéma ci-dessous illustre l’examen approfondie des dynamiques des systèmes montrant pourquoi les choses sont allées plus lentement à long terme et pourquoi le tout premier Word pour Windows a été livré des années en retard par rapport à la date souhaitée...

[[File:Xsystems-thinking-19-fr.png|border|848px|link=]]

''Dynamiques avancées de la pression sur le calendrier et de la boîte à outils secrète.''

Naturellement, avoir une grande quantité de code de mauvaise qualité ralentit les choses. De manière beaucoup plus subtile, les développeurs ont ''ignoré'' la liste croissante d’anomalies pour privilégier la production de nouvelles features. Cela a eu pour conséquence d’avoir un délai important entre la déclaration d’une anomalie et sa correction. Il s’avère que cela a fait augmenter de manière significative la variabilité et le temps nécessaire pour corriger une anomalie en raison des effets cumulatifs négatifs liés à la nature même d’une vieille anomalie (par exemple avec la mise en place des solutions de contournement et des couplages existants entre les fonctionnalités), de l’oubli du contexte détaillé par les développeurs en relation avec l’anomalie, ces derniers mettant par conséquent plus de temps à le redécouvrir, de l’accumulation continue de code de mauvaise qualité dans le même temps.

Le lecteur avisé remarquera également plusieurs boucles causales positives renforçant le cycle de dégradation ; il s’agit de l’une des raisons expliquant le retard pris sur plusieurs années pour livrer le produit.

Une solution ? L’approche lean avec les principes ''Arrêter et corriger'' et ''Aller voir''. ''Premièrement'', plutôt que d’essayer d’aller plus vite lorsqu’il y a des problèmes, des managers-formateurs encouragent les gens à aller plus ''lentement'' et à les inciter à apprendre les dynamiques des systèmes, les causes racines et à les corriger pour améliorer le ''système'' du développement. En allant plus lentement, Toyota - les maîtres de l’approche lean - est devenue l’une des entreprises les plus rapides du monde. ''Deuxièmement'', les managers doivent ''aller voir ce qui se passe sur le vrai lieu de travail'' pour apprendre ce qu’il se passe. Le ''vrai lieu'' dans le développement logiciel c’est le code, ce qui implique que les managers de proximité sont des développeurs expérimentés qui évalueront le code fréquemment.

Les personnes de chez Microsoft n’ont réfléchi sur la situation que bien après la livraison. Lorsqu’ils ont fini par faire une rétrospective, cela a amené à une politique du ''zéro défaut'', cela signifie que la première priorité était de corriger les anomalies connues dans le code en cours de développement afin d’aller vers du zéro anomalie ouverte dans la liste des anomalies avant d’écrire du code pour une nouvelle feature.

== Voir (et entendre) l’optimisation locale ==
"Chacun fait de son mieux, mais malgré tout le flux de production du système se dégrade. Comment cela est-il possible ?". Il s’agit du paradoxe de '''l’optimisation locale''', autrement dit c’est lorsqu’une personne à titre individuel ou qu'un responsable de département prend une décision d’un point de vue local ou dans son propre intérêt. Les personnes prenant ce type de décision ''croient fréquemment qu’ils prennent la meilleure décision'', mais parce que ‘meilleure’ est ici synonyme d’optimisation locale, cela a pour résultat une sous-optimisation globale du flux du système. Ceci est le résultat d’une "mentalité de silo", d’incompréhension, de peur, de restrictions d’informations, de feedbacks à retardement, d’ignorance, de carriérisme, d’avarice et de bien d’autres ''dysfonctionnements d’apprentissages organisationnels''.

Une petite équipe produit de 30 personnes n’a ni le temps ni l’argent pour s’engager dans ce genre de non-sens ou de gâchis. Mais les grandes entreprises avec de grands groupes produit, des processus centralisés et des groupes outils, un "bureau de gestion de projet" centralisé, et ainsi de suite, semblent avoir élevé l’optimisation locale et le gâchis à une forme d’art. Les bureaucraties gouvernementales en sont bien sûr la quintessence. En conséquence, lorsque vous servez de guide dans une adoption agile à grande échelle, ''voir'' (ou ''entendre'') et s’occuper de l’optimisation locale est tout simplement quelque chose de vital.

Par exemple, les départements juridiques et sécurité mettent en place des politiques qui leurs semblent très importantes de leurs points de vue. Dans l’objectif de prévenir la perte de propriété intellectuelle, le département juridique peut décréter "il est interdit d’afficher tout type d’information sur les murs". Or, le département de la logistique, soumis de son côté à une pression de politique de réductions des coûts peut surenchérir en disant : "Il est important de s’assurer que nos murs ne soient ni sales ni abîmés". Et ainsi s’arrête le management visuel qui est l’une des pratiques de l’approche lean (le management visuel se faisant habituellement sur les murs), et ils inhibent également une pratique d’innovation bien connue à savoir le travail de groupe devant un tableau blanc. Les juristes réussiront peut être à réduire la perte de propriété intellectuelle (ce qui en réalité devrait poser question), et les gens de la logistique réussiront à garder leurs murs propres, mais au prix d’inhiber le groupe de développement produit dans sa capacité d’innover et de collaborer. Finalement, l’entreprise se laissera distancer par la concurrence avec de moins en moins de propriété intellectuelle valant la peine d’être défendue parce que les outils permettant l’innovation et de livrer rapidement ont été bannis, mais les juristes auront rempli leur mandat vis-à-vis de la direction pour "s’assurer que la propriété intellectuelle est protégée". Et la police de la logistique aura nettoyé les murs. ''Ils ont fait de leur mieux''.

Ce qui suit est extrait d’un vrai mail de la ''POLICE DE LA LOGISTIQUE'' dans une organisation qui a banni le management visuel sur les murs. Pouvez-vous identifier les optimisations locales et les modèles mentaux qui sont derrière tout ça ?

Les [https://fr.wikipedia.org/wiki/Bureau_%C3%A0_cloisons bureaux à cloisons] peuvent être personnalisés. Mais tout ce qui est visible au-dessus de la cloison ou qui perturbe l’harmonie de l’environnement de bureau est interdit.

Nous constatons aussi des optimisations locales dans les groupes centralisés dont le rôle est de choisir les logiciels pour les autres personnes de l’entreprise. La croyance la plus répandue relative à cette démarche est qu’il s’agit de ce qu’il y a de mieux pour réduire les coûts d’achats (curieusement ces mêmes groupes recommandent rarement les logiciels open source gratuits) ou ce qu’il y a de mieux pour accomplir une tâche compliquée ou ce qu’il y a de mieux pour l’accomplissement du travail d’un seul type de travailleur (même si ''tout le monde'' est censé devoir utiliser l’outil), plutôt que de maximiser l’objectif de l’entreprise qui est d’avoir un système de flux de production de la valeur plus rapide pour les clients.

Dans les adoptions de Scrum ou des principes agiles à grande échelle, la plupart des problématiques de type "Oui, mais..." qui sont soulevées sont des exemples de sous-optimisations, comme par exemple "''Oui, mais... qu’en est-il des comptes-rendus auprès du management'' ?" ou encore de manière plus générale "* Oui, mais … qu’en est-il de... * ?". Alors, les principes et les pratiques sont dévoyés, pour servir soit l’objectif de rendre compte, soit n’importe quel autre objectif secondaire plutôt que suivre l’objectif d’optimiser le flux de valeur produite. De temps en temps, nous voyons des '''optimisations locales dans certains cas rares ou extrêmes'''. Par exemple, une entreprise doit choisir un outil centralisé répondant à un certain nombre de cas d’utilisations possibles dont un cas extrêmement rare ou complexe, la personne, en charge de faire ce choix, choisit un outil correspondant à un cas unique d’utilisation, sous-optimisant ainsi l’ensemble du système pour un cas représentant uniquement 5% des cas d’utilisation au lieu de l’optimiser pour la majorité des 95% des autres cas d’utilisations.

D’autres optimisations locales sont dues, quant à elles, à l’ignorance des nouvelles manières de travailler. C’est quelque chose de très répandue et tout spécialement dans les groupes produit à grande échelle. Par exemple, un jour nous avons aidé un groupe produit distribué à travers l’Europe à adopter d’une part Scrum et d’autre part la pratique de ''l’intégration continue'' le tout sous la forme d’un système d’intégration continue dédié intégrant, compilant, testant automatiquement de manière continue le produit. Après quelques temps, un manager, que l’on pourrait qualifier de traditionnel, extérieur au groupe est venu inspecter ce qu’il se passait. Celui-ci a recommandé que les pratiques d’intégration devraient être changées en raison de l’absence de schéma d’intégration global permettant à un responsable d’intégration de faire manuellement l’intégration de l’ensemble du logiciel ; une absence de schéma pour la bonne raison qu’il n’y avait plus besoin de responsable d’intégration au sein de l’organisation. Il voulait ‘optimiser’ le travail d’un responsable d’intégration qui n’existait plus. Il était dans l’impossibilité de voir que la totalité de l’ancienne manière de faire les choses avait disparu avec l’intégration continue. Cette histoire se répéta dans l’ensemble des départements du groupe produit : il y a avait des optimisations locales partout autour des façons de faire existantes, tels que les tests manuels, le département d’architecture séparé des équipes, les équipes composants, etc. N’importe quel coach dont la tâche consistait à introduire Scrum à grande échelle au niveau de l’organisation avait une ''montagne'' d’optimisations locales à penser à gérer.

Dans l’approche lean et dans les méthodes agiles, l’accent est mis sur les objectifs du système dans sa globalité : livrer de la valeur de grande qualité au plus vite tout en gardant le moral des équipes au plus haut - autrement dit une '''optimisation globale'''. Essayer de reconsidérer vos décisions à la lumière de cet objectif. Pour développer une culture de " l’optimisation globale", remettez donc en cause toutes les décisions et les règles avec la question suivante :

'''Est-ce que cette décision ou cette règle se focalise sur le fait de livrer de la valeur au client externe au plus vite, ou se focalise-t-elle sur les intérêts d’un département, d’une personne, d’une pratique/règle interne, ou d’un cas rarissime ?

Dans LeSS, le Product Owner est responsable pour choisir ces objectifs à haute valeur qui '''pourrait mener à un produit potentiellement livrable (à la fin du Sprint) maximisant les impacts souhaités et enchantant le client tout en maintenant un rythme soutenable et une haute qualité d’ingénierie'''. Cet objectif explicite est destiné à orienter le système vers son optimisation globale plutôt que vers une optimisation qui ne serait que locale.

== Conclusion ==
En plus de devenir un pratiquant de l’approche systémique vous-même, encouragez donc les autres à en apprendre plus sur ce sujet. Nous vous suggérons d’essayer de rassembler quelques-uns de vos collègues autour d’un tableau blanc et d’y dessiner des diagrammes de boucles causales, afin que les architectes des systèmes et les pratiquants de l’approche systémique soient réunis en un seul endroit.

[[Fichier:Xgroup-cld-modeling.jpg|848px|border|link=]]

''Séance d’approche systémique. Réalisation d’un diagramme de boucles causales à plusieurs mains dans l’objectif d’avoir une conversation.''

== Lectures recommandées ==

* [https://www.amazon.fr/Hors-crise-W-Edwards-Deming/dp/2717843930/ ''Hors de la Crise''] de W. Edwards Deming est un ouvrage de référence, sans conteste le plus connu des penseurs systémiques et des experts sur la qualité. Cet ouvrage commence par un objectif modeste : "l’objectif de ce livre est la transformation du style du management américain... ce qui exige de tout changer pour mettre en place une toute nouvelle structure." Deming prône un ''Système de connaissances approfondies'' dans lequel les managers (1) reconnaissent qu’il y a un ''système'', (2) qu’ils sont en mesure de comprendre les facteurs les plus répandus et les facteurs spéciaux de variations au sein du système (la théorie des files d’attente est liée à ce phénomène de variation), (3) qu’ils sont en mesure de comprendre que les connaissances sont limitées et qu’il y a des erreurs de raisonnement, et (4) que la psychologie et les recherches en sciences sociales jouent des rôles tout à fait crédibles dans l’objectif de comprendre que les règles régissant les comportements ou en lien avec la motivation des individus ne soient pas basés sur le seul "bon sens". Le coeur de l’ouvrage tourne autour des célèbres [[Les_14_points_de_Deming|''14 points pour le management'']], y compris par exemple "''Éliminer le management par les objectifs. Éliminer le management par les nombres, par les objectifs par les nombres. Y substituer le leadership''."
* [https://www.amazon.fr/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ ''Industrial Dynamics''] de Jay Forrester est un classique du genre sur les dynamiques des systèmes, très bien écrit et très instructif. Même si cet ouvrage a été écrit au début des années 1960, il est toujours aussi pertinent aujourd’hui. Il va au-delà de la modélisation des causes à effets pour modéliser également le flux et les stocks d’informations, d’argent et de matériaux au sein d’un système. Le livre contient également une modélisation mathématique formelle de ces dynamiques, toutefois la lecture de cette dernière reste facultative pour apprécier la qualité de l’ouvrage.
* Les ouvrages [https://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226/ ''Quality Software Management: Systems Thinking''] et [https://www.amazon.fr/Introduction-General-Systems-Thinking-Weinberg/dp/0932633498/ ''An Introduction to General Systems Thinking''] de Gerald Weinberg sont intéressants. Il sont écrits du point de vue d’un consultant expérimenté en développement de systèmes.
* [https://www.amazon.fr/cinqui%C3%A8me-discipline-Levier-organisations-apprenantes/dp/2212559372/ ''La cinquième discipline''] est un autre classique du genre qui prône que l’encadrement d’une entreprise devrait appliquer l’approche systémique (autrement dit la ''cinquième'' discipline) ainsi que d’autres disciplines-clés toutes aussi importantes en vue d’obtenir une entreprise durable. Ces autres disciplines que les dirigeants devraient appliquer sont (1) une discipline personnelle, (2) une réflexion sur leurs propres croyances et raisonnements erronés, (3) la définition et la communication d’une vision partagée ayant du sens, et (4) la capacité des équipes à apprendre. Nous vous recommandons d’ignorer - du moins dans un premier temps pendant vos premières années de pratiques - le concept d’archétypes présenté dans le livre. Ce concept avait pour but d’être une aide à l’apprentissage de la cinquième discipline mais nous avons observé qu’il était soit une source de distraction soit qu’il intimidait les lecteurs quant à leur apprentissage et à l’application de la modélisation basique<ref> ‘Basique’ ne signifie pas trivial ou facile à résoudre. Par exemple, les problématiques de 'motivation' et de 'qualité' sont des problématiques basiques mais elles ne sont pas faciles à résoudre.</ref>de dynamiques des systèmes. Les ‘archétypes’ ne font pas partie à l’origine des dynamiques des systèmes.
*[https://www.amazon.fr/guide-lorganisation-apprenante-d%C3%A9velopper-lintelligence/dp/2212568711/ ''La 5ème discipline - le guide de l’organisation apprenante''] est une source extrêmement riche sur l’approche systémique écrite du point de vue des pratiquants de cette approche et de consultants.
* Les écrits d’Argyris, Outnam, McLain et Schön sur les apprentissages organisationnels comme [https://actiondesign.com/resources/readings/action-science ''Action Science''] et [http://www.amazon.com/Organizational-Learning-Addison-Wesley-Organization-Development/dp/0201001748/ ''Organizational Learning''] abordent des concepts importants tels que la ''double-boucle apprenante'' et le ''dialogue grand-plaidoyer/grand-réquisitoire''.
* Les publications et les ressources de la ''Society for Organizational Learning''](https://www.solonline.org/).

== Notes ==
<references />

LeSS - Approche systémique

2020-11-01T19:13:08Z

Nicolas Mereaux :

[[Category: Nicolas Mereaux]]
[[Category: Portail LeSS]]
[[Category: Agilité à grande échelle]]
Auteur : The LeSS Company B.V. 
Source : [https://less.works/less/principles/systems-thinking.html Systems Thinking] 
----
Traducteur : Nicolas Mereaux [[Fichier:Nime.png|50px|link=https://twitter.com/__nime__]] 
Relecteurs : Christophe Gesché, Fabrice Aimetti 
Date : 27/10/2020 
----
Traduction : 
 
[[LeSS - Portail Principes]] 
 

== Approche systémique ==

''J’ai pris un cours de lecture rapide puis j’ai lu « Guerre et Paix » en vingt minutes. Cela parle de la Russie. — Woody Allen''

"Quoi que nous fassions, le nombre d’anomalie dans notre ''backlog'' reste identique." nous a dit un jour un manager en évoquant un produit de près de 15 millions de lignes de code écrites en C et C++ et sur lequel plusieurs centaines de développeurs étaient en train de travailler. Que pouvait-il bien se passer ? L’approche systémique peut s’avérer utile dans ce cas. En petits groupes, les forces en présence peuvent rapidement être identifiées et comprises de manière informelle, mais dans le cadre du développement d’un gros produit ou de n’importe quel gros système, c’est difficile. Gerry Weinberg met en avant deux facteurs décisifs dans ce genre de situation :

'''Loi de Weinberg-Brooks''' : De plus en plus de projets informatiques sont partis de travers après que le management ait pris des décisions basées sur des '''modèles systémiques incorrects''' plus que pour toutes autres combinaisons de causes.

'''Erreur de causalité''' : Chaque effet a une cause... et nous pouvons dire desquelles il s’agit. [http://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226 [Weinberg92]]

Ces deux facteurs reflètent bien l’impact de nos '''modèles mentaux''' sur le système, un sujet que nous reverrons plus tard dans cette partie.

Les problèmes résultant de nos modèles mentaux et de nos postulats sont un point à traiter. Un autre point est l’adoption à grande échelle de Scrum, de l’approche lean et des principes agiles en dehors du domaine du développement. Ce point est aussi présent dans la gestion de produit, les budgets, les tests, la commercialisation, la gouvernance et la politique RH. En conséquence, dans les adoptions agiles à grande échelle, il est utile de se réunir avec des collègues et de ''réfléchir en profondeur'' sur les modèles mentaux, les relations causales, les boucles de feedback et les mécanismes (ou les illusions) de contrôle dans un gros système qui va être sérieusement ''perturbé''. L’approche systémique est l’un de ces outils de réflexion.

En 1958 la ''Harvard Business Review'' a publié un article de Jay Forrestor, professeur à la MIT Sloan School, qui a fait date [https://kupdf.com/download/industrial-dynamics-a-major-breakthrough-for-decision-makers_5902479bdc0d603940959ed5_pdf “Industrial Dynamics: A Major Breakthrough for Decision Makers”]. Cet article a lancé le mouvement de l’approche systémique dans le domaine des formations en gestion d’entreprise et la MIT Sloan School of Management devint célèbre pour ses formations en '''dynamique des systèmes'''. Le terme de dynamique des systèmes est parfois utilisé comme synonyme de l''''approche systémique''', même si ce dernier est un terme beaucoup plus général.

Le MIT a également attiré d’autres chercheurs intéressés par la dynamique systémique tel que Peter Senge<ref>''La cinquième discipline'' écrit par Senge sur l’approche systémique et les organisations apprenantes a été nommé "l’un des livres les plus novateurs sur le management de ces 75 dernières années" par la ''Harvard Business Review.'' [Senge94].</ref>

En corrélation avec la loi de ''Weinberg-Brook'', Jay Wright Forrester a montré que les décideurs à qui il avait été donné des modèles dynamiques de systèmes opérationnels et à qui il avait été demandé d’améliorer la performance opérationnelle, ''n’avaient fait généralement qu’empirer les choses'' [https://www.amazon.fr/guide-lorganisation-apprenante-d%C3%A9velopper-lintelligence/dp/2212568711/ [SKRRS94]]. Il en est ressorti d’ailleurs que la plupart des personnes évaluaient mal la manière dont il faut améliorer les systèmes, et appliquaient généralement leur "bon sens", en mettant en place des solutions de contournement qui n’apportent aucune amélioration systémique à long terme.

Pourquoi le comportement d’un groupe de développement de grande taille (autrement dit un système) n’est-il pas compris ou guidé de manière compétente ? La réponse réside, en partie, dans le comportement des systèmes stochastiques avec les files et les variabilités comme nous avons pu l’évoquer avec le principe LeSS de la [https://less.works/less/principles/queueing_theory.html théorie des files d’attentes (en)]. Et c’est la même réponse qui est au coeur de la ''théorie du contrôle'' : la plupart des systèmes d’intérêt - tel qu’un groupe de développement de produit - ont des boucles de feedback positives et négatives ainsi qu’un comportement non linéaire. Le comportement de ces systèmes défient nos intuitions les plus profondes. Et puis il y a la question secondaire des ''gens''.

En résumé, les raisons expliquants l’incompétence à maîtriser ou à guider un gros système sont (liste non exhaustive) :

* le manque de connaissance des dynamiques des systèmes, des boucles de feedback, du comportement non linéaire des systèmes, et des conséquences inattendues dans les systèmes sur le lieu de travail.
* la mauvaise compréhension des causes racines des problèmes (et de comment les trouver)
** ''les causes'', pas ''la cause'' ; en approche systémique, nous savons que les causes des problèmes sont multiples, indirectes et dynamiques
* l’incapacité à savoir si ou pourquoi une solution de contournement ou une décision locale dégrade la performance globale opérationnelle.

Pour résumé, nous n'utilisons pas l’approche systémique<ref>Une autre raison : croire que plus de contrôle est possible qu’il ne l’est en réalité. La science de la complexité suggère qu’il existe des limites en termes de prédiction et de contrôle des systèmes sociaux semi-chaotiques [Stacey07]. C’est une énorme boîte de Pandore qui restera close dans ce livre.</ref>.

Ces raisons sont la conséquence de l’intersection du management et de l’adoption à grande échelle des principes lean et agile. L’équipe de direction fait partie du système qui est perturbé ; si elle n’applique pas l’approche systémique, elle pourrait ''vraiment'' le perturber - et pas de la bonne manière !

Les points-clés à retenir de l’approche systémique peuvent être résumé dans les [https://en.wikipedia.org/wiki/The_Fifth_Discipline#The_11_Laws_of_the_Fifth_Discipline 11 'lois'] décrites dans la [https://www.amazon.fr/cinqui%C3%A8me-discipline-organisations-apprenantes-dexemplaires-ebook/dp/B017WSYAHG Cinquième Discipline] :
* Les problèmes d’aujourd’hui viennent des 'solutions' d’hier.
* Plus vous poussez, plus le système pousse en retour.
* Le comportement va d’abord empirer avant de s’améliorer.
* La manière la plus facile de s’en sortir conduit souvent à faire quelques pas en arrière.
* Le médicament peut être pire que la maladie.
* Aller plus vite c’est aller plus lentement.
* Les causes et les effets ne sont pas étroitement liés dans l’espace et le temps.
* De petits changements peuvent produire de gros résultats... mais les zones où l’effet de levier est le plus important sont souvent les moins évidentes.
* Vous pouvez avoir votre gâteau et le manger aussi... mais pas en une seule bouchée.
* Couper un éléphant en deux ne produit pas deux petits éléphants.
* Il n’y a aucun reproche à faire.

La devise de Toyota en interne est [http://www.toyota-global.com/company/toyota_traditions/quality/may_jun_2005.html "Bien '''réfléchir''' permet d'avoir de bons produits"]. L’approche systémique est un ensemble d’outils de réflexion pour aider à :
* '''voir les dynamiques des systèmes''' : une organisation de développement est un système de personnes et de règles avec de subtiles boucles de feedback et des conséquences inattendues
** nous pouvons apprendre à voir et ainsi à améliorer le système avec des '''diagrammes de boucles causales''' réalisés lors d’un atelier
* '''percevoir les modèles mentaux''' : parmi les raisons derrière des décisions sous-optimales se trouvent des hypothèses erronées et des raisonnements incorrects
** les diagrammes de boucles causales et les cinq pourquoi permettent de révéler cela
* '''voir les optimisations locales''' : une autre source de décisions sous-optimales est '''l’optimisation locale''', autrement dit prendre la "meilleure" décision du point de vue d’une personne ou d’un département, au détriment d’une '''optimisation globale''' qui est l’objectif au niveau système ''lean'' et qui consiste à pouvoir ''livrer la plus grande valeur possible de très grande qualité avec un moral d’acier.''

Cette présentation de l’approche systémique est faite autour des domaines suivants : apprendre à voir (1) ''les dynamiques des systèmes'', (2) ''les modèles mentaux'', (3) ''les causes racines'', et (4) ''l’optimisation locale''.

== Voir les dynamiques des systèmes : introduction ==

=== Complexité statique versus complexité dynamique ===

La plupart d’entre nous, notamment les ingénieurs et les financiers, ont été formés pour maîtriser la '''complexité de détails statiques''', en apprenant à analyser et à gérer l’information (exigences, analyses financières, ...), à décomposer des structures complexes en structures simples, et ainsi de suite. C’est-à-dire, la complexité d’une information qui est par nature structurellement statique.

Pourquoi les gros systèmes informatiques ont-ils tendance à se dégrader malgré de plus en plus de temps passé sur les anomalies ? Qu’est-ce qui pourrait bien se passer si les États-Unis d’Amérique envahissait l’Irak ? Voir les dynamiques derrière ces questions implique d’analyser la '''complexité des dynamiques''' en jeu.

Au contraire d'une formation sur les détails statiques que la plupart d’entre nous avons suivie, peu d’entre nous ont reçu de formation sur l’étude des systèmes dynamiques et complexes<ref>Macro économie, psychologie, sociologie et biologie sont des exceptions parmi tant d’autres.</ref> et notamment dans le milieu professionnel. Peut-être parce que nous avons la croyance qu’il est suffisant de s’appuyer sur le bon sens en milieu professionnel. Jay Wright Forrester a démontré que le "bon sens" n’est pas suffisant dans des systèmes complexes et qu’il est possible de former des personnes pour leur permettre de mieux appréhender les '''modèles de dynamique des systèmes''' en milieu professionnel en utilisant notamment des ''diagrammes de flux'' [http://www.amazon.fr/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ [Forrester61]].

Les diagrammes de flux peuvent s’appliquer aussi bien aux flux matériels, financiers, d’informations, de stocks (n’importe quel type de stock quantitatif comme de l’argent ou des anomalies), aux conséquences des décisions et des politiques et des relations de causes à effet. Lorsque nous pensons aux diagrammes de flux, nous pensons souvent au seul ''diagramme de boucle causale'' dédié aux relations de cause à effets et aux boucles de rétroaction dans un système [http://www.amazon.fr/Business-Dynamics-Systems-Thinking-Modeling/dp/0071179895 [Sterman00]]. Il existe une grande variété d’autres diagrammes qui peuvent faire figurer les stocks (quels qu’ils soient), les liens de causalité, et les retards. Dans son ouvrage, [http://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226/ [Weinberg92]] Gerald Weinberg appelle cela un ''diagramme d’effet''.

=== La première loi de la réalisation d’un diagramme : nous modélisons pour avoir une conversation ===

Un outil très utile pour apprendre les dynamiques des systèmes est le diagramme de boucles causales : nous vous recommandons de l’utiliser sur un tableau blanc notamment lors des Rétrospectives Globales LeSS avec les collègues. Mais avant d’aller plus loin, voici la ''première loi de réalisation d’un diagramme''.

'''La première valeur d’un diagramme c’est la discussion qui se déroule lors de la réalisation du diagramme : nous modélisons pour avoir une conversation.'''

Lorsqu’un groupe se rassemble pour dessiner un diagramme de boucles causales sur un tableau blanc ("C’est l’acte de discuter et de réfléchir qui est le plus important lorsque nous dessinons", Valtech India.), la première valeur d’un diagramme c’est la conversation et la compréhension commune à laquelle les personnes arrivent lors de la création du modèle. Ce qu’il en résulte, à savoir un diagramme facile à comprendre, est important pour rendre les idées et les modèles mentaux concrets et non ambigües (sur le tableau blanc) parce que les mots seuls peuvent être imprécis et mal compris. Toutefois, le diagramme est secondaire par rapport à ce avec quoi les gens repartent : ils ont appris quelque chose et ont revu leur compréhension du monde à travers une discussion.

[[Fichier:Xgroup-cld-modeling.jpg|848px|border|link=]]

''Un atelier d’approche systémique : réalisation d’un diagramme de boucles causales à plusieurs - modéliser pour avoir une conversation.''

''Trucs et astuces de pro pour modéliser'' : nous commençons par écrire sur des petits post-its les noms des ''variables'', par exemple "vélocité des ''features''" ou "nombre d’anomalies". Nous les plaçons ensuite sur le tableau blanc. Puis nous dessinons les liens de causalités entre les post-its. Il y aura (ou il devrait y avoir) beaucoup de réécriture, d’effaçage, de redessin lors de la session de modélisation. Le résultat le plus important d’une telle session est la ''compréhension'' : il se peut qu’à l’issue de cet atelier, certains participants voudront prendre une photo du dessin du tableau blanc.

== Voir les dynamiques des systèmes : les diagrammes de boucles causales ==

Les diagrammes de boucles causales sont souvent utilisés en introduction à LeSS pour aider à voir les dynamiques de ce qu’il se passe lors du développement à grande échelle. Il est donc utile de comprendre ce type de diagrammes pour cette seule et unique raison. Et cela s’avèrera encore plus utile pour vous, si vous le faites avec vos collègues devant un tableau blanc. Vous modélisez pour avoir une conversation. Quand ? Plus probablement lors d’une rétrospective globale LeSS.

L’aspect pratique de cet exercice est bien plus important que ce qu’il peut paraître au premier abord. Notre conseil d’"être un pratiquant systémique" peut vous sembler vague et sans grand impact. Mais si vous et quatre de vos collègues prenez l’habitude de vous réunir devant un grand tableau blanc, en dessinant des diagrammes de boucles causales ensemble, alors vous arriverez à faire la connexion entre "''être'' un pratiquant systémique" avec "''faire'' de l’approche systémique".

Les exemples suivants peuvent paraître aseptisés car présentés dans un livre. Mais imaginez-vous à côté d’un tableau blanc avec d’autres personnes dessinant ensemble des diagrammes au cours d’une conversation animée. C’est de cette manière-là que nous suggérons de 'faire' de l’approche systémique.

=== Notation et exemples ===

Les diagrammes de boucles causales contiennent beaucoup d’éléments ; les éléments suivants sont les plus communément utilisés et sont vus en détail tout au long du scénario qui va suivre :
* variables
* liens de causalité
* effets opposés
* contraintes
* objectifs
* réactions ; solutions de contournement
* effets d’interaction
* effets extrêmes
* retards
* boucles de feedback positives

''Le scénario qui suit est un scénario simplifié pour une organisation spécifique. Il ne s’agit pas d’une généralisation.''

====Les variables====
Les diagrammes de boucles causales comportent des ''variables'' (ou des stocks) telle que la ''vélocité (taux de livraison) des features logicielles'' et le ''nombre d’anomalies''. Les variables ont une quantité mesurable.

[[File:Xsystems-thinking-4-fr.png|border|848px|link=]]

====Les liens de causalité====
Un élément peut avoir un effet sur un autre, par exemple si la vélocité des ''features'' augmente alors le nombre d’anomalies augmente ; autrement dit, plus de code, plus d’anomalies.

[[File:Xsystems-thinking-5-fr.png|border|848px|link=]]

Il est temps désormais de se jeter à corps perdu dans la ''loi de Weinberg-Brooks'' et dans la ''causalité fallacieuse''. Il est facile de dessiner un diagramme, ça l’est moins de modéliser en faisant preuve de clairvoyance comme par exemple, la relation entre le ''nombre de développeurs'' et la ''vélocité des features''.

Toute relation de cause à effets est par nature obscure, même si les gens ont l’habitude de sauter sur la première conclusion venue comme par exemple plus de développeurs égale plus de vélocité. Ajouter des personnes tard au cours du développement peut ''réduire'' la vélocité (il s’agit d’une composante de la "loi de Brooks" [Brooks95]). Ou, ''davantage'' de mauvais développeurs pourrait vraiment vous ralentir. Il pourrait être objecté qu’''enlever'' des développeurs exécrables peut permettre ''d’améliorer'' la vélocité.

[[File:Xsystems-thinking-6-fr.png|link=|848px|border]]

====Effets opposés====
L’effet d’un lien de causalité peut aller dans la même direction ou dans la direction opposée. Si A augmente alors B augmente, ou vice versa. L’effet opposé se souligne à l’aide d’un ‘O’ sur la ligne. Supposons que les anomalies ralentissent grandement le système, réduisant la vélocité des nouvelles features parce que les gens passent davantage de temps à corriger ou à trouver des solutions de contournement aux anomalies.

[[File:Xsystems-thinking-7-fr.png|border|848px|link=]]

====Contraintes====
À moins que vous ne trouviez des personnes prêtent à travailler gratuitement, il y a une contrainte sur le nombre de développeurs basé sur le budget disponible.

Les contraintes ne sont ''pas'' des liens de causalité. Lorsque le montant du budget disponible augmente, ce n’est pas le cas du nombre de développeurs.

[[File:Xsystems-thinking-8-fr.png|border|848px|link=]]

====Buts et réactions====
Les personnes, les départements et les systèmes ont des buts, comme par exemple avoir une ''vélocité des features plus élevée''. Les buts occasionnent souvent de la pression pour que les gens réagissent (ou agissent) dans l’intention de leur faire atteindre ce but. Mais étant donné qu’il y a la ''causalité fallacieuse'' et la ''loi de Weinberg-Brooks'' à laquelle il faut faire face, les gens devraient être prudents quant aux actions pertinentes à entreprendre. Voici un exemple de diagramme modélisant cela :

[[File:Xsystems-thinking-9-fr.png|border|848px|link=]]

Non seulement un but à atteindre avec une ''récompense'' au bout engendre une pression à agir, mais cela créé aussi une pression à ''faire semblant'' d’agir et à atteindre le but : les récompenses provoquent un '''dysfonctionnement des indicateurs'''. Le dysfonctionnement des indicateurs peut être proportionnel à la valeur perçue de la récompense parce que les personnes sont motivées pour avoir la récompense, non pour améliorer le système [http://www.amazon.fr/Measuring-Managing-Performance-Organizations-Dorset-ebook/dp/B00DY3KQX6/ [Austin96]]. Remarquez bien comment et de quelle manière les récompenses peuvent dégrader la performance du système. De manière visuelle, les dynamiques d’un tel système pourrait être...

[[File:Xsystems-thinking-10-fr.png|border|848px|link=]]

Il est assez intéressant de voir que toutes ces dynamiques ont été ajoutées par l’introduction d’une récompense et qu’il n’y pas de connexion entre le haut et le bas de cette modélisation.

Il n’y a aucune garantie que la vélocité des features s’améliore ou même que l’on y travaille.

Enlever le système de récompense est une solution à la cause racine de ce dysfonctionnement. Une autre contremesure de surface est le principe et le comportement managériale ''Aller voir'' (aller voir physiquement sur le lieu où le travail s’effectue) de l’approche lean :

[[File:Xsystems-thinking-11-fr.png|border|848px|link=]]

====Solutions de contournement====
Une solution payante à long terme pour atteindre une vélocité plus grande, mais qui n’est pas sans difficulté, consiste à : recruter des développeurs très qualifiés, faire davantage d’accompagnements et de formations, et à se séparer des moins bons éléments. L’alternative est ce que l’on appelle une ''solution de contournement'', c’est ce que l’on met en place dans l’espoir d’atteindre l’objectif en moins de temps et avec moins d’effort. Parfois, une solution de contournement se révèle payante aussi bien sur le court terme que sur le long terme, renforçant par la-même le système. D’autres fois cela ne fonctionne pas... d’où l’expression "aller plus vite c’est aller plus lentement". Par exemple, les gens peuvent ''croire'' qu’augmenter le nombre de développeurs permet d’augmenter la vélocité des features. Et ils peuvent par conséquent être amenés à espérer qu’en recrutant davantage de développeurs cela permettra de résoudre plus vite et plus facilement le problème de vélocité. La mention 'SC' sur le diagramme ci-dessous indique une solution de contournement.

[[File:Xsystems-thinking-12-fr.png|border|848px|link=]]

====Effets d’interaction====
La capacité à embaucher est contraint à la capacité budgétaire. Une solution de longue haleine non sans difficulté est d’obtenir davantage de budget. Une solution de contournement possible est de recruter un ''grand'' nombre de développeurs bon marché. Dans ce cas, le niveau du budget a un ''effet d’interaction'' avec les autres boucles causales. Un budget peu élevé aura tendance à renforcer le taux de développeurs bon marché si la pression pour recruter augmente.

Nous pourrions dessiner simplement un lien de causalité (opposé) de ''rentrée budgétaire'' à ''taux de recrutement de développeurs bon marché'', mais cela voudrait simplement dire qu’avoir un budget moindre aurait pour conséquence de recruter davantage de développeurs bon marché. Mais ce n’est pas tout à fait ce que nous voulons dire ; ce que voulons montrer en fait, c’est l’effet d’interaction, c’est-à-dire qu’un effet A influence un ''effet'' B. Cela se fait en montrant un lien de causalité heurtant un autre lien de causalité, par exemple en traçant une ligne de ''rentrée budgétaire'' vers la ligne représentant la solution de contournement qui va vers ''taux de recrutement de développeurs bon marché''.

[[File:Xsystems-thinking-13-fr.png|border|848px|link=]]

====Effets extrêmes====
Il nous est arrivé de travailler avec d’excellents développeurs très bon marché et avec d’autres développeurs hors de prix et très nuls, mais en moyenne, vous obtenez à hauteur de ce que vous payez ; lorsque vous recrutez au moins disant, le niveau moyen en terme de compétences sera plus faible. Dans le diagramme ci-dessous, nous avons voulu montrer que l’impact du recrutement de personnes bon marché en rapport avec le ''nombre de développeurs peu qualifiés'' à un impact sensiblement plus grand que la moyenne.

Pour montrer un ''effet extrême'' sur un modèle, faites un trait épais comme vous pouvez voir ci-dessous :

[[File:Xsystems-thinking-14-fr.png|border|848px|link=]]

====Retards====
Un problème courant au niveau du recrutement dans un projet de développement logiciel concerne ''l’erreur au niveau de la variance d’un développeur moyen'' ; autrement dit la croyance fausse que la variance d’un développeur à un autre (en terme de productivité, de qualité de code, etc.) est relativement faible. Toutefois, les études de la variance au sujet des développeurs montrent un rapport de 1 à 4 entre le 1er quartile et le dernier [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.4788 [Prechelt00]]. C’est plutôt quelque chose de significatif. De même des études - en long et en large - du modèle COCOMO montrent que la capacité du développement personnel est le facteur de loin le plus important quant à la productivité [http://www.amazon.com/Software-Cost-Estimation-Cocomo-II/dp/0130266922/ref=sr_1_1?ie=UTF8&qid=1413597244&sr=8-1&keywords=Software+Cost+Estimation+with+Cocomo+II [Boehm00]]. Et, en moyenne, il s’avère que les développeurs peu qualifiés font du code de mauvaise qualité (mauvaise conception) et de plus d’anomalies, ceci rajoute un autre frein au système.

Mais l’impact de ces effets ne sont pas visibles immédiatement. Par exemple, cela peut prendre un certain temps après un recrutement massif de développeurs peu qualifiés avant que les impacts négatifs ne se fassent sentir au niveau de la qualité du code ou de la conception. De manière similaire, la ''baisse'' moyenne de la vélocité des features (en raison de l’impact important de la variance des développeurs évoqué plus haut) ne se verra pas immédiatement.

Pour montrer ces ''effets à retardement'' dans le modèle, faites une double-ligne en travers de la ligne d’effet.

[[File:Xsystems-thinking-15-fr.png|border|848px|link=]]

Le retard a une influence intéressante sur le pouvoir ''pédagogique'' ou correctif sur un système. Si un impact ou une conséquence inattendue est retardé suffisamment longtemps, personne n’en voit ni l’effet (qu’il soit bénéfique ou néfaste) ni sur la façon dont A influence B ou plus subtilement comment ''A a influencé B qui a influencé A''.

Par conséquent, personne n’apprend de ses erreurs ni n’est en capacité de les corriger, que ce soit en terme de stratégie, d’actions d’encadrement, d’outils ou de quoi que ce soit. De la même manière, l’amélioration graduelle à travers l’application d’une démarche lean ''kaizen'', peut prendre un certain temps ; de la patience et de la perspicacité sont nécessaires pour voir si et comment les choses s’améliorent.

====Boucles de feedback positives====
Les boucles de feedback négatives ou positives<ref>''Les boucles de feedback'' sont parfois utilisées dans ce livre dans le sens littéral du terme, plutôt dans le sens des dynamiques des systèmes.</ref> et les retards sont le point de départ pour une approche plus subtile d’un système, et de sa compréhension. Par exemple, de quelle manière une personne peut-elle devenir un meilleur développeur ? En partie, en bénéficiant du mentorat de très bons développeurs et en jetant un oeil sur du très bon code. Mais il est impossible de trouver du bon code dans un endroit remplit de développeurs médiocres, il est impossible également d’y attirer ou de retenir le petit groupe de très bon développeurs qui pourraient prendre le rôle de mentors. Ils préfèrent largement aller travailler ailleurs.

Ce groupe de développeurs médiocres rentrent dans un cercle vicieux en raison d’un ensemble de ''boucles de feedback positives''. Fort heureusement, ce cercle vicieux est assujetti aux contraintes du budget.

Malheureusement de plus en plus des très bons développeurs, ceux en capacité d’élaborer du très bon code et de faire du mentorat auprès des autres développeurs, partent. Par conséquent, il y a de moins en moins de code de qualité à regarder et à partir duquel il est possible d’en tirer des enseignements. Le pourcentage de développeurs médiocres augmente de plus en plus et la vélocité au niveau des features continue à chuter. Le code devient de plus en plus brouillon, difficile, avec pleins de bouts de code dupliqués à gauche et à droite, le tout de telle manière que la capacité d’implémenter des features décline. Étant donné que la vélocité des features continue de chuter, il y a davantage de pression pour recruter des développeurs très bon marché. Tout cela conduit à de multiples boucles de renforcement positives dans le système comme l’illustre l’exemple ci-dessous :

[[File:Xsystems-thinking-16-fr.png|border|848px|link=]]

''Astuce'' : Vous pouvez trouver des boucles de feedback positives en cherchant des cycles ayant un ''nombre pair'' de relations. Vous en trouverez plusieurs exemples ci-dessus.

==== Conclusion ====

Le scénario donné à titre d’exemple est uniquement cela, un exemple. Une diagramme de boucle causale permet de visualiser la richesse de la dynamique dans le système dans un milieu professionnel. La meilleure manière de modéliser un tel système est de le faire en groupe face à un tableau blanc.

== Voir les modèles mentaux ==
Les précédents diagrammes de boucles causales reflètent les modèles mentaux de causalité des individus... qui peuvent s’avérer faux. Il est intéressant de remarquer que les modèles de causalité des individus sont influencés par la ponctualité (ou les retards) et la qualité des feedbacks dans le système.

Les "modèles mentaux" nous permettent d’améliorer nos compétences de méta-cognition pour voir et questionner nos propres postulats et l’enchaînement de nos raisonnements. Brûlons-nous des étapes de manière erronée ? Cette question implique aussi lorsque nous sommes en train de travailler avec des collègues de discuter avec eux (en s’enquérant plutôt qu’en reprochant) de leurs modèles mentaux.

''Voir'' les modèles mentaux n’est que la première étape ; les ''changer'' constitue une seconde partie bien plus difficile. Cet art est bien au-delà du sujet de cette introduction, même si une adoption réussie de LeSS implique des changements en terme d’état d’esprit et de prise de conscience au sein de très nombreuses équipes.

Une astuce pour mieux ''voir'' les modèles mentaux (croyances, échelle d’inférence, ...) en jeu au niveau des dynamiques des systèmes est de poser les questions suivantes lors d’un atelier de modélisation puis de tracer les éléments de réponse au tableau blanc. "Parlons donc des hypothèses derrière ce modèle. Que ''croyons''-nous ou tenons pour acquis en terme de faits et d’effets qui nous ont conduits ici ?"

Les éléments de réponse sont dessinés sur le tableau blanc. En voici un exemple :

[[File:Xsystems-thinking-17-fr.png|botrder|848px|link=]]
''Visualiser les postulats présents dans nos têtes... nos modèles mentaux.''

=== Exemple : La dynamique "Aller plus vite c’est aller plus lentement" ===
Dorénavant, avec notre vocabulaire enrichi des termes de solutions de contournement, de boucles de feedback positives et de modèles mentaux, il est fascinant de voir qu’il peut y avoir un semblant d’amélioration à court terme sur une variable donnée, mais que cela entraîne en même temps une ''dégradation à retardement'' de cette même variable, d’où la dynamique "Aller plus vite c’est aller plus lentement". Il s’agit d’une dynamique récurrente et d’une cause de vulnérabilité à terme. Voici un nouvel exemple illustrant cela :

''L'histoire de Microsoft Word et de'' '''''la boîte à outils secrète du développeur''''' : un exemple typique d’une ‘amélioration’ à court terme mais d’une dynamique de dégradation à long terme est le récit de la première livraison de Microsoft Word sur Windows [http://www.amazon.com/Joel-Software-Occasionally-Developers-Designers/dp/1590593898/ [Spolsky04]]. Le logiciel a été livré avec des ''années'' de retard par rapport à la date prévue. Pourquoi ? ''Parce que les managers ont essayé à tout prix de suivre le calendrier de départ et ont fait pression sur les développeurs pour le respecter''.

Cette histoire illustre pourquoi cet espoir illusoire de respecter une date souhaitée est bien identifié comme une source de gâchis dans l’approche lean. Dans le cas présent l’espoir illusoire consiste à insister (du moins apparemment) à suivre le calendrier, ce qui implique une idée fausse ou illusoire que les estimations ne sont pas de simples estimations mais des promesses, un mythe classique qui pousse à la dégradation d’un système.

Le modèle qui suit ''résume'' les dynamiques à l’oeuvre lorsque des managers poussent leurs équipes à respecter à tout prix les calendriers prévisionnels, et pourquoi cette solution de contournement qui freine pourtant l’avancement des travaux semblent les faire aller plus vite à court terme mais en réalité ''plus lentement'' à long terme. Par rapport à ce qui est décrit précédemment dans la dynamique de la pression du calendrier et de la boîte à outils secrète, certaines dynamiques ont été omises intentionnellement sur ce schéma et sont visibles sur le schéma des dynamiques avancées.

[[File:Xsystems-thinking-18-fr.png|border|848px|link=]]

''Dynamique de la pression sur le calendrier et de la boîte à outils secrète.''

En solution de contournement, les managers de Microsoft ont exhorté, ont corrompu (à l’aide de primes potentielles), et ont menacé les développeurs de Word pour leur faire respecter le calendrier prévisionnel. En conséquence, les développeurs ont, de manière tout à fait prévisible, sorti leur '''boîte à outils secrète de développeurs''', autrement dit tout un arsenal de pratiques pour pisser du code pourri (aucuns tests, aucunes revues, ignorance des anomalies connues, développement par copier-coller, mauvaise conception, ...) pour développer visiblement plus vite. Vous voyez bien, les développeurs ont aussi des solutions de contournement pour régler leurs problèmes.

Vu de l’extérieur, ces tactiques ont fonctionné à merveille. Au fur et à mesure que les managers mettaient la pression sur les développeurs, les ‘features’ étaient développées de plus en plus vite grâce à l’utilisation de la boîte à outils secrète, ce qui a renforcé la croyance en quoi mettre la pression sur les développeurs était quelque chose d’utile. Mais cette apparente accélération a eu en fait un effet à retardement qui a rendu les choses plus lentes (c’est ce que nous allons voir par la suite). Étant donné que le management n’a pas été assez rapide à voir l’effet à retardement de la boîte à outils, et parce que les managers pensent qu’ils n’ont pas besoin d’aller regarder fréquemment en détails le code source ou qu’ils n’ont pas besoin d’être eux-mêmes des développeurs très expérimentés, ils n’ont rien appris de cette dynamique.

Le schéma ci-dessous illustre l’examen approfondie des dynamiques des systèmes montrant pourquoi les choses sont allées plus lentement à long terme et pourquoi le tout premier Word pour Windows a été livré des années en retard par rapport à la date souhaitée...

[[File:Xsystems-thinking-19-fr.png|border|848px|link=]]

''Dynamiques avancées de la pression sur le calendrier et de la boîte à outils secrète.''

Naturellement, avoir une grande quantité de code de mauvaise qualité ralentit les choses. De manière beaucoup plus subtile, les développeurs ont ''ignoré'' la liste croissante d’anomalies pour privilégier la production de nouvelles features. Cela a eu pour conséquence d’avoir un délai important entre la déclaration d’une anomalie et sa correction. Il s’avère que cela a fait augmenter de manière significative la variabilité et le temps nécessaire pour corriger une anomalie en raison des effets cumulatifs négatifs liés à la nature même d’une vieille anomalie (par exemple avec la mise en place des solutions de contournement et des couplages existants entre les fonctionnalités), de l’oubli du contexte détaillé par les développeurs en relation avec l’anomalie, ces derniers mettant par conséquent plus de temps à le redécouvrir, de l’accumulation continue de code de mauvaise qualité dans le même temps.

Le lecteur avisé remarquera également plusieurs boucles causales positives renforçant le cycle de dégradation ; il s’agit de l’une des raisons expliquant le retard pris sur plusieurs années pour livrer le produit.

Une solution ? L’approche lean avec les principes ''Arrêter et corriger'' et ''Aller voir''. ''Premièrement'', plutôt que d’essayer d’aller plus vite lorsqu’il y a des problèmes, des managers-formateurs encouragent les gens à aller plus ''lentement'' et à les inciter à apprendre les dynamiques des systèmes, les causes racines et à les corriger pour améliorer le ''système'' du développement. En allant plus lentement, Toyota - les maîtres de l’approche lean - est devenue l’une des entreprises les plus rapides du monde. ''Deuxièmement'', les managers doivent ''aller voir ce qui se passe sur le vrai lieu de travail'' pour apprendre ce qu’il se passe. Le ''vrai lieu'' dans le développement logiciel c’est le code, ce qui implique que les managers de proximité sont des développeurs expérimentés qui évalueront le code fréquemment.

Les personnes de chez Microsoft n’ont réfléchi sur la situation que bien après la livraison. Lorsqu’ils ont fini par faire une rétrospective, cela a amené à une politique du ''zéro défaut'', cela signifie que la première priorité était de corriger les anomalies connues dans le code en cours de développement afin d’aller vers du zéro anomalie ouverte dans la liste des anomalies avant d’écrire du code pour une nouvelle feature.

== Voir (et entendre) l’optimisation locale ==
"Chacun fait de son mieux, mais malgré tout le flux de production du système se dégrade. Comment cela est-il possible ?". Il s’agit du paradoxe de '''l’optimisation locale''', autrement dit c’est lorsqu’une personne à titre individuel ou qu'un responsable de département prend une décision d’un point de vue local ou dans son propre intérêt. Les personnes prenant ce type de décision ''croient fréquemment qu’ils prennent la meilleure décision'', mais parce que ‘meilleure’ est ici synonyme d’optimisation locale, cela a pour résultat une sous-optimisation globale du flux du système. Ceci est le résultat d’une "mentalité de silo", d’incompréhension, de peur, de restrictions d’informations, de feedbacks à retardement, d’ignorance, de carriérisme, d’avarice et de bien d’autres ''dysfonctionnements d’apprentissages organisationnels''.

Une petite équipe produit de 30 personnes n’a ni le temps ni l’argent pour s’engager dans ce genre de non-sens ou de gâchis. Mais les grandes entreprises avec de grands groupes produit, des processus centralisés et des groupes outils, un "bureau de gestion de projet" centralisé, et ainsi de suite, semblent avoir élevé l’optimisation locale et le gâchis à une forme d’art. Les bureaucraties gouvernementales en sont bien sûr la quintessence. En conséquence, lorsque vous servez de guide dans une adoption agile à grande échelle, ''voir'' (ou ''entendre'') et s’occuper de l’optimisation locale est tout simplement quelque chose de vital.

Par exemple, les départements juridiques et sécurité mettent en place des politiques qui leurs semblent très importantes de leurs points de vue. Dans l’objectif de prévenir la perte de propriété intellectuelle, le département juridique peut décréter "il est interdit d’afficher tout type d’information sur les murs". Or, le département de la logistique, soumis de son côté à une pression de politique de réductions des coûts peut surenchérir en disant : "Il est important de s’assurer que nos murs ne soient ni sales ni abîmés". Et ainsi s’arrête le management visuel qui est l’une des pratiques de l’approche lean (le management visuel se faisant habituellement sur les murs), et ils inhibent également une pratique d’innovation bien connue à savoir le travail de groupe devant un tableau blanc. Les juristes réussiront peut être à réduire la perte de propriété intellectuelle (ce qui en réalité devrait poser question), et les gens de la logistique réussiront à garder leurs murs propres, mais au prix d’inhiber le groupe de développement produit dans sa capacité d’innover et de collaborer. Finalement, l’entreprise se laissera distancer par la concurrence avec de moins en moins de propriété intellectuelle valant la peine d’être défendue parce que les outils permettant l’innovation et de livrer rapidement ont été bannis, mais les juristes auront rempli leur mandat vis-à-vis de la direction pour "s’assurer que la propriété intellectuelle est protégée". Et la police de la logistique aura nettoyé les murs. ''Ils ont fait de leur mieux''.

Ce qui suit est extrait d’un vrai mail de la ''POLICE DE LA LOGISTIQUE'' dans une organisation qui a banni le management visuel sur les murs. Pouvez-vous identifier les optimisations locales et les modèles mentaux qui sont derrière tout ça ?

Les [https://fr.wikipedia.org/wiki/Bureau_%C3%A0_cloisons bureaux à cloisons] peuvent être personnalisés. Mais tout ce qui est visible au-dessus de la cloison ou qui perturbe l’harmonie de l’environnement de bureau est interdit.

Nous constatons aussi des optimisations locales dans les groupes centralisés dont le rôle est de choisir les logiciels pour les autres personnes de l’entreprise. La croyance la plus répandue relative à cette démarche est qu’il s’agit de ce qu’il y a de mieux pour réduire les coûts d’achats (curieusement ces mêmes groupes recommandent rarement les logiciels open source gratuits) ou ce qu’il y a de mieux pour accomplir une tâche compliquée ou ce qu’il y a de mieux pour l’accomplissement du travail d’un seul type de travailleur (même si ''tout le monde'' est censé devoir utiliser l’outil), plutôt que de maximiser l’objectif de l’entreprise qui est d’avoir un système de flux de production de la valeur plus rapide pour les clients.

Dans les adoptions de Scrum ou des principes agiles à grande échelle, la plupart des problématiques de type "Oui, mais..." qui sont soulevées sont des exemples de sous-optimisations, comme par exemple "''Oui, mais... qu’en est-il des comptes-rendus auprès du management'' ?" ou encore de manière plus générale "* Oui, mais … qu’en est-il de... * ?". Alors, les principes et les pratiques sont dévoyés, pour servir soit l’objectif de rendre compte, soit n’importe quel autre objectif secondaire plutôt que suivre l’objectif d’optimiser le flux de valeur produite. De temps en temps, nous voyons des '''optimisations locales dans certains cas rares ou extrêmes'''. Par exemple, une entreprise doit choisir un outil centralisé répondant à un certain nombre de cas d’utilisations possibles dont un cas extrêmement rare ou complexe, la personne, en charge de faire ce choix, choisit un outil correspondant à un cas unique d’utilisation, sous-optimisant ainsi l’ensemble du système pour un cas représentant uniquement 5% des cas d’utilisation au lieu de l’optimiser pour la majorité des 95% des autres cas d’utilisations.

D’autres optimisations locales sont dues, quant à elles, à l’ignorance des nouvelles manières de travailler. C’est quelque chose de très répandue et tout spécialement dans les groupes produit à grande échelle. Par exemple, un jour nous avons aidé un groupe produit distribué à travers l’Europe à adopter d’une part Scrum et d’autre part la pratique de ''l’intégration continue'' le tout sous la forme d’un système d’intégration continue dédié intégrant, compilant, testant automatiquement de manière continue le produit. Après quelques temps, un manager, que l’on pourrait qualifier de traditionnel, extérieur au groupe est venu inspecter ce qu’il se passait. Celui-ci a recommandé que les pratiques d’intégration devraient être changées en raison de l’absence de schéma d’intégration global permettant à un responsable d’intégration de faire manuellement l’intégration de l’ensemble du logiciel ; une absence de schéma pour la bonne raison qu’il n’y avait plus besoin de responsable d’intégration au sein de l’organisation. Il voulait ‘optimiser’ le travail d’un responsable d’intégration qui n’existait plus. Il était dans l’impossibilité de voir que la totalité de l’ancienne manière de faire les choses avait disparu avec l’intégration continue. Cette histoire se répéta dans l’ensemble des départements du groupe produit : il y a avait des optimisations locales partout autour des façons de faire existantes, tels que les tests manuels, le département d’architecture séparé des équipes, les équipes composants, etc. N’importe quel coach dont la tâche consistait à introduire Scrum à grande échelle au niveau de l’organisation avait une ''montagne'' d’optimisations locales à penser à gérer.

Dans l’approche lean et dans les méthodes agiles, l’accent est mis sur les objectifs du système dans sa globalité : livrer de la valeur de grande qualité au plus vite tout en gardant le moral des équipes au plus haut - autrement dit une '''optimisation globale'''. Essayer de reconsidérer vos décisions à la lumière de cet objectif. Pour développer une culture de " l’optimisation globale", remettez donc en cause toutes les décisions et les règles avec la question suivante :

'''Est-ce que cette décision ou cette règle se focalise sur le fait de livrer de la valeur au client externe au plus vite, ou se focalise-t-elle sur les intérêts d’un département, d’une personne, d’une pratique/règle interne, ou d’un cas rarissime ?

Dans LeSS, le Product Owner est responsable pour choisir ces objectifs à haute valeur qui '''pourrait mener à un produit potentiellement livrable (à la fin du Sprint) maximisant les impacts souhaités et enchantant le client tout en maintenant un rythme soutenable et une haute qualité d’ingénierie'''. Cet objectif explicite est destiné à orienter le système vers son optimisation globale plutôt que vers une optimisation qui ne serait que locale.

== Conclusion ==
En plus de devenir un pratiquant de l’approche systémique vous-même, encouragez donc les autres à en apprendre plus sur ce sujet. Nous vous suggérons d’essayer de rassembler quelques-uns de vos collègues autour d’un tableau blanc et d’y dessiner des diagrammes de boucles causales, afin que les architectes des systèmes et les pratiquants de l’approche systémique soient réunis en un seul endroit.

[[Fichier:Xgroup-cld-modeling.jpg|848px|border|link=]]

''Séance d’approche systémique. Réalisation d’un diagramme de boucles causales à plusieurs mains dans l’objectif d’avoir une conversation.''

== Lectures recommandées ==

* [https://www.amazon.fr/Hors-crise-W-Edwards-Deming/dp/2717843930/ ''Hors de la Crise''] de W. Edwards Deming est un ouvrage de référence, sans conteste le plus connu des penseurs systémiques et des experts sur la qualité. Cet ouvrage commence par un objectif modeste : "l’objectif de ce livre est la transformation du style du management américain... ce qui exige de tout changer pour mettre en place une toute nouvelle structure." Deming prône un ''Système de connaissances approfondies'' dans lequel les managers (1) reconnaissent qu’il y a un ''système'', (2) qu’ils sont en mesure de comprendre les facteurs les plus répandus et les facteurs spéciaux de variations au sein du système (la théorie des files d’attente est liée à ce phénomène de variation), (3) qu’ils sont en mesure de comprendre que les connaissances sont limitées et qu’il y a des erreurs de raisonnement, et (4) que la psychologie et les recherches en sciences sociales jouent des rôles tout à fait crédibles dans l’objectif de comprendre que les règles régissant les comportements ou en lien avec la motivation des individus ne soient pas basés sur le seul "bon sens". Le coeur de l’ouvrage tourne autour des célèbres [[Les_14_points_de_Deming|''14 points pour le management'']], y compris par exemple "''Éliminer le management par les objectifs. Éliminer le management par les nombres, par les objectifs par les nombres. Y substituer le leadership''."
* [https://www.amazon.fr/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ ''Industrial Dynamics''] de Jay Forrester est un classique du genre sur les dynamiques des systèmes, très bien écrit et très instructif. Même si cet ouvrage a été écrit au début des années 1960, il est toujours aussi pertinent aujourd’hui. Il va au-delà de la modélisation des causes à effets pour modéliser également le flux et les stocks d’informations, d’argent et de matériaux au sein d’un système. Le livre contient également une modélisation mathématique formelle de ces dynamiques, toutefois la lecture de cette dernière reste facultative pour apprécier la qualité de l’ouvrage.
* Les ouvrages [https://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226/ ''Quality Software Management: Systems Thinking''] et [https://www.amazon.fr/Introduction-General-Systems-Thinking-Weinberg/dp/0932633498/ ''An Introduction to General Systems Thinking''] de Gerald Weinberg sont intéressants. Il sont écrits du point de vue d’un consultant expérimenté en développement de systèmes.
* [https://www.amazon.fr/cinqui%C3%A8me-discipline-Levier-organisations-apprenantes/dp/2212559372/ ''La cinquième discipline''] est un autre classique du genre qui prône que l’encadrement d’une entreprise devrait appliquer l’approche systémique (autrement dit la ''cinquième'' discipline) ainsi que d’autres disciplines-clés toutes aussi importantes en vue d’obtenir une entreprise durable. Ces autres disciplines que les dirigeants devraient appliquer sont (1) une discipline personnelle, (2) une réflexion sur leurs propres croyances et raisonnements erronés, (3) la définition et la communication d’une vision partagée ayant du sens, et (4) la capacité des équipes à apprendre. Nous vous recommandons d’ignorer - du moins dans un premier temps pendant vos premières années de pratiques - le concept d’archétypes présenté dans le livre. Ce concept avait pour but d’être une aide à l’apprentissage de la cinquième discipline mais nous avons observé qu’il était soit une source de distraction soit qu’il intimidait les lecteurs quant à leur apprentissage et à l’application de la modélisation basique<ref> ‘Basique’ ne signifie pas trivial ou facile à résoudre. Par exemple, les problématiques de 'motivation' et de 'qualité' sont des problématiques basiques mais elles ne sont pas faciles à résoudre.</ref>de dynamiques des systèmes. Les ‘archétypes’ ne font pas partie à l’origine des dynamiques des systèmes.
*[https://www.amazon.fr/guide-lorganisation-apprenante-d%C3%A9velopper-lintelligence/dp/2212568711/ ''La 5ème discipline - le guide de l’organisation apprenante''] est une source extrêmement riche sur l’approche systémique écrite du point de vue des pratiquants de cette approche et de consultants.
* Les écrits d’Argyris, Outnam, McLain et Schön sur les apprentissages organisationnels comme [https://actiondesign.com/resources/readings/action-science ''Action Science''] et [http://www.amazon.com/Organizational-Learning-Addison-Wesley-Organization-Development/dp/0201001748/ ''Organizational Learning''] abordent des concepts importants tels que la ''double-boucle apprenante'' et le ''dialogue grand-plaidoyer/grand-réquisitoire''.
* Les publications et les ressources de la ''Society for Organizational Learning''](https://www.solonline.org/).

== Notes ==
<references />

LeSS - Approche systémique

2020-10-27T22:20:08Z

Nicolas Mereaux :

[[Category: Nicolas Mereaux]]
[[Category: Portail LeSS]]
[[Category: Agilité à grande échelle]]
Auteur : The LeSS Company B.V. 
Source : [https://less.works/less/principles/systems-thinking.html] 
----
Traducteur : Nicolas Mereaux 
Relecteur : Fabrice Aimetti, Christophe Gesché 
Date : 27/10/2018 
----
Traduction : 
 
[[LeSS - Portail Principes]] 
 

= Systems Thinking =

= Approche systémique =

I took a speed reading course and read “War and Peace” in twenty minutes. It involves Russia. —Woody Allen

J’ai pris un cours de lecture rapide puis j’ai lu « Guerre et Paix » en vingt minutes. Cela parle de la Russie.

“No matter what we do, the number of defects in our backlog remains about the same,” a manager told us; this for a 15 MSLOC C and C++ product with several hundred developers where we were working. What’s going on? Systems thinking may help. In small groups the forces at play are more quickly seen and informally understood, but in large product development—or any large system—it’s tough. Gerry Weinberg highlights two decisive factors in this situation:

« Quoi que nous fassions, le nombre d’anomalie dans notre ''backlog'' reste identique. » nous a dit un jour un manager en évoquant un produit de près de 15 millions de lignes de code sur lequel plusieurs centaines de développeurs étaient en train de travailler. Que pouvait-il bien se passer ? L’approche systémique peut s’avérer utile dans ce cas comme dans d’autres. En petits groupes, les forces en présence peuvent rapidement être identifiées et comprises de manière informelle, mais dans le cadre du développement d’un gros produit ou de n’importe quel gros système, c’est difficile. Gerry Weinberg met en avant deux facteurs décisifs dans ce genre de situation :

<blockquote>'''Weinberg-Brooks’ Law''': More software projects have gone awry from management’s taking action based on '''''incorrect system models''''' than for all other causes combined.

'''Causation Fallacy''': Every effect has a cause… and we can tell which is which. [http://www.amazon.com/Quality-Software-Management-Systems-Thinking/dp/0932633226/ref=sr_1_1?ie=UTF8&qid=1413527418&sr=8-1&keywords=Quality+Software+Management%3A+Systems+Thinking [Weinberg92]]
</blockquote>
<blockquote>'''Loi de Weinberg-Brooks''' : De plus en plus de projets informatiques sont partis de travers après que le management ait pris des décisions basées sur des '''modèles systémiques incorrects''' plus que pour toutes autres causes combinées.

'''Erreur de causalité''' : Chaque effet a une cause … et nous pouvons dire desquelles il s’agit. [http://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226/ref=sr_1_1?ie=UTF8&qid=1413527418&sr=8-1&keywords=Quality+Software+Management%3A+Systems+Thinking [Weinberg92]]
</blockquote>
These reflect the impact of our '''mental models''' on the system, a subject that will be revisited later in this section.

Ces deux facteurs reflètent bien l’impact de nos '''modèles mentaux''' sur le système, un sujet que nous reverrons plus tard dans cette section.

Problems stemming from mental models and assumptions are one issue. Another is that large-scale adoption of Scrum, lean thinking, and agile principles is not isolated to the development group. It bumps into product management, budgeting, beta-testing, launch, and governance and HR policies. Accordingly, in large-scale agile adoption it is useful to be able to get together with colleagues and ''effectively reason'' about the mental models, causal relations, feedback loops, and control mechanisms (or illusions of control) in a big system that is about to be seriously ''perturbed.'' Systems thinking is one of those reasoning tools.

Les problèmes résultant de nos modèles mentaux et de nos postulats sont un point à traiter. Un autre point est l’adoption à grande échelle de Scrum, de l’approche lean et des principes agiles en dehors du domaine du développement. Ce point est aussi présent dans la gestion de produit, les budgets, les tests, la commercialisation, la gouvernance et la politique RH. En conséquence, dans les adoptions agiles à grande échelle, il est utile de se réunir avec des collègues et de ''réfléchir en profondeur'' sur les modèles mentaux, les relations causales, les boucles de ''feedback'' et les mécanismes de contrôles (ou les illusions de contrôle) dans un gros système qui va être sérieusement ''pertubé''. L’approche systémique est l’un de ces outils de réflexion.

In 1958, the ''Harvard Business Review'' published [https://kupdf.com/download/industrial-dynamics-a-major-breakthrough-for-decision-makers_5902479bdc0d603940959ed5_pdf “Industrial Dynamics: A Major Breakthrough for Decision Makers,”] a landmark paper by Jay Forrester, MIT Sloan School professor. This paper spurred the movement of systems thinking in business education, and the MIT Sloan School of Management became known for educating people in '''system dynamics'''. System dynamics is sometimes treated as a synonym for '''systems thinking''' , though the latter is a more general term.

En 1958 la ''Harvard Business Review'' a publié un article de Jay Forrestor, professeur au MIT Sloan School, qui a fait date [https://kupdf.com/download/industrial-dynamics-a-major-breakthrough-for-decision-makers_5902479bdc0d603940959ed5_pdf “Industrial Dynamics: A Major Breakthrough for Decision Makers,”]. Cet article a lancé le mouvement de l’approche systémique dans le domaine des formations en gestion d’entreprise et la MIT Sloan School of Management devint célèbre pour ses formations en '''dynamique des systèmes'''. Le terme de dynamique des systèmes est parfois utilisé comme synonyme d’'''approche systémique''', même si ce dernier est un terme beaucoup plus général.

MIT also attracted other system-dynamics-oriented researchers such as Peter Senge.[https://less.works/less/principles/systems-thinking.html#footnote-1 1]

Le MIT a également attiré d’autres chercheurs intéressés par la dynamique systémique tel que Peter Senge[^1].

Consistent with ''Weinberg-Brook’s Law'', Forrester’s research showed that decision makers who were given dynamic models of a business system and asked to improve their output performance, ''usually made them run worse'' [http://www.amazon.com/The-Fifth-Discipline-Fieldbook-Organization/dp/0385472560/ref=sr_1_fkmr0_3?ie=UTF8&qid=1413528034&sr=8-3-fkmr0&keywords=The+Fifth+Discipline+%EF%BF%BCFieldbook [SKRRS94]]. The observation was that most people have weak judgement on how to fundamentally improve systems, usually applying incorrect “common sense” and quick-fix ‘solutions’ that do not create long-lasting systemic improvement.

En corrélation avec la loi de ''Weinberg-Brook'', Jay Wright Forrester a montré que les décideurs à qui il avait été donné des modèles dynamiques de systèmes opérationnels et à qui il avait été demandé d’améliorer la performance opérationnelle, ''n’avaient fait généralement qu’empirer les choses'' [https://www.amazon.fr/guide-lorganisation-apprenante-d%C3%A9velopper-lintelligence/dp/2212568711/ [SKRRS94]]. Il en est ressorti d’ailleurs que la plupart des personnes évaluaient mal la manière dont il faut améliorer les systèmes, et appliquaient généralement leur « bon sens », en mettant en place des solutions de contournement qui n’apportent aucune amélioration systémique à long terme.

Why is the behavior of a large development group (a system) not understood or guided skillfully? The answer lies, in part, in the behavior of stochastic systems with queues and variability, as explored in the [https://less.works/less/principles/queueing_theory.html Queueing Theory] LeSS principle. And the same answer lies in ''control theory'': Most systems of interest—such as a product development group—have complex positive and negative feedback loops and nonlinear behavior. The behavior of these systems defies our gut instinct. And then there is the minor issue of ''people''.

Pourquoi le comportement d’un groupe de développement de grande taille (autrement dit un système) n’est-il pas compris ou guidé de manière compétente ? La réponse réside, en partie, dans le comportement des systèmes stochastiques avec les files et les variabilités comme nous avons pu l’évoquer avec le principe LeSS de la [https://less.works/less/principles/queueing_theory.html théorie des files d’attentes]. Et c’est la même réponse qui est au cœur de la ''théorie du contrôle'' : la plupart des systèmes d’intérêt - tel qu’un groupe de développement de produit - ont des boucles de ''feedback'' positives et négatives ainsi qu’un comportement non linéaire. Le comportement de ces systèmes défient nos instincts. Et puis il y a la problématique mineure des ''gens''.

In summary, reasons for not being skillful in fathoming or guiding a big system include (but are not limited to):

En résumé, les raisons expliquants l’incompétence à maîtriser ou à guider un gros systèmes sont (liste non exhaustive) :

* lack of knowledge about the system dynamics, feedback loops, nonlinear systems behavior, and unintended consequences in workplace systems
* un manque de connaissance des dynamiques des systèmes, des boucles de ''feedback'', du comportement non linéaire des systèmes, et des conséquences inattendues dans les systèmes sur le lieu de travail.
* not understanding root causes of problems (and how to find)
* une incompréhension des causes racines des problèmes (et de comment les trouver)
** ''causes,'' not cause; in systems thinking one sees that there are multiple, indirect, and dynamic causes to problems
** ''les causes'', non la cause ; en approche systémique, nous savons que les causes des problèmes sont multiples, indirectes et dynamiques
* not knowing if or why quick-fix or local-department decisions degraded overall delivery performance.
* l’incapacité à savoir si ou pourquoi une solution de contournement ou une décision locale dégrade la performance globale opérationnelle.

In short, not being systems thinkers.[https://less.works/less/principles/systems-thinking.html#footnote-2 2]

En bref, ne pas utiliser l’approche systémique[^2].

These reasons are consequential at the intersection of management and large-scale adoption of lean and agile principles. The leadership team is part of the system being perturbed; if they do not apply systems thinking, they could ''really'' perturb it—and not in a good way!

Ces raisons sont la conséquence de l’intersection du management et de l’adoption des principes lean et agile. L’équipe de direction fait partie du système qui est pertubé ; si elle n’applique pas l’approche systémique, elle pourrait ''vraiment'' le perturber - et pas de la bonne façon.

As a summary of systems thinking insight, we like the [https://en.wikipedia.org/wiki/The_Fifth_Discipline#The_11_Laws_of_the_Fifth_Discipline 11 ‘laws’] described in [http://www.amazon.com/Fifth-Discipline-Practice-Learning-Organization-ebook/dp/B000SEIFKK/ref=sr_1_1?ie=UTF8&qid=1413531002&sr=8-1&keywords=the+fifth+discipline The Fifth Discipline]:

Les points-clés à retenir de l’approche systémique peuvent être résumé dans les [https://en.wikipedia.org/wiki/The_Fifth_Discipline#The_11_Laws_of_the_Fifth_Discipline 11 lois] décrites dans la [https://www.amazon.fr/cinqui%C3%A8me-discipline-organisations-apprenantes-dexemplaires-ebook/dp/B017WSYAHG Cinquième discipline]

* Today’s problems come from yesterday’s ‘solutions.’
* The harder you push, the harder the system pushes back.
* Behavior will grow worse before it grows better.
* The easy way out usually leads back in.
* The cure can be worse than the disease.
* Faster is slower.
* Cause and effect are not closely related in time and space.
* Small changes can produce big results…but the areas of highest leverage are often the least obvious.
* You can have your cake and eat it too—but not all at once.
* Dividing an elephant in half does not produce two small elephants.
* There is no blame.
* Les problèmes d’aujourd’hui viennent des solutions d’hier
* Plus vous poussez, plus le système pousse en retour
* Le comportement empirera d’abord avant de s’améliorer
* La manière la plus facile de s’en sortir conduit souvent à faire quelques pas en arrière
* Le médicament peut être pire que la maladie
* Plus vite c’est plus lentement
* Les causes et les effets ne sont pas étroitement liés dans l’espace et le temps
* De petits changements peuvent produire de gros résultats … mais les zones où l’effet de levier est le plus important sont souvent les moins évidentes
* Vous pouvez avoir votre gâteau et le manger aussi - mais pas en une seule bouchée
* Couper un éléphant en deux ne produit pas deux petits éléphants
* Il n’y a aucun reproche à faire

Toyota’s internal motto is [http://www.toyota-global.com/company/toyota_traditions/quality/may_jun_2005.html “Good '''thinking''', good products.”] Systems thinking is a set of ''thinking'' tools to help…

La devise de Toyota en interne est [http://www.toyota-global.com/company/toyota_traditions/quality/may_jun_2005.html « Une bonne '''réflexion''', de bons produits »]. L’approche systémique est un jeu d’outils de réflexion pour aider …

* '''see system dynamics'''—a development organization is a system of people and policies with subtle feedback loops and unintended consequences
* '''à voir les dynamiques des systèmes''' - une organisation de développement est un système de personnes et de règles avec de subtiles boucles de ''feedback'' et des conséquences inattendues
** we can learn to see and thus improve the system with '''causal loop diagrams''' created in a workshop
** nous pouvons apprendre à voir et ainsi à améliorer le système avec des '''diagrammes de boucles causales''' faits lors d’un atelier
* '''see mental models'''—one reason behind suboptimal decisions is mistaken assumptions and faulty reasoning
* '''à percevoir les modèles mentaux''' - parmi les raisons derrière des décisions sous-optimales se trouvent des hypothèses erronées et des raisonnements incorrects
** causal loop diagramming and Five Whys expose these
** les diagrammes de boucles causales et les cinq pourquoi permettent de révéler tout ça
* '''see local optimization'''—another source of suboptimal decisions is '''local optimization''' , making the ‘best’ decision from the viewpoint of a person or department, rather than '''global optimization''' for the lean systems-level goal of ''deliver value fast with high quality and high morale'' .
* '''à voir les optimisations locales''' - une autre source de décisions sous-optimales est '''l’optimisation locale''', autrement dit prendre la « meilleure » décision du point de vue d’une personne ou d’un département, au détriment d’une '''optimisation globale''' qui est l’objectif au niveau système ''lean'' que de pouvoir ''livrer la plus grande valeur possible de très grande qualité avec un moral d’acier''

This introduction is organized around the following areas in systems thinking: Learning to see (1) ''system dynamics'' , (2) ''mental models'' , (3) ''root causes'' , and (4) ''local optimization'' .

Cette introduction à l’approche systémique est présenté autour des domaines suivants : Apprendre à voir (1) ''les dynamiques des systèmes'', (2) ''les modèles mentaux'', (3) ''les causes racines'', et (4) ''l’optimisation locale''.

== Seeing System Dynamics: Introduction ==

== Voir les dynamiques des systèmes : Introduction ==

=== Static versus Dynamic Complexity ===

=== Complexité statique versus complexité dynamique ===

Many of us, especially in engineering and finance, are educated to master '''complexity of static details'''—learning to analyze and manage information (requirements, financial analysis, …), decompose complex structures into simpler ones, and so forth. That is, complexity of a static, information, or structural nature.

La plupart d’entre nous, notamment les ingénieurs et les financiers, ont été formés pour maîtriser la '''complexité de détails statiques''' - en apprenant à analyser et à gérer l’information (exigences, analyses financières, …), à décomposer des structures complexes en structures simples, et ainsi de suite. C’est-à-dire, la complexité d’une information qui est par nature structurellement statique.

Why do big software systems tend to degrade, with more and more time spent on defects? What might happen if the USA invades Iraq? Seeing the dynamics behind these questions involves analysis of the '''complexity of dynamics''' .

Pourquoi les gros systèmes informatiques ont-ils tendance à se dégrader malgré de plus en plus de temps passé sur les anomalies ? Qu’est-ce qui pourrait bien se passer si les États-Unis d’Amérique envahissait l’Irak ? Voir les dynamiques derrière ces questions implique d’analyser la '''complexité des dynamiques''' en jeu.

In contrast to static-details education, many of us receive no ''formal'' education in analyzing ''dynamics'' complexity[https://less.works/less/principles/systems-thinking.html#footnote-3 3], especially workplace dynamics. Perhaps there is a belief it is sufficient to rely on common sense in the workplace. Forrester demonstrated that “common sense” is just not so in complex systems, and showed it is possible to formally educate people to become better system dynamics thinkers in the workplace using ''dynamic system models'' visualized in ''flow diagrams'' [http://www.amazon.com/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ref=sr_1_1?ie=UTF8&qid=1413582840&sr=8-1&keywords=Industrial+Dynamics [Forrester61]].

En contraste avec une formation sur les détails statiques que la plupart d’entre nous avons suivie, peu d’entre nous ont reçu de formation sur l’étude des systèmes dynamiques et complexes[^3] et notamment en milieu professionnel. Peut-être parce que nous avons la croyance qu’il est suffisant de s’appuyer sur le bon sens en milieu professionnel. Jay Wright Forrester a démontré que le « bon sens » n’est pas suffisant dans des systèmes complexes et qu’il est possible de former des personnes pour leur permettre de mieux appréhender les dynamiques des systèmes en milieu professionnel en utilisant notamment des ''diagrammes de flux'' [http://www.amazon.fr/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ref=sr_1_1?ie=UTF8&qid=1413582840&sr=8-1&keywords=Industrial+Dynamics [Forrester61]].

Flow diagrams encompass material, financial, and information flows, stocks (variables with a quantity, such as cash or number of defects), the impact of decisions and policies, and cause-effect relations. A popular simplification is the '''causal loop diagram''' that focuses on cause-effect relationships and feedback loops in a system [http://www.amazon.com/Business-Dynamics-Systems-Thinking-Modeling/dp/0071179895 [Sterman00]]. There are a variety of similar notations; they all show stocks (variables), causal links, and delay. In [http://www.amazon.com/Quality-Software-Management-Systems-Thinking/dp/0932633226/ref=sr_1_1?ie=UTF8&qid=1413527418&sr=8-1&keywords=Quality+Software+Management%3A+Systems+Thinking [Weinberg92]] this is called the ''diagram of effect'' .

Les diagrammes de flux peuvent s’appliquer aussi bien aux flux matériels, financiers, d’informations, de stocks (n’importe quel type de stock quantitatif comme de l’argent ou des anomalies), aux conséquences des décisions et des politiques et des relations de causes à effet. Lorsque nous pensons aux diagrammes de flux, nous pensons souvent au seul diagramme de boucle causale dédié aux relations de cause à effets et aux boucles de rétroaction dans un système [http://www.amazon.fr/Business-Dynamics-Systems-Thinking-Modeling/dp/0071179895 [Sterman00]]. Il existe une grande variété d’autres diagrammes qui peuvent faire figurer les stocks (quels qu’ils soient), les liens de causalités, et les retards. Dans son ouvrage, [http://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226/ref=sr_1_1?ie=UTF8&qid=1413527418&sr=8-1&keywords=Quality+Software+Management%3A+Systems+Thinking [Weinberg92]] Gerald Weinberg appelle cela un ''diagramme d’effet''.

=== The First Law of Diagramming: Model to Have a Conversation ===

=== La première loi de la réalisation d’un diagramme : nous modélisons pour avoir une conversation ===

A tool to learn to see system dynamics is a causal loop diagram, ideally sketched on a whiteboard in a LeSS Overall Retrospective with colleagues. Before going further, here is the ''First Law of Diagramming''

Un outil très utile pour apprendre les dynamiques des systèmes est le diagramme de boucles causales - nous vous recommandons de l’utiliser sur un tableau blanc notamment lors des Rétrospectives Globales LeSS. Mais avant d’aller plus loin, voici la ''première loi de réalisation d’un diagramme''.

<blockquote>'''The primary value in diagrams is in the discussion while diagramming—we model to have a conversation.'''
</blockquote>
<blockquote>'''La première valeur d’un diagramme c’est la discussion qui se déroule lors de la réalisation du diagramme - nous modélisons pour avoir une conversation.'''
</blockquote>
When a group gets together to sketch a causal loop diagram on a whiteboard (See it is the the acts of discussing and thinking that are most important when diagramming, Valtech India.), the primary value is the conversation and shared understanding they arrive at while creating the model. Its visualization as an easy-to-see diagram ''is'' important to make concrete and unambiguous (on the whiteboard) the ideas—the mental models people have—because words alone can be fuzzy and misunderstood. But still, the diagram is secondary to what people take away: learning and a revised understanding through a discussion.

Lorsqu’un groupe se rassemble pour dessiner un diagramme de boucles causales sur un tableau blanc (« C’est l’acte de discuter et de réfléchir qui est le plus important lorsque nous dessinons », Valtech India.), la première valeur d’un diagramme c’est la conversation et la compréhension commune à laquelle les personnes arrivent lors de la création du modèle. Ce qu’il en résulte à savoir un diagramme facile à comprendre est important pour rendre les idées et les modèles mentaux concrets et non ambigües (sur le tableau blanc) parce que les mots seuls peuvent être imprécis et mal compris. Toutefois, le diagramme est secondaire par rapport avec ce que les gens repartent : ils ont appris quelque chose et ont revu leur compréhension du monde à travers une discussion.

[[File:https://less.works/img/systems-thinking/xgroup,P20cld,P20modeling.jpg.pagespeed.ic.lirKMzwWbD.webp|frame|none|alt=|caption group%20cld%20modeling.jpg]]

''Doing system thinking. Sketching a causal loop diagram together—modeling to have a conversation.''

[[File:Xgroup-cld-modeling.jpg|frameless|848px|Un atelier d’approche systémique : réalisation d’un diagramme de boucles causales à plusieurs - modéliser pour avoir une conversation]]

''Un atelier d’approche systémique : réalisation d’un diagramme de boucles causales à plusieurs - modéliser pour avoir une conversation.''

''Concrete modeling tip'' : We start by writing on sticky notes to define ''variables'' . A note might read “feature velocity” or “# defects.” We place these on a whiteboard. Then we sketch causal link lines between the sticky notes. There will be (or should be) lots of rewriting, erasing, and redrawing during the modeling session. The most meaningful outcome is ''understanding'' ; in addition, some participants will want to take a digital photo of the whiteboard sketch.

''Trucs et astuces de pro pour modéliser'' : Nous commençons par écrire sur des petits papiers repositionnables les noms des ''variables'', par exemple « vélocité des ''features'' » ou « nombre d’anomalies ». Nous les plaçons ensuite sur le tableau blanc. Puis nous dessinons les liens de causalités entre les papiers . Il y aura (ou il devrait y avoir) beaucoup de réécriture, d’effaçage, de redessin lors de la session de modélisation. Le résultat le plus important d’une telle session est la ''compréhension'' - il se peut qu’à l’issue de cet atelier, certains participants voudront prendre une photo du dessin du tableau blanc.

== Seeing System Dynamics: Causal Loop Diagrams ==

== Voir les dynamiques des systèmes : les diagrammes de boucles causales ==

Causal loop diagrams are used regularly in introductions to LeSS, to help see the dynamics of what is going on in large-scale development. It is useful to understand them for that reason alone. And more useful to you, we recommend you do these together with colleagues at a whiteboard. Model to have a conversation. When? Probably during a LeSS Overall Retrospective.

Les diagrammes de boucles causales sont souvent utilisés en introduction à LeSS pour aider à voir les dynamiques de ce qu’il se passe dans du développement à grande échelle. Il est donc utile de comprendre ce type de diagrammes pour cette seule et unique raison. Et cela s’avèrera encore plus utile pour vous, si vous le faites avec vos collègues devant un tableau blanc. Vous modélisez pour avoir une conversation. Quand ? Plus probablement lors d’une rétrospective globale LeSS.

The practical aspect of this tip is more important than may first be appreciated. It is vague and low-impact to suggest “be a systems thinker.” But if you and four colleagues get into the habit of standing together at a large whiteboard, sketching causal loop diagrams together, then there is a concrete and potentially high-impact practice that connects “''be'' a systems thinker” with “''do'' systems thinking.”

L’aspect pratique de cet exercice est bien plus important que ce qu’il peut paraître au premier abord. Notre conseil d’« être un pratiquant systémique » peut vous sembler vague et sans grand impact. Mais si vous et quatre de vos collègues prenez l’habitude de vous réunir devant un grand tableau blanc, en dessinant des diagrammes de boucles causales ensemble, alors vous arriverez à faire la connexion entre « ''être'' un pratiquant systémique » avec « ''faire'' de l’approche systémique ».

The following examples seem sterile when presented in a book. But imagine you were at a whiteboard with other people and the diagrams were being sketched during a lively conversation. That’s the way we suggest ‘doing’ systems thinking.

Les exemples suivants peuvent paraître stériles car présentés dans un livre. Mais imaginez-vous à côté d’un tableau blanc avec d’autres personnes dessinant ensemble des diagrammes au cours d’une conversation animée. C’est de cette manière-là que nous suggérons de ‘ faire ’ de l’approche systémique.

====== Notation and Examples ======

====== Notation et exemples ======

Causal loop diagrams contain many elements; the following common useful subset is explored through a scenario.

Les diagrammes de boucles causales contiennent beaucoup d’éléments ; les éléments suivants sont les plus communément utilisés et sont vus en détail tout au long du scénario qui va suivre

* variables
* causal links
* opposite effects
* constraints
* goals
* reactions; quick-fix reactions
* interaction effects
* extreme effects
* delays
* positive feedback loops
* variables
* liens de causalité
* effets opposés
* contraintes
* objectifs
* réactions ; réactions solutions de contournement
* effets d’interaction
* effets extrêmes
* retards
* boucles de ''feedback'' positives

''The following simplified scenario is for a particular organization. It is not a generalization.''

''Le scénario qui suit est un scénario simplifié pour une organisation spécifique. Il ne s’agit pas d’une généralisation.''

'''Variables'''—Causal loop diagrams include ''variables'' (or stocks) such as the ''velocity (rate of delivery) of software features'' and ''number of defects'' . Variables have a measurable quantity.

'''Les variables''' - Les diagrammes de boucles causales comportent des ''variables'' (ou des stocks) telle que la ''vélocité (taux de livraison) des features'' et le ''nombre d’anomalies''. Les variables ont une quantité mesurable.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-4.png.pagespeed.ic.WpO9GKmuZP.webp|frame|none|alt=|caption systems thinking-4.png]]

[[File:Xsystems-thinking-4-fr.png|frameless|848px|1er schéma]]

'''Causal links'''—An element can have an effect on another, such as if feature velocity increases, then the number of defects increase; that is, more new code, more defects.

'''Les liens de causalité''' - Un élément peut avoir un effet sur un autre, comme par exemple si la vélocité des ''features'' augmente alors le nombre d’anomalies augmente ; autrement dit, plus de code, plus d’anomalies.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-5.png.pagespeed.ic.oPRro2SqND.webp|frame|none|alt=|caption systems thinking-5.png]]

[[File:Xsystems-thinking-5-fr.png|frameless|848px|2ème schéma]]

Now it is time to bump into ''Weinberg-Brook’s Law'' and the ''Causation Fallacy'' . It is easy to sketch a diagram; it is something else to model with insight. For example, consider the relationship between the ''number of developers'' and ''feature velocity.''

Il est temps désormais de se jeter à corps perdu dans la ''loi de Weinberg-Brooks'' et dans la ''causalité fallacieuse''. C’est facile de dessiner un diagramme, ça l’est moins que de modéliser en faisant preuve de clairvoyance comme par exemple, la relation entre le ''nombre de développeurs'' et la ''vélocité des features''.

The nature of any cause-effect relationship is actually not obvious, though it is common for people to jump to conclusions such as more developers means better velocity. Adding people late in development may ''reduce'' velocity (a sub-element of “Brooks’ Law” [Brooks95]). Or, ''more'' bad programmers could really slow you down. An argument can be made that ''removing'' terrible developers can ''improve'' velocity.

Toute relation de cause à effets est par nature obscure, même si les gens ont l’habitude de sauter sur la première conclusion venue comme par exemple plus de développeurs égale plus de vélocité. Ajouter des personnes tard au cours du développement peut ''réduire'' la vélocité (il s’agit d’une composante de la « loi de Brooks » [Brooks95]). Ou, ''davantage'' de mauvais développeurs pourrait vraiment vous ralentir. Il pourrait être objecté qu’''enlever'' des développeurs exécrables peut permettre ''d’améliorer'' la vélocité.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-6.png.pagespeed.ic.6XIYl7Vm3_.webp|frame|none|alt=|caption systems thinking-6.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-6-fr.png|frame|none|alt=|caption systems thinking-6.png]]

[[File:Xsystems-thinking-6-fr.png|frameless|848px|3ème schéma]]

'''Opposite effects'''—A causal link effect may be the same or opposite direction; if A goes up then B goes up, or vice versa. Opposite effect is shown with an ‘O’ on the line. Suppose defects going up puts a drag on the system, lowering the velocity of new features because people spend more time fixing or working around bugs.

'''Effets opposés''' - L’effet d’un lien de causalité peut aller dans la même direction ou dans la direction opposée. Si A monte alors B monte ou vice versa. L’effet opposé se souligne à l’aide d’un ‘0’ sur la ligne. Supposons que les anomalies ralentissent grandement le système, réduisant la vélocité des nouvelles ''features'' parce que les gens passent plus de temps à corriger ou à trouver des solutions de contournement aux anomalies.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-7.png.pagespeed.ic.DPGMJyX2Qf.webp|frame|none|alt=|caption systems thinking-7.png]]

[[File:Xsystems-thinking-7-fr.png|frameless|848px|4ème schéma]]

'''Constraints'''—Unless you can find people to work for free, there is a constraint on the number of developers, based upon cash supply.

'''Contraintes''' - À moins que vous ne trouviez des personnes prêtent à travailler gratuitement, il y a une contrainte sur le nombre de développeurs basé sur le budget disponible.

Constraints are ''not'' causal links. As cash supply goes up, it is not the case that the number of developers goes up.

Les contraintes ne sont ''pas'' des liens de causalité. Lorsque la montant du budget disponible augmente, ce n’est pas le cas du nombre de développeurs/

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-8.png.pagespeed.ic.gbgAIK-IsZ.webp|frame|none|alt=|caption systems thinking-8.png]]

[[File:Xsystems-thinking-8-fr.png|frameless|848px|5ème schéma]]

'''Goals and Reactions'''–People, departments, and systems have goals, such as ''higher feature velocity'' . Goals often generate pressure for people to react (or act), with the intent of achieving the goal. But since there is ''Causation Fallacy'' and ''Weinberg-Brooks’ Law'' to contend with, people should be cautious about assuming what actions will help. Now a goal and pressure for reaction is shown:

'''Buts et réactions''' - Les personnes, les départements et les systèmes ont des buts, comme par exemple avoir une ''vélocité des features plus élevée''. Les buts occasionnent souvent de la pression pour que les gens réagissent (ou agissent) dans l’intention de leur faire atteindre ce but. Mais étant donné qu’il y a la ''causalité fallacieuse'' et la ''loi de Weinberg-Brooks'' à laquelle il faut faire face, les gens devraient être prudents quant aux actions pertinentes à entreprendre. Voici un exemple de diagramme modélisant cela :

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-9.png.pagespeed.ic.yVcHbh4_-i.webp|frame|none|alt=|caption systems thinking-9.png]]

[[File:Xsystems-thinking-9-fr.png|frameless|848px|6ème schéma]]

Not only does a goal with a ''reward'' create pressure to act, but also it creates pressure to ''appear'' to be acting and achieving, due to the '''measurement dysfunction''' generated by rewards. And the measurement dysfunction can be proportional to the perceived value of the reward because people are being motivated to get a reward, not to improve the system [http://www.amazon.com/Measuring-Managing-Performance-Organizations-Dorset-ebook/dp/B00DY3KQX6/ref=sr_1_1?ie=UTF8&qid=1413596674&sr=8-1&keywords=measuring+and+managing+performance+in+organizations [Austin96]]. Notice how rewards can actually degrade system performance. Visually, the system dynamics may be…

Non seulement un but à atteindre avec une ''récompense'' au bout engendre une pression à agir, mais cela créé aussi une pression à ''faire semblant'' d’agir et à atteindre le but — les récompenses provoquent un '''dysfonctionnement des indicateurs'''. Le dysfonctionnement des indicateurs peut être proportionnel à la valeur perçue de la récompense parce que les personnes sont motivées pour avoir la récompense, non pour améliorer le système [http://www.amazon.fr/Measuring-Managing-Performance-Organizations-Dorset-ebook/dp/B00DY3KQX6/ref=sr_1_1?ie=UTF8&qid=1413596674&sr=8-1&keywords=measuring+and+managing+performance+in+organizations [Austin96]]. Remarquez bien comment et de quelle manière les récompenses peuvent dégrader la performance du système. De manière visuelle, les dynamiques d’un tel système pourrait être …

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-10.png.pagespeed.ic.39CLFp-g_9.webp|frame|none|alt=|caption systems thinking-10.png]]

[[File:Xsystems-thinking-10-fr.png|frameless|848px|7ème schéma]]

It is quite interesting that all these dynamics have been added by introduction of reward, and yet there is no necessary connection between the top part of this model and the bottom.

Il est assez intéressant de voir que toutes ces dynamiques ont été ajouté par l’introduction d’une récompense et qu’il n’y pas de connexion entre le haut et le bas de cette modélisation.

There is no guarantee that feature velocity has improved—or even been worked on.

Il n’y a aucune garantie que la vélocité des features s’améliore ou même que l’on y travaille.

Removing the reward system is a root-cause solution to the dysfunction. Another (lesser) surface countermeasure is the lean-thinking ''Go See'' (go see physically at the place of real work) principle and management behavior:

Enlever le système de récompense est une solution à la cause racine de ce dysfonctionnement. Une autre contremesure de surface est le principe et le comportement managériale ''Aller voir'' (aller voir physiquement sur le lieu où le travail s’effectue) de l’approche lean.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-11.png.pagespeed.ic.NU8SjnJkUY.webp|frame|none|alt=|caption systems thinking-11.png]]

[[File:Xsystems-thinking-11-fr.png|frameless|848px|8ème schéma]]

'''Quick-fix reactions'''—One difficult and slow solution toward the goal of higher velocity is to hire great developers, to increase coaching and education of existing staff, and to remove terrible workers. The alternative is called a ''quick fix'' , a reaction that is hoped to achieve the goal quickly and with less effort. Sometimes a quick fix works well both in the short and long term, really strengthening the system. Sometimes not…hence, “faster is slower.” For example, people may ''believe'' that increasing the number of developers increases the feature velocity. And they may thereby hope that hiring more developers will most quickly and easily solve the velocity problem. ‘QF’ indicates the quick fix:

'''Solutions de contournement''' - Une solution payante à long terme pour atteindre une vélocité plus grande, qui n’est pas sans difficulté, consiste à : recruter de développeurs très qualifiés, faire davantage d’accompagnements et de formations, et à se séparer des moins bons éléments. L’alternative est ce que l’on appelle une ''solution de contournement'', c’est ce que l’on met en place dans l’espoir d’atteindre l’objectif en moins de temps et avec moins d’effort. Parfois, une solution de contournement se révèle payante aussi bien dans le court terme que dans le long terme, renforçant par la-même le système. D’autres fois cela ne fonctionne pas … d’où l’expression « aller plus vite c’est aller plus lentement ». Par exemple, les gens peuvent ''croire'' qu’augmenter le nombre de développeurs permet d’augmenter la vélocité des features. Et ils peuvent par conséquent être amenés à espérer qu’en recrutant davantage de développeurs cela permettra de résoudre plus vite et plus facilement le problème de vélocité. La mention ‘SC’ sur le diagramme ci-dessous indique une solution de contournement.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-12.png.pagespeed.ic.x8IJWKprUx.webp|frame|none|alt=|caption systems thinking-12.png]]

[[File:Xsystems-thinking-12-fr.png|frameless|848px|9ème schéma]]

'''Interaction effects'''—There is the constraint of cash supply on hiring. One hard and slow solution is to get more cash. A quicker fix is to hire ''much'' cheaper developers. In this case, the level of cash supply now has an ''interaction effect'' with other causal links. Low cash tends to strengthen the hire rate of much cheaper developers when there is pressure to increase hire rates.

'''Effets d’interaction''' - La capacité à embaucher est contraint à la capacité budgétaire. Une solution de longue haleine non sans difficulté est d’obtenir davantage de budget. Une solution de contournement possible est de recruter un ''grand'' nombre de développeurs bon marché. Dans ce cas, le niveau du budget a un ''effet d’interaction'' avec les autres boucles causales. Un budget peu élevé aura tendance à renforcer le taux de développeurs bon marché si la pression pour recruter augmente.

One could simply draw an (opposite) causal link directly from ''cash supply'' to ''hire rate of very cheap developers'' , but that merely says that less cash leads to more hiring of extremely cheap developers. That is not quite what we want to say; rather, we want to show the interaction effect—that effect A influences ''effect'' B. This is done by showing a causal link entering another causal link. For example, from ''cash supply'' to the quick-fix line going into ''hire rate of very cheap developers'' :

Nous pourrions dessiner simplement un lien de causalité (opposé) de ''rentrée budgétaire'' à ''taux de recrutement de développeurs bon marché'', mais cela voudrait simplement dire qu’avoir un budget moindre aurait pour conséquence de recruter davantage de développeurs bon marché. Mais ce n’est pas tout à fait ce que nous voulons dire ; ce que voulons montrer en fait, c’est l’effet d’interaction - c’est-à-dire qu’un effet A influence un ''effet'' B. Cela se fait en montrant un lien de causalité heurtant un autre lien de causalité, par exemple en traçant une ligne de ''rentrée budgétaire'' vers la ligne représentant la solution de contournement qui va vers ''taux de recrutement de développeurs bon marché''.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-13.png.pagespeed.ic.LvAE8ewRFJ.webp|frame|none|alt=|caption systems thinking-13.png]]

[[File:Xsystems-thinking-13-fr.png|frameless|848px|10ème schéma]]

'''Extreme effects'''—We have worked with some very inexpensive developers with excellent skill and some very expensive developers that are terrible, but on average, you get what you pay for—when you hire from a large pool of very cheap labor, the average skill level is lower. In the model we want to show that the impact of hiring very cheap labor on the ''number of low-skilled developers'' is a significantly greater effect than average.

'''Effets extrêmes''' - Il nous est arrivé de travailler avec d’excellents développeurs très bon marché et avec d’autres hors de prix très nuls, mais en moyenne, vous obtenez à hauteur de ce que vous payez - lorsque vous recrutez au moins disant, le niveau moyen en terme de compétences sera plus faible. Dans le diagramme ci-dessous, nous avons voulu montrer que l’impact du recrutement de personnes bon marché en rapport avec le ''nombre de développeurs peu qualifiés'' à un impact sensiblement plus grand que la moyenne.

To show an ''extreme effect'' in the model, use a thick line:

Pour montrer un ''effet extrême'' sur un modèle, faites un trait épais comme vous pouvez voir ci-dessous :

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-14.png.pagespeed.ic.JYkqz8Qe24.webp|frame|none|alt=|caption systems thinking-14.png]]

[[File:Xsystems-thinking-14-fr.png|frameless|848px|11ème schéma]]

'''Delays'''—One problem in hiring in software development is the ''fallacy of mild programmer variance'' —the mistaken belief that programmer variance (in terms of productivity, code quality, etc.) is relatively small. However, programmer variance studies suggest an average of four times faster in the top versus bottom quartile [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.4788 [Prechelt00]]. Rather significant. Also, the COCOMO model—based on large and longitudinal studies—shows that the capability of the development personnel is by far the most important factor for productivity [http://www.amazon.com/Software-Cost-Estimation-Cocomo-II/dp/0130266922/ref=sr_1_1?ie=UTF8&qid=1413597244&sr=8-1&keywords=Software+Cost+Estimation+with+Cocomo+II [Boehm00]]. And, on average, very weak programmers create poor-quality code (poor design) and more defects, creating another drag on the system.

'''Retards''' Un problème courant au niveau du recrutement dans un projet de développement logiciel concerne ''l’erreur au niveau de la variance d’un développeur moyen'' - autrement dit la croyance fausse que la variance d’un développeur à un autre (en terme de productivité, de qualité de code, etc.) est relativement faible. Toutefois, les études de la variance au sujet des développeurs montrent un rapport de un à 4 entre le 1er quartile et le dernier [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.4788 [Prechelt00]]. C’est plutôt quelque chose de significatif. De même des études - en long et en large - du modèle COCOMO montrent que la capacité du développement personnel est le facteur de loin le plus important quant à la productivité [http://www.amazon.com/Software-Cost-Estimation-Cocomo-II/dp/0130266922/ref=sr_1_1?ie=UTF8&qid=1413597244&sr=8-1&keywords=Software+Cost+Estimation+with+Cocomo+II [Boehm00]]. Et, en moyenne, il s’avère que les développeurs peu qualifiés font du code de mauvaise qualité (mauvaise conception) et de plus d’anomalies, ceci rajoute un autre frein au système.

But the impacts of these effects are not immediately obvious. For example, it takes a relatively long time after hiring a large pool of weak programmers before the impacts of more and more bad code/design start to be felt. Similarly, the average ''decrease'' in feature velocity (because of the powerful impact of programmer variance) will not show up immediately.

Mais l’impact de ces effets ne sont pas visibles immédiatement. Par exemple, cela peut prendre un certain temps après un recrutement massif de développeurs peu qualifiés avant que les impacts négatifs ne se fassent sentir au niveau de la qualité du code ou de la conception. De manière similaire, la ''baisse'' moyenne de la vélocité des features (en raison de l’impact important de la variance des développeurs évoqué plus haut) ne se verra pas immédiatement.

To show these ''delayed effects'' in the model, use a double-line through the effect line:

Pour montrer ces ''effets à retardement'' dans le modèle, faites une double-ligne en travers de la ligne d’effet.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-15.png.pagespeed.ic.0fwliLJm6G.webp|frame|none|alt=|caption systems thinking-15.png]]

[[File:Xsystems-thinking-15-fr.png|frameless|848px|12ème schéma]]

Delay has an intriguing influence on the ''educational'' or corrective power in a system. If an impact or unintended consequence is long delayed, one does not feel the effect (pain or gain) and so does not clearly see how A influenced B, or more subtly how ''A influenced B influenced A'' .

Le retard a une influence intéressante sur le pouvoir ''pédagogique'' ou correctif sur un système. Si un impact ou une conséquence inattendue est retardé suffisamment longtemps, personne n’en voit ni l’effet (qu’il soit bénéfique ou néfaste) ni sur la façon dont A influence B ou plus subtilement comment ''A a influencé B qui a influencé A''.

Therefore, one does not learn from or correct mistakes—in policy, management actions, tools, and so forth. Likewise, gradual improvement through the lean thinking practice of ''kaizen'' can take a long time; patience and insight are needed to see if and how things improve.

Par conséquent, personne n’apprend de ses erreurs ni n’est en capacité de les corriger - que ce soit en terme de stratégie, d’actions d’encadrement, d’outils ou de quoi que ce soit. De la même manière, l’amélioration graduelle à travers l’application d’une démarche lean ''kaizen'', peut prendre un certain temps ; de la patience et de la perspicacité sont nécessaires pour voir si et comment les choses s’améliorent.

'''Positive feedback loops'''—Negative or positive feedback loops[https://less.works/less/principles/systems-thinking.html#footnote-5 5] and delays are where things start to get more subtle in a system—and in understanding a system. For example, how does one become a better programmer? In part, by mentoring from great programmers and seeing lots of examples of great code. But an office with a lot of low-skill developers does not generate a lot of great code examples, nor does it attract or retain the small pool of great programmers who could act as mentors. They would rather work somewhere else.

'''Boucles de feedback positives''' - Les boucles de feedback négatives ou positives [^5] et les retards sont le point de départ pour une approche plus subtile d’un système - et de sa compréhension. Par exemple, de quelle manière une personne peut-elle devenir un meilleur développeur ? En partie, en bénéficiant du mentorat de très bons développeurs et en jetant un œil sur du très bon code. Mais il est impossible de trouver du bon code dans un endroit remplit de développeurs médiocres, il est impossible également d’y attirer ou de retenir le petit groupe de très bon développeurs qui pourraient prendre le rôle de mentors. Ils préfèrent largement aller travailler ailleurs.

Now the development group starts to enter a self-reinforcing downward spiral—a set of ''positive feedback loops'' . Fortunately, the downward trend is constrained by the supply of cash.

Ce groupe de développeurs médiocres rentrent dans un cercle vicieux en raison d’un ensemble de ''boucles de feedback positives''. Fort heureusement, ce cercle vicieux est assujeti aux contraintes du budget.

More great programmers—who could craft great code and mentor others—leave. So there is less and less quality code to look at and to learn from. The percentage of weak programmers grows even larger and feature velocity drops further. Code becomes more messy, awkward, and duplication-riddled, so the capacity to swiftly implement features declines. Since feature velocity is dropping further, there is more pressure to hire yet more very cheap programmers. All this leads to multiple positive reinforcement loops in the system, for example:

Malheureusement de plus en plus des très bons développeurs - ceux en capacité d’élaborer du très bon code et de faire du mentorat auprès des autres développeurs - partent. Par conséquent, il y a de moins en moins de code de qualité à regarder et à partir duquel il est possible d’en tirer des enseignements. Le pourcentage de développeurs médiocres augmente de plus en plus et la vélocité au niveau des features continue à chuter. Le code devient de plus en plus brouillon, difficile, avec pleins de bouts de code dupliqués à gauche et à droite, le tout de telle manière que la capacité d’implémenter des features décline. Étant donné que la vélocité des features continue de chuter, il y a davantage de pression pour recruter des développeurs très bon marché. Tout cela conduit à de multiples boucles de renforcement positives dans le système comme l’illustre l’exemple ci-dessous :

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-16.png.pagespeed.ic.ONFuUmJHSE.webp|frame|none|alt=|caption systems thinking-16.png]]

[[File:Xsystems-thinking-16-fr.png|frameless|848px|13ème schéma]]

''Tip'' : You can find positive feedback loops by finding cycles with an ''even number'' of ‘Opposite’ effect relationships. There are several examples in the model above.

''Astuce'' : Vous pouvez trouver des boucles de feedback positives en cherchant des cycles ayant un ''nombre pair'' de relations. Vous en trouverez plusieurs exemples ci-dessus.

===== Conclusion =====

===== Conclusion =====

The example scenario is only that—an example. A causal loop diagram can visualize rich dynamics in a workplace system. These are best created by a group at a whiteboard.

Le scénario donné à titre d’exemple est uniquement cela - un exemple. Une diagramme de boucle causale permet de visualiser la richesse de la dynamique dans le système dans un milieu professionnel. La meilleure manière de modéliser un tel système est de le faire en groupe face à un tableau blanc.

== Seeing Mental Models ==

== Voir les modèles mentaux ==

The previous causal loop diagrams reflect people’s mental models of causation, which may be wrong. It is interesting to note that people’s models of causation are influenced by the timeliness (delay) and quality of feedback in the system.

Les précédents diagrammes de boucles causales reflètent les modèles mentaux de causalité des individus … qui peuvent s’avérer faux. Il est intéressant de remarquer que les modèles de causalité des individus sont influencés par la ponctualité (ou les retards) et la qualité des feedbacks dans le système.

The implication of “mental models” is to improve our meta-cognitive skill to see and question our own assumptions and chains of reasoning. Are we making faulty leaps of logic? It also implies when working with others to discuss (inquiring rather than abusing) the mental models of our colleagues.

Les « modèles mentaux » nous permettent d’améliorer nos compétences de méta-cognition pour voir et questionner nos propres postulats et l’enchaînement de nos raisonnements. Brûlons-nous des étapes de manière erronée ? Cette question implique aussi lorsque nous sommes en train de travailler avec des collègues de discuter avec eux (en s’enquérant plutôt qu’en reprochant) de leurs modèles mentaux.

''Seeing'' these mental models is step one; ''changing'' them is the even harder part of step two. That art is beyond the scope of this introduction, though a successful LeSS adoption must involve changes in mindset and insight among many groups.

''Voir'' les modèles mentaux n’est que la première étape ; les ''changer'' constitue une seconde partie bien plus difficile. Cet art est bien au-delà du sujet de cette introduction, même si une adoption réussie de LeSS implique des changements en terme d’état d’esprit et de prise de conscience au sein de très nombreuses équipes.

A tip to better ''see'' the mental models (beliefs, chains of inference, …) playing out in the system dynamics is to ask the following question during a modeling workshop and then sketch the answers. “Let’s talk about the assumptions behind this model. What do we ''believe'' or assume in terms of facts and effects that led us here?”

Une astuce pour mieux ''voir'' les modèles mentaux (croyances, échelle d’inférence, …) en jeu au niveau des dynamiques des systèmes est de poser les questions suivantes lors d’un atelier de modélisation puis de tracer les éléments de réponse au tableau blanc. « Parlons donc des hypothèses derrière ce modèle. Que ''croyons''-nous ou tenons pour acquis en terme de faits et d’effets qui nous ont conduits ici ? »

Answers are sketched on the whiteboard model, for example:

Les éléments de réponse sont dessinés sur le tableau blanc. En voici un exemple :

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-17.png.pagespeed.ic.5UIqBnJfK1.webp|frame|none|alt=|caption systems thinking-17.png]]
Visualizing the assumptions in our heads… our mental models.

[[File:Xsystems-thinking-17-fr.png|frameless|848px|14ème schéma]]
''Visualiser les postulats présents dans nos têtes … nos modèles mentaux.''

=== Example: The “Faster is Slower” Dynamic ===

=== Exemple : La dynamique « Aller plus vite c’est aller plus lentement » ===

With the vocabulary of quick fixes, delays, positive feedback loops, and mental models, it is fascinating to see that there can be a short-term apparent improvement in a variable as the result of a quick fix, but a ''delayed degradation'' of the very same variable—the “faster is slower” dynamic. This is a recurrent dynamic in the workplace and a cause of weakness. So it is worth another illustration.

Dorénavant, avec notre vocabulaire enrichi des termes de solutions de contournement, de boucles de feedback positives et de modèles mentaux, il est fascinant de voir qu’il peut y avoir un semblant d’amélioration à court terme sur une variable donnée, mais que cela entraîne en même temps une ''dégradation à retardement'' de cette même variable - d’où la dynamique « Aller plus vite c’est aller plus lentement ». Il s’agit d’une dynamique récurrente et d’une cause de vulnérabilité à terme. Voici un nouvel exemple illustrant cela :

''The story of Microsoft Word and the'' '''''secret developer toolbox''''' : A classic example of the short-term ‘improving’ but long-term degrading dynamic is the story of the first release of Microsoft Word for Windows [http://www.amazon.com/Joel-Software-Occasionally-Developers-Designers/dp/1590593898/ref=sr_1_1?ie=UTF8&qid=1413597951&sr=8-1&keywords=Joel+on+Software [Spolsky04]]. It was released ''years'' later than desired. Why? ''Because managers tried to follow the original schedule and pushed developers to meet it'' .

''Histoire de Microsoft Word et de'' '''''la boîte à outils secrète du développeur''''' : Un exemple typique d’une ‘amélioration’ à court terme mais d’une dynamique de dégradation à long terme est le récit de la première livraison de Microsoft Word sur Windows [http://www.amazon.com/Joel-Software-Occasionally-Developers-Designers/dp/1590593898/ref=sr_1_1?ie=UTF8&qid=1413597951&sr=8-1&keywords=Joel+on+Software [Spolsky04]]. Le logiciel a été livré avec des ''années'' de retard par rapport à la date prévue. Pourquoi ? ''Parce que les managers ont essayé à tout prix de suivre le calendrier de départ et ont fait pression sur les développeurs pour le respecter''.

The story illustrates why ''wishful thinking'' is identified as one of the wastes in lean thinking. In this case the wishful thinking of insisting on (apparently) following a schedule, which implies the misconception or wishful thinking that development estimates are not estimates but are commitments—a common myth that propels degradation of a system.

Cette histoire illustre pourquoi cet espoir illusoire de respecter une date souhaitée est bien identifié comme une source de gâchis dans l’approche lean. Dans le cas présent l’espoir illusoire consiste à insister (du moins apparemment) à suivre le calendrier, ce qui implique une idée fausse ou illusoire que les estimations ne sont pas de simples estimations mais des promesses - un mythe classique qui pousse à la dégradation d’un système.

[https://less.works/less/principles/systems-thinking.html#figure-1 The next model] illustrates a ''summary'' of the dynamics of what happened when the managers pushed people to evidently keep to the original schedule, and why this quick-fix reaction to slow progress appeared to make things faster in the short term but actually even ''slower'' in the long term. See the dynamic of schedule pressure and the secret toolbox. intentionally omits some deeper dynamics that are expanded and shown in See deeper dynamics of schedule pressure and the secret toolbox..

[https://less.works/less/principles/systems-thinking.html#figure-1 Le modèle suivant] illustre un ''résumé'' des dynamiques à l’œuvre lorsque des managers poussent leurs équipes à respecter à tout prix les calendriers prévisionnels, et pourquoi cette solution de contournement qui freine pourtant l’avancement des travaux semblent les faire aller plus vite à court terme mais en réalité ''plus lentement'' à long terme. Par rapport à ce qui est décrit précédemment dans la dynamique de la pression du calendrier et la boîte à outils secrète, certaines dynamiques ont été omises intentionnellement sur ce schéma et sont visibles sur le schéma dynamiques avancées.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-18.png.pagespeed.ic.A7OSuu755I.webp|frame|none|alt=|caption systems thinking-18.png]]
The dynamic of schedule pressure and the secret toolbox.

[[File:Xsystems-thinking-18-fr.png|frameless|848px|15ème schéma]]
''Dynamique de la pression sur le calendrier et de la boîte à outils secrète.''

As a quick fix, the Microsoft managers exhorted, bribed (with potential rewards), and threatened the Word developers to keep to the original schedule. Consequently, the developers predictably pulled out their '''secret developer toolbox''' —the many practices related to hacking out dirty code (no tests, no reviews, ignore known defects, copy-paste programming, poor design, …) to apparently deliver a feature faster. You see, developers also have ''quick-fix'' reactions for their problems.

En solution de contournement, les managers de Microsoft ont exhorté, ont corrompu (à l’aide de primes potentielles), et ont menacé les développeurs de Word pour leur faire respecter le calendrier prévisionnel. En conséquence, les développeurs ont, de manière tout à fait prévisible, sorti leur '''boîte à outils secrète de développeurs''' - autrement dit tout un arsenal de pratiques pour pisser du code pourri (aucuns tests, aucunes revues, ignorance des anomalies connues, développement par copier-coller, mauvaise conception, …) pour développer visiblement plus vite. Vous voyez bien, les développeurs ont aussi des solutions de contournement pour régler leurs problèmes.

The tactics seemed to have worked like magic. As the managers pressured the developers, ‘features’ were delivered quicker as people used the secret toolbox, which reinforced the belief that pressuring developers helps. But this apparent acceleration actually had a delayed effect to make things slower, which is explored next. Since management did not quickly see the delayed effect of the secret toolbox, and because they believed managers should not be frequently looking in detail at the source code or themselves be master programmers, they did not learn from this dynamic.

Vu de l’extérieur, ces tactiques ont fonctionné à merveille. Au fur et à mesure que les managers mettaient la pression sur les développeurs, les ‘features’ étaient développées de plus en plus vite grâce à l’utilisation de la boîte à outils secrète, ce qui a renforcé la croyance en quoi mettre la pression sur les développeurs était quelque chose d’utile. Mais cette apparente accélération a eu en fait un effet à retardement qui a rendu les choses plus lentes (c’est ce que nous allons voir par la suite). Étant donné que le management n’a pas été assez rapide à voir l’effet à retardement de la boîte à outils, et parce que les managers pensent qu’ils n’ont pas besoin d’aller regarder fréquemment en détails le code source ou qu’ils n’ont pas besoin d’être eux-mêmes des développeurs très expérimentés, ils n’ont rien appris de cette dynamique.

A closer exploration of the system dynamics shows why things went slower in the long term and why the first Word for Windows release was years later than desired, illustrated in this model…

Le schéma ci-dessous illustre l’examen approfondie des dynamiques des systèmes montrant pourquoi les choses sont allées plus lentement à long terme et pourquoi le tout premier Word pour Windows a été livré des années en retard par rapport à la date souhaitée …

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-19.png.pagespeed.ic.D24dvGHzfu.webp|systems thinking-19.png]]
Some deeper dynamics of schedule pressure and the secret toolbox.

[[File:Xsystems-thinking-19-fr.png|frameless|848px|16ème schéma]]
''Dynamiques avancées de la pression sur le calendrier et de la boîte à outils secrètes.''

Naturally, lots of dirty code eventually slowed things down. More subtly, developers would ''ignore'' the bug list of ever-increasing open defects to—instead—generate new features. This led to a long delay between the creation of a defect and its correction. It turns out that this significantly increases variability and time to fix a defect because of the compounding negative effect of a long-lived bug (for example, due to workarounds and coupling) and because developers have long forgotten the detailed context of code related to the defect and therefore need to slowly rediscover that context—with more and more dirty confusing code surrounding them.

Naturellement, avoir une grande quantité de code de mauvaise qualité ralentie les choses. De manière beaucoup plus subtile, les développeurs ont ''ignoré'' la liste croissante d’anomalies pour privilégier la production de nouvelles features. Cela a eu pour conséquence d’avoir un délai important entre la déclaration d’une anomalie et sa correction. Il s’avère que cela a fait augmenter de manière significative la variabilité et le temps nécessaire pour corriger une anomalie en raison des effets cumulatifs négatifs liée à la nature même d’une vieille anomalie (par exemple avec la mise en place des solutions de contournement et des couplages existants entre les fonctionnalités), de l’oubli du contexte détaillé par les développeurs en relation avec l’anomalie, ces derniers mettant par conséquent plus de temps à le redécouvrir, de l’accumulation continue de code de mauvaise qualité dans le même temps.

The astute reader may also notice the several positive feedback loops that reinforce the degradation cycle; this is one reason the product was years later than intended.

Le lecteur avisé remarquera également plusieurs boucles causales positives renforçant le cycle de dégradation ; il s’agit de l’une des raisons expliquant le retard pris sur plusieurs années pour livrer le produit.

Solution? The lean thinking ''Stop and Fix'' and ''Go See'' principles. ''First'' , rather than trying to go faster when there are problems, manager-teachers encourage people to go ''slower'' and help them learn to see system dynamics and root causes, and to fix these—to improve the ''system'' of development. By going slower, Toyota—the masters of lean thinking—has become one of the fastest companies around. ''Second'' , for managers to ''go see at the real place of work'' to learn what is going on. The “real place” in software development is the code, which suggests that first-level managers are master programmers who are frequently evaluating the code.

Une solution ? L’approche lean avec les principes ''Arrêter et corriger'' et ''Aller voir''. ''Premièrement'', plutôt que d’essayer d’aller plus vite lorsqu’il y a des problèmes, des managers-formateurs encouragent les gens à aller plus ''lentement'' et à les inciter à apprendre les dynamiques des systèmes, les causes racines et à les corriger pour améliorer le ''système'' du développement. En allant plus lentement, Toyota - les maîtres de l’approche lean - est devenue l’une des entreprises les rapides du monde. _Deuxièmement, les managers doivent ''aller voir ce qui se passe sur le vrai lieu de travail'' pour apprendre ce qu’il se passe. Le « vrai lieu » dans le développement logiciel c’est le code, ce qui implique que les managers de proximité sont des développeurs expérimentés qui évalueront le code fréquemment.

Microsoft people did not reflect on the situation until after release. When they did finally hold a retrospective, it led to a ''zero-defects'' policy, meaning that the first priority was to fix known bugs in the code under development—to drive down to zero the open-defects list before writing more new-feature code.

Les personnes de chez Microsoft n’ont pas réfléchi sur la situation que bien après la livraison. Lorsqu’ils ont fini par faire une rétrospective, cela a amené à une politique du ''zéro défaut'', cela signifie que la première priorité était de corriger les anomalies connues dans le code en cours de développement afin d’aller vers du zéro anomalie ouverte dans la liste des anomalies avant d’écrire du code pour une nouvelle feature.

== Seeing (and Hearing) Local Optimization ==

== Voir (et entendre) l’optimisation locale ==

“Everyone is doing their best yet overall systems throughput is degrading. How can that be?” This is the paradox of '''local optimization''' —when a person or departmental decision maker optimizes for the local view or self-interest. The party making the decision frequently ''believes they are making the best decision'' , but because ‘best’ is a local optimization, in fact it sub-optimizes overall system throughput. This is a result of “silo mentality,” misunderstanding, fear, limited information, delayed feedback, ignorance, careerism, avarice, and other common ''organizational learning disorders'' .

« Chacun fait de son mieux, mais malgré tout le flux de production du système se dégrade. Comment cela est-il possible ? ». Il s’agit du paradoxe de '''l’optimisation locale''' - autrement dit c’est lorsqu’une personne à titre individuel ou un responsable de département prend une décision d’un point de vue local ou dans son propre intérêt. Les personnes prenant ce type de décision ''croient fréquemment qu’ils prennent la meilleure décision'', mais parce que ‘meilleure’ est ici synonyme d’optimisation locale, cela a pour résultat une sous-optimisation globale du flux du système. Ceci est le résultat d’une « mentalité de silo », d’incompréhension, de peur, de restrictions d’informations, de feedbacks à retardement, d’ignorance, de carriérisme, d’avarice et de bien d’autres ''dysfonctionnements d’apprentissages organisationnels''.

A small product group of 30 people does not have the time or money to engage in much nonsense or waste. But large companies, with large product groups, centralized process and tool groups, a centralized “project management office,” and so forth, seem to have raised local optimization and waste to an art form. Government bureaucracies are the quintessential example, of course. As such, when you serve as a guide in large-scale agile adoption, ''seeing'' (or ''hearing'' ) and dealing with local optimization is singularly vital.

Une petite équipe produit de 30 personnes n’a ni temps ni l’argent pour s’engager dans ce genre de non-sens ou de gâchis. Mais les grandes entreprises avec de grands groupes produit, des processus centralisés et des groupes outils, un « bureau de gestion de projet » centralisé, et ainsi de suite, semblent avoir élevé l’optimisation locale et le gâchis à une forme d’art. Les bureaucraties gouvernementales en sont bien sûr la quintessence. En conséquence, lorsque vous servez de guide dans une adoption agile à grande échelle, ''voir'' (ou ''entendre'') et s’occuper de l’optimisation locale est tout simplement quelque chose de vital.

For example, the legal and corporate security departments put in place a policy that seems terribly important from their perspective. In the aim of preventing loss of intellectual property (IP), the legal department decrees “no one shall put any information on the walls.” Or, in response to cost-cutting pressure, the facilities management says, “It is important to ensure our walls are not dirty or damaged.” And thus they shut down a practice in lean thinking, visual management (which is usually done on walls), and they inhibit a well-known innovation practice, group whiteboard work. The lawyers may succeed in reducing loss of IP (actually, that is questionable), and the facilities people will succeed in keeping the walls clean—at the cost of inhibiting the product development group from innovating and collaborating. Finally, the company falls behind with less and less IP even worth protecting because tools for innovation and delivering fast have been disallowed, but the lawyers have successfully fulfilled their mandate from the executive team to “ensure our IP is protected.” And the ''furniture police'' have clear walls. ''They have done their best'' .

Par exemple, les départements juridiques et sécurité mettent en place des politiques qui leurs semblent très importantes de leurs points de vue. Dans l’objectif de prévenir la perte de propriété intellectuelle, le département juridique peut décréter « il est interdit d’afficher tout type d’information sur les murs. ». Or, le département des immeubles soumis de son côté, à une pression de politique de réductions de coûts peut surenchérir en disant : « Il est important de s’assurer que nos murs ne soient ni sales ni abîmés ». Et ainsi s’arrête le management visuel qui est l’une des pratiques de l’approche lean (le management visuel se faisant habituellement sur les murs), et ils inhibent également une pratique d’innovation bien connue à savoir le travail de groupe devant un tableau blanc. Les juristes réussiront peut être à réduire la perte de propriété intellectuelle (ce qui en réalité devrait poser question), et les gens des immeubles réussiront à garder leurs murs propres - mais au prix d’inhiber le groupe de développement produit dans sa capacité d’innover et de collaborer. Finalement, l’entreprise se laissera distancer par la concurrence avec de moins en moins de propriété intellectuelle valant la peine d’être défendue parce que les outils permettant l’innovation et de livrer rapidement ont été bannis, mais les juristes auront rempli leur mandat vis-à-vis de la direction de « s’assurer que la propriété intellectuelle est protégée ». Et la police de la logistique aura nettoyé les murs. ''Ils ont fait de leur mieux''.

The following is a real e-mail quote from the ''FURNITURE POLICE'' in one organization that dissallowed visual management on the walls. Can you identify the local optimizations and mental models driving this?

Ce qui suit est extrait d’un vrai message électronique de la ''POLICE DE LA LOGISTIQUE'' dans une organisation qui a banni le management visuel sur les murs. Pouvez-vous identifier les optimisations locales et les modèles mentaux qui sont derrière tout ça ?

<blockquote>''Individual work cubic partition can be personalized. But things obvious higher than the partition or harming the office environment’s harmony are restricted.''
</blockquote>
<blockquote>_Les [https://fr.wikipedia.org/wiki/Bureau_%C3%A0_cloisons bureaux à cloisons] peuvent être personnalisés. Mais tout ce qui visible au-dessus de la cloison ou qui perturbe l’harmonie de l’environnement de bureau est interdite.
</blockquote>
We also see local optimization in centralized groups that make software tool choices for others. The common mindset is to choose a tool that is best at reducing some supposed cost (curiously, these groups seldom recommend free open source tools) or best at doing something complicated or best for the work of one specialized worker role (even though ''everybody'' has to use the tool), rather than maximizing the global goal of faster system throughput of value to customers.

Nous constatons aussi des optimisations locales dans les groupes centralisés dont le rôle est de choisir les logiciels pour les autres personnes de l’entreprise. La croyance la plus répandue que cette démarche est qu’il s’agit de ce qu’il y a de mieux pour réduire les coûts d’achats (curieusement ces mêmes groupes recommandent rarement les logiciels libres gratuits) ou ce qu’il y a de mieux pour accomplir une tâche compliquée ou ce qu’il y a de mieux pour l’accomplissement du travail d’un seul type de travailleur (même si ''tout le monde'' est censé devoir utiliser l’outil), plutôt que de maximiser l’objectif de l’entreprise qui est d’avoir un système de flux de production de la valeur plus rapide pour les clients.

In large-scale adoption of Scrum or agile principles, most of the “Yes, but …” issues that are raised are examples of local optimization, such as, “''Yes, but…what about management reporting''?” or more generally, “''Yes, but…what about <special case="">''?” Then, policies and practices are twisted around, serving the goal of reporting or some other secondary aim rather than the primary goal of optimizing for fast value throughput. Sometimes we see ''local optimization for the extreme or rare case'' . For example, a person responsible for making a centralized tool choice for the enterprise presents a scenario for a complex or rare case of use, and then chooses the tool that fits that, sub-optimizing for a 5 percent case instead of optimizing for ease and speed for the 95 percent case.</special>

Dans les adoptions de Scrum ou des principes agiles à grande échelle, la plupart des problématiques de type « Oui, mais … » qui sont soulevées sont des exemples de sous-optimisations, comme par exemple « ''Oui, mais … qu’en est-il des comptes-rendus auprès du management'' ? » ou encore de manière plus générale « * Oui, mais … qu’en est-il de … * ? ». Alors, les principes et les pratiques sont dévoyés, pour servir soit l’objectif de rendre compte soit n’importe quel autre objectif secondaire plutôt que suivre l’objectif d’optimiser le flux de valeur produite. De temps en temps, nous voyons des '''optimisations locales dans certains cas rares ou extrêmes'''. Par exemple, une entreprise doit choisir un outil centralisé répondant à un certain nombre de cas d’utilisations possibles dont un cas extrêmement rare ou complexe, la personne, en charge de faire ce choix, choisit un outil correspondant à un cas unique d’utilisation, sous-optimisant ainsi l’ensemble du système pour un cas représentant uniquement 5% des cas d’utilisation au lieu de l’optimiser pour la majorité des 95% des autres cas d’utilisations.

Other local optimizations are due to ignorance of new ways of working. This is especially common in large-scale product groups. For example, we once helped a large networking product group in Europe adopt Scrum and the practice of ''continuous integration'' (CI) combined with a CI system that continually integrated, built, and automatically tested the product. After some time, an outside traditional manager inspected what was going on, and recommended the integration practices should be changed—because there was no written integration plan for how a human integration manager should manually integrate all the software, and of course, there was no integration manager. They wanted to ‘optimize’ around the work of an integration manager that was no longer needed. They could not see that their entire old-fashioned model of work had been eliminated with CI. This story repeats in all the departments of a large established product: local optimization around the ''existing'' ways of work, such as manual test, a separate architecture department, component teams, and so on. A coach working to introduce large-scale Scrum at the enterprise level has a ''mountain'' of similar local optimization thinking to deal with.

D’autres optimisations locales sont dues, quant à elles, à l’ignorance des nouvelles manières de travailler. C’est quelque chose de très répandue et tout spécialement dans les groupes produit à grande échelle. Par exemple, un jour nous avons aidé un groupe produit distribué à travers l’Europe à adopter d’une part Scrum et d’autre part la pratique de ''l’intégration continue'' (CI) le tout sous la forme d’un système d’intégration continue dédié intégrant, compilant, testant automatiquement de manière continue le produit. Après quelques temps, un manager, que l’on pourrait qualifier de traditionnel, extérieur au groupe est venu inspecter ce qu’il se passait. Celui-ci a recommandé que les pratiques d’intégration devraient être changées en raison de l’absence de schéma d’intégration global permettant à un responsable d’intégration de faire manuellement l’intégration de l’ensemble du logiciel ; une absence de schéma pour la bonne raison qu’il n’y avait plus besoin de responsable d’intégration au sein de l’organisation. Il voulait ‘optimiser’ le travail d’un responsable d’intégration qui n’existait plus. Il était dans l’impossibilité de voir que la totalité de l’ancienne manière de faire les choses avait disparu avec l’intégration continue. Cette histoire se répéta dans l’ensemble des départements du groupe produit : il y a avait des optimisations locales partout autour des façons de faire existantes, tels que les tests manuels, le département d’architecture séparé des équipes, les équipes composants, etc. N’importe quel coach dont la tâche consistait à introduire Scrum à grande échelle au niveau de l’organisation avait une ''montagne'' d’optimisations locales à penser à gérer.

In lean thinking and agile methods, the focus is on global systems goals: Deliver value fast with high quality and morale—'''global optimization''' . Try to consider decisions in light of this goal. To develop an “optimize the whole” culture, challenge all decisions and policies with the question:

Dans l’approche lean et dans les méthodes agiles, l’accent est mis sur les objectifs du système dans sa globalité : livrer de la valeur de grande qualité au plus vite tout en gardant le moral des équipes au plus haut - autrement dit une '''optimisation globale'''. Essayer de reconsidérer vos décisions à la lumière de cet objectif. Pour développer une culture de « l’optimisation du tout », remettez donc en cause toutes les décisions et les règles avec la question suivante :

<blockquote>'''Does this decision or policy focus on delivering value to the external customer fast, or does it focus on the interests of a department, person, internal policy/practice, or rare case?'''
</blockquote>
<blockquote>** Est-ce que cette décision ou cette règle se focalise-t-elle sur livrer de la valeur au client externe au plus vite, ou se focalise-t-elle sur les intérêts d’un département, d’une personne, d’une pratique/règle interne, ou d’un cas rarissime ?**
</blockquote>
In LeSS, the Product Owner is responsible for choosing high-value goals that '''could lead to potentially shippable product (at the end of the Sprint) and that maximize the desired impacts and that delight the customer, while maintaining a sustainable pace and high engineering quality'''. That explicit goal is meant to orient the system toward global rather than local optimization.

Dans LeSS, le Product Owner est responsable pour choisir ces objectifs à haute valeur qui '''pourrait mener à un produit potentiellement livrable (à la fin du Sprint) maximisant les impacts souhaités et réjouissant le client tout en maintenant un rythme soutenable et une haute qualité d’ingénierie'''. Cet objectif explicite est destiné à orienter le système vers son optimisation globale plutôt que vers une optimisation qui ne serait que locale.

== Conclusion ==

== Conclusion ==

In addition to becoming a systems thinker yourself, encourage others to learn more about this topic. We suggest you to try getting together at a whiteboard with colleagues to sketch a causal loop diagram, so that ''being'' systems thinkers and ''doing'' systems thinking are connected at the workplace.

En plus de devenir un pratiquant de l’approche systémique vous-même, encouragez donc les autres à en apprendre plus sur ce sujet. Nous vous suggérons d’essayer de rassembler quelques-uns de vos collègues autour d’un tableau blanc et d’y dessiner des diagrammes de boucles causales, afin que les architectes des systèmes et les pratiquants de l’approche systémique soient réunis en un seul endroit.

<figure>
[[File:https://less.works/img/systems-thinking/xgroup,P20cld,P20modeling.jpg.pagespeed.ic.lirKMzwWbD.webp|group%20cld%20modeling.jpg]]
</figure>
[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-20-fr.png|frame|none|alt=|caption systems thinking-20.png]]

<figcaption>
Doing system thinking. Sketching a causal loop diagram together—modeling to have a conversation.
</figcaption>
Séance d’approche systémique. Réalisation d’un diagramme de boucle cause à plusieurs mains dans l’objectif d’avoir une conversation.

== Recommended Readings ==

== Lectures recommandées ==

* W. Edwards Deming’s [http://www.amazon.com/Out-Crisis-W-Edwards-Deming-ebook/dp/B00653KTES/ref=sr_1_1?ie=UTF8&qid=1413601625&sr=8-1&keywords=out+of+the+crisis ''Out of the Crisis''] is a master work by arguably the most well-known systems thinker and quality expert. It opens with the modest goal, “The aim of this book is transformation of the style of American management… It requires a whole new structure, from foundation upward.” Deming also advocates the ''System of Profound Knowledge'' in which managers (1) appreciate there is a ''system'' , (2) understand common-cause and special-cause variation (queueing theory is related to variation), (3) understand limitations of knowledge and reasoning mistakes, and (4) know credible psychology and social research results so that behavior- or motivation-related policies are ''not'' based on “common sense.” The core of the book centers around his famous ''14 Points for Management'' , including (for example), “''Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership'' .”
* [https://www.amazon.fr/Hors-crise-W-Edwards-Deming/dp/2717843930/ ''Hors de la Crise''] de W. Edwards Deming est un ouvrage de référence par, sans conteste, le plus connu des penseurs systémiques et des experts sur la qualité. Cet ouvrage commence par un objectif modeste : « l’objectif de ce livre est la transformation du style du management américain … ce qui exige une toute nouvelle structure de fonds en combles. ». Deming prône un ''Système de connaissances approfondies'' dans lequel les managers (1) reconnaissent qu’il y a un ''système'', (2) qu’ils sont en mesure de comprendre les facteurs les plus répandus et les facteurs spéciaux de variations au sein du système (la théorie des files d’attente est liée à ce phénomène de variation), (3) qu’ils sont en mesure de comprendre que les connaissances sont limitées et qu’il y a des erreurs de raisonnements, et (4) que la psychologie et les recherches en sciences sociales jouent des rôles tout à fait crédibles dans l’objectif de comprendre que les règles régissants les comportements ou en lien avec la motivation des individus ne soient pas basés sur le seul « bon sens ». Le cœur de l’ouvrage tourne autour des célèbres ''14 points pour le management'', y compris par exemple « ''Éliminer le management par les objectifs. Éliminer le management par les nombres, par les objectifs par les nombres. Y substituer le leadership''»
* Jay Forrester’s [http://www.amazon.com/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ref=sr_1_1?ie=UTF8&qid=1413601681&sr=8-1&keywords=industrial+dynamics ''Industrial Dynamics''] is the classic text on system dynamics—well written and insightful. Although written in the early 1960s, it is as relevant today as when published. It goes beyond cause-effect modeling to also model the flow and inventories of information, money, and material in systems. The book includes formal mathematical modeling but this is not obligatory to appreciate system dynamics.
* [https://www.amazon.fr/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ ''Industrial Dynamics''] de Jay Forrester est un classique du genre sur les dynamiques des systèmes - très bien écrit et très instructif. Même si cet ouvrage a été écrit au début des années 1960, il est toujours aussi pertinent aujourd’hui. Il va au-delà de la modélisation des causes à effets pour modéliser également le flux et les stocks d’informations, d’argent et de matériaux au sein d’un système. Le livre contient également une modélisation mathématique formelle de ces dynamiques, toutefois la lecture de cette dernière reste facultative quant à apprécier la qualité de l’ouvrage.
* Weinberg’s ''Quality Software Management: Systems Thinking'' and ''An Introduction to General Systems Thinking'' are worthwhile. Written from the perspective of an experienced consultant in systems development.
* Les ouvrages [https://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226/ ''Quality Software Management: Systems Thinking''] et [https://www.amazon.fr/Introduction-General-Systems-Thinking-Weinberg/dp/0932633498/ ''An Introduction to General Systems Thinking''] de Gerald Weinberg sont intéressants. Il sont écrits du point de vue d’un consultant expérimenté en développement de systèmes.
* Senge’s [http://www.amazon.com/Fifth-Discipline-Practice-Learning-Organization-ebook/dp/B000SEIFKK/ref=sr_1_1?ie=UTF8&qid=1413601715&sr=8-1&keywords=the+fifth+discipline ''The Fifth Discipline''] is a classic that advocates the need for leadership to apply systems thinking (it is the ''fifth'' discipline) and other key disciplines for a great, sustainable enterpise. The others include leaders with (1) personal mastery and (2) reflection on their beliefs and faulty reasoning, the (3) definition and communication of a meaningful shared vision, and (4) the ability of teams to learn. We recommend ignoring—at least during the first few years of practice—the ‘archetypes’ notion presented in the book. It was well meant as a learning aid but has been observed to distract and intimidate people from learning and applying basic system dynamics modeling. The ‘archetypes’ are not part of original system dynamics.

[https://www.amazon.fr/cinqui%C3%A8me-discipline-Levier-organisations-apprenantes/dp/2212559372/ ''La cinquième discipline''] est un autre classique du genre qui prône que l’encadrement d’une entreprise devrait appliquer l’approche systémique (autrement dit la ''cinquième'' discipline) ainsi que d’autres disciplines-clés toutes aussi importantes en vue d’obtenir une entreprise durable. Ces autres disciplines que les dirigeants devraient appliquer sont (1) une maîtrise personnelle des aspirations, (2) une réflexion sur leurs propres croyances et raisonnements erronés, (3) la définition et la communication d’une vision partagée ayant du sens, et (4) la capacité des équipes à apprendre. Nous vous recommandons d’ignorer - du moins dans un premier temps pendant vos premières années de pratiques - le concept d’archétypes présenté dans le livre. Ce concept avait pour but d’être une aide à l’apprentissage de la cinquième discipline mais nous avons observé qu’il était soit une source de distraction soit qu’il intimidait les lecteurs quant à leur apprentissage et à l’application de la modélisation des dynamiques des systèmes. Les ‘archetypes’ ne font pas partie à l’origine des dynamiques des systèmes.

* [http://www.amazon.com/Fifth-Discipline-Fieldbook-Strategies-Organization-ebook/dp/B00JTCJEO8/ref=sr_1_1?ie=UTF8&qid=1413601809&sr=8-1&keywords=The+Fifth+Discipline+Fieldbook ''The Fifth Discipline Fieldbook''] is an in-depth resource, written from the viewpoint of many practitioners and consultants.

*[https://www.amazon.fr/guide-lorganisation-apprenante-d%C3%A9velopper-lintelligence/dp/2212568711/ ''La 5ème discipline - le guide de l’organisation apprenante''] est une source extrêmement riche sur l’approche systèmique écrite du point de vue des pratiquants de cette approche et de consultants.

* The organizational-learning writings from Argyris, Putnam, McLain, and Schön. Important concepts include ''double-loop learning'' and ''high-advocacy/high-inquiry dialogue''. Classic works include [https://actiondesign.com/resources/readings/action-science ''Action Science''] and [http://www.amazon.com/Organizational-Learning-Addison-Wesley-Organization-Development/dp/0201001748/ref=sr_1_11?ie=UTF8&qid=1413601940&sr=8-11&keywords=organizational+learning ''Organizational Learning''].
* Les écrits d’Argyris, Outnam, McLain et Schön sur les apprentissages organisationnels comme [https://actiondesign.com/resources/readings/action-science ''Action Science''] et [http://www.amazon.com/Organizational-Learning-Addison-Wesley-Organization-Development/dp/0201001748/ref=sr_1_11?ie=UTF8&qid=1413601940&sr=8-11&keywords=organizational+learning ''Organizational Learning''] abordent des concepts importants tels que la ''double-boucle apprenante'' et le ''dialogue grand-plaidoyer/grand-réquisitoire''.
* The publications and resources available through the [https://www.solonline.org/ ''Society for Organizational Learning''].
* Les publications et les ressources de la ''Society for Organizational Learning''](https://www.solonline.org/).

-----

===== Notes: =====

# Senge wrote ''The Fifth Discipline'' , on systems thinking and learning organizations, named “one of the seminal management books of the last 75 years” by the ''Harvard Business Review.'' See** [Senge94].
# Another reason: Believing more control is possible than actually is. Complexity science suggests fundamental limits on predicting and controlling semi-chaotic social systems [Stacey07]. This is a rather large can of worms that will remain unopened in this book.
# Macroeconomics, psychology, sociology, and biology are exceptions, among many others.
# ‘Basic’ does not mean trivial or easy to solve. For example, ‘motivation’ and ‘quality’ are basic but not easy issues.
# ''Feedback loops'' is occasionally used in this book in the colloquial sense of feedback, rather than this system dynamics sense.

# ''La cinquième discipline'' écrit par Senge sur l’approche systèmique et les organisations apprenantes a été nommé « l’un des livres les plus novateurs sur le management de ces 75 dernières années » par la ''Harvard Business Review.'' [Senge94].
# Une autre raison : Croire que plus de contrôle est possible qu’il ne l’est actuellement. La science de la complexité montre qu’il existe des limites en terme de prédiction et de contrôle des systèmes sociaux semi-chaotiques [Stacey07]. C’est une énorme boîte de Pandore qui restera enfermée dans ce livre.
# Macro économie, psychologie, sociologie et biologie sont des exemples d’exceptions parmi d’autres
# ‘Basique’ ne signifie pas trivial ou facile à résoudre. Par exemple, les problématiques de ‘motivation’ et de ‘qualité’ sont des problématiques basiques mais elles ne sont pas faciles à résoudre.
# ''Les boucles de feedback'' sont parfois utilisées dans ce livre dans le sens littéral du terme, plutôt dans le sens des dynamiques des systèmes

LeSS - Approche systémique

2020-10-27T22:05:15Z

Nicolas Mereaux :

[[Category: Nicolas Mereaux]]
[[Category: Portail LeSS]]
[[Category: Agilité à grande échelle]]
Auteur : The LeSS Company B.V. 
Source : [https://less.works/less/principles/systems-thinking.html] 
----
Traducteur : Nicolas Mereaux 
Relecteur : Fabrice Aimetti, Christophe Gesché 
Date : 27/10/2018 
----
Traduction : 
 
[[LeSS - Portail Principes]] 
 

= Systems Thinking =

= Approche systémique =

I took a speed reading course and read “War and Peace” in twenty minutes. It involves Russia. —Woody Allen

J’ai pris un cours de lecture rapide puis j’ai lu « Guerre et Paix » en vingt minutes. Cela parle de la Russie.

“No matter what we do, the number of defects in our backlog remains about the same,” a manager told us; this for a 15 MSLOC C and C++ product with several hundred developers where we were working. What’s going on? Systems thinking may help. In small groups the forces at play are more quickly seen and informally understood, but in large product development—or any large system—it’s tough. Gerry Weinberg highlights two decisive factors in this situation:

« Quoi que nous fassions, le nombre d’anomalie dans notre ''backlog'' reste identique. » nous a dit un jour un manager en évoquant un produit de près de 15 millions de lignes de code sur lequel plusieurs centaines de développeurs étaient en train de travailler. Que pouvait-il bien se passer ? L’approche systémique peut s’avérer utile dans ce cas comme dans d’autres. En petits groupes, les forces en présence peuvent rapidement être identifiées et comprises de manière informelle, mais dans le cadre du développement d’un gros produit ou de n’importe quel gros système, c’est difficile. Gerry Weinberg met en avant deux facteurs décisifs dans ce genre de situation :

<blockquote>'''Weinberg-Brooks’ Law''': More software projects have gone awry from management’s taking action based on '''''incorrect system models''''' than for all other causes combined.

'''Causation Fallacy''': Every effect has a cause… and we can tell which is which. [http://www.amazon.com/Quality-Software-Management-Systems-Thinking/dp/0932633226/ref=sr_1_1?ie=UTF8&qid=1413527418&sr=8-1&keywords=Quality+Software+Management%3A+Systems+Thinking [Weinberg92]]
</blockquote>
<blockquote>'''Loi de Weinberg-Brooks''' : De plus en plus de projets informatiques sont partis de travers après que le management ait pris des décisions basées sur des '''modèles systémiques incorrects''' plus que pour toutes autres causes combinées.

'''Erreur de causalité''' : Chaque effet a une cause … et nous pouvons dire desquelles il s’agit. [http://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226/ref=sr_1_1?ie=UTF8&qid=1413527418&sr=8-1&keywords=Quality+Software+Management%3A+Systems+Thinking [Weinberg92]]
</blockquote>
These reflect the impact of our '''mental models''' on the system, a subject that will be revisited later in this section.

Ces deux facteurs reflètent bien l’impact de nos '''modèles mentaux''' sur le système, un sujet que nous reverrons plus tard dans cette section.

Problems stemming from mental models and assumptions are one issue. Another is that large-scale adoption of Scrum, lean thinking, and agile principles is not isolated to the development group. It bumps into product management, budgeting, beta-testing, launch, and governance and HR policies. Accordingly, in large-scale agile adoption it is useful to be able to get together with colleagues and ''effectively reason'' about the mental models, causal relations, feedback loops, and control mechanisms (or illusions of control) in a big system that is about to be seriously ''perturbed.'' Systems thinking is one of those reasoning tools.

Les problèmes résultant de nos modèles mentaux et de nos postulats sont un point à traiter. Un autre point est l’adoption à grande échelle de Scrum, de l’approche lean et des principes agiles en dehors du domaine du développement. Ce point est aussi présent dans la gestion de produit, les budgets, les tests, la commercialisation, la gouvernance et la politique RH. En conséquence, dans les adoptions agiles à grande échelle, il est utile de se réunir avec des collègues et de ''réfléchir en profondeur'' sur les modèles mentaux, les relations causales, les boucles de ''feedback'' et les mécanismes de contrôles (ou les illusions de contrôle) dans un gros système qui va être sérieusement ''pertubé''. L’approche systémique est l’un de ces outils de réflexion.

In 1958, the ''Harvard Business Review'' published [https://kupdf.com/download/industrial-dynamics-a-major-breakthrough-for-decision-makers_5902479bdc0d603940959ed5_pdf “Industrial Dynamics: A Major Breakthrough for Decision Makers,”] a landmark paper by Jay Forrester, MIT Sloan School professor. This paper spurred the movement of systems thinking in business education, and the MIT Sloan School of Management became known for educating people in '''system dynamics'''. System dynamics is sometimes treated as a synonym for '''systems thinking''' , though the latter is a more general term.

En 1958 la ''Harvard Business Review'' a publié un article de Jay Forrestor, professeur au MIT Sloan School, qui a fait date [https://kupdf.com/download/industrial-dynamics-a-major-breakthrough-for-decision-makers_5902479bdc0d603940959ed5_pdf “Industrial Dynamics: A Major Breakthrough for Decision Makers,”]. Cet article a lancé le mouvement de l’approche systémique dans le domaine des formations en gestion d’entreprise et la MIT Sloan School of Management devint célèbre pour ses formations en '''dynamique des systèmes'''. Le terme de dynamique des systèmes est parfois utilisé comme synonyme d’'''approche systémique''', même si ce dernier est un terme beaucoup plus général.

MIT also attracted other system-dynamics-oriented researchers such as Peter Senge.[https://less.works/less/principles/systems-thinking.html#footnote-1 1]

Le MIT a également attiré d’autres chercheurs intéressés par la dynamique systémique tel que Peter Senge[^1].

Consistent with ''Weinberg-Brook’s Law'', Forrester’s research showed that decision makers who were given dynamic models of a business system and asked to improve their output performance, ''usually made them run worse'' [http://www.amazon.com/The-Fifth-Discipline-Fieldbook-Organization/dp/0385472560/ref=sr_1_fkmr0_3?ie=UTF8&qid=1413528034&sr=8-3-fkmr0&keywords=The+Fifth+Discipline+%EF%BF%BCFieldbook [SKRRS94]]. The observation was that most people have weak judgement on how to fundamentally improve systems, usually applying incorrect “common sense” and quick-fix ‘solutions’ that do not create long-lasting systemic improvement.

En corrélation avec la loi de ''Weinberg-Brook'', Jay Wright Forrester a montré que les décideurs à qui il avait été donné des modèles dynamiques de systèmes opérationnels et à qui il avait été demandé d’améliorer la performance opérationnelle, ''n’avaient fait généralement qu’empirer les choses'' [https://www.amazon.fr/guide-lorganisation-apprenante-d%C3%A9velopper-lintelligence/dp/2212568711/ [SKRRS94]]. Il en est ressorti d’ailleurs que la plupart des personnes évaluaient mal la manière dont il faut améliorer les systèmes, et appliquaient généralement leur « bon sens », en mettant en place des solutions de contournement qui n’apportent aucune amélioration systémique à long terme.

Why is the behavior of a large development group (a system) not understood or guided skillfully? The answer lies, in part, in the behavior of stochastic systems with queues and variability, as explored in the [https://less.works/less/principles/queueing_theory.html Queueing Theory] LeSS principle. And the same answer lies in ''control theory'': Most systems of interest—such as a product development group—have complex positive and negative feedback loops and nonlinear behavior. The behavior of these systems defies our gut instinct. And then there is the minor issue of ''people''.

Pourquoi le comportement d’un groupe de développement de grande taille (autrement dit un système) n’est-il pas compris ou guidé de manière compétente ? La réponse réside, en partie, dans le comportement des systèmes stochastiques avec les files et les variabilités comme nous avons pu l’évoquer avec le principe LeSS de la [https://less.works/less/principles/queueing_theory.html théorie des files d’attentes]. Et c’est la même réponse qui est au cœur de la ''théorie du contrôle'' : la plupart des systèmes d’intérêt - tel qu’un groupe de développement de produit - ont des boucles de ''feedback'' positives et négatives ainsi qu’un comportement non linéaire. Le comportement de ces systèmes défient nos instincts. Et puis il y a la problématique mineure des ''gens''.

In summary, reasons for not being skillful in fathoming or guiding a big system include (but are not limited to):

En résumé, les raisons expliquants l’incompétence à maîtriser ou à guider un gros systèmes sont (liste non exhaustive) :

* lack of knowledge about the system dynamics, feedback loops, nonlinear systems behavior, and unintended consequences in workplace systems
* un manque de connaissance des dynamiques des systèmes, des boucles de ''feedback'', du comportement non linéaire des systèmes, et des conséquences inattendues dans les systèmes sur le lieu de travail.
* not understanding root causes of problems (and how to find)
* une incompréhension des causes racines des problèmes (et de comment les trouver)
** ''causes,'' not cause; in systems thinking one sees that there are multiple, indirect, and dynamic causes to problems
** ''les causes'', non la cause ; en approche systémique, nous savons que les causes des problèmes sont multiples, indirectes et dynamiques
* not knowing if or why quick-fix or local-department decisions degraded overall delivery performance.
* l’incapacité à savoir si ou pourquoi une solution de contournement ou une décision locale dégrade la performance globale opérationnelle.

In short, not being systems thinkers.[https://less.works/less/principles/systems-thinking.html#footnote-2 2]

En bref, ne pas utiliser l’approche systémique[^2].

These reasons are consequential at the intersection of management and large-scale adoption of lean and agile principles. The leadership team is part of the system being perturbed; if they do not apply systems thinking, they could ''really'' perturb it—and not in a good way!

Ces raisons sont la conséquence de l’intersection du management et de l’adoption des principes lean et agile. L’équipe de direction fait partie du système qui est pertubé ; si elle n’applique pas l’approche systémique, elle pourrait ''vraiment'' le perturber - et pas de la bonne façon.

As a summary of systems thinking insight, we like the [https://en.wikipedia.org/wiki/The_Fifth_Discipline#The_11_Laws_of_the_Fifth_Discipline 11 ‘laws’] described in [http://www.amazon.com/Fifth-Discipline-Practice-Learning-Organization-ebook/dp/B000SEIFKK/ref=sr_1_1?ie=UTF8&qid=1413531002&sr=8-1&keywords=the+fifth+discipline The Fifth Discipline]:

Les points-clés à retenir de l’approche systémique peuvent être résumé dans les [https://en.wikipedia.org/wiki/The_Fifth_Discipline#The_11_Laws_of_the_Fifth_Discipline 11 lois] décrites dans la [https://www.amazon.fr/cinqui%C3%A8me-discipline-organisations-apprenantes-dexemplaires-ebook/dp/B017WSYAHG Cinquième discipline]

* Today’s problems come from yesterday’s ‘solutions.’
* The harder you push, the harder the system pushes back.
* Behavior will grow worse before it grows better.
* The easy way out usually leads back in.
* The cure can be worse than the disease.
* Faster is slower.
* Cause and effect are not closely related in time and space.
* Small changes can produce big results…but the areas of highest leverage are often the least obvious.
* You can have your cake and eat it too—but not all at once.
* Dividing an elephant in half does not produce two small elephants.
* There is no blame.
* Les problèmes d’aujourd’hui viennent des solutions d’hier
* Plus vous poussez, plus le système pousse en retour
* Le comportement empirera d’abord avant de s’améliorer
* La manière la plus facile de s’en sortir conduit souvent à faire quelques pas en arrière
* Le médicament peut être pire que la maladie
* Plus vite c’est plus lentement
* Les causes et les effets ne sont pas étroitement liés dans l’espace et le temps
* De petits changements peuvent produire de gros résultats … mais les zones où l’effet de levier est le plus important sont souvent les moins évidentes
* Vous pouvez avoir votre gâteau et le manger aussi - mais pas en une seule bouchée
* Couper un éléphant en deux ne produit pas deux petits éléphants
* Il n’y a aucun reproche à faire

Toyota’s internal motto is [http://www.toyota-global.com/company/toyota_traditions/quality/may_jun_2005.html “Good '''thinking''', good products.”] Systems thinking is a set of ''thinking'' tools to help…

La devise de Toyota en interne est [http://www.toyota-global.com/company/toyota_traditions/quality/may_jun_2005.html « Une bonne '''réflexion''', de bons produits »]. L’approche systémique est un jeu d’outils de réflexion pour aider …

* '''see system dynamics'''—a development organization is a system of people and policies with subtle feedback loops and unintended consequences
* '''à voir les dynamiques des systèmes''' - une organisation de développement est un système de personnes et de règles avec de subtiles boucles de ''feedback'' et des conséquences inattendues
** we can learn to see and thus improve the system with '''causal loop diagrams''' created in a workshop
** nous pouvons apprendre à voir et ainsi à améliorer le système avec des '''diagrammes de boucles causales''' faits lors d’un atelier
* '''see mental models'''—one reason behind suboptimal decisions is mistaken assumptions and faulty reasoning
* '''à percevoir les modèles mentaux''' - parmi les raisons derrière des décisions sous-optimales se trouvent des hypothèses erronées et des raisonnements incorrects
** causal loop diagramming and Five Whys expose these
** les diagrammes de boucles causales et les cinq pourquoi permettent de révéler tout ça
* '''see local optimization'''—another source of suboptimal decisions is '''local optimization''' , making the ‘best’ decision from the viewpoint of a person or department, rather than '''global optimization''' for the lean systems-level goal of ''deliver value fast with high quality and high morale'' .
* '''à voir les optimisations locales''' - une autre source de décisions sous-optimales est '''l’optimisation locale''', autrement dit prendre la « meilleure » décision du point de vue d’une personne ou d’un département, au détriment d’une '''optimisation globale''' qui est l’objectif au niveau système ''lean'' que de pouvoir ''livrer la plus grande valeur possible de très grande qualité avec un moral d’acier''

This introduction is organized around the following areas in systems thinking: Learning to see (1) ''system dynamics'' , (2) ''mental models'' , (3) ''root causes'' , and (4) ''local optimization'' .

Cette introduction à l’approche systémique est présenté autour des domaines suivants : Apprendre à voir (1) ''les dynamiques des systèmes'', (2) ''les modèles mentaux'', (3) ''les causes racines'', et (4) ''l’optimisation locale''.

== Seeing System Dynamics: Introduction ==

== Voir les dynamiques des systèmes : Introduction ==

=== Static versus Dynamic Complexity ===

=== Complexité statique versus complexité dynamique ===

Many of us, especially in engineering and finance, are educated to master '''complexity of static details'''—learning to analyze and manage information (requirements, financial analysis, …), decompose complex structures into simpler ones, and so forth. That is, complexity of a static, information, or structural nature.

La plupart d’entre nous, notamment les ingénieurs et les financiers, ont été formés pour maîtriser la '''complexité de détails statiques''' - en apprenant à analyser et à gérer l’information (exigences, analyses financières, …), à décomposer des structures complexes en structures simples, et ainsi de suite. C’est-à-dire, la complexité d’une information qui est par nature structurellement statique.

Why do big software systems tend to degrade, with more and more time spent on defects? What might happen if the USA invades Iraq? Seeing the dynamics behind these questions involves analysis of the '''complexity of dynamics''' .

Pourquoi les gros systèmes informatiques ont-ils tendance à se dégrader malgré de plus en plus de temps passé sur les anomalies ? Qu’est-ce qui pourrait bien se passer si les États-Unis d’Amérique envahissait l’Irak ? Voir les dynamiques derrière ces questions implique d’analyser la '''complexité des dynamiques''' en jeu.

In contrast to static-details education, many of us receive no ''formal'' education in analyzing ''dynamics'' complexity[https://less.works/less/principles/systems-thinking.html#footnote-3 3], especially workplace dynamics. Perhaps there is a belief it is sufficient to rely on common sense in the workplace. Forrester demonstrated that “common sense” is just not so in complex systems, and showed it is possible to formally educate people to become better system dynamics thinkers in the workplace using ''dynamic system models'' visualized in ''flow diagrams'' [http://www.amazon.com/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ref=sr_1_1?ie=UTF8&qid=1413582840&sr=8-1&keywords=Industrial+Dynamics [Forrester61]].

En contraste avec une formation sur les détails statiques que la plupart d’entre nous avons suivie, peu d’entre nous ont reçu de formation sur l’étude des systèmes dynamiques et complexes[^3] et notamment en milieu professionnel. Peut-être parce que nous avons la croyance qu’il est suffisant de s’appuyer sur le bon sens en milieu professionnel. Jay Wright Forrester a démontré que le « bon sens » n’est pas suffisant dans des systèmes complexes et qu’il est possible de former des personnes pour leur permettre de mieux appréhender les dynamiques des systèmes en milieu professionnel en utilisant notamment des ''diagrammes de flux'' [http://www.amazon.fr/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ref=sr_1_1?ie=UTF8&qid=1413582840&sr=8-1&keywords=Industrial+Dynamics [Forrester61]].

Flow diagrams encompass material, financial, and information flows, stocks (variables with a quantity, such as cash or number of defects), the impact of decisions and policies, and cause-effect relations. A popular simplification is the '''causal loop diagram''' that focuses on cause-effect relationships and feedback loops in a system [http://www.amazon.com/Business-Dynamics-Systems-Thinking-Modeling/dp/0071179895 [Sterman00]]. There are a variety of similar notations; they all show stocks (variables), causal links, and delay. In [http://www.amazon.com/Quality-Software-Management-Systems-Thinking/dp/0932633226/ref=sr_1_1?ie=UTF8&qid=1413527418&sr=8-1&keywords=Quality+Software+Management%3A+Systems+Thinking [Weinberg92]] this is called the ''diagram of effect'' .

Les diagrammes de flux peuvent s’appliquer aussi bien aux flux matériels, financiers, d’informations, de stocks (n’importe quel type de stock quantitatif comme de l’argent ou des anomalies), aux conséquences des décisions et des politiques et des relations de causes à effet. Lorsque nous pensons aux diagrammes de flux, nous pensons souvent au seul diagramme de boucle causale dédié aux relations de cause à effets et aux boucles de rétroaction dans un système [http://www.amazon.fr/Business-Dynamics-Systems-Thinking-Modeling/dp/0071179895 [Sterman00]]. Il existe une grande variété d’autres diagrammes qui peuvent faire figurer les stocks (quels qu’ils soient), les liens de causalités, et les retards. Dans son ouvrage, [http://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226/ref=sr_1_1?ie=UTF8&qid=1413527418&sr=8-1&keywords=Quality+Software+Management%3A+Systems+Thinking [Weinberg92]] Gerald Weinberg appelle cela un ''diagramme d’effet''.

=== The First Law of Diagramming: Model to Have a Conversation ===

=== La première loi de la réalisation d’un diagramme : nous modélisons pour avoir une conversation ===

A tool to learn to see system dynamics is a causal loop diagram, ideally sketched on a whiteboard in a LeSS Overall Retrospective with colleagues. Before going further, here is the ''First Law of Diagramming''

Un outil très utile pour apprendre les dynamiques des systèmes est le diagramme de boucles causales - nous vous recommandons de l’utiliser sur un tableau blanc notamment lors des Rétrospectives Globales LeSS. Mais avant d’aller plus loin, voici la ''première loi de réalisation d’un diagramme''.

<blockquote>'''The primary value in diagrams is in the discussion while diagramming—we model to have a conversation.'''
</blockquote>
<blockquote>'''La première valeur d’un diagramme c’est la discussion qui se déroule lors de la réalisation du diagramme - nous modélisons pour avoir une conversation.'''
</blockquote>
When a group gets together to sketch a causal loop diagram on a whiteboard (See it is the the acts of discussing and thinking that are most important when diagramming, Valtech India.), the primary value is the conversation and shared understanding they arrive at while creating the model. Its visualization as an easy-to-see diagram ''is'' important to make concrete and unambiguous (on the whiteboard) the ideas—the mental models people have—because words alone can be fuzzy and misunderstood. But still, the diagram is secondary to what people take away: learning and a revised understanding through a discussion.

Lorsqu’un groupe se rassemble pour dessiner un diagramme de boucles causales sur un tableau blanc (« C’est l’acte de discuter et de réfléchir qui est le plus important lorsque nous dessinons », Valtech India.), la première valeur d’un diagramme c’est la conversation et la compréhension commune à laquelle les personnes arrivent lors de la création du modèle. Ce qu’il en résulte à savoir un diagramme facile à comprendre est important pour rendre les idées et les modèles mentaux concrets et non ambigües (sur le tableau blanc) parce que les mots seuls peuvent être imprécis et mal compris. Toutefois, le diagramme est secondaire par rapport avec ce que les gens repartent : ils ont appris quelque chose et ont revu leur compréhension du monde à travers une discussion.

[[File:https://less.works/img/systems-thinking/xgroup,P20cld,P20modeling.jpg.pagespeed.ic.lirKMzwWbD.webp|frame|none|alt=|caption group%20cld%20modeling.jpg]]

''Doing system thinking. Sketching a causal loop diagram together—modeling to have a conversation.''

[[File:Xgroup-cld-modeling.jpg|frameless|848px|Un atelier d’approche systémique : réalisation d’un diagramme de boucles causales à plusieurs - modéliser pour avoir une conversation]]

''Un atelier d’approche systémique : réalisation d’un diagramme de boucles causales à plusieurs - modéliser pour avoir une conversation.''

''Concrete modeling tip'' : We start by writing on sticky notes to define ''variables'' . A note might read “feature velocity” or “# defects.” We place these on a whiteboard. Then we sketch causal link lines between the sticky notes. There will be (or should be) lots of rewriting, erasing, and redrawing during the modeling session. The most meaningful outcome is ''understanding'' ; in addition, some participants will want to take a digital photo of the whiteboard sketch.

''Trucs et astuces de pro pour modéliser'' : Nous commençons par écrire sur des petits papiers repositionnables les noms des ''variables'', par exemple « vélocité des ''features'' » ou « nombre d’anomalies ». Nous les plaçons ensuite sur le tableau blanc. Puis nous dessinons les liens de causalités entre les papiers . Il y aura (ou il devrait y avoir) beaucoup de réécriture, d’effaçage, de redessin lors de la session de modélisation. Le résultat le plus important d’une telle session est la ''compréhension'' - il se peut qu’à l’issue de cet atelier, certains participants voudront prendre une photo du dessin du tableau blanc.

== Seeing System Dynamics: Causal Loop Diagrams ==

== Voir les dynamiques des systèmes : les diagrammes de boucles causales ==

Causal loop diagrams are used regularly in introductions to LeSS, to help see the dynamics of what is going on in large-scale development. It is useful to understand them for that reason alone. And more useful to you, we recommend you do these together with colleagues at a whiteboard. Model to have a conversation. When? Probably during a LeSS Overall Retrospective.

Les diagrammes de boucles causales sont souvent utilisés en introduction à LeSS pour aider à voir les dynamiques de ce qu’il se passe dans du développement à grande échelle. Il est donc utile de comprendre ce type de diagrammes pour cette seule et unique raison. Et cela s’avèrera encore plus utile pour vous, si vous le faites avec vos collègues devant un tableau blanc. Vous modélisez pour avoir une conversation. Quand ? Plus probablement lors d’une rétrospective globale LeSS.

The practical aspect of this tip is more important than may first be appreciated. It is vague and low-impact to suggest “be a systems thinker.” But if you and four colleagues get into the habit of standing together at a large whiteboard, sketching causal loop diagrams together, then there is a concrete and potentially high-impact practice that connects “''be'' a systems thinker” with “''do'' systems thinking.”

L’aspect pratique de cet exercice est bien plus important que ce qu’il peut paraître au premier abord. Notre conseil d’« être un pratiquant systémique » peut vous sembler vague et sans grand impact. Mais si vous et quatre de vos collègues prenez l’habitude de vous réunir devant un grand tableau blanc, en dessinant des diagrammes de boucles causales ensemble, alors vous arriverez à faire la connexion entre « ''être'' un pratiquant systémique » avec « ''faire'' de l’approche systémique ».

The following examples seem sterile when presented in a book. But imagine you were at a whiteboard with other people and the diagrams were being sketched during a lively conversation. That’s the way we suggest ‘doing’ systems thinking.

Les exemples suivants peuvent paraître stériles car présentés dans un livre. Mais imaginez-vous à côté d’un tableau blanc avec d’autres personnes dessinant ensemble des diagrammes au cours d’une conversation animée. C’est de cette manière-là que nous suggérons de ‘ faire ’ de l’approche systémique.

====== Notation and Examples ======

====== Notation et exemples ======

Causal loop diagrams contain many elements; the following common useful subset is explored through a scenario.

Les diagrammes de boucles causales contiennent beaucoup d’éléments ; les éléments suivants sont les plus communément utilisés et sont vus en détail tout au long du scénario qui va suivre

* variables
* causal links
* opposite effects
* constraints
* goals
* reactions; quick-fix reactions
* interaction effects
* extreme effects
* delays
* positive feedback loops
* variables
* liens de causalité
* effets opposés
* contraintes
* objectifs
* réactions ; réactions solutions de contournement
* effets d’interaction
* effets extrêmes
* retards
* boucles de ''feedback'' positives

''The following simplified scenario is for a particular organization. It is not a generalization.''

''Le scénario qui suit est un scénario simplifié pour une organisation spécifique. Il ne s’agit pas d’une généralisation.''

'''Variables'''—Causal loop diagrams include ''variables'' (or stocks) such as the ''velocity (rate of delivery) of software features'' and ''number of defects'' . Variables have a measurable quantity.

'''Les variables''' - Les diagrammes de boucles causales comportent des ''variables'' (ou des stocks) telle que la ''vélocité (taux de livraison) des features'' et le ''nombre d’anomalies''. Les variables ont une quantité mesurable.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-4.png.pagespeed.ic.WpO9GKmuZP.webp|frame|none|alt=|caption systems thinking-4.png]]

[[File:Xsystems-thinking-4-fr.png|frameless|848px|1er schéma]]

'''Causal links'''—An element can have an effect on another, such as if feature velocity increases, then the number of defects increase; that is, more new code, more defects.

'''Les liens de causalité''' - Un élément peut avoir un effet sur un autre, comme par exemple si la vélocité des ''features'' augmente alors le nombre d’anomalies augmente ; autrement dit, plus de code, plus d’anomalies.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-5.png.pagespeed.ic.oPRro2SqND.webp|frame|none|alt=|caption systems thinking-5.png]]

[[File:Xsystems-thinking-5-fr.png|frameless|848px|2ème schéma]]

Now it is time to bump into ''Weinberg-Brook’s Law'' and the ''Causation Fallacy'' . It is easy to sketch a diagram; it is something else to model with insight. For example, consider the relationship between the ''number of developers'' and ''feature velocity.''

Il est temps désormais de se jeter à corps perdu dans la ''loi de Weinberg-Brooks'' et dans la ''causalité fallacieuse''. C’est facile de dessiner un diagramme, ça l’est moins que de modéliser en faisant preuve de clairvoyance comme par exemple, la relation entre le ''nombre de développeurs'' et la ''vélocité des features''.

The nature of any cause-effect relationship is actually not obvious, though it is common for people to jump to conclusions such as more developers means better velocity. Adding people late in development may ''reduce'' velocity (a sub-element of “Brooks’ Law” [Brooks95]). Or, ''more'' bad programmers could really slow you down. An argument can be made that ''removing'' terrible developers can ''improve'' velocity.

Toute relation de cause à effets est par nature obscure, même si les gens ont l’habitude de sauter sur la première conclusion venue comme par exemple plus de développeurs égale plus de vélocité. Ajouter des personnes tard au cours du développement peut ''réduire'' la vélocité (il s’agit d’une composante de la « loi de Brooks » [Brooks95]). Ou, ''davantage'' de mauvais développeurs pourrait vraiment vous ralentir. Il pourrait être objecté qu’''enlever'' des développeurs exécrables peut permettre ''d’améliorer'' la vélocité.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-6.png.pagespeed.ic.6XIYl7Vm3_.webp|frame|none|alt=|caption systems thinking-6.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-6-fr.png|frame|none|alt=|caption systems thinking-6.png]]

[[File:Xsystems-thinking-6-fr.png|frameless|848px|3ème schéma]]

'''Opposite effects'''—A causal link effect may be the same or opposite direction; if A goes up then B goes up, or vice versa. Opposite effect is shown with an ‘O’ on the line. Suppose defects going up puts a drag on the system, lowering the velocity of new features because people spend more time fixing or working around bugs.

'''Effets opposés''' - L’effet d’un lien de causalité peut aller dans la même direction ou dans la direction opposée. Si A monte alors B monte ou vice versa. L’effet opposé se souligne à l’aide d’un ‘0’ sur la ligne. Supposons que les anomalies ralentissent grandement le système, réduisant la vélocité des nouvelles ''features'' parce que les gens passent plus de temps à corriger ou à trouver des solutions de contournement aux anomalies.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-7.png.pagespeed.ic.DPGMJyX2Qf.webp|frame|none|alt=|caption systems thinking-7.png]]

[[File:Xsystems-thinking-7-fr.png|frameless|848px|4ème schéma]]

'''Constraints'''—Unless you can find people to work for free, there is a constraint on the number of developers, based upon cash supply.

'''Contraintes''' - À moins que vous ne trouviez des personnes prêtent à travailler gratuitement, il y a une contrainte sur le nombre de développeurs basé sur le budget disponible.

Constraints are ''not'' causal links. As cash supply goes up, it is not the case that the number of developers goes up.

Les contraintes ne sont ''pas'' des liens de causalité. Lorsque la montant du budget disponible augmente, ce n’est pas le cas du nombre de développeurs/

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-8.png.pagespeed.ic.gbgAIK-IsZ.webp|frame|none|alt=|caption systems thinking-8.png]]

[[File:Xsystems-thinking-8-fr.png|frameless|848px|5ème schéma]]

'''Goals and Reactions'''–People, departments, and systems have goals, such as ''higher feature velocity'' . Goals often generate pressure for people to react (or act), with the intent of achieving the goal. But since there is ''Causation Fallacy'' and ''Weinberg-Brooks’ Law'' to contend with, people should be cautious about assuming what actions will help. Now a goal and pressure for reaction is shown:

'''Buts et réactions''' - Les personnes, les départements et les systèmes ont des buts, comme par exemple avoir une ''vélocité des features plus élevée''. Les buts occasionnent souvent de la pression pour que les gens réagissent (ou agissent) dans l’intention de leur faire atteindre ce but. Mais étant donné qu’il y a la ''causalité fallacieuse'' et la ''loi de Weinberg-Brooks'' à laquelle il faut faire face, les gens devraient être prudents quant aux actions pertinentes à entreprendre. Voici un exemple de diagramme modélisant cela :

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-9.png.pagespeed.ic.yVcHbh4_-i.webp|frame|none|alt=|caption systems thinking-9.png]]

[[File:Xsystems-thinking-9-fr.png|frameless|848px|6ème schéma]]

Not only does a goal with a ''reward'' create pressure to act, but also it creates pressure to ''appear'' to be acting and achieving, due to the '''measurement dysfunction''' generated by rewards. And the measurement dysfunction can be proportional to the perceived value of the reward because people are being motivated to get a reward, not to improve the system [http://www.amazon.com/Measuring-Managing-Performance-Organizations-Dorset-ebook/dp/B00DY3KQX6/ref=sr_1_1?ie=UTF8&qid=1413596674&sr=8-1&keywords=measuring+and+managing+performance+in+organizations [Austin96]]. Notice how rewards can actually degrade system performance. Visually, the system dynamics may be…

Non seulement un but à atteindre avec une ''récompense'' au bout engendre une pression à agir, mais cela créé aussi une pression à ''faire semblant'' d’agir et à atteindre le but — les récompenses provoquent un '''dysfonctionnement des indicateurs'''. Le dysfonctionnement des indicateurs peut être proportionnel à la valeur perçue de la récompense parce que les personnes sont motivées pour avoir la récompense, non pour améliorer le système [http://www.amazon.fr/Measuring-Managing-Performance-Organizations-Dorset-ebook/dp/B00DY3KQX6/ref=sr_1_1?ie=UTF8&qid=1413596674&sr=8-1&keywords=measuring+and+managing+performance+in+organizations [Austin96]]. Remarquez bien comment et de quelle manière les récompenses peuvent dégrader la performance du système. De manière visuelle, les dynamiques d’un tel système pourrait être …

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-10.png.pagespeed.ic.39CLFp-g_9.webp|frame|none|alt=|caption systems thinking-10.png]]

[[File:Xsystems-thinking-10-fr.png|frameless|848px|7ème schéma]]

It is quite interesting that all these dynamics have been added by introduction of reward, and yet there is no necessary connection between the top part of this model and the bottom.

Il est assez intéressant de voir que toutes ces dynamiques ont été ajouté par l’introduction d’une récompense et qu’il n’y pas de connexion entre le haut et le bas de cette modélisation.

There is no guarantee that feature velocity has improved—or even been worked on.

Il n’y a aucune garantie que la vélocité des features s’améliore ou même que l’on y travaille.

Removing the reward system is a root-cause solution to the dysfunction. Another (lesser) surface countermeasure is the lean-thinking ''Go See'' (go see physically at the place of real work) principle and management behavior:

Enlever le système de récompense est une solution à la cause racine de ce dysfonctionnement. Une autre contremesure de surface est le principe et le comportement managériale ''Aller voir'' (aller voir physiquement sur le lieu où le travail s’effectue) de l’approche lean.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-11.png.pagespeed.ic.NU8SjnJkUY.webp|frame|none|alt=|caption systems thinking-11.png]]

[[File:Xsystems-thinking-11-fr.png|frameless|848px|8ème schéma]]

'''Quick-fix reactions'''—One difficult and slow solution toward the goal of higher velocity is to hire great developers, to increase coaching and education of existing staff, and to remove terrible workers. The alternative is called a ''quick fix'' , a reaction that is hoped to achieve the goal quickly and with less effort. Sometimes a quick fix works well both in the short and long term, really strengthening the system. Sometimes not…hence, “faster is slower.” For example, people may ''believe'' that increasing the number of developers increases the feature velocity. And they may thereby hope that hiring more developers will most quickly and easily solve the velocity problem. ‘QF’ indicates the quick fix:

'''Solutions de contournement''' - Une solution payante à long terme pour atteindre une vélocité plus grande, qui n’est pas sans difficulté, consiste à : recruter de développeurs très qualifiés, faire davantage d’accompagnements et de formations, et à se séparer des moins bons éléments. L’alternative est ce que l’on appelle une ''solution de contournement'', c’est ce que l’on met en place dans l’espoir d’atteindre l’objectif en moins de temps et avec moins d’effort. Parfois, une solution de contournement se révèle payante aussi bien dans le court terme que dans le long terme, renforçant par la-même le système. D’autres fois cela ne fonctionne pas … d’où l’expression « aller plus vite c’est aller plus lentement ». Par exemple, les gens peuvent ''croire'' qu’augmenter le nombre de développeurs permet d’augmenter la vélocité des features. Et ils peuvent par conséquent être amenés à espérer qu’en recrutant davantage de développeurs cela permettra de résoudre plus vite et plus facilement le problème de vélocité. La mention ‘SC’ sur le diagramme ci-dessous indique une solution de contournement.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-12.png.pagespeed.ic.x8IJWKprUx.webp|frame|none|alt=|caption systems thinking-12.png]]

[[File:Xsystems-thinking-12-fr.png|frameless|848px|9ème schéma]]

'''Interaction effects'''—There is the constraint of cash supply on hiring. One hard and slow solution is to get more cash. A quicker fix is to hire ''much'' cheaper developers. In this case, the level of cash supply now has an ''interaction effect'' with other causal links. Low cash tends to strengthen the hire rate of much cheaper developers when there is pressure to increase hire rates.

'''Effets d’interaction''' - La capacité à embaucher est contraint à la capacité budgétaire. Une solution de longue haleine non sans difficulté est d’obtenir davantage de budget. Une solution de contournement possible est de recruter un ''grand'' nombre de développeurs bon marché. Dans ce cas, le niveau du budget a un ''effet d’interaction'' avec les autres boucles causales. Un budget peu élevé aura tendance à renforcer le taux de développeurs bon marché si la pression pour recruter augmente.

One could simply draw an (opposite) causal link directly from ''cash supply'' to ''hire rate of very cheap developers'' , but that merely says that less cash leads to more hiring of extremely cheap developers. That is not quite what we want to say; rather, we want to show the interaction effect—that effect A influences ''effect'' B. This is done by showing a causal link entering another causal link. For example, from ''cash supply'' to the quick-fix line going into ''hire rate of very cheap developers'' :

Nous pourrions dessiner simplement un lien de causalité (opposé) de ''rentrée budgétaire'' à ''taux de recrutement de développeurs bon marché'', mais cela voudrait simplement dire qu’avoir un budget moindre aurait pour conséquence de recruter davantage de développeurs bon marché. Mais ce n’est pas tout à fait ce que nous voulons dire ; ce que voulons montrer en fait, c’est l’effet d’interaction - c’est-à-dire qu’un effet A influence un ''effet'' B. Cela se fait en montrant un lien de causalité heurtant un autre lien de causalité, par exemple en traçant une ligne de ''rentrée budgétaire'' vers la ligne représentant la solution de contournement qui va vers ''taux de recrutement de développeurs bon marché''.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-13.png.pagespeed.ic.LvAE8ewRFJ.webp|frame|none|alt=|caption systems thinking-13.png]]

[[File:Xsystems-thinking-13-fr.png|frameless|848px|10ème schéma]]

'''Extreme effects'''—We have worked with some very inexpensive developers with excellent skill and some very expensive developers that are terrible, but on average, you get what you pay for—when you hire from a large pool of very cheap labor, the average skill level is lower. In the model we want to show that the impact of hiring very cheap labor on the ''number of low-skilled developers'' is a significantly greater effect than average.

'''Effets extrêmes''' - Il nous est arrivé de travailler avec d’excellents développeurs très bon marché et avec d’autres hors de prix très nuls, mais en moyenne, vous obtenez à hauteur de ce que vous payez - lorsque vous recrutez au moins disant, le niveau moyen en terme de compétences sera plus faible. Dans le diagramme ci-dessous, nous avons voulu montrer que l’impact du recrutement de personnes bon marché en rapport avec le ''nombre de développeurs peu qualifiés'' à un impact sensiblement plus grand que la moyenne.

To show an ''extreme effect'' in the model, use a thick line:

Pour montrer un ''effet extrême'' sur un modèle, faites un trait épais comme vous pouvez voir ci-dessous :

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-14.png.pagespeed.ic.JYkqz8Qe24.webp|frame|none|alt=|caption systems thinking-14.png]]

[[File:Xsystems-thinking-14-fr.png|frameless|848px|11ème schéma]]

'''Delays'''—One problem in hiring in software development is the ''fallacy of mild programmer variance'' —the mistaken belief that programmer variance (in terms of productivity, code quality, etc.) is relatively small. However, programmer variance studies suggest an average of four times faster in the top versus bottom quartile [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.4788 [Prechelt00]]. Rather significant. Also, the COCOMO model—based on large and longitudinal studies—shows that the capability of the development personnel is by far the most important factor for productivity [http://www.amazon.com/Software-Cost-Estimation-Cocomo-II/dp/0130266922/ref=sr_1_1?ie=UTF8&qid=1413597244&sr=8-1&keywords=Software+Cost+Estimation+with+Cocomo+II [Boehm00]]. And, on average, very weak programmers create poor-quality code (poor design) and more defects, creating another drag on the system.

'''Retards''' Un problème courant au niveau du recrutement dans un projet de développement logiciel concerne ''l’erreur au niveau de la variance d’un développeur moyen'' - autrement dit la croyance fausse que la variance d’un développeur à un autre (en terme de productivité, de qualité de code, etc.) est relativement faible. Toutefois, les études de la variance au sujet des développeurs montrent un rapport de un à 4 entre le 1er quartile et le dernier [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.4788 [Prechelt00]]. C’est plutôt quelque chose de significatif. De même des études - en long et en large - du modèle COCOMO montrent que la capacité du développement personnel est le facteur de loin le plus important quant à la productivité [http://www.amazon.com/Software-Cost-Estimation-Cocomo-II/dp/0130266922/ref=sr_1_1?ie=UTF8&qid=1413597244&sr=8-1&keywords=Software+Cost+Estimation+with+Cocomo+II [Boehm00]]. Et, en moyenne, il s’avère que les développeurs peu qualifiés font du code de mauvaise qualité (mauvaise conception) et de plus d’anomalies, ceci rajoute un autre frein au système.

But the impacts of these effects are not immediately obvious. For example, it takes a relatively long time after hiring a large pool of weak programmers before the impacts of more and more bad code/design start to be felt. Similarly, the average ''decrease'' in feature velocity (because of the powerful impact of programmer variance) will not show up immediately.

Mais l’impact de ces effets ne sont pas visibles immédiatement. Par exemple, cela peut prendre un certain temps après un recrutement massif de développeurs peu qualifiés avant que les impacts négatifs ne se fassent sentir au niveau de la qualité du code ou de la conception. De manière similaire, la ''baisse'' moyenne de la vélocité des features (en raison de l’impact important de la variance des développeurs évoqué plus haut) ne se verra pas immédiatement.

To show these ''delayed effects'' in the model, use a double-line through the effect line:

Pour montrer ces ''effets à retardement'' dans le modèle, faites une double-ligne en travers de la ligne d’effet.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-15.png.pagespeed.ic.0fwliLJm6G.webp|frame|none|alt=|caption systems thinking-15.png]]

[[File:Xsystems-thinking-15-fr.png|frameless|848px|12ème schéma]]

Delay has an intriguing influence on the ''educational'' or corrective power in a system. If an impact or unintended consequence is long delayed, one does not feel the effect (pain or gain) and so does not clearly see how A influenced B, or more subtly how ''A influenced B influenced A'' .

Le retard a une influence intéressante sur le pouvoir ''pédagogique'' ou correctif sur un système. Si un impact ou une conséquence inattendue est retardé suffisamment longtemps, personne n’en voit ni l’effet (qu’il soit bénéfique ou néfaste) ni sur la façon dont A influence B ou plus subtilement comment ''A a influencé B qui a influencé A''.

Therefore, one does not learn from or correct mistakes—in policy, management actions, tools, and so forth. Likewise, gradual improvement through the lean thinking practice of ''kaizen'' can take a long time; patience and insight are needed to see if and how things improve.

Par conséquent, personne n’apprend de ses erreurs ni n’est en capacité de les corriger - que ce soit en terme de stratégie, d’actions d’encadrement, d’outils ou de quoi que ce soit. De la même manière, l’amélioration graduelle à travers l’application d’une démarche lean ''kaizen'', peut prendre un certain temps ; de la patience et de la perspicacité sont nécessaires pour voir si et comment les choses s’améliorent.

'''Positive feedback loops'''—Negative or positive feedback loops[https://less.works/less/principles/systems-thinking.html#footnote-5 5] and delays are where things start to get more subtle in a system—and in understanding a system. For example, how does one become a better programmer? In part, by mentoring from great programmers and seeing lots of examples of great code. But an office with a lot of low-skill developers does not generate a lot of great code examples, nor does it attract or retain the small pool of great programmers who could act as mentors. They would rather work somewhere else.

'''Boucles de feedback positives''' - Les boucles de feedback négatives ou positives [^5] et les retards sont le point de départ pour une approche plus subtile d’un système - et de sa compréhension. Par exemple, de quelle manière une personne peut-elle devenir un meilleur développeur ? En partie, en bénéficiant du mentorat de très bons développeurs et en jetant un œil sur du très bon code. Mais il est impossible de trouver du bon code dans un endroit remplit de développeurs médiocres, il est impossible également d’y attirer ou de retenir le petit groupe de très bon développeurs qui pourraient prendre le rôle de mentors. Ils préfèrent largement aller travailler ailleurs.

Now the development group starts to enter a self-reinforcing downward spiral—a set of ''positive feedback loops'' . Fortunately, the downward trend is constrained by the supply of cash.

Ce groupe de développeurs médiocres rentrent dans un cercle vicieux en raison d’un ensemble de ''boucles de feedback positives''. Fort heureusement, ce cercle vicieux est assujeti aux contraintes du budget.

More great programmers—who could craft great code and mentor others—leave. So there is less and less quality code to look at and to learn from. The percentage of weak programmers grows even larger and feature velocity drops further. Code becomes more messy, awkward, and duplication-riddled, so the capacity to swiftly implement features declines. Since feature velocity is dropping further, there is more pressure to hire yet more very cheap programmers. All this leads to multiple positive reinforcement loops in the system, for example:

Malheureusement de plus en plus des très bons développeurs - ceux en capacité d’élaborer du très bon code et de faire du mentorat auprès des autres développeurs - partent. Par conséquent, il y a de moins en moins de code de qualité à regarder et à partir duquel il est possible d’en tirer des enseignements. Le pourcentage de développeurs médiocres augmente de plus en plus et la vélocité au niveau des features continue à chuter. Le code devient de plus en plus brouillon, difficile, avec pleins de bouts de code dupliqués à gauche et à droite, le tout de telle manière que la capacité d’implémenter des features décline. Étant donné que la vélocité des features continue de chuter, il y a davantage de pression pour recruter des développeurs très bon marché. Tout cela conduit à de multiples boucles de renforcement positives dans le système comme l’illustre l’exemple ci-dessous :

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-16.png.pagespeed.ic.ONFuUmJHSE.webp|frame|none|alt=|caption systems thinking-16.png]]

[[File:Xsystems-thinking-16-fr.png|frameless|848px|13ème schéma]]

''Tip'' : You can find positive feedback loops by finding cycles with an ''even number'' of ‘Opposite’ effect relationships. There are several examples in the model above.

''Astuce'' : Vous pouvez trouver des boucles de feedback positives en cherchant des cycles ayant un ''nombre pair'' de relations. Vous en trouverez plusieurs exemples ci-dessus.

===== Conclusion =====

===== Conclusion =====

The example scenario is only that—an example. A causal loop diagram can visualize rich dynamics in a workplace system. These are best created by a group at a whiteboard.

Le scénario donné à titre d’exemple est uniquement cela - un exemple. Une diagramme de boucle causale permet de visualiser la richesse de la dynamique dans le système dans un milieu professionnel. La meilleure manière de modéliser un tel système est de le faire en groupe face à un tableau blanc.

== Seeing Mental Models ==

== Voir les modèles mentaux ==

The previous causal loop diagrams reflect people’s mental models of causation, which may be wrong. It is interesting to note that people’s models of causation are influenced by the timeliness (delay) and quality of feedback in the system.

Les précédents diagrammes de boucles causales reflètent les modèles mentaux de causalité des individus … qui peuvent s’avérer faux. Il est intéressant de remarquer que les modèles de causalité des individus sont influencés par la ponctualité (ou les retards) et la qualité des feedbacks dans le système.

The implication of “mental models” is to improve our meta-cognitive skill to see and question our own assumptions and chains of reasoning. Are we making faulty leaps of logic? It also implies when working with others to discuss (inquiring rather than abusing) the mental models of our colleagues.

Les « modèles mentaux » nous permettent d’améliorer nos compétences de méta-cognition pour voir et questionner nos propres postulats et l’enchaînement de nos raisonnements. Brûlons-nous des étapes de manière erronée ? Cette question implique aussi lorsque nous sommes en train de travailler avec des collègues de discuter avec eux (en s’enquérant plutôt qu’en reprochant) de leurs modèles mentaux.

''Seeing'' these mental models is step one; ''changing'' them is the even harder part of step two. That art is beyond the scope of this introduction, though a successful LeSS adoption must involve changes in mindset and insight among many groups.

''Voir'' les modèles mentaux n’est que la première étape ; les ''changer'' constitue une seconde partie bien plus difficile. Cet art est bien au-delà du sujet de cette introduction, même si une adoption réussie de LeSS implique des changements en terme d’état d’esprit et de prise de conscience au sein de très nombreuses équipes.

A tip to better ''see'' the mental models (beliefs, chains of inference, …) playing out in the system dynamics is to ask the following question during a modeling workshop and then sketch the answers. “Let’s talk about the assumptions behind this model. What do we ''believe'' or assume in terms of facts and effects that led us here?”

Une astuce pour mieux ''voir'' les modèles mentaux (croyances, échelle d’inférence, …) en jeu au niveau des dynamiques des systèmes est de poser les questions suivantes lors d’un atelier de modélisation puis de tracer les éléments de réponse au tableau blanc. « Parlons donc des hypothèses derrière ce modèle. Que ''croyons''-nous ou tenons pour acquis en terme de faits et d’effets qui nous ont conduits ici ? »

Answers are sketched on the whiteboard model, for example:

Les éléments de réponse sont dessinés sur le tableau blanc. En voici un exemple :

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-17.png.pagespeed.ic.5UIqBnJfK1.webp|frame|none|alt=|caption systems thinking-17.png]]
Visualizing the assumptions in our heads… our mental models.

[[File:Xsystems-thinking-17-fr.png|frameless|848px|14ème schéma]]
''Visualiser les postulats présents dans nos têtes … nos modèles mentaux.''

=== Example: The “Faster is Slower” Dynamic ===

=== Exemple : La dynamique « Aller plus vite c’est aller plus lentement » ===

With the vocabulary of quick fixes, delays, positive feedback loops, and mental models, it is fascinating to see that there can be a short-term apparent improvement in a variable as the result of a quick fix, but a ''delayed degradation'' of the very same variable—the “faster is slower” dynamic. This is a recurrent dynamic in the workplace and a cause of weakness. So it is worth another illustration.

Dorénavant, avec notre vocabulaire enrichi des termes de solutions de contournement, de boucles de feedback positives et de modèles mentaux, il est fascinant de voir qu’il peut y avoir un semblant d’amélioration à court terme sur une variable donnée, mais que cela entraîne en même temps une ''dégradation à retardement'' de cette même variable - d’où la dynamique « Aller plus vite c’est aller plus lentement ». Il s’agit d’une dynamique récurrente et d’une cause de vulnérabilité à terme. Voici un nouvel exemple illustrant cela :

''The story of Microsoft Word and the'' '''''secret developer toolbox''''' : A classic example of the short-term ‘improving’ but long-term degrading dynamic is the story of the first release of Microsoft Word for Windows [http://www.amazon.com/Joel-Software-Occasionally-Developers-Designers/dp/1590593898/ref=sr_1_1?ie=UTF8&qid=1413597951&sr=8-1&keywords=Joel+on+Software [Spolsky04]]. It was released ''years'' later than desired. Why? ''Because managers tried to follow the original schedule and pushed developers to meet it'' .

''Histoire de Microsoft Word et de'' '''''la boîte à outils secrète du développeur''''' : Un exemple typique d’une ‘amélioration’ à court terme mais d’une dynamique de dégradation à long terme est le récit de la première livraison de Microsoft Word sur Windows [http://www.amazon.com/Joel-Software-Occasionally-Developers-Designers/dp/1590593898/ref=sr_1_1?ie=UTF8&qid=1413597951&sr=8-1&keywords=Joel+on+Software [Spolsky04]]. Le logiciel a été livré avec des ''années'' de retard par rapport à la date prévue. Pourquoi ? ''Parce que les managers ont essayé à tout prix de suivre le calendrier de départ et ont fait pression sur les développeurs pour le respecter''.

The story illustrates why ''wishful thinking'' is identified as one of the wastes in lean thinking. In this case the wishful thinking of insisting on (apparently) following a schedule, which implies the misconception or wishful thinking that development estimates are not estimates but are commitments—a common myth that propels degradation of a system.

Cette histoire illustre pourquoi cet espoir illusoire de respecter une date souhaitée est bien identifié comme une source de gâchis dans l’approche lean. Dans le cas présent l’espoir illusoire consiste à insister (du moins apparemment) à suivre le calendrier, ce qui implique une idée fausse ou illusoire que les estimations ne sont pas de simples estimations mais des promesses - un mythe classique qui pousse à la dégradation d’un système.

[https://less.works/less/principles/systems-thinking.html#figure-1 The next model] illustrates a ''summary'' of the dynamics of what happened when the managers pushed people to evidently keep to the original schedule, and why this quick-fix reaction to slow progress appeared to make things faster in the short term but actually even ''slower'' in the long term. See the dynamic of schedule pressure and the secret toolbox. intentionally omits some deeper dynamics that are expanded and shown in See deeper dynamics of schedule pressure and the secret toolbox..

[https://less.works/less/principles/systems-thinking.html#figure-1 Le modèle suivant] illustre un ''résumé'' des dynamiques à l’œuvre lorsque des managers poussent leurs équipes à respecter à tout prix les calendriers prévisionnels, et pourquoi cette solution de contournement qui freine pourtant l’avancement des travaux semblent les faire aller plus vite à court terme mais en réalité ''plus lentement'' à long terme. Par rapport à ce qui est décrit précédemment dans la dynamique de la pression du calendrier et la boîte à outils secrète, certaines dynamiques ont été omises intentionnellement sur ce schéma et sont visibles sur le schéma dynamiques avancées.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-18.png.pagespeed.ic.A7OSuu755I.webp|frame|none|alt=|caption systems thinking-18.png]]
The dynamic of schedule pressure and the secret toolbox.

[[File:Xsystems-thinking-18-fr.png|frameless|848px|15ème schéma]]
''Dynamique de la pression sur le calendrier et de la boîte à outils secrète.''

As a quick fix, the Microsoft managers exhorted, bribed (with potential rewards), and threatened the Word developers to keep to the original schedule. Consequently, the developers predictably pulled out their '''secret developer toolbox''' —the many practices related to hacking out dirty code (no tests, no reviews, ignore known defects, copy-paste programming, poor design, …) to apparently deliver a feature faster. You see, developers also have ''quick-fix'' reactions for their problems.

En solution de contournement, les managers de Microsoft ont exhorté, ont corrompu (à l’aide de primes potentielles), et ont menacé les développeurs de Word pour leur faire respecter le calendrier prévisionnel. En conséquence, les développeurs ont, de manière tout à fait prévisible, sorti leur '''boîte à outils secrète de développeurs''' - autrement dit tout un arsenal de pratiques pour pisser du code pourri (aucuns tests, aucunes revues, ignorance des anomalies connues, développement par copier-coller, mauvaise conception, …) pour développer visiblement plus vite. Vous voyez bien, les développeurs ont aussi des solutions de contournement pour régler leurs problèmes.

The tactics seemed to have worked like magic. As the managers pressured the developers, ‘features’ were delivered quicker as people used the secret toolbox, which reinforced the belief that pressuring developers helps. But this apparent acceleration actually had a delayed effect to make things slower, which is explored next. Since management did not quickly see the delayed effect of the secret toolbox, and because they believed managers should not be frequently looking in detail at the source code or themselves be master programmers, they did not learn from this dynamic.

Vu de l’extérieur, ces tactiques ont fonctionné à merveille. Au fur et à mesure que les managers mettaient la pression sur les développeurs, les ‘features’ étaient développées de plus en plus vite grâce à l’utilisation de la boîte à outils secrète, ce qui a renforcé la croyance en quoi mettre la pression sur les développeurs était quelque chose d’utile. Mais cette apparente accélération a eu en fait un effet à retardement qui a rendu les choses plus lentes (c’est ce que nous allons voir par la suite). Étant donné que le management n’a pas été assez rapide à voir l’effet à retardement de la boîte à outils, et parce que les managers pensent qu’ils n’ont pas besoin d’aller regarder fréquemment en détails le code source ou qu’ils n’ont pas besoin d’être eux-mêmes des développeurs très expérimentés, ils n’ont rien appris de cette dynamique.

A closer exploration of the system dynamics shows why things went slower in the long term and why the first Word for Windows release was years later than desired, illustrated in this model…

Le schéma ci-dessous illustre l’examen approfondie des dynamiques des systèmes montrant pourquoi les choses sont allées plus lentement à long terme et pourquoi le tout premier Word pour Windows a été livré des années en retard par rapport à la date souhaitée …

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-19.png.pagespeed.ic.D24dvGHzfu.webp|systems thinking-19.png]]
Some deeper dynamics of schedule pressure and the secret toolbox.

[[File:Xsystems-thinking-19-fr.png|frameless|848px|16ème schéma]]
''Dynamiques avancées de la pression sur le calendrier et de la boîte à outils secrètes.''

Naturally, lots of dirty code eventually slowed things down. More subtly, developers would ''ignore'' the bug list of ever-increasing open defects to—instead—generate new features. This led to a long delay between the creation of a defect and its correction. It turns out that this significantly increases variability and time to fix a defect because of the compounding negative effect of a long-lived bug (for example, due to workarounds and coupling) and because developers have long forgotten the detailed context of code related to the defect and therefore need to slowly rediscover that context—with more and more dirty confusing code surrounding them.

Naturellement, avoir une grande quantité de code de mauvaise qualité ralentie les choses. De manière beaucoup plus subtile, les développeurs ont ''ignoré'' la liste croissante d’anomalies pour privilégier la production de nouvelles features. Cela a eu pour conséquence d’avoir un délai important entre la déclaration d’une anomalie et sa correction. Il s’avère que cela a fait augmenter de manière significative la variabilité et le temps nécessaire pour corriger une anomalie en raison des effets cumulatifs négatifs liée à la nature même d’une vieille anomalie (par exemple avec la mise en place des solutions de contournement et des couplages existants entre les fonctionnalités), de l’oubli du contexte détaillé par les développeurs en relation avec l’anomalie, ces derniers mettant par conséquent plus de temps à le redécouvrir, de l’accumulation continue de code de mauvaise qualité dans le même temps.

The astute reader may also notice the several positive feedback loops that reinforce the degradation cycle; this is one reason the product was years later than intended.

Le lecteur avisé remarquera également plusieurs boucles causales positives renforçant le cycle de dégradation ; il s’agit de l’une des raisons expliquant le retard pris sur plusieurs années pour livrer le produit.

Solution? The lean thinking ''Stop and Fix'' and ''Go See'' principles. ''First'' , rather than trying to go faster when there are problems, manager-teachers encourage people to go ''slower'' and help them learn to see system dynamics and root causes, and to fix these—to improve the ''system'' of development. By going slower, Toyota—the masters of lean thinking—has become one of the fastest companies around. ''Second'' , for managers to ''go see at the real place of work'' to learn what is going on. The “real place” in software development is the code, which suggests that first-level managers are master programmers who are frequently evaluating the code.

Une solution ? L’approche lean avec les principes ''Arrêter et corriger'' et ''Aller voir''. ''Premièrement'', plutôt que d’essayer d’aller plus vite lorsqu’il y a des problèmes, des managers-formateurs encouragent les gens à aller plus ''lentement'' et à les inciter à apprendre les dynamiques des systèmes, les causes racines et à les corriger pour améliorer le ''système'' du développement. En allant plus lentement, Toyota - les maîtres de l’approche lean - est devenue l’une des entreprises les rapides du monde. _Deuxièmement, les managers doivent ''aller voir ce qui se passe sur le vrai lieu de travail'' pour apprendre ce qu’il se passe. Le « vrai lieu » dans le développement logiciel c’est le code, ce qui implique que les managers de proximité sont des développeurs expérimentés qui évalueront le code fréquemment.

Microsoft people did not reflect on the situation until after release. When they did finally hold a retrospective, it led to a ''zero-defects'' policy, meaning that the first priority was to fix known bugs in the code under development—to drive down to zero the open-defects list before writing more new-feature code.

Les personnes de chez Microsoft n’ont pas réfléchi sur la situation que bien après la livraison. Lorsqu’ils ont fini par faire une rétrospective, cela a amené à une politique du ''zéro défaut'', cela signifie que la première priorité était de corriger les anomalies connues dans le code en cours de développement afin d’aller vers du zéro anomalie ouverte dans la liste des anomalies avant d’écrire du code pour une nouvelle feature.

== Seeing (and Hearing) Local Optimization ==

== Voir (et entendre) l’optimisation locale ==

“Everyone is doing their best yet overall systems throughput is degrading. How can that be?” This is the paradox of '''local optimization''' —when a person or departmental decision maker optimizes for the local view or self-interest. The party making the decision frequently ''believes they are making the best decision'' , but because ‘best’ is a local optimization, in fact it sub-optimizes overall system throughput. This is a result of “silo mentality,” misunderstanding, fear, limited information, delayed feedback, ignorance, careerism, avarice, and other common ''organizational learning disorders'' .

« Chacun fait de son mieux, mais malgré tout le flux de production du système se dégrade. Comment cela est-il possible ? ». Il s’agit du paradoxe de '''l’optimisation locale''' - autrement dit c’est lorsqu’une personne à titre individuel ou un responsable de département prend une décision d’un point de vue local ou dans son propre intérêt. Les personnes prenant ce type de décision ''croient fréquemment qu’ils prennent la meilleure décision'', mais parce que ‘meilleure’ est ici synonyme d’optimisation locale, cela a pour résultat une sous-optimisation globale du flux du système. Ceci est le résultat d’une « mentalité de silo », d’incompréhension, de peur, de restrictions d’informations, de feedbacks à retardement, d’ignorance, de carriérisme, d’avarice et de bien d’autres ''dysfonctionnements d’apprentissages organisationnels''.

A small product group of 30 people does not have the time or money to engage in much nonsense or waste. But large companies, with large product groups, centralized process and tool groups, a centralized “project management office,” and so forth, seem to have raised local optimization and waste to an art form. Government bureaucracies are the quintessential example, of course. As such, when you serve as a guide in large-scale agile adoption, ''seeing'' (or ''hearing'' ) and dealing with local optimization is singularly vital.

Une petite équipe produit de 30 personnes n’a ni temps ni l’argent pour s’engager dans ce genre de non-sens ou de gâchis. Mais les grandes entreprises avec de grands groupes produit, des processus centralisés et des groupes outils, un « bureau de gestion de projet » centralisé, et ainsi de suite, semblent avoir élevé l’optimisation locale et le gâchis à une forme d’art. Les bureaucraties gouvernementales en sont bien sûr la quintessence. En conséquence, lorsque vous servez de guide dans une adoption agile à grande échelle, ''voir'' (ou ''entendre'') et s’occuper de l’optimisation locale est tout simplement quelque chose de vital.

For example, the legal and corporate security departments put in place a policy that seems terribly important from their perspective. In the aim of preventing loss of intellectual property (IP), the legal department decrees “no one shall put any information on the walls.” Or, in response to cost-cutting pressure, the facilities management says, “It is important to ensure our walls are not dirty or damaged.” And thus they shut down a practice in lean thinking, visual management (which is usually done on walls), and they inhibit a well-known innovation practice, group whiteboard work. The lawyers may succeed in reducing loss of IP (actually, that is questionable), and the facilities people will succeed in keeping the walls clean—at the cost of inhibiting the product development group from innovating and collaborating. Finally, the company falls behind with less and less IP even worth protecting because tools for innovation and delivering fast have been disallowed, but the lawyers have successfully fulfilled their mandate from the executive team to “ensure our IP is protected.” And the ''furniture police'' have clear walls. ''They have done their best'' .

Par exemple, les départements juridiques et sécurité mettent en place des politiques qui leurs semblent très importantes de leurs points de vue. Dans l’objectif de prévenir la perte de propriété intellectuelle, le département juridique peut décréter « il est interdit d’afficher tout type d’information sur les murs. ». Or, le département des immeubles soumis de son côté, à une pression de politique de réductions de coûts peut surenchérir en disant : « Il est important de s’assurer que nos murs ne soient ni sales ni abîmés ». Et ainsi s’arrête le management visuel qui est l’une des pratiques de l’approche lean (le management visuel se faisant habituellement sur les murs), et ils inhibent également une pratique d’innovation bien connue à savoir le travail de groupe devant un tableau blanc. Les juristes réussiront peut être à réduire la perte de propriété intellectuelle (ce qui en réalité devrait poser question), et les gens des immeubles réussiront à garder leurs murs propres - mais au prix d’inhiber le groupe de développement produit dans sa capacité d’innover et de collaborer. Finalement, l’entreprise se laissera distancer par la concurrence avec de moins en moins de propriété intellectuelle valant la peine d’être défendue parce que les outils permettant l’innovation et de livrer rapidement ont été bannis, mais les juristes auront rempli leur mandat vis-à-vis de la direction de « s’assurer que la propriété intellectuelle est protégée ». Et la police de la logistique aura nettoyé les murs. ''Ils ont fait de leur mieux''.

The following is a real e-mail quote from the ''FURNITURE POLICE'' in one organization that dissallowed visual management on the walls. Can you identify the local optimizations and mental models driving this?

Ce qui suit est extrait d’un vrai message électronique de la ''POLICE DE LA LOGISTIQUE'' dans une organisation qui a banni le management visuel sur les murs. Pouvez-vous identifier les optimisations locales et les modèles mentaux qui sont derrière tout ça ?

<blockquote>''Individual work cubic partition can be personalized. But things obvious higher than the partition or harming the office environment’s harmony are restricted.''
</blockquote>
<blockquote>_Les [https://fr.wikipedia.org/wiki/Bureau_%C3%A0_cloisons bureaux à cloisons] peuvent être personnalisés. Mais tout ce qui visible au-dessus de la cloison ou qui perturbe l’harmonie de l’environnement de bureau est interdite.
</blockquote>
We also see local optimization in centralized groups that make software tool choices for others. The common mindset is to choose a tool that is best at reducing some supposed cost (curiously, these groups seldom recommend free open source tools) or best at doing something complicated or best for the work of one specialized worker role (even though ''everybody'' has to use the tool), rather than maximizing the global goal of faster system throughput of value to customers.

Nous constatons aussi des optimisations locales dans les groupes centralisés dont le rôle est de choisir les logiciels pour les autres personnes de l’entreprise. La croyance la plus répandue que cette démarche est qu’il s’agit de ce qu’il y a de mieux pour réduire les coûts d’achats (curieusement ces mêmes groupes recommandent rarement les logiciels libres gratuits) ou ce qu’il y a de mieux pour accomplir une tâche compliquée ou ce qu’il y a de mieux pour l’accomplissement du travail d’un seul type de travailleur (même si ''tout le monde'' est censé devoir utiliser l’outil), plutôt que de maximiser l’objectif de l’entreprise qui est d’avoir un système de flux de production de la valeur plus rapide pour les clients.

In large-scale adoption of Scrum or agile principles, most of the “Yes, but …” issues that are raised are examples of local optimization, such as, “''Yes, but…what about management reporting''?” or more generally, “''Yes, but…what about <special case="">''?” Then, policies and practices are twisted around, serving the goal of reporting or some other secondary aim rather than the primary goal of optimizing for fast value throughput. Sometimes we see ''local optimization for the extreme or rare case'' . For example, a person responsible for making a centralized tool choice for the enterprise presents a scenario for a complex or rare case of use, and then chooses the tool that fits that, sub-optimizing for a 5 percent case instead of optimizing for ease and speed for the 95 percent case.</special>

Dans les adoptions de Scrum ou des principes agiles à grande échelle, la plupart des problématiques de type « Oui, mais … » qui sont soulevées sont des exemples de sous-optimisations, comme par exemple « ''Oui, mais … qu’en est-il des comptes-rendus auprès du management'' ? » ou encore de manière plus générale « * Oui, mais … qu’en est-il de … * ? ». Alors, les principes et les pratiques sont dévoyés, pour servir soit l’objectif de rendre compte soit n’importe quel autre objectif secondaire plutôt que suivre l’objectif d’optimiser le flux de valeur produite. De temps en temps, nous voyons des '''optimisations locales dans certains cas rares ou extrêmes'''. Par exemple, une entreprise doit choisir un outil centralisé répondant à un certain nombre de cas d’utilisations possibles dont un cas extrêmement rare ou complexe, la personne, en charge de faire ce choix, choisit un outil correspondant à un cas unique d’utilisation, sous-optimisant ainsi l’ensemble du système pour un cas représentant uniquement 5% des cas d’utilisation au lieu de l’optimiser pour la majorité des 95% des autres cas d’utilisations.

Other local optimizations are due to ignorance of new ways of working. This is especially common in large-scale product groups. For example, we once helped a large networking product group in Europe adopt Scrum and the practice of ''continuous integration'' (CI) combined with a CI system that continually integrated, built, and automatically tested the product. After some time, an outside traditional manager inspected what was going on, and recommended the integration practices should be changed—because there was no written integration plan for how a human integration manager should manually integrate all the software, and of course, there was no integration manager. They wanted to ‘optimize’ around the work of an integration manager that was no longer needed. They could not see that their entire old-fashioned model of work had been eliminated with CI. This story repeats in all the departments of a large established product: local optimization around the ''existing'' ways of work, such as manual test, a separate architecture department, component teams, and so on. A coach working to introduce large-scale Scrum at the enterprise level has a ''mountain'' of similar local optimization thinking to deal with.

D’autres optimisations locales sont dues, quant à elles, à l’ignorance des nouvelles manières de travailler. C’est quelque chose de très répandue et tout spécialement dans les groupes produit à grande échelle. Par exemple, un jour nous avons aidé un groupe produit distribué à travers l’Europe à adopter d’une part Scrum et d’autre part la pratique de ''l’intégration continue'' (CI) le tout sous la forme d’un système d’intégration continue dédié intégrant, compilant, testant automatiquement de manière continue le produit. Après quelques temps, un manager, que l’on pourrait qualifier de traditionnel, extérieur au groupe est venu inspecter ce qu’il se passait. Celui-ci a recommandé que les pratiques d’intégration devraient être changées en raison de l’absence de schéma d’intégration global permettant à un responsable d’intégration de faire manuellement l’intégration de l’ensemble du logiciel ; une absence de schéma pour la bonne raison qu’il n’y avait plus besoin de responsable d’intégration au sein de l’organisation. Il voulait ‘optimiser’ le travail d’un responsable d’intégration qui n’existait plus. Il était dans l’impossibilité de voir que la totalité de l’ancienne manière de faire les choses avait disparu avec l’intégration continue. Cette histoire se répéta dans l’ensemble des départements du groupe produit : il y a avait des optimisations locales partout autour des façons de faire existantes, tels que les tests manuels, le département d’architecture séparé des équipes, les équipes composants, etc. N’importe quel coach dont la tâche consistait à introduire Scrum à grande échelle au niveau de l’organisation avait une ''montagne'' d’optimisations locales à penser à gérer.

In lean thinking and agile methods, the focus is on global systems goals: Deliver value fast with high quality and morale—'''global optimization''' . Try to consider decisions in light of this goal. To develop an “optimize the whole” culture, challenge all decisions and policies with the question:

Dans l’approche lean et dans les méthodes agiles, l’accent est mis sur les objectifs du système dans sa globalité : livrer de la valeur de grande qualité au plus vite tout en gardant le moral des équipes au plus haut - autrement dit une '''optimisation globale'''. Essayer de reconsidérer vos décisions à la lumière de cet objectif. Pour développer une culture de « l’optimisation du tout », remettez donc en cause toutes les décisions et les règles avec la question suivante :

<blockquote>'''Does this decision or policy focus on delivering value to the external customer fast, or does it focus on the interests of a department, person, internal policy/practice, or rare case?'''
</blockquote>
<blockquote>** Est-ce que cette décision ou cette règle se focalise-t-elle sur livrer de la valeur au client externe au plus vite, ou se focalise-t-elle sur les intérêts d’un département, d’une personne, d’une pratique/règle interne, ou d’un cas rarissime ?**
</blockquote>
In LeSS, the Product Owner is responsible for choosing high-value goals that '''could lead to potentially shippable product (at the end of the Sprint) and that maximize the desired impacts and that delight the customer, while maintaining a sustainable pace and high engineering quality'''. That explicit goal is meant to orient the system toward global rather than local optimization.

Dans LeSS, le Product Owner est responsable pour choisir ces objectifs à haute valeur qui '''pourrait mener à un produit potentiellement livrable (à la fin du Sprint) maximisant les impacts souhaités et réjouissant le client tout en maintenant un rythme soutenable et une haute qualité d’ingénierie'''. Cet objectif explicite est destiné à orienter le système vers son optimisation globale plutôt que vers une optimisation qui ne serait que locale.

== Conclusion ==

== Conclusion ==

In addition to becoming a systems thinker yourself, encourage others to learn more about this topic. We suggest you to try getting together at a whiteboard with colleagues to sketch a causal loop diagram, so that ''being'' systems thinkers and ''doing'' systems thinking are connected at the workplace.

En plus de devenir un pratiquant de l’approche systémique vous-même, encouragez donc les autres à en apprendre plus sur ce sujet. Nous vous suggérons d’essayer de rassembler quelques-uns de vos collègues autour d’un tableau blanc et d’y dessiner des diagrammes de boucles causales, afin que les architectes des systèmes et les pratiquants de l’approche systémique soient réunis en un seul endroit.

<figure>
[[File:https://less.works/img/systems-thinking/xgroup,P20cld,P20modeling.jpg.pagespeed.ic.lirKMzwWbD.webp|group%20cld%20modeling.jpg]]
</figure>
[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-20-fr.png|frame|none|alt=|caption systems thinking-20.png]]

<figcaption>
Doing system thinking. Sketching a causal loop diagram together—modeling to have a conversation.
</figcaption>
Séance d’approche systémique. Réalisation d’un diagramme de boucle cause à plusieurs mains dans l’objectif d’avoir une conversation.

== Recommended Readings ==

== Lectures recommandées ==

* W. Edwards Deming’s [http://www.amazon.com/Out-Crisis-W-Edwards-Deming-ebook/dp/B00653KTES/ref=sr_1_1?ie=UTF8&qid=1413601625&sr=8-1&keywords=out+of+the+crisis ''Out of the Crisis''] is a master work by arguably the most well-known systems thinker and quality expert. It opens with the modest goal, “The aim of this book is transformation of the style of American management… It requires a whole new structure, from foundation upward.” Deming also advocates the ''System of Profound Knowledge'' in which managers (1) appreciate there is a ''system'' , (2) understand common-cause and special-cause variation (queueing theory is related to variation), (3) understand limitations of knowledge and reasoning mistakes, and (4) know credible psychology and social research results so that behavior- or motivation-related policies are ''not'' based on “common sense.” The core of the book centers around his famous ''14 Points for Management'' , including (for example), “''Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership'' .”
* [https://www.amazon.fr/Hors-crise-W-Edwards-Deming/dp/2717843930/ ''Hors de la Crise''] de W. Edwards Deming est un ouvrage de référence par, sans conteste, le plus connu des penseurs systémiques et des experts sur la qualité. Cet ouvrage commence par un objectif modeste : « l’objectif de ce livre est la transformation du style du management américain … ce qui exige une toute nouvelle structure de fonds en combles. ». Deming prône un ''Système de connaissances approfondies'' dans lequel les managers (1) reconnaissent qu’il y a un ''système'', (2) qu’ils sont en mesure de comprendre les facteurs les plus répandus et les facteurs spéciaux de variations au sein du système (la théorie des files d’attente est liée à ce phénomène de variation), (3) qu’ils sont en mesure de comprendre que les connaissances sont limitées et qu’il y a des erreurs de raisonnements, et (4) que la psychologie et les recherches en sciences sociales jouent des rôles tout à fait crédibles dans l’objectif de comprendre que les règles régissants les comportements ou en lien avec la motivation des individus ne soient pas basés sur le seul « bon sens ». Le cœur de l’ouvrage tourne autour des célèbres ''14 points pour le management'', y compris par exemple « ''Éliminer le management par les objectifs. Éliminer le management par les nombres, par les objectifs par les nombres. Y substituer le leadership''»
* Jay Forrester’s [http://www.amazon.com/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ref=sr_1_1?ie=UTF8&qid=1413601681&sr=8-1&keywords=industrial+dynamics ''Industrial Dynamics''] is the classic text on system dynamics—well written and insightful. Although written in the early 1960s, it is as relevant today as when published. It goes beyond cause-effect modeling to also model the flow and inventories of information, money, and material in systems. The book includes formal mathematical modeling but this is not obligatory to appreciate system dynamics.
* [https://www.amazon.fr/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ ''Industrial Dynamics''] de Jay Forrester est un classique du genre sur les dynamiques des systèmes - très bien écrit et très instructif. Même si cet ouvrage a été écrit au début des années 1960, il est toujours aussi pertinent aujourd’hui. Il va au-delà de la modélisation des causes à effets pour modéliser également le flux et les stocks d’informations, d’argent et de matériaux au sein d’un système. Le livre contient également une modélisation mathématique formelle de ces dynamiques, toutefois la lecture de cette dernière reste facultative quant à apprécier la qualité de l’ouvrage.
* Weinberg’s ''Quality Software Management: Systems Thinking'' and ''An Introduction to General Systems Thinking'' are worthwhile. Written from the perspective of an experienced consultant in systems development.
* Les ouvrages [https://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226/ ''Quality Software Management: Systems Thinking''] et [https://www.amazon.fr/Introduction-General-Systems-Thinking-Weinberg/dp/0932633498/ ''An Introduction to General Systems Thinking''] de Gerald Weinberg sont intéressants. Il sont écrits du point de vue d’un consultant expérimenté en développement de systèmes.
* Senge’s [http://www.amazon.com/Fifth-Discipline-Practice-Learning-Organization-ebook/dp/B000SEIFKK/ref=sr_1_1?ie=UTF8&qid=1413601715&sr=8-1&keywords=the+fifth+discipline ''The Fifth Discipline''] is a classic that advocates the need for leadership to apply systems thinking (it is the ''fifth'' discipline) and other key disciplines for a great, sustainable enterpise. The others include leaders with (1) personal mastery and (2) reflection on their beliefs and faulty reasoning, the (3) definition and communication of a meaningful shared vision, and (4) the ability of teams to learn. We recommend ignoring—at least during the first few years of practice—the ‘archetypes’ notion presented in the book. It was well meant as a learning aid but has been observed to distract and intimidate people from learning and applying basic system dynamics modeling. The ‘archetypes’ are not part of original system dynamics.

[https://www.amazon.fr/cinqui%C3%A8me-discipline-Levier-organisations-apprenantes/dp/2212559372/ ''La cinquième discipline''] est un autre classique du genre qui prône que l’encadrement d’une entreprise devrait appliquer l’approche systémique (autrement dit la ''cinquième'' discipline) ainsi que d’autres disciplines-clés toutes aussi importantes en vue d’obtenir une entreprise durable. Ces autres disciplines que les dirigeants devraient appliquer sont (1) une maîtrise personnelle des aspirations, (2) une réflexion sur leurs propres croyances et raisonnements erronés, (3) la définition et la communication d’une vision partagée ayant du sens, et (4) la capacité des équipes à apprendre. Nous vous recommandons d’ignorer - du moins dans un premier temps pendant vos premières années de pratiques - le concept d’archétypes présenté dans le livre. Ce concept avait pour but d’être une aide à l’apprentissage de la cinquième discipline mais nous avons observé qu’il était soit une source de distraction soit qu’il intimidait les lecteurs quant à leur apprentissage et à l’application de la modélisation des dynamiques des systèmes. Les ‘archetypes’ ne font pas partie à l’origine des dynamiques des systèmes.

* [http://www.amazon.com/Fifth-Discipline-Fieldbook-Strategies-Organization-ebook/dp/B00JTCJEO8/ref=sr_1_1?ie=UTF8&qid=1413601809&sr=8-1&keywords=The+Fifth+Discipline+Fieldbook ''The Fifth Discipline Fieldbook''] is an in-depth resource, written from the viewpoint of many practitioners and consultants.

*[https://www.amazon.fr/guide-lorganisation-apprenante-d%C3%A9velopper-lintelligence/dp/2212568711/ ''La 5ème discipline - le guide de l’organisation apprenante''] est une source extrêmement riche sur l’approche systèmique écrite du point de vue des pratiquants de cette approche et de consultants.

* The organizational-learning writings from Argyris, Putnam, McLain, and Schön. Important concepts include ''double-loop learning'' and ''high-advocacy/high-inquiry dialogue''. Classic works include [https://actiondesign.com/resources/readings/action-science ''Action Science''] and [http://www.amazon.com/Organizational-Learning-Addison-Wesley-Organization-Development/dp/0201001748/ref=sr_1_11?ie=UTF8&qid=1413601940&sr=8-11&keywords=organizational+learning ''Organizational Learning''].
* Les écrits d’Argyris, Outnam, McLain et Schön sur les apprentissages organisationnels comme [https://actiondesign.com/resources/readings/action-science ''Action Science''] et [http://www.amazon.com/Organizational-Learning-Addison-Wesley-Organization-Development/dp/0201001748/ref=sr_1_11?ie=UTF8&qid=1413601940&sr=8-11&keywords=organizational+learning ''Organizational Learning''] abordent des concepts importants tels que la ''double-boucle apprenante'' et le ''dialogue grand-plaidoyer/grand-réquisitoire''.
* The publications and resources available through the [https://www.solonline.org/ ''Society for Organizational Learning''].
* Les publications et les ressources de la ''Society for Organizational Learning''](https://www.solonline.org/).

-----

===== Notes: =====

# Senge wrote ''The Fifth Discipline'' , on systems thinking and learning organizations, named “one of the seminal management books of the last 75 years” by the ''Harvard Business Review.'' See** [Senge94].
# Another reason: Believing more control is possible than actually is. Complexity science suggests fundamental limits on predicting and controlling semi-chaotic social systems [Stacey07]. This is a rather large can of worms that will remain unopened in this book.
# Macroeconomics, psychology, sociology, and biology are exceptions, among many others.
# ‘Basic’ does not mean trivial or easy to solve. For example, ‘motivation’ and ‘quality’ are basic but not easy issues.
# ''Feedback loops'' is occasionally used in this book in the colloquial sense of feedback, rather than this system dynamics sense.

[^1] ''La cinquième discipline'' écrit par Senge sur l’approche systèmique et les organisations apprenantes a été nommé « l’un des livres les plus novateurs sur le management de ces 75 dernières années » par la ''Harvard Business Review.'' See** [Senge94]. [^2]: Une autre raison : Croire que plus de contrôle est possible qu’il ne l’est actuellement. La science de la complexité montre qu’il existe des limites en terme de prédiction et de contrôle des systèmes sociaux semi-chaotiques [Stacey07]. C’est une énorme boîte de Pandore qui restera enfermée dans ce livre. [^3]: Macro économie, psychologie, sociologie et biologie sont des exemples d’exceptions parmi d’autres [^4]: ‘Basique’ ne signifie pas trivial ou facile à résoudre. Par exemple, les problématiques de ‘motivation’ et de ‘qualité’ sont des problématiques basiques mais elles ne sont pas faciles à résoudre. [^5]: ''Les boucles de feedback'' sont parfois utilisées dans ce livre dans le sens littéral du terme, plutôt dans le sens des dynamiques des systèmes

LeSS - Approche systémique

2020-10-27T21:29:30Z

Nicolas Mereaux :

= Systems Thinking =

= Approche systémique =

I took a speed reading course and read “War and Peace” in twenty minutes. It involves Russia. —Woody Allen

J’ai pris un cours de lecture rapide puis j’ai lu « Guerre et Paix » en vingt minutes. Cela parle de la Russie.

“No matter what we do, the number of defects in our backlog remains about the same,” a manager told us; this for a 15 MSLOC C and C++ product with several hundred developers where we were working. What’s going on? Systems thinking may help. In small groups the forces at play are more quickly seen and informally understood, but in large product development—or any large system—it’s tough. Gerry Weinberg highlights two decisive factors in this situation:

« Quoi que nous fassions, le nombre d’anomalie dans notre ''backlog'' reste identique. » nous a dit un jour un manager en évoquant un produit de près de 15 millions de lignes de code sur lequel plusieurs centaines de développeurs étaient en train de travailler. Que pouvait-il bien se passer ? L’approche systémique peut s’avérer utile dans ce cas comme dans d’autres. En petits groupes, les forces en présence peuvent rapidement être identifiées et comprises de manière informelle, mais dans le cadre du développement d’un gros produit ou de n’importe quel gros système, c’est difficile. Gerry Weinberg met en avant deux facteurs décisifs dans ce genre de situation :

<blockquote>'''Weinberg-Brooks’ Law''': More software projects have gone awry from management’s taking action based on '''''incorrect system models''''' than for all other causes combined.

'''Causation Fallacy''': Every effect has a cause… and we can tell which is which. [http://www.amazon.com/Quality-Software-Management-Systems-Thinking/dp/0932633226/ref=sr_1_1?ie=UTF8&qid=1413527418&sr=8-1&keywords=Quality+Software+Management%3A+Systems+Thinking [Weinberg92]]
</blockquote>
<blockquote>'''Loi de Weinberg-Brooks''' : De plus en plus de projets informatiques sont partis de travers après que le management ait pris des décisions basées sur des '''modèles systémiques incorrects''' plus que pour toutes autres causes combinées.

'''Erreur de causalité''' : Chaque effet a une cause … et nous pouvons dire desquelles il s’agit. [http://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226/ref=sr_1_1?ie=UTF8&qid=1413527418&sr=8-1&keywords=Quality+Software+Management%3A+Systems+Thinking [Weinberg92]]
</blockquote>
These reflect the impact of our '''mental models''' on the system, a subject that will be revisited later in this section.

Ces deux facteurs reflètent bien l’impact de nos '''modèles mentaux''' sur le système, un sujet que nous reverrons plus tard dans cette section.

Problems stemming from mental models and assumptions are one issue. Another is that large-scale adoption of Scrum, lean thinking, and agile principles is not isolated to the development group. It bumps into product management, budgeting, beta-testing, launch, and governance and HR policies. Accordingly, in large-scale agile adoption it is useful to be able to get together with colleagues and ''effectively reason'' about the mental models, causal relations, feedback loops, and control mechanisms (or illusions of control) in a big system that is about to be seriously ''perturbed.'' Systems thinking is one of those reasoning tools.

Les problèmes résultant de nos modèles mentaux et de nos postulats sont un point à traiter. Un autre point est l’adoption à grande échelle de Scrum, de l’approche lean et des principes agiles en dehors du domaine du développement. Ce point est aussi présent dans la gestion de produit, les budgets, les tests, la commercialisation, la gouvernance et la politique RH. En conséquence, dans les adoptions agiles à grande échelle, il est utile de se réunir avec des collègues et de ''réfléchir en profondeur'' sur les modèles mentaux, les relations causales, les boucles de ''feedback'' et les mécanismes de contrôles (ou les illusions de contrôle) dans un gros système qui va être sérieusement ''pertubé''. L’approche systémique est l’un de ces outils de réflexion.

In 1958, the ''Harvard Business Review'' published [https://kupdf.com/download/industrial-dynamics-a-major-breakthrough-for-decision-makers_5902479bdc0d603940959ed5_pdf “Industrial Dynamics: A Major Breakthrough for Decision Makers,”] a landmark paper by Jay Forrester, MIT Sloan School professor. This paper spurred the movement of systems thinking in business education, and the MIT Sloan School of Management became known for educating people in '''system dynamics'''. System dynamics is sometimes treated as a synonym for '''systems thinking''' , though the latter is a more general term.

En 1958 la ''Harvard Business Review'' a publié un article de Jay Forrestor, professeur au MIT Sloan School, qui a fait date [https://kupdf.com/download/industrial-dynamics-a-major-breakthrough-for-decision-makers_5902479bdc0d603940959ed5_pdf “Industrial Dynamics: A Major Breakthrough for Decision Makers,”]. Cet article a lancé le mouvement de l’approche systémique dans le domaine des formations en gestion d’entreprise et la MIT Sloan School of Management devint célèbre pour ses formations en '''dynamique des systèmes'''. Le terme de dynamique des systèmes est parfois utilisé comme synonyme d’'''approche systémique''', même si ce dernier est un terme beaucoup plus général.

MIT also attracted other system-dynamics-oriented researchers such as Peter Senge.[https://less.works/less/principles/systems-thinking.html#footnote-1 1]

Le MIT a également attiré d’autres chercheurs intéressés par la dynamique systémique tel que Peter Senge[^1].

Consistent with ''Weinberg-Brook’s Law'', Forrester’s research showed that decision makers who were given dynamic models of a business system and asked to improve their output performance, ''usually made them run worse'' [http://www.amazon.com/The-Fifth-Discipline-Fieldbook-Organization/dp/0385472560/ref=sr_1_fkmr0_3?ie=UTF8&qid=1413528034&sr=8-3-fkmr0&keywords=The+Fifth+Discipline+%EF%BF%BCFieldbook [SKRRS94]]. The observation was that most people have weak judgement on how to fundamentally improve systems, usually applying incorrect “common sense” and quick-fix ‘solutions’ that do not create long-lasting systemic improvement.

En corrélation avec la loi de ''Weinberg-Brook'', Jay Wright Forrester a montré que les décideurs à qui il avait été donné des modèles dynamiques de systèmes opérationnels et à qui il avait été demandé d’améliorer la performance opérationnelle, ''n’avaient fait généralement qu’empirer les choses'' [https://www.amazon.fr/guide-lorganisation-apprenante-d%C3%A9velopper-lintelligence/dp/2212568711/ [SKRRS94]]. Il en est ressorti d’ailleurs que la plupart des personnes évaluaient mal la manière dont il faut améliorer les systèmes, et appliquaient généralement leur « bon sens », en mettant en place des solutions de contournement qui n’apportent aucune amélioration systémique à long terme.

Why is the behavior of a large development group (a system) not understood or guided skillfully? The answer lies, in part, in the behavior of stochastic systems with queues and variability, as explored in the [https://less.works/less/principles/queueing_theory.html Queueing Theory] LeSS principle. And the same answer lies in ''control theory'': Most systems of interest—such as a product development group—have complex positive and negative feedback loops and nonlinear behavior. The behavior of these systems defies our gut instinct. And then there is the minor issue of ''people''.

Pourquoi le comportement d’un groupe de développement de grande taille (autrement dit un système) n’est-il pas compris ou guidé de manière compétente ? La réponse réside, en partie, dans le comportement des systèmes stochastiques avec les files et les variabilités comme nous avons pu l’évoquer avec le principe LeSS de la [http://www.les-traducteurs-agiles.org/2017/01/29/less-theorie-des-files-d-attente.html théorie des files d’attentes]. Et c’est la même réponse qui est au cœur de la ''théorie du contrôle'' : la plupart des systèmes d’intérêt - tel qu’un groupe de développement de produit - ont des boucles de ''feedback'' positives et négatives ainsi qu’un comportement non linéaire. Le comportement de ces systèmes défient nos instincts. Et puis il y a la problématique mineure des ''gens''.

In summary, reasons for not being skillful in fathoming or guiding a big system include (but are not limited to):

En résumé, les raisons expliquants l’incompétence à maîtriser ou à guider un gros systèmes sont (liste non exhaustive) :

* lack of knowledge about the system dynamics, feedback loops, nonlinear systems behavior, and unintended consequences in workplace systems
* un manque de connaissance des dynamiques des systèmes, des boucles de ''feedback'', du comportement non linéaire des systèmes, et des conséquences inattendues dans les systèmes sur le lieu de travail.
* not understanding root causes of problems (and how to find)
* une incompréhension des causes racines des problèmes (et de comment les trouver)
** ''causes,'' not cause; in systems thinking one sees that there are multiple, indirect, and dynamic causes to problems
** ''les causes'', non la cause ; en approche systémique, nous savons que les causes des problèmes sont multiples, indirectes et dynamiques
* not knowing if or why quick-fix or local-department decisions degraded overall delivery performance.
* l’incapacité à savoir si ou pourquoi une solution de contournement ou une décision locale dégrade la performance globale opérationnelle.

In short, not being systems thinkers.[https://less.works/less/principles/systems-thinking.html#footnote-2 2]

En bref, ne pas utiliser l’approche systémique[^2].

These reasons are consequential at the intersection of management and large-scale adoption of lean and agile principles. The leadership team is part of the system being perturbed; if they do not apply systems thinking, they could ''really'' perturb it—and not in a good way!

Ces raisons sont la conséquence de l’intersection du management et de l’adoption des principes lean et agile. L’équipe de direction fait partie du système qui est pertubé ; si elle n’applique pas l’approche systémique, elle pourrait ''vraiment'' le perturber - et pas de la bonne façon.

As a summary of systems thinking insight, we like the [https://en.wikipedia.org/wiki/The_Fifth_Discipline#The_11_Laws_of_the_Fifth_Discipline 11 ‘laws’] described in [http://www.amazon.com/Fifth-Discipline-Practice-Learning-Organization-ebook/dp/B000SEIFKK/ref=sr_1_1?ie=UTF8&qid=1413531002&sr=8-1&keywords=the+fifth+discipline The Fifth Discipline]:

Les points-clés à retenir de l’approche systémique peuvent être résumé dans les [https://en.wikipedia.org/wiki/The_Fifth_Discipline#The_11_Laws_of_the_Fifth_Discipline 11 lois] décrites dans la [https://www.amazon.fr/cinqui%C3%A8me-discipline-organisations-apprenantes-dexemplaires-ebook/dp/B017WSYAHG Cinquième discipline]

* Today’s problems come from yesterday’s ‘solutions.’
* The harder you push, the harder the system pushes back.
* Behavior will grow worse before it grows better.
* The easy way out usually leads back in.
* The cure can be worse than the disease.
* Faster is slower.
* Cause and effect are not closely related in time and space.
* Small changes can produce big results…but the areas of highest leverage are often the least obvious.
* You can have your cake and eat it too—but not all at once.
* Dividing an elephant in half does not produce two small elephants.
* There is no blame.
* Les problèmes d’aujourd’hui viennent des solutions d’hier
* Plus vous poussez, plus le système pousse en retour
* Le comportement empirera d’abord avant de s’améliorer
* La manière la plus facile de s’en sortir conduit souvent à faire quelques pas en arrière
* Le médicament peut être pire que la maladie
* Plus vite c’est plus lentement
* Les causes et les effets ne sont pas étroitement liés dans l’espace et le temps
* De petits changements peuvent produire de gros résultats … mais les zones où l’effet de levier est le plus important sont souvent les moins évidentes
* Vous pouvez avoir votre gâteau et le manger aussi - mais pas en une seule bouchée
* Couper un éléphant en deux ne produit pas deux petits éléphants
* Il n’y a aucun reproche à faire

Toyota’s internal motto is [http://www.toyota-global.com/company/toyota_traditions/quality/may_jun_2005.html “Good '''thinking''', good products.”] Systems thinking is a set of ''thinking'' tools to help…

La devise de Toyota en interne est [http://www.toyota-global.com/company/toyota_traditions/quality/may_jun_2005.html « Une bonne '''réflexion''', de bons produits »]. L’approche systémique est un jeu d’outils de réflexion pour aider …

* '''see system dynamics'''—a development organization is a system of people and policies with subtle feedback loops and unintended consequences
* '''à voir les dynamiques des systèmes''' - une organisation de développement est un système de personnes et de règles avec de subtiles boucles de ''feedback'' et des conséquences inattendues
** we can learn to see and thus improve the system with '''causal loop diagrams''' created in a workshop
** nous pouvons apprendre à voir et ainsi à améliorer le système avec des '''diagrammes de boucles causales''' faits lors d’un atelier
* '''see mental models'''—one reason behind suboptimal decisions is mistaken assumptions and faulty reasoning
* '''à percevoir les modèles mentaux''' - parmi les raisons derrière des décisions sous-optimales se trouvent des hypothèses erronées et des raisonnements incorrects
** causal loop diagramming and Five Whys expose these
** les diagrammes de boucles causales et les cinq pourquoi permettent de révéler tout ça
* '''see local optimization'''—another source of suboptimal decisions is '''local optimization''' , making the ‘best’ decision from the viewpoint of a person or department, rather than '''global optimization''' for the lean systems-level goal of ''deliver value fast with high quality and high morale'' .
* '''à voir les optimisations locales''' - une autre source de décisions sous-optimales est '''l’optimisation locale''', autrement dit prendre la « meilleure » décision du point de vue d’une personne ou d’un département, au détriment d’une '''optimisation globale''' qui est l’objectif au niveau système ''lean'' que de pouvoir ''livrer la plus grande valeur possible de très grande qualité avec un moral d’acier''

This introduction is organized around the following areas in systems thinking: Learning to see (1) ''system dynamics'' , (2) ''mental models'' , (3) ''root causes'' , and (4) ''local optimization'' .

Cette introduction à l’approche systémique est présenté autour des domaines suivants : Apprendre à voir (1) ''les dynamiques des systèmes'', (2) ''les modèles mentaux'', (3) ''les causes racines'', et (4) ''l’optimisation locale''.

== Seeing System Dynamics: Introduction ==

== Voir les dynamiques des systèmes : Introduction ==

=== Static versus Dynamic Complexity ===

=== Complexité statique versus complexité dynamique ===

Many of us, especially in engineering and finance, are educated to master '''complexity of static details'''—learning to analyze and manage information (requirements, financial analysis, …), decompose complex structures into simpler ones, and so forth. That is, complexity of a static, information, or structural nature.

La plupart d’entre nous, notamment les ingénieurs et les financiers, ont été formés pour maîtriser la '''complexité de détails statiques''' - en apprenant à analyser et à gérer l’information (exigences, analyses financières, …), à décomposer des structures complexes en structures simples, et ainsi de suite. C’est-à-dire, la complexité d’une information qui est par nature structurellement statique.

Why do big software systems tend to degrade, with more and more time spent on defects? What might happen if the USA invades Iraq? Seeing the dynamics behind these questions involves analysis of the '''complexity of dynamics''' .

Pourquoi les gros systèmes informatiques ont-ils tendance à se dégrader malgré de plus en plus de temps passé sur les anomalies ? Qu’est-ce qui pourrait bien se passer si les États-Unis d’Amérique envahissait l’Irak ? Voir les dynamiques derrière ces questions implique d’analyser la '''complexité des dynamiques''' en jeu.

In contrast to static-details education, many of us receive no ''formal'' education in analyzing ''dynamics'' complexity[https://less.works/less/principles/systems-thinking.html#footnote-3 3], especially workplace dynamics. Perhaps there is a belief it is sufficient to rely on common sense in the workplace. Forrester demonstrated that “common sense” is just not so in complex systems, and showed it is possible to formally educate people to become better system dynamics thinkers in the workplace using ''dynamic system models'' visualized in ''flow diagrams'' [http://www.amazon.com/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ref=sr_1_1?ie=UTF8&qid=1413582840&sr=8-1&keywords=Industrial+Dynamics [Forrester61]].

En contraste avec une formation sur les détails statiques que la plupart d’entre nous avons suivie, peu d’entre nous ont reçu de formation sur l’étude des systèmes dynamiques et complexes[^3] et notamment en milieu professionnel. Peut-être parce que nous avons la croyance qu’il est suffisant de s’appuyer sur le bon sens en milieu professionnel. Jay Wright Forrester a démontré que le « bon sens » n’est pas suffisant dans des systèmes complexes et qu’il est possible de former des personnes pour leur permettre de mieux appréhender les dynamiques des systèmes en milieu professionnel en utilisant notamment des ''diagrammes de flux'' [http://www.amazon.fr/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ref=sr_1_1?ie=UTF8&qid=1413582840&sr=8-1&keywords=Industrial+Dynamics [Forrester61]].

Flow diagrams encompass material, financial, and information flows, stocks (variables with a quantity, such as cash or number of defects), the impact of decisions and policies, and cause-effect relations. A popular simplification is the '''causal loop diagram''' that focuses on cause-effect relationships and feedback loops in a system [http://www.amazon.com/Business-Dynamics-Systems-Thinking-Modeling/dp/0071179895 [Sterman00]]. There are a variety of similar notations; they all show stocks (variables), causal links, and delay. In [http://www.amazon.com/Quality-Software-Management-Systems-Thinking/dp/0932633226/ref=sr_1_1?ie=UTF8&qid=1413527418&sr=8-1&keywords=Quality+Software+Management%3A+Systems+Thinking [Weinberg92]] this is called the ''diagram of effect'' .

Les diagrammes de flux peuvent s’appliquer aussi bien aux flux matériels, financiers, d’informations, de stocks (n’importe quel type de stock quantitatif comme de l’argent ou des anomalies), aux conséquences des décisions et des politiques et des relations de causes à effet. Lorsque nous pensons aux diagrammes de flux, nous pensons souvent au seul diagramme de boucle causale dédié aux relations de cause à effets et aux boucles de rétroaction dans un système [http://www.amazon.fr/Business-Dynamics-Systems-Thinking-Modeling/dp/0071179895 [Sterman00]]. Il existe une grande variété d’autres diagrammes qui peuvent faire figurer les stocks (quels qu’ils soient), les liens de causalités, et les retards. Dans son ouvrage, [http://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226/ref=sr_1_1?ie=UTF8&qid=1413527418&sr=8-1&keywords=Quality+Software+Management%3A+Systems+Thinking [Weinberg92]] Gerald Weinberg appelle cela un ''diagramme d’effet''.

=== The First Law of Diagramming: Model to Have a Conversation ===

=== La première loi de la réalisation d’un diagramme : nous modélisons pour avoir une conversation ===

A tool to learn to see system dynamics is a causal loop diagram, ideally sketched on a whiteboard in a LeSS Overall Retrospective with colleagues. Before going further, here is the ''First Law of Diagramming''

Un outil très utile pour apprendre les dynamiques des systèmes est le diagramme de boucles causales - nous vous recommandons de l’utiliser sur un tableau blanc notamment lors des Rétrospectives Globales LeSS. Mais avant d’aller plus loin, voici la ''première loi de réalisation d’un diagramme''.

<blockquote>'''The primary value in diagrams is in the discussion while diagramming—we model to have a conversation.'''
</blockquote>
<blockquote>'''La première valeur d’un diagramme c’est la discussion qui se déroule lors de la réalisation du diagramme - nous modélisons pour avoir une conversation.'''
</blockquote>
When a group gets together to sketch a causal loop diagram on a whiteboard (See it is the the acts of discussing and thinking that are most important when diagramming, Valtech India.), the primary value is the conversation and shared understanding they arrive at while creating the model. Its visualization as an easy-to-see diagram ''is'' important to make concrete and unambiguous (on the whiteboard) the ideas—the mental models people have—because words alone can be fuzzy and misunderstood. But still, the diagram is secondary to what people take away: learning and a revised understanding through a discussion.

Lorsqu’un groupe se rassemble pour dessiner un diagramme de boucles causales sur un tableau blanc (« C’est l’acte de discuter et de réfléchir qui est le plus important lorsque nous dessinons », Valtech India.), la première valeur d’un diagramme c’est la conversation et la compréhension commune à laquelle les personnes arrivent lors de la création du modèle. Ce qu’il en résulte à savoir un diagramme facile à comprendre est important pour rendre les idées et les modèles mentaux concrets et non ambigües (sur le tableau blanc) parce que les mots seuls peuvent être imprécis et mal compris. Toutefois, le diagramme est secondaire par rapport avec ce que les gens repartent : ils ont appris quelque chose et ont revu leur compréhension du monde à travers une discussion.

[[File:https://less.works/img/systems-thinking/xgroup,P20cld,P20modeling.jpg.pagespeed.ic.lirKMzwWbD.webp|frame|none|alt=|caption group%20cld%20modeling.jpg]]

''Doing system thinking. Sketching a causal loop diagram together—modeling to have a conversation.''

[[File:Xgroup-cld-modeling.jpg|frameless|848px|Un atelier d’approche systémique : réalisation d’un diagramme de boucles causales à plusieurs - modéliser pour avoir une conversation]]

''Un atelier d’approche systémique : réalisation d’un diagramme de boucles causales à plusieurs - modéliser pour avoir une conversation.''

''Concrete modeling tip'' : We start by writing on sticky notes to define ''variables'' . A note might read “feature velocity” or “# defects.” We place these on a whiteboard. Then we sketch causal link lines between the sticky notes. There will be (or should be) lots of rewriting, erasing, and redrawing during the modeling session. The most meaningful outcome is ''understanding'' ; in addition, some participants will want to take a digital photo of the whiteboard sketch.

''Trucs et astuces de pro pour modéliser'' : Nous commençons par écrire sur des petits papiers repositionnables les noms des ''variables'', par exemple « vélocité des ''features'' » ou « nombre d’anomalies ». Nous les plaçons ensuite sur le tableau blanc. Puis nous dessinons les liens de causalités entre les papiers . Il y aura (ou il devrait y avoir) beaucoup de réécriture, d’effaçage, de redessin lors de la session de modélisation. Le résultat le plus important d’une telle session est la ''compréhension'' - il se peut qu’à l’issue de cet atelier, certains participants voudront prendre une photo du dessin du tableau blanc.

== Seeing System Dynamics: Causal Loop Diagrams ==

== Voir les dynamiques des systèmes : les diagrammes de boucles causales ==

Causal loop diagrams are used regularly in introductions to LeSS, to help see the dynamics of what is going on in large-scale development. It is useful to understand them for that reason alone. And more useful to you, we recommend you do these together with colleagues at a whiteboard. Model to have a conversation. When? Probably during a LeSS Overall Retrospective.

Les diagrammes de boucles causales sont souvent utilisés en introduction à LeSS pour aider à voir les dynamiques de ce qu’il se passe dans du développement à grande échelle. Il est donc utile de comprendre ce type de diagrammes pour cette seule et unique raison. Et cela s’avèrera encore plus utile pour vous, si vous le faites avec vos collègues devant un tableau blanc. Vous modélisez pour avoir une conversation. Quand ? Plus probablement lors d’une rétrospective globale LeSS.

The practical aspect of this tip is more important than may first be appreciated. It is vague and low-impact to suggest “be a systems thinker.” But if you and four colleagues get into the habit of standing together at a large whiteboard, sketching causal loop diagrams together, then there is a concrete and potentially high-impact practice that connects “''be'' a systems thinker” with “''do'' systems thinking.”

L’aspect pratique de cet exercice est bien plus important que ce qu’il peut paraître au premier abord. Notre conseil d’« être un pratiquant systémique » peut vous sembler vague et sans grand impact. Mais si vous et quatre de vos collègues prenez l’habitude de vous réunir devant un grand tableau blanc, en dessinant des diagrammes de boucles causales ensemble, alors vous arriverez à faire la connexion entre « ''être'' un pratiquant systémique » avec « ''faire'' de l’approche systémique ».

The following examples seem sterile when presented in a book. But imagine you were at a whiteboard with other people and the diagrams were being sketched during a lively conversation. That’s the way we suggest ‘doing’ systems thinking.

Les exemples suivants peuvent paraître stériles car présentés dans un livre. Mais imaginez-vous à côté d’un tableau blanc avec d’autres personnes dessinant ensemble des diagrammes au cours d’une conversation animée. C’est de cette manière-là que nous suggérons de ‘ faire ’ de l’approche systémique.

====== Notation and Examples ======

====== Notation et exemples ======

Causal loop diagrams contain many elements; the following common useful subset is explored through a scenario.

Les diagrammes de boucles causales contiennent beaucoup d’éléments ; les éléments suivants sont les plus communément utilisés et sont vus en détail tout au long du scénario qui va suivre

* variables
* causal links
* opposite effects
* constraints
* goals
* reactions; quick-fix reactions
* interaction effects
* extreme effects
* delays
* positive feedback loops
* variables
* liens de causalité
* effets opposés
* contraintes
* objectifs
* réactions ; réactions solutions de contournement
* effets d’interaction
* effets extrêmes
* retards
* boucles de ''feedback'' positives

''The following simplified scenario is for a particular organization. It is not a generalization.''

''Le scénario qui suit est un scénario simplifié pour une organisation spécifique. Il ne s’agit pas d’une généralisation.''

'''Variables'''—Causal loop diagrams include ''variables'' (or stocks) such as the ''velocity (rate of delivery) of software features'' and ''number of defects'' . Variables have a measurable quantity.

'''Les variables''' - Les diagrammes de boucles causales comportent des ''variables'' (ou des stocks) telle que la ''vélocité (taux de livraison) des features'' et le ''nombre d’anomalies''. Les variables ont une quantité mesurable.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-4.png.pagespeed.ic.WpO9GKmuZP.webp|frame|none|alt=|caption systems thinking-4.png]]

[[File:Xsystems-thinking-4-fr.png|frameless|848px|1er schéma]]

'''Causal links'''—An element can have an effect on another, such as if feature velocity increases, then the number of defects increase; that is, more new code, more defects.

'''Les liens de causalité''' - Un élément peut avoir un effet sur un autre, comme par exemple si la vélocité des ''features'' augmente alors le nombre d’anomalies augmente ; autrement dit, plus de code, plus d’anomalies.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-5.png.pagespeed.ic.oPRro2SqND.webp|frame|none|alt=|caption systems thinking-5.png]]

[[File:Xsystems-thinking-5-fr.png|frameless|848px|2ème schéma]]

Now it is time to bump into ''Weinberg-Brook’s Law'' and the ''Causation Fallacy'' . It is easy to sketch a diagram; it is something else to model with insight. For example, consider the relationship between the ''number of developers'' and ''feature velocity.''

Il est temps désormais de se jeter à corps perdu dans la ''loi de Weinberg-Brooks'' et dans la ''causalité fallacieuse''. C’est facile de dessiner un diagramme, ça l’est moins que de modéliser en faisant preuve de clairvoyance comme par exemple, la relation entre le ''nombre de développeurs'' et la ''vélocité des features''.

The nature of any cause-effect relationship is actually not obvious, though it is common for people to jump to conclusions such as more developers means better velocity. Adding people late in development may ''reduce'' velocity (a sub-element of “Brooks’ Law” [Brooks95]). Or, ''more'' bad programmers could really slow you down. An argument can be made that ''removing'' terrible developers can ''improve'' velocity.

Toute relation de cause à effets est par nature obscure, même si les gens ont l’habitude de sauter sur la première conclusion venue comme par exemple plus de développeurs égale plus de vélocité. Ajouter des personnes tard au cours du développement peut ''réduire'' la vélocité (il s’agit d’une composante de la « loi de Brooks » [Brooks95]). Ou, ''davantage'' de mauvais développeurs pourrait vraiment vous ralentir. Il pourrait être objecté qu’''enlever'' des développeurs exécrables peut permettre ''d’améliorer'' la vélocité.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-6.png.pagespeed.ic.6XIYl7Vm3_.webp|frame|none|alt=|caption systems thinking-6.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-6-fr.png|frame|none|alt=|caption systems thinking-6.png]]

[[File:Xsystems-thinking-6-fr.png|frameless|848px|3ème schéma]]

'''Opposite effects'''—A causal link effect may be the same or opposite direction; if A goes up then B goes up, or vice versa. Opposite effect is shown with an ‘O’ on the line. Suppose defects going up puts a drag on the system, lowering the velocity of new features because people spend more time fixing or working around bugs.

'''Effets opposés''' - L’effet d’un lien de causalité peut aller dans la même direction ou dans la direction opposée. Si A monte alors B monte ou vice versa. L’effet opposé se souligne à l’aide d’un ‘0’ sur la ligne. Supposons que les anomalies ralentissent grandement le système, réduisant la vélocité des nouvelles ''features'' parce que les gens passent plus de temps à corriger ou à trouver des solutions de contournement aux anomalies.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-7.png.pagespeed.ic.DPGMJyX2Qf.webp|frame|none|alt=|caption systems thinking-7.png]]

[[File:Xsystems-thinking-7-fr.png|frameless|848px|4ème schéma]]

'''Constraints'''—Unless you can find people to work for free, there is a constraint on the number of developers, based upon cash supply.

'''Contraintes''' - À moins que vous ne trouviez des personnes prêtent à travailler gratuitement, il y a une contrainte sur le nombre de développeurs basé sur le budget disponible.

Constraints are ''not'' causal links. As cash supply goes up, it is not the case that the number of developers goes up.

Les contraintes ne sont ''pas'' des liens de causalité. Lorsque la montant du budget disponible augmente, ce n’est pas le cas du nombre de développeurs/

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-8.png.pagespeed.ic.gbgAIK-IsZ.webp|frame|none|alt=|caption systems thinking-8.png]]

[[File:Xsystems-thinking-8-fr.png|frameless|848px|5ème schéma]]

'''Goals and Reactions'''–People, departments, and systems have goals, such as ''higher feature velocity'' . Goals often generate pressure for people to react (or act), with the intent of achieving the goal. But since there is ''Causation Fallacy'' and ''Weinberg-Brooks’ Law'' to contend with, people should be cautious about assuming what actions will help. Now a goal and pressure for reaction is shown:

'''Buts et réactions''' - Les personnes, les départements et les systèmes ont des buts, comme par exemple avoir une ''vélocité des features plus élevée''. Les buts occasionnent souvent de la pression pour que les gens réagissent (ou agissent) dans l’intention de leur faire atteindre ce but. Mais étant donné qu’il y a la ''causalité fallacieuse'' et la ''loi de Weinberg-Brooks'' à laquelle il faut faire face, les gens devraient être prudents quant aux actions pertinentes à entreprendre. Voici un exemple de diagramme modélisant cela :

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-9.png.pagespeed.ic.yVcHbh4_-i.webp|frame|none|alt=|caption systems thinking-9.png]]

[[File:Xsystems-thinking-9-fr.png|frameless|848px|6ème schéma]]

Not only does a goal with a ''reward'' create pressure to act, but also it creates pressure to ''appear'' to be acting and achieving, due to the '''measurement dysfunction''' generated by rewards. And the measurement dysfunction can be proportional to the perceived value of the reward because people are being motivated to get a reward, not to improve the system [http://www.amazon.com/Measuring-Managing-Performance-Organizations-Dorset-ebook/dp/B00DY3KQX6/ref=sr_1_1?ie=UTF8&qid=1413596674&sr=8-1&keywords=measuring+and+managing+performance+in+organizations [Austin96]]. Notice how rewards can actually degrade system performance. Visually, the system dynamics may be…

Non seulement un but à atteindre avec une ''récompense'' au bout engendre une pression à agir, mais cela créé aussi une pression à ''faire semblant'' d’agir et à atteindre le but — les récompenses provoquent un '''dysfonctionnement des indicateurs'''. Le dysfonctionnement des indicateurs peut être proportionnel à la valeur perçue de la récompense parce que les personnes sont motivées pour avoir la récompense, non pour améliorer le système [http://www.amazon.fr/Measuring-Managing-Performance-Organizations-Dorset-ebook/dp/B00DY3KQX6/ref=sr_1_1?ie=UTF8&qid=1413596674&sr=8-1&keywords=measuring+and+managing+performance+in+organizations [Austin96]]. Remarquez bien comment et de quelle manière les récompenses peuvent dégrader la performance du système. De manière visuelle, les dynamiques d’un tel système pourrait être …

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-10.png.pagespeed.ic.39CLFp-g_9.webp|frame|none|alt=|caption systems thinking-10.png]]

[[File:Xsystems-thinking-10-fr.png|frameless|848px|7ème schéma]]

It is quite interesting that all these dynamics have been added by introduction of reward, and yet there is no necessary connection between the top part of this model and the bottom.

Il est assez intéressant de voir que toutes ces dynamiques ont été ajouté par l’introduction d’une récompense et qu’il n’y pas de connexion entre le haut et le bas de cette modélisation.

There is no guarantee that feature velocity has improved—or even been worked on.

Il n’y a aucune garantie que la vélocité des features s’améliore ou même que l’on y travaille.

Removing the reward system is a root-cause solution to the dysfunction. Another (lesser) surface countermeasure is the lean-thinking ''Go See'' (go see physically at the place of real work) principle and management behavior:

Enlever le système de récompense est une solution à la cause racine de ce dysfonctionnement. Une autre contremesure de surface est le principe et le comportement managériale ''Aller voir'' (aller voir physiquement sur le lieu où le travail s’effectue) de l’approche lean.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-11.png.pagespeed.ic.NU8SjnJkUY.webp|frame|none|alt=|caption systems thinking-11.png]]

[[File:Xsystems-thinking-11-fr.png|frameless|848px|8ème schéma]]

'''Quick-fix reactions'''—One difficult and slow solution toward the goal of higher velocity is to hire great developers, to increase coaching and education of existing staff, and to remove terrible workers. The alternative is called a ''quick fix'' , a reaction that is hoped to achieve the goal quickly and with less effort. Sometimes a quick fix works well both in the short and long term, really strengthening the system. Sometimes not…hence, “faster is slower.” For example, people may ''believe'' that increasing the number of developers increases the feature velocity. And they may thereby hope that hiring more developers will most quickly and easily solve the velocity problem. ‘QF’ indicates the quick fix:

'''Solutions de contournement''' - Une solution payante à long terme pour atteindre une vélocité plus grande, qui n’est pas sans difficulté, consiste à : recruter de développeurs très qualifiés, faire davantage d’accompagnements et de formations, et à se séparer des moins bons éléments. L’alternative est ce que l’on appelle une ''solution de contournement'', c’est ce que l’on met en place dans l’espoir d’atteindre l’objectif en moins de temps et avec moins d’effort. Parfois, une solution de contournement se révèle payante aussi bien dans le court terme que dans le long terme, renforçant par la-même le système. D’autres fois cela ne fonctionne pas … d’où l’expression « aller plus vite c’est aller plus lentement ». Par exemple, les gens peuvent ''croire'' qu’augmenter le nombre de développeurs permet d’augmenter la vélocité des features. Et ils peuvent par conséquent être amenés à espérer qu’en recrutant davantage de développeurs cela permettra de résoudre plus vite et plus facilement le problème de vélocité. La mention ‘SC’ sur le diagramme ci-dessous indique une solution de contournement.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-12.png.pagespeed.ic.x8IJWKprUx.webp|frame|none|alt=|caption systems thinking-12.png]]

[[File:Xsystems-thinking-12-fr.png|frameless|848px|9ème schéma]]

'''Interaction effects'''—There is the constraint of cash supply on hiring. One hard and slow solution is to get more cash. A quicker fix is to hire ''much'' cheaper developers. In this case, the level of cash supply now has an ''interaction effect'' with other causal links. Low cash tends to strengthen the hire rate of much cheaper developers when there is pressure to increase hire rates.

'''Effets d’interaction''' - La capacité à embaucher est contraint à la capacité budgétaire. Une solution de longue haleine non sans difficulté est d’obtenir davantage de budget. Une solution de contournement possible est de recruter un ''grand'' nombre de développeurs bon marché. Dans ce cas, le niveau du budget a un ''effet d’interaction'' avec les autres boucles causales. Un budget peu élevé aura tendance à renforcer le taux de développeurs bon marché si la pression pour recruter augmente.

One could simply draw an (opposite) causal link directly from ''cash supply'' to ''hire rate of very cheap developers'' , but that merely says that less cash leads to more hiring of extremely cheap developers. That is not quite what we want to say; rather, we want to show the interaction effect—that effect A influences ''effect'' B. This is done by showing a causal link entering another causal link. For example, from ''cash supply'' to the quick-fix line going into ''hire rate of very cheap developers'' :

Nous pourrions dessiner simplement un lien de causalité (opposé) de ''rentrée budgétaire'' à ''taux de recrutement de développeurs bon marché'', mais cela voudrait simplement dire qu’avoir un budget moindre aurait pour conséquence de recruter davantage de développeurs bon marché. Mais ce n’est pas tout à fait ce que nous voulons dire ; ce que voulons montrer en fait, c’est l’effet d’interaction - c’est-à-dire qu’un effet A influence un ''effet'' B. Cela se fait en montrant un lien de causalité heurtant un autre lien de causalité, par exemple en traçant une ligne de ''rentrée budgétaire'' vers la ligne représentant la solution de contournement qui va vers ''taux de recrutement de développeurs bon marché''.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-13.png.pagespeed.ic.LvAE8ewRFJ.webp|frame|none|alt=|caption systems thinking-13.png]]

[[File:Xsystems-thinking-13-fr.png|frameless|848px|10ème schéma]]

'''Extreme effects'''—We have worked with some very inexpensive developers with excellent skill and some very expensive developers that are terrible, but on average, you get what you pay for—when you hire from a large pool of very cheap labor, the average skill level is lower. In the model we want to show that the impact of hiring very cheap labor on the ''number of low-skilled developers'' is a significantly greater effect than average.

'''Effets extrêmes''' - Il nous est arrivé de travailler avec d’excellents développeurs très bon marché et avec d’autres hors de prix très nuls, mais en moyenne, vous obtenez à hauteur de ce que vous payez - lorsque vous recrutez au moins disant, le niveau moyen en terme de compétences sera plus faible. Dans le diagramme ci-dessous, nous avons voulu montrer que l’impact du recrutement de personnes bon marché en rapport avec le ''nombre de développeurs peu qualifiés'' à un impact sensiblement plus grand que la moyenne.

To show an ''extreme effect'' in the model, use a thick line:

Pour montrer un ''effet extrême'' sur un modèle, faites un trait épais comme vous pouvez voir ci-dessous :

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-14.png.pagespeed.ic.JYkqz8Qe24.webp|frame|none|alt=|caption systems thinking-14.png]]

[[File:Xsystems-thinking-14-fr.png|frameless|848px|11ème schéma]]

'''Delays'''—One problem in hiring in software development is the ''fallacy of mild programmer variance'' —the mistaken belief that programmer variance (in terms of productivity, code quality, etc.) is relatively small. However, programmer variance studies suggest an average of four times faster in the top versus bottom quartile [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.4788 [Prechelt00]]. Rather significant. Also, the COCOMO model—based on large and longitudinal studies—shows that the capability of the development personnel is by far the most important factor for productivity [http://www.amazon.com/Software-Cost-Estimation-Cocomo-II/dp/0130266922/ref=sr_1_1?ie=UTF8&qid=1413597244&sr=8-1&keywords=Software+Cost+Estimation+with+Cocomo+II [Boehm00]]. And, on average, very weak programmers create poor-quality code (poor design) and more defects, creating another drag on the system.

'''Retards''' Un problème courant au niveau du recrutement dans un projet de développement logiciel concerne ''l’erreur au niveau de la variance d’un développeur moyen'' - autrement dit la croyance fausse que la variance d’un développeur à un autre (en terme de productivité, de qualité de code, etc.) est relativement faible. Toutefois, les études de la variance au sujet des développeurs montrent un rapport de un à 4 entre le 1er quartile et le dernier [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.4788 [Prechelt00]]. C’est plutôt quelque chose de significatif. De même des études - en long et en large - du modèle COCOMO montrent que la capacité du développement personnel est le facteur de loin le plus important quant à la productivité [http://www.amazon.com/Software-Cost-Estimation-Cocomo-II/dp/0130266922/ref=sr_1_1?ie=UTF8&qid=1413597244&sr=8-1&keywords=Software+Cost+Estimation+with+Cocomo+II [Boehm00]]. Et, en moyenne, il s’avère que les développeurs peu qualifiés font du code de mauvaise qualité (mauvaise conception) et de plus d’anomalies, ceci rajoute un autre frein au système.

But the impacts of these effects are not immediately obvious. For example, it takes a relatively long time after hiring a large pool of weak programmers before the impacts of more and more bad code/design start to be felt. Similarly, the average ''decrease'' in feature velocity (because of the powerful impact of programmer variance) will not show up immediately.

Mais l’impact de ces effets ne sont pas visibles immédiatement. Par exemple, cela peut prendre un certain temps après un recrutement massif de développeurs peu qualifiés avant que les impacts négatifs ne se fassent sentir au niveau de la qualité du code ou de la conception. De manière similaire, la ''baisse'' moyenne de la vélocité des features (en raison de l’impact important de la variance des développeurs évoqué plus haut) ne se verra pas immédiatement.

To show these ''delayed effects'' in the model, use a double-line through the effect line:

Pour montrer ces ''effets à retardement'' dans le modèle, faites une double-ligne en travers de la ligne d’effet.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-15.png.pagespeed.ic.0fwliLJm6G.webp|frame|none|alt=|caption systems thinking-15.png]]

[[File:Xsystems-thinking-15-fr.png|frameless|848px|12ème schéma]]

Delay has an intriguing influence on the ''educational'' or corrective power in a system. If an impact or unintended consequence is long delayed, one does not feel the effect (pain or gain) and so does not clearly see how A influenced B, or more subtly how ''A influenced B influenced A'' .

Le retard a une influence intéressante sur le pouvoir ''pédagogique'' ou correctif sur un système. Si un impact ou une conséquence inattendue est retardé suffisamment longtemps, personne n’en voit ni l’effet (qu’il soit bénéfique ou néfaste) ni sur la façon dont A influence B ou plus subtilement comment ''A a influencé B qui a influencé A''.

Therefore, one does not learn from or correct mistakes—in policy, management actions, tools, and so forth. Likewise, gradual improvement through the lean thinking practice of ''kaizen'' can take a long time; patience and insight are needed to see if and how things improve.

Par conséquent, personne n’apprend de ses erreurs ni n’est en capacité de les corriger - que ce soit en terme de stratégie, d’actions d’encadrement, d’outils ou de quoi que ce soit. De la même manière, l’amélioration graduelle à travers l’application d’une démarche lean ''kaizen'', peut prendre un certain temps ; de la patience et de la perspicacité sont nécessaires pour voir si et comment les choses s’améliorent.

'''Positive feedback loops'''—Negative or positive feedback loops[https://less.works/less/principles/systems-thinking.html#footnote-5 5] and delays are where things start to get more subtle in a system—and in understanding a system. For example, how does one become a better programmer? In part, by mentoring from great programmers and seeing lots of examples of great code. But an office with a lot of low-skill developers does not generate a lot of great code examples, nor does it attract or retain the small pool of great programmers who could act as mentors. They would rather work somewhere else.

'''Boucles de feedback positives''' - Les boucles de feedback négatives ou positives [^5] et les retards sont le point de départ pour une approche plus subtile d’un système - et de sa compréhension. Par exemple, de quelle manière une personne peut-elle devenir un meilleur développeur ? En partie, en bénéficiant du mentorat de très bons développeurs et en jetant un œil sur du très bon code. Mais il est impossible de trouver du bon code dans un endroit remplit de développeurs médiocres, il est impossible également d’y attirer ou de retenir le petit groupe de très bon développeurs qui pourraient prendre le rôle de mentors. Ils préfèrent largement aller travailler ailleurs.

Now the development group starts to enter a self-reinforcing downward spiral—a set of ''positive feedback loops'' . Fortunately, the downward trend is constrained by the supply of cash.

Ce groupe de développeurs médiocres rentrent dans un cercle vicieux en raison d’un ensemble de ''boucles de feedback positives''. Fort heureusement, ce cercle vicieux est assujeti aux contraintes du budget.

More great programmers—who could craft great code and mentor others—leave. So there is less and less quality code to look at and to learn from. The percentage of weak programmers grows even larger and feature velocity drops further. Code becomes more messy, awkward, and duplication-riddled, so the capacity to swiftly implement features declines. Since feature velocity is dropping further, there is more pressure to hire yet more very cheap programmers. All this leads to multiple positive reinforcement loops in the system, for example:

Malheureusement de plus en plus des très bons développeurs - ceux en capacité d’élaborer du très bon code et de faire du mentorat auprès des autres développeurs - partent. Par conséquent, il y a de moins en moins de code de qualité à regarder et à partir duquel il est possible d’en tirer des enseignements. Le pourcentage de développeurs médiocres augmente de plus en plus et la vélocité au niveau des features continue à chuter. Le code devient de plus en plus brouillon, difficile, avec pleins de bouts de code dupliqués à gauche et à droite, le tout de telle manière que la capacité d’implémenter des features décline. Étant donné que la vélocité des features continue de chuter, il y a davantage de pression pour recruter des développeurs très bon marché. Tout cela conduit à de multiples boucles de renforcement positives dans le système comme l’illustre l’exemple ci-dessous :

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-16.png.pagespeed.ic.ONFuUmJHSE.webp|frame|none|alt=|caption systems thinking-16.png]]

[[File:Xsystems-thinking-16-fr.png|frameless|848px|13ème schéma]]

''Tip'' : You can find positive feedback loops by finding cycles with an ''even number'' of ‘Opposite’ effect relationships. There are several examples in the model above.

''Astuce'' : Vous pouvez trouver des boucles de feedback positives en cherchant des cycles ayant un ''nombre pair'' de relations. Vous en trouverez plusieurs exemples ci-dessus.

===== Conclusion =====

===== Conclusion =====

The example scenario is only that—an example. A causal loop diagram can visualize rich dynamics in a workplace system. These are best created by a group at a whiteboard.

Le scénario donné à titre d’exemple est uniquement cela - un exemple. Une diagramme de boucle causale permet de visualiser la richesse de la dynamique dans le système dans un milieu professionnel. La meilleure manière de modéliser un tel système est de le faire en groupe face à un tableau blanc.

== Seeing Mental Models ==

== Voir les modèles mentaux ==

The previous causal loop diagrams reflect people’s mental models of causation, which may be wrong. It is interesting to note that people’s models of causation are influenced by the timeliness (delay) and quality of feedback in the system.

Les précédents diagrammes de boucles causales reflètent les modèles mentaux de causalité des individus … qui peuvent s’avérer faux. Il est intéressant de remarquer que les modèles de causalité des individus sont influencés par la ponctualité (ou les retards) et la qualité des feedbacks dans le système.

The implication of “mental models” is to improve our meta-cognitive skill to see and question our own assumptions and chains of reasoning. Are we making faulty leaps of logic? It also implies when working with others to discuss (inquiring rather than abusing) the mental models of our colleagues.

Les « modèles mentaux » nous permettent d’améliorer nos compétences de méta-cognition pour voir et questionner nos propres postulats et l’enchaînement de nos raisonnements. Brûlons-nous des étapes de manière erronée ? Cette question implique aussi lorsque nous sommes en train de travailler avec des collègues de discuter avec eux (en s’enquérant plutôt qu’en reprochant) de leurs modèles mentaux.

''Seeing'' these mental models is step one; ''changing'' them is the even harder part of step two. That art is beyond the scope of this introduction, though a successful LeSS adoption must involve changes in mindset and insight among many groups.

''Voir'' les modèles mentaux n’est que la première étape ; les ''changer'' constitue une seconde partie bien plus difficile. Cet art est bien au-delà du sujet de cette introduction, même si une adoption réussie de LeSS implique des changements en terme d’état d’esprit et de prise de conscience au sein de très nombreuses équipes.

A tip to better ''see'' the mental models (beliefs, chains of inference, …) playing out in the system dynamics is to ask the following question during a modeling workshop and then sketch the answers. “Let’s talk about the assumptions behind this model. What do we ''believe'' or assume in terms of facts and effects that led us here?”

Une astuce pour mieux ''voir'' les modèles mentaux (croyances, échelle d’inférence, …) en jeu au niveau des dynamiques des systèmes est de poser les questions suivantes lors d’un atelier de modélisation puis de tracer les éléments de réponse au tableau blanc. « Parlons donc des hypothèses derrière ce modèle. Que ''croyons''-nous ou tenons pour acquis en terme de faits et d’effets qui nous ont conduits ici ? »

Answers are sketched on the whiteboard model, for example:

Les éléments de réponse sont dessinés sur le tableau blanc. En voici un exemple :

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-17.png.pagespeed.ic.5UIqBnJfK1.webp|frame|none|alt=|caption systems thinking-17.png]]
Visualizing the assumptions in our heads… our mental models.

[[File:Xsystems-thinking-17-fr.png|frameless|848px|14ème schéma]]
''Visualiser les postulats présents dans nos têtes … nos modèles mentaux.''

=== Example: The “Faster is Slower” Dynamic ===

=== Exemple : La dynamique « Aller plus vite c’est aller plus lentement » ===

With the vocabulary of quick fixes, delays, positive feedback loops, and mental models, it is fascinating to see that there can be a short-term apparent improvement in a variable as the result of a quick fix, but a ''delayed degradation'' of the very same variable—the “faster is slower” dynamic. This is a recurrent dynamic in the workplace and a cause of weakness. So it is worth another illustration.

Dorénavant, avec notre vocabulaire enrichi des termes de solutions de contournement, de boucles de feedback positives et de modèles mentaux, il est fascinant de voir qu’il peut y avoir un semblant d’amélioration à court terme sur une variable donnée, mais que cela entraîne en même temps une ''dégradation à retardement'' de cette même variable - d’où la dynamique « Aller plus vite c’est aller plus lentement ». Il s’agit d’une dynamique récurrente et d’une cause de vulnérabilité à terme. Voici un nouvel exemple illustrant cela :

''The story of Microsoft Word and the'' '''''secret developer toolbox''''' : A classic example of the short-term ‘improving’ but long-term degrading dynamic is the story of the first release of Microsoft Word for Windows [http://www.amazon.com/Joel-Software-Occasionally-Developers-Designers/dp/1590593898/ref=sr_1_1?ie=UTF8&qid=1413597951&sr=8-1&keywords=Joel+on+Software [Spolsky04]]. It was released ''years'' later than desired. Why? ''Because managers tried to follow the original schedule and pushed developers to meet it'' .

''Histoire de Microsoft Word et de'' '''''la boîte à outils secrète du développeur''''' : Un exemple typique d’une ‘amélioration’ à court terme mais d’une dynamique de dégradation à long terme est le récit de la première livraison de Microsoft Word sur Windows [http://www.amazon.com/Joel-Software-Occasionally-Developers-Designers/dp/1590593898/ref=sr_1_1?ie=UTF8&qid=1413597951&sr=8-1&keywords=Joel+on+Software [Spolsky04]]. Le logiciel a été livré avec des ''années'' de retard par rapport à la date prévue. Pourquoi ? ''Parce que les managers ont essayé à tout prix de suivre le calendrier de départ et ont fait pression sur les développeurs pour le respecter''.

The story illustrates why ''wishful thinking'' is identified as one of the wastes in lean thinking. In this case the wishful thinking of insisting on (apparently) following a schedule, which implies the misconception or wishful thinking that development estimates are not estimates but are commitments—a common myth that propels degradation of a system.

Cette histoire illustre pourquoi cet espoir illusoire de respecter une date souhaitée est bien identifié comme une source de gâchis dans l’approche lean. Dans le cas présent l’espoir illusoire consiste à insister (du moins apparemment) à suivre le calendrier, ce qui implique une idée fausse ou illusoire que les estimations ne sont pas de simples estimations mais des promesses - un mythe classique qui pousse à la dégradation d’un système.

[https://less.works/less/principles/systems-thinking.html#figure-1 The next model] illustrates a ''summary'' of the dynamics of what happened when the managers pushed people to evidently keep to the original schedule, and why this quick-fix reaction to slow progress appeared to make things faster in the short term but actually even ''slower'' in the long term. See the dynamic of schedule pressure and the secret toolbox. intentionally omits some deeper dynamics that are expanded and shown in See deeper dynamics of schedule pressure and the secret toolbox..

[https://less.works/less/principles/systems-thinking.html#figure-1 Le modèle suivant] illustre un ''résumé'' des dynamiques à l’œuvre lorsque des managers poussent leurs équipes à respecter à tout prix les calendriers prévisionnels, et pourquoi cette solution de contournement qui freine pourtant l’avancement des travaux semblent les faire aller plus vite à court terme mais en réalité ''plus lentement'' à long terme. Par rapport à ce qui est décrit précédemment dans la dynamique de la pression du calendrier et la boîte à outils secrète, certaines dynamiques ont été omises intentionnellement sur ce schéma et sont visibles sur le schéma dynamiques avancées.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-18.png.pagespeed.ic.A7OSuu755I.webp|frame|none|alt=|caption systems thinking-18.png]]
The dynamic of schedule pressure and the secret toolbox.

[[File:Xsystems-thinking-18-fr.png|frameless|848px|15ème schéma]]
''Dynamique de la pression sur le calendrier et de la boîte à outils secrète.''

As a quick fix, the Microsoft managers exhorted, bribed (with potential rewards), and threatened the Word developers to keep to the original schedule. Consequently, the developers predictably pulled out their '''secret developer toolbox''' —the many practices related to hacking out dirty code (no tests, no reviews, ignore known defects, copy-paste programming, poor design, …) to apparently deliver a feature faster. You see, developers also have ''quick-fix'' reactions for their problems.

En solution de contournement, les managers de Microsoft ont exhorté, ont corrompu (à l’aide de primes potentielles), et ont menacé les développeurs de Word pour leur faire respecter le calendrier prévisionnel. En conséquence, les développeurs ont, de manière tout à fait prévisible, sorti leur '''boîte à outils secrète de développeurs''' - autrement dit tout un arsenal de pratiques pour pisser du code pourri (aucuns tests, aucunes revues, ignorance des anomalies connues, développement par copier-coller, mauvaise conception, …) pour développer visiblement plus vite. Vous voyez bien, les développeurs ont aussi des solutions de contournement pour régler leurs problèmes.

The tactics seemed to have worked like magic. As the managers pressured the developers, ‘features’ were delivered quicker as people used the secret toolbox, which reinforced the belief that pressuring developers helps. But this apparent acceleration actually had a delayed effect to make things slower, which is explored next. Since management did not quickly see the delayed effect of the secret toolbox, and because they believed managers should not be frequently looking in detail at the source code or themselves be master programmers, they did not learn from this dynamic.

Vu de l’extérieur, ces tactiques ont fonctionné à merveille. Au fur et à mesure que les managers mettaient la pression sur les développeurs, les ‘features’ étaient développées de plus en plus vite grâce à l’utilisation de la boîte à outils secrète, ce qui a renforcé la croyance en quoi mettre la pression sur les développeurs était quelque chose d’utile. Mais cette apparente accélération a eu en fait un effet à retardement qui a rendu les choses plus lentes (c’est ce que nous allons voir par la suite). Étant donné que le management n’a pas été assez rapide à voir l’effet à retardement de la boîte à outils, et parce que les managers pensent qu’ils n’ont pas besoin d’aller regarder fréquemment en détails le code source ou qu’ils n’ont pas besoin d’être eux-mêmes des développeurs très expérimentés, ils n’ont rien appris de cette dynamique.

A closer exploration of the system dynamics shows why things went slower in the long term and why the first Word for Windows release was years later than desired, illustrated in this model…

Le schéma ci-dessous illustre l’examen approfondie des dynamiques des systèmes montrant pourquoi les choses sont allées plus lentement à long terme et pourquoi le tout premier Word pour Windows a été livré des années en retard par rapport à la date souhaitée …

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-19.png.pagespeed.ic.D24dvGHzfu.webp|systems thinking-19.png]]
Some deeper dynamics of schedule pressure and the secret toolbox.

[[File:Xsystems-thinking-19-fr.png|frameless|848px|16ème schéma]]
''Dynamiques avancées de la pression sur le calendrier et de la boîte à outils secrètes.''

Naturally, lots of dirty code eventually slowed things down. More subtly, developers would ''ignore'' the bug list of ever-increasing open defects to—instead—generate new features. This led to a long delay between the creation of a defect and its correction. It turns out that this significantly increases variability and time to fix a defect because of the compounding negative effect of a long-lived bug (for example, due to workarounds and coupling) and because developers have long forgotten the detailed context of code related to the defect and therefore need to slowly rediscover that context—with more and more dirty confusing code surrounding them.

Naturellement, avoir une grande quantité de code de mauvaise qualité ralentie les choses. De manière beaucoup plus subtile, les développeurs ont ''ignoré'' la liste croissante d’anomalies pour privilégier la production de nouvelles features. Cela a eu pour conséquence d’avoir un délai important entre la déclaration d’une anomalie et sa correction. Il s’avère que cela a fait augmenter de manière significative la variabilité et le temps nécessaire pour corriger une anomalie en raison des effets cumulatifs négatifs liée à la nature même d’une vieille anomalie (par exemple avec la mise en place des solutions de contournement et des couplages existants entre les fonctionnalités), de l’oubli du contexte détaillé par les développeurs en relation avec l’anomalie, ces derniers mettant par conséquent plus de temps à le redécouvrir, de l’accumulation continue de code de mauvaise qualité dans le même temps.

The astute reader may also notice the several positive feedback loops that reinforce the degradation cycle; this is one reason the product was years later than intended.

Le lecteur avisé remarquera également plusieurs boucles causales positives renforçant le cycle de dégradation ; il s’agit de l’une des raisons expliquant le retard pris sur plusieurs années pour livrer le produit.

Solution? The lean thinking ''Stop and Fix'' and ''Go See'' principles. ''First'' , rather than trying to go faster when there are problems, manager-teachers encourage people to go ''slower'' and help them learn to see system dynamics and root causes, and to fix these—to improve the ''system'' of development. By going slower, Toyota—the masters of lean thinking—has become one of the fastest companies around. ''Second'' , for managers to ''go see at the real place of work'' to learn what is going on. The “real place” in software development is the code, which suggests that first-level managers are master programmers who are frequently evaluating the code.

Une solution ? L’approche lean avec les principes ''Arrêter et corriger'' et ''Aller voir''. ''Premièrement'', plutôt que d’essayer d’aller plus vite lorsqu’il y a des problèmes, des managers-formateurs encouragent les gens à aller plus ''lentement'' et à les inciter à apprendre les dynamiques des systèmes, les causes racines et à les corriger pour améliorer le ''système'' du développement. En allant plus lentement, Toyota - les maîtres de l’approche lean - est devenue l’une des entreprises les rapides du monde. _Deuxièmement, les managers doivent ''aller voir ce qui se passe sur le vrai lieu de travail'' pour apprendre ce qu’il se passe. Le « vrai lieu » dans le développement logiciel c’est le code, ce qui implique que les managers de proximité sont des développeurs expérimentés qui évalueront le code fréquemment.

Microsoft people did not reflect on the situation until after release. When they did finally hold a retrospective, it led to a ''zero-defects'' policy, meaning that the first priority was to fix known bugs in the code under development—to drive down to zero the open-defects list before writing more new-feature code.

Les personnes de chez Microsoft n’ont pas réfléchi sur la situation que bien après la livraison. Lorsqu’ils ont fini par faire une rétrospective, cela a amené à une politique du ''zéro défaut'', cela signifie que la première priorité était de corriger les anomalies connues dans le code en cours de développement afin d’aller vers du zéro anomalie ouverte dans la liste des anomalies avant d’écrire du code pour une nouvelle feature.

== Seeing (and Hearing) Local Optimization ==

== Voir (et entendre) l’optimisation locale ==

“Everyone is doing their best yet overall systems throughput is degrading. How can that be?” This is the paradox of '''local optimization''' —when a person or departmental decision maker optimizes for the local view or self-interest. The party making the decision frequently ''believes they are making the best decision'' , but because ‘best’ is a local optimization, in fact it sub-optimizes overall system throughput. This is a result of “silo mentality,” misunderstanding, fear, limited information, delayed feedback, ignorance, careerism, avarice, and other common ''organizational learning disorders'' .

« Chacun fait de son mieux, mais malgré tout le flux de production du système se dégrade. Comment cela est-il possible ? ». Il s’agit du paradoxe de '''l’optimisation locale''' - autrement dit c’est lorsqu’une personne à titre individuel ou un responsable de département prend une décision d’un point de vue local ou dans son propre intérêt. Les personnes prenant ce type de décision ''croient fréquemment qu’ils prennent la meilleure décision'', mais parce que ‘meilleure’ est ici synonyme d’optimisation locale, cela a pour résultat une sous-optimisation globale du flux du système. Ceci est le résultat d’une « mentalité de silo », d’incompréhension, de peur, de restrictions d’informations, de feedbacks à retardement, d’ignorance, de carriérisme, d’avarice et de bien d’autres ''dysfonctionnements d’apprentissages organisationnels''.

A small product group of 30 people does not have the time or money to engage in much nonsense or waste. But large companies, with large product groups, centralized process and tool groups, a centralized “project management office,” and so forth, seem to have raised local optimization and waste to an art form. Government bureaucracies are the quintessential example, of course. As such, when you serve as a guide in large-scale agile adoption, ''seeing'' (or ''hearing'' ) and dealing with local optimization is singularly vital.

Une petite équipe produit de 30 personnes n’a ni temps ni l’argent pour s’engager dans ce genre de non-sens ou de gâchis. Mais les grandes entreprises avec de grands groupes produit, des processus centralisés et des groupes outils, un « bureau de gestion de projet » centralisé, et ainsi de suite, semblent avoir élevé l’optimisation locale et le gâchis à une forme d’art. Les bureaucraties gouvernementales en sont bien sûr la quintessence. En conséquence, lorsque vous servez de guide dans une adoption agile à grande échelle, ''voir'' (ou ''entendre'') et s’occuper de l’optimisation locale est tout simplement quelque chose de vital.

For example, the legal and corporate security departments put in place a policy that seems terribly important from their perspective. In the aim of preventing loss of intellectual property (IP), the legal department decrees “no one shall put any information on the walls.” Or, in response to cost-cutting pressure, the facilities management says, “It is important to ensure our walls are not dirty or damaged.” And thus they shut down a practice in lean thinking, visual management (which is usually done on walls), and they inhibit a well-known innovation practice, group whiteboard work. The lawyers may succeed in reducing loss of IP (actually, that is questionable), and the facilities people will succeed in keeping the walls clean—at the cost of inhibiting the product development group from innovating and collaborating. Finally, the company falls behind with less and less IP even worth protecting because tools for innovation and delivering fast have been disallowed, but the lawyers have successfully fulfilled their mandate from the executive team to “ensure our IP is protected.” And the ''furniture police'' have clear walls. ''They have done their best'' .

Par exemple, les départements juridiques et sécurité mettent en place des politiques qui leurs semblent très importantes de leurs points de vue. Dans l’objectif de prévenir la perte de propriété intellectuelle, le département juridique peut décréter « il est interdit d’afficher tout type d’information sur les murs. ». Or, le département des immeubles soumis de son côté, à une pression de politique de réductions de coûts peut surenchérir en disant : « Il est important de s’assurer que nos murs ne soient ni sales ni abîmés ». Et ainsi s’arrête le management visuel qui est l’une des pratiques de l’approche lean (le management visuel se faisant habituellement sur les murs), et ils inhibent également une pratique d’innovation bien connue à savoir le travail de groupe devant un tableau blanc. Les juristes réussiront peut être à réduire la perte de propriété intellectuelle (ce qui en réalité devrait poser question), et les gens des immeubles réussiront à garder leurs murs propres - mais au prix d’inhiber le groupe de développement produit dans sa capacité d’innover et de collaborer. Finalement, l’entreprise se laissera distancer par la concurrence avec de moins en moins de propriété intellectuelle valant la peine d’être défendue parce que les outils permettant l’innovation et de livrer rapidement ont été bannis, mais les juristes auront rempli leur mandat vis-à-vis de la direction de « s’assurer que la propriété intellectuelle est protégée ». Et la police de la logistique aura nettoyé les murs. ''Ils ont fait de leur mieux''.

The following is a real e-mail quote from the ''FURNITURE POLICE'' in one organization that dissallowed visual management on the walls. Can you identify the local optimizations and mental models driving this?

Ce qui suit est extrait d’un vrai message électronique de la ''POLICE DE LA LOGISTIQUE'' dans une organisation qui a banni le management visuel sur les murs. Pouvez-vous identifier les optimisations locales et les modèles mentaux qui sont derrière tout ça ?

<blockquote>''Individual work cubic partition can be personalized. But things obvious higher than the partition or harming the office environment’s harmony are restricted.''
</blockquote>
<blockquote>_Les [https://fr.wikipedia.org/wiki/Bureau_%C3%A0_cloisons bureaux à cloisons] peuvent être personnalisés. Mais tout ce qui visible au-dessus de la cloison ou qui perturbe l’harmonie de l’environnement de bureau est interdite.
</blockquote>
We also see local optimization in centralized groups that make software tool choices for others. The common mindset is to choose a tool that is best at reducing some supposed cost (curiously, these groups seldom recommend free open source tools) or best at doing something complicated or best for the work of one specialized worker role (even though ''everybody'' has to use the tool), rather than maximizing the global goal of faster system throughput of value to customers.

Nous constatons aussi des optimisations locales dans les groupes centralisés dont le rôle est de choisir les logiciels pour les autres personnes de l’entreprise. La croyance la plus répandue que cette démarche est qu’il s’agit de ce qu’il y a de mieux pour réduire les coûts d’achats (curieusement ces mêmes groupes recommandent rarement les logiciels libres gratuits) ou ce qu’il y a de mieux pour accomplir une tâche compliquée ou ce qu’il y a de mieux pour l’accomplissement du travail d’un seul type de travailleur (même si ''tout le monde'' est censé devoir utiliser l’outil), plutôt que de maximiser l’objectif de l’entreprise qui est d’avoir un système de flux de production de la valeur plus rapide pour les clients.

In large-scale adoption of Scrum or agile principles, most of the “Yes, but …” issues that are raised are examples of local optimization, such as, “''Yes, but…what about management reporting''?” or more generally, “''Yes, but…what about <special case="">''?” Then, policies and practices are twisted around, serving the goal of reporting or some other secondary aim rather than the primary goal of optimizing for fast value throughput. Sometimes we see ''local optimization for the extreme or rare case'' . For example, a person responsible for making a centralized tool choice for the enterprise presents a scenario for a complex or rare case of use, and then chooses the tool that fits that, sub-optimizing for a 5 percent case instead of optimizing for ease and speed for the 95 percent case.</special>

Dans les adoptions de Scrum ou des principes agiles à grande échelle, la plupart des problématiques de type « Oui, mais … » qui sont soulevées sont des exemples de sous-optimisations, comme par exemple « ''Oui, mais … qu’en est-il des comptes-rendus auprès du management'' ? » ou encore de manière plus générale « * Oui, mais … qu’en est-il de … * ? ». Alors, les principes et les pratiques sont dévoyés, pour servir soit l’objectif de rendre compte soit n’importe quel autre objectif secondaire plutôt que suivre l’objectif d’optimiser le flux de valeur produite. De temps en temps, nous voyons des '''optimisations locales dans certains cas rares ou extrêmes'''. Par exemple, une entreprise doit choisir un outil centralisé répondant à un certain nombre de cas d’utilisations possibles dont un cas extrêmement rare ou complexe, la personne, en charge de faire ce choix, choisit un outil correspondant à un cas unique d’utilisation, sous-optimisant ainsi l’ensemble du système pour un cas représentant uniquement 5% des cas d’utilisation au lieu de l’optimiser pour la majorité des 95% des autres cas d’utilisations.

Other local optimizations are due to ignorance of new ways of working. This is especially common in large-scale product groups. For example, we once helped a large networking product group in Europe adopt Scrum and the practice of ''continuous integration'' (CI) combined with a CI system that continually integrated, built, and automatically tested the product. After some time, an outside traditional manager inspected what was going on, and recommended the integration practices should be changed—because there was no written integration plan for how a human integration manager should manually integrate all the software, and of course, there was no integration manager. They wanted to ‘optimize’ around the work of an integration manager that was no longer needed. They could not see that their entire old-fashioned model of work had been eliminated with CI. This story repeats in all the departments of a large established product: local optimization around the ''existing'' ways of work, such as manual test, a separate architecture department, component teams, and so on. A coach working to introduce large-scale Scrum at the enterprise level has a ''mountain'' of similar local optimization thinking to deal with.

D’autres optimisations locales sont dues, quant à elles, à l’ignorance des nouvelles manières de travailler. C’est quelque chose de très répandue et tout spécialement dans les groupes produit à grande échelle. Par exemple, un jour nous avons aidé un groupe produit distribué à travers l’Europe à adopter d’une part Scrum et d’autre part la pratique de ''l’intégration continue'' (CI) le tout sous la forme d’un système d’intégration continue dédié intégrant, compilant, testant automatiquement de manière continue le produit. Après quelques temps, un manager, que l’on pourrait qualifier de traditionnel, extérieur au groupe est venu inspecter ce qu’il se passait. Celui-ci a recommandé que les pratiques d’intégration devraient être changées en raison de l’absence de schéma d’intégration global permettant à un responsable d’intégration de faire manuellement l’intégration de l’ensemble du logiciel ; une absence de schéma pour la bonne raison qu’il n’y avait plus besoin de responsable d’intégration au sein de l’organisation. Il voulait ‘optimiser’ le travail d’un responsable d’intégration qui n’existait plus. Il était dans l’impossibilité de voir que la totalité de l’ancienne manière de faire les choses avait disparu avec l’intégration continue. Cette histoire se répéta dans l’ensemble des départements du groupe produit : il y a avait des optimisations locales partout autour des façons de faire existantes, tels que les tests manuels, le département d’architecture séparé des équipes, les équipes composants, etc. N’importe quel coach dont la tâche consistait à introduire Scrum à grande échelle au niveau de l’organisation avait une ''montagne'' d’optimisations locales à penser à gérer.

In lean thinking and agile methods, the focus is on global systems goals: Deliver value fast with high quality and morale—'''global optimization''' . Try to consider decisions in light of this goal. To develop an “optimize the whole” culture, challenge all decisions and policies with the question:

Dans l’approche lean et dans les méthodes agiles, l’accent est mis sur les objectifs du système dans sa globalité : livrer de la valeur de grande qualité au plus vite tout en gardant le moral des équipes au plus haut - autrement dit une '''optimisation globale'''. Essayer de reconsidérer vos décisions à la lumière de cet objectif. Pour développer une culture de « l’optimisation du tout », remettez donc en cause toutes les décisions et les règles avec la question suivante :

<blockquote>'''Does this decision or policy focus on delivering value to the external customer fast, or does it focus on the interests of a department, person, internal policy/practice, or rare case?'''
</blockquote>
<blockquote>** Est-ce que cette décision ou cette règle se focalise-t-elle sur livrer de la valeur au client externe au plus vite, ou se focalise-t-elle sur les intérêts d’un département, d’une personne, d’une pratique/règle interne, ou d’un cas rarissime ?**
</blockquote>
In LeSS, the Product Owner is responsible for choosing high-value goals that '''could lead to potentially shippable product (at the end of the Sprint) and that maximize the desired impacts and that delight the customer, while maintaining a sustainable pace and high engineering quality'''. That explicit goal is meant to orient the system toward global rather than local optimization.

Dans LeSS, le Product Owner est responsable pour choisir ces objectifs à haute valeur qui '''pourrait mener à un produit potentiellement livrable (à la fin du Sprint) maximisant les impacts souhaités et réjouissant le client tout en maintenant un rythme soutenable et une haute qualité d’ingénierie'''. Cet objectif explicite est destiné à orienter le système vers son optimisation globale plutôt que vers une optimisation qui ne serait que locale.

== Conclusion ==

== Conclusion ==

In addition to becoming a systems thinker yourself, encourage others to learn more about this topic. We suggest you to try getting together at a whiteboard with colleagues to sketch a causal loop diagram, so that ''being'' systems thinkers and ''doing'' systems thinking are connected at the workplace.

En plus de devenir un pratiquant de l’approche systémique vous-même, encouragez donc les autres à en apprendre plus sur ce sujet. Nous vous suggérons d’essayer de rassembler quelques-uns de vos collègues autour d’un tableau blanc et d’y dessiner des diagrammes de boucles causales, afin que les architectes des systèmes et les pratiquants de l’approche systémique soient réunis en un seul endroit.

<figure>
[[File:https://less.works/img/systems-thinking/xgroup,P20cld,P20modeling.jpg.pagespeed.ic.lirKMzwWbD.webp|group%20cld%20modeling.jpg]]
</figure>
[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-20-fr.png|frame|none|alt=|caption systems thinking-20.png]]

<figcaption>
Doing system thinking. Sketching a causal loop diagram together—modeling to have a conversation.
</figcaption>
Séance d’approche systémique. Réalisation d’un diagramme de boucle cause à plusieurs mains dans l’objectif d’avoir une conversation.

== Recommended Readings ==

== Lectures recommandées ==

* W. Edwards Deming’s [http://www.amazon.com/Out-Crisis-W-Edwards-Deming-ebook/dp/B00653KTES/ref=sr_1_1?ie=UTF8&qid=1413601625&sr=8-1&keywords=out+of+the+crisis ''Out of the Crisis''] is a master work by arguably the most well-known systems thinker and quality expert. It opens with the modest goal, “The aim of this book is transformation of the style of American management… It requires a whole new structure, from foundation upward.” Deming also advocates the ''System of Profound Knowledge'' in which managers (1) appreciate there is a ''system'' , (2) understand common-cause and special-cause variation (queueing theory is related to variation), (3) understand limitations of knowledge and reasoning mistakes, and (4) know credible psychology and social research results so that behavior- or motivation-related policies are ''not'' based on “common sense.” The core of the book centers around his famous ''14 Points for Management'' , including (for example), “''Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership'' .”
* [https://www.amazon.fr/Hors-crise-W-Edwards-Deming/dp/2717843930/ ''Hors de la Crise''] de W. Edwards Deming est un ouvrage de référence par, sans conteste, le plus connu des penseurs systémiques et des experts sur la qualité. Cet ouvrage commence par un objectif modeste : « l’objectif de ce livre est la transformation du style du management américain … ce qui exige une toute nouvelle structure de fonds en combles. ». Deming prône un ''Système de connaissances approfondies'' dans lequel les managers (1) reconnaissent qu’il y a un ''système'', (2) qu’ils sont en mesure de comprendre les facteurs les plus répandus et les facteurs spéciaux de variations au sein du système (la théorie des files d’attente est liée à ce phénomène de variation), (3) qu’ils sont en mesure de comprendre que les connaissances sont limitées et qu’il y a des erreurs de raisonnements, et (4) que la psychologie et les recherches en sciences sociales jouent des rôles tout à fait crédibles dans l’objectif de comprendre que les règles régissants les comportements ou en lien avec la motivation des individus ne soient pas basés sur le seul « bon sens ». Le cœur de l’ouvrage tourne autour des célèbres ''14 points pour le management'', y compris par exemple « ''Éliminer le management par les objectifs. Éliminer le management par les nombres, par les objectifs par les nombres. Y substituer le leadership''»
* Jay Forrester’s [http://www.amazon.com/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ref=sr_1_1?ie=UTF8&qid=1413601681&sr=8-1&keywords=industrial+dynamics ''Industrial Dynamics''] is the classic text on system dynamics—well written and insightful. Although written in the early 1960s, it is as relevant today as when published. It goes beyond cause-effect modeling to also model the flow and inventories of information, money, and material in systems. The book includes formal mathematical modeling but this is not obligatory to appreciate system dynamics.
* [https://www.amazon.fr/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ ''Industrial Dynamics''] de Jay Forrester est un classique du genre sur les dynamiques des systèmes - très bien écrit et très instructif. Même si cet ouvrage a été écrit au début des années 1960, il est toujours aussi pertinent aujourd’hui. Il va au-delà de la modélisation des causes à effets pour modéliser également le flux et les stocks d’informations, d’argent et de matériaux au sein d’un système. Le livre contient également une modélisation mathématique formelle de ces dynamiques, toutefois la lecture de cette dernière reste facultative quant à apprécier la qualité de l’ouvrage.
* Weinberg’s ''Quality Software Management: Systems Thinking'' and ''An Introduction to General Systems Thinking'' are worthwhile. Written from the perspective of an experienced consultant in systems development.
* Les ouvrages [https://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226/ ''Quality Software Management: Systems Thinking''] et [https://www.amazon.fr/Introduction-General-Systems-Thinking-Weinberg/dp/0932633498/ ''An Introduction to General Systems Thinking''] de Gerald Weinberg sont intéressants. Il sont écrits du point de vue d’un consultant expérimenté en développement de systèmes.
* Senge’s [http://www.amazon.com/Fifth-Discipline-Practice-Learning-Organization-ebook/dp/B000SEIFKK/ref=sr_1_1?ie=UTF8&qid=1413601715&sr=8-1&keywords=the+fifth+discipline ''The Fifth Discipline''] is a classic that advocates the need for leadership to apply systems thinking (it is the ''fifth'' discipline) and other key disciplines for a great, sustainable enterpise. The others include leaders with (1) personal mastery and (2) reflection on their beliefs and faulty reasoning, the (3) definition and communication of a meaningful shared vision, and (4) the ability of teams to learn. We recommend ignoring—at least during the first few years of practice—the ‘archetypes’ notion presented in the book. It was well meant as a learning aid but has been observed to distract and intimidate people from learning and applying basic system dynamics modeling. The ‘archetypes’ are not part of original system dynamics.

[https://www.amazon.fr/cinqui%C3%A8me-discipline-Levier-organisations-apprenantes/dp/2212559372/ ''La cinquième discipline''] est un autre classique du genre qui prône que l’encadrement d’une entreprise devrait appliquer l’approche systémique (autrement dit la ''cinquième'' discipline) ainsi que d’autres disciplines-clés toutes aussi importantes en vue d’obtenir une entreprise durable. Ces autres disciplines que les dirigeants devraient appliquer sont (1) une maîtrise personnelle des aspirations, (2) une réflexion sur leurs propres croyances et raisonnements erronés, (3) la définition et la communication d’une vision partagée ayant du sens, et (4) la capacité des équipes à apprendre. Nous vous recommandons d’ignorer - du moins dans un premier temps pendant vos premières années de pratiques - le concept d’archétypes présenté dans le livre. Ce concept avait pour but d’être une aide à l’apprentissage de la cinquième discipline mais nous avons observé qu’il était soit une source de distraction soit qu’il intimidait les lecteurs quant à leur apprentissage et à l’application de la modélisation des dynamiques des systèmes. Les ‘archetypes’ ne font pas partie à l’origine des dynamiques des systèmes.

* [http://www.amazon.com/Fifth-Discipline-Fieldbook-Strategies-Organization-ebook/dp/B00JTCJEO8/ref=sr_1_1?ie=UTF8&qid=1413601809&sr=8-1&keywords=The+Fifth+Discipline+Fieldbook ''The Fifth Discipline Fieldbook''] is an in-depth resource, written from the viewpoint of many practitioners and consultants.

*[https://www.amazon.fr/guide-lorganisation-apprenante-d%C3%A9velopper-lintelligence/dp/2212568711/ ''La 5ème discipline - le guide de l’organisation apprenante''] est une source extrêmement riche sur l’approche systèmique écrite du point de vue des pratiquants de cette approche et de consultants.

* The organizational-learning writings from Argyris, Putnam, McLain, and Schön. Important concepts include ''double-loop learning'' and ''high-advocacy/high-inquiry dialogue''. Classic works include [https://actiondesign.com/resources/readings/action-science ''Action Science''] and [http://www.amazon.com/Organizational-Learning-Addison-Wesley-Organization-Development/dp/0201001748/ref=sr_1_11?ie=UTF8&qid=1413601940&sr=8-11&keywords=organizational+learning ''Organizational Learning''].
* Les écrits d’Argyris, Outnam, McLain et Schön sur les apprentissages organisationnels comme [https://actiondesign.com/resources/readings/action-science ''Action Science''] et [http://www.amazon.com/Organizational-Learning-Addison-Wesley-Organization-Development/dp/0201001748/ref=sr_1_11?ie=UTF8&qid=1413601940&sr=8-11&keywords=organizational+learning ''Organizational Learning''] abordent des concepts importants tels que la ''double-boucle apprenante'' et le ''dialogue grand-plaidoyer/grand-réquisitoire''.
* The publications and resources available through the [https://www.solonline.org/ ''Society for Organizational Learning''].
* Les publications et les ressources de la ''Society for Organizational Learning''](https://www.solonline.org/).

-----

===== Notes: =====

# Senge wrote ''The Fifth Discipline'' , on systems thinking and learning organizations, named “one of the seminal management books of the last 75 years” by the ''Harvard Business Review.'' See** [Senge94].
# Another reason: Believing more control is possible than actually is. Complexity science suggests fundamental limits on predicting and controlling semi-chaotic social systems [Stacey07]. This is a rather large can of worms that will remain unopened in this book.
# Macroeconomics, psychology, sociology, and biology are exceptions, among many others.
# ‘Basic’ does not mean trivial or easy to solve. For example, ‘motivation’ and ‘quality’ are basic but not easy issues.
# ''Feedback loops'' is occasionally used in this book in the colloquial sense of feedback, rather than this system dynamics sense.

[^1] ''La cinquième discipline'' écrit par Senge sur l’approche systèmique et les organisations apprenantes a été nommé « l’un des livres les plus novateurs sur le management de ces 75 dernières années » par la ''Harvard Business Review.'' See** [Senge94]. [^2]: Une autre raison : Croire que plus de contrôle est possible qu’il ne l’est actuellement. La science de la complexité montre qu’il existe des limites en terme de prédiction et de contrôle des systèmes sociaux semi-chaotiques [Stacey07]. C’est une énorme boîte de Pandore qui restera enfermée dans ce livre. [^3]: Macro économie, psychologie, sociologie et biologie sont des exemples d’exceptions parmi d’autres [^4]: ‘Basique’ ne signifie pas trivial ou facile à résoudre. Par exemple, les problématiques de ‘motivation’ et de ‘qualité’ sont des problématiques basiques mais elles ne sont pas faciles à résoudre. [^5]: ''Les boucles de feedback'' sont parfois utilisées dans ce livre dans le sens littéral du terme, plutôt dans le sens des dynamiques des systèmes

Fichier:Xsystems-thinking-19-fr.png

2020-10-27T21:22:23Z

Nicolas Mereaux :

Fichier:Xsystems-thinking-18-fr.png

2020-10-27T21:21:51Z

Nicolas Mereaux :

Fichier:Xsystems-thinking-17-fr.png

2020-10-27T21:20:17Z

Nicolas Mereaux :

Fichier:Xsystems-thinking-16-fr.png

2020-10-27T21:19:40Z

Nicolas Mereaux :

Fichier:Xsystems-thinking-15-fr.png

2020-10-27T21:19:07Z

Nicolas Mereaux :

Fichier:Xsystems-thinking-14-fr.png

2020-10-27T21:18:21Z

Nicolas Mereaux :

Fichier:Xsystems-thinking-13-fr.png

2020-10-27T21:18:01Z

Nicolas Mereaux :

Fichier:Xsystems-thinking-12-fr.png

2020-10-27T21:17:44Z

Nicolas Mereaux :

Fichier:Xsystems-thinking-11-fr.png

2020-10-27T21:17:24Z

Nicolas Mereaux :

Fichier:Xsystems-thinking-10-fr.png

2020-10-27T21:17:02Z

Nicolas Mereaux :

Fichier:Xsystems-thinking-9-fr.png

2020-10-27T21:16:36Z

Nicolas Mereaux :

Fichier:Xsystems-thinking-8-fr.png

2020-10-27T21:14:39Z

Nicolas Mereaux :

Fichier:Xsystems-thinking-7-fr.png

2020-10-27T21:12:58Z

Nicolas Mereaux :

Fichier:Xsystems-thinking-6-fr.png

2020-10-27T21:12:03Z

Nicolas Mereaux :

Fichier:Xgroup-cld-modeling.jpg

2020-10-27T21:02:54Z

Nicolas Mereaux :

Fichier:Xsystems-thinking-5-fr.png

2020-10-27T21:00:57Z

Nicolas Mereaux :

Fichier:Xsystems-thinking-4-fr.png

2020-10-27T20:33:08Z

Nicolas Mereaux :

LeSS - Approche systémique

2020-10-27T20:30:44Z

Nicolas Mereaux : Page créée avec « = Systems Thinking = = Approche systémique = I took a speed reading course and read “War and Peace” in twenty minutes. It involves Russia. —Woody Allen J’ai pr... »

= Systems Thinking =

= Approche systémique =

I took a speed reading course and read “War and Peace” in twenty minutes. It involves Russia. —Woody Allen

J’ai pris un cours de lecture rapide puis j’ai lu « Guerre et Paix » en vingt minutes. Cela parle de la Russie.

“No matter what we do, the number of defects in our backlog remains about the same,” a manager told us; this for a 15 MSLOC C and C++ product with several hundred developers where we were working. What’s going on? Systems thinking may help. In small groups the forces at play are more quickly seen and informally understood, but in large product development—or any large system—it’s tough. Gerry Weinberg highlights two decisive factors in this situation:

« Quoi que nous fassions, le nombre d’anomalie dans notre ''backlog'' reste identique. » nous a dit un jour un manager en évoquant un produit de près de 15 millions de lignes de code sur lequel plusieurs centaines de développeurs étaient en train de travailler. Que pouvait-il bien se passer ? L’approche systémique peut s’avérer utile dans ce cas comme dans d’autres. En petits groupes, les forces en présence peuvent rapidement être identifiées et comprises de manière informelle, mais dans le cadre du développement d’un gros produit ou de n’importe quel gros système, c’est difficile. Gerry Weinberg met en avant deux facteurs décisifs dans ce genre de situation :

<blockquote>'''Weinberg-Brooks’ Law''': More software projects have gone awry from management’s taking action based on '''''incorrect system models''''' than for all other causes combined.

'''Causation Fallacy''': Every effect has a cause… and we can tell which is which. [http://www.amazon.com/Quality-Software-Management-Systems-Thinking/dp/0932633226/ref=sr_1_1?ie=UTF8&qid=1413527418&sr=8-1&keywords=Quality+Software+Management%3A+Systems+Thinking [Weinberg92]]
</blockquote>
<blockquote>'''Loi de Weinberg-Brooks''' : De plus en plus de projets informatiques sont partis de travers après que le management ait pris des décisions basées sur des '''modèles systémiques incorrects''' plus que pour toutes autres causes combinées.

'''Erreur de causalité''' : Chaque effet a une cause … et nous pouvons dire desquelles il s’agit. [http://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226/ref=sr_1_1?ie=UTF8&qid=1413527418&sr=8-1&keywords=Quality+Software+Management%3A+Systems+Thinking [Weinberg92]]
</blockquote>
These reflect the impact of our '''mental models''' on the system, a subject that will be revisited later in this section.

Ces deux facteurs reflètent bien l’impact de nos '''modèles mentaux''' sur le système, un sujet que nous reverrons plus tard dans cette section.

Problems stemming from mental models and assumptions are one issue. Another is that large-scale adoption of Scrum, lean thinking, and agile principles is not isolated to the development group. It bumps into product management, budgeting, beta-testing, launch, and governance and HR policies. Accordingly, in large-scale agile adoption it is useful to be able to get together with colleagues and ''effectively reason'' about the mental models, causal relations, feedback loops, and control mechanisms (or illusions of control) in a big system that is about to be seriously ''perturbed.'' Systems thinking is one of those reasoning tools.

Les problèmes résultant de nos modèles mentaux et de nos postulats sont un point à traiter. Un autre point est l’adoption à grande échelle de Scrum, de l’approche lean et des principes agiles en dehors du domaine du développement. Ce point est aussi présent dans la gestion de produit, les budgets, les tests, la commercialisation, la gouvernance et la politique RH. En conséquence, dans les adoptions agiles à grande échelle, il est utile de se réunir avec des collègues et de ''réfléchir en profondeur'' sur les modèles mentaux, les relations causales, les boucles de ''feedback'' et les mécanismes de contrôles (ou les illusions de contrôle) dans un gros système qui va être sérieusement ''pertubé''. L’approche systémique est l’un de ces outils de réflexion.

In 1958, the ''Harvard Business Review'' published [https://kupdf.com/download/industrial-dynamics-a-major-breakthrough-for-decision-makers_5902479bdc0d603940959ed5_pdf “Industrial Dynamics: A Major Breakthrough for Decision Makers,”] a landmark paper by Jay Forrester, MIT Sloan School professor. This paper spurred the movement of systems thinking in business education, and the MIT Sloan School of Management became known for educating people in '''system dynamics'''. System dynamics is sometimes treated as a synonym for '''systems thinking''' , though the latter is a more general term.

En 1958 la ''Harvard Business Review'' a publié un article de Jay Forrestor, professeur au MIT Sloan School, qui a fait date [https://kupdf.com/download/industrial-dynamics-a-major-breakthrough-for-decision-makers_5902479bdc0d603940959ed5_pdf “Industrial Dynamics: A Major Breakthrough for Decision Makers,”]. Cet article a lancé le mouvement de l’approche systémique dans le domaine des formations en gestion d’entreprise et la MIT Sloan School of Management devint célèbre pour ses formations en '''dynamique des systèmes'''. Le terme de dynamique des systèmes est parfois utilisé comme synonyme d’'''approche systémique''', même si ce dernier est un terme beaucoup plus général.

MIT also attracted other system-dynamics-oriented researchers such as Peter Senge.[https://less.works/less/principles/systems-thinking.html#footnote-1 1]

Le MIT a également attiré d’autres chercheurs intéressés par la dynamique systémique tel que Peter Senge[^1].

Consistent with ''Weinberg-Brook’s Law'', Forrester’s research showed that decision makers who were given dynamic models of a business system and asked to improve their output performance, ''usually made them run worse'' [http://www.amazon.com/The-Fifth-Discipline-Fieldbook-Organization/dp/0385472560/ref=sr_1_fkmr0_3?ie=UTF8&qid=1413528034&sr=8-3-fkmr0&keywords=The+Fifth+Discipline+%EF%BF%BCFieldbook [SKRRS94]]. The observation was that most people have weak judgement on how to fundamentally improve systems, usually applying incorrect “common sense” and quick-fix ‘solutions’ that do not create long-lasting systemic improvement.

En corrélation avec la loi de ''Weinberg-Brook'', Jay Wright Forrester a montré que les décideurs à qui il avait été donné des modèles dynamiques de systèmes opérationnels et à qui il avait été demandé d’améliorer la performance opérationnelle, ''n’avaient fait généralement qu’empirer les choses'' [https://www.amazon.fr/guide-lorganisation-apprenante-d%C3%A9velopper-lintelligence/dp/2212568711/ [SKRRS94]]. Il en est ressorti d’ailleurs que la plupart des personnes évaluaient mal la manière dont il faut améliorer les systèmes, et appliquaient généralement leur « bon sens », en mettant en place des solutions de contournement qui n’apportent aucune amélioration systémique à long terme.

Why is the behavior of a large development group (a system) not understood or guided skillfully? The answer lies, in part, in the behavior of stochastic systems with queues and variability, as explored in the [https://less.works/less/principles/queueing_theory.html Queueing Theory] LeSS principle. And the same answer lies in ''control theory'': Most systems of interest—such as a product development group—have complex positive and negative feedback loops and nonlinear behavior. The behavior of these systems defies our gut instinct. And then there is the minor issue of ''people''.

Pourquoi le comportement d’un groupe de développement de grande taille (autrement dit un système) n’est-il pas compris ou guidé de manière compétente ? La réponse réside, en partie, dans le comportement des systèmes stochastiques avec les files et les variabilités comme nous avons pu l’évoquer avec le principe LeSS de la [http://www.les-traducteurs-agiles.org/2017/01/29/less-theorie-des-files-d-attente.html théorie des files d’attentes]. Et c’est la même réponse qui est au cœur de la ''théorie du contrôle'' : la plupart des systèmes d’intérêt - tel qu’un groupe de développement de produit - ont des boucles de ''feedback'' positives et négatives ainsi qu’un comportement non linéaire. Le comportement de ces systèmes défient nos instincts. Et puis il y a la problématique mineure des ''gens''.

In summary, reasons for not being skillful in fathoming or guiding a big system include (but are not limited to):

En résumé, les raisons expliquants l’incompétence à maîtriser ou à guider un gros systèmes sont (liste non exhaustive) :

* lack of knowledge about the system dynamics, feedback loops, nonlinear systems behavior, and unintended consequences in workplace systems
* un manque de connaissance des dynamiques des systèmes, des boucles de ''feedback'', du comportement non linéaire des systèmes, et des conséquences inattendues dans les systèmes sur le lieu de travail.
* not understanding root causes of problems (and how to find)
* une incompréhension des causes racines des problèmes (et de comment les trouver)
** ''causes,'' not cause; in systems thinking one sees that there are multiple, indirect, and dynamic causes to problems
** ''les causes'', non la cause ; en approche systémique, nous savons que les causes des problèmes sont multiples, indirectes et dynamiques
* not knowing if or why quick-fix or local-department decisions degraded overall delivery performance.
* l’incapacité à savoir si ou pourquoi une solution de contournement ou une décision locale dégrade la performance globale opérationnelle.

In short, not being systems thinkers.[https://less.works/less/principles/systems-thinking.html#footnote-2 2]

En bref, ne pas utiliser l’approche systémique[^2].

These reasons are consequential at the intersection of management and large-scale adoption of lean and agile principles. The leadership team is part of the system being perturbed; if they do not apply systems thinking, they could ''really'' perturb it—and not in a good way!

Ces raisons sont la conséquence de l’intersection du management et de l’adoption des principes lean et agile. L’équipe de direction fait partie du système qui est pertubé ; si elle n’applique pas l’approche systémique, elle pourrait ''vraiment'' le perturber - et pas de la bonne façon.

As a summary of systems thinking insight, we like the [https://en.wikipedia.org/wiki/The_Fifth_Discipline#The_11_Laws_of_the_Fifth_Discipline 11 ‘laws’] described in [http://www.amazon.com/Fifth-Discipline-Practice-Learning-Organization-ebook/dp/B000SEIFKK/ref=sr_1_1?ie=UTF8&qid=1413531002&sr=8-1&keywords=the+fifth+discipline The Fifth Discipline]:

Les points-clés à retenir de l’approche systémique peuvent être résumé dans les [https://en.wikipedia.org/wiki/The_Fifth_Discipline#The_11_Laws_of_the_Fifth_Discipline 11 lois] décrites dans la [https://www.amazon.fr/cinqui%C3%A8me-discipline-organisations-apprenantes-dexemplaires-ebook/dp/B017WSYAHG Cinquième discipline]

* Today’s problems come from yesterday’s ‘solutions.’
* The harder you push, the harder the system pushes back.
* Behavior will grow worse before it grows better.
* The easy way out usually leads back in.
* The cure can be worse than the disease.
* Faster is slower.
* Cause and effect are not closely related in time and space.
* Small changes can produce big results…but the areas of highest leverage are often the least obvious.
* You can have your cake and eat it too—but not all at once.
* Dividing an elephant in half does not produce two small elephants.
* There is no blame.
* Les problèmes d’aujourd’hui viennent des solutions d’hier
* Plus vous poussez, plus le système pousse en retour
* Le comportement empirera d’abord avant de s’améliorer
* La manière la plus facile de s’en sortir conduit souvent à faire quelques pas en arrière
* Le médicament peut être pire que la maladie
* Plus vite c’est plus lentement
* Les causes et les effets ne sont pas étroitement liés dans l’espace et le temps
* De petits changements peuvent produire de gros résultats … mais les zones où l’effet de levier est le plus important sont souvent les moins évidentes
* Vous pouvez avoir votre gâteau et le manger aussi - mais pas en une seule bouchée
* Couper un éléphant en deux ne produit pas deux petits éléphants
* Il n’y a aucun reproche à faire

Toyota’s internal motto is [http://www.toyota-global.com/company/toyota_traditions/quality/may_jun_2005.html “Good '''thinking''', good products.”] Systems thinking is a set of ''thinking'' tools to help…

La devise de Toyota en interne est [http://www.toyota-global.com/company/toyota_traditions/quality/may_jun_2005.html « Une bonne '''réflexion''', de bons produits »]. L’approche systémique est un jeu d’outils de réflexion pour aider …

* '''see system dynamics'''—a development organization is a system of people and policies with subtle feedback loops and unintended consequences
* '''à voir les dynamiques des systèmes''' - une organisation de développement est un système de personnes et de règles avec de subtiles boucles de ''feedback'' et des conséquences inattendues
** we can learn to see and thus improve the system with '''causal loop diagrams''' created in a workshop
** nous pouvons apprendre à voir et ainsi à améliorer le système avec des '''diagrammes de boucles causales''' faits lors d’un atelier
* '''see mental models'''—one reason behind suboptimal decisions is mistaken assumptions and faulty reasoning
* '''à percevoir les modèles mentaux''' - parmi les raisons derrière des décisions sous-optimales se trouvent des hypothèses erronées et des raisonnements incorrects
** causal loop diagramming and Five Whys expose these
** les diagrammes de boucles causales et les cinq pourquoi permettent de révéler tout ça
* '''see local optimization'''—another source of suboptimal decisions is '''local optimization''' , making the ‘best’ decision from the viewpoint of a person or department, rather than '''global optimization''' for the lean systems-level goal of ''deliver value fast with high quality and high morale'' .
* '''à voir les optimisations locales''' - une autre source de décisions sous-optimales est '''l’optimisation locale''', autrement dit prendre la « meilleure » décision du point de vue d’une personne ou d’un département, au détriment d’une '''optimisation globale''' qui est l’objectif au niveau système ''lean'' que de pouvoir ''livrer la plus grande valeur possible de très grande qualité avec un moral d’acier''

This introduction is organized around the following areas in systems thinking: Learning to see (1) ''system dynamics'' , (2) ''mental models'' , (3) ''root causes'' , and (4) ''local optimization'' .

Cette introduction à l’approche systémique est présenté autour des domaines suivants : Apprendre à voir (1) ''les dynamiques des systèmes'', (2) ''les modèles mentaux'', (3) ''les causes racines'', et (4) ''l’optimisation locale''.

== Seeing System Dynamics: Introduction ==

== Voir les dynamiques des systèmes : Introduction ==

=== Static versus Dynamic Complexity ===

=== Complexité statique versus complexité dynamique ===

Many of us, especially in engineering and finance, are educated to master '''complexity of static details'''—learning to analyze and manage information (requirements, financial analysis, …), decompose complex structures into simpler ones, and so forth. That is, complexity of a static, information, or structural nature.

La plupart d’entre nous, notamment les ingénieurs et les financiers, ont été formés pour maîtriser la '''complexité de détails statiques''' - en apprenant à analyser et à gérer l’information (exigences, analyses financières, …), à décomposer des structures complexes en structures simples, et ainsi de suite. C’est-à-dire, la complexité d’une information qui est par nature structurellement statique.

Why do big software systems tend to degrade, with more and more time spent on defects? What might happen if the USA invades Iraq? Seeing the dynamics behind these questions involves analysis of the '''complexity of dynamics''' .

Pourquoi les gros systèmes informatiques ont-ils tendance à se dégrader malgré de plus en plus de temps passé sur les anomalies ? Qu’est-ce qui pourrait bien se passer si les États-Unis d’Amérique envahissait l’Irak ? Voir les dynamiques derrière ces questions implique d’analyser la '''complexité des dynamiques''' en jeu.

In contrast to static-details education, many of us receive no ''formal'' education in analyzing ''dynamics'' complexity[https://less.works/less/principles/systems-thinking.html#footnote-3 3], especially workplace dynamics. Perhaps there is a belief it is sufficient to rely on common sense in the workplace. Forrester demonstrated that “common sense” is just not so in complex systems, and showed it is possible to formally educate people to become better system dynamics thinkers in the workplace using ''dynamic system models'' visualized in ''flow diagrams'' [http://www.amazon.com/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ref=sr_1_1?ie=UTF8&qid=1413582840&sr=8-1&keywords=Industrial+Dynamics [Forrester61]].

En contraste avec une formation sur les détails statiques que la plupart d’entre nous avons suivie, peu d’entre nous ont reçu de formation sur l’étude des systèmes dynamiques et complexes[^3] et notamment en milieu professionnel. Peut-être parce que nous avons la croyance qu’il est suffisant de s’appuyer sur le bon sens en milieu professionnel. Jay Wright Forrester a démontré que le « bon sens » n’est pas suffisant dans des systèmes complexes et qu’il est possible de former des personnes pour leur permettre de mieux appréhender les dynamiques des systèmes en milieu professionnel en utilisant notamment des ''diagrammes de flux'' [http://www.amazon.fr/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ref=sr_1_1?ie=UTF8&qid=1413582840&sr=8-1&keywords=Industrial+Dynamics [Forrester61]].

Flow diagrams encompass material, financial, and information flows, stocks (variables with a quantity, such as cash or number of defects), the impact of decisions and policies, and cause-effect relations. A popular simplification is the '''causal loop diagram''' that focuses on cause-effect relationships and feedback loops in a system [http://www.amazon.com/Business-Dynamics-Systems-Thinking-Modeling/dp/0071179895 [Sterman00]]. There are a variety of similar notations; they all show stocks (variables), causal links, and delay. In [http://www.amazon.com/Quality-Software-Management-Systems-Thinking/dp/0932633226/ref=sr_1_1?ie=UTF8&qid=1413527418&sr=8-1&keywords=Quality+Software+Management%3A+Systems+Thinking [Weinberg92]] this is called the ''diagram of effect'' .

Les diagrammes de flux peuvent s’appliquer aussi bien aux flux matériels, financiers, d’informations, de stocks (n’importe quel type de stock quantitatif comme de l’argent ou des anomalies), aux conséquences des décisions et des politiques et des relations de causes à effet. Lorsque nous pensons aux diagrammes de flux, nous pensons souvent au seul diagramme de boucle causale dédié aux relations de cause à effets et aux boucles de rétroaction dans un système [http://www.amazon.fr/Business-Dynamics-Systems-Thinking-Modeling/dp/0071179895 [Sterman00]]. Il existe une grande variété d’autres diagrammes qui peuvent faire figurer les stocks (quels qu’ils soient), les liens de causalités, et les retards. Dans son ouvrage, [http://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226/ref=sr_1_1?ie=UTF8&qid=1413527418&sr=8-1&keywords=Quality+Software+Management%3A+Systems+Thinking [Weinberg92]] Gerald Weinberg appelle cela un ''diagramme d’effet''.

=== The First Law of Diagramming: Model to Have a Conversation ===

=== La première loi de la réalisation d’un diagramme : nous modélisons pour avoir une conversation ===

A tool to learn to see system dynamics is a causal loop diagram, ideally sketched on a whiteboard in a LeSS Overall Retrospective with colleagues. Before going further, here is the ''First Law of Diagramming''

Un outil très utile pour apprendre les dynamiques des systèmes est le diagramme de boucles causales - nous vous recommandons de l’utiliser sur un tableau blanc notamment lors des Rétrospectives Globales LeSS. Mais avant d’aller plus loin, voici la ''première loi de réalisation d’un diagramme''.

<blockquote>'''The primary value in diagrams is in the discussion while diagramming—we model to have a conversation.'''
</blockquote>
<blockquote>'''La première valeur d’un diagramme c’est la discussion qui se déroule lors de la réalisation du diagramme - nous modélisons pour avoir une conversation.'''
</blockquote>
When a group gets together to sketch a causal loop diagram on a whiteboard (See it is the the acts of discussing and thinking that are most important when diagramming, Valtech India.), the primary value is the conversation and shared understanding they arrive at while creating the model. Its visualization as an easy-to-see diagram ''is'' important to make concrete and unambiguous (on the whiteboard) the ideas—the mental models people have—because words alone can be fuzzy and misunderstood. But still, the diagram is secondary to what people take away: learning and a revised understanding through a discussion.

Lorsqu’un groupe se rassemble pour dessiner un diagramme de boucles causales sur un tableau blanc (« C’est l’acte de discuter et de réfléchir qui est le plus important lorsque nous dessinons », Valtech India.), la première valeur d’un diagramme c’est la conversation et la compréhension commune à laquelle les personnes arrivent lors de la création du modèle. Ce qu’il en résulte à savoir un diagramme facile à comprendre est important pour rendre les idées et les modèles mentaux concrets et non ambigües (sur le tableau blanc) parce que les mots seuls peuvent être imprécis et mal compris. Toutefois, le diagramme est secondaire par rapport avec ce que les gens repartent : ils ont appris quelque chose et ont revu leur compréhension du monde à travers une discussion.

<figure>
[[File:https://less.works/img/systems-thinking/xgroup,P20cld,P20modeling.jpg.pagespeed.ic.lirKMzwWbD.webp|frame|none|alt=|caption group%20cld%20modeling.jpg]]

[[File:https://less.works/img/systems-thinking/xgroup,P20cld,P20modeling.jpg.pagespeed.ic.lirKMzwWbD.webp|frame|none|alt=|caption group%20cld%20modeling.jpg]]

<figcaption>
Doing system thinking. Sketching a causal loop diagram together—modeling to have a conversation.
</figcaption>
</figure>
Un atelier d’approche systémique : réalisation d’un diagramme de boucles causales à plusieurs - modéliser pour avoir une conversation.

''Concrete modeling tip'' : We start by writing on sticky notes to define ''variables'' . A note might read “feature velocity” or “# defects.” We place these on a whiteboard. Then we sketch causal link lines between the sticky notes. There will be (or should be) lots of rewriting, erasing, and redrawing during the modeling session. The most meaningful outcome is ''understanding'' ; in addition, some participants will want to take a digital photo of the whiteboard sketch.

''Trucs et astuces de pro pour modéliser'' : Nous commençons par écrire sur des petits papiers repositionnables les noms des ''variables'', par exemple « vélocité des ''features'' » ou « nombre d’anomalies ». Nous les plaçons ensuite sur le tableau blanc. Puis nous dessinons les liens de causalités entre les papiers . Il y aura (ou il devrait y avoir) beaucoup de réécriture, d’effaçage, de redessin lors de la session de modélisation. Le résultat le plus important d’une telle session est la ''compréhension'' - il se peut qu’à l’issue de cet atelier, certains participants voudront prendre une photo du dessin du tableau blanc.

== Seeing System Dynamics: Causal Loop Diagrams ==

== Voir les dynamiques des systèmes : les diagrammes de boucles causales ==

Causal loop diagrams are used regularly in introductions to LeSS, to help see the dynamics of what is going on in large-scale development. It is useful to understand them for that reason alone. And more useful to you, we recommend you do these together with colleagues at a whiteboard. Model to have a conversation. When? Probably during a LeSS Overall Retrospective.

Les diagrammes de boucles causales sont souvent utilisés en introduction à LeSS pour aider à voir les dynamiques de ce qu’il se passe dans du développement à grande échelle. Il est donc utile de comprendre ce type de diagrammes pour cette seule et unique raison. Et cela s’avèrera encore plus utile pour vous, si vous le faites avec vos collègues devant un tableau blanc. Vous modélisez pour avoir une conversation. Quand ? Plus probablement lors d’une rétrospective globale LeSS.

The practical aspect of this tip is more important than may first be appreciated. It is vague and low-impact to suggest “be a systems thinker.” But if you and four colleagues get into the habit of standing together at a large whiteboard, sketching causal loop diagrams together, then there is a concrete and potentially high-impact practice that connects “''be'' a systems thinker” with “''do'' systems thinking.”

L’aspect pratique de cet exercice est bien plus important que ce qu’il peut paraître au premier abord. Notre conseil d’« être un pratiquant systémique » peut vous sembler vague et sans grand impact. Mais si vous et quatre de vos collègues prenez l’habitude de vous réunir devant un grand tableau blanc, en dessinant des diagrammes de boucles causales ensemble, alors vous arriverez à faire la connexion entre « ''être'' un pratiquant systémique » avec « ''faire'' de l’approche systémique ».

The following examples seem sterile when presented in a book. But imagine you were at a whiteboard with other people and the diagrams were being sketched during a lively conversation. That’s the way we suggest ‘doing’ systems thinking.

Les exemples suivants peuvent paraître stériles car présentés dans un livre. Mais imaginez-vous à côté d’un tableau blanc avec d’autres personnes dessinant ensemble des diagrammes au cours d’une conversation animée. C’est de cette manière-là que nous suggérons de ‘ faire ’ de l’approche systémique.

====== Notation and Examples ======

====== Notation et exemples ======

Causal loop diagrams contain many elements; the following common useful subset is explored through a scenario.

Les diagrammes de boucles causales contiennent beaucoup d’éléments ; les éléments suivants sont les plus communément utilisés et sont vus en détail tout au long du scénario qui va suivre

* variables
* causal links
* opposite effects
* constraints
* goals
* reactions; quick-fix reactions
* interaction effects
* extreme effects
* delays
* positive feedback loops
* variables
* liens de causalité
* effets opposés
* contraintes
* objectifs
* réactions ; réactions solutions de contournement
* effets d’interaction
* effets extrêmes
* retards
* boucles de ''feedback'' positives

''The following simplified scenario is for a particular organization. It is not a generalization.''

''Le scénario qui suit est un scénario simplifié pour une organisation spécifique. Il ne s’agit pas d’une généralisation.''

'''Variables'''—Causal loop diagrams include ''variables'' (or stocks) such as the ''velocity (rate of delivery) of software features'' and ''number of defects'' . Variables have a measurable quantity.

'''Les variables''' - Les diagrammes de boucles causales comportent des ''variables'' (ou des stocks) telle que la ''vélocité (taux de livraison) des features'' et le ''nombre d’anomalies''. Les variables ont une quantité mesurable.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-4.png.pagespeed.ic.WpO9GKmuZP.webp|frame|none|alt=|caption systems thinking-4.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-4-fr.png|frame|none|alt=|caption systems thinking-4.png]]

'''Causal links'''—An element can have an effect on another, such as if feature velocity increases, then the number of defects increase; that is, more new code, more defects.

'''Les liens de causalité''' - Un élément peut avoir un effet sur un autre, comme par exemple si la vélocité des ''features'' augmente alors le nombre d’anomalies augmente ; autrement dit, plus de code, plus d’anomalies.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-5.png.pagespeed.ic.oPRro2SqND.webp|frame|none|alt=|caption systems thinking-5.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-4-fr.png|frame|none|alt=|caption systems thinking-5.png]]

Now it is time to bump into ''Weinberg-Brook’s Law'' and the ''Causation Fallacy'' . It is easy to sketch a diagram; it is something else to model with insight. For example, consider the relationship between the ''number of developers'' and ''feature velocity.''

Il est temps désormais de se jeter à corps perdu dans la ''loi de Weinberg-Brooks'' et dans la ''causalité fallacieuse''. C’est facile de dessiner un diagramme, ça l’est moins que de modéliser en faisant preuve de clairvoyance comme par exemple, la relation entre le ''nombre de développeurs'' et la ''vélocité des features''.

The nature of any cause-effect relationship is actually not obvious, though it is common for people to jump to conclusions such as more developers means better velocity. Adding people late in development may ''reduce'' velocity (a sub-element of “Brooks’ Law” [Brooks95]). Or, ''more'' bad programmers could really slow you down. An argument can be made that ''removing'' terrible developers can ''improve'' velocity.

Toute relation de cause à effets est par nature obscure, même si les gens ont l’habitude de sauter sur la première conclusion venue comme par exemple plus de développeurs égale plus de vélocité. Ajouter des personnes tard au cours du développement peut ''réduire'' la vélocité (il s’agit d’une composante de la « loi de Brooks » [Brooks95]). Ou, ''davantage'' de mauvais développeurs pourrait vraiment vous ralentir. Il pourrait être objecté qu’''enlever'' des développeurs exécrables peut permettre ''d’améliorer'' la vélocité.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-6.png.pagespeed.ic.6XIYl7Vm3_.webp|frame|none|alt=|caption systems thinking-6.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-6-fr.png|frame|none|alt=|caption systems thinking-6.png]]

'''Opposite effects'''—A causal link effect may be the same or opposite direction; if A goes up then B goes up, or vice versa. Opposite effect is shown with an ‘O’ on the line. Suppose defects going up puts a drag on the system, lowering the velocity of new features because people spend more time fixing or working around bugs.

'''Effets opposés''' - L’effet d’un lien de causalité peut aller dans la même direction ou dans la direction opposée. Si A monte alors B monte ou vice versa. L’effet opposé se souligne à l’aide d’un ‘0’ sur la ligne. Supposons que les anomalies ralentissent grandement le système, réduisant la vélocité des nouvelles ''features'' parce que les gens passent plus de temps à corriger ou à trouver des solutions de contournement aux anomalies.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-7.png.pagespeed.ic.DPGMJyX2Qf.webp|frame|none|alt=|caption systems thinking-7.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-7-fr.png|frame|none|alt=|caption systems thinking-7.png]]

'''Constraints'''—Unless you can find people to work for free, there is a constraint on the number of developers, based upon cash supply.

'''Contraintes''' - À moins que vous ne trouviez des personnes prêtent à travailler gratuitement, il y a une contrainte sur le nombre de développeurs basé sur le budget disponible.

Constraints are ''not'' causal links. As cash supply goes up, it is not the case that the number of developers goes up.

Les contraintes ne sont ''pas'' des liens de causalité. Lorsque la montant du budget disponible augmente, ce n’est pas le cas du nombre de développeurs/

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-8.png.pagespeed.ic.gbgAIK-IsZ.webp|frame|none|alt=|caption systems thinking-8.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-8-fr.png|frame|none|alt=|caption systems thinking-8.png]]

'''Goals and Reactions'''–People, departments, and systems have goals, such as ''higher feature velocity'' . Goals often generate pressure for people to react (or act), with the intent of achieving the goal. But since there is ''Causation Fallacy'' and ''Weinberg-Brooks’ Law'' to contend with, people should be cautious about assuming what actions will help. Now a goal and pressure for reaction is shown:

'''Buts et réactions''' - Les personnes, les départements et les systèmes ont des buts, comme par exemple avoir une ''vélocité des features plus élevée''. Les buts occasionnent souvent de la pression pour que les gens réagissent (ou agissent) dans l’intention de leur faire atteindre ce but. Mais étant donné qu’il y a la ''causalité fallacieuse'' et la ''loi de Weinberg-Brooks'' à laquelle il faut faire face, les gens devraient être prudents quant aux actions pertinentes à entreprendre. Voici un exemple de diagramme modélisant cela :

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-9.png.pagespeed.ic.yVcHbh4_-i.webp|frame|none|alt=|caption systems thinking-9.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-9-fr.png|frame|none|alt=|caption systems thinking-9.png]]

Not only does a goal with a ''reward'' create pressure to act, but also it creates pressure to ''appear'' to be acting and achieving, due to the '''measurement dysfunction''' generated by rewards. And the measurement dysfunction can be proportional to the perceived value of the reward because people are being motivated to get a reward, not to improve the system [http://www.amazon.com/Measuring-Managing-Performance-Organizations-Dorset-ebook/dp/B00DY3KQX6/ref=sr_1_1?ie=UTF8&qid=1413596674&sr=8-1&keywords=measuring+and+managing+performance+in+organizations [Austin96]]. Notice how rewards can actually degrade system performance. Visually, the system dynamics may be…

Non seulement un but à atteindre avec une ''récompense'' au bout engendre une pression à agir, mais cela créé aussi une pression à ''faire semblant'' d’agir et à atteindre le but — les récompenses provoquent un '''dysfonctionnement des indicateurs'''. Le dysfonctionnement des indicateurs peut être proportionnel à la valeur perçue de la récompense parce que les personnes sont motivées pour avoir la récompense, non pour améliorer le système [http://www.amazon.fr/Measuring-Managing-Performance-Organizations-Dorset-ebook/dp/B00DY3KQX6/ref=sr_1_1?ie=UTF8&qid=1413596674&sr=8-1&keywords=measuring+and+managing+performance+in+organizations [Austin96]]. Remarquez bien comment et de quelle manière les récompenses peuvent dégrader la performance du système. De manière visuelle, les dynamiques d’un tel système pourrait être …

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-10.png.pagespeed.ic.39CLFp-g_9.webp|frame|none|alt=|caption systems thinking-10.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-10-fr.png|frame|none|alt=|caption systems thinking-10.png]]

It is quite interesting that all these dynamics have been added by introduction of reward, and yet there is no necessary connection between the top part of this model and the bottom.

Il est assez intéressant de voir que toutes ces dynamiques ont été ajouté par l’introduction d’une récompense et qu’il n’y pas de connexion entre le haut et le bas de cette modélisation.

There is no guarantee that feature velocity has improved—or even been worked on.

Il n’y a aucune garantie que la vélocité des features s’améliore ou même que l’on y travaille.

Removing the reward system is a root-cause solution to the dysfunction. Another (lesser) surface countermeasure is the lean-thinking ''Go See'' (go see physically at the place of real work) principle and management behavior:

Enlever le système de récompense est une solution à la cause racine de ce dysfonctionnement. Une autre contremesure de surface est le principe et le comportement managériale ''Aller voir'' (aller voir physiquement sur le lieu où le travail s’effectue) de l’approche lean.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-11.png.pagespeed.ic.NU8SjnJkUY.webp|frame|none|alt=|caption systems thinking-11.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-11-fr.png|frame|none|alt=|caption systems thinking-11.png]]

'''Quick-fix reactions'''—One difficult and slow solution toward the goal of higher velocity is to hire great developers, to increase coaching and education of existing staff, and to remove terrible workers. The alternative is called a ''quick fix'' , a reaction that is hoped to achieve the goal quickly and with less effort. Sometimes a quick fix works well both in the short and long term, really strengthening the system. Sometimes not…hence, “faster is slower.” For example, people may ''believe'' that increasing the number of developers increases the feature velocity. And they may thereby hope that hiring more developers will most quickly and easily solve the velocity problem. ‘QF’ indicates the quick fix:

'''Solutions de contournement''' - Une solution payante à long terme pour atteindre une vélocité plus grande, qui n’est pas sans difficulté, consiste à : recruter de développeurs très qualifiés, faire davantage d’accompagnements et de formations, et à se séparer des moins bons éléments. L’alternative est ce que l’on appelle une ''solution de contournement'', c’est ce que l’on met en place dans l’espoir d’atteindre l’objectif en moins de temps et avec moins d’effort. Parfois, une solution de contournement se révèle payante aussi bien dans le court terme que dans le long terme, renforçant par la-même le système. D’autres fois cela ne fonctionne pas … d’où l’expression « aller plus vite c’est aller plus lentement ». Par exemple, les gens peuvent ''croire'' qu’augmenter le nombre de développeurs permet d’augmenter la vélocité des features. Et ils peuvent par conséquent être amenés à espérer qu’en recrutant davantage de développeurs cela permettra de résoudre plus vite et plus facilement le problème de vélocité. La mention ‘SC’ sur le diagramme ci-dessous indique une solution de contournement.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-12.png.pagespeed.ic.x8IJWKprUx.webp|frame|none|alt=|caption systems thinking-12.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-12-fr.png|frame|none|alt=|caption systems thinking-12.png]]

'''Interaction effects'''—There is the constraint of cash supply on hiring. One hard and slow solution is to get more cash. A quicker fix is to hire ''much'' cheaper developers. In this case, the level of cash supply now has an ''interaction effect'' with other causal links. Low cash tends to strengthen the hire rate of much cheaper developers when there is pressure to increase hire rates.

'''Effets d’interaction''' - La capacité à embaucher est contraint à la capacité budgétaire. Une solution de longue haleine non sans difficulté est d’obtenir davantage de budget. Une solution de contournement possible est de recruter un ''grand'' nombre de développeurs bon marché. Dans ce cas, le niveau du budget a un ''effet d’interaction'' avec les autres boucles causales. Un budget peu élevé aura tendance à renforcer le taux de développeurs bon marché si la pression pour recruter augmente.

One could simply draw an (opposite) causal link directly from ''cash supply'' to ''hire rate of very cheap developers'' , but that merely says that less cash leads to more hiring of extremely cheap developers. That is not quite what we want to say; rather, we want to show the interaction effect—that effect A influences ''effect'' B. This is done by showing a causal link entering another causal link. For example, from ''cash supply'' to the quick-fix line going into ''hire rate of very cheap developers'' :

Nous pourrions dessiner simplement un lien de causalité (opposé) de ''rentrée budgétaire'' à ''taux de recrutement de développeurs bon marché'', mais cela voudrait simplement dire qu’avoir un budget moindre aurait pour conséquence de recruter davantage de développeurs bon marché. Mais ce n’est pas tout à fait ce que nous voulons dire ; ce que voulons montrer en fait, c’est l’effet d’interaction - c’est-à-dire qu’un effet A influence un ''effet'' B. Cela se fait en montrant un lien de causalité heurtant un autre lien de causalité, par exemple en traçant une ligne de ''rentrée budgétaire'' vers la ligne représentant la solution de contournement qui va vers ''taux de recrutement de développeurs bon marché''.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-13.png.pagespeed.ic.LvAE8ewRFJ.webp|frame|none|alt=|caption systems thinking-13.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-13-fr.png|frame|none|alt=|caption systems thinking-13.png]]

'''Extreme effects'''—We have worked with some very inexpensive developers with excellent skill and some very expensive developers that are terrible, but on average, you get what you pay for—when you hire from a large pool of very cheap labor, the average skill level is lower. In the model we want to show that the impact of hiring very cheap labor on the ''number of low-skilled developers'' is a significantly greater effect than average.

'''Effets extrêmes''' - Il nous est arrivé de travailler avec d’excellents développeurs très bon marché et avec d’autres hors de prix très nuls, mais en moyenne, vous obtenez à hauteur de ce que vous payez - lorsque vous recrutez au moins disant, le niveau moyen en terme de compétences sera plus faible. Dans le diagramme ci-dessous, nous avons voulu montrer que l’impact du recrutement de personnes bon marché en rapport avec le ''nombre de développeurs peu qualifiés'' à un impact sensiblement plus grand que la moyenne.

To show an ''extreme effect'' in the model, use a thick line:

Pour montrer un ''effet extrême'' sur un modèle, faites un trait épais comme vous pouvez voir ci-dessous :

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-14.png.pagespeed.ic.JYkqz8Qe24.webp|frame|none|alt=|caption systems thinking-14.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-14-fr.png|frame|none|alt=|caption systems thinking-14.png]]

'''Delays'''—One problem in hiring in software development is the ''fallacy of mild programmer variance'' —the mistaken belief that programmer variance (in terms of productivity, code quality, etc.) is relatively small. However, programmer variance studies suggest an average of four times faster in the top versus bottom quartile [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.4788 [Prechelt00]]. Rather significant. Also, the COCOMO model—based on large and longitudinal studies—shows that the capability of the development personnel is by far the most important factor for productivity [http://www.amazon.com/Software-Cost-Estimation-Cocomo-II/dp/0130266922/ref=sr_1_1?ie=UTF8&qid=1413597244&sr=8-1&keywords=Software+Cost+Estimation+with+Cocomo+II [Boehm00]]. And, on average, very weak programmers create poor-quality code (poor design) and more defects, creating another drag on the system.

'''Retards''' Un problème courant au niveau du recrutement dans un projet de développement logiciel concerne ''l’erreur au niveau de la variance d’un développeur moyen'' - autrement dit la croyance fausse que la variance d’un développeur à un autre (en terme de productivité, de qualité de code, etc.) est relativement faible. Toutefois, les études de la variance au sujet des développeurs montrent un rapport de un à 4 entre le 1er quartile et le dernier [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.4788 [Prechelt00]]. C’est plutôt quelque chose de significatif. De même des études - en long et en large - du modèle COCOMO montrent que la capacité du développement personnel est le facteur de loin le plus important quant à la productivité [http://www.amazon.com/Software-Cost-Estimation-Cocomo-II/dp/0130266922/ref=sr_1_1?ie=UTF8&qid=1413597244&sr=8-1&keywords=Software+Cost+Estimation+with+Cocomo+II [Boehm00]]. Et, en moyenne, il s’avère que les développeurs peu qualifiés font du code de mauvaise qualité (mauvaise conception) et de plus d’anomalies, ceci rajoute un autre frein au système.

But the impacts of these effects are not immediately obvious. For example, it takes a relatively long time after hiring a large pool of weak programmers before the impacts of more and more bad code/design start to be felt. Similarly, the average ''decrease'' in feature velocity (because of the powerful impact of programmer variance) will not show up immediately.

Mais l’impact de ces effets ne sont pas visibles immédiatement. Par exemple, cela peut prendre un certain temps après un recrutement massif de développeurs peu qualifiés avant que les impacts négatifs ne se fassent sentir au niveau de la qualité du code ou de la conception. De manière similaire, la ''baisse'' moyenne de la vélocité des features (en raison de l’impact important de la variance des développeurs évoqué plus haut) ne se verra pas immédiatement.

To show these ''delayed effects'' in the model, use a double-line through the effect line:

Pour montrer ces ''effets à retardement'' dans le modèle, faites une double-ligne en travers de la ligne d’effet.

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-15.png.pagespeed.ic.0fwliLJm6G.webp|frame|none|alt=|caption systems thinking-15.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-15-fr.png|frame|none|alt=|caption systems thinking-15.png]]

Delay has an intriguing influence on the ''educational'' or corrective power in a system. If an impact or unintended consequence is long delayed, one does not feel the effect (pain or gain) and so does not clearly see how A influenced B, or more subtly how ''A influenced B influenced A'' .

Le retard a une influence intéressante sur le pouvoir ''pédagogique'' ou correctif sur un système. Si un impact ou une conséquence inattendue est retardé suffisamment longtemps, personne n’en voit ni l’effet (qu’il soit bénéfique ou néfaste) ni sur la façon dont A influence B ou plus subtilement comment ''A a influencé B qui a influencé A''.

Therefore, one does not learn from or correct mistakes—in policy, management actions, tools, and so forth. Likewise, gradual improvement through the lean thinking practice of ''kaizen'' can take a long time; patience and insight are needed to see if and how things improve.

Par conséquent, personne n’apprend de ses erreurs ni n’est en capacité de les corriger - que ce soit en terme de stratégie, d’actions d’encadrement, d’outils ou de quoi que ce soit. De la même manière, l’amélioration graduelle à travers l’application d’une démarche lean ''kaizen'', peut prendre un certain temps ; de la patience et de la perspicacité sont nécessaires pour voir si et comment les choses s’améliorent.

'''Positive feedback loops'''—Negative or positive feedback loops[https://less.works/less/principles/systems-thinking.html#footnote-5 5] and delays are where things start to get more subtle in a system—and in understanding a system. For example, how does one become a better programmer? In part, by mentoring from great programmers and seeing lots of examples of great code. But an office with a lot of low-skill developers does not generate a lot of great code examples, nor does it attract or retain the small pool of great programmers who could act as mentors. They would rather work somewhere else.

'''Boucles de feedback positives''' - Les boucles de feedback négatives ou positives [^5] et les retards sont le point de départ pour une approche plus subtile d’un système - et de sa compréhension. Par exemple, de quelle manière une personne peut-elle devenir un meilleur développeur ? En partie, en bénéficiant du mentorat de très bons développeurs et en jetant un œil sur du très bon code. Mais il est impossible de trouver du bon code dans un endroit remplit de développeurs médiocres, il est impossible également d’y attirer ou de retenir le petit groupe de très bon développeurs qui pourraient prendre le rôle de mentors. Ils préfèrent largement aller travailler ailleurs.

Now the development group starts to enter a self-reinforcing downward spiral—a set of ''positive feedback loops'' . Fortunately, the downward trend is constrained by the supply of cash.

Ce groupe de développeurs médiocres rentrent dans un cercle vicieux en raison d’un ensemble de ''boucles de feedback positives''. Fort heureusement, ce cercle vicieux est assujeti aux contraintes du budget.

More great programmers—who could craft great code and mentor others—leave. So there is less and less quality code to look at and to learn from. The percentage of weak programmers grows even larger and feature velocity drops further. Code becomes more messy, awkward, and duplication-riddled, so the capacity to swiftly implement features declines. Since feature velocity is dropping further, there is more pressure to hire yet more very cheap programmers. All this leads to multiple positive reinforcement loops in the system, for example:

Malheureusement de plus en plus des très bons développeurs - ceux en capacité d’élaborer du très bon code et de faire du mentorat auprès des autres développeurs - partent. Par conséquent, il y a de moins en moins de code de qualité à regarder et à partir duquel il est possible d’en tirer des enseignements. Le pourcentage de développeurs médiocres augmente de plus en plus et la vélocité au niveau des features continue à chuter. Le code devient de plus en plus brouillon, difficile, avec pleins de bouts de code dupliqués à gauche et à droite, le tout de telle manière que la capacité d’implémenter des features décline. Étant donné que la vélocité des features continue de chuter, il y a davantage de pression pour recruter des développeurs très bon marché. Tout cela conduit à de multiples boucles de renforcement positives dans le système comme l’illustre l’exemple ci-dessous :

[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-16.png.pagespeed.ic.ONFuUmJHSE.webp|frame|none|alt=|caption systems thinking-16.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-16-fr.png|frame|none|alt=|caption systems thinking-16.png]]

''Tip'' : You can find positive feedback loops by finding cycles with an ''even number'' of ‘Opposite’ effect relationships. There are several examples in the model above.

''Astuce'' : Vous pouvez trouver des boucles de feedback positives en cherchant des cycles ayant un ''nombre pair'' de relations. Vous en trouverez plusieurs exemples ci-dessus.

===== Conclusion =====

===== Conclusion =====

The example scenario is only that—an example. A causal loop diagram can visualize rich dynamics in a workplace system. These are best created by a group at a whiteboard.

Le scénario donné à titre d’exemple est uniquement cela - un exemple. Une diagramme de boucle causale permet de visualiser la richesse de la dynamique dans le système dans un milieu professionnel. La meilleure manière de modéliser un tel système est de le faire en groupe face à un tableau blanc.

== Seeing Mental Models ==

== Voir les modèles mentaux ==

The previous causal loop diagrams reflect people’s mental models of causation, which may be wrong. It is interesting to note that people’s models of causation are influenced by the timeliness (delay) and quality of feedback in the system.

Les précédents diagrammes de boucles causales reflètent les modèles mentaux de causalité des individus … qui peuvent s’avérer faux. Il est intéressant de remarquer que les modèles de causalité des individus sont influencés par la ponctualité (ou les retards) et la qualité des feedbacks dans le système.

The implication of “mental models” is to improve our meta-cognitive skill to see and question our own assumptions and chains of reasoning. Are we making faulty leaps of logic? It also implies when working with others to discuss (inquiring rather than abusing) the mental models of our colleagues.

Les « modèles mentaux » nous permettent d’améliorer nos compétences de méta-cognition pour voir et questionner nos propres postulats et l’enchaînement de nos raisonnements. Brûlons-nous des étapes de manière erronée ? Cette question implique aussi lorsque nous sommes en train de travailler avec des collègues de discuter avec eux (en s’enquérant plutôt qu’en reprochant) de leurs modèles mentaux.

''Seeing'' these mental models is step one; ''changing'' them is the even harder part of step two. That art is beyond the scope of this introduction, though a successful LeSS adoption must involve changes in mindset and insight among many groups.

''Voir'' les modèles mentaux n’est que la première étape ; les ''changer'' constitue une seconde partie bien plus difficile. Cet art est bien au-delà du sujet de cette introduction, même si une adoption réussie de LeSS implique des changements en terme d’état d’esprit et de prise de conscience au sein de très nombreuses équipes.

A tip to better ''see'' the mental models (beliefs, chains of inference, …) playing out in the system dynamics is to ask the following question during a modeling workshop and then sketch the answers. “Let’s talk about the assumptions behind this model. What do we ''believe'' or assume in terms of facts and effects that led us here?”

Une astuce pour mieux ''voir'' les modèles mentaux (croyances, échelle d’inférence, …) en jeu au niveau des dynamiques des systèmes est de poser les questions suivantes lors d’un atelier de modélisation puis de tracer les éléments de réponse au tableau blanc. « Parlons donc des hypothèses derrière ce modèle. Que ''croyons''-nous ou tenons pour acquis en terme de faits et d’effets qui nous ont conduits ici ? »

Answers are sketched on the whiteboard model, for example:

Les éléments de réponse sont dessinés sur le tableau blanc. En voici un exemple :

<figure>
[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-17.png.pagespeed.ic.5UIqBnJfK1.webp|frame|none|alt=|caption systems thinking-17.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-17-fr.png|frame|none|alt=|caption systems thinking-17.png]]

<figcaption>
Visualizing the assumptions in our heads… our mental models.
</figcaption>
</figure>
Visualiser les postulats présents dans nos têtes … nos modèles mentaux.

=== Example: The “Faster is Slower” Dynamic ===

=== Exemple : La dynamique « Aller plus vite c’est aller plus lentement » ===

With the vocabulary of quick fixes, delays, positive feedback loops, and mental models, it is fascinating to see that there can be a short-term apparent improvement in a variable as the result of a quick fix, but a ''delayed degradation'' of the very same variable—the “faster is slower” dynamic. This is a recurrent dynamic in the workplace and a cause of weakness. So it is worth another illustration.

Dorénavant, avec notre vocabulaire enrichi des termes de solutions de contournement, de boucles de feedback positives et de modèles mentaux, il est fascinant de voir qu’il peut y avoir un semblant d’amélioration à court terme sur une variable donnée, mais que cela entraîne en même temps une ''dégradation à retardement'' de cette même variable - d’où la dynamique « Aller plus vite c’est aller plus lentement ». Il s’agit d’une dynamique récurrente et d’une cause de vulnérabilité à terme. Voici un nouvel exemple illustrant cela :

''The story of Microsoft Word and the'' '''''secret developer toolbox''''' : A classic example of the short-term ‘improving’ but long-term degrading dynamic is the story of the first release of Microsoft Word for Windows [http://www.amazon.com/Joel-Software-Occasionally-Developers-Designers/dp/1590593898/ref=sr_1_1?ie=UTF8&qid=1413597951&sr=8-1&keywords=Joel+on+Software [Spolsky04]]. It was released ''years'' later than desired. Why? ''Because managers tried to follow the original schedule and pushed developers to meet it'' .

''Histoire de Microsoft Word et de'' '''''la boîte à outils secrète du développeur''''' : Un exemple typique d’une ‘amélioration’ à court terme mais d’une dynamique de dégradation à long terme est le récit de la première livraison de Microsoft Word sur Windows [http://www.amazon.com/Joel-Software-Occasionally-Developers-Designers/dp/1590593898/ref=sr_1_1?ie=UTF8&qid=1413597951&sr=8-1&keywords=Joel+on+Software [Spolsky04]]. Le logiciel a été livré avec des ''années'' de retard par rapport à la date prévue. Pourquoi ? ''Parce que les managers ont essayé à tout prix de suivre le calendrier de départ et ont fait pression sur les développeurs pour le respecter''.

The story illustrates why ''wishful thinking'' is identified as one of the wastes in lean thinking. In this case the wishful thinking of insisting on (apparently) following a schedule, which implies the misconception or wishful thinking that development estimates are not estimates but are commitments—a common myth that propels degradation of a system.

Cette histoire illustre pourquoi cet espoir illusoire de respecter une date souhaitée est bien identifié comme une source de gâchis dans l’approche lean. Dans le cas présent l’espoir illusoire consiste à insister (du moins apparemment) à suivre le calendrier, ce qui implique une idée fausse ou illusoire que les estimations ne sont pas de simples estimations mais des promesses - un mythe classique qui pousse à la dégradation d’un système.

[https://less.works/less/principles/systems-thinking.html#figure-1 The next model] illustrates a ''summary'' of the dynamics of what happened when the managers pushed people to evidently keep to the original schedule, and why this quick-fix reaction to slow progress appeared to make things faster in the short term but actually even ''slower'' in the long term. See the dynamic of schedule pressure and the secret toolbox. intentionally omits some deeper dynamics that are expanded and shown in See deeper dynamics of schedule pressure and the secret toolbox..

[https://less.works/less/principles/systems-thinking.html#figure-1 Le modèle suivant] illustre un ''résumé'' des dynamiques à l’œuvre lorsque des managers poussent leurs équipes à respecter à tout prix les calendriers prévisionnels, et pourquoi cette solution de contournement qui freine pourtant l’avancement des travaux semblent les faire aller plus vite à court terme mais en réalité ''plus lentement'' à long terme. Par rapport à ce qui est décrit précédemment dans la dynamique de la pression du calendrier et la boîte à outils secrète, certaines dynamiques ont été omises intentionnellement sur ce schéma et sont visibles sur le schéma dynamiques avancées.

<figure>
[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-18.png.pagespeed.ic.A7OSuu755I.webp|frame|none|alt=|caption systems thinking-18.png]]

[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-18-fr.png|frame|none|alt=|caption systems thinking-18.png]]

<figcaption>
The dynamic of schedule pressure and the secret toolbox.
</figcaption>
</figure>
Dynamique de la pression sur le calendrier et de la boîte à outils secrète.

As a quick fix, the Microsoft managers exhorted, bribed (with potential rewards), and threatened the Word developers to keep to the original schedule. Consequently, the developers predictably pulled out their '''secret developer toolbox''' —the many practices related to hacking out dirty code (no tests, no reviews, ignore known defects, copy-paste programming, poor design, …) to apparently deliver a feature faster. You see, developers also have ''quick-fix'' reactions for their problems.

En solution de contournement, les managers de Microsoft ont exhorté, ont corrompu (à l’aide de primes potentielles), et ont menacé les développeurs de Word pour leur faire respecter le calendrier prévisionnel. En conséquence, les développeurs ont, de manière tout à fait prévisible, sorti leur '''boîte à outils secrète de développeurs''' - autrement dit tout un arsenal de pratiques pour pisser du code pourri (aucuns tests, aucunes revues, ignorance des anomalies connues, développement par copier-coller, mauvaise conception, …) pour développer visiblement plus vite. Vous voyez bien, les développeurs ont aussi des solutions de contournement pour régler leurs problèmes.

The tactics seemed to have worked like magic. As the managers pressured the developers, ‘features’ were delivered quicker as people used the secret toolbox, which reinforced the belief that pressuring developers helps. But this apparent acceleration actually had a delayed effect to make things slower, which is explored next. Since management did not quickly see the delayed effect of the secret toolbox, and because they believed managers should not be frequently looking in detail at the source code or themselves be master programmers, they did not learn from this dynamic.

Vu de l’extérieur, ces tactiques ont fonctionné à merveille. Au fur et à mesure que les managers mettaient la pression sur les développeurs, les ‘features’ étaient développées de plus en plus vite grâce à l’utilisation de la boîte à outils secrète, ce qui a renforcé la croyance en quoi mettre la pression sur les développeurs était quelque chose d’utile. Mais cette apparente accélération a eu en fait un effet à retardement qui a rendu les choses plus lentes (c’est ce que nous allons voir par la suite). Étant donné que le management n’a pas été assez rapide à voir l’effet à retardement de la boîte à outils, et parce que les managers pensent qu’ils n’ont pas besoin d’aller regarder fréquemment en détails le code source ou qu’ils n’ont pas besoin d’être eux-mêmes des développeurs très expérimentés, ils n’ont rien appris de cette dynamique.

A closer exploration of the system dynamics shows why things went slower in the long term and why the first Word for Windows release was years later than desired, illustrated in this model…

Le schéma ci-dessous illustre l’examen approfondie des dynamiques des systèmes montrant pourquoi les choses sont allées plus lentement à long terme et pourquoi le tout premier Word pour Windows a été livré des années en retard par rapport à la date souhaitée …

<figure>
[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-19.png.pagespeed.ic.D24dvGHzfu.webp|systems thinking-19.png]]
</figure>
[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-19-fr.png|frame|none|alt=|caption systems thinking-19.png]]

<figcaption>
Some deeper dynamics of schedule pressure and the secret toolbox.
</figcaption>
Dynamiques avancées de la pression sur le calendrier et de la boîte à outils secrètes.

Naturally, lots of dirty code eventually slowed things down. More subtly, developers would ''ignore'' the bug list of ever-increasing open defects to—instead—generate new features. This led to a long delay between the creation of a defect and its correction. It turns out that this significantly increases variability and time to fix a defect because of the compounding negative effect of a long-lived bug (for example, due to workarounds and coupling) and because developers have long forgotten the detailed context of code related to the defect and therefore need to slowly rediscover that context—with more and more dirty confusing code surrounding them.

Naturellement, avoir une grande quantité de code de mauvaise qualité ralentie les choses. De manière beaucoup plus subtile, les développeurs ont ''ignoré'' la liste croissante d’anomalies pour privilégier la production de nouvelles features. Cela a eu pour conséquence d’avoir un délai important entre la déclaration d’une anomalie et sa correction. Il s’avère que cela a fait augmenter de manière significative la variabilité et le temps nécessaire pour corriger une anomalie en raison des effets cumulatifs négatifs liée à la nature même d’une vieille anomalie (par exemple avec la mise en place des solutions de contournement et des couplages existants entre les fonctionnalités), de l’oubli du contexte détaillé par les développeurs en relation avec l’anomalie, ces derniers mettant par conséquent plus de temps à le redécouvrir, de l’accumulation continue de code de mauvaise qualité dans le même temps.

The astute reader may also notice the several positive feedback loops that reinforce the degradation cycle; this is one reason the product was years later than intended.

Le lecteur avisé remarquera également plusieurs boucles causales positives renforçant le cycle de dégradation ; il s’agit de l’une des raisons expliquant le retard pris sur plusieurs années pour livrer le produit.

Solution? The lean thinking ''Stop and Fix'' and ''Go See'' principles. ''First'' , rather than trying to go faster when there are problems, manager-teachers encourage people to go ''slower'' and help them learn to see system dynamics and root causes, and to fix these—to improve the ''system'' of development. By going slower, Toyota—the masters of lean thinking—has become one of the fastest companies around. ''Second'' , for managers to ''go see at the real place of work'' to learn what is going on. The “real place” in software development is the code, which suggests that first-level managers are master programmers who are frequently evaluating the code.

Une solution ? L’approche lean avec les principes ''Arrêter et corriger'' et ''Aller voir''. ''Premièrement'', plutôt que d’essayer d’aller plus vite lorsqu’il y a des problèmes, des managers-formateurs encouragent les gens à aller plus ''lentement'' et à les inciter à apprendre les dynamiques des systèmes, les causes racines et à les corriger pour améliorer le ''système'' du développement. En allant plus lentement, Toyota - les maîtres de l’approche lean - est devenue l’une des entreprises les rapides du monde. _Deuxièmement, les managers doivent ''aller voir ce qui se passe sur le vrai lieu de travail'' pour apprendre ce qu’il se passe. Le « vrai lieu » dans le développement logiciel c’est le code, ce qui implique que les managers de proximité sont des développeurs expérimentés qui évalueront le code fréquemment.

Microsoft people did not reflect on the situation until after release. When they did finally hold a retrospective, it led to a ''zero-defects'' policy, meaning that the first priority was to fix known bugs in the code under development—to drive down to zero the open-defects list before writing more new-feature code.

Les personnes de chez Microsoft n’ont pas réfléchi sur la situation que bien après la livraison. Lorsqu’ils ont fini par faire une rétrospective, cela a amené à une politique du ''zéro défaut'', cela signifie que la première priorité était de corriger les anomalies connues dans le code en cours de développement afin d’aller vers du zéro anomalie ouverte dans la liste des anomalies avant d’écrire du code pour une nouvelle feature.

== Seeing (and Hearing) Local Optimization ==

== Voir (et entendre) l’optimisation locale ==

“Everyone is doing their best yet overall systems throughput is degrading. How can that be?” This is the paradox of '''local optimization''' —when a person or departmental decision maker optimizes for the local view or self-interest. The party making the decision frequently ''believes they are making the best decision'' , but because ‘best’ is a local optimization, in fact it sub-optimizes overall system throughput. This is a result of “silo mentality,” misunderstanding, fear, limited information, delayed feedback, ignorance, careerism, avarice, and other common ''organizational learning disorders'' .

« Chacun fait de son mieux, mais malgré tout le flux de production du système se dégrade. Comment cela est-il possible ? ». Il s’agit du paradoxe de '''l’optimisation locale''' - autrement dit c’est lorsqu’une personne à titre individuel ou un responsable de département prend une décision d’un point de vue local ou dans son propre intérêt. Les personnes prenant ce type de décision ''croient fréquemment qu’ils prennent la meilleure décision'', mais parce que ‘meilleure’ est ici synonyme d’optimisation locale, cela a pour résultat une sous-optimisation globale du flux du système. Ceci est le résultat d’une « mentalité de silo », d’incompréhension, de peur, de restrictions d’informations, de feedbacks à retardement, d’ignorance, de carriérisme, d’avarice et de bien d’autres ''dysfonctionnements d’apprentissages organisationnels''.

A small product group of 30 people does not have the time or money to engage in much nonsense or waste. But large companies, with large product groups, centralized process and tool groups, a centralized “project management office,” and so forth, seem to have raised local optimization and waste to an art form. Government bureaucracies are the quintessential example, of course. As such, when you serve as a guide in large-scale agile adoption, ''seeing'' (or ''hearing'' ) and dealing with local optimization is singularly vital.

Une petite équipe produit de 30 personnes n’a ni temps ni l’argent pour s’engager dans ce genre de non-sens ou de gâchis. Mais les grandes entreprises avec de grands groupes produit, des processus centralisés et des groupes outils, un « bureau de gestion de projet » centralisé, et ainsi de suite, semblent avoir élevé l’optimisation locale et le gâchis à une forme d’art. Les bureaucraties gouvernementales en sont bien sûr la quintessence. En conséquence, lorsque vous servez de guide dans une adoption agile à grande échelle, ''voir'' (ou ''entendre'') et s’occuper de l’optimisation locale est tout simplement quelque chose de vital.

For example, the legal and corporate security departments put in place a policy that seems terribly important from their perspective. In the aim of preventing loss of intellectual property (IP), the legal department decrees “no one shall put any information on the walls.” Or, in response to cost-cutting pressure, the facilities management says, “It is important to ensure our walls are not dirty or damaged.” And thus they shut down a practice in lean thinking, visual management (which is usually done on walls), and they inhibit a well-known innovation practice, group whiteboard work. The lawyers may succeed in reducing loss of IP (actually, that is questionable), and the facilities people will succeed in keeping the walls clean—at the cost of inhibiting the product development group from innovating and collaborating. Finally, the company falls behind with less and less IP even worth protecting because tools for innovation and delivering fast have been disallowed, but the lawyers have successfully fulfilled their mandate from the executive team to “ensure our IP is protected.” And the ''furniture police'' have clear walls. ''They have done their best'' .

Par exemple, les départements juridiques et sécurité mettent en place des politiques qui leurs semblent très importantes de leurs points de vue. Dans l’objectif de prévenir la perte de propriété intellectuelle, le département juridique peut décréter « il est interdit d’afficher tout type d’information sur les murs. ». Or, le département des immeubles soumis de son côté, à une pression de politique de réductions de coûts peut surenchérir en disant : « Il est important de s’assurer que nos murs ne soient ni sales ni abîmés ». Et ainsi s’arrête le management visuel qui est l’une des pratiques de l’approche lean (le management visuel se faisant habituellement sur les murs), et ils inhibent également une pratique d’innovation bien connue à savoir le travail de groupe devant un tableau blanc. Les juristes réussiront peut être à réduire la perte de propriété intellectuelle (ce qui en réalité devrait poser question), et les gens des immeubles réussiront à garder leurs murs propres - mais au prix d’inhiber le groupe de développement produit dans sa capacité d’innover et de collaborer. Finalement, l’entreprise se laissera distancer par la concurrence avec de moins en moins de propriété intellectuelle valant la peine d’être défendue parce que les outils permettant l’innovation et de livrer rapidement ont été bannis, mais les juristes auront rempli leur mandat vis-à-vis de la direction de « s’assurer que la propriété intellectuelle est protégée ». Et la police de la logistique aura nettoyé les murs. ''Ils ont fait de leur mieux''.

The following is a real e-mail quote from the ''FURNITURE POLICE'' in one organization that dissallowed visual management on the walls. Can you identify the local optimizations and mental models driving this?

Ce qui suit est extrait d’un vrai message électronique de la ''POLICE DE LA LOGISTIQUE'' dans une organisation qui a banni le management visuel sur les murs. Pouvez-vous identifier les optimisations locales et les modèles mentaux qui sont derrière tout ça ?

<blockquote>''Individual work cubic partition can be personalized. But things obvious higher than the partition or harming the office environment’s harmony are restricted.''
</blockquote>
<blockquote>_Les [https://fr.wikipedia.org/wiki/Bureau_%C3%A0_cloisons bureaux à cloisons] peuvent être personnalisés. Mais tout ce qui visible au-dessus de la cloison ou qui perturbe l’harmonie de l’environnement de bureau est interdite.
</blockquote>
We also see local optimization in centralized groups that make software tool choices for others. The common mindset is to choose a tool that is best at reducing some supposed cost (curiously, these groups seldom recommend free open source tools) or best at doing something complicated or best for the work of one specialized worker role (even though ''everybody'' has to use the tool), rather than maximizing the global goal of faster system throughput of value to customers.

Nous constatons aussi des optimisations locales dans les groupes centralisés dont le rôle est de choisir les logiciels pour les autres personnes de l’entreprise. La croyance la plus répandue que cette démarche est qu’il s’agit de ce qu’il y a de mieux pour réduire les coûts d’achats (curieusement ces mêmes groupes recommandent rarement les logiciels libres gratuits) ou ce qu’il y a de mieux pour accomplir une tâche compliquée ou ce qu’il y a de mieux pour l’accomplissement du travail d’un seul type de travailleur (même si ''tout le monde'' est censé devoir utiliser l’outil), plutôt que de maximiser l’objectif de l’entreprise qui est d’avoir un système de flux de production de la valeur plus rapide pour les clients.

In large-scale adoption of Scrum or agile principles, most of the “Yes, but …” issues that are raised are examples of local optimization, such as, “''Yes, but…what about management reporting''?” or more generally, “''Yes, but…what about <special case="">''?” Then, policies and practices are twisted around, serving the goal of reporting or some other secondary aim rather than the primary goal of optimizing for fast value throughput. Sometimes we see ''local optimization for the extreme or rare case'' . For example, a person responsible for making a centralized tool choice for the enterprise presents a scenario for a complex or rare case of use, and then chooses the tool that fits that, sub-optimizing for a 5 percent case instead of optimizing for ease and speed for the 95 percent case.</special>

Dans les adoptions de Scrum ou des principes agiles à grande échelle, la plupart des problématiques de type « Oui, mais … » qui sont soulevées sont des exemples de sous-optimisations, comme par exemple « ''Oui, mais … qu’en est-il des comptes-rendus auprès du management'' ? » ou encore de manière plus générale « * Oui, mais … qu’en est-il de … * ? ». Alors, les principes et les pratiques sont dévoyés, pour servir soit l’objectif de rendre compte soit n’importe quel autre objectif secondaire plutôt que suivre l’objectif d’optimiser le flux de valeur produite. De temps en temps, nous voyons des '''optimisations locales dans certains cas rares ou extrêmes'''. Par exemple, une entreprise doit choisir un outil centralisé répondant à un certain nombre de cas d’utilisations possibles dont un cas extrêmement rare ou complexe, la personne, en charge de faire ce choix, choisit un outil correspondant à un cas unique d’utilisation, sous-optimisant ainsi l’ensemble du système pour un cas représentant uniquement 5% des cas d’utilisation au lieu de l’optimiser pour la majorité des 95% des autres cas d’utilisations.

Other local optimizations are due to ignorance of new ways of working. This is especially common in large-scale product groups. For example, we once helped a large networking product group in Europe adopt Scrum and the practice of ''continuous integration'' (CI) combined with a CI system that continually integrated, built, and automatically tested the product. After some time, an outside traditional manager inspected what was going on, and recommended the integration practices should be changed—because there was no written integration plan for how a human integration manager should manually integrate all the software, and of course, there was no integration manager. They wanted to ‘optimize’ around the work of an integration manager that was no longer needed. They could not see that their entire old-fashioned model of work had been eliminated with CI. This story repeats in all the departments of a large established product: local optimization around the ''existing'' ways of work, such as manual test, a separate architecture department, component teams, and so on. A coach working to introduce large-scale Scrum at the enterprise level has a ''mountain'' of similar local optimization thinking to deal with.

D’autres optimisations locales sont dues, quant à elles, à l’ignorance des nouvelles manières de travailler. C’est quelque chose de très répandue et tout spécialement dans les groupes produit à grande échelle. Par exemple, un jour nous avons aidé un groupe produit distribué à travers l’Europe à adopter d’une part Scrum et d’autre part la pratique de ''l’intégration continue'' (CI) le tout sous la forme d’un système d’intégration continue dédié intégrant, compilant, testant automatiquement de manière continue le produit. Après quelques temps, un manager, que l’on pourrait qualifier de traditionnel, extérieur au groupe est venu inspecter ce qu’il se passait. Celui-ci a recommandé que les pratiques d’intégration devraient être changées en raison de l’absence de schéma d’intégration global permettant à un responsable d’intégration de faire manuellement l’intégration de l’ensemble du logiciel ; une absence de schéma pour la bonne raison qu’il n’y avait plus besoin de responsable d’intégration au sein de l’organisation. Il voulait ‘optimiser’ le travail d’un responsable d’intégration qui n’existait plus. Il était dans l’impossibilité de voir que la totalité de l’ancienne manière de faire les choses avait disparu avec l’intégration continue. Cette histoire se répéta dans l’ensemble des départements du groupe produit : il y a avait des optimisations locales partout autour des façons de faire existantes, tels que les tests manuels, le département d’architecture séparé des équipes, les équipes composants, etc. N’importe quel coach dont la tâche consistait à introduire Scrum à grande échelle au niveau de l’organisation avait une ''montagne'' d’optimisations locales à penser à gérer.

In lean thinking and agile methods, the focus is on global systems goals: Deliver value fast with high quality and morale—'''global optimization''' . Try to consider decisions in light of this goal. To develop an “optimize the whole” culture, challenge all decisions and policies with the question:

Dans l’approche lean et dans les méthodes agiles, l’accent est mis sur les objectifs du système dans sa globalité : livrer de la valeur de grande qualité au plus vite tout en gardant le moral des équipes au plus haut - autrement dit une '''optimisation globale'''. Essayer de reconsidérer vos décisions à la lumière de cet objectif. Pour développer une culture de « l’optimisation du tout », remettez donc en cause toutes les décisions et les règles avec la question suivante :

<blockquote>'''Does this decision or policy focus on delivering value to the external customer fast, or does it focus on the interests of a department, person, internal policy/practice, or rare case?'''
</blockquote>
<blockquote>** Est-ce que cette décision ou cette règle se focalise-t-elle sur livrer de la valeur au client externe au plus vite, ou se focalise-t-elle sur les intérêts d’un département, d’une personne, d’une pratique/règle interne, ou d’un cas rarissime ?**
</blockquote>
In LeSS, the Product Owner is responsible for choosing high-value goals that '''could lead to potentially shippable product (at the end of the Sprint) and that maximize the desired impacts and that delight the customer, while maintaining a sustainable pace and high engineering quality'''. That explicit goal is meant to orient the system toward global rather than local optimization.

Dans LeSS, le Product Owner est responsable pour choisir ces objectifs à haute valeur qui '''pourrait mener à un produit potentiellement livrable (à la fin du Sprint) maximisant les impacts souhaités et réjouissant le client tout en maintenant un rythme soutenable et une haute qualité d’ingénierie'''. Cet objectif explicite est destiné à orienter le système vers son optimisation globale plutôt que vers une optimisation qui ne serait que locale.

== Conclusion ==

== Conclusion ==

In addition to becoming a systems thinker yourself, encourage others to learn more about this topic. We suggest you to try getting together at a whiteboard with colleagues to sketch a causal loop diagram, so that ''being'' systems thinkers and ''doing'' systems thinking are connected at the workplace.

En plus de devenir un pratiquant de l’approche systémique vous-même, encouragez donc les autres à en apprendre plus sur ce sujet. Nous vous suggérons d’essayer de rassembler quelques-uns de vos collègues autour d’un tableau blanc et d’y dessiner des diagrammes de boucles causales, afin que les architectes des systèmes et les pratiquants de l’approche systémique soient réunis en un seul endroit.

<figure>
[[File:https://less.works/img/systems-thinking/xgroup,P20cld,P20modeling.jpg.pagespeed.ic.lirKMzwWbD.webp|group%20cld%20modeling.jpg]]
</figure>
[[File:%7B%7B%20site.url%20%7D%7Dassets/less/xsystems-thinking-20-fr.png|frame|none|alt=|caption systems thinking-20.png]]

<figcaption>
Doing system thinking. Sketching a causal loop diagram together—modeling to have a conversation.
</figcaption>
Séance d’approche systémique. Réalisation d’un diagramme de boucle cause à plusieurs mains dans l’objectif d’avoir une conversation.

== Recommended Readings ==

== Lectures recommandées ==

* W. Edwards Deming’s [http://www.amazon.com/Out-Crisis-W-Edwards-Deming-ebook/dp/B00653KTES/ref=sr_1_1?ie=UTF8&qid=1413601625&sr=8-1&keywords=out+of+the+crisis ''Out of the Crisis''] is a master work by arguably the most well-known systems thinker and quality expert. It opens with the modest goal, “The aim of this book is transformation of the style of American management… It requires a whole new structure, from foundation upward.” Deming also advocates the ''System of Profound Knowledge'' in which managers (1) appreciate there is a ''system'' , (2) understand common-cause and special-cause variation (queueing theory is related to variation), (3) understand limitations of knowledge and reasoning mistakes, and (4) know credible psychology and social research results so that behavior- or motivation-related policies are ''not'' based on “common sense.” The core of the book centers around his famous ''14 Points for Management'' , including (for example), “''Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership'' .”
* [https://www.amazon.fr/Hors-crise-W-Edwards-Deming/dp/2717843930/ ''Hors de la Crise''] de W. Edwards Deming est un ouvrage de référence par, sans conteste, le plus connu des penseurs systémiques et des experts sur la qualité. Cet ouvrage commence par un objectif modeste : « l’objectif de ce livre est la transformation du style du management américain … ce qui exige une toute nouvelle structure de fonds en combles. ». Deming prône un ''Système de connaissances approfondies'' dans lequel les managers (1) reconnaissent qu’il y a un ''système'', (2) qu’ils sont en mesure de comprendre les facteurs les plus répandus et les facteurs spéciaux de variations au sein du système (la théorie des files d’attente est liée à ce phénomène de variation), (3) qu’ils sont en mesure de comprendre que les connaissances sont limitées et qu’il y a des erreurs de raisonnements, et (4) que la psychologie et les recherches en sciences sociales jouent des rôles tout à fait crédibles dans l’objectif de comprendre que les règles régissants les comportements ou en lien avec la motivation des individus ne soient pas basés sur le seul « bon sens ». Le cœur de l’ouvrage tourne autour des célèbres ''14 points pour le management'', y compris par exemple « ''Éliminer le management par les objectifs. Éliminer le management par les nombres, par les objectifs par les nombres. Y substituer le leadership''»
* Jay Forrester’s [http://www.amazon.com/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ref=sr_1_1?ie=UTF8&qid=1413601681&sr=8-1&keywords=industrial+dynamics ''Industrial Dynamics''] is the classic text on system dynamics—well written and insightful. Although written in the early 1960s, it is as relevant today as when published. It goes beyond cause-effect modeling to also model the flow and inventories of information, money, and material in systems. The book includes formal mathematical modeling but this is not obligatory to appreciate system dynamics.
* [https://www.amazon.fr/Industrial-Dynamics-Jay-Wright-Forrester/dp/1614275335/ ''Industrial Dynamics''] de Jay Forrester est un classique du genre sur les dynamiques des systèmes - très bien écrit et très instructif. Même si cet ouvrage a été écrit au début des années 1960, il est toujours aussi pertinent aujourd’hui. Il va au-delà de la modélisation des causes à effets pour modéliser également le flux et les stocks d’informations, d’argent et de matériaux au sein d’un système. Le livre contient également une modélisation mathématique formelle de ces dynamiques, toutefois la lecture de cette dernière reste facultative quant à apprécier la qualité de l’ouvrage.
* Weinberg’s ''Quality Software Management: Systems Thinking'' and ''An Introduction to General Systems Thinking'' are worthwhile. Written from the perspective of an experienced consultant in systems development.
* Les ouvrages [https://www.amazon.fr/Quality-Software-Management-Systems-Thinking/dp/0932633226/ ''Quality Software Management: Systems Thinking''] et [https://www.amazon.fr/Introduction-General-Systems-Thinking-Weinberg/dp/0932633498/ ''An Introduction to General Systems Thinking''] de Gerald Weinberg sont intéressants. Il sont écrits du point de vue d’un consultant expérimenté en développement de systèmes.
* Senge’s [http://www.amazon.com/Fifth-Discipline-Practice-Learning-Organization-ebook/dp/B000SEIFKK/ref=sr_1_1?ie=UTF8&qid=1413601715&sr=8-1&keywords=the+fifth+discipline ''The Fifth Discipline''] is a classic that advocates the need for leadership to apply systems thinking (it is the ''fifth'' discipline) and other key disciplines for a great, sustainable enterpise. The others include leaders with (1) personal mastery and (2) reflection on their beliefs and faulty reasoning, the (3) definition and communication of a meaningful shared vision, and (4) the ability of teams to learn. We recommend ignoring—at least during the first few years of practice—the ‘archetypes’ notion presented in the book. It was well meant as a learning aid but has been observed to distract and intimidate people from learning and applying basic system dynamics modeling. The ‘archetypes’ are not part of original system dynamics.

[https://www.amazon.fr/cinqui%C3%A8me-discipline-Levier-organisations-apprenantes/dp/2212559372/ ''La cinquième discipline''] est un autre classique du genre qui prône que l’encadrement d’une entreprise devrait appliquer l’approche systémique (autrement dit la ''cinquième'' discipline) ainsi que d’autres disciplines-clés toutes aussi importantes en vue d’obtenir une entreprise durable. Ces autres disciplines que les dirigeants devraient appliquer sont (1) une maîtrise personnelle des aspirations, (2) une réflexion sur leurs propres croyances et raisonnements erronés, (3) la définition et la communication d’une vision partagée ayant du sens, et (4) la capacité des équipes à apprendre. Nous vous recommandons d’ignorer - du moins dans un premier temps pendant vos premières années de pratiques - le concept d’archétypes présenté dans le livre. Ce concept avait pour but d’être une aide à l’apprentissage de la cinquième discipline mais nous avons observé qu’il était soit une source de distraction soit qu’il intimidait les lecteurs quant à leur apprentissage et à l’application de la modélisation des dynamiques des systèmes. Les ‘archetypes’ ne font pas partie à l’origine des dynamiques des systèmes.

* [http://www.amazon.com/Fifth-Discipline-Fieldbook-Strategies-Organization-ebook/dp/B00JTCJEO8/ref=sr_1_1?ie=UTF8&qid=1413601809&sr=8-1&keywords=The+Fifth+Discipline+Fieldbook ''The Fifth Discipline Fieldbook''] is an in-depth resource, written from the viewpoint of many practitioners and consultants.

*[https://www.amazon.fr/guide-lorganisation-apprenante-d%C3%A9velopper-lintelligence/dp/2212568711/ ''La 5ème discipline - le guide de l’organisation apprenante''] est une source extrêmement riche sur l’approche systèmique écrite du point de vue des pratiquants de cette approche et de consultants.

* The organizational-learning writings from Argyris, Putnam, McLain, and Schön. Important concepts include ''double-loop learning'' and ''high-advocacy/high-inquiry dialogue''. Classic works include [https://actiondesign.com/resources/readings/action-science ''Action Science''] and [http://www.amazon.com/Organizational-Learning-Addison-Wesley-Organization-Development/dp/0201001748/ref=sr_1_11?ie=UTF8&qid=1413601940&sr=8-11&keywords=organizational+learning ''Organizational Learning''].
* Les écrits d’Argyris, Outnam, McLain et Schön sur les apprentissages organisationnels comme [https://actiondesign.com/resources/readings/action-science ''Action Science''] et [http://www.amazon.com/Organizational-Learning-Addison-Wesley-Organization-Development/dp/0201001748/ref=sr_1_11?ie=UTF8&qid=1413601940&sr=8-11&keywords=organizational+learning ''Organizational Learning''] abordent des concepts importants tels que la ''double-boucle apprenante'' et le ''dialogue grand-plaidoyer/grand-réquisitoire''.
* The publications and resources available through the [https://www.solonline.org/ ''Society for Organizational Learning''].
* Les publications et les ressources de la ''Society for Organizational Learning''](https://www.solonline.org/).

-----

===== Notes: =====

# Senge wrote ''The Fifth Discipline'' , on systems thinking and learning organizations, named “one of the seminal management books of the last 75 years” by the ''Harvard Business Review.'' See** [Senge94].
# Another reason: Believing more control is possible than actually is. Complexity science suggests fundamental limits on predicting and controlling semi-chaotic social systems [Stacey07]. This is a rather large can of worms that will remain unopened in this book.
# Macroeconomics, psychology, sociology, and biology are exceptions, among many others.
# ‘Basic’ does not mean trivial or easy to solve. For example, ‘motivation’ and ‘quality’ are basic but not easy issues.
# ''Feedback loops'' is occasionally used in this book in the colloquial sense of feedback, rather than this system dynamics sense.

[^1] ''La cinquième discipline'' écrit par Senge sur l’approche systèmique et les organisations apprenantes a été nommé « l’un des livres les plus novateurs sur le management de ces 75 dernières années » par la ''Harvard Business Review.'' See** [Senge94]. [^2]: Une autre raison : Croire que plus de contrôle est possible qu’il ne l’est actuellement. La science de la complexité montre qu’il existe des limites en terme de prédiction et de contrôle des systèmes sociaux semi-chaotiques [Stacey07]. C’est une énorme boîte de Pandore qui restera enfermée dans ce livre. [^3]: Macro économie, psychologie, sociologie et biologie sont des exemples d’exceptions parmi d’autres [^4]: ‘Basique’ ne signifie pas trivial ou facile à résoudre. Par exemple, les problématiques de ‘motivation’ et de ‘qualité’ sont des problématiques basiques mais elles ne sont pas faciles à résoudre. [^5]: ''Les boucles de feedback'' sont parfois utilisées dans ce livre dans le sens littéral du terme, plutôt dans le sens des dynamiques des systèmes

Catégorie:Portail LeSS

2020-10-27T20:05:15Z

Nicolas Mereaux :

<addthis />
[[Catégorie: Portails Thématiques]]
[[Category: Agilité à grande échelle]]
[[Category: Portail Framework]]
[[Fichier:LeSS-logo 72.png|link=]] À la découverte de LeSS, ce framework de mise à l'échelle de l'élégance de Scrum. 
[[Image:LeSS-overview-diagram_fr.png|LeSS-overview-diagram_fr.png|link=]] [http://less.works/less/framework/introduction.html introduction] '''''"Depuis 2005, nous avons travaillé avec des clients pour mettre en oeuvre le framework LeSS (Large-Scale Scrum) de mise à l'échelle du développement Scrum, agile et lean pour les groupes produit de grande taille. Nous partageons cette connaissance à travers LeSS pour que, vous aussi, vous puissiez réussir lorsque vous passez à l'échelle."''''' - Craig Larman & Bas Vodde '''Articles thématiques''' 
----

* '''[[LeSS%20-%20Portail%20Framework|Portail Framework LeSS (fr)] - 95%]]'''
** [http://less.works/less/framework/introduction.html Introduction à LeSS]
** [[Pourquoi%20LeSS%20%3F|Pourquoi LeSS (fr)]]
** [[LeSS%20-%20Le%20Produit|Le Produit (fr)]]
** [[LeSS%20-%20Le%20Product%20Owner|Le Product Owner (fr)]]
** [[LeSS%20-%20Le%20backlog%20du%20produit|Le Backlog du Produit (fr)]]
** [[LeSS%20-%20Les%20%C3%89quipes|Les Équipes (fr)]]
** [[LeSS%20-%20Le%20Sprint|Le Sprint (fr)]]
** [[LeSS%20-%20La%20Planification%20du%20Sprint%20%281%C3%A8re%20partie%29|La Planification du Sprint (1ère partie) (fr)]]
** [[LeSS%20-%20La%20Planification%20du%20Sprint%20%282%C3%A8me%20partie%29|La Planification du Sprint (2ème partie) (fr)]]
** [[LeSS%20-%20Le%20Backlog%20du%20Sprint|Le Backlog du Sprint (fr)]]
** [[LeSS%20-%20La%20M%C3%AAl%C3%A9e%20Quotidienne|La Mêlée Quotidienne (fr)]]
** [[LeSS%20-%20Coordination%20%26%20Int%C3%A9gration|Coordination & Intégration (fr)]]
** [[LeSS%20-%20L%27Incr%C3%A9ment%20Produit%20Potentiellement%20D%C3%A9ployable|L'Incrément Produit Potentiellement Déployable (fr)]]
** [[LeSS%20-%20La%20D%C3%A9finition%20du%20Fini|La Définition du Fini (fr)]]
** [[LeSS%20-%20La%20Revue%20de%20Sprint|La Revue de Sprint (fr)]]
** [[LeSS%20-%20La%20R%C3%A9trospective|La Rétrospective (fr)]]
** [[LeSS%20-%20La%20R%C3%A9trospective%20Globale|La Rétrospective Globale (fr)]]
** [[LeSS%20-%20L%27Affinage%20du%20Backlog%20Produit|L'Affinage du Backlog Produit (fr)]]
** [[LeSS%20-%20L%27Affinage%20Initial%20du%20Backlog%20Produit|L'Affinage Initial du Backlog Produit (fr)]]
** [[LeSS%20-%20Le%20ScrumMaster|Le ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20Principes|Portail Principes (fr)] - 63%]]'''
** [[LeSS%20-%20Pr%C3%A9sentation%20des%20principes|Présentation des principes (fr)]]
** [[LeSS%20-%20Scrum%20%C3%A0%20grande%20%C3%A9chelle%20reste%20du%20Scrum|Scrum à grande échelle reste du Scrum (fr)]]
** [[Less_-_Plus_avec_LeSS|Plus avec LeSS (fr)]]
** [http://less.works/less/principles/lean-thinking.html Pensée Lean]
** [[LeSS - Approche systémique|Approche systémique (fr)]]
** [[LeSS%20-%20Contr%C3%B4le%20du%20processus%20empirique|Contrôle du processus empirique (fr)]]
** [[LeSS%20-%20Transparence|Transparence (fr)]]
** [http://less.works/less/principles/continuous-improvement-towards-perfection.html Amélioration continue vers la perfection]
** [[Less_-_Centré_client|Centré client (fr)]]
** [[Less_-_Focus_sur_le_produit_global|Focus sur le produit global (fr)]]
** [https://less.works/less/principles/queueing_theory.html Théorie des files d'attente]
 

* '''[[LeSS%20-%20Portail%20Structure|Portail Structure (fr)]] - 100%'''
** [[LeSS%20-%20Equipes|Equipes (fr)]]
** [[LeSS%20-%20Organisation%20en%20fonction%20de%20la%20valeur%20client|Organisation en fonction de la valeur client (fr)]]
** [[LeSS%20-%20Equipes%20Feature|Equipes Feature (fr)]]
** [[LeSS%20-%20Structure%20organisationnelle|Structure organisationnelle (fr)]]
** [[LeSS%20-%20Communaut%C3%A9s|Communautés (fr)]]
** [[LeSS%20-%20ScrumMaster|ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20Excellence%20technique|Portail Excellence Technique (fr)]] - 40%'''
** [[LeSS%20-%20Sp%C3%A9cifications%20par%20l%27exemple|Spécifications par l'exemple (fr)]]
** [[Less - Intégration continue|Intégration Continue (fr)]]
** [https://less.works/less/technical-excellence/continuous-delivery.html Livraison Continue]
** [[LeSS - Tests d'Acceptation|Tests d'Acceptation (fr)]]
** [http://less.works/less/technical-excellence/architecture-design.html Architecture & Conception]
** [http://less.works/less/technical-excellence/clean-code.html Ecrire du Code Propre]
** [http://less.works/less/technical-excellence/unit-testing.html Tests unitaires]
** [[Less - Développement piloté par les tests|Développement piloté par les tests (fr)]]
** [http://less.works/less/technical-excellence/thinking-about-testing.html Réflexions à propos des tests]
** [http://less.works/less/technical-excellence/test-automation.html Automatisation des tests]
 

* '''[[LeSS%20-%20Portail%20Management|Portail Management (fr)]] - 100%'''
** [[LeSS%20-%20R%C3%B4le%20du%20Manager|Rôle du Manager (fr)]]
** [[LeSS%20-%20Enseigner%20la%20r%C3%A9solution%20de%20probl%C3%A8me|Enseigner la résolution de problème (fr)]]
** [[LeSS%20-%20Aller%20Voir|Aller Voir (fr)]]
** [[LeSS%20-%20Auto-gestion|Auto-gestion (fr)]]
** [[LeSS%20-%20Service%20d%27am%C3%A9lioration|Service d'amélioration (fr)]]
** [[LeSS%20-%20Le%20Manager%20en%20tant%20que%20ScrumMaster|Le Manager en tant que ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20LeSS%20Huge|Portail Less Huge (fr)]] - 100%'''
** [[LeSS%20-%20Domaines%20d%27exigences|Domaines d'Exigences (fr)]]
** [[LeSS%20-%20Backlog%20Produit%20de%20Domaine|Backlog Produit de Domaine (fr)]]
** [[LeSS%20-%20Product%20Owner%20de%20Domaine|Product Owner de Domaine (fr)]]
** [[LeSS%20-%20Structure%20organisationnelle%20pour%20LeSS%20Huge|Structure organisationnelle pour LeSS Huge (fr)]]
 

* '''[[LeSS%20-%20Portail%20Adoption|Portail Adoption (fr)]] - 100%'''
** [[LeSS%20-%20Les%20trois%20principes|Trois principes (fr)]]
** [[LeSS%20-%20D%C3%A9marrer|Démarrer (fr)]]
** [[LeSS%20-%20Coaching|Coaching (fr)]]
** [[LeSS%20-%20Am%C3%A9lioration%20continue|Amélioration Continue (fr)]]
** [[LeSS%20-%20Sch%C3%A9ma%20d%27adoption%20des%20%C3%A9quipes%20feature|Schéma d'adoption des équipes feature (fr)]]
** [[LeSS%20-%20Rester%20sain%20d%27esprit|Rester sain d'esprit (fr)]]
 

* '''LeSS Test'''
** [http://less.works/less/test/pre-course.html LeSS Test]
** [http://less.works/less/test/scrum.html Scrum Test]

Catégorie:Portail LeSS

2020-10-27T20:04:20Z

Nicolas Mereaux :

<addthis />
[[Catégorie: Portails Thématiques]]
[[Category: Agilité à grande échelle]]
[[Category: Portail Framework]]
[[Fichier:LeSS-logo 72.png|link=]] À la découverte de LeSS, ce framework de mise à l'échelle de l'élégance de Scrum. 
[[Image:LeSS-overview-diagram_fr.png|LeSS-overview-diagram_fr.png|link=]] [http://less.works/less/framework/introduction.html introduction] '''''"Depuis 2005, nous avons travaillé avec des clients pour mettre en oeuvre le framework LeSS (Large-Scale Scrum) de mise à l'échelle du développement Scrum, agile et lean pour les groupes produit de grande taille. Nous partageons cette connaissance à travers LeSS pour que, vous aussi, vous puissiez réussir lorsque vous passez à l'échelle."''''' - Craig Larman & Bas Vodde '''Articles thématiques''' 
----

* '''[[LeSS%20-%20Portail%20Framework|Portail Framework LeSS (fr)] - 95%]]'''
** [http://less.works/less/framework/introduction.html Introduction à LeSS]
** [[Pourquoi%20LeSS%20%3F|Pourquoi LeSS (fr)]]
** [[LeSS%20-%20Le%20Produit|Le Produit (fr)]]
** [[LeSS%20-%20Le%20Product%20Owner|Le Product Owner (fr)]]
** [[LeSS%20-%20Le%20backlog%20du%20produit|Le Backlog du Produit (fr)]]
** [[LeSS%20-%20Les%20%C3%89quipes|Les Équipes (fr)]]
** [[LeSS%20-%20Le%20Sprint|Le Sprint (fr)]]
** [[LeSS%20-%20La%20Planification%20du%20Sprint%20%281%C3%A8re%20partie%29|La Planification du Sprint (1ère partie) (fr)]]
** [[LeSS%20-%20La%20Planification%20du%20Sprint%20%282%C3%A8me%20partie%29|La Planification du Sprint (2ème partie) (fr)]]
** [[LeSS%20-%20Le%20Backlog%20du%20Sprint|Le Backlog du Sprint (fr)]]
** [[LeSS%20-%20La%20M%C3%AAl%C3%A9e%20Quotidienne|La Mêlée Quotidienne (fr)]]
** [[LeSS%20-%20Coordination%20%26%20Int%C3%A9gration|Coordination & Intégration (fr)]]
** [[LeSS%20-%20L%27Incr%C3%A9ment%20Produit%20Potentiellement%20D%C3%A9ployable|L'Incrément Produit Potentiellement Déployable (fr)]]
** [[LeSS%20-%20La%20D%C3%A9finition%20du%20Fini|La Définition du Fini (fr)]]
** [[LeSS%20-%20La%20Revue%20de%20Sprint|La Revue de Sprint (fr)]]
** [[LeSS%20-%20La%20R%C3%A9trospective|La Rétrospective (fr)]]
** [[LeSS%20-%20La%20R%C3%A9trospective%20Globale|La Rétrospective Globale (fr)]]
** [[LeSS%20-%20L%27Affinage%20du%20Backlog%20Produit|L'Affinage du Backlog Produit (fr)]]
** [[LeSS%20-%20L%27Affinage%20Initial%20du%20Backlog%20Produit|L'Affinage Initial du Backlog Produit (fr)]]
** [[LeSS%20-%20Le%20ScrumMaster|Le ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20Principes|Portail Principes (fr)] - 63%]]'''
** [[LeSS%20-%20Pr%C3%A9sentation%20des%20principes|Présentation des principes (fr)]]
** [[LeSS%20-%20Scrum%20%C3%A0%20grande%20%C3%A9chelle%20reste%20du%20Scrum|Scrum à grande échelle reste du Scrum (fr)]]
** [[Less_-_Plus_avec_LeSS|Plus avec LeSS (fr)]]
** [http://less.works/less/principles/lean-thinking.html Pensée Lean]
** [[LeSS - Approche systémique|Approche systémique (fr]]
** [[LeSS%20-%20Contr%C3%B4le%20du%20processus%20empirique|Contrôle du processus empirique (fr)]]
** [[LeSS%20-%20Transparence|Transparence (fr)]]
** [http://less.works/less/principles/continuous-improvement-towards-perfection.html Amélioration continue vers la perfection]
** [[Less_-_Centré_client|Centré client (fr)]]
** [[Less_-_Focus_sur_le_produit_global|Focus sur le produit global (fr)]]
** [https://less.works/less/principles/queueing_theory.html Théorie des files d'attente]
 

* '''[[LeSS%20-%20Portail%20Structure|Portail Structure (fr)]] - 100%'''
** [[LeSS%20-%20Equipes|Equipes (fr)]]
** [[LeSS%20-%20Organisation%20en%20fonction%20de%20la%20valeur%20client|Organisation en fonction de la valeur client (fr)]]
** [[LeSS%20-%20Equipes%20Feature|Equipes Feature (fr)]]
** [[LeSS%20-%20Structure%20organisationnelle|Structure organisationnelle (fr)]]
** [[LeSS%20-%20Communaut%C3%A9s|Communautés (fr)]]
** [[LeSS%20-%20ScrumMaster|ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20Excellence%20technique|Portail Excellence Technique (fr)]] - 40%'''
** [[LeSS%20-%20Sp%C3%A9cifications%20par%20l%27exemple|Spécifications par l'exemple (fr)]]
** [[Less - Intégration continue|Intégration Continue (fr)]]
** [https://less.works/less/technical-excellence/continuous-delivery.html Livraison Continue]
** [[LeSS - Tests d'Acceptation|Tests d'Acceptation (fr)]]
** [http://less.works/less/technical-excellence/architecture-design.html Architecture & Conception]
** [http://less.works/less/technical-excellence/clean-code.html Ecrire du Code Propre]
** [http://less.works/less/technical-excellence/unit-testing.html Tests unitaires]
** [[Less - Développement piloté par les tests|Développement piloté par les tests (fr)]]
** [http://less.works/less/technical-excellence/thinking-about-testing.html Réflexions à propos des tests]
** [http://less.works/less/technical-excellence/test-automation.html Automatisation des tests]
 

* '''[[LeSS%20-%20Portail%20Management|Portail Management (fr)]] - 100%'''
** [[LeSS%20-%20R%C3%B4le%20du%20Manager|Rôle du Manager (fr)]]
** [[LeSS%20-%20Enseigner%20la%20r%C3%A9solution%20de%20probl%C3%A8me|Enseigner la résolution de problème (fr)]]
** [[LeSS%20-%20Aller%20Voir|Aller Voir (fr)]]
** [[LeSS%20-%20Auto-gestion|Auto-gestion (fr)]]
** [[LeSS%20-%20Service%20d%27am%C3%A9lioration|Service d'amélioration (fr)]]
** [[LeSS%20-%20Le%20Manager%20en%20tant%20que%20ScrumMaster|Le Manager en tant que ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20LeSS%20Huge|Portail Less Huge (fr)]] - 100%'''
** [[LeSS%20-%20Domaines%20d%27exigences|Domaines d'Exigences (fr)]]
** [[LeSS%20-%20Backlog%20Produit%20de%20Domaine|Backlog Produit de Domaine (fr)]]
** [[LeSS%20-%20Product%20Owner%20de%20Domaine|Product Owner de Domaine (fr)]]
** [[LeSS%20-%20Structure%20organisationnelle%20pour%20LeSS%20Huge|Structure organisationnelle pour LeSS Huge (fr)]]
 

* '''[[LeSS%20-%20Portail%20Adoption|Portail Adoption (fr)]] - 100%'''
** [[LeSS%20-%20Les%20trois%20principes|Trois principes (fr)]]
** [[LeSS%20-%20D%C3%A9marrer|Démarrer (fr)]]
** [[LeSS%20-%20Coaching|Coaching (fr)]]
** [[LeSS%20-%20Am%C3%A9lioration%20continue|Amélioration Continue (fr)]]
** [[LeSS%20-%20Sch%C3%A9ma%20d%27adoption%20des%20%C3%A9quipes%20feature|Schéma d'adoption des équipes feature (fr)]]
** [[LeSS%20-%20Rester%20sain%20d%27esprit|Rester sain d'esprit (fr)]]
 

* '''LeSS Test'''
** [http://less.works/less/test/pre-course.html LeSS Test]
** [http://less.works/less/test/scrum.html Scrum Test]

Less - Développement piloté par les tests

2020-03-08T17:58:11Z

Nicolas Mereaux : Page créée avec « Auteur : The LeSS Company B.V. Source : [https://less.works/less/technical-excellence/test-driven-development.html Technical Excellence - Test-Driven Development (LeSS)] -... »

Auteur : The LeSS Company B.V.
Source : [https://less.works/less/technical-excellence/test-driven-development.html Technical Excellence - Test-Driven Development (LeSS)]
----
Traducteur : Nicolas Mereaux
Relecture : Fabrice Aimetti
Date : 08/03/2020
----
Traduction :

[[LeSS - Portail Excellence technique]]

= Test-Driven Development =

= Développement piloté par les tests (TDD) =

== What Is Test-Driven Development ==

== Qu’est-ce que le développement piloté par les tests ? ==

Test-driven development is a development style that drives the design by tests developed in short cycles of:

Le développement piloté par les tests est un style de développement qui guide la conception par l’introduction de tests développés sur des cycles courts :

# Write one test.
# Implement just enough code to make it pass.
# Refactor the code so it is clean.

# Écrire un test.
# Implémenter juste ce qu’il faut de code pour passer le test.
# Refactorer le code afin qu’il soit tout propre

[[Fichier:Tdd-cycle-fr.png|centré|254px|TDD]]

In a language such as Java, this cycle is as short as five minutes. In older languages, with slower compilation and less automated refactoring support, this cycle is longer—perhaps twenty minutes.

Dans un langage comme Java, ce cycle ne prend pas plus de 5 minutes. Dans des langages plus anciens, ayant des temps de compilation plus longs et moins d’outils de refactoring automatisés, ce cycle est plus long - 20 minutes environ.

Is test-driven development different in large product development? No. It is an individual developer practice and the number of people in the development does not matter. The amount of legacy code, old technology, and embedded develop- ment does have an impact on unit testing and test-driven development. Therefore, most experiments in this section are related to these.

Est-ce que le développement piloté par les tests est différent dans le cadre du développement de produits de taille importante ? Non, car il s’agit d’une pratique individuelle de développeur peu importe le nombre de personnes impliquées dans le développement. La quantité de code historique, les anciennes technologies et les développements dans l’embarqué ont un impact sur le test unitaire et sur le développement piloté par les tests. En conséquence, la plupart des expérimentations de la présente section sont en lien avec ces sujets.

=== A TDD cycle Should Be … ===

=== Un cycle TDD type devrait être … ===

'''Short''' The turnaround time for passing each test is short. It could take 5 mins per cycle. '''Rhythmic''' You’ll feel the rhythm distinctly - “red, green, refactor… red, green refactor…” '''Incremental''' You’ll know that as you write and pass more tests, working functionalities are being build up incrementally. '''Design-focused''' With good knowledge of software design principles, you’ll discover TDD is not a testing technique but a method of designing software. '''Disciplined''' TDD is a different way of developing software. To break the old habit of “code and fix” and to adopt a new habit will require discipline and persistence.

'''Court''' Le temps de traitement pour passer chaque test est court. Cela devrait prendre 5 minutes par cycle. '''Rhythmique''' Vous sentirez le rythme très distinctement - « rouge, vert, refactorer … rouge, vert, refactorer … » '''Incrémental''' Vous saurez au fur et à mesure que vous écrirez et ferez passer de plus en plus de tests, que des fonctionnalités sont construites de manière incrémentale '''Focalisé sur la conception''' Avec une bonne connaissance des principes de conception logicielle, vous découvrirez que le développement piloté par les tests n’est pas une technique de tests mais une méthode pour concevoir du logiciel. '''Discipliné''' Le TDD est une autre façon de développer du logiciel. Casser les vieilles habitudes « coder et corriger » pour adopter une nouvelle habitude exigera de la discipline et de la persévérance

== Why TDD? ==

== Pourquoi le TDD ? ==

== Coaching TDD ==

== Coacher le TDD ==

=== Use TDD Coaches ===

=== Recourir à des coachs en TDD ===

When a client of ours reviewed a draft of the companion book, he mentioned that we ought to stress coaching more. “One of our mistakes is that we didn’t provide enough coaching,” he said. Though we agreed with him, we pointed out that since we are both consultants and provide such coaching, this advice would not be very credible. We might as well add an experiment “Try…Hire us.” Thus, we minimized the advice related to hiring coaches.

À la relecture du brouillon du livret d’accompagnement, l’un de nos clients a énoncé que nous devrions insister davantage sur l’aspect coaching. « L’une de nos erreurs a été de ne pas avoir fourni suffisamment de coaching » a-t-il dit. Bien que nous ayons été d’accord avec lui, nous lui avons fait remarquer que nous étions tous les deux des consultants et que nous offrions ce type d’accompagnement, ce conseil n’était donc pas très crédible. Nous aurions bien pu aussi bien mettre une pancarte « Essayez … Engagez-nous ». Par conséquent, nous minimisons le conseil d’avoir recours à des coachs.

But related to test-driven development, we cannot stress strongly enough: Hire coaches! Adopting TDD means unlearning traditional programming and relearning how to design and code. We rarely meet people who were able to adopt this by self-education. Most developers need a coach to pair-program with them for days or weeks. The coach constantly reminds them to write the tests first and to really clean up the code—including the test code. He helps them apply TDD and refactoring to their real code.

Toutefois en ce qui concerne le développement piloté par les tests, nous ne pouvons que trop insister : engagez des coachs ! Adopter le TDD signifie désapprendre le développement traditionnel et réapprendre comment concevoir et coder. Nous rencontrons rarement des gens qui soient en capacité de l’adopter en autodidacte. La plupart des développeurs ont besoin d’un coach pour programmer avec eux en binome pendant quelques jours ou quelques semaines. Le coach leurs rappelle constamment d’écrire les tests d’abord et de mettre de l’ordre dans le code - y compris le code de tests. Il les aide à appliquer le TDD et à refactorer leur véritable code.

Test-driven development might be the hardest agile practice to adopt, but it is also one of the biggest opportunities for improving the quality of the design and code. Hire coaches!

Le développement piloté par les tests pourrait bien être la pratique agile la plus difficile à adopter, mais il s’agit aussi de l’une des plus grosses opportunités pour améliorer la qualité de la conception et du code. Engagez des coachs !

=== Internal and external coaches ===

=== Coachs internes et externes ===

External coaches are needed when adopting TDD because the com- petence does not yet exist inside the company. But, over time, growing internal coaches reduces the dependence on externals and the cost of coaching.

Des coachs externes sont nécessaires quant à l’adoption de TDD car la compétence n’existe pas encore dans l’entreprise. Mais, avec le temps, la montée en compétence de coachs internes diminuent la dépendance vis-à-vis de coachs externes et en réduit le coût.

That said, we have seen several attempts fail to develop internal coaches. Some reasons:

Ceci dit, nous avons assisté à plusieurs échecs quant à la mise en place de coachs internes. Voici quelques raisons de ces échecs :

* No structure was in place to decide when and with which teams to work.
* No time was reserved for coaching. Instead the internal coaches were asked to do normal development.
* Developers were less eager to learn from internal coaches…you are never a prophet in your own land.
* Coaching skills were not appreciated and further developed. The result is that skilled internal coaches often leave to be an external coach.

* Aucune structure n’était en place pour décider avec quelle équipe travailler et quand le faire.
* Aucun temps n’était accordé pour du coaching. Au lieu de cela il était demandé aux coachs internes de faire du développement « traditionnel ».
* Les développeurs étaient moins enthousiastes d’apprendre de coachs internes … vous n’êtes jamais prophète dans votre propre pays.
* Les compétences de coach n’étaient ni appréciées ni encouragées à être davantage développées. En conséquence de quoi, les coachs internes compétents partaient souvent pour devenir coach externe.

Choose both internal and external coaching. Depending on either of them alone is risky but combining them can lead to good results.

Choisissez les deux, du coaching interne et du coaching externe. Dépendre de l’un des deux uniquement est risqué mais les combiner peut conduire à de bons résultats.

== Test-driven development for a better architecture ==

== Développement piloté par les tests pour une meilleure architecture ==

TDD can help improve the architecture of a system. How?

Le TDD peut aider à améliorer l’architecture d’un système. Comment ?

When we are coaching, a frequent request is help for dealing with our client’s “inflexible architecture.” This most often boils down to problems in high coupling between components—a common problem in legacy code written without TDD because the original developer did not try to test the component in isolation.

Quand nous faisons de l’accompagnement, une demande d’assistante fréquente qui nous est adressée est d’aider à assouplir « l’architecture inflexible» de notre client. Cela se réduit le plus souvent à des problèmes de couplages très étroits entre les composants - un problème assez répandu dans du code ancien écrit sans TDD parce que le développeur d’origine n’avait pas essayé de tester le composant de manière isolé.

On the other hand, when a developer creates a new component (such as a class) with TDD, or refactors a legacy component to be unit-testable, they must break the dependencies of that component so that it is testable in isolation. That requires designing (or refactoring) for dependency injection and increased use of mechanisms for flexibility: interfaces, polymorphism, design patterns, dependency injection frameworks, function pointers, and more.

D’un autre côté, lorsqu’un développeur créé un nouveau composant (comme une classe) avec le TDD, ou refactore un composant historique pour être testable unitairement, il doit casser les dépendances de ce composant afin qu’il soit testable de manière isolé. Cela exige de faire une conception orientée injection de dépendances et d’augmenter l’utilisation de mécanismes pour plus de flexibilité : interfaces, polymorphisme, schéma de conceptions, ''framework'' d’injection de dépendances, pointeurs de fonctions, etc

In this way, TDD encourages lower coupling and simple, flexible configuration—qualities of a good architecture.

De cette manière, le TDD encourage un couplage plus lâche, plus simple, une configuration plus simple - en somme, les qualités d’une bonne architecture.

Fichier:Tdd-cycle-fr.png

2020-03-08T17:52:14Z

Nicolas Mereaux : Cycle TDD

Cycle TDD

Catégorie:Portail LeSS

2020-03-08T17:40:32Z

Nicolas Mereaux :

<addthis />
[[Catégorie: Portails Thématiques]]
[[Category: Agilité à grande échelle]]
[[Category: Portail Framework]]
[[Fichier:LeSS-logo 72.png]] À la découverte de LeSS, ce framework de mise à l'échelle de l'élégance de Scrum. 
[[Image:LeSS-overview-diagram_fr.png|LeSS-overview-diagram_fr.png]] [http://less.works/less/framework/introduction.html introduction] '''''"Depuis 2005, nous avons travaillé avec des clients pour mettre en oeuvre le framework LeSS (Large-Scale Scrum) de mise à l'échelle du développement Scrum, agile et lean pour les groupes produit de grande taille. Nous partageons cette connaissance à travers LeSS pour que, vous aussi, vous puissiez réussir lorsque vous passez à l'échelle."''''' - Craig Larman & Bas Vodde '''Articles thématiques''' 
----

* '''[[LeSS%20-%20Portail%20Framework|Portail Framework LeSS (fr)] - 95%]]'''
** [http://less.works/less/framework/introduction.html Introduction à LeSS]
** [[Pourquoi%20LeSS%20%3F|Pourquoi LeSS (fr)]]
** [[LeSS%20-%20Le%20Produit|Le Produit (fr)]]
** [[LeSS%20-%20Le%20Product%20Owner|Le Product Owner (fr)]]
** [[LeSS%20-%20Le%20backlog%20du%20produit|Le Backlog du Produit (fr)]]
** [[LeSS%20-%20Les%20%C3%89quipes|Les Équipes (fr)]]
** [[LeSS%20-%20Le%20Sprint|Le Sprint (fr)]]
** [[LeSS%20-%20La%20Planification%20du%20Sprint%20%281%C3%A8re%20partie%29|La Planification du Sprint (1ère partie) (fr)]]
** [[LeSS%20-%20La%20Planification%20du%20Sprint%20%282%C3%A8me%20partie%29|La Planification du Sprint (2ème partie) (fr)]]
** [[LeSS%20-%20Le%20Backlog%20du%20Sprint|Le Backlog du Sprint (fr)]]
** [[LeSS%20-%20La%20M%C3%AAl%C3%A9e%20Quotidienne|La Mêlée Quotidienne (fr)]]
** [[LeSS%20-%20Coordination%20%26%20Int%C3%A9gration|Coordination & Intégration (fr)]]
** [[LeSS%20-%20L%27Incr%C3%A9ment%20Produit%20Potentiellement%20D%C3%A9ployable|L'Incrément Produit Potentiellement Déployable (fr)]]
** [[LeSS%20-%20La%20D%C3%A9finition%20du%20Fini|La Définition du Fini (fr)]]
** [[LeSS%20-%20La%20Revue%20de%20Sprint|La Revue de Sprint (fr)]]
** [[LeSS%20-%20La%20R%C3%A9trospective|La Rétrospective (fr)]]
** [[LeSS%20-%20La%20R%C3%A9trospective%20Globale|La Rétrospective Globale (fr)]]
** [[LeSS%20-%20L%27Affinage%20du%20Backlog%20Produit|L'Affinage du Backlog Produit (fr)]]
** [[LeSS%20-%20L%27Affinage%20Initial%20du%20Backlog%20Produit|L'Affinage Initial du Backlog Produit (fr)]]
** [[LeSS%20-%20Le%20ScrumMaster|Le ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20Principes|Portail Principes (fr)] - 63%]]'''
** [[LeSS%20-%20Pr%C3%A9sentation%20des%20principes|Présentation des principes (fr)]]
** [[LeSS%20-%20Scrum%20%C3%A0%20grande%20%C3%A9chelle%20reste%20du%20Scrum|Scrum à grande échelle reste du Scrum (fr)]]
** [[Less_-_Plus_avec_LeSS|Plus avec LeSS (fr)]]
** [http://less.works/less/principles/lean-thinking.html Pensée Lean]
** [http://less.works/less/principles/systems_thinking.html Approche systémique]
** [[LeSS%20-%20Contr%C3%B4le%20du%20processus%20empirique|Contrôle du processus empirique (fr)]]
** [[LeSS%20-%20Transparence|Transparence (fr)]]
** [http://less.works/less/principles/continuous-improvement-towards-perfection.html Amélioration continue vers la perfection]
** [[Less_-_Centré_client|Centré client (fr)]]
** [[Less_-_Focus_sur_le_produit_global|Focus sur le produit global (fr)]]
** [https://less.works/less/principles/queueing_theory.html Théorie des files d'attente]
 

* '''[[LeSS%20-%20Portail%20Structure|Portail Structure (fr)]] - 100%'''
** [[LeSS%20-%20Equipes|Equipes (fr)]]
** [[LeSS%20-%20Organisation%20en%20fonction%20de%20la%20valeur%20client|Organisation en fonction de la valeur client (fr)]]
** [[LeSS%20-%20Equipes%20Feature|Equipes Feature (fr)]]
** [[LeSS%20-%20Structure%20organisationnelle|Structure organisationnelle (fr)]]
** [[LeSS%20-%20Communaut%C3%A9s|Communautés (fr)]]
** [[LeSS%20-%20ScrumMaster|ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20Excellence%20technique|Portail Excellence Technique (fr)]] - 30%'''
** [[LeSS%20-%20Sp%C3%A9cifications%20par%20l%27exemple|Spécifications par l'exemple (fr)]]
** [[Less - Intégration continue|Intégration Continue (fr)]]
** [https://less.works/less/technical-excellence/continuous-delivery.html Livraison Continue]
** [[LeSS - Tests d'Acceptation|Tests d'Acceptation (fr)]]
** [http://less.works/less/technical-excellence/architecture-design.html Architecture & Conception]
** [http://less.works/less/technical-excellence/clean-code.html Ecrire du Code Propre]
** [http://less.works/less/technical-excellence/unit-testing.html Tests unitaires]
** [[Less - Développement piloté par les tests|Développement piloté par les tests (fr)]]
** [http://less.works/less/technical-excellence/thinking-about-testing.html Réflexions à propos des tests]
** [http://less.works/less/technical-excellence/test-automation.html Automatisation des tests]
 

* '''[[LeSS%20-%20Portail%20Management|Portail Management (fr)]] - 100%'''
** [[LeSS%20-%20R%C3%B4le%20du%20Manager|Rôle du Manager (fr)]]
** [[LeSS%20-%20Enseigner%20la%20r%C3%A9solution%20de%20probl%C3%A8me|Enseigner la résolution de problème (fr)]]
** [[LeSS%20-%20Aller%20Voir|Aller Voir (fr)]]
** [[LeSS%20-%20Auto-gestion|Auto-gestion (fr)]]
** [[LeSS%20-%20Service%20d%27am%C3%A9lioration|Service d'amélioration (fr)]]
** [[LeSS%20-%20Le%20Manager%20en%20tant%20que%20ScrumMaster|Le Manager en tant que ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20LeSS%20Huge|Portail Less Huge (fr)]] - 100%'''
** [[LeSS%20-%20Domaines%20d%27exigences|Domaines d'Exigences (fr)]]
** [[LeSS%20-%20Backlog%20Produit%20de%20Domaine|Backlog Produit de Domaine (fr)]]
** [[LeSS%20-%20Product%20Owner%20de%20Domaine|Product Owner de Domaine (fr)]]
** [[LeSS%20-%20Structure%20organisationnelle%20pour%20LeSS%20Huge|Structure organisationnelle pour LeSS Huge (fr)]]
 

* '''[[LeSS%20-%20Portail%20Adoption|Portail Adoption (fr)]] - 100%'''
** [[LeSS%20-%20Les%20trois%20principes|Trois principes (fr)]]
** [[LeSS%20-%20D%C3%A9marrer|Démarrer (fr)]]
** [[LeSS%20-%20Coaching|Coaching (fr)]]
** [[LeSS%20-%20Am%C3%A9lioration%20continue|Amélioration Continue (fr)]]
** [[LeSS%20-%20Sch%C3%A9ma%20d%27adoption%20des%20%C3%A9quipes%20feature|Schéma d'adoption des équipes feature (fr)]]
** [[LeSS%20-%20Rester%20sain%20d%27esprit|Rester sain d'esprit (fr)]]
 

* '''LeSS Test'''
** [http://less.works/less/test/pre-course.html LeSS Test]
** [http://less.works/less/test/scrum.html Scrum Test]

LeSS - Le Product Owner

2019-06-26T19:03:48Z

Nicolas Mereaux :

[[Category: Portail LeSS]]
[[Category: Portail Product Owner]]
Auteur : The LeSS Company B.V. 
Source : [https://less.works/less/framework/product-owner.html Product Owner (LeSS)] 
----
Traducteur : [http://www.les-traducteurs-agiles.org/traducteurs/ Nicolas Mereaux] 
Date : 23/06/2019 
----
Traduction : 
 
[[LeSS - Portail Framework]] 
 
Le rôle de Product Owner dans LeSS est conceptuellement le même que celui dans une unique équipe Scrum. Toutefois, à grande échelle la focale change légèrement pour aller vers quelque chose permettant de garder une vision globale et de garantir un retour sur investissement (ROI) maximum au niveau du produit. 
 
== Le Product Owner à grande échelle ==
S’il est une chose assez répandue dans le développement de produit à grande échelle c’est que différentes personnes tirent dans différentes directions et pour des sous-groupes de se focaliser sur des sur-optimisations au niveau local. Avoir un seul Product Owner avec un seul Backlog de Produit permet de maintenir un [[Less_-_Focus_sur_le_produit_global|focus sur le produit global (fr)]]. 
 
Dans les traditionnels groupes produit à grande échelle, nous trouvons d’une part un groupe (souvent des responsables produits - ''product managers'' -) focalisé vers l’extérieur et d’autre part un groupe (généralement les développeurs) focalisé vers l’intérieur - et jamais aucun des deux ne se rejoignent. Dans LeSS, le Product Owner unique dispose de beaucoup de temps pour se focaliser vers l’extérieur - les clients et leurs priorités - tout en étant aussi en capacité de prendre du temps pour se focaliser vers l’intérieur - les équipes. Il agit en tant que connecteur, faisant se réunir ensemble les équipes et les clients/utilisateurs afin que les équipes deviennent encore plus [[Less_-_Centré_client|orientées client (fr)]]). 
 
Par rapport à d’autres approches de Scrum à grande échelle, il est possible avec LeSS de passer à grande échelle le rôle de Product Owner avec une seule personne parce qu’il y a moins de rôles, de positions et moins de complexité. 
 
== Priorisation plus que Clarification ==
Il y a deux flux d’informations-clés dans Scrum qui sont liés au Product Owner : (1) la priorisation (ordonnancement) des éléments dans le Backlog de Produit et (2) la clarification des éléments dans le Backlog de Produit. Dans le premier flux (priorisation), les informations liées aux centres de profits, aux clients stratégiques, aux risques métiers, et à d’autres préoccupations métiers sont recherchées et analysées. Dans le second flux (clarification), l’information est recherchée pour détailler le comportement et les qualités intrinsèques des éléments, l’expérience utilisateur, et à d’autres préoccupations sur la conception des fonctionnalités. 
 
Un Product Owner LeSS porte une réflexion accrue sur la priorisation mais collabore avec les équipes sur la clarification. De plus, il encourage et aide les équipes à entrer en communication directe avec les véritables utilisateurs et clients pour plus de clarification. Il agit en tant que connecteur, pas en tant qu’intermédiaire. 
 
Pourquoi mettre l’emphase sur une interaction directe entre les équipes et les clients/utilisateurs ? Voici quelques raisons : (1) éviter la perte d’informations liée au passage de relais, (2) encourager la co-création de solutions aux problèmes réels des clients, et (3) améliorer la motivation et l’empathie envers les clients en ayant des développeurs qui collaborent directement avec eux. 
 
Il est important de noter que lorsque les équipes font le gros du boulot de clarification, le Product Owner dispose de plus de temps et d’énergie pour se focaliser sur la vision globale, pour prioriser de manière continue et pour explorer de nouvelles opportunités stratégiques. 
 
== Trouver un Product Owner en fonction de votre type de développement ==

=== Étape 1 : connaître votre type de développement ===
Trouver le bon type de Product Owner dépend de la connaissance de votre type de développement :
* '''Développement de produits''' pour des clients externes ou un marché
* '''Développement (de produit) à usage interne''' pour un ou plusieurs utilisateurs à l’intérieur de l’entreprise. Un tel groupe de développement s’appelle généralement Développement des Systèmes d’Informations ou l’Informatique
* '''Développement d’un projet''' généralement pour un client externe. Le travail est organisé et contractualisé sous la forme d’un projet quel qu’il soit bien que cela ne signifie pas pour autant un contrat du projet basée sur le triangle périmètre/date/coût. La société de développement est généralement un prestataire extérieur ou un intégrateur-système. Le client, ou l’entreprise cliente, englobe à la fois l’entité acheteuse et les utilisateurs, qui ne sont pas nécessairement dans le même département. 
 
=== Étape 2 : trouver le bon Product Owner ===
'''Développement de produits''' - l’entreprise aura soit (1) une unité métier pilotant l’initiative produit (exemple : la banque de détails), ou (2) un département de gestion produits pilotant l’initiative. Traditionnellement, la gestion de produits est responsable de l’analyse des clients et de la concurrence, de la vision produit, de la sélection et de la priorisation des fonctionnalités à grosse maille, de la feuille de route produit, ainsi que d’autres activités non techniques. On ne gère pas non plus le travail d’un groupe de développement traditionnel. 
 
Où donc trouver un Product Owner pour un groupe adoptant LeSS ? S’il y a un département de gestion produits alors un responsable produit peut être un bon choix. Sinon, il faut chercher une personne du côté d’une unité métier qui puisse piloter l’initiative. La chose importante à garder à l’esprit est que le Product Owner pour le développement d’un produit devrait venir du côté métier. 
 
'''Développement (de produits) à usage interne''' - un bon Product Owner pour le développement de produits à usage interne dans LeSS est (1) quelqu’un provenant d’un groupe qui utilisera le système, et (2) qui est étroitement impliqué et a une grande expérience sur le boulot réel que le système prendra en charge. Une telle personne est très proche des véritables utilisateurs. 
 
'''Développement d’un projet''' - Ici le point-clé est que le Product Owner vient de l’entreprise qui bénéficiera du système et, comme pour le développement interne, qui est impliqué et dispose d’une grande expérience sur le travail opérationnel, et proche des utilisateurs. 
 
Une variante habituelle à la fois dans le développement à usage interne et dans le développement d’un projet est lorsque le système sera amené à être utilisé par plusieurs départements. Un bon choix est alors de trouver une personne expérimentée au niveau opérationnel provenant de l’un des départements où se trouve les utilisateurs les plus importants et qui est intéressé par prendre le rôle et qui sait naviguer au niveau politique au sein de l’organisation. 
 
L’illustration suivante montre le Product Owner dans différentes organisations : 
 
[[Fichier:Who-is-the-po-fr.jpg.jpg|800px|Qui est le PO]] 
 
Dans tous les cas, un super Product Owner est une personne passionnée par le produit. 
 
Lorsqu’il est impossible de trouver le bon Product Owner immédiatement, vous pouvez tout de même rapidement démarrer une adoption de LeSS avec un Product Owner ''temporaire'' qui soit en mesure de comprendre ce qu’il se passe et prendre en charge les mécanismes du rôle mais qui n’est pas du côté métier. Laissons ensuite les équipes dérouler plusieurs Sprints avec le Product Owner temporaire jusqu’à ce que les problèmes majeurs soient résolus et - c’est important - jusqu’à ce que les équipes de développement puissent livrer un incrément vraiment ‘terminé’, déployable (ou quelque chose d’approchant) à chaque Sprint. Pourquoi ? Les équpes produits trouveront plus probablement et inspireront le bon Product Owner à plus long terme si elles peuvent montrer une nouvelle capacité qui soit attrayante et qui offre un bénéfice métier très tangible. Il est extrêmement important que tout le monde comprenne que le Product Owner temporaire est un bouche-trou. Nous utilisons régulièrement le terme "faux Product Owner" pour indiquer à quel point il peut être dommageable que ce poste de Product Owner temporaire se pérennise. Non seulement parce qu’un faux PO n’est pas le meilleur Product Owner mais également parce qu’il peut provoquer des dégâts en essayant de remplir un rôle pour lequel il n’est pas qualifié. Il doit être remplacé dès que possible pour éviter le risque d'aboutir à la création d’un produit de seconde classe. 
 
=== Étape 3 : donner l’autorité et la responsabilité au vrai Product Owner ===
Le terme Product Owner n’est pas un nouveau nom donné à un responsable de projet traditionnel qui livre le résultat d’un travail basé sur un périmètre et une date contractualisés. Au lieu de cela, un Product Owner est une personne qui doit avoir l’autorité pour choisir et changer le contenu, les dates de livraison, les priorités, la vision, etc. Bien sûr, il collabore avec les parties prenantes, mais un vrai Product Owner est la personne qui détient l’autorité pour la prise de décision finale. 
 
== Cinq types de relations ==
Le Product Owner doit être en mesure de comprendre et travailler pour améliorer les cinq types de relations clés impactées par l’adoption de LeSS :
[[Fichier:Les différents types de relation du Product Owner.png|600px|Les différents types de relation du Product Owner]] 
 
<ul>
<li>'''Product Owner ↔ Équipes'''
Les équipes sont là pour aider le Product Owner à créer le meilleur produit possible pour le client. Elles doivent savoir quoi construire par la suite et si oui ou non ce qu’elles ont déjà réalisé a déjà atteint l'objectif. Le Product Owner doit savoir ce dont les équipes ont besoin et comment il peut être en mesure de les aider.</li>
<li>'''Product Owner ↔ Clients'''
Le Product Owner et les équipes essayent de créer le meilleur produit possible pour le client. Le client a besoin de savoir quand il aura les fonctionnalités qu’il souhaite, et peut être aussi le raisonnement sous-jacent aux priorités. Impliquez-les le plus possible en étant transparent. Le Product Owner doit apprendre leurs véritables objectifs ou problèmes en étant avec eux (ou entrevoir quelque chose au-delà même de leur vision) et collecter l’information qui l'aidera à bien prioriser.</li>
<li>'''Équipes ↔ Clients'''
Les équipes essayent de créer le meilleur produit pour le client. Elles doivent connaître le contexte des fonctionnalités et avoir une connaissance détaillée du domaine. Idéalement, les équipes co-créent les solutions directement avec les clients en capturant l’essence même (plutôt que la surface) des objectifs et des problèmes des clients. Les équipes doivent confirmer avec les clients qu’elles ont bien compris les exigences clarifiées ensemble.</li>
<li>'''Product Owner ↔ Hiérarchie'''
La hiérarchie au-dessus du groupe produit (responsables portefeuilles, cadres dirigeants, etc.) devraient considérer le Product Owner comme étant la personne qui a la responsabilité finale quant à la réussite du produit et qui doit en rendre compte. Il est responsable pour donner de la visibilité sur l'état d'avancement du développement et concrétiser le mandat (peut-être implicite) de la hiérarchie pour optimiser les impacts souhaités (par exemple, le ROI et les parts de marché). Le Product Owner, avec le soutien des Scrum Masters implique la hiérarchie pour aider à améliorer la structure de l’organisation.</li>
<li>'''Product Owner ↔ Scrum Masters'''
Les relations décrites ci-dessus font partie intégrante de l’art d’être Product Owner (ou “product ownership”), mais celle-ci est différente. Elle concerne les connaissances et le comportement du Product Owner. Les Scrum Masters doivent connaître les préoccupations, les questions et les obstacles du Product Owner afin d’être en mesure de l’aider. Un bon Scrum Master doit être une oreille bienveillante ou une épaule amicale sur laquelle pleurer. Les Scrum Masters éduquent et donnent du feedback au Product Owner afin qu’il puisse s’adapter en conséquence.</li></ul>

== Les Réunions LeSS ==
Lorsque nous présentons LeSS, une question qui revient souvent est : "Comment un seul Product Owner peut-il gérer toutes ces réunions avec toutes ces équipes ?". Fort heureusement, l’inquiétude qui se cache derrière cette question est qu’elle est basée en fait sur un malentendu. Le seul et unique Product Owner en LeSS assiste uniquement à des réunions individuelles même si c’est avec plusieurs équipes. Et le nombre d’équipiers dans ces réunions est gérable. S’il y a seulement deux équipes, tout le monde peut effectivement être présent et participer. S’il y a plusieurs équipes, deux représentants seulement de chaque équipe peuvent être présents. 
 
Quelles sont les réunions LeSS auxquelles un Product Owner assiste et quelles sont les durées moyennes dans un Sprint type de deux semaines ?
* [[LeSS_-_La_Planification_du_Sprint_(1ère_partie)|La Planification du Sprint (1ère partie) (fr)]] - 1 heure.
* [[LeSS_-_L%27Affinage_du_Backlog_Produit|L’Affinage Global du Backlog Produit (fr)]] - 4 heures.
* [[LeSS_-_La_Revue_de_Sprint|La Revue de Sprint (fr)]]] - 2 heures.
* [[LeSS_-_La_Rétrospective_Globale|La Rétrospective Globale (fr)]] - 1,5 heure.
Donc le temps total passé dans les évènements LeSS est, en moyenne, d’environ huit heures dans un Sprint de deux semaines. 
 
Le Product Owner ne participe pas aux réunions spécifiques des équipes que sont : [[LeSS_-_La_Planification_du_Sprint_(2ème_partie)|la Planification du Sprint (2ème partie) (fr)]], [[LeSS_-_La_Mêlée_Quotidienne|la Mêlée Quotidienne (fr)]], [[LeSS_-_L%27Affinage_du_Backlog_Produit|les Affinages de backlog faits par les équipes (fr)]], [[LeSS_-_La_Rétrospective|les Rétrospectives des équipes (fr)]].

LeSS - Le Product Owner

2019-06-23T15:53:04Z

Nicolas Mereaux : Page créée avec « Auteur : The LeSS Company B.V. Source : [https://less.works/less/framework/product-owner.html Product Owner (LeSS)] <hr /> Traducteur : [http://www.les-traduct... »

Auteur : The LeSS Company B.V. 
Source : [https://less.works/less/framework/product-owner.html Product Owner (LeSS)] 
<hr />
Traducteur : [http://www.les-traducteurs-agiles.org/traducteurs/ Nicolas Mereaux] 
Date de traduction : 23/06/2019 
<hr />

The Product Owner role in LeSS is conceptually the same as in one-team Scrum. However, at scale the focus changes slightly toward keeping an overview and ensuring the maximum return on investment (ROI) in the product.

Le rôle de Product Owner dans LeSS est conceptuellement le même que celui dans une équipe Scrum solo. Toutefois, à grande échelle la focale change légèrement pour aller vers quelque chose permettant de garder une vision globale et de s’assurer un retour sur investissement (ROI) maximum au niveau du produit.

== Scaled Product Owner ==

== Le Product Owner à grande échelle ==

It’s common in large-scale product development for different people to pull in different directions and for subgroups to focus on local sub-optimizations. Maintaining one Product Owner with one Product Backlog supports [https://less.works/less/principles/whole-product-focus.html whole-product focus].

S’il est une chose assez répandu dans le développement de produit à grande échelle c’est que différentes personnes tirent dans différentes directions et pour des sous-groupes de se focaliser sur des sur-optimisations au niveau local. Avoir un seul Product Owner avec un seul Backlog de Produit permet de maintenir un [http://www.les-traducteurs-agiles.org/2018/10/11/less-focus-sur-le-produit-global.html focus sur le produit global].

In traditional large-scale product groups, there’s a group (often product managers) that focuses outward and a group (usually developers) that focuses inward — and never the twain shall meet. In LeSS, the one Product Owner has lots of free time to focus outward on customers and their priorities while also being able to spend some time looking inwards to the teams. She acts as a connector, bringing teams and customers/users together so the teams become more [https://less.works/less/principles/customer-centric.html customer focused].

Dans les groupes produit à grande échelle rencontrés traditionnellement, nous trouvons d’une part un groupe (souvent des responsables produits - ''product managers'' -) focalisé vers l’extérieur et d’autre part un groupe (généralement les développeurs) focalisé vers l’intérieur - et jamais aucun des deux ne se rejoignent. Dans LeSS, le Product Owner unique dispose de beaucoup de temps pour se focaliser vers l’extérieur - les clients et leurs priorités - tout en étant aussi en capacité de prendre du temps pour se focaliser vers l’intérieur - les équipes. Il agit en tant que connecteur, faisant se réunir ensemble les équipes et les clients/utilisateurs afin que les équipes deviennent encore plus [orientées clients]https://less.works/less/principles/customer-centric.html).

In contrast with other scaled Scrum approaches, it’s possible in LeSS to effectively scale the Product Owner role with just one person because there are fewer roles and positions, and less complexity.

Par rapport à d’autres approches de Scrum à grande échelle, il est possible avec LeSS de passer à grande échelle le rôle de Product Owner avec une seule personne parce qu’il y a moins de rôles, de positions et moins de complexité.

== Prioritization over Clarification ==

== Priorisation plus que clarification ==

There are two key information flows in Scrum related to the Product Owner: (1) prioritizing (ordering) items in the Product Backlog and (2) clarifying items in the Product Backlog. In the first flow (prioritization), information related to profit drivers, strategic customers, business risks, and other business concerns is sought and analyzed. In the second flow (clarification), information is sought to detail the behavior and qualities of items, the user experience, and other feature design concerns.

Il y a deux flux d’informations-clés dans Scrum liés au Product Owner : (1) la priorisation (ordonnancement) des éléments dans le Backlog de Produit et (2) la clarification des items dans le Backlog de Produit. Dans le premier flux (priorisation), les informations liées aux centres de profits, aux clients stratégiques, aux risques métiers, et à d’autres préoccupations business sont recherchées et analysées. Dans le second flux (clarification), l’information est recherchée pou détailler le comportement et les qualités intrinsèques des items, l’expérience utilisateur, et à d’autres préoccupations sur la conception des fonctionnalités.

A LeSS Product Owner focuses on thinking hard about prioritization but collaborates with the teams on clarification. Further, she encourages and helps the teams enter into a direct conversation with true users and customers for clarification. She acts as a connector, not an intermediary.

Un Product Owner LeSS porte une réflexion accrue sur la priorisation mais collabore avec les équipes sur la clarification. De plus, il encourage et aide les équipes à entrer en communication directe avec les vrais utilisateurs et les vrais clients pour plus de clarification. Il agit en tant que connecteur, pas en tant qu’intermédiaire.

Why emphasize direct interaction between teams and customers/users? Reasons include: (1) avoiding information loss from handoffs, (2) fostering co-creation of solutions to real customer problems, and (3) improving motivation and empathy for customers by having developers collaborate with them directly.

Pourquoi mettre l’emphase sur une interaction directe entre les équipes et les clients/utilisateurs ? Voici quelques raisons : (1) éviter la perte d’informations par le passage de relais, (2) encourager la co-création de solutions aux problèmes des vrais clients, et (3) améliorer la motivation et l’empathie envers les clients en ayant des développeurs qui collaborent directement avec eux.

It’s worth noting that when the teams do most of the clarification work the Product Owner has more time and energy to focus on the big picture, continuously prioritizing and exploring new and strategic opportunities.

Il est important de noter que lorsque les équipes font le gros du boulot de clarification, le Product Owner dispose de plus de temps et d’énergie pour se focaliser sur la vision globale, pour prioriser de manière continue et pour explorer de nouvelles opportunités ou stratégiques.

== Find a Product Owner Given Your Type of Development ==

== Trouver un Product Owner selon votre type de développement ==

=== Step 1: Know Your Development Type ===

=== Étape 1 : connaître votre type de développement ===

Finding the right Product Owner depends on knowing the type of development you are doing:

Trouver le bon type de Product Owner dépend de la connaissance du type de développement que vous faîtes :

* '''Product development'''—For external customers or a market.
* '''Internal (product) development'''—For one or more users within the company. The development group is usually called IT or Systems Development.
* '''Project development'''—Usually for one external customer. The work is organized and contracted as a project of some kind although that does not necessarily mean a fixed scope/date/cost project contract. The development company is usually an outsourcer or systems-integrator. The customer, or client company, includes both the purchasing entity and the users, who are not always in the same department.
* '''Développement de produits''' pour des clients externes ou un marché
* '''Développement (de produit) à usage interne''' pour un ou plusieurs utilisateurs à l’intérieur de l’entreprise. Un tel groupe de développement s’appelle généralement Développement des Systèmes d’Informations ou l’Informatique
* '''Développement d’un projet''' généralement pour un client externe. Le travail est organisé et contractualisé sous la forme d’un projet quel qu’elle soit bien que cela ne signifie pas pour autant un contrat pour le projet avec un(e) périmètre/date/coût fixe. L’entreprise de développement est généralement un prestataire extérieur ou un intégrateur-système. Le client, ou l’entreprise cliente, englobe à la fois l’entité acheteuse et les clients, qui ne sont pas nécessairement dans le même département.

=== Step 2: Finding the right Product Owner ===

=== Étape 2 : trouver le bon Product Owner ===

'''Product development'''—The company will have either (1) a business unit driving the product initiative (e.g., Retail Banking), or (2) a Product Management department driving the initiative. Traditional Product Management is responsible for customer and competitor analysis, product vision, coarse-grained feature selection and prioritization, product roadmap, and other non-technical activities. They don’t manage the work of a traditional development group.

'''Développement de produits''' - l’entreprise aura soit (1) une unité opérationnelle métier pilotant l’initiative produit (exemple : la banque de détails), ou (2) un département de gestion produits pilotant l’initiative. Traditionnellement, la gestion de produits est responsable de l’analyse des clients et de la concurrence, de la vision produit, de la sélection et de la priorisation des fonctionnalités à grosse maille, de la feuille de route produit, ainsi que d’autres activités non techniques. Il ne gère pas non plus le travail d’un groupe de développement traditionel.

Where to find a Product Owner for a group adopting LeSS? If there’s a Product Management department, then a Product Manager can be a good choice. Otherwise, look for a person from the business unit that’s driving the initiative. The important thing to keep in mind is that the Product Owner for product development should come from the business side.

Où donc trouver un Product Owner pour un groupe adoptant LeSS ? S’il y a un département de gestion produits alors un responsable produit peut être un bon choix. Sinon, il faut chercher une personne du côté d’une unité opérationnelle métier qui puisse piloter l’initiative. La chose importante à garder à l’esprit est que le Product Owner pour le développement d’un produit devrait venir du côté métier.

'''Internal (product) development'''—A good Product Owner for internal product development in LeSS is (1) from within the group that will use the system, and (2) is closely involved in and deeply experienced in doing the real work that the system will support. They are very close to the real users.

'''Développement (de produits) à usage interne''' - un bon Product Owner pour le développement de produits à usage interne dans LeSS est (1) quelqu’un provenant d’un groupe qui utilisera le système, et (2) est étroitement impliqué et a une grande expérience sur le boulot réel que le système prendra en charge. Une telle personne est très proche des vrais utilisateurs.

'''Project development'''—The key point is that a Product Owner is from the company receiving the system and, as with internal development, is involved in and deeply experienced in the hands-on work, close to users.

'''Développement d’un projet''' - Ici le point-clé est que le Product Owner vient de l’entreprise qui bénéficiera du système et, comme pour le développement interne, qui est impliqué et dispose d’une grande expérience sur le travail opérationnel, et proche des utilisateurs.

A common variant for both internal and project development is when the system will be used by many departments. Then, a good choice is an experienced, hands-on individual from one of the major user departments who is interested in taking on the role and has political savvy.

Une variante que l’on rencontre habituellement à la fois dans le développement à usage interne et dans le développement d’un projet est lorsque le système sera amené à être utilisé par plusieurs départements. Un bon choix est alors de trouver un individu expérimenté au niveau opérationnel provenant de l’un des départements où se trouve les utilisateurs les plus importants et qui est intéressé par prendre le rôle et qui sait naviguer au niveau politique au sein de l’organisation.

The following figure shows the Product Owner in different organizations:

L’illustration suivante montre le Product Owner dans différentes organisations :

<figure class>
[[File:https://less.works/img/framework/who-is-the-product-owner-in-different-types-of-development.png.pagespeed.ce.yMQPDhMzEA.png|Who is the Product Owner in Different Types of Development]]
<figcaption>
[https://less.works/img/framework/who-is-the-product-owner-in-different-types-of-development.png [Download PNG]]

[[Fichier:Who-is-the-po-fr.jpg.jpg|600px|Qui est le PO]]

In all cases, a great Product Owner has a passion for the product.

Dans tous les cas, un grand Product Owner est une personne ayant une passion pour le produit.

When it is impossible to find the right Product Owner immediately, you can quickly start a LeSS adoption with a ''temporary'' Product Owner who understands what’s going on and can perform the mechanics of the role but is not from the business side. Let the teams complete several Sprints under the temporary Product Owner until the major kinks are worked out and — this is important — the development teams can deliver a truly ‘done’, shippable increment (or something close) every Sprint. Why? The product teams will be more likely to find and inspire the right longterm Product Owner if they can show a compelling new capability that offers very tangible business benefit. It’s terribly important that everyone understand that the temporary Product Owner is a placeholder. We often use the term “fake Product Owner” to indicate just how damaging this temporary Product Owner can be. Because the fake PO is not only not the best Product Owner but also she can cause damage trying to fill a role for which she is not qualified. She must be replaced as soon as possible to avoid the risk of creating a second-class product.

Lorsqu’il est impossible de trouver le bon Product Owner immédiatement, vous pouvez tout de même démarrer une adoption de LeSS avec un Product Owner ''temporaire'' qui soit en mesure de comprendre ce qu’il se passe et prendre en charge les mécanismes du rôle mais qui n’est pas du côté métier. Laissons ensuite les équipes dérouler plusieurs Sprints avec le Product Owner temporaire jusqu’à ce que les problèmes majeurs soient résolus et - c’est important - jusqu’à ce que les équipes de développement puissent livrer un incrément vraiment ‘terminé’, livrable (ou quelque chose d’approchant) à chaque Sprint. Pourquoi ? Les équpes produits trouveront plus probablement et inspireront le bon Product Owner à plus long terme si elles peuvent montrer une nouvelle capacité qui soit attrayante et qui offre un bénéfice métier très tangible. Il est - terriblement - important que tout le monde comprenne que le Product Owner temporaire est un bouche-trou. Nous utilisons régulièrement le terme “faux Product Owner” pour indiquer à quel point il peut être dommageable que ce poste de Product Owner temporaire se pérénise. Non seulement parce qu’un faux PO n’est pas le meilleur Product Owner mais également parce qu’il peut provoquer des dégâts en essayant de remplir un rôle pour lequel il n’est pas qualifié. Il doit être remplacé dès que possible pour éviter le risque de voir aboutir à la création d’un produit de seconde classe.

=== Step 3: Give Authority and Responsibility to a Real Product Owner ===

=== Étape 3 : donner l’autorité et la responsabilité au vrai Product Owner ===

Product Owner is not a new name for a traditional project manager who delivers a scope and date contract of work. Rather, a Product Owner must have the independent authority to choose and change content, release dates, priorities, vision, etc. Of course she collaborates with stakeholders, but a real Product Owner has final decision-making authority.

Le terme Product Owner n’est pas un nouveau nom donné à un responsable de projet traditionnel dont le travail est de livrer le résultat d’un travail basé sur un périmètre et une date donnée contractualisés. Au lieu de cela, un Product Owner est une personne qui doit avoir l’autorité pour choisir et changer le contenu, les dates de livraisosn, les priorités, la vision, etc. Bien sûr, il collabore avec les parties prenantes, mais un vrai Product Owner est la personne qui détient l’autorité pour la prise de décision finale.

== Five Relationships ==

== Cinq types de relations ==

The Product Owner needs to understand and work to improve five key relationships that are affected by LeSS adoption:

Le Product Owner doit être en mesure de comprendre et travailler pour améliorer les cinq types de relations clés impactées par l’adoption de LeSS :

<figure class>
[[File:https://less.works/img/framework/xproduct-owner-relationships.png.pagespeed.ic.xwDr0aHR79.webp|Product Owner Relationships]]
<figcaption>
[https://less.works/img/framework/product-owner-relationships.pdf [Download PDF]]

[[Fichier:Les différents types de relation du Product Owner.png|600px|Les différents types de relation du Product Owner]]

<ul>
<li>'''Product Owner<–>Teams'''</li>
<li>'''Product Owner <-> équipes'''
The teams are there to help the Product Owner create the best possible product for the customer. They need to know what to build next and whether or not what they have already built has hit the mark. The Product Owner needs to know what the teams need and how she can help them.
Les équipes sont là pour aider le Product Owner à créer le meilleur produit possible pour le client. Elles doivent savoir quoi construire par la suite et si oui ou non ce qu’elles ont déjà réalisé a déjà fait mouche. Le Product Owner doit savoir ce dont les équipes ont besoin et comment il peut être en mesure de les aider.</li>
<li>'''Product Owner<–>Customers'''</li>
<li>'''Product Owner <-> Clients'''
The Product Owner and teams are trying to create the best possible product for the customer. The customer needs to know when they will have features they care about, and perhaps the reasoning behind the priorities. Involve them as much as possible by being transparent. The Product Owner needs to learn their real goals or problems with them (or envision something beyond their vision) and collect the information that will help him prioritize well.
Le Product Owner et les équipes essayent de créer le meilleur produit possible pour le client. Le client a besoin de savoir lorsqu’il aura les fonctionnalités qu’il souhaite, et peut être aussi quelles sont les raisons sous-jacentes aux priorités. Impliquez-les le plus possible en étant transparent. Le Product Owner doit apprendre leurs vrais objectifs ou leurs vrais problèmes avec eux (ou prévoir quelque chose au-delà de leur vision) et collecter l’information qui les aidera à bien prioriser.</li>
<li>'''Teams<–>Customers'''</li>
<li>'''équipes <-> clients'''
The teams are trying to create the best possible product for the customer. They need to know the context for features and have detailed domain knowledge. Ideally, teams co-create solutions directly with customers by grasping the customers’ essential (rather than superficial) goals and problems. Teams need to confirm with customers that they fully understand the requirements they are clarifying together.
Les équipes essayent de créer le meilleur produit pour le client. Elles doivent connaître le contexte des fonctionnalités et avoir une connaissance détaillée du domaine. Idéalement, les équipes co-créent les solutions directement avec les clients en capturant l’essence même (plutôt que le seul côté superficiel) des objectifs et des problèmes des clients. Les équipes doivent confirmer avec les clients qu’elles ont bien compris les exigences clarifiées ensemble.</li>
<li>'''Product Owner<–>Higher Management'''</li>
<li>'''Product Owner <-> encadrement plus haut dans la hiérarchie'''
Higher management beyond the product group (portfolio managers, C-level executives, etc.) should view the Product Owner as having the final accountability and responsibility for product success. She is responsible for making the development status visible and realizing higher management’s (perhaps implicit) mandate to optimize desired impacts (e.g., ROI and market share). The Product Owner, with support from Scrum Masters, engages higher management’s help to improve the organizational design.
Les supérieurs hiérarchiques au-dessus du groupe produit (responsables portefeuilles, cadres dirigeants, etc.) devraient considérer le Product Owner comme étant la personne qui a la responsabilité finale quant à la réussite du produit et qui doit en rendre compte. Il est responsable pour rendre le statut du développement visible et concrétiser le mandat des supérieurs hiérarchiques (qui est peut être implicite) pour optimiser les impacts souhaités (par exemple, le ROI et la part de marché). Le Product Owner, avec le support des Scrum Masters implique ces supérieurs hiérarchiques dans l’aide qu’ils peuvent apporter pour améliorer la structure de l’organisation.</li>
<li>'''Product Owner<->Scrum Masters'''</li>
<li>'''Product Owner <-> Scrum Masters'''
The relationships above are directly related to “product ownership,” but this one is different. It relates to Product Owner knowledge and behavior. The Scrum Masters need to know the Product Owner’s concerns, questions, and obstacles so they can help. A good Scrum Master can be a friendly ear or a shoulder to cry on. Scrum Masters educate and feed back so Product Owners can adapt.
Les relations décrites ci-dessus font partie intégrante de l’art d’être Product Owner (ou “product ownership”), mais celle-ci est différente. Elle concerne les connaissances et le comportement du Product Owner. Les Scrum Masters doivent connaître les préoccupations, les questions et les obstacles du Product Owner afin d’être en mesure de l’aider. Un bon Scrum Master doit être une oreille bienveillante ou une épaule amicale sur laquelle pleurer. Les Scrum Masters éduquent et donnent des retours d’informations au Product Owner afin qu’il puisse s’adapter en conséquence.</li></ul>

== LeSS Meetings ==

== Les réunions LeSS ==

When we introduce LeSS, a frequent question is, “How is one Product Owner going to manage all of those meetings with all of those teams?” Fortunately, the concern behind that question is based on a misunderstanding. The one Product Owner in LeSS only attends single meetings even though there are multiple teams. And the number of team members at those single meetings is manageable. If there are just two teams, everyone can effectively attend and participate. If there are many teams, only two representatives from each team may attend.

Lorsque nous présentons LeSS, une question qui revient souvent est : “Comment un seul Product Owner peut-il gérer toutes ces réunions avec toutes ces équipes ?”. Fort heureusement, l’inquiétude qui se cache derrière cette question est qu’elle est basée en fait sur un malentendu. Le seul et unique Product Owner en LeSS assiste uniquement à des réunions individuelles même si c’est avec plusieurs équipes. Et le nombre d’équipiers dans ces réunions est gérable. S’il y a seulement deux équipes, tout le monde peut effectivement être présent et participer. S’il y a plusieurs équipes, deux représentants seulement de chaque équipe peut être présent.

What LeSS meetings does the Product Owner attend and what is their average duration in a typical two-week Sprint?

Quelles sont les réunions LeSS auxquelles un Product Owner assiste et quelles sont les durées moyennes dans un Sprint type de deux semaines ?

* [https://less.works/less/framework/sprint-planning-one.html Sprint Planning One] - 1 hour.
* [https://less.works/less/framework/product-backlog-refinement.html Overall Product Backlog Refinement (PBR)] - 4 hours
* [https://less.works/less/framework/sprint-review.html Sprint Review] - 2 hours.
* [https://less.works/less/framework/overall-retrospective.html Overall Retrospective] - 1.5 hours.

---

* [http://www.les-traducteurs-agiles.org/2017/03/09/less-la-planification-du-sprint-1ere-partie.html La Planification du Sprint (1ère partie)] - 1 heure.
* [http://www.les-traducteurs-agiles.org/2018/01/26/less-l-affinage-du-backlog-produit.html L’Affinage du Backlog Produit] - 4 heures
* [http://www.les-traducteurs-agiles.org/2017/08/30/less-la-revue-de-sprint.html La Revue de Sprint] - 2 heures.
* [http://www.les-traducteurs-agiles.org/2017/04/13/less-la-retrospective-globale.html La Rétrospective Globale] - 1.5 heures.

So the total time spent in LeSS events is, on average, about eight hours in a two-week Sprint.

Donc le temps total passé dans les évènements LeSS est, en moyenne, d’environ huit heures dans un Sprint de deux semaines.

The Product Owner does not attend the team-specific meetings: [https://less.works/less/framework/sprint-planning-two.html Sprint Planning Two], [https://less.works/less/framework/daily-scrum.html Daily Scrums], [https://less.works/less/framework/product-backlog-refinement.html team PBRs], [https://less.works/less/framework/retrospective.html team Retrospectives].

Le Product Owner ne participe pas aux réunions spécifiques d’équipe que sont : [http://www.les-traducteurs-agiles.org/2017/03/10/less-la-planification-du-sprint-2eme-partie.html La Planification du Sprint (2ème partie)], [http://www.les-traducteurs-agiles.org/2017/04/17/less-la-melee-quotidienne.html La Mêlée Quotidienne], [http://www.les-traducteurs-agiles.org/2018/01/26/less-l-affinage-du-backlog-produit.html les affinages de backlog faits par l’équipe], [http://www.les-traducteurs-agiles.org/2017/04/15/less-la-retrospective.html les rétrospectives d’équipe].

Fichier:Who-is-the-po-fr.jpg.jpg

2019-06-23T15:47:58Z

Nicolas Mereaux :

Fichier:Les différents types de relation du Product Owner.png

2019-06-23T15:38:23Z

Nicolas Mereaux :

Les différents types de relation du Product Owner

Catégorie:Portail LeSS

2019-06-23T15:09:49Z

Nicolas Mereaux :

<addthis />
[[Catégorie: Portails Thématiques]]
[[Category: Agilité à grande échelle]]
[[Fichier:LeSS-logo 72.png]] À la découverte de LeSS, ce framework de mise à l'échelle de l'élégance de Scrum. 
[[Image:LeSS-overview-diagram_fr.png|LeSS-overview-diagram_fr.png]] [http://less.works/less/framework/introduction.html introduction] '''''"Depuis 2005, nous avons travaillé avec des clients pour mettre en oeuvre le framework LeSS (Large-Scale Scrum) de mise à l'échelle du développement Scrum, agile et lean pour les groupes produit de grande taille. Nous partageons cette connaissance à travers LeSS pour que, vous aussi, vous puissiez réussir lorsque vous passez à l'échelle."''''' - Craig Larman & Bas Vodde '''Articles thématiques''' 
----

* '''[[LeSS%20-%20Portail%20Framework|Portail Framework LeSS (fr)] - 95%]]'''
** [http://less.works/less/framework/introduction.html Introduction à LeSS]
** [[Pourquoi%20LeSS%20%3F|Pourquoi LeSS (fr)]]
** [[LeSS%20-%20Le%20Produit|Le Produit (fr)]]
** [[LeSS%20-%20Le%20Product%20Owner|Le Product Owner (fr)]]
** [[LeSS%20-%20Le%20backlog%20du%20produit|Le Backlog du Produit (fr)]]
** [[LeSS%20-%20Les%20%C3%89quipes|Les Équipes (fr)]]
** [[LeSS%20-%20Le%20Sprint|Le Sprint (fr)]]
** [[LeSS%20-%20La%20Planification%20du%20Sprint%20%281%C3%A8re%20partie%29|La Planification du Sprint (1ère partie) (fr)]]
** [[LeSS%20-%20La%20Planification%20du%20Sprint%20%282%C3%A8me%20partie%29|La Planification du Sprint (2ème partie) (fr)]]
** [[LeSS%20-%20Le%20Backlog%20du%20Sprint|Le Backlog du Sprint (fr)]]
** [[LeSS%20-%20La%20M%C3%AAl%C3%A9e%20Quotidienne|La Mêlée Quotidienne (fr)]]
** [[LeSS%20-%20Coordination%20%26%20Int%C3%A9gration|Coordination & Intégration (fr)]]
** [[LeSS%20-%20L%27Incr%C3%A9ment%20Produit%20Potentiellement%20D%C3%A9ployable|L'Incrément Produit Potentiellement Déployable (fr)]]
** [[LeSS%20-%20La%20D%C3%A9finition%20du%20Fini|La Définition du Fini (fr)]]
** [[LeSS%20-%20La%20Revue%20de%20Sprint|La Revue de Sprint (fr)]]
** [[LeSS%20-%20La%20R%C3%A9trospective|La Rétrospective (fr)]]
** [[LeSS%20-%20La%20R%C3%A9trospective%20Globale|La Rétrospective Globale (fr)]]
** [[LeSS%20-%20L%27Affinage%20du%20Backlog%20Produit|L'Affinage du Backlog Produit (fr)]]
** [[LeSS%20-%20L%27Affinage%20Initial%20du%20Backlog%20Produit|L'Affinage Initial du Backlog Produit (fr)]]
** [[LeSS%20-%20Le%20ScrumMaster|Le ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20Principes|Portail Principes (fr)] - 63%]]'''
** [[LeSS%20-%20Pr%C3%A9sentation%20des%20principes|Présentation des principes (fr)]]
** [[LeSS%20-%20Scrum%20%C3%A0%20grande%20%C3%A9chelle%20reste%20du%20Scrum|Scrum à grande échelle reste du Scrum (fr)]]
** [[Less_-_Plus_avec_LeSS|Plus avec LeSS (fr)]]
** [http://less.works/less/principles/lean-thinking.html Pensée Lean]
** [http://less.works/less/principles/systems_thinking.html Approche systémique]
** [[LeSS%20-%20Contr%C3%B4le%20du%20processus%20empirique|Contrôle du processus empirique (fr)]]
** [[LeSS%20-%20Transparence|Transparence (fr)]]
** [http://less.works/less/principles/continuous-improvement-towards-perfection.html Amélioration continue vers la perfection]
** [[Less_-_Centré_client|Centré client (fr)]]
** [[Less_-_Focus_sur_le_produit_global|Focus sur le produit global (fr)]]
** [https://less.works/less/principles/queueing_theory.html Théorie des files d'attente]
 

* '''[[LeSS%20-%20Portail%20Structure|Portail Structure (fr)]] - 100%'''
** [[LeSS%20-%20Equipes|Equipes (fr)]]
** [[LeSS%20-%20Organisation%20en%20fonction%20de%20la%20valeur%20client|Organisation en fonction de la valeur client (fr)]]
** [[LeSS%20-%20Equipes%20Feature|Equipes Feature (fr)]]
** [[LeSS%20-%20Structure%20organisationnelle|Structure organisationnelle (fr)]]
** [[LeSS%20-%20Communaut%C3%A9s|Communautés (fr)]]
** [[LeSS%20-%20ScrumMaster|ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20Excellence%20technique|Portail Excellence Technique (fr)]] - 30%'''
** [[LeSS%20-%20Sp%C3%A9cifications%20par%20l%27exemple|Spécifications par l'exemple (fr)]]
** [[Less - Intégration continue|Intégration Continue (fr)]]
** [https://less.works/less/technical-excellence/continuous-delivery.html Livraison Continue]
** [[LeSS - Tests d'Acceptation|Tests d'Acceptation (fr)]]
** [http://less.works/less/technical-excellence/architecture-design.html Architecture & Conception]
** [http://less.works/less/technical-excellence/clean-code.html Ecrire du Code Propre]
** [http://less.works/less/technical-excellence/unit-testing.html Tests unitaires]
** [http://less.works/less/technical-excellence/test-driven-development.html Développement piloté par les tests]
** [http://less.works/less/technical-excellence/thinking-about-testing.html Réflexions à propos des tests]
** [http://less.works/less/technical-excellence/test-automation.html Automatisation des tests]
 

* '''[[LeSS%20-%20Portail%20Management|Portail Management (fr)]] - 100%'''
** [[LeSS%20-%20R%C3%B4le%20du%20Manager|Rôle du Manager (fr)]]
** [[LeSS%20-%20Enseigner%20la%20r%C3%A9solution%20de%20probl%C3%A8me|Enseigner la résolution de problème (fr)]]
** [[LeSS%20-%20Aller%20Voir|Aller Voir (fr)]]
** [[LeSS%20-%20Auto-gestion|Auto-gestion (fr)]]
** [[LeSS%20-%20Service%20d%27am%C3%A9lioration|Service d'amélioration (fr)]]
** [[LeSS%20-%20Le%20Manager%20en%20tant%20que%20ScrumMaster|Le Manager en tant que ScrumMaster (fr)]]
 

* '''[[LeSS%20-%20Portail%20LeSS%20Huge|Portail Less Huge (fr)]] - 100%'''
** [[LeSS%20-%20Domaines%20d%27exigences|Domaines d'Exigences (fr)]]
** [[LeSS%20-%20Backlog%20Produit%20de%20Domaine|Backlog Produit de Domaine (fr)]]
** [[LeSS%20-%20Product%20Owner%20de%20Domaine|Product Owner de Domaine (fr)]]
** [[LeSS%20-%20Structure%20organisationnelle%20pour%20LeSS%20Huge|Structure organisationnelle pour LeSS Huge (fr)]]
 

* '''[[LeSS%20-%20Portail%20Adoption|Portail Adoption (fr)]] - 100%'''
** [[LeSS%20-%20Les%20trois%20principes|Trois principes (fr)]]
** [[LeSS%20-%20D%C3%A9marrer|Démarrer (fr)]]
** [[LeSS%20-%20Coaching|Coaching (fr)]]
** [[LeSS%20-%20Am%C3%A9lioration%20continue|Amélioration Continue (fr)]]
** [[LeSS%20-%20Sch%C3%A9ma%20d%27adoption%20des%20%C3%A9quipes%20feature|Schéma d'adoption des équipes feature (fr)]]
** [[LeSS%20-%20Rester%20sain%20d%27esprit|Rester sain d'esprit (fr)]]
 

* '''LeSS Test'''
** [http://less.works/less/test/pre-course.html LeSS Test]
** [http://less.works/less/test/scrum.html Scrum Test]

LeSS - Tests d'Acceptation

2019-01-08T22:11:36Z

Nicolas Mereaux : Page créée avec « Auteur : The LeSS Company B.V. Source : [https://less.works/less/technical-excellence/acceptance-testing.html Acceptance Testing] <hr/> Traducteur : Nicolas Mereaux Re... »

Auteur : The LeSS Company B.V.

Source : [https://less.works/less/technical-excellence/acceptance-testing.html Acceptance Testing]

<hr/>

Traducteur : Nicolas Mereaux

Relecture : Fabrice Aimetti

Date : /01/2018

<hr/>
Traduction :

== Don’t confusing acceptance and user-acceptance test ==

== Ne confondez pas tests d'acceptation et tests d'acceptation utilisateur ==

In the ideal situation, acceptance test and user-acceptance test are the same, but… Agile development literature uses the term “acceptance tests,” where we use the term “customer-facing tests.” However, in traditional development, “acceptance test” often means “user-acceptance test,” which might be different. Avoid misunderstandings.

Dans l'idéal, les tests d'acceptation et les tests d'acceptation utilisateur sont identiques, mais … la littérature du développement Agile utilise le terme de « tests d'acceptation » là où nous utilisons le terme de « tests orientés utilisateur ». Toutefois, en développement traditionnel, les « tests d'acceptation » veulent souvent dire « tests d'acceptation utilisateur » ce qui pourrait s'avérer différents. Évitons donc les malentendus.

[[Fichier:Less-xacceptance vs uat-en.png|vignette|UAT is a subset of acceptance tests]]

[[Fichier:Less-xacceptance vs uat-fr.png|vignette|Les tests d'acceptation utilisateur sont un sous-ensemble des tests d'acceptation]]

Diagram 1: UAT is a subset of acceptance tests

Illustration 1 : Les tests d'acceptation utilisateur sont un sous-ensemble des tests d'acceptation

The above figure expresses the relationship in a diagram. User-acceptance test (UAT) is a part of acceptance testing in agile development. But acceptance test might also include non-UAT tests such as traditional functional or system test created by the team.

L'illustration ci-dessus montre ce qui relie ces 2 types de tests. Les tests d'acceptation utilisateur (TAU) ne sont qu'une partie des tests d'acceptation en développement agile. Mais les tests d'acceptation peuvent aussi inclure des tests qui ne soient pas des tests d'acceptations utilisateur tel que les traditionnels tests fonctionnels ou les tests systèmes faits par l'équipe.

Ideally, all the acceptance testing—including UAT—is done within the iteration. However, getting the UAT in the iteration may be difficult because it requires active end-user involvement and not all customers are ready for that. In that case, UAT is excluded from the Definition of Done until the product group improves their relationship with the customer so that they can expand their Definition of Done.

Idéalement, tous les tests d'acceptation - y compris les tests d'acceptation utilisateurs - sont faits dans l'itération. Toutefois, faire les tests d'acceptation utilisateur dans l'itération peut s'avérer difficile parce que cela demande une implication active de l'utilisateur final et tous les utilisateurs finaux ne sont pas prêts à ça. Dans ce cas, les tests d'acceptation utilisateur sont exclus de la Définition du Fini jusqu'à ce que le groupe produit améliore sa relation avec l'utilisateur final afin qu'il puisse étendre sa Définition du Fini.

== Show tests in Sprint Review ==

== Montrer les tests en Revue de Sprint ==

In a [https://less.works/less/framework/sprint-review.html Sprint Review], the team demonstrates visible progress to the Product Owner by showing the output of the iteration.

Lors d'une [[LeSS - La Revue de Sprint|Revue de Sprint]], l'équipe montre des avancées visibles au Product Owner en montrant ce qui a été produit pendant l'itération.

We worked with some groups that defined the demo steps during the Sprint planning. The team would spend an inordinate amount of time in demo preparation. A complete waste.

Certains des groupes avec lesquels nous avons travaillé préparaient à l'avance les différentes étapes pendant la Planification de Sprint. Dans ces cas-là, l'équipe passe un temps démesuré en préparation de démo. Un véritable gâchis.

During [https://less.works/less/framework/sprint-planning-one.html Sprint Planning], an alternative is to define the examples that need to pass and show the progress by using these tests in the Sprint Review.

Lors de la [[LeSS - La Planification du Sprint (1ère partie)|Planification du Sprint]], une alternative possible est de définir les exemples passants et montrer l'avancement des travaux en utilisant ces tests lors de la Revue du Sprint.

== Use acceptance test-driven development ==

== Utiliser le développement piloté par les tests d'acceptation ==

[https://less.works/less/technical-excellence/specification-by-example.html Acceptance test-driven development (A-TDD) or Specification by Example] is a collaborative requirements discovery approach where examples and automatable tests are used for specifying requirements—creating executable specifications. These are created with the team, Product Owner, and other stakeholders in requirements workshops.

[[LeSS - Spécifications par l'exemple|Le développment piloté par les tests d'acceptation (A-TDD) ou Spécifications par l'exemple]] est une approche collaborative de découverte des exigences dans laquelle des exemples et des tests automatisés sont utilisés pour spécifier les exigences, créant ainsi des spécifications exécutables. Elles sont créées conjointement par l'équipe, le Product Owner, et les autres parties prenantes lors d'ateliers d'exigences.

Fichier:Less-xacceptance vs uat-fr.png

2019-01-08T21:59:56Z

Nicolas Mereaux :

schéma tests d'acceptation en français