Taux d’échec 268 % plus élevés pour les projets logiciels Agile
Une étude a révélé que les projets logiciels adoptant des pratiques Agiles ont 268 % plus de chances d’échouer que ceux qui ne le font pas.
Même si la recherche commandée par le cabinet de conseil Engprax peut être considérée comme un bouchon à peine voilé pour la méthodologie de l’Impact Engineering, elle alimente la suspicion selon laquelle le Manifeste Agile n’est peut-être pas tout ce qu’il prétend être.
Le travail de terrain de l’étude a été mené entre le 3 et le 7 mai avec la participation de 600 ingénieurs logiciels (250 au Royaume-Uni et 350 aux États-Unis). Une statistique marquante est que les projets dont les exigences sont claires et documentées avant le début du développement ont 97 % plus de chances de réussir. En comparaison, l’un des quatre piliers du Manifeste Agile est « un logiciel fonctionnel plutôt qu’une documentation complète ».
Selon l’étude, mettre en place une spécification avant le début du développement peut entraîner une augmentation de 50 % du succès, et s’assurer que les exigences sont adaptées au problème réel peut conduire à une augmentation de 57 %.
Dr Junade Ali, auteur d’Impact Engineering, a déclaré : « Avec 65 % des projets adoptant des pratiques Agile 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 fournir des logiciels de haute qualité dans les délais et dans les limites du budget, c’est un processus d’ingénierie des exigences robuste et la sécurité psychologique nécessaire pour discuter et résoudre les problèmes lorsqu’ils surviennent, tout en prenant des mesures pour éviter l’épuisement des développeurs. «
Le Manifeste Agile a été critiqué au fil des années. Le tristement célèbre système informatique UK Post Office Horizon était l’un des premiers projets à grande échelle utilisant cette méthodologie, bien que blâmer une approche Agile pour les défauts de conception du système semble un peu exagéré.
Il est également facile d’oublier que les autres méthodologies ont leurs propres défauts. Waterfall, par exemple, utilise une succession de phases documentées, dont le codage n’est qu’une partie. Bien que simple à comprendre et à gérer, Waterfall peut également être lent et coûteux, avec des changements difficiles à mettre en œuvre.
Les équipes ont donc tendance à rechercher des alternatives.
Les projets dans lesquels les ingénieurs estimaient avoir la liberté de discuter et de résoudre les problèmes avaient 87 % plus de chances de réussir. Il est inquiétant de constater que les travailleurs britanniques sont 13 % moins susceptibles de se sentir capables de discuter de leurs problèmes que ceux des États-Unis, selon l’étude.
De nombreux péchés du monde technologique actuel ont tendance à être attribués au Manifeste Agile. Un flux incessant de correctifs indique que la qualité n’est peut-être plus ce qu’elle était autrefois, et que le code apparaissant dans un état inachevé ou inconsidéré a tous été attribués aux pratiques Agile.
Un développeur Agile a critiqué l’élément de stand-up quotidien, le décrivant à Le registre comme « une fête de régurgitation ».
Cependant, même si le Manifeste Agile peut rencontrer des problèmes, ceux-ci proviennent davantage de sa mise en œuvre que des principes eux-mêmes. « Nous n’avons pas besoin d’une équipe de test parce que nous sommes Agile » est une abdication de responsabilité qui permet de réaliser des économies.
En soulignant la nécessité de comprendre les exigences avant le début du développement, la recherche trace un chemin entre les puristes Agile et les défenseurs de Waterfall.