2016-02-10 6 views
-2

Mon entreprise a mis en place un nouveau processus pour que l'équipe soit responsable de la définition de fait à l'intérieur du sprint.Accepter le sprint dans la réunion de révision? Et d'autres questions de révision

Lors de la réunion de révision de sprint, le bon de travail est présenté pour la première fois et ils passent en revue chaque problème devant l'équipe, puis font des commentaires sur le problème, par exemple. "Est-ce que cela fonctionne comme prévu, sinon, comment?" Défaut créé ... "

En lisant beaucoup de choses sur Scrum cela ne semble pas être le" Scrum "était de faire des choses, en fait beaucoup de ressources disent explicitement Le fait que la réunion d'examen soit une réunion d'acceptation est une mauvaise chose et devrait porter sur la rétroaction.

Le problème avec ceci est quand le PO devrait-il voir le travail? Quand acceptons-nous/rejetons-nous un sprint?

Nous n'avons pas le test de PO dans un sprint à cause de quelques raisons:

  • Si un bon de commande est le test au cours d'un sprint alors la propriété de faire des problèmes sûrs sont compris est pas sur la équipe, ils pourraient à moitié comprendre et simplement mettre en œuvre quelque chose et ensuite obtenir une explication de l'OP après qu'ils l'ont montré à eux.
  • Il y a aussi moins besoin d'une équipe pour tester leur propre travail parce qu'ils ont le PO là pour attraper des choses.
  • Le PO a beaucoup de choses à faire pendant le sprint, par ex. Backlog toilettage, rencontrer des clients, si nous ajoutons dans les tests pendant le sprint à cela alors il peut y avoir trop à faire.

Encore une fois, ce sont toutes les hypothèses que nous avons faites afin que toute réflexion sur ceux-ci serait extrêmement utile.

+0

Je ne sais pas si les problèmes de gestion de projet sont liés à ce forum. En outre, j'ai l'intuition que c'est une question ouverte et/ou basée sur l'opinion. S'il vous plaît envisager de demander sur i.e. http://pm.stackexchange.com/questions/tagged/agile – quetzalcoatl

Répondre

2

La revue de vitesse est une opportunité pour l'équipe de démontrer le travail qui a été fait à un public plus large, généralement des parties prenantes. La raison pour laquelle nous avons cette réunion est que toutes les personnes intéressées par le travail n'ont pas le temps de l'examiner continuellement pendant le sprint. Il leur est souvent facile d'assister à l'examen Sprint et de faire part de leurs commentaires pendant la réunion.

Je m'attendrais à ce que le propriétaire du produit ait vu tous les la fonctionnalité avant la révision de Sprint. En fait, beaucoup d'équipes avec lesquelles j'ai travaillé avec le Product Owner est la personne qui dirige la démonstration à Sprint Review. En effet, ils démontrent ce qu'ils ont demandé à développer pour un public plus large.

Le propriétaire du produit est passant en revue les articles pendant le sprint. Mon approche préférée est de faire en sorte que le développeur démontre la fonctionnalité d'une histoire au Product Owner le plus tôt possible, parfois même pendant qu'il est en train de le développer. Plus tôt le Product Owner verra l'histoire en action, plus tôt il fournira des commentaires. Une rétroaction précoce est essentielle pour que l'équipe travaille efficacement.

Notez qu'ils sont passant en revue et non testant. Bien qu'il n'y ait aucun inconvénient à ce que le propriétaire du produit fasse des tests si son équipe et le propriétaire du produit le trouvent utile.

Comme vous l'avez souligné à juste titre, le Product Owner a beaucoup à faire pendant un sprint. Il appartient à toute l'équipe Scrum de discuter de la meilleure façon de dépenser le temps du propriétaire du produit. Personnellement, je dirais que l'examen des histoires au cours du sprint est une priorité pour les propriétaires de produits car il permet des économies d'efficacité.