Depuis plus de quinze ans, j’entends la même affirmation : « En agile, on ne fait plus de documentation, ni de spécifications. » ou encore : « Les exigences, c’était bon pour le cycle en V, pas pour l’agile. ».
À chaque fois, je souris. Non pas parce que c’est faux, mais parce qu’on confond le support avec le besoin, la documentation avec l’exigence.
Une exigence n’est pas un document.
L’agilité a supprimé les documents inutiles, privilégié les échanges, accepté que tout ne soit pas connu dès le premier jour. Excellente évolution.
Mais dans beaucoup d’organisations, une confusion s’est installée : en supprimant les documents, certains ont cru supprimer les exigences.
Or une exigence reste l’expression d’un besoin, d’une contrainte, d’une attente à satisfaire. Qu’elle prenne la forme d’une spécification, d’une User Story ou d’un schéma au tableau blanc ne change rien à sa nature.
Elles reviennent, parce que les équipes en ont besoin.
Une équipe arrête de produire des spécifications. Quelques semaines plus tard apparaissent des tableaux Miro non référencés, des pages Confluence, des fichiers Excel à rallonge, des critères d’acceptation qui font office de cas de test…
Les exigences ne disparaissent jamais ; elles se déplacent là où les équipes trouvent de la valeur. Parce que les développeurs ont besoin de comprendre, les testeurs de vérifier, les métiers de partager une vision commune.
Le vrai problème n’est pas la documentation.
Quand une transformation agile rencontre des difficultés, j’entends : « Nous manquons de documentation. ». Je ne crois pas que ce soit le vrai sujet.
Le problème est plus souvent un manque de compréhension commune. Une spec de 300 pages ne la garantit pas. Une User Story de trois lignes non plus.
La vraie question : quel niveau d’information est nécessaire pour permettre à chacun de prendre les bonnes décisions ? Cela dépend du contexte : une appli mobile grand public n’impose pas le même niveau de rigueur qu’un dispositif médical ou une plateforme bancaire.
L’agilité n’est pas l’absence de rigueur. Elle consiste à adapter le niveau de formalisation au niveau de risque. L’ingénierie des exigences reste une compétence stratégique, y compris en agile — simplement, elle ne porte plus toujours ce nom.
Au lieu de se demander « Faut-il encore gérer les exigences en agile ? », je proposerais plutôt : « Comment les faire vivre de manière assez légère pour favoriser la collaboration, tout en restant assez rigoureuse pour sécuriser les décisions ? ».
Et vous ?
Dans vos équipes, avez-vous réellement supprimé les exigences… ou ont-elles simplement changé de forme ?
_____
Je suis Stéphane Badreau, consultant, coach, formateur et auteur pour une ingénierie agile.
#Agilité#Transformation#Ingénierie#Exigences#Documentation