Est-ce une bonne idée d'écrire les spécifications des exigences par histoires?

Nous utilisons actuellement des méthodes agiles dans mon projet actuel, et nous avons des tas d'histoires comme celles-ci:

• En tant qu'assistante, je veux rembourser un client afin qu'il puisse obtenir un peu d'argent quand il le demande

• En tant que client, je souhaite régler un achat afin de pouvoir recevoir mon article.

Jusqu'à présent, nous avons choisi les histoires les plus importantes à chaque sprint et les avons élaborées dans un certain nombre de spécifications d'exigences formelles (nous regroupons certaines des histoires similaires dans la même spécification). Selon l'histoire, il peut s'agir simplement d'un bouton sur un écran ou d'un flux de travail complet.

Le problème est que, parce qu'il y a tellement d'histoires, ce n'est pas immédiatement clair, pour aucune partie du système, quelles histoires s'y rapportent.

Cela fonctionne au moment des développeurs, à chaque sprint, les développeurs reçoivent simplement une spécification décrivant ce qu'ils doivent faire et les changements qu'ils doivent apporter. Mais en termes de maintenance de cette liste d'histoires et de tests, cela commence à avoir des bogues de suivi très difficiles et en général juste à maintenir les spécifications, car une fonctionnalité de l'écran peut avoir été documentée à un certain nombre d'endroits différents car elle est divisé par histoire.

La rédaction de spécifications basées sur des histoires est-elle une bonne idée? Avons-nous écrit les histoires de la mauvaise façon?

Cela pourrait être controversé, mais c'est parti!

Nous avons travaillé sur un système en temps réel où l'un de mes anciens patrons a suggéré de faire AGILE! C'était vraiment facile de gagner la gestion sur ce point; cependant, c'était plus facile à dire qu'à faire.

Le concept d'histoires est bon - mais pour être très direct, il est assez vague. Qu'est-ce qu'une histoire, vraiment? Le vrai problème est que l'utilisation d'histoires alone(et à peu près la même chose pour les cas d'utilisation) a plusieurs problèmes - comme suit:

1. Les exigences ne peuvent pas être hors contexte (à moins que vous ne répétiez grossièrement tant de fois). Il existe des hypothèses, des connaissances de base et d'autres exigences qui sont également liées à une exigence donnée; elles n'ont de sens que dans un contexte et uniquement dans un ordre spécifique. La mise en œuvre de la plus importante est tout d'abord logique, mais lorsque vous les déposez au moins - conservez un référencement complet dès le début lorsque vous les collectez. Le mot d'exigence lui-même est complexe et n'est pas vraiment limité aux cas d'utilisation / histoires. En effet, les histoires sont exploitables, mais il y a ensuite des exigences qui peuvent ne pas être exploitables, telles que les performances, les contraintes à respecter, les règles métier, etc.

2. Les exigences doivent être appropriées en taille et de manière quantifiable, sinon vous ne pouvez jamais avoir besoin de plus d'une grande histoire! Qu'est-ce qui forme exactement 1 histoire?

   • s'agit-il d'un scénario détaillé complet? (par exemple, une histoire lorsque ATM rejette une transaction)
   • s'agit-il d'un ensemble d'actions que l'utilisateur effectue? (par exemple histoire complète sur le retrait)
   • ou s'agit-il d'un écran dans l'interface utilisateur? (par exemple, écran de retrait comme histoire complète).
   • Comment vraiment quantifier des règles métier très nettes avec des histoires? Honnêtement, cela peut être n'importe lequel des éléments ci-dessus. L'important est de savoir dans quelle mesure vous êtes confiné et granulaire. C'est un style assez personnel. Si cela fonctionne, c'est bien;

3. La connaissance du domaine est vraiment indispensable! Un exemple simple, d'un architecte qui connaît diverses propriétés du verre, de l'acier et du bois. cette connaissance ne fait pas partie du document d'exigence pour le bâtiment par exemple! De la même manière, si vous écrivez un logiciel bancaire - il y a tout un tas de concepts sur la banque. En les énonçant, car l' exigence elle-même la rend non traitable car elle ne vous dit pas ce que devrait faire le logiciel par opposition à la façon dont le monde fonctionne . L'histoire comprend-elle de telles subtilités de domaine? ou cela exclut-il cela?

