Concentrez-vous sur le quoi et le pourquoi et évitez le comment lors de l'écriture des user stories.
Ce à quoi vous êtes confronté est en fait un très bon exercice pour tous les développeurs. Être capable d'exprimer l'exigence en termes simples et commerciaux est une compétence importante.
Vous devez vous concentrer sur l'exigence générale telle que "besoin d'être en mesure de faire une seule sélection dans une liste déroulante d'objets afin que l'utilisateur puisse activer l'action Foo" au lieu de spécifier à l'aide d'une zone de liste déroulante ou d'une liste ou tout ce qui déclenche une routine spécifique .
Une autre façon d'aborder cela est de prétendre que la base / le cadre de code sous-jacent est une boîte noire presque complète. Chaque fois que vous vous retrouvez à dire "utiliser l'objet XYZ", vous pouvez vérifier vous-même en vous demandant si vous le savez dans un système de boîte noire.
Mise à jour:
OMI, il est correct de mettre des détails dans un cas d'utilisation qui indiquent le niveau de détail requis pour les informations. Par exemple, avec un système d'inscription, il est juste de spécifier
- nom de famille; champ obligatoire
- prénom; champ obligatoire
- ID de compte; le système n'a généré aucune entrée nécessaire
- signe astrologique; champ facultatif - (suggestion) fournir une recherche en entrant la date de naissance?
- etc....
L'essentiel est que vous ne spécifiez pas le mode technique de ces informations. Si vous vous dites "utilisez une classe String / un tableau de caractères / ou un champ varchar" pour le nom de famille, alors vous savez que vous spécifiez trop.
Si vous êtes multilingue, utilisez deux langues disparates comme test décisif. Par exemple, les chaînes en C sont généralement des tableaux char (acter) alors que C ++, Java et C # (d'accord, et presque tout le monde ...) ont un véritable objet de type String. Si vous constatez que votre spécification est invalidée en utilisant l'une de ces langues, vous saurez que vous avez sur-spécifié.
Il convient de noter que j'utilise spécifiquement le terme Cas d'utilisation par opposition à User Story , bien que la variante que j'utilise est un hybride des deux. Mon objectif d'un cas d'utilisation est de donner un aperçu de ce qui se passe (une User Story dans le sens le plus strict) mais ensuite de passer en revue les acteurs, les systèmes et les fonctionnalités générales nécessaires. Mon approche est plus proche de ce que Fowler suggère dans cet article wikipedia par opposition à l'approche de Cockburn.
J'aurai donc un cas d'utilisation unique (ou plus) pour le scénario d'inscription ou l'élément de travail. Si c'est vraiment complexe, je le décomposerais en multiples, mais ce n'est pas grave. Le cas d'utilisation peut ensuite être décomposé en tâches individuelles selon les besoins. Ce qui est jeté dans une mêlée particulière dépend de beaucoup de variables, mais rien dans cette approche ne vous empêche d'avoir un composant démontrable à la fin de la mêlée.
