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

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

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

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

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

'''Solutions de contournement''' : une solution payante à long terme pour atteindre une vélocité plus grande, mais 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 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.

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

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

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

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