4. Modéliser le monde est une condition préalable qui n'est pas tout à fait supportée par.
   Il y a eu beaucoup de littérature sur la modélisation qui se concentre uniquement sur la compréhension du fonctionnement du monde est une connaissance de base. La modélisation forme une base solide sur laquelle les exigences acquièrent un sens clair; mais une telle chose devrait être directe. Malheureusement, la plupart des pratiques agiles refusent la valeur de la modélisation initiale dans l'intérêt de livraisons plus rapides et plus légères; mais que je pense toujours que c'est un arrêt majeur quand les choses doivent évoluer. De nombreux projets réussissent non pas parce que la modélisation n'est pas pertinente - mais les ingénieurs expérimentés les connaissent dans leur tête et n'ont pas besoin de beaucoup de conseils explicites.

Voici donc votre question:

La rédaction de spécifications basées sur des histoires est-elle une bonne idée? Avons-nous écrit les histoires de la mauvaise façon?

Je pense que les histoires d'utilisateurs ont une valeur de verdict explicite donné par le client. Mais s'ils sont mal organisés et insuffisamment détaillés (ou vagues), il y a un problème. À moins que vous ayez une structure plus large pour accumuler la compréhension plus large (connaissance du domaine) et la portée (spécification totale). Histoires d'utilisateurs uniquement pour des segments ou des éléments d'un système plus vaste.

PS: J'ai une opinion exacte sur les cas d'utilisation (car ils sont représentés dans des diagrammes ovales) que si vous ne les placez pas dans le contexte approprié et à la granularité appropriée, ils ne font pas du bon travail. (Je les appelle des cas inutiles ). La seule source crédible que je trouve pour rendre l'écriture de cas d'utilisation vraiment évolutive et significative est la rédaction de cas d'utilisation efficaces par Cockburn

> Writing specs by stories? a good idea?

Oui si vous pouvez gérer les interdépendances et les priorités de vos histoires.

Voici un article sur les cartes d'histoires qui peuvent vous aider à commander et à gérer de nombreuses histoires d'utilisateurs.

Au moment d'écrire cette réponse, j'ai réalisé qu'il ne s'agissait pas de tests, mais de documentation. Vous devez d'abord lire le manifeste agile :

[Nous apprécions] un logiciel fonctionnel plutôt qu'une documentation complète

Vous devez donc rendre vos spécifications exécutables, c'est-à-dire les écrire sous la forme d'un ensemble de tests entièrement automatisé.

La rédaction de spécifications basées sur des histoires est-elle une bonne idée?

Oui, à mon humble avis, ça l'est. C'est ce qu'on appelle le «développement axé sur le comportement» ou la «spécification par l'exemple». En rubis, il y a un excellent outil de concombre qui aide beaucoup.

Le problème est que, parce qu'il y a tellement d'histoires, ce n'est pas immédiatement clair, pour aucune partie du système, quelles histoires s'y rapportent.

Pourquoi voulez-vous que ce soit clair? Je veux dire, avez-vous vraiment besoin d'une matrice de traçabilité "test / code"? L'avantage d'écrire des tests en tant que spécification est que vous n'avez pas besoin d'une traçabilité séparée «exigences / tests», car les tests deviennent des exigences. Aux fins des tests d'intégration, vous devez traiter votre logiciel dans son ensemble, et non comme des parties distinctes.

Vous pourriez avoir besoin d'un outil de couverture pour voir s'il y a des modules "morts", des parties de votre système non couvertes par vos tests de spécifications. Mais vous ne devriez vraiment pas vous soucier de la spécification à laquelle ce code particulier correspond. Cela devrait être vice versa: à partir d'une spécification particulière, vous devez savoir quelle partie du système lui correspond. Vous ne devez pas vous inquiéter de la duplication de vos spécifications. Et si vous appliquez un principe DRY à votre code, il y aurait des dizaines de spécifications exécutant le même code.

