Dans une équipe Scrum, quelle est l'importance de compléter une seule histoire avant de continuer?
Notre maître Scrum est assez dogmatique à propos d'apporter une seule histoire à l'achèvement avant de continuer. Je peux voir que ce développement semblerait être plus "contrôlé" dans ce scénario, plus le Master Scrum aurait une image très précise de ce que les membres de l'équipe travaillaient à tout moment ... mais je suis intéressé par ce que cela achète vraiment nous?
Clairement, le maître Scrum veut minimiser la divergence de la réalité de la réalité afin d'éviter qu'un choc se présente à la fin du sprint - mais si le sprint est de deux semaines de temps, la burndique est mise à jour de manière cohérente et les bloqueurs sont communiqués à des tondes - tout Une telle divergence sera limitée par la longueur du sprint et être rendue visible à mi-sprint à travers les canaux habituels (c'est-à-dire le texte debout ou parlant à la maîtrise de Scrum individuellement). Toute question restante peut être traitée dans la rétrospective bimensuelle.
La raison de la question est que je semble trouver que je travaille plus efficacement en gardant deux (ou 3 si on est particulièrement facile), des histoires en cours à tout moment que je travaille comme je vois en forme. Cela semble contribuer à l'arrière-plan sub-conscient pensé qui aide à la fin de la tâche. Cela me permet également de mieux comprendre la plus grande image si quelques histoires sont liées.
Nos histoires fonctionnent généralement pour avoir une ou deux jours de travail.
Alors, travaille sur quelques histoires à la fois fronça les sourcils et si oui, qu'est-ce que l'une-histoire à la fois vous achète?
5 Réponses :
Je pense personnellement qu'une histoire à la fois fonctionne bien car il vous empêche de vous concentrer sur une tâche. Le coût du passage de contexte entre plusieurs histoires peut être élevé. C'est une préférence personnelle pour moi, mais différentes personnes travaillent différemment. Bien que je pense que votre maître Scrum est correct dans sa méthodologie, si vous avez trouvé des raisons très convaincantes de plusieurs histoires à la fois et que vous pouvez démontrer que c'est en fait de l'avancement, ce serait une bonne affaire de faire.
Je pense que cela appartient vraiment à l'équipe de décider. Je pense que vous l'avez frappé dans votre rédaction sur la burndique, la chose la plus importante est de respecter vos engagements de sprint de manière cohérente. Comment cela se produit devrait vraiment faire partie de l'équipe s'ils sont vraiment autonomes. L'équipe im nair maintenant, notre norme est de travailler sur plusieurs histoires à la fois; C'est la nature de notre configuration étant donné que nous essayons de réellement répandre la propriété des histoires à travers l'équipe. Cela peut être une norme différente pour la vôtre si vous avez des histoires plus courtes et plus d'un style de propriété individuel.
imo, il y a une question sous-jacente ici. Parfois, lorsque vous travaillez sur une histoire, j'aurai besoin d'un autre département / équipe, par exemple. Clarification sur une exigence ou un graphique pour une page, cela signifie que je ne finirai pas une histoire avant de passer à une autre histoire. Pendant que vous en avez mentionné cela dans la discussion sur les bloqueurs de STUCTUP, cela peut arriver où il appartient à une personne à l'extérieur de m'aider à terminer une histoire afin qu'il puisse y avoir plusieurs autres sur ma plaque. Ainsi, je peux avoir plusieurs histoires dues à bloquer quelque chose et de vouloir toujours être productif.
En général, je n'aime pas essayer de gérer plusieurs copies de la base de code ou de commuter mon code, donc je préfère faire une histoire à la fois, en supposant qu'aucun bloqueur. La taille de la base de code que je travaille est de ~ 1,1 Go de données réparties sur 82 000+ fichiers afin que plusieurs copies puissent être plus qu'un peu douloureux que j'imagine.
Mes suppositions personnelles à ce sujet, c'est que cela appartient à l'équipe de définir la norme et de voir que cela fonctionne pour eux. Si certains comme une histoire à la fois et les autres font plusieurs et tout va bien, cool. Si tout le monde aime avoir plusieurs histoires à différents points d'achèvement, cela peut fonctionner aussi.
... mais planifie le blocage
D'autre part, travailler 2 ou 3 histoires à la fois signifie que si vous êtes momentanément bloqué sur une seule histoire, vous pouvez être immédiatement productif de l'autre. Je trouve qu'il y a des frais généraux chaque fois que je commence une nouvelle histoire. Cette surcharge empêche de remplir une heure de "écart" de la journée dans ma journée avec une histoire nouvelle , alors qu'il est beaucoup plus facile de passer à une histoire à une histoire que j'ai déjà démarrée.
En bout de ligne, laissez l'équipe décider ... et ensuite examiner les résultats lors d'une rétrospective . Si vos histoires, tâches et processus de travail soutiennent un environnement où les membres de l'équipe peuvent travailler 2 (peut-être 3) histoires à la fois sans sacrifier la productivité ou la prévisibilité, alors votre SM devrait respecter cela. Mais dans le même temps, vous devriez examiner honnêtement les résultats lors de chaque rétrospective et être prêt à changer si le SM ne pense pas son travail.
Je pense généralement que la décision sur la manière de travailler au mieux devrait être faite presque exclusivement par l'équipe. Le rôle de Scrummaster est d'aider et de soutenir l'équipe, de ne pas remettre en question la façon de travailler de l'équipe lors d'un sprint.
Pour être juste, cela peut parfois être une bonne idée de la Scrummaster de pointer des défauts ou des risques possibles - cela tomberait dans la catégorie «Aide et soutien». Être dogmatique à propos de votre idée personnelle sur la façon dont un sprint devrait ressembler à l'intérieur de l'interne n'est pas quelque chose que je voudrais un scrummaster d'agir comme. Cela semble un peu comme mal comprendre le rôle de gestionnaire, ce qui n'est tout simplement pas le cas.
Quant à ce que nous le faisons: nous travaillons presque toujours sur plusieurs histoires à la fois. À l'heure actuelle, nous avons une équipe de Scrum de quatre personnes avec trois développeurs et un testeur et nous avons presque toujours au moins deux ou trois histoires en même temps. Dans le dernier sprint, nous avons essayé de commencer avec toutes les histoires tôt dans le sprint pour arriver au point où nous avons une conception de base et une bonne idée de ce que les problèmes potentiels pouvaient être. Bien sûr, nous ne travaillions pas sur toutes les histoires à la fois après cela.
Je comprends que, en termes de gestion des risques, vous voudrez peut-être vous assurer que tout est fait pour une histoire avant de vous attaquer à la suivante. Toutefois, l'inconvénient est que lorsque vous rencontrez des problèmes imprévus, vous pourriez avoir suffisamment de temps pour les résoudre. Habituellement, des problèmes montrent leurs visages laids pendant la phase de mise en œuvre et assez souvent assez tôt. Donc, vous échangez essentiellement un risque pour un autre.
Quel risque est plus facile à gérer plus vite devrait être à l'équipe. C'est leur sprint après tout et même si je pense que c'est parfaitement juste pour le Scrummaster de mentionner des préoccupations concernant la façon dont le sprint va, il ne devrait pas forcer son idée de la meilleure façon de travailler sur l'équipe.
À la fin, je pense que cela se résume à ces deux choses:
oui, nous travaillons sur plusieurs histoires à la fois et il a fonctionné bien jusqu'à présent.
N'oubliez pas que le scrummaster est Travailler pour l'équipe, pas l'autre chemin autour.
Veuillez noter que je parle principalement de toute l'équipe travaillant sur plusieurs histoires à la fois, pas un développeur. Le problème que je considérerais, vous devez vous assurer que vous ne bloquez aucune histoire en les gardant ouverts, de sorte que personne d'autre ne puisse continuer le travail. Encore une fois, c'est une question de circonstance et de préférence. En ce qui concerne les tests, notre testeur a souvent quelques tâches de test pour différentes histoires, de sorte qu'il puisse facilement passer à une tâche différente, si un bogue le bloque de la poursuite des tests une fonctionnalité.
Je vote pour fermer cette question comme étant hors sujet car il ne s'agit pas de la programmation.