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

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

'''Constraints'''—Unless you can find people to work for free, there is a constraint on the number of developers, based upon cash supply.

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

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

 

[[File:Xsystems-thinking-14-fr.png|frameless|848px|11ème schéma]]

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