Déchets de projets logiciels et comment les réduire

Le gaspillage des projets logiciels coûte cher $1Md par jour dans les entreprises et les gouvernements du monde entier qui effectuent un travail totalement inutile.

Chaque jour, les équipes logicielles du monde entier perdent 30 à 60% de leur temps (et du temps et de l'argent des employeurs) en raison de pratiques inefficaces. La plupart de ces déchets sont évitables. À tout moment, chaque membre de l’équipe peut effectuer un travail utile mais, le travail qu'ils font aurait pu être évité. Dans la plupart des cas, les gestionnaires ignorent ce qui se passe.

Cet article examine certaines des principales causes de gaspillage dans le travail logiciel. Commençons par examiner les activités des équipes logicielles qui génèrent du gaspillage. Tous ceux qui ont travaillé sur un projet logiciel en auront vécu plusieurs.

Les équipes logicielles perdent souvent des efforts et du temps :

1. revisiter des fonctionnalités mal conçues des sprints précédents,
2. comprendre et retravailler le code mal structuré d'autres développeurs lors des sprints précédents,
3. résoudre les malentendus car l'auteur de l'exigence n'a pas veillé à ce que les exigences soient claires de manière à ce que tous les lecteurs (utilisateurs, architectes, développeurs, testeurs) parviennent à une compréhension commune,
4. faire une refonte parce que l'auteur de l'exigence a mal compris ce qui était réellement nécessaire,
5. rédiger des tests manuels ou automatisés par rapport à des exigences qui s'avèrent ultérieurement incorrectes,
6. changer ou éliminer le code incorrect parce que les exigences étaient mauvaises,
7. retouche ou travail supplémentaire parce qu'une mauvaise structure de données a été choisie, peut-être parce que les exigences étaient incohérentes,
8. mettre en œuvre des exigences de faible priorité parce qu’une image plus complète de l’ensemble des exigences n’était pas prise en compte ou n’était pas disponible.
9. retravailler le code en raison d'une utilisation du langage incohérente et non structurée dans les exigences,
10. corriger et retester les bugs qui auraient pu être évités si les exigences et les conceptions avaient été plus claires,
11. rédiger des critères d'acceptation détaillés et inappropriés d'exigences qui manquent d'une description de base,
12. changement de tâche causé par des retouches dues à des exigences ou des conceptions médiocres. (le contraire de « fais-le bien et fais-le une fois »)
13. participer à des réunions d'estimation (story point) qui sont principalement consacrées à la découverte du sens des exigences, car les exigences ne sont pas claires,
14. travailler sur des projets qui sont ensuite annulés parce que le projet a dépassé le budget et le calendrier, parce que la connaissance de la portée globale était mauvaise ou incomplète au départ

On parle beaucoup de pratiques Lean de la part des équipes logicielles, dont l’objectif est d’éliminer le gaspillage. Pourtant, il est rare de trouver des équipes qui examinent attentivement la source réelle et l’ampleur des déchets, déterminent leur impact sur les progrès et déterminent comment ils pourraient être évités à l’avenir. La plupart des équipes se livrent à une ou plusieurs des activités inutiles ci-dessus. L'impact accumulé s'élève en moyenne à environ 40-50% de tout le travail effectué par les équipes logicielles. Et la plupart de ces problèmes sont évitables.

Effort gaspillé dans le travail du savoir

Le gaspillage d’efforts en matière de connaissances est courant et considérable. Par exemple, modifier un code déjà stable est très coûteux car celui-ci, ainsi que toutes les fonctionnalités qui l'entourent, doivent être reconsidérés et retestés. Un nouveau test est nécessaire pour garantir que le changement n’a pas introduit d’effet négatif. Une modification de code sur une seule ligne peut nécessiter un nouveau test de milliers de lignes de code associé. Le développement piloté par les tests (TDD) est une technique qui permet d'atténuer ce problème, mais il ne l'empêche pas et ne détecte pas non plus tous les défauts possibles.

Sur les projets impliquant des équipes plus importantes, le travail d'une personne dépend du travail antérieur d'une autre. Avant d'apporter une modification à un code, un développeur doit comprendre ce que son prédécesseur a écrit, puis déterminer où il a été utilisé, puis enfin commencer à apporter les modifications souhaitées. Il en va de même pour les exigences, les conceptions et les tests. Le pré-changement apprentissage peut prendre des heures, voire des jours.  Ce qui semble être une modification mineure peut devenir disproportionnellement très coûteux.  

Passer d’un morceau de code à l’autre implique un changement de contexte. Pour que les connaissances fonctionnent correctement, nous devons nous concentrer et éviter de changer de contexte. La correction des bogues implique plus de changement de contexte que l'écriture du code en premier lieu. Le changement de contexte est complètement inutile. La combinaison du réapprentissage et du changement de contexte explique en partie comment un petit changement de code peut être extrêmement coûteux. Idéalement, nous souhaitons modifier une méthode le moins de fois possible au-delà du sprint dans lequel elle a été créée. 

Les équipes mesurent-elles les vrais déchets ?

En général, non, ce n’est pas le cas. C'est vrai, $1Bn par jour sont gaspillés par les entreprises et les gouvernements du monde entier et très peu d'entre eux le mesurent. Ces déchets ne diminueront pas ou ne disparaîtront pas d’eux-mêmes par magie ; un travail proactif est nécessaire.

L’analyse des causes profondes peut être utile pour identifier où, pourquoi et quelle quantité de gaspillage est produite. Avant d'envisager un projet logiciel à venir qui nécessite une modification ou une correction du code existant, nous devons nous poser quelques questions importantes, voici une liste non exhaustive :

• Cette exigence ou ce changement aurait-il pu être prévu ou raisonnablement anticipé ?
• Comment aurions-nous pu le savoir plus tôt afin d'éviter d'avoir à modifier le code existant ? Ce changement aurait-il pu être complètement évité ?
• Combien d'efforts supplémentaires et de durée prolongée sont causés par ce changement maintenant par rapport à si nous l'avions résolu lors de la première écriture du code.
• Combien de temps et d’efforts supplémentaires sont consacrés aux tests de régression à la suite de ce changement ?
• Quel est l'effet d'entraînement de ce changement maintenant par rapport à si nous l'avions fait plus tôt.
• Ce changement introduit-il de nouveaux risques en termes de performances ou de sécurité sur le code précédemment déployé (introduit-il un mauvais correctif) ?
• Ce changement est-il exprimé dans des termes sans ambiguïté tels que tout lecteur le comprendra.

La cause profonde la plus courante

La cause première de la plupart de ces gaspillages est un mauvais travail au début du cycle de vie du logiciel. Mauvais travail sur les exigences, décisions d'architecture précipitées, travail d'options de solution ou travail de conception bâclé.

La plupart des équipes logicielles prennent rarement en compte l'impact réel des défauts d'exigences sur leur productivité et le gaspillage qu'ils entraînent. En outre, ils peuvent négliger le coût de mauvaises décisions de conception longtemps après la mise en œuvre de la conception. C'est étiqueté comme dette technique.

Des exigences peu claires mises en œuvre avec une conception médiocre et peu flexible peuvent entraîner des coûts de retouche extraordinaires. Ce coût de reprise peut alors être encore plus élevé s’il entraîne un retard dans d’autres travaux connexes et non liés. Dans certains cas, et assez fréquemment sur des projets plus importants, de mauvaises exigences et de mauvaises décisions de conception au début peuvent conduire à l'abandon d'un projet entier.

Les défauts d’exigences découverts tardivement sont généralement le type de défaut le plus coûteux à corriger.

Environ $720Bn sont dépensés par an à l'échelle mondiale pour le travail sur les logiciels d'entreprise. Environ la moitié de ces problèmes sont des retouches qui sont évitables et sont causées par de mauvaises exigences, de mauvaises décisions de conception et les conséquences des deux. Au niveau mondial, cela représente environ $360 milliards par an, soit environ $1 milliards par jour.

Qu'en est-il de l'Agile

Agile ne guérit pas les déchets que nous avons décrits ici. Le principal avantage des méthodologies de développement logiciel Agile est une boucle de rétroaction rapide entre les utilisateurs et les développeurs. Nous constatons que dans de nombreux cas, l’adoption d’Agile entraîne une baisse de la qualité et de la rigueur des exigences et autres travaux de pré-codage. Les organisations sont pressées de proposer de nouvelles fonctionnalités logicielles. Les acteurs impliqués dans le travail présentent une approche « adapter au fur et à mesure », qui semble attractive. Si elles sont bien appliquées, les pratiques Agile contribuent à garantir que le client obtient ce qu'il souhaite, mais lorsqu'elles sont accompagnées d'un précodage bâclé, les résultats sont des niveaux importants de retouches au cours du projet et une augmentation des efforts inutiles.

Les données de milliers de projets montrent qu’il y a autant de défauts introduits avant le codage que pendant le codage.[je] C’est ce qu’on appelle le potentiel de défaut. 16% – 35% de tous les défauts de production sont causés par des exigences médiocres ou incomplètes.[ii]

Peu d’équipes logicielles réfléchissent soigneusement au fait que les exigences et les défauts de conception sont à l’origine de tant d’efforts inutiles. Vous ne pouvez pas développer tant que vous n’avez pas une idée des exigences. En d’autres termes, le développement suit les exigences. Une exigence mal documentée ou mal exprimée peut conduire toute une équipe à faire des jours ou des semaines de travail inutile. Souvent, ce type de gaspillage est considéré comme « apprentissage » ou « évolution des exigences des utilisateurs », alors qu'en réalité il ne s'agit ni de l'un ni de l'autre, il s'agit d'un travail répondant à des exigences inférieures aux normes. Il existe plusieurs raisons pour lesquelles le fonctionnement des exigences peut être médiocre. L'une des raisons est que de nombreuses organisations ne parviennent pas à garantir que le personnel qui rédige les exigences est suffisamment formé et expérimenté pour effectuer un travail de haute qualité en matière d'exigences. Une autre raison est qu’il y a peu d’accord et de cohérence au sein du secteur sur ce qui constitue une bonne exigence.

Autres causes courantes de gaspillage de projets logiciels

Nous avons mentionné un travail antérieur médiocre et un changement de contexte comme principales causes de gaspillage. D'autres causes courantes incluent :

• gaspillage causé par un mauvais leadership,
• gaspillage causé par un faible niveau de compétence, entraînant une augmentation des retouches et des bugs
• les déchets issus de processus suivants qui semblent ajouter de la valeur mais ne le font pas,
• ne pas suivre de bons processus qui ajoutent de la valeur mais qui ne sont peut-être pas à la mode,
• gaspillage de frais de communication en raison de la taille excessive de l'équipe,

Les exigences logicielles sont souvent de mauvaise qualité

Les exigences logicielles et les user stories sont souvent de mauvaise qualité. Peut-être que l'auteur n'est pas suffisamment compétent ou expérimenté. Peut-être n’ont-ils pas accès aux informations dont ils ont besoin. Le problème avec presque toutes les exigences est qu’elles sont écrites dans un langage naturel sans contrainte. Habituellement, les auteurs manquent de formation formelle sur les exigences de qualité de rédaction. Le langage naturel sans contrainte n'est pas le moyen idéal pour communiquer les exigences logicielles, mais c'est ce que nous utilisons principalement. La plupart des organisations ne gèrent pas la qualité des exigences.

Chez Scopemaster, nous avons analysé plus de 300 000 exigences provenant de centaines de projets logiciels dans différents pays et secteurs. Ce que nous avons constaté, c'est que :

• En moyenne, une exigence (ou user story) est composée de 12 mots (hors critères d'acceptation). Et en moyenne, chaque mot correspondra à 125 mots de codage, ou jetons en cours d'écriture. Ainsi, nous pouvons dire qu’une erreur avec un seul mot d’une exigence pourrait conduire à devoir réécrire 125 mots de codage. Ces chiffres ne doivent pas être utilisés comme base d’estimation, mais indiquent l’importance de chaque mot d’une exigence.
• En moyenne, nous constatons 4 à 8 problèmes pour chaque exigence. Ces problèmes varient en gravité mais, à moins d'être résolus rapidement, chacun provoquera ou est susceptible de provoquer un bogue logiciel.

Les défauts courants liés aux exigences comprennent :

• Pas orienté utilisateur
• Inconsistant
• Pas clair
• Non testable
• Non-dimensionnable
• Contenu technique excessif
• Dupliqué
• Manquant
• Pas utile
• Trop verbeux

La plupart des lecteurs interpréteront différemment une exigence écrite. Si la différence d’interprétation n’est pas triviale, elle est susceptible de conduire à un bug logiciel. Si ce bug n’est identifié que plus tard, beaucoup de travail aura peut-être été fait et devra être refait afin de le corriger. Réussir du premier coup ou détecter les défauts le plus tôt possible est vraiment important.

Attributs de qualité des bonnes exigences logicielles

Il existe diverses sources et opinions sur ce qui constitue une exigence de bonne qualité. Il y a un excellent travail réalisé par le IEEE et ils reviennent régulièrement sur ce sujet. Il existe une liste d’attributs communément adoptée, bien que déficiente à notre avis, qui est fréquemment promue par divers coachs agiles, encapsulée dans la pneumonique INVEST.

Voici notre liste d’attributs de qualité des exigences.

Vérifier chaque exigence répond bien à tout ce qui précède, est un travail plutôt fastidieux, mais nécessaire si vous souhaitez minimiser le gaspillage. Heureusement, des outils tels que ScopeMaster peuvent désormais assurer la part du lion de l'assurance qualité de ces exigences pour vous.

Autres formes de déchets de projets logiciels

Merci à Todd Sedano pour son image très utile en haut de cet article qui montre les formes courantes de gaspillage de projets logiciels. Nous avons maintenant couvert les trois premiers en détail, car ils constituent les principales causes profondes du gaspillage des projets. Regardons les autres :

Des solutions inutilement complexes

La dette technique, les intégrations complexes, le mélange de langages, les règles métier complexes et les architectures logicielles médiocres conduisent tous à des solutions trop complexes, ce qui entraîne une perte de temps à retravailler, à découvrir comment fonctionne le système et à garantir que l'introduction de changements n'entraîne pas de résultats indésirables. c'est-à-dire qu'une bonne architecture conduit à une flexibilité efficace.

Charge cognitive étrangère

Le gaspillage des projets logiciels est parfois dû au fait de donner aux développeurs et aux concepteurs des distractions et des contraintes supplémentaires. Les projets réussis protégeront les développeurs, les testeurs et les concepteurs de tout ce dont ils n'ont pas à s'inquiéter.

La détresse psychologique

Cette cause de gaspillage a tendance à être moins courante ou est causée par des pressions externes ou, dans de rares cas, par une très mauvaise gestion.

Perte de connaissances

Dans les environnements de systèmes vastes ou complexes, la continuité du personnel contribue à conserver les connaissances. Si des experts partent, il faudra peut-être des semaines ou des mois d'apprentissage pour rattraper le niveau du personnel qui part.

Multitâche/attente

Les projets logiciels perdent du temps et des efforts en matière de changement de tâches (résultat du multitâche). Cela peut souvent prendre 20 à 50 minutes à un développeur pour revenir là où il se trouvait avant qu'une distraction n'interrompe le fil de ses pensées.

Communication inefficace

Nous avons largement couvert ce problème avec des exigences médiocres. Mais parfois, la communication sur d’autres projets est mal gérée, par exemple si les dirigeants ne parviennent pas à donner des indications claires sur ce qui est important pour l’entreprise.

Éviter le gaspillage

Pour éviter ce gaspillage, il nous suffit de mieux travailler sur les exigences et de mieux concevoir. Est-ce si simple ? Oui.

Si vous rédigez de meilleures exigences qui communiquent de manière claire et cohérente à tous les lecteurs, puis consacrez suffisamment de temps pour vous assurer que les options de conception sont soigneusement examinées, que les conceptions sont examinées et optimisées avant le codage, de bonnes choses se produiront et le gaspillage sera minime.

L’accent est rarement mis sur la qualité des exigences. En outre, de nombreuses approches, cadres et tendances Agile sapent les moyens éprouvés et efficaces de fournir des logiciels de haute qualité du premier coup. Qualité des exigences et qualité de conception peut être mesurés, suivis et améliorés, mais ils le sont rarement.

Les équipes ont besoin d'aide pour résoudre ce problème

Rédiger de bonnes exigences n’est pas facile, cela nécessite de la formation et de l’expérience. De nombreuses équipes ont un propriétaire de produit qui est soit un expert en la matière, soit un BA expérimenté. Il connaît peut-être le secteur mais ne sait pas rédiger de bonnes exigences de qualité. Voici quelques raisons pour lesquelles ce problème reste largement ignoré :

1. Il y a peu de récompense professionnelle pour remettre en question les exigences de qualité

2. Si l'exigence est faible et que vous devez la construire deux fois, vous êtes payé plus

3. Les auteurs d'exigences ont rarement une connaissance approfondie des besoins des utilisateurs, des systèmes existants et de la manière de rédiger de bonnes exigences.

4. Souvent, les auteurs des exigences sont les développeurs qui rédigent des tâches de développement riches en jargon, des exigences utilisateur difficiles à comprendre et pouvant être comprises par tous.

5. Les équipes limitent rarement le langage des exigences à celui qui permet d'obtenir une compréhension commune toujours claire.

6. L'équipe s'appuie sur la discussion pour dissiper les malentendus. Les discussions restent souvent non documentées.

7. Il existe une grande diversité d’opinions sur ce qui constitue une bonne qualité des exigences.

2022 et l’automatisation/IA viennent à la rescousse

Des outils émergent qui peuvent aider à l’assurance qualité (AQ) des exigences. Les fournisseurs d'outils de gestion des exigences travaillent sur de nouvelles fonctionnalités pour faciliter certains aspects de l'assurance qualité des exigences. IBM Doors, Jama Connect, Visuresolutions et ScopeMaster en sont des exemples. Notre propre outil ScopeMaster est l'outil le plus avancé disponible pour résoudre les problèmes décrits dans cet article. Il automatise le contrôle qualité des exigences dès le début du cycle de vie du logiciel. C'est comme un analyseur statique des exigences ; il fait pour les exigences quoi SonarQube fait pour le code.

ScopeMaster et certains autres outils utilisent le traitement du langage naturel et d'autres techniques analytiques pour interpréter et tester les exigences. ScopeMaster guide l'auteur des exigences pour améliorer la qualité des exigences à une vitesse et avec une rigueur qui étaient jusqu'à présent impossibles. (ScopeMaster effectuera en moyenne 100 000 tests sur un ensemble de 100 user stories en 4 minutes). ScopeMaster détecte généralement 2 à 4 défauts par exigence en quelques secondes seulement.

ScopeMaster trouvera environ la moitié de tous les vices cachés dans un ensemble d'exigences. Les types de défauts couvrant 9 des 10 attributs de qualité indiqués ci-dessus. Cela peut aider les équipes à élever très rapidement la qualité d'un ensemble d'exigences à un niveau beaucoup plus élevé, contribuant ainsi à atténuer ce problème de pa $360Bn.

Conclusion

Si vous êtes impliqué dans des projets logiciels dans le secteur des entreprises ou du gouvernement, vous risquez de gaspiller jusqu'à 50% de votre budget en travaux évitables. La cause première d’une grande partie de ce gaspillage réside dans les mauvaises exigences et dans le travail de conception du système. Reconnaître qu’il y a un problème et qu’il s’agit probablement de la cause profonde est la première étape pour pouvoir le résoudre. L'étape suivante consiste à introduire une initiative d'amélioration de la qualité qui aborde le début du cycle de vie du développement : objectifs, exigences, architecture et conception. Commencez à mesurer les défauts des exigences et l’impact qu’ils ont sur vos progrès. Reconnaître les défauts potentiels et introduire des initiatives pour détecter et corriger ces défauts le plus tôt possible. Des outils tels que ScopeMaster changent la donne en matière de certitude logicielle.

Écrit par Colin Hammond, vétéran de l'informatique depuis 37 ans et fondateur de ScopeMaster.

[je] Sources de défauts Défauts par point de fonction Défauts d'exigences 0,75 Défauts d'architecture 0,15 Défauts de conception 1,00 Défauts de code 1,25 Défauts de documents 0,20 Défauts de mauvaise correction 0,15 Potentiel de défaut total 3,65

https://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty-years-of-IFPUG.-Software-Economics-and-Function-Point-Metrics-Capers-Jones.pdf

[ii] Capers Jones et Accenture, janvier 2021

Économie de la qualité logicielle, par C Jones et Olivier Bonsignor.