histoires de l'utilisateur contre les cas d'utilisation

Question

sont des cas d'utilisation juste de multiples histoires utilisateur ??

Quels sont les avantages de l'utilisation des témoignages d'utilisateurs sur les cas d'utilisation .. et vice-versa ... Quand utiliser un autre ... plus Est-ce que toutes les méthodes agiles utilise des histoires utilisateur ??

Answer 1

En fait, les cas d'utilisation d'origine (voir Jacobson ) était assez léger , autant que des témoignages d'utilisateurs sont maintenant. Au fil du temps, ils ont évolué jusqu'à ce qu'un format commun pour les « cas d'utilisation » est maintenant un document compliqué avec les entrées, les sorties, l'héritage, utilise les relations, etc., programmeurs pseudocode, en général, tentent de tout convertir en programmation.

Dans tous les cas, la tentative de définir ce qui distingue un « cas d'utilisation » d'une « histoire d'utilisateur » vient d'un « scénario » est assez futile, car il est difficile de trouver deux autorités qui sont d'accord. \

Personnellement, je trouve le motif "[Actor] [verbes] [nom] pour obtenir [valeur commerciale]" utile. Si elle obtient plus d'un paragraphe de texte, il peut être trop grand.

Answer 2

Quand il revient à lui « agile » est juste une étiquette, et les gens sont en désaccord sur exactement ce que cela signifie. De même que les gens appellent des choses très différentes « cas d'utilisation ».

Dans mon expérience, la principale différence entre les deux est que l'histoire de l'utilisateur se concentre sur l'utilisateur, et est généralement plus courte et moins formel - idéalement, il devrait facilement tenir sur une carte postale. Il ne donne pas de détails probablement de la gestion des erreurs, etc.

Les cas d'utilisation peut beaucoup plus formelle (bien que certaines personnes les écrire de façon informelle aussi) - ils se concentrent sur chaque interaction avec le système, et peut bien aller plus en détail sur plusieurs systèmes différents / acteurs / etc dans le même cas d'utilisation.

C'est juste mon expérience bien - les chances sont tout le monde aura utilisé ces outils de différentes façons. Je ne serais pas trop accroché sur les étiquettes -. Il suffit d'utiliser ce qui fonctionne pour votre projet

Answer 3

Les cas d'utilisation ne sont pas des compilations d'histoires d'utilisateur.

histoires de l'utilisateur sont généralement beaucoup plus simple que les cas d'utilisation. Je pense que les cas d'utilisation tentent de couvrir absolument tout à voir avec le comportement de certains aspects du système. Autrement dit, tous les comportements, tous les chemins d'erreur et toute la gestion des exceptions.

Le modèle recommandé pour un utilisateur est:

  

En tant que (rôle) Je veux (quelque chose) de sorte que (avantage)

(Merci Mike Cohn pour fournir ce modèle simple)

Les descriptions des comportements exprimés comme celui-ci sont plus agiles.

Ce type de modèle permet de décrire le comportement en utilisant différents niveaux de détail. Par exemple:

1. pour ces histoires en cours d'exécution dans un sprint beaucoup plus tard, vous pouvez décrire le comportement dans une sorte de haut niveau de façon, par exemple en tant que membre de l'équipe ops je veux surveiller le système à distance afin que je puisse déterminer la santé du système sur la route.
2. pour les histoires mises en œuvre dans le prochain sprint, vous pouvez décrire le comportement est une manière un peu plus détaillée, par exemple en tant que membre de l'équipe ops je veux avoir un ops dédié uniquement connexion afin que je puisse vérifier la santé du système.
3. pour les histoires mises en œuvre dans le sprint actuel, vous pouvez décrire le comportement d'une manière très détaillée, par exemple en tant que membre de l'équipe ops je veux avoir une interface web afin que je puisse vérifier l'état actuel du serveur ftp ingest.

IMHO Les cas d'utilisation sont beaucoup plus sculptées dans la pierre! Et peut donc être un problème de mise à jour après la version initiale.

HTH

Cheers,

Rob

Answer 4

En un mot, non.

Cas d'utilisation sont les spécifications détaillées généralement traçons comment une pièce particulière de fonctionnalité va travailler, ou comment un utilisateur spécifique va utiliser le système. Il est typiquement dans la voix d'un utilisateur spécifique (ou acteur) et est assez autonome.

Une histoire d'utilisateur d'autre part est « une invitation à la discussion ». Il est généralement une ou deux phrases. est une bonne ressource pour cela. Et Mike Cohn Histoires de l'utilisateur appliquée vaut bien la peine.

La syntaxe typique est « En tant que J'ai besoin pour atteindre » ou « Pour atteindre comme J'ai besoin » qui entraîne la maison la valeur de l'histoire.

histoires de l'utilisateur sont pas destiné à être autonome, mais destiné à inviter à la discussion de l'histoire entre le développeur et le client (ou proxy client).

Answer 5

Vous pouvez penser à un usecase comme une histoire d'utilisateur, mais pas l'inverse. Un usecase couvrira plusieurs « fins » à l'histoire, des exigences particulières (par exemple les champs de formulaire doit être entré au format xyz, et affichera un message d'erreur 123 si l'utilisateur entre un champ dans le mauvais format). En outre, un usecase peut inclure des références supplémentaires à des documents externes, tels que les consignes de sécurité.

Answer 6

Histoires de l'utilisateur est un outil utilisé dans le développement Agile pour vous assurer que vous créez le produit de votre utilisateur a vraiment besoin.

• Il décrit plutôt pourquoi vous devez faire ceci ou cette fonction au lieu de Comment ou Quelle est la caractéristique .
• De mon expérience personnelle, il est un excellent moyen d'équilibrer la vision du client et développeur de créer un meilleur produit.

Contrairement aux Etats-Unis Cas d'utilisation met l'accent sur l'OMS utilise votre produit. Voici la différence.

Je dirais qu'il n'y a pas d'autre instrument pour un développeur agile comme User Stories. Si vous voulez apprendre à les écrire, vérifier avec succès ce poste.