Est-ce une mauvaise pratique de travailler sur plusieurs histoires simultanément?

Question

Dans une équipe Scrum, à quel point est-il important de compléter une histoire unique avant de passer à autre chose? Notre maître de mêlée est assez dogmatique à propos de la réalisation d'une histoire unique avant de passer à autre chose. Je peux voir que le développement semble être plus "contrôlé" dans ce scénario, et le maître de mêlée aurait une image très précise de ce que les membres de l'équipe travaillaient à un moment donné ... mais je suis intéressé par ce que cela achète vraiment nous? Il est clair que le maître de mêlée veut minimiser la divergence du burndown de la réalité pour éviter un choc à la fin du sprint - mais sûrement si le sprint est de deux semaines, le burndown est mis à jour régulièrement et les bloqueurs sont communiqués aux standups. une telle divergence sera limitée par la longueur du sprint, et sera visible au milieu du sprint à travers les canaux habituels (c'est-à-dire le stand-up ou en parlant individuellement au maître de mêlée). Toutes les questions restantes peuvent être traitées dans la rétrospective bimensuelle.

La raison de la question est que je semble trouver que je travaille le plus efficacement en gardant disons 2 (ou 3 si l'on est particulièrement facile) histoires en cours à tout moment que je travaille comme bon me semble. Cela semble aider avec la pensée de fond subconscient qui aide à l'achèvement de la tâche. Cela me permet également de mieux comprendre la situation dans son ensemble si deux histoires sont liées. Nos histoires ont généralement un ou deux jours de travail.

Donc, travaille sur quelques histoires à la fois mal vues et si oui, qu'est-ce que vous raconte une histoire à la fois?

Answer 1

Je pense que c'est à l'équipe de décider. Je pense que vous avez frappé dans votre écriture sur le burndown, la chose la plus importante est de respecter vos engagements de sprint de manière cohérente. comment cela se passe vraiment devrait être à l'équipe si elles sont vraiment autonomes. l'équipe im maintenant, notre norme est de travailler sur plusieurs histoires à la fois; C'est la nature de notre configuration étant donné que nous essayons de vraiment propager la propriété des histoires à travers l'équipe. cela peut être une norme différente pour le vôtre si vous avez des histoires plus courtes et plus d'un style de propriété individuelle.

Answer 2

Je pense personnellement qu'une histoire à la fois fonctionne bien parce qu'elle vous permet de vous concentrer sur une tâche. Le coût du changement 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 de mêlée a raison dans sa méthodologie, si vous avez trouvé des raisons très convaincantes pour plusieurs histoires à la fois et que vous pouvez démontrer que cela aide le progrès, ce serait un bon exemple à faire.

Answer 3

IMO, il y a une question sous-jacente ici. Parfois, lorsque je travaille sur une histoire, j'ai besoin de quelque chose d'un autre département/équipe, par exemple. clarification sur une exigence ou un graphique pour une page, et cela signifie que je ne vais pas terminer une histoire avant de passer à une autre histoire. Tandis que vous en parlez en discutant des bloqueurs au stand-up, cela peut se produire là où il appartient à quelqu'un de l'extérieur de m'aider à finir une histoire alors il peut y en avoir plusieurs dans mon assiette. Ainsi, je peux avoir plusieurs histoires parce que je bloque quelque chose et que je veux toujours être productif.

En général, je n'aime pas essayer de gérer plusieurs copies de la base de code ou de changer de code beaucoup, donc je préfère faire une histoire à la fois, en supposant qu'aucun bloqueur. La taille de la base de code avec laquelle je travaille est d'environ 1,1 Go de données réparties sur plus de 82 000 fichiers, donc avoir plusieurs copies pourrait être plus que pénible.

Ma conjecture personnelle sur ceci est que c'est à l'équipe d'établir le standard et de voir que cela fonctionne pour eux. Si certains aiment une histoire à la fois et d'autres font plusieurs et tout va bien, cool.Si tout le monde aime avoir plusieurs histoires à divers points d'achèvement, cela peut fonctionner aussi.

Answer 4

Ne pas HOG l'arriéré ... Dans mon expérience, quand les histoires sont entre 1 et 2 jours en taille, ils ont tendance à être mis en œuvre par un seul développeur. Si vous travaillez simultanément sur deux ou trois articles, cela pourrait réduire la quantité de choses dans le backlog que les autres développeurs peuvent choisir et compromettre le sprint.

... mais plan de blocage D'autre part, travailler 2 ou 3 étages au moyen une fois que si vous êtes momentanément bloqué sur une histoire que vous pouvez être immédiatement productif sur l'autre. Je trouve qu'il y a des frais généraux chaque fois que je commence une nouvelle histoire. Cet overhead rend difficile le remplissage d'une «pause» d'une heure dans ma journée avec une nouvelle histoire , alors qu'il est beaucoup plus facile de passer à une histoire que j'ai déjà commencée. En conclusion, laissez l'équipe décider ... puis examinez les résultats au cours d'une rétrospective32 Si vos histoires, tâches et processus de travail prennent en charge un environnement dans lequel les membres de l'équipe peuvent travailler 2 (peut-être 3) histoires à la fois sans sacrifier la productivité ou la prévisibilité, votre SM devrait respecter cela. Mais en même temps, vous devriez honnêtement examiner les résultats lors de chaque rétrospective et être prêt à changer si le SM ne pense pas que cela fonctionne.

Answer 5

En général, je pense que la décision de travailler au mieux devrait être prise presque exclusivement par l'équipe. Le rôle du ScrumMaster est d'aider et de soutenir l'équipe, de ne pas remettre en question la manière de travailler de l'équipe pendant un sprint.

Pour être juste, il peut parfois être une bonne idée pour le ScrumMaster de signaler les défauts ou les risques possibles - qui entreraient 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 n'est pas quelque chose que je voudrais faire un ScrumMaster agir comme. Cela ressemble un peu à une mauvaise compréhension du rôle de gestionnaire, ce qui n'est tout simplement pas le cas. En ce qui concerne la façon dont nous le faisons: Nous travaillons presque toujours sur plusieurs histoires à la fois. En ce moment, nous avons une équipe de mêlée 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 au début du sprint pour arriver au point où nous avons un design de base et une bonne idée de ce que pourraient être les problèmes potentiels. Bien sûr, nous ne travaillions pas sur toutes les histoires en même temps après cela.

Je comprends qu'en termes de gestion des risques, vous voudrez peut-être vous assurer que tout est fait pour une histoire avant d'aborder la suivante. Cependant, l'inconvénient est que lorsque vous rencontrez des problèmes imprévus, vous n'avez peut-être pas assez de temps pour les corriger. Habituellement, les problèmes montrent leurs visages laids pendant la phase de mise en œuvre et souvent assez tôt. Donc, vous échangez essentiellement un risque contre un autre.

Quel risque est le plus facile à gérer devrait être à la charge de l'équipe. C'est leur sprint après tout et même si je pense qu'il est tout à fait juste que le ScrumMaster mentionne des inquiétudes sur la façon dont le sprint se déroule, il ne devrait pas forcer son idée de la meilleure façon de travailler dans l'équipe.

En fin de compte, je pense que cela se résume à ces deux choses:

1. OUI, nous travaillons sur plusieurs histoires à la fois et il a fonctionné bien jusqu'à présent.Rappelez-vous que le ScrumMaster est en travaillant pour l'équipe, et non l'autre .

Veuillez noter que je parle surtout de toute l'équipe travaillant sur plusieurs étages à la fois, pas un seul développeur. Le problème que je verrais là est que vous devez vous assurer que vous ne bloquez pas les histoires en les gardant ouvertes, afin que personne d'autre ne puisse continuer le travail. Encore une fois, c'est une question de circonstance et de préférence. Quand il s'agit de tester, notre testeur a souvent quelques tâches de test pour différentes histoires, de sorte qu'il peut facilement passer à une tâche différente, si un bug l'empêche de continuer à tester une fonctionnalité.