Scrum Rituals: Sprint Demo

Demo Scrum Sprint: un guide complet

Prise des clés: La démo de sprint présente des travaux de sprint terminés, permettant au propriétaire du produit de valider les critères d'acceptation. Il clarifie les travaux terminés, améliore l'estimation et informe la vitesse de l'équipe. L'accent est mis sur la valeur démontrable, et non sur des détails techniques ou des problèmes (ceux-ci appartiennent à la rétrospective). Les fonctionnalités acceptées sont ensuite intégrées (publiées) selon un calendrier durable.

(Cette section est basée sur Scrum: Novice to ninja par M. David Green. Disponible dans les magasins et comme un ebook.)

La démo de sprint, tenue à la conclusion du sprint, est un rituel crucial. L'équipe de développement démontre des travaux terminés, tandis que le propriétaire du produit évalue l'achèvement contre les critères d'acceptation, l'acceptation ou le rejet de chaque histoire. Cela fournit une image claire de la progression du sprint et affine l'estimation future.

Objectifs de démonstration de sprint:

L'objectif principal est de comprendre la sortie du sprint et l'état mis à jour du produit après l'intégration. Les histoires acceptées déterminent la vitesse de l'équipe, améliorant les futures estimations du backlog de sprint.

Invités à la démo Sprint:

Bien que les invités soient les bienvenus observateurs, leur présence ne devrait pas perturber les objectifs de la démo ou le TimeBox. Ce sont des observateurs, pas des participants, à moins que la rétroaction ne soit activement sollicitée.

Timeboxing La démo Sprint:

L'allocation de temps dépend du nombre et de la complexité des histoires terminées. Une demi-journée est courante pour les sprints de deux semaines. Le Scrum Master garantit l'adhésion au temps alloué.

combinant la démo et rétrospective:

Souvent, les équipes planifient la rétrospective le même jour pour minimiser les perturbations de la productivité. Cependant, cela priorise les artefacts Scrum sur le développement de produits tangibles - un compromis nécessitant une attention particulière.

Préparation pour la démo sprint:

La démo présente toutes les histoires "faites", quel que soit le statut de libération. Chaque membre de l'équipe contribuant doit être prêt à expliquer son travail. Une réunion avant lemo avec le propriétaire du produit assure l'alignement avec les critères d'acceptation et se prépare aux manifestations. Le Scrum Master coordonne la préparation et garantit que la démo s'adapte dans le TimeBox.

Demos axés sur le propriétaire du produit:

Alors que les ingénieurs peuvent présenter, le propriétaire du produit effectue des tests en direct est bénéfique. Les ingénieurs connaissent le «chemin heureux», mais le propriétaire du produit identifie les cas Edge et priorise les critères d'acceptation, assurant des tests complets et l'engagement des parties prenantes.

démontrer une histoire:

Le Scrum Master guide le processus, en examinant systématiquement chaque histoire. Le propriétaire du produit lit les critères de l'histoire et de l'acceptation pendant la création de la démo, garantissant que tout le monde comprend les attentes. La démo se concentre sur l'ajout fonctionnel au produit, démontrant l'exécution de chaque critère d'acceptation. Les critères d'acceptation inadéquats identifiés lors de la démo résultent de nouvelles histoires pour les futurs sprints.

Éviter une discussion détaillée sur les questions:

Bien que de précieuses discussions détaillées sur les défis de développement devraient être reportées à la rétrospective. Se concentrer sur le produit empêche la démo de s'enliser dans les détails techniques.

Points et vitesse de comptabilité:

Le Scrum Master calcule la vitesse du sprint en fonction des points attribués aux histoires acceptées. Les histoires rejetées ou incomplètes sont suivies et leur statut mis à jour. Les rapports résumant les progrès du sprint sont souvent générés.

Libérer les histoires:

La libération intègre des fonctionnalités terminées dans le produit en direct. Les méthodes de libération varient; Certaines équipes sortent immédiatement, tandis que d'autres regroupent des histoires pour des versions plus grandes. L'intégration continue prend en charge la version immédiate, éliminant les étapes de libération post-Demo.

Intégration continue:

Avec une intégration continue, les ingénieurs ne devraient pas abandonner une histoire jusqu'à ce qu'il soit sorti et testé. Cela peut nécessiter un temps dédié pour la maintenance et l'amélioration.

Planification des versions:

Les horaires de libération doivent s'aligner sur le rythme durable de l'équipe et les objectifs du propriétaire du produit, et non les délais arbitraires. Évitez de vous précipiter pour respecter les délais au détriment de la qualité; prioriser les fonctionnalités critiques si nécessaire.

Questions fréquemment posées (FAQ)

(La section FAQ a été omise par la brièveté, car elle répète en grande partie des informations déjà couvertes dans le texte principal.)

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!