Emergence progressive des exigences

Plutôt que d'essayer de tout figer au début mieux vaut décider au dernier moment possible.

Il est impossible de connaître toutes les exigences[1] dès le début d'un projet. Depuis 20 ans j'ai participé à de nombreuses définitions et spécifications d'exigences dans différents domaines et il en a toujours été ainsi. En réfléchissant longtemps et en essayant d'imaginer les situations dans lesquelles se trouveront les utilisateurs, on peut bien sûr découvrir un bon nombre d'exigences significatives, mais il existera toujours des exigences que, même en se mettant dans la peau des utilisateurs, on ne pourra pas spécifier voire identifier à l'avance.

Je viens d'en faire l'expérience sur le projet Wilos. J'aurais été bien incapable de définir précisément dès octobre ce qu'est finalement le produit aujourd'hui, même si j'avais des idées et que j'avais rédigé un document donnant la vision que j'en avais.

Non seulement il n'aurait pas été possible de spécifier en détail les exigences, mais cela n'aurait servi à rien. En effet, dans un développement agile, une exigence[2] est réalisée dans une itération. Avant qu'elle soit affectée à une itération, il suffit d'en savoir assez pour permettre cette sélection, ce qui repose principalement sur 2 attributs : sa priorité (fonction de la valeur) et l'estimation en points (le coût). Pas besoin d'avoir une spécification détaillée pour cela, des critères de satisfaction suffisent.

Les exigences émergent progressivement. Juste à temps. Ce concept est à la base du Lean et on retrouve pour le développement logiciel cette idée de s'engager sur une décision irréversible au dernier moment où c'est raisonnable [3] chez les Poppendieck

Notes

[1] requirement en anglais, « capacité » ou condition à laquelle le système doit se conformer (IEEE)

[2] en général une histoire d'utilisateur

[3] Schedule Irreversible Decisions at the Last Responsible Moment