Comment rédiger des user stories en tant que développeur?

J'écris un système où le propriétaire du système et moi-même sommes des développeurs, et nous sommes actuellement la seule source de `` demandes '' ou d'exigences pour le système, que j'aimerais capturer dans des user stories liées aux fonctionnalités {1}. Ma priorité urgente est maintenant de faire en sorte qu'un arriéré manageable soit saisi. Comment dois-je procéder pour capturer le niveau de spécifications techniques avec lequel je suis habitué à travailler dans les histoires d'utilisateurs, qui ne sont pas censées être trop techniques.

{1} J'évalue le service de gestion de projet agile TargetProcess , et chaque user story doit être liée à une fonction parent. Le système semble un bon ajustement, donc cette petite contrainte est quelque chose avec laquelle je préfère travailler plutôt que de contourner.

Le modèle d'histoire typique est très facile à visualiser:

As a [ROLE] I need to [WHAT] so that/because [WHY].

La chose intéressante est que l'importance des composants est inversée.

POURQUOI est plus important que QUOI et qui est plus important que ROLE

Exemple utilisant cette question

En tant que développeur de logiciels, j'ai besoin d'apprendre à écrire des histoires d'utilisateurs afin de pouvoir remplir le backlog avec des brouillons pour démarrer les discussions sur les fonctionnalités et obtenir des points qui leur sont attribués.

Rien de plus ne fait que compliquer l'intention et la mise en œuvre des User Stories.

Outils supplémentaires (l'intégration est préférable)

Les outils peuvent être utilisés pour capturer des informations détaillées supplémentaires sur les histoires qui sont capturées lors de leur discussion pour attribuer des points / estimations, mais ces détails ne doivent pas faire partie de l'histoire elle-même. Quelque chose d'aussi simple qu'un wiki avec 1 page par histoire pour mettre les détails / transcriptions des discussions sur est une bonne solution. La feuille de calcul Excel est une solution terrible.

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.