Sous-tâche précoce au début de chaque sprint

J'ai rejoint une nouvelle équipe qui utilise Agile / Scrum, et leur processus de développement est le suivant:

1) Les développeurs examinent chaque histoire avant chaque sprint pour s'assurer qu'elle ne manque rien de critique. Il y a un état formel pour cela dans le workflow.

2) pendant le coup d'envoi du Sprint, toute l'équipe fait une estimation (planification du poker) du nombre de points d'histoire que chaque histoire coûterait.

3) enfin, immédiatement après le début de chaque sprint, chaque développeur est tenu de décomposer avec impatience toutes les histoires attribuées en sous-tâches avec des estimations de temps (par opposition à la sous-tâche avant de commencer chaque histoire).

Le principal argument de la dernière étape est qu'il permet de découvrir si la mise en œuvre d'une histoire prendrait plus de temps que prévu et d'avertir Scrum Master des risques potentiels de manquer les délais de sprint.

Pourtant, je trouve cela contre-productif, principalement pour les raisons suivantes:

• si le but est de fournir une estimation approximative, les points d'histoire (étape # 2) sont ce qui fait le travail. Sinon, pourquoi s'embêter avec des histoires? - faites juste des sous-tâches tôt.
• si le but est de fournir des estimations précises, alors c'est un exemple clair de ce qui est décrit dans les commutateurs de tâche humaine considérés comme nuisibles . C'est, je pense, particulièrement le cas pour les nouveaux développeurs qui rejoignent les équipes existantes dans de grands projets où comprendre ce qui doit être fait peut prendre jusqu'à 50% du temps. Vous devez entrer dans les détails de l'histoire n ° 1, puis de l'histoire n ° 2, n ° 3, etc., etc., ce qui génère une grande quantité d'informations.

On me dit aussi qu'une telle pratique est "à la lettre" et je ne suis même pas censé en discuter. Quelqu'un peut-il fournir une référence à une telle pratique - si cela est clairement défini dans les bibles Scrum, et / ou peut-être fournir des informations supplémentaires?

Ce n'est pas différent de la façon dont nous menons une partie de notre processus de mêlée. nous

1. Estimer les histoires près du haut de l'arriéré dans les "points d'histoire"
2. Sélectionnez / expliquez les histoires en fonction des points de l'histoire qui, selon nous, «constitueront» le sprint
3. Décomposez les histoires en tâches techniques plus détaillées
4. Estimez les tâches techniques et comparez avec l'estimation des points d'histoire d'origine (nous savons approximativement combien de temps de développement équivaut normalement à un point d'histoire)

Mais ce que vous voulez savoir, c'est pourquoi nous estimons deux fois!

