Les histoires d'utilisateurs et les exigences sont des bêtes très différentes.
Exigences
Les exigences présupposent que la conception de l'application est faite à l'avance et que le développement correspond à la mise en œuvre de cette conception. Les exigences portent donc sur la manière de mettre en œuvre une fonctionnalité.
Exemple de besoin:
- Créez un formulaire de contact utilisateur avec les champs suivants: nom, prénom, email, texte libre et un bouton d'envoi. Lorsque vous cliquez sur le bouton d'envoi, un courrier électronique est envoyé à notre équipe d'assistance.
Histoires d'utilisateurs
Les histoires d'utilisateurs se concentrent sur les objectifs à atteindre et insistent sur le fait que la conception du produit est réalisée à la dernière minute et qu'il s'agit d'une collaboration entre une personne chargée du produit et une personne chargée du développement. Les détails sont décidés lors de la mise en œuvre en fonction des opportunités.
Exemple d'histoire:
- En tant qu'utilisateur Jimmy, je souhaite contacter votre équipe d'assistance lorsque je ne peux pas utiliser le site correctement pour pouvoir m'aider.
Quelle est la différence?
Comme vous pouvez le constater, le nombre de détails fournis est certes différent, mais de nombreuses informations ne sont disponibles que dans le récit, à savoir le but que nous essayons d'atteindre avec cette fonctionnalité.
Même s'il peut sembler que l'objectif est relativement peu important, il s'agit d'une hypothèse erronée dans le développement agile. Il existe généralement deux cas dans lesquels connaître le but est très important: réduire le coût des opportunités et permettre l’agilité.
Coût d'opportunité
S'il existe des hypothèses cachées dans l'exigence, cela pourrait être très difficile à réaliser. Par exemple: un serveur de messagerie est-il disponible? Si ce n’est pas le cas, l’exigence risque de prendre beaucoup plus de temps à être développée. Dans d’autres cas, il est possible que la conception ne permette pas d’atteindre un objectif plus simple.
En revanche, la user story concerne un utilisateur qui contacte notre service de support. Si l'envoi d'un courrier est impossible ou trop coûteux, nous pouvons concevoir une solution différente sur-le-champ: écrire dans une base de données, par exemple, utiliser un formulaire via Google Documents ou simplement mettre une adresse e-mail à la place du formulaire. Cela ne peut pas être facilement fait avec une exigence, mais c'est facile avec une histoire et une personne présente.
Agilité
Pour cette raison, avec les exigences, nous avons généralement tendance à penser à ces hypothèses cachées à l’avance et à nous assurer qu’il n’ya pas de problèmes. Donc, dans ce cas, il pourrait y avoir une exigence différente, planifiée à l’avance, qui garantissait la présence d’un serveur de messagerie.
Cela nous amène à une autre différence énorme entre les histoires et les exigences qui est la hiérarchie . Comme je l'ai expliqué plus haut, les exigences doivent, de par leur nature, être ordonnées selon une hiérarchie naturelle afin que les dépendances soient satisfaites. Les histoires, par contre, se concentrent sur le but recherché et n’ont aucune contrainte de ce type.
Ceci est voulu par la conception, car dans l'agilité, il est d'une importance fondamentale d'ajouter, de supprimer, de replanifier et de modifier les récits selon les besoins pendant l'exécution du projet. Les exigences peuvent généralement être ajoutées, parfois modifiées ou supprimées, mais il est généralement très pénible de les déplacer en raison de toutes les dépendances. Ce n'est tout simplement pas fait très souvent. Si vous travaillez avec des exigences, votre mise en œuvre agile en souffrira, ou ne le sera probablement pas du tout, en ce sens qu’il sera capable d’accepter le changement.