Le but est d'éviter un travail inutile en forçant l'utilisateur / client à fournir un avantage commercial solide et tangible comme raison de l'existence de cette fonctionnalité.
Il n'est pas rare que des fonctionnalités soient ajoutées simplement parce que quelqu'un pensait qu'elles avaient l'air cool, ou parce que d'autres logiciels l'ont, donc le nôtre doit également l'avoir. Plus souvent qu'autrement, ceux-ci sont au moins complètement inutiles, sinon activement nocifs.
Cependant, il est généralement facile de repérer ces fonctionnalités, car les personnes qui les proposent généralement auront du mal à fournir une raison commerciale convaincante.
Il y a une technique appelée Popping The Why Stack , où vous prenez la partie "afin que", et demandez "Pourquoi?", Puis vous prenez cette réponse, et demandez "Pourquoi?" à nouveau, récursivement. Si, après (disons) de trois à cinq « Pourquoi » s, vous n'êtes pas arrivé à soit « parce que ça va nous faire de l' argent » ou « parce que ça va nous économiser de l' argent » ( de préférence avec une description précise exactement comment cette va se produire), alors la fonctionnalité ne vaut pas la peine d'être implémentée.
Certaines personnes croient que cela est si important qu'elles l'ont mis en premier dans le modèle d'histoire:
Afin de [...]
Comme un [...]
Je veux [...]
Il y a un excellent exemple tiré d'une conférence de certaines personnes de Thoughtworks: l'un de leurs clients voulait que les rapports imprimés soient formatés de manière très particulière. Lorsque le consultant a demandé "Pourquoi", ils ont dit que de cette façon, ils étaient plus faciles à taper. Ainsi, au lieu d'implémenter la fonction de formatage des rapports, ils ont simplement transféré les rapports sur le réseau. Sans la clause «so that», ils continueraient d' imprimer leurs documents dans un département, de les envoyer par la poste à l'autre département et de les recopier.