Une étude menée auprès de 600 ingénieurs logiciels britanniques et américains révèle que les projets qui adoptent les pratiques du Manifeste Agile ont 268 % plus de chances d'échouer que ceux qui font le contraire. L'étude démontre que les taux d'échec des projets de logiciels agiles peuvent être divisés par 6,5 en utilisant une nouvelle méthodologie d'ingénierie d'impact. L'adoption de l'ingénierie d'impact pourrait permettre d'économiser 115 milliards de dollars américains par an en dépenses de R&D inutiles aux États-Unis et les contribuables britanniques pourraient économiser environ 7 milliards de livres sterling par an sur les projets gouvernementaux de changement numérique qui n'aboutissent pas.Le développement agile de logiciels est un état d'esprit qui découle des valeurs convenues par l'Agile Alliance, un groupe de 17 praticiens du logiciel, en 2001. Comme l'indique leur Manifeste pour le développement agile de logiciels, les praticiens accordent de l'importance aux valeurs suivantes : les individus et les interactions plutôt que les processus et les outils, un logiciel fonctionnel plutôt qu'une documentation exhaustive, la collaboration avec les clients plutôt que la négociation de contrats, la réaction au changement plutôt que le suivi d'un plan.
Le Manifeste Agile existe depuis plus de 21 ans maintenant, mais la recherche empirique sur l'impact réel de ses valeurs sur l'industrie reste lacunaire, malgré une étude récente montrant que 81 % des décideurs au Royaume-Uni et 89 % aux États-Unis sont préoccupés par le respect des délais de livraison des projets de logiciels dans leur organisation.
Une nouvelle étude menée pour un nouveau livre, Impact Engineering, a montré que 65 % des projets de logiciels adoptant les pratiques d'ingénierie des exigences Agile ne parviennent pas à être livrés dans les délais et dans les limites du budget, avec un niveau de qualité élevé. En revanche, les projets qui adoptent une nouvelle approche d'ingénierie d'impact décrite dans le nouveau livre n'échouent que dans 10 % des cas.
Le taux d'échec des projets logiciels agiles est supérieur de 268 %
L'étude, menée par Junade Ali PhD CEng FIET et J.L. Partners, a vu la participation de 600 ingénieurs en logiciel (250 au Royaume-Uni et 350 aux États-Unis). Le travail sur le terrain s'est déroulé du 3 au 7 mai 2024. J.L. Partners est membre du British Polling Council et respecte ses règles.
Selon les auteurs, "la signification statistique des données de l'étude montrant que les projets utilisant les pratiques de l'ingénierie d'impact sont plus performants que tous les autres est si forte que la probabilité que cette conclusion soit incorrecte équivaut à lancer six fois consécutivement le chiffre six sur un dé à six faces, dès la première tentative" (les probabilités sont très faibles).
Trois des quatre pratiques énumérées dans le Manifeste Agile sont "le logiciel de travail plutôt qu'une documentation exhaustive", "la collaboration avec le client plutôt que la négociation d'un contrat" et "la réponse au changement plutôt que le suivi d'un plan". Toutefois, la nouvelle étude a révélé que les projets qui disposaient d'un cahier des charges ou d'exigences documentées avant le début du développement avaient 50 % de chances de plus de réussir que ceux qui n'en disposaient pas, que les projets qui avaient des exigences claires avant le début du développement avaient 97 % de chances de plus de réussir et que les projets qui ne nécessitaient pas de modifications importantes des exigences à la fin du processus de développement avaient 7 % de chances de plus de réussir.
D'autres pratiques ont également contribué à la réussite des projets. Les projets dans lesquels l'ingénieur logiciel a déclaré se sentir psychologiquement en sécurité pour discuter des problèmes et les résoudre rapidement lorsqu'ils apparaissent avaient 87 % plus de chances de réussir que ceux qui n'en avaient pas. Les projets dont les exigences se fondaient précisément sur un problème réel avaient 54 % plus de chances de réussir que les autres.
Il est intéressant de noter que l'étude n'a pas révélé de différence statistiquement significative entre la réussite des personnes travaillant sur un seul projet et celles travaillant sur plusieurs projets, bien que la réduction des travaux en cours soit un élément clé de la méthodologie de développement de logiciels Lean. Toutefois, des recherches antérieures menées par le Dr Ali ont montré que 83 % des ingénieurs en informatique déclarent souffrir d'épuisement professionnel, la "charge de travail élevée" en étant la principale raison.
Cette étude intervient alors que les défaillances logicielles catastrophiques sont de plus en plus présentes dans l'esprit du public. Dans son précédent ouvrage intitulé "How to Protect Yourself from Killer Computers", le Dr Ali a étudié de nombreux cas de logiciels mortels dont les causes techniques ont été attribuées à des problèmes de conception logicielle, notamment des avions effectuant des "plongées mortelles", des accidents de voiture mortels et des surdoses de radiations mortelles dans les hôpitaux.
En effet, le système informatique Horizon était l'un des premiers projets à grande échelle à utiliser une méthodologie Agile, à savoir le développement rapide d'applications, qui a été condamnée par les ingénieurs de Fujitsu qui ont témoigné dans l'enquête publique (Terence Austin et le dénonciateur David McDonnell) comme étant à l'origine des problèmes techniques dus à l'absence d'un processus solide d'ingénierie des exigences.
Charles Cipione, l'expert technique qui a témoigné dans le cadre de l'enquête, a résumé la situation en disant que "si vous n'avez pas une bonne conception, cela ne fonctionnera pas correctement". L'incapacité à résoudre ces problèmes et les tentatives de dissimulation ont conduit au scandale des Postes, décrit comme la plus grande erreur judiciaire de l'histoire britannique, liée à de multiples suicides de personnes emprisonnées à tort, dont une femme enceinte.
L'étude a également révélé, de manière inquiétante, que les ingénieurs en logiciel du Royaume-Uni avaient 13 % de chances en moins de se sentir capables de discuter et de résoudre les problèmes que ceux des États-Unis, ce qui représente la plus grande différence de toutes les pratiques d'ingénierie entre les deux pays. Cette constatation fait suite à une étude réalisée en novembre 2023 par Engprax, selon laquelle 75 % des ingénieurs en informatique au Royaume-Uni ont subi des représailles après avoir signalé des actes répréhensibles.
Junade Ali, auteur de l'ouvrage Impact Engineering, a déclaré :
Avec 65 % des projets adoptant des pratiques agiles qui ne sont pas livrés à temps, il est temps de remettre en question le culte de l'Agile. Nos recherches ont montré que ce qui compte lorsqu'il s'agit de livrer un logiciel de haute qualité dans les délais et dans les limites du budget, c'est un processus solide d'ingénierie des exigences et la sécurité psychologique nécessaire pour discuter et résoudre les problèmes lorsqu'ils apparaissent, tout en prenant des mesures pour prévenir l'épuisement des développeurs. C'est un élément fondamental de la philosophie de l'ingénierie d'impact.
« Impact Engineering » est désormais disponible sur Amazon en format Kindle eBook et en livre de poche. Ce roman d'entreprise est basé sur des études de cas réels de transformations personnelles et organisationnelles utilisant la méthodologie de l'ingénierie d'impact et un cadre psychologique nouvellement développé pour réaliser des transformations réussies, en plus d'un chapitre décrivant la base scientifique sous-jacente de la méthodologie.
Et vous ?
Pensez-vous que cette étude est crédible ou pertinente ? Quel est votre avis sur le sujet ?Voir aussi :
Les développeurs devraient abandonner les méthodes agiles selon Ron Jeffries, l'un des signataires du Manifeste Agile L'armée américaine annonce une nouvelle politique visant à favoriser l'adoption de pratiques de développement logiciel agiles La méthode Scrum est-elle une méthode agile efficace ou un cancer pour les développeurs ? Les propos d'un professionnel de l'informatique divisent la communauté 
Envoyé par d_d_v