Cela fonctionne au moment des développeurs, à chaque sprint, les développeurs reçoivent simplement une spécification décrivant ce qu'ils doivent faire et les changements qu'ils doivent apporter. Mais en termes de maintenance de cette liste d'histoires et de tests, cela commence à avoir des bogues de suivi très difficiles et en général juste à maintenir les spécifications, car une fonctionnalité de l'écran peut avoir été documentée à un certain nombre d'endroits différents car elle est divisé par histoire.

Il n'est pas rare que des centaines de tests d'intégration soient interrompus par un petit changement dans un module critique. C'est là que les tests unitaires entrent en jeu.

Vous devez structurer vos tests en tant que tels afin de pouvoir déterminer si un test particulier couvre une exigence de haut niveau, ou juste un détail subtil de celle-ci. Dans ce dernier cas, vous devez séparer ce test de votre suite de tests d'intégration. Le but des tests unitaires est de localiser les bogues. Ainsi, si vous introduisez un bogue, il y aura un et un seul échec de test.

Avons-nous écrit les histoires de la mauvaise façon?

Je pense que vous avez juste besoin d'organiser vos histoires en épopées soit par utilisateur, par exemple "Client", "Assistant", soit par fonctionnalités / écrans / workflows ("Achat", "Remboursement").

Et encore une fois, les tests de spécification ne remplacent pas les tests unitaires. Lire la suite

Vous avez mentionné un problème et la façon dont vous le résolvez, mais vous oubliez de mentionner un exemple de vos spécifications et de votre regroupement et comment il est lié à la façon dont vous développez votre produit.

Écrire des spécifications par histoires? une bonne idée?

Agile ne l'interdit pas. En agile, vous pouvez faire tout ce dont vous avez besoin pour offrir une valeur commerciale maximale à un rythme durable. Donc, si la rédaction de spécifications est quelque chose dont vous avez besoin pour offrir plus de valeur commerciale, c'est absolument OK de le faire.

Votre exemple montre deux user stories. Ils sont peut-être en quelque sorte liés dans votre logique métier, mais c'est un scénario très courant.

Si vous avez besoin de suivre la fonctionnalité des histoires d'utilisateurs, vous pouvez à nouveau utiliser ce qui vous convient le mieux, y compris la documentation, certains diagrammes ou vos "spécifications", mais vous devez être prêt à ce que la maintenance de ces artefacts vous coûte plus cher à mesure que la complexité de l'application développée augmente. Donc, la seule question à laquelle vous devez répondre dans ce cas est: si je n'utilise pas mes spécifications, cela nous coûtera-t-il plus cher? Si la réponse est oui, vous avez choisi une meilleure option.

L'agile fonctionne mieux pour les projets de petite à moyenne taille avec une petite équipe où l'architecture entière est considérée comme une connaissance tacite partagée au sein de l'équipe. Au cours de la planification des itérations, vous passerez en revue vos histoires choisies, discuterez de l'impact sur la mise en œuvre actuelle et rédigerez certaines tâches nécessaires pour terminer l'histoire. La véritable documentation dans ce cas sera la suite de tests contenant les tests d'acceptation et d'intégration / unitaires automatiques. Une fois que votre SW ou votre équipe aura grandi, les connaissances tacites devront passer partiellement à une certaine documentation.

C'est là que l'abstraction joue un rôle majeur. Vous devez regarder les histoires en respectant la perspective pertinente. Rassemblez les noms et les verbes dans les déclarations et confirmez-les. Vous ne pouvez pas baser vos modèles sur des hypothèses personnelles . Faites également attention aux détails.

La rédaction de spécifications basées sur des user stories ne peut pas être précise. Vous devez creuser des détails supplémentaires et parfois ignorer les détails qui ne sont pas pertinents. Les spécifications doivent être rédigées lorsque votre modèle est complet et précis lors de la confirmation de votre analyste.