Séparer le quoi du comment - Concevoir dans un environnement agile [fermé]

Question

Dans un environnement agile (Scrum), comment amener la direction produit à créer des éléments ou des histoires de backlog suffisamment petits sans lui demander de faire toute la conception, ce qui n'est pas sa spécialité ?En d’autres termes, comment séparer le quoi (les exigences métier) du comment (la conception) dans le développement agile ?

Answer 1

Avec Scrum, le gestion des produits devrait être une seule personne :le propriétaire du produit .

Ce que vous voulez faire est fait pendant le planification des sprints, où toute l'équipe (product propriétaire, scrummaster, développeurs) doit être présente.

Le quoi devrait être défini comme Histoires d'utilisateurs par le propriétaire du produit .Les user stories sont censées être de haut niveau, ce qui limite votre propriétaire de produit à exprimer les exigences commerciales dans les histoires d'une phrase devraient faire l'affaire.

par exemple. En tant qu'utilisateur de StackOverflow, j'aimerais voir ma réputation

L'un des objectifs de la planification du sprint est de décider des histoires à réaliser pendant le sprint.Ainsi, lorsque les histoires sont choisies par le Product Owner, l'équipe peut les subdiviser, parler brièvement du design (le comment) et les estimer.

En un mot, le quoi doit être effectué par le propriétaire du produit, le comment par l'équipe.Si ce processus est clairement expliqué au Product Owner, il n’essaiera pas de tout concevoir.S'il essaie quand même, le scrummaster l'arrêtera.

Answer 2

La première chose que vous devez faire, et c'est la cause d'un grand nombre d'échecs de projets Scrum, est d'apprendre à votre gestion de produit à jouer le rôle de Product Owner.Vous devez lui montrer qu'il est responsable du retour sur investissement du projet, et pour cela, il est responsable de la priorisation des histoires/éléments/besoins commerciaux/fonctionnalités ou tout ce que vous utilisez pour composer votre backlog produit de la manière la plus efficace possible. les objets de valeur ont des priorités plus élevées.

Je suis favorable à l'utilisation des user stories comme éléments du backlog produit, puis, lors de la planification du sprint, à la répartition sur des tâches plus petites des stories sélectionnées pour composer le backlog du sprint.

Ce que vous devez toujours garder à l'esprit lorsque vous rédigez ou aidez votre PO à rédiger vos user stories, c'est que les histoires doivent être INVESTISSÉES. jeindépendant, Nnégociable, Vutile aux clients, Eestimable, Scentre commercial et Testable.

Je pense qu'au début, l'utilisation du modèle ci-dessous pourrait être utile pour que le bon de commande reste concentré sur les objectifs commerciaux :

"En tant que - type d'utilisateur -, je veux - un objectif - pour que - une raison -."

Un exemple d'histoire serait "En tant qu'utilisateur de stackoverflow, je souhaite voter sur une réponse afin que la réponse la plus précieuse puisse être facilement trouvée."

N'oubliez pas de faire rédiger le PO ou de définir le test d'acceptation pour chaque histoire de votre Sprint Backlog car il peut être utilisé comme critère de base pour déterminer si une histoire est entièrement mise en œuvre.

Pour l'exemple ci-dessus, deux tests d'acceptation possibles sont :

"Testez pour voter une réponse"

"Testez pour voter contre une réponse"

Avec cette histoire et deux tests d'acceptation, l'équipe sait que l'utilisateur de stackoverflow peut voter sur les réponses et que pour que le statut de l'histoire soit mis à jour et terminé, il est nécessaire que le système permette à l'utilisateur de voter pour ou contre une réponse sans lever d'exceptions.

Answer 3

N'oubliez pas que les éléments du backlog produit doivent être classés par ordre d'importance, en utilisant un système de pondération (nombres premiers, fibonacci,..), de sorte que si vous avez des éléments dans votre backlog, ceux d'importance similaire (c'est-à-dire2 éléments d'un poids de 21), alors ils devraient en théorie tous deux tenter de s'insérer dans le sprint devant les 13 et les 8.

Answer 4

Pendant la (ré)estimation du backlog (après priorisation), l'équipe doit effectuer de la modélisation afin de comprendre toute l'étendue de la User Story et être en mesure d'estimer avec précision la complexité.Ce n'est pas toute l'étendue de la modélisation qui peut avoir lieu (les équipes peuvent faire davantage de développement), mais c'est un excellent point de départ et permettra de profiter de la présence du client/propriétaire du produit pour répondre aux questions. et puis.

En conséquence, la discussion qui en résultera vous aidera à travailler avec le Product Owner pour diviser ses exigences en une granularité significative et appropriée.