• Nous faisons une estimation grossière (basée sur l'histoire) parce que nous aimons pouvoir faire des prédictions sur ce qui pourrait être dans le prochain sprint, et peut-être même celui après. En fin de compte, la direction doit être en mesure de communiquer avec le client sur les échelles de temps probables, donc si nous n'avons pas cette estimation d'échelle grossière, la planification à long terme est pratiquement impossible.
• Évidemment, cela signifie que nous faisons des estimations grossières pour plus que le sprint actuel. Parce qu'il n'y a aucune garantie que l'ordre du carnet de commandes ne changera pas pour le prochain sprint, nous ne voulons pas investir le temps dans la répartition des tâches et les estimations à échelle précise jusqu'à ce qu'elles soient nécessaires.
• Nous décomposons la tâche pour nous assurer que toutes les tâches ont été énumérées et que les histoires peuvent être travaillées en parallèle plus facilement.
• Nous faisons des estimations à petite échelle (basées sur la tâche) parce que cela nous donne un graphique de gravure beaucoup plus fluide (en particulier là où il n'y a pas de moyen facile de diviser une grande histoire en "fonctionnalités" viables).
• Parce que nous faisons les deux, ils agissent comme des vérifications de santé mentale les uns sur les autres - une divergence sauvage indique que nous avons besoin d'une erreur quelque part que nous devons identifier. Il s'agit d'un sous-produit utile, mais pas la raison en soi pour laquelle nous estimons "deux fois".

En relisant votre question et votre commentaire, je constate qu'il existe des différences entre notre flux de travail et le vôtre.

• Nous faisons des pannes en équipe , nous constatons que même si les frais généraux sont plus importants, la discussion technique que nous en tirons est souvent très précieuse et peut détecter des lacunes dans notre histoire. Lorsque nous avons l'expérience, les connaissances ou la disparité des capacités, cette discussion est également là où ceux qui ont plus peuvent aider ceux qui ont moins (très utile avec les nouvelles embauches).
• Nous faisons des estimations au niveau de la tâche en équipe , l'une des raisons pour lesquelles la "planification du poker" fonctionne est due au phénomène de "sagesse des foules" - comme je le mentionne dans les commentaires, à ce stade, l'estimation d'une tâche devrait prendre moins de 30 secondes , donc les frais généraux sont négligeables.

Cela ressemble à la raison pour laquelle votre équipe effectue des ventilations de tâches et des estimations de tâches pour une gravure en douceur - ce qui est bien, cela fait partie du suivi de la progression du sprint et permet à votre Scrum-master de détecter et de résoudre les problèmes tôt. Si vous voulez ces informations, vous devez faire les ventilations et les estimations et vous devez les faire d'abord.

À mon avis, le changement de tâche n'est probablement pas un problème pour vous ici, je ne pense pas que la décomposition de différentes tâches soit vraiment un changement de tâche dans le même sens que le passage du développement d'une fonctionnalité à une autre en partie est un changement de tâche . Je pense que la compréhension de "l'architecture" globale du sprint est probablement une chose très utile.

Cependant, je pense qu'il pourrait y avoir d'autres problèmes que vous pourriez envisager. Comme toujours avec Agile, vous devez identifier un problème que vous avez et proposer une solution , puis décider si votre solution a fonctionné dans la rétrospective . C'est l'essentiel de la construction d'une solution agile qui fonctionne pour votre entreprise et votre équipe. Donc, certains problèmes que vous pourriez avoir:

• Vous effectuez des ventilations individuellement - alors comment les membres de votre équipe junior / inexpérimentés apprennent-ils des membres de votre équipe senior? Bien sûr, ils peuvent probablement tout apprendre eux-mêmes - mais ils apprendront plus vite s'ils sont encadrés. Les membres de l'équipe junior mettent-ils beaucoup de temps à décomposer les choses? Font-ils des erreurs ou manquent-ils des choses qui coûtent du temps à l'équipe à long terme? Se décomposer en équipe peut aider ici.
• Vous faites des estimations individuellement - la même chose s'applique que le premier point, mais en plus ces estimations sont-elles moins précises qu'elles pourraient l'être?
• Il semble que les tâches soient assignées au début du sprint, mais si tel est le cas, combien le trouvez-vous coûteux lorsque vous devez modifier l'affectation? Si quelqu'un est en retard ou malade, est-il facile pour quelqu'un d'autre de reprendre ses tâches? Doivent-ils passer par la répartition des tâches et essayer de les comprendre sans interrompre le cessionnaire d'origine? Si vous vous décomposez et estimez en équipe, tout le monde devrait pouvoir travailler sur tout!
• Vos histoires sont-elles trop grandes? Si la panne prend 50% du temps, les histoires semblent être très impliquées - peut-être qu'elles peuvent être réduites? Nous gardons nos histoires dans une semaine de travail.
• Vos tâches sont-elles trop petites? Si vous passez beaucoup de temps à créer des listes de tâches, vous allez peut-être trop dans les détails? Nous avons tendance à avoir des tâches comprises entre 1 et 8 heures de travail, de sorte qu'au cours d'une journée, tout le monde progresse à signaler lors du prochain standup quotidien.

Si c'est comme ça que votre entreprise veut mener son développement et arrêter la discussion, vos choix sont limités, ou vous risquez au moins de déranger les gens.

Étant donné que le but ultime de l'agilité est de travailler sur des logiciels de valeur, vous pouvez essayer d'offrir une aide en mesurant la capacité de votre équipe à livrer (points livrés / estimés, bogues dans le sprint, nombre de tests, couverture de code, temps de disponibilité, ventes générées - peu importe). Soyez prêt pour tous les résultats - il se peut que cette façon de travailler fonctionne pour eux même si cela n'a aucun sens pour vous. Si vous avez raison, les déchets deviendront évidents.

Méfiez-vous du processus suivant pour le plaisir du processus - cela perd du temps et fournit toujours des produits médiocres. Une bonne équipe agile expérimente, mesure et apprend. La meilleure façon de changer le comportement sans tomber dans l'opinion est de prendre des décisions fondées sur des preuves.

C'est aussi mon avis. Je vous suggère d'essayer par vous-même et de mesurer le résultat - voyez ce que j'ai fait là-bas :)

Je suppose que votre coup d'envoi Sprint signifie la réunion de planification Sprint. Je pense que votre Scrum Master a mal interprété le déroulement de cette réunion. Vous décidez non seulement des histoires à développer, vous les testez également auprès de votre équipe, sa définition de prêt à vous assurer qu'ils ne manquent de rien (généralement en utilisant INVEST ), et vous subdivisez également ces histoires en tâches. Pour citer Mike Cohn (l'un des fondateurs de la Scrum Alliance);

Le backlog de sprint est l'autre résultat de la planification de sprint. Un backlog de sprint est une liste des éléments de backlog de produit que l'équipe s'engage à livrer, ainsi que la liste des tâches nécessaires à la livraison de ces éléments de backlog de produit. Chaque tâche du backlog de sprint est également généralement estimée.

La décomposition des histoires et leur estimation font donc partie de la session de planification de sprint; pas après la fin de la session de planification et non individuellement.

Pour fournir plus d'informations, notre flux de travail pendant la réunion de planification de sprint est le suivant:

1. nous prenons une histoire du haut du backlog de produit et la divisons en tâches. En règle générale, une tâche doit généralement être plus petite qu'une journée.

2. Nous estimons l'histoire compte tenu des tâches que nous avons déduites. Si l'histoire s'avère grande, nous essayons de diviser l'histoire en petites histoires.

3. Rincer et répéter jusqu'à ce que nous atteignions le total des points estimés

Contrairement à ce que dit Cohn, j'ai constaté qu'il n'y a pas vraiment besoin d'estimer chacune des tâches séparément, car les tâches sont spécifiées comme étant plus petites qu'une journée. Étant donné que les tâches sont inférieures à une journée de travail, vous pouvez facilement remarquer pendant le Standup quotidien lorsqu'une tâche prend plus de temps que prévu, car la personne qui travaille sur la tâche spécifique dira qu'elle y travaille toujours.

Pendant le sprint, l'équipe se fraye un chemin à travers les histoires, et à la fin, l'équipe devrait réfléchir à ce qui a réellement été fait. C'est à cela que sert la réunion rétrospective Scrum. S'il y a encore des histoires sur la table, vous pouvez déduire que votre estimation était trop optimiste et agir en conséquence pour le prochain sprint. Alternativement, il pourrait y avoir eu certains incidents qui se sont produits et qui ont affecté votre travail, etc. Vous constaterez que les estimations s'améliorent avec le temps lorsque vous y réfléchissez.

"par le livre" - c'est votre problème. Vous vous noyez dans plus de processus que vous n'en auriez eu si vous aviez travaillé des cascades.

Il n'y a pas de «livre» pour Agile, il n'y a que le manifeste agile qui dit «faites tout sans les frais généraux». Donc, si vous estimez des tailles et que vous divisez les histoires en tâches pour les réestimer, alors c'est une surcharge de processus inutile qui doit être rendue plus efficace - c'est à cela que sert l'agile. Scrum et tous les autres sont vraiment des lignes directrices sur la façon dont vous commencez à faire de l'agilité. Ce faisant, vous devez identifier ces points qui n'ont aucun sens ou qui n'aident pas votre équipe à travailler plus efficacement, et vous devez les changer.

Cependant, certaines personnes pensent que les méthodes de travail proscrites doivent être écrites dans la pierre et ne jamais en déroger, même si elles deviennent stupides. J'essaierais de diviser les histoires en tâches avant la réunion Scrum - vous dites que les développeurs sont tenus de revoir chaque histoire, eh bien, voici la chance de faire le fractionnement en même temps dans le cadre de la revue. Ensuite, vous pouvez déclarer les tâches qui composent l'histoire dans la réunion Scrum (ne leur allouez pas de temps!) Et laisser les gens décider ensuite de la taille du lot de travail de l'histoire, en fonction de ces informations supplémentaires contenues (ce qui n'est jamais une mauvaise chose, la prise de décision éclairée est bien meilleure que la conjecture, et un ne peut être fait que lorsque vous avez des informations à alimenter dans la prise de décision).

Après la réunion, vous pouvez toujours attribuer des heures aux tâches (même si je ne vois pas l'intérêt de cela, les sprints ne sont pas basés sur le temps, ils sont basés sur "combien de choses vous vous attendez à faire" qui est mesuré en points d'histoire , pas le temps. C'est un problème commun avec la mêlée, les points ne signifient pas le temps mais vous devez terminer, disons, 20 points par quinzaine donc 2 points = 1 journée de travail. C'est censé être une estimation rapide du nombre de tâches à mettre dans le sprint afin que vous ne soyez ni surchargé ni sous-travaillé, pas combien seront réellement effectués. Les meilleurs sprints sont ceux qui ont quelques tâches restantes, ce qui vous montre une estimation parfaite. La fin de chaque tâche montre que les gens se sont précipités sur les derniers ou retardé à la fin à la fin - ni l'un ni l'autre n'est productif).

Donc, en bref - imprimez une copie du Manifeste Agile et la version anti-agile . Je parie que tu fais plus anti qu'agile. Scrum a tendance à être comme ça. La seule façon de résoudre ce problème est de dialoguer avec votre équipe et d'obtenir l'adhésion au changement. Ne laissez pas la direction vous dire comment votre équipe doit travailler, ce n'est pas agile non plus, et cela sera écrit dans The Book.

À un moment donné au cours de chaque Sprint, vous devriez avoir une réunion de raffinement du carnet de produit . Lors de cette réunion, vous vous assurez que la partie supérieure du carnet de produit est suffisamment décomposée pour que les éléments de cette partie soient ajoutés au prochain carnet de sprint.

Si le raffinement du carnet de produit est bien géré, la réunion de planification du sprint peut être plus efficace. Idéalement, cela éliminerait la nécessité pour les développeurs de "décomposer avec impatience" les histoires après le démarrage du Sprint.

Si les éléments du carnet de produit sont ajoutés au carnet de sprint avant d' être suffisamment décomposés pour une estimation réaliste, il sera difficile de prendre de bonnes décisions sur ce qu'il faut ajouter au sprint.