Les spécifications à problème (2) Spécifications qui changent en cours de développement

Ce billet fait partie d’une série de trois articles consacrés aux spécifications et à leurs problèmes. Le précédent portait sur les développements réalisés sans spécification. Je vous invite à le lire rapidement pour comprendre le contexte.

En image

Version texte

On peut voir une maison dont la façade est couverte de fenêtres de tailles et de formes différentes.

Explication de l’architecte : « Pour les fenêtres ? Ah oui, à force de changer d’avis… »

Mon avis

Il s’agit là d’un cas d’école tellement cela arrive souvent. Une spécification fonctionnelle a été écrite, elle a été analysée (possiblement en faisant plusieurs itérations), une spécification technique en a découlé, et le développement a été commencé. Soudain, sous prétexte de vouloir apporter des « précisions » à la spécification, la spécification initiale est modifiée de manière subtile. Enfin, la subtilité est fonctionnelle ; d’un point de vue technique, les modifications nécessaires sont assez profondes. Mais si vous commencez à vouloir négocier, on vous rétorque que les modifications sont mineures, et que vous devez pouvoir vous adapter, que diable !  Sous-entendu : l’équipe technique doit prouver sa valeur en étant capable de gérer ces changements sans que cela n’affecte son planning.

Le problème, c’est que ce genre de chose implique quasi-automatiquement de prendre des raccourcis, afin de tenir les délais initialement prévus. L’une des conséquences directe est que l’environnement technique global (code source, schéma de base de données, documentation technique, etc.) se retrouve truffé de scories, des reliquats des différentes directions techniques qui ont été suivies puis abandonnées, à cause de tous ces pseudo-refactoring qui n’ont pas été prévus. Pour finir, vous obtenez des applications difficiles à maintenir et à faire évoluer.

Pourtant, il faut être fondamentalement prêt à faire face aux changements. La solution a été trouvée avec l’utilisation des cycles itératifs et des méthodes agiles. Chaque itération permet de s’assurer que les développements vont dans le bon sens. Mais aucun changement de direction ne peut intervenir en cours d’itération.