« Usines à Fonctionnalités vs Générateurs de Valeur » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 48 : | Ligne 48 : | ||
<br/> | <br/> | ||
Les managers peuvent désormais se consacrer à l'important travail d'optimisation des résultats par rapport aux moyens mis en œuvre. Vous pouvez voir les résultats tout autour de vous. Certaines optimisations, telles que le cloud computing et la programmation par binôme, sont judicieuses. D'autres, comme les open space et les évaluations des performances, ont un impact plus discutable. Mais la plus grande innovation en matière de productivité est peut-être venue des ingénieurs eux-mêmes. Le développement Agile a été inventé pour remplacer la gestion de projet classique en cascade par une approche légère et itérative de la création de logiciels. Cependant, les consultants ont progressivement appris qu'ils pouvaient mieux vendre le développement agile en le présentant comme un booster de productivité - plus de code mis en production en moins de temps et d'efforts. Ce fut un succès retentissant. Aujourd'hui, je constate une forte corrélation entre la focalisation sur les résultats et les mises en œuvre maladroites de Scrum et SAFe.<br/> | Les managers peuvent désormais se consacrer à l'important travail d'optimisation des résultats par rapport aux moyens mis en œuvre. Vous pouvez voir les résultats tout autour de vous. Certaines optimisations, telles que le cloud computing et la programmation par binôme, sont judicieuses. D'autres, comme les open space et les évaluations des performances, ont un impact plus discutable. Mais la plus grande innovation en matière de productivité est peut-être venue des ingénieurs eux-mêmes. Le développement Agile a été inventé pour remplacer la gestion de projet classique en cascade par une approche légère et itérative de la création de logiciels. Cependant, les consultants ont progressivement appris qu'ils pouvaient mieux vendre le développement agile en le présentant comme un booster de productivité - plus de code mis en production en moins de temps et d'efforts. Ce fut un succès retentissant. Aujourd'hui, je constate une forte corrélation entre la focalisation sur les résultats et les mises en œuvre maladroites de Scrum et SAFe.<br/> | ||
==Des fissures importantes dans le modèle== | |||
En théorie, le modèle de l'usine à fonctionnalités est tout à fait logique. En pratique, il s'agit d'un modèle très imparfait.<br/> | |||
<br/> | |||
Dans une véritable usine, chaque unité produite - chaque voiture, chaise ou canette de soda - crée une certaine valeur : nous pouvons la vendre et gagner de l'argent. Par conséquent, plus de sortie équivaut à plus de valeur.<br/> | |||
<br/> | |||
Lorsque nous développons des logiciels, les fonctionnalités que nous "produisons" ne sont pas vendues individuellement, mais sont plutôt ajoutées à un produit existant (en ce sens, le développement de logiciels s'apparente davantage au développement d'une ville qu'à la fabrication d'une voiture). Chaque modification apportée au produit est censée créer une certaine valeur ajoutée - plus de transactions, plus de revenus, des gains de temps, etc. Dans l'esprit des industries de nos ancêtres, nous supposons que tout ce que nous choisissons de créer a de la valeur.<br/> | |||
<br/> | |||
Mais est-ce le cas ?<br/> | |||
<br/> | |||
Au cours de la dernière décennie, nous avons commencé à obtenir la réponse. Les entreprises qui ont utilisé des techniques d'expérimentation A/B pour tester leurs idées ont appris que, dans le meilleur des cas, seule une idée sur trois aboutit à une amélioration mesurable et que, dans la plupart des cas, le taux de réussite est beaucoup plus faible, de l'ordre de 10% à 15%.<br/> | |||
<br/> | |||
[[Fichier:Success-Rates-Ronny-Kohavi-research.jpg|border|700px|link=]]<br/> | |||
''Taux de réussite des expériences et risques de faux positifs. Source : [https://dl.acm.org/doi/10.1145/3534678.3539160 Kohavi et al]''<br/> | |||
<br/> | <br/> | ||
