Pourquoi les projets logiciels prennent-ils toujours plus longtemps que prevu? La reponse n'est pas ce que la plupart des equipes pensent. Ce n'est pas une mauvaise planification, de mauvaises estimations ou des developpeurs peu qualifies. Le vrai probleme est invisible: du gaspillage qui a ete intege dans chaque delai, chaque estimation et chaque sprint depuis si longtemps que personne ne le remet en question. Les equipes acceptent des delais de 3 mois pour 6 semaines de travail parce qu'elles n'ont jamais vu a quoi ressemble la livraison sans le freinage des requis peu claires, incompletes ou mal alignees. C'est pourquoi la plus grande percee en logiciel ne viendra pas du code.
C'est ce que j'appelle le Probleme invisible. Et tant que vous ne pouvez pas le voir, vous ne pouvez pas le corriger.
Qu'est-ce que le "Probleme invisible" dans la livraison logicielle?
Le Probleme invisible est le gaspillage qui se cache dans chaque estimation logicielle parce que les equipes ne l'ont jamais mesure. Il vit dans l'ecart entre ce qu'une equipe pourrait livrer avec des requis clairs et validees et ce qu'elle livre reellement avec les specifications ambigues et chargees d'hypotheses qu'elle utilise typiquement.
Voici comment ca fonctionne en pratique. Un chef de produit redige un requis. L'equipe de developpement l'interprete. Elle la construit. Deux semaines plus tard, la partie prenante examine la demonstration et dit: "Ce n'est pas exactement ce que je voulais dire." L'equipe reconstruit. Personne n'enregistre cela comme un echec des requis. Cela est categorise comme un "affinage" ou une "iteration" ou simplement absorbe dans la velocite du sprint suivant. Le gaspillage est reel, mais il n'a pas de nom, pas de mesure et pas de responsabilite.
Vous ne pouvez pas optimiser ce que vous ne voyez pas. Et la plupart des equipes n'ont jamais vu leur processus de requis assez clairement pour savoir combien cela leur coute.
La raison pour laquelle ce gaspillage reste invisible est simple: il n'y a pas de point de reference. Les equipes ont toujours fonctionne de cette facon. Elles n'ont pas de point de comparaison. Elles ne savent pas a quoi ressemble un taux de retouche sain parce qu'elles ne l'ont jamais suivi. Elles ne savent pas combien de changements d'envergure en cours de sprint sont normaux parce que personne ne les compte. Le gaspillage est normalise dans les attentes de velocite, et en consequence, il devient le cout d'exploitation que personne n'audite.
attente, retouche et clarification des requis
Comment savoir si votre equipe a un probleme de requis?
La plupart des equipes qui ont un probleme de requis ne le realisent pas. Les symptomes sont mal diagnostiques comme de la dette technique, une mauvaise estimation ou des problemes de capacite de l'equipe. Mais il y a cinq questions de diagnostic qui percent le bruit et revelent la vraie source du friction dans la livraison. Si vous repondez "oui" a trois ou plus, votre equipe a un probleme de requis invisible.
- Plus de 20% de l'effort de votre sprint va-t-il vers la retouche? L'etude Microsoft "Time Warp" de 2024 a revele que les developpeurs ne consacrent que 32% de leur temps a ecrire du nouveau code. Le reste va a l'attente, la retouche et la clarification. Si votre equipe ne peut pas repondre a cette question avec un numero specifique, c'est le premier probleme.
- A quelle frequence les parties prenantes disent-elles "ce n'est pas ce que je voulais dire" aux demonstrations de sprint? Si cela arrive plus d'une fois par sprint, vous construisez a partir d'hypotheses mal alignees. Le code est correct; la specification est erronee.
- Combien de changements d'envergure en cours de sprint se produisent par sprint? Les changements d'envergure ne sont pas inheremment mauvais, mais les changements d'envergure non suivis sont du gaspillage invisible. Si vous ne les comptez pas, vous ne pouvez pas les gerer.
- Un membre de l'equipe peut-il expliquer la logique commerciale des trois principaux elements du sprint? Si les developpeurs construisent des fonctionnalites sans comprendre le "pourquoi", ils prennent des centaines de petites decisions de conception sans contexte. Chacune est un probleme d'alignement potentiel.
- Quand a-t-on retire pour la derniere fois une fonctionnalite livree parce que personne ne l'utilisait? Si la reponse est "jamais", vous ne mesurez pas l'adoption des fonctionnalites. Et si vous ne la mesurez pas, vous n'avez aucune idee du pourcentage de votre effort qui produit de la valeur.
Spotify a decouvert que les nouveaux ingenieurs prenaient plus de 60 jours pour fusionner leur dixieme pull request. Le probleme n'etait pas la competence technique. C'etait de la friction invisible: des processus d'integration peu clairs, de la documentation fragmentee et un manque d'outillage standardise qui forcait les developpeurs a passer leur temps a naviguer dans le systeme plutot qu'a construire.
Apres avoir deploye Backstage, leur portail developpeur interne qui centralise la documentation, la propriete des services et les normes de projet, ce repere de 60 jours est tombe a 20 jours. Une reduction de 67%. Les ingenieurs utilisant la plateforme etaient 2,3 fois plus actifs sur GitHub que ceux qui ne l'utilisaient pas.
La lecon: le gaspillage etait invisible parce que tout le monde l'acceptait comme "la facon dont l'integration fonctionne ici." Une fois que Spotify a rendu la friction visible et standardise le parcours, les gains de vitesse ont suivi immediatement.
Sources: InfoQ, Backstage at Spotify, Spotify Engineering Blog
Pourquoi les entreprises ne realisent-elles pas combien la retouche leur coute?
La raison fondamentale est l'absence de mesure. Vous ne pouvez pas ameliorer ce que vous ne suivez pas, et la plupart des organisations ne suivent pas le cout de la retouche liee aux requis. Elles suivent la velocite. Elles suivent les bogues. Elles suivent la frequence de deploiement. Mais elles ne suivent pas d'ou vient leur retouche, et ce point de donnees manquant cree un point aveugle assez grand pour cacher des milliards de dollars de gaspillage annuel.
principalement en raison de requis mal alignees
Il y a trois raisons structurelles pour lesquelles ce point aveugle persiste. Premierement, le gaspillage est categorise sous les mauvaises etiquettes. Une requis qui a ete mal comprise devient un "bogue". Une fonctionnalite qui doit etre reconstructe devient de la "dette technique". Un projet qui prend deux fois plus longtemps que celui estime devient du "glissement d'envergure". Chacune de ces etiquettes detourne la responsabilite de la cause racine: les requis n'etaient pas claires, completes ou validees.
Deuxiemement, la retouche est normalisee dans les attentes de velocite. Quand une equipe livre de facon coherente a une certaine velocite, ce nombre inclut la surcharge de retouche. Personne ne se demande si la velocite pourrait etre 40% plus elevee si la retouche etait eliminee, parce que personne n'a jamais vu a quoi ressemble la livraison sans cette surcharge. Ajouter des outils de codage IA par-dessus cette fondation brisee ne fait qu'accelerer le probleme, un phenomene que nous explorons dans La gueule de bois Copilot.
Troisiemement, il n'existe pas de norme industrielle pour la qualite des requis. Les equipes mesurent la qualite du code avec des outils d'analyse statique, la couverture des tests avec des suites automatisees et la frequence de deploiement avec des metriques de plateforme. Mais la qualite des requis n'a pas d'ecosysteme de mesure equivalent. Tant que ce ne sera pas le cas, le probleme reste invisible.
A quoi ressemble une evaluation de la maturite des requis?
Une evaluation de la maturite des requis donne a votre equipe la reference qui lui faisait defaut. Elle mappe l'endroit ou votre organisation se situe sur une echelle de cinq niveaux, des pratiques ad hoc (ou se situent la plupart des equipes) aux processus optimises et axes sur les donnees. La valeur n'est pas dans le cadre lui-meme; la valeur est dans la visibilite qu'il cree. Une fois que vous savez ou vous etes, vous pouvez faire des ameliorations ciblees au lieu de deviner.
| Niveau | Description | A quoi ca ressemble |
|---|---|---|
| Niveau 1 | Ad hoc | Les requis vivent dans les esprits des gens, dans les fils de discussion Slack ou dans des documents disperses. Pas de format coherent. Pas de processus d'examen. Le succes depend de la memoire individuelle et de la connaissance tribale. |
| Niveau 2 | Documentee | Les requis sont ecrites, mais la qualite varie enormement. Certaines sont detaillees, d'autres sont des phrases uniques. Pas de modele standardise. Les examens se produisent de facon incoherente. |
| Niveau 3 | Standardisee | Modeles coherents, processus d'examen structures et propriete clairement definie. Chaque requis suit un format defini et passe par une etape de validation avant que le developpement ne commence. |
| Niveau 4 | Mesuree | Les metriques de qualite sont suivies: scores de completude, taux de demandes de changement, analyse d'origine des defauts. L'equipe a des donnees sur l'origine du gaspillage et les utilise pour s'ameliorer continuellement. |
| Niveau 5 | Optimisee | La qualite des requis est continuellement amelioree en utilisant les perspectives guidees par les donnees. La validation assistee par l'IA detecte les lacunes avant qu'elles n'atteignent le developpement. L'equipe mesure le cout de chaque changement de requis et optimise de maniere proactive. |
La plupart des equipes operent aux niveaux 1 ou 2. Elles savent que les requis comptent, mais elles manquent de structure et de mesure pour les ameliorer systematiquement. Le passage du niveau 2 au niveau 3 seul reduit typiquement la retouche de 25 a 35 pour cent, car il introduit le changement le plus impactant: la validation structuree avant le code.
Comment commencer a mesurer la qualite des requis des maintenant?
Vous n'avez pas besoin d'une evaluation de maturite pour commencer a vous ameliorer. Vous avez besoin de trois metriques, et vous pouvez commencer a les suivre ce sprint. Ce ne sont pas des metriques complexes qui necessitent de nouveaux outils ou processus. Ce sont des observations que vous pouvez faire avec les systemes que vous avez deja. (Pour en savoir plus sur l'approche de Specira, consultez notre foire aux questions.)
Metrique 1: Score de completude. Avant chaque sprint, notez chaque requis engagee sur trois dimensions: clarte (tout membre de l'equipe peut-il l'interpreter de la meme facon?), testabilite (pouvez-vous rediger des criteres d'acceptation sans poser de questions de clarification?), et alignement des parties prenantes (le parrain du metier a-t-il explicitement confirme que c'est ce qu'il veut?). Notez chaque dimension de 1 a 5. Toute requis notet en dessous de 3 sur une dimension quelconque est un risque de retouche.
Metrique 2: Demandes de changement en cours de sprint. Comptez chaque changement d'envergure qui se produit apres l'engagement du sprint. Cela comprend les clarifications de requis qui modifient la direction de la mise en oeuvre, les retrouvailles des parties prenantes qui alterent le resultat attendu et les dependances nouvellement decouverte. Suivez le volume par sprint et l'effort que chaque changement consomme. Dans trois sprints, vous aurez une image claire de combien de votre capacite est absorbee par les requis qui n'etaient pas pretes quand le sprint a commence.
Metrique 3: Origine du defaut apres lancement. Pour chaque defaut de production, etiquetez la cause racine: etait-ce une erreur de codage, un vice de conception ou une lacune des requis? La plupart des equipes supposent que les defauts sont principalement des problemes au niveau du code. Quand ils commencent a etiqueter les causes racines, ils decouvrent que les erreurs de requis detectees tardivement dans le cycle de vie coutent 3 a 78 fois plus a corriger que celles detectees tot, selon les etudes de cout de cycle de vie de la NASA. Plus vous tracez les defauts a leur origine tot, plus vite vous cessez de payer ce multiplicateur.
Le changement qui change tout
Le Probleme invisible persiste parce que les equipes mesurent la production (fonctionnalites livrees, points d'histoire completes) au lieu de l'alignement (avons-nous construit la bonne chose, pour la bonne raison, du premier coup?). Une fois que vous introduisez meme des metriques de qualite de requis de base, le gaspillage devient visible. Et le gaspillage visible est du gaspillage que vous pouvez eliminer.
Vous n'avez pas besoin d'un processus parfait. Vous avez besoin d'une reference. Commencez a mesurer ce sprint. Comparez les chiffres dans trois mois. Les resultats parleront d'eux-memes. Et si vous voulez voir comment les equipes compriment six semaines de travail de requis en quelques heures, la voie est plus proche que vous ne le pensez.
Questions fréquentes
