Discussion :

[arno03]

Bonsoir tout le monde.

Je suis en train de créer mon premier product backlog dans le cadre d'un projet universitaire, et je me pose quelques questions.

Dans un premier temps j'ai crée mon UC Model, à partir duquel j'ai dégagé des User Stories. Ensuite, pour le product backlog, j'ai mis tous mes User Stories sous la forme "En tant que...je peux...afin de..." que j'ai priorisé, mais mon problème est de savoir ce que je dois mettre après les US ?

Je pense qu'il faudrait mettre des choses telles que "Installation des serveurs", ou "Test", mais sous quelle forme ?

Merci d'avance pour vos réponses.

Arnaud

[rad_hass]

Il y a ceux qui mettent dans le Product Backlog, ce qu'on appelle des Story Technique... D'autres le déconseillent compte tenue du fait qu'elle n'apporte pas directement de la valeur ajoutée à l'utilisateur... Une story technique c'est typiquement une Installation des serveurs, travaux d'archi, analyse de solution... Ce qui prend du temps à l'équipe, alors en général vaux mieux le mettre dans le product backlog de mon point de vue.

Par contre le test je ne le mettrai pas au même niveau... Pour moi ça serait plutôt une tâche d'une story... Donc pas directement présent dans le backlog.

Good luck

[arno03]

Merci pour ta réponse

1. Je pense que je vais les inclure dans mon backlog, mais dois-je rester dans le format "En tant que___je peux___afin de"
Ex : En tant que développeur je dois installer les serveurs afin d'héberger le site.

2. De plus, j'aimerais savoir, pour l'élaboration d'un product backlog de haut niveau, à partir de mon UseCase Model j'ai écrit mes UserStories dans mon backlog, et maintenant je dois passer au RoadMap.
J'aimerais savoir si je dois découper les releases de mon RoadMap en UC ou en US ?
Ex :
UC 1 = US1.1, US1.2, US1.3
UC 2 = US2.1, US2.2, US3.3
Est ce que dans ma release 1 je peux avoir uniquement US1.1 et US2.2, et donc ne pas reformer le UseCase en entier ?

Merci d'avance

[rad_hass]

Le format que tu indique est celui qui est conseillé pour une user story (cf Mike Cohn)... Qui n'a pas beaucoup de sens pour une technical story... Il faut surtout se poser la question de l'utilité de ce que tu fais quand tu es en mode agile, faire du formalisme pour en faire

Pour ta question 2, personnellement je ne suis pas persuadé de l'utilité de l'utilisation d'Use Case et d'User Story en même temps :-), toutefois ça dépend du contexte et des personnes impliquées dans le projet... Si je fais le parallèle avec ce que j'utilise habituellement un UC pour toi serait une feature pour moi, donc non ça ne me choque pas qu'une (ou plusieurs) User Story soit fini dans un sprint et pas certaines appartenant à la même feature.

[arno03]

Merci pour tes réponses c'est plus clair maintenant.

J'aimerais savoir si dans un product backlog de haut niveau, on trouve des User Stories ou des Uses cases (features) ?

[rad_hass]

J'ai fais le parallèle entre tes Uses Cases et mes features, peut être maladroitement car ce n'est pas la même chose concrètement...

Une feature est une fonctionnalité de ton produit, elle peut être contenu dans le product backlog avant son découpage en story... Mon parallèle avec tes Uses Cases, était juste en rapport avec ta formule UC1 = US1.1 + US1.2 qui correspond à mon découpage d'une feature en story ;-)...

Maintenant pour ta question je ne comprend pas la notion de haut niveau... Tu veux dire d'un point de vue User ? Les seuls éléments à cacher se sont les stories techniques... Donc on voit les users stories et les features.

[Drawingrom]

Le backlog est orienté "valeur métier" pour l'utilisateur, d'où le formalisme "En tant que ... je veux ... afin de <valeur métier>". Il n'y a pas forcément de corrélation entre UC et US (enfin, je dis ça mais je n'ai pas l'habitude de faire d'analyse en UC).

Quand tu vas faire un backlog avec un product owner, je pense que c'est plus réaliste d'avoir une discussion sur la valeur apportée plutôt que sur les uses case (c'est plus un truc de MOE à l'ancienne...).

[AsPrO]

Dans le product backlog tu ne trouves que des users stories, car c'est fait par un product owner qui est généralement du coté client.

Les uc se trouvent dans les sprint backlog car fait par la team de développeurs. Un US est décomposé en task ( UC ), et l'ensemble de ces task forment donc une US


US1 = UC1 + UC2 + UCn et pas l'inverse :p

[arno03]

Merci pour vos réponses

[Paradisma]

Je suis un peu confuse, quelle est la difference entre UC et US !?
Un exemple Svp. Merci beaucoup.

[rad_hass]

Je suis un peu confuse, quelle est la difference entre UC et US !?
Un exemple Svp. Merci beaucoup.

Use case viens d'UML avec le diagramme des cas d'utilisation, ça représente une séquence d'action utilisateur... Et c'est visuel car diagramme.

User Story très utilisé en Scrum est une description d'une fonctionnalité... Textuel... Qui laisse une grande part à l'échange orale.

Les deux sont utilisés pour définir le besoin utilisateur... Donc bien qu'ils aient le même objectif ce sont des outils distinct.

@AsPrO je ne suis pas d'accord avec le fait qu'une US est une ou plusieurs UC. Comme je ne suis pas d'accord avec le fait qu'une UC soit assimilé à une tâche. Tout comme je ne suis pas d'accord qu'une UC soit faite exclusivement par les dev...

[Paradisma]

Use case viens d'UML avec le diagramme des cas d'utilisation, ça représente une séquence d'action utilisateur... Et c'est visuel car diagramme.

User Story très utilisé en Scrum est une description d'une fonctionnalité... Textuel... Qui laisse une grande part à l'échange orale.

Les deux sont utilisés pour définir le besoin utilisateur... Donc bien qu'ils aient le même objectif ce sont des outils distinct.

@AsPrO je ne suis pas d'accord avec le fait qu'une US est une ou plusieurs UC. Comme je ne suis pas d'accord avec le fait qu'une UC soit assimilé à une tâche. Tout comme je ne suis pas d'accord qu'une UC soit faite exclusivement par les dev...

Justement, c'est ce que je savais aussi, mais les réponses disant qu'un US= Plusieur Uc m'as perturbé un peu !!

Merci