Exemples de conception et d'implémentation pour une fonctionnalité dans Scrum?

Question

Si je divise le développement d'une caractéristique particulière en plusieurs histoires:

• première pour une conception de haut niveau de la fonction,
• Basé sur la première histoire que je crée d'autres histoires pour développer les différentes pièces autonomes qui compose la fonction,

Cela signifie-t-il que je fais une cascade? En outre, si je divise le développement des pièces autonomes identifiées précédemment en conception et en mise en œuvre. Cela voudrait-il dire que je fais une chute d'eau?

Note: Je suis un grand novice de Scrum.

Answer 1

Il n'y a pas une telle chose comme histoires de conception et de mise en œuvre, User Stories devrait fournir un certain niveau de fonctionnalité de bout en bout à l'utilisateur (à savoir la livraison de la valeur client).

Le fait que vous mixez les termes histoires et caractéristiques ne permet pas de communiquer, mais ce que vous décrivez sons réellement comme des tâches (Sprint niveau de backlog), pas des histoires d'utilisateur (produit niveau de backlog).

Et si ce ne sont pas des tâches, alors ce sont de très mauvaises histoires.Peut-être que la "fonctionnalité" est trop grande et vous devriez put the story on diet mais ce que je vois ici est un story smell typique.

Si vous êtes nouveau User Stories, je recommande vivement d'utiliser la template régulière (En tant que type d'utilisateur <>, je veux < un but> de sorte que < une raison quelconque>) et aussi de suivre la INVEST modèle. Cela vous aidera vraiment à éviter les pièges comme celui de votre question. Retour à la vraie question (est-ce que je fais une cascade?): Il n'y a rien de mal à faire du design dans un sprint (comme une tâche d'une histoire). Mais si toute votre histoire porte sur le design, vous ne faites pas vraiment de Scrum, vous êtes censé fournir un incrément de bout en bout démontrable à la fin du Sprint.

Answer 2

Non, vous n'êtes pas. Les sous-tâches peuvent être ajoutées au backlog (vraisemblablement avec une priorité à peu près égale afin qu'elles sortent à peu près au même moment) et ensuite la super-tâche consisterait à intégrer/tester/etc les composants séparés.

Cela me semble être un moyen valable de décomposer un grand composant pour moi. Assurez-vous de bien dimensionner les différents morceaux de manière appropriée. J'ai trouvé que les morceaux de 4 à 16 heures marchaient mieux. Donner 40 heures pour une tâche signifie qu'ils vont faire 2 heures de travail jusqu'à vendredi quand ils entassent les 32 autres (avec beaucoup de bugs).

Answer 3

histoires Scrum ont tendance à être sur « business value »:

valeur d'entreprise est un concept qui décrit la valeur relative de tout effort de développement de l'entreprise. La valeur commerciale est souvent non quantifiable, mais souvent liée à l'argent.

Vous pouvez considérer la valeur commerciale comme quelque chose qui pourrait encore être vendu si le projet était arrêté. Si vous écrivez une histoire pour créer: «un design de haut niveau de la fonctionnalité», ce que vous pourriez produire en mettant en œuvre cette histoire n'est pas quelque chose que l'entreprise peut vendre. Ce n'est pas quelque chose que les clients peuvent essayer, acheter, utiliser. En effet, la valeur commerciale de cette histoire est nulle.

Vous pourriez avoir plus de chance de penser à des histoires «verticalement». "Vertical slices" sont des fonctionnalités minimales qui couvrent l'ensemble de votre pile technologique. Par exemple: "Un utilisateur doit pouvoir entrer son nom dans une zone de texte, cliquer sur un bouton et afficher son enregistrement dans la base de données." Ce n'est pas, en soi, particulièrement utile, mais il est plus précieux que la conception d'une fonctionnalité.