La documentation est-elle une User Story? [fermé]

13

Fermé . Cette question est basée sur l'opinion . Il n'accepte pas actuellement les réponses.

Voulez-vous améliorer cette question? Mettez à jour la question afin d'y répondre avec des faits et des citations en modifiant ce message .

Fermé il y a 4 ans .

Nous devons faire de la documentation utilisateur pour un produit sur lequel nous travaillons depuis quelques sprints. Nous commençons maintenant un nouveau projet dans le prochain sprint et l'OP fait de la documentation pour le produit produit précédemment une histoire d'utilisateur pour ce sprint.

Je me demande simplement votre avis sur cette approche. Personnellement, je ne suis pas d'accord pour dire que la documentation est une User Story dans Scrum car elle ne produit aucun code.

EDIT: Merci pour vos opinions les gars. Je pensais qu'un sprint devait implémenter un incrément de logiciel de travail, mais vos opinions ont changé ma perspective. Merci pour toutes vos réponses.

scrum user-story

— ediblecode
source

vous vous interrogez sur la création d'une user story pour créer la documentation du système, ou sur l'utilisation d'une user story comme documentation du système?

— Ryathal

Je pense que d'autres ont déjà fourni la réponse que vous recherchez, mais en général, presque tout travail effectué par votre équipe est une histoire. Bien qu'elles soient appelées «histoires d'utilisateurs», elles peuvent être saisies du point de vue (ou du besoin) de toute partie prenante d'un projet, qui comprend également vous, le développeur (par exemple, «En tant que développeur, j'ai besoin de ..... tas d'internes .... ")

— DXM

2

Si vous pouvez terminer et être payé pour une user story sans écrire de code, sautez par dessus.

— JeffO

1

@JeffO - Je préfère de loin écrire du code merci. Peut-être que je peux écrire le code pour écrire la documentation ... Sorte d'une machine Light Von Neumann: p

— SoylentGray

15

«En tant qu'utilisateur de X, j'ai besoin de savoir comment fonctionne X» me semble une histoire d'utilisateur légitime. Cela pourrait entraîner une documentation écrite ou une aide en ligne.

Le point n'est pas seulement du code - il répond aux exigences des utilisateurs.

— Matthew Flynn
source

6

Les opérateurs, administrateurs et autres techniciens sont des utilisateurs de première classe. Ils obtiennent des histoires d'utilisateurs comme tous les autres utilisateurs.

— S.Lott

10

Idéalement, la documentation fait partie de chaque user story et ne s'accumule jamais. Mais, dans le monde réel, cela n'arrive pas souvent. Dans ce cas, vous devez créer une user story pour rattraper une pièce manquante spécifique de la documentation.

Vous avez raison, cela ne produit aucun code. Mais il satisfait une exigence de l'utilisateur et doit être priorisé par rapport aux autres exigences de l'utilisateur.

Si cela signifie que cela ne se fait jamais, parce que telle ou telle fonctionnalité est en cours de travail, vous n'avez probablement pas eu besoin de la documentation si mal.

— pdr
source

3

Si une documentation est nécessaire, elle peut éventuellement faire partie de la définition de done.

— Hugo

3

Je suis d'accord avec l'évaluation de la documentation de pdr s'il s'agit d'une documentation requise, technique ou de projet. Idéalement, il devrait être intégré dans le travail de sprint.

La documentation du produit me semble très différente car c'est un produit livrable demandé par l'utilisateur réel et fournit directement de la valeur à l'utilisateur. Il faut bien entendu comprendre que la documentation produit n'est pas essentiellement une tâche technique mais une tâche fonctionnelle, et peut ou non être une activité appropriée pour une ressource technique sur le projet.

Je pense que cela devrait être une histoire d'utilisateur, mais je pense qu'une ressource de projet qui a une bonne compréhension des exigences commerciales, du point de vue de l'utilisateur et de bonnes compétences en rédaction technique devrait se voir confier ces tâches. Idéalement, ce serait un analyste commercial s'il en existe un, ou peut-être un testeur d'assurance qualité de niveau supérieur avec une solide compréhension des exigences, des histoires d'utilisateurs et de bonnes compétences en rédaction technique. Cela pourrait également être un développeur, mais la documentation produit écrite par les développeurs a tendance à ne pas être de haute qualité ou aussi utile car les développeurs sont généralement trop proches des détails techniques.

— maple_shaft
source

1

Dans notre organisation, l'équipe outillage, en charge de la maintenance et de l'amélioration de notre système d'intégration continue, utilise Scrum pour les aider à gérer leur travail. Ils n'écrivent pas de code mais ils pratiquent néanmoins Scrum.

Pour répondre spécifiquement à votre question, je voudrais savoir si l'équipe considère que la documentation fait partie de la "Définition de Terminé" ou non.

Si l'équipe considère que la documentation fait partie de la "définition du fait", alors il n'est pas nécessaire d'avoir une histoire supplémentaire et l'histoire ne peut être acceptée que si la documentation est écrite et validée.

Si l'équipe considère que la documentation ne fait pas partie de la "définition du fait", je créerais une histoire distincte afin que le Product Owner puisse gérer son travail.

— David Segonds
source