« LeSS - Approche systémique » : différence entre les versions

De Wiki Agile
← Modification précédenteModification suivante →
VisuelWikicode
Ligne 254 : Ligne 254 :


== Voir les modèles mentaux ==
== 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.


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


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.
''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 ? »
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 :
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.''


[[File:https://less.works/img/systems-thinking/xsystems,P20thinking-17.png.pagespeed.ic.5UIqBnJfK1.webp|frame|none|alt=|caption systems thinking-17.png]]
=== Exemple : La dynamique "Aller plus vite c’est aller plus lentement" ===
Visualizing the assumptions in our heads… our mental models.
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 :
 
[[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.
''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.


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


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:https://less.works/img/systems-thinking/xsystems,P20thinking-18.png.pagespeed.ic.A7OSuu755I.webp|frame|none|alt=|caption systems thinking-18.png]]
[[File:Xsystems-thinking-18-fr.png|border|848px|link=]]
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.''
''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.
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.
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 …
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]]
[[File:Xsystems-thinking-19-fr.png|border|848px|link=]]
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ète.''
''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.
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.


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.
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.
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.
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 ==
== Voir (et entendre) l’optimisation locale ==
Récupérée de "https://wikiagile.coach/LeSS_-_Approche_systémique"