Comment aborder la tâche de mêlée brûler lorsque les tâches impliquent plusieurs personnes?


12

Dans mon entreprise, une seule tâche ne peut jamais être accomplie par une seule personne. Il y aura une personne distincte pour l'AQ et l'examen du code pour chaque tâche. Cela signifie que chaque individu donnera ses estimations, par tâche, du temps qu'il faudra pour terminer.

Le problème est, comment dois-je aborder la combustion? Si j'agrège les heures ensemble, supposez l'estimation suivante:

10 heures - Temps de développement

4 heures - QA

4 heures - Révision du code.

Estimation des tâches = 18 heures

À la fin de chaque journée, je demande que la tâche soit mise à jour avec "combien de temps il reste jusqu'à ce qu'il soit fait". Cependant, chaque personne ne pense généralement qu'à sa part. Doivent-ils marquer l'effort restant, puis AJOUTER les estimations d'effort à cela? Comment allez-vous les gars?

MISE À JOUR

Pour aider à clarifier certaines choses, dans mon organisation, chaque tâche dans une histoire nécessite 3 personnes.

  1. Quelqu'un pour développer la tâche. (faire des tests unitaires, ect ...)
  2. Un spécialiste de l'AQ pour revoir la tâche (ils font principalement des tests d'intégration et de régression)
  3. Un responsable technique pour la révision du code.

Je ne pense pas qu'il y ait une mauvaise ou une bonne façon, mais c'est notre façon ... et cela ne changera pas. Nous travaillons en équipe pour terminer même le plus petit niveau d'une histoire chaque fois que possible. Vous ne pouvez pas réellement tester si quelque chose fonctionne jusqu'à ce qu'il soit terminé, et vous ne pouvez pas non plus revoir la qualité du code ... donc le mieux que vous puissiez faire est de diviser les choses en petites tranches logiques afin que la fonctionnalité minimale puisse être testée et examiné le plus tôt possible dans le processus.

Ma question à ceux qui fonctionnent de cette façon serait de savoir comment brûler une "tâche" lorsqu'ils sont configurés de cette façon. À moins qu'une tâche n'ait ses propres sous-tâches (ce que JIRA n'autorise pas) ... Je ne suis pas sûr de la meilleure façon de suivre quotidiennement "ce qui reste".


8
Pourriez-vous décrire quel est votre processus? Nous n'utilisons jamais d'heures dans notre planification Scrum, et nous ne signalons jamais d'heures restantes. Les tâches sont terminées.
dcaswell

1
@ user814064: Bon point. Chaque fois que j'ai vu des équipes évaluer chaque tâche, elles se trompaient toujours. Parfois d'un facteur 1/10 et plus.
Arseni Mourzenko

Ce processus est nouveau pour moi. Dans le passé, nous avons incendié la tâche lorsqu'elle était terminée. CEPENDANT, j'essaie d'encourager les gens à mieux évaluer. Nous pouvons revenir sur nos estimations et les comparer à nos chiffres réels et, espérons-le, en tirer des leçons. Cela peut être une tentative infructueuse, mais c'est quelque chose que je veux que les équipes essaient pendant un certain temps.
AgileMan

Il est difficile d'expliquer pourquoi vous ne devriez pas faire cela avec les quelques caractères que vous êtes autorisé à saisir ici. Estimer est exactement ce que son nom implique: c'est vague, c'est un chiffre approximatif et vous ne pouvez pas vous améliorer de manière significative et équilibrée en termes de coûts et d'efforts. Après tout, cela s'appelle «estimer», pas «calculer». Je vous conseille de lire les articles de Neil Killick sur #NoEstimates: neilkillick.com/2013/01/31/…
Stefan Billiet

Réponses:


14

Ce sont 3 tâches, pas une.

Il peut s'agir d'une fonctionnalité / histoire, mais il s'agit de trois tâches. Une seule tâche peut être accomplie par une seule personne en temps limité.


@ user814064: ce n'est pas une hypothèse; les estimations de l'OP pour chaque tâche dans le poste
Steven A. Lowe

J'aurais dû être plus précis ... c'est DÉJÀ au niveau de la tâche. Par exemple, CHAQUE tâche (le petit morceau de l'histoire) doit être développée, testée et revue. Même si la tâche a été accomplie par une seule personne ... d'autres passeront du temps pour s'assurer qu'elle est terminée. Je suppose que vous pouvez faire en sorte que chaque tâche ait ses propres tâches ... mais je ne sais pas comment cela fonctionnerait.
AgileMan

3
@AgileMan: dans un monde de bon sens, une tâche est une seule unité de travail qui peut être effectuée par une seule personne, et trois tâches en série par trois personnes différentes est un projet. Dans le monde de la mêlée ... c'est la même chose. (par exemple, www.scrumalliance.org/community/articles/2007/march/glossary-of-scrum-terms#1129). Story-1-dev, Story-1-QA-review et Story-1-code-review sont 3 tâches différentes. Si vous devez modéliser des tâches en 3 parties, peut-être 3 tableaux de burndown différents seraient appropriés;)
Steven A. Lowe

Si cela est nécessaire au niveau d'une tâche, vous devez vraiment travailler sur votre définition de terminé et décomposer vos tâches. Ce devrait être un simple oui / non pour savoir si une tâche est terminée, pas un processus à travers plusieurs personnes.
SpoonerNZ

7

TL; DR

Vous utilisez le brûlage incorrect de plusieurs manières. Les tâches et les histoires sont terminées ou non; en essayant de suivre les écarts par rapport aux estimations de planification basées sur le temps dans votre analyse, vous réestimez réellement votre calendrier plutôt que d'estimer le produit du travail restant.

Dans Scrum, vous devriez mesurer les progrès vers un objectif de sprint plutôt que de mesurer la chronologie du sprint. Cela permet de se concentrer sur la capacité de l'équipe et la livraison des fonctionnalités plutôt que sur des ajustements de planification continus.

Tâches vs histoires

Vous confondez tâches et histoires. Les histoires comprennent toutes les tâches requises pour terminer l'histoire selon la «définition de fait» de votre équipe. L'histoire est considérée comme 100% incomplète à moins que toutes ses tâches soient terminées. Dans Scrum, les histoires sont toujours estimées d'une manière ou d'une autre; le plus souvent, ils sont estimés en points d'histoire.

Les tâches sont les étapes ou les jalons nécessaires pour terminer l'histoire. Bien que chaque tâche puisse avoir des dépendances et des prérequis, vous pouvez certainement dire que la révision du code est terminée ou non, indépendamment des autres tâches.

Incendier

Dans Scrum, votre graphique de gravure montre la quantité de travail restante pour le sprint ou le projet. Les véritables graphiques de brûlage comportent souvent des plateaux; dans certains cas, le graphique peut même augmenter. Par exemple, sur un sprint d'une semaine avec deux histoires valant 3 et 5 points, vos points de données peuvent ressembler à ceci:

Mon | Tue | Wed | Thu | Fri
--- | --- | --- | --- | ---
 8  |  5  |  5  |  5  |  0

Dans ce scénario idéaliste, vous commencez avec 8 points d'histoire. L'histoire en 3 points a été achevée mardi après-midi, tandis que l'histoire en 5 points n'a été achevée que vendredi. Les points d'histoire ne sont pas déduits du brûlage tant que l'histoire n'a pas atteint la définition de terminé. Si vous utilisez des heures idéales au lieu de points d'histoire, la seule chose qui change est votre échelle.

Time-Boxing

La pratique généralement acceptée consiste à s'assurer que vos tâches sont décomposées en morceaux de la taille d'une bouchée entre 1/2 journée et 2 jours. L'écart de plus d'une journée devrait être évident dans les stand-ups quotidiens ou le Sprint Backlog; il ne devrait pas être nécessaire d'effectuer une extraction de statut officielle.

Vous pouvez également effectuer une analyse statistique sur le graphique de gravure pour déterminer si votre sprint a une tendance correcte. De petits écarts ou plateaux sont normaux, mais si personne ne soulève de bloqueurs dans les stand-ups quotidiens mais que votre brûlage semble bloqué, c'est généralement un signe que le Sprint Backlog a été mal estimé ou qu'il y a du "travail invisible" qui doit être explicite dans votre processus.


Je ne pense pas que nous soyons totalement d'accord. Bien sûr, le tableau déroulant mesure les progrès vers un objectif de sprint ... mais il le fait en mesurant les progrès sur des histoires de sprint spécifiques. En règle générale, vous pouvez choisir de brûler une fois qu'une histoire est terminée à 100%, ou vous pouvez brûler des heures sur chaque histoire chaque jour à mesure que le travail est terminé. J'essaie de faire ce dernier ... mais je trouve cela difficile pour les équipes de le faire. J'ai l'impression que votre message s'écarte de la question que j'ai posée à l'origine.
AgileMan

l'un des risques de ne pas autoriser la fermeture d'une tâche à 100% est que 100% de vos tâches soient effectuées à 99%, ce qui signifie que rien n'est réellement "fait"
hanzolo

1
@AgileMan Vous trouvez "difficile pour les équipes de faire" parce que vous mesurez la mauvaise chose. Vous êtes certainement les bienvenus pour appliquer toute méthodologie qui fonctionne pour vous et votre équipe, mais je maintiens l'affirmation selon laquelle la mesure des estimations originales - le temps écoulé n'est pas la même chose que la mesure du produit du travail restant. Faites ce qui fonctionne pour votre projet, mais n'ayez pas peur de remettre en question les hypothèses qui sous-tendent vos mesures actuelles.
CodeGnome

@CodeGnome. Il y a une simple mauvaise communication en cours ici. Je n'essaie pas de suivre le "temps écoulé". J'essaie de déterminer le "temps restant". Quand cette tâche sera-t-elle effectuée? C'est tout ce que j'essaie de déterminer. Cependant, puisque même la plus petite tâche (généralement) implique plusieurs personnes, le défi est de savoir comment déterminer ce qui reste d'une manière simple et directe.
AgileMan

4

Pouvez-vous définir la tâche de développement comme «terminée» avant que l'AQ ne fasse sa part? Pouvez-vous définir la révision du code comme «terminée» avant que le développement soit terminé? L'AQ peut-elle être "effectuée" si la révision du code et du développement ne l'est pas?

Je dirais que vous devez regrouper les trois éléments en une seule tâche et que les trois personnes devraient y travailler ensemble.

Scrum ne dit PAS qu'un élément est la responsabilité d'un membre de l'équipe. Bien au contraire - les éléments du journal de sprint sont la responsabilité de l'ÉQUIPE. S'il faut trois personnes pour effectuer une tâche, c'est ce qu'il faut.


J'ai des doutes sur cette suggestion. Pour moi, une tâche de développement peut être effectuée avant le contrôle qualité et la révision du code, mais le contrôle du code et le contrôle qualité (qui sont des tâches individuelles pour eux-mêmes) produisent très probablement de nouvelles tâches de développement qui peuvent être "brûlées" individuellement. Bien sûr, si "tâche" signifie "implémenter une user story complète", alors vous avez raison, mais pourquoi la tâche sera-t-elle si grossière?
Doc Brown

@DocBrown - Je l'ai fait dans les deux sens. J'ai constaté que dire qu'une tâche est effectuée alors qu'elle n'a pas été vérifiée (examen et test) ne s'est pas avéré utile pour suivre les progrès. Le fait de mettre tout le monde un crochet pour accomplir la tâche aide à maintenir l'urgence pour toutes les personnes impliquées.
Matthew Flynn

De toute évidence, rien n'est "fait" jusqu'à ce qu'il soit passé par le processus DoD. Cependant, les choses peuvent évoluer à un point où il peut être avantageux d'être revu par d'autres parties. Dans l'état actuel des choses, je fusionne tout le "travail" requis pour chaque petite tâche en une heure agrégée comme vous l'avez mentionné. Le défi est lorsqu'une personne essaie de rapporter ce qui reste, elle doit généralement en rendre compte, puis ajouter les estimations des autres personnes en haut ... c'est donc un travail très chargé. J'ai l'impression qu'il y a une meilleure façon.
AgileMan

3

Ça n'a pas d'importance. Tant qu'il est relativement cohérent entre les histoires, votre graphique de burndown fonctionnera dans les deux cas. Utilisez le moyen le plus naturel pour votre équipe de signaler.

Mon équipe fait en fait une sorte d'hybride, mais pas par accord formel. Nous mettons 16 heures si nous pensons qu'une tâche prendra une personne deux jours, mais si deux personnes finissent par y travailler ensemble, nous ne la changeons pas.

Après l'estimation initiale, il devient officieusement plus d'un pour cent achevé pour notre équipe qu'il ne reste une heure. Si nous pensions à l'origine que cela prendrait deux jours, mais après un jour, nous pensons qu'il n'est terminé qu'à 25%, nous prenons 4 des 16 heures de congé d'origine. Cela laisse 12 heures alors que techniquement, nous en estimons 24, car nous déduirons probablement 4 heures pour les 3 jours restants.

Cela m'a ennuyé en tant que Scrum Master au début, mais aussi étrange que cela puisse paraître, c'est un moyen très naturel de donner des estimations, car les développeurs détestent vraiment ajouter des heures à une estimation. Tout est en moyenne pour rendre le burndown toujours utile, et c'est ce qui est important.


2

Le temps restant de la tâche n'a pas beaucoup d'importance: rien ne peut être livré tant que toute l'histoire n'est pas terminée.

Si vous souhaitez suivre le temps restant sur une histoire (globalement) en demandant aux gens de remplir le temps restant sur les tâches, puis divisez les tâches par personne.

Cela dit:

  • De grandes tâches peuvent être une indication que vos histoires sont trop grandes. Dans ce cas, la meilleure solution est de réduire la portée et la taille des histoires, et si vous la réduisez suffisamment, le suivi du temps restant sur les tâches n'a plus d'importance (elles sont terminées ou non - somme des estimations sur les tâches non terminées est assez granuleux).
  • SCRUM encourage tout le monde à comprendre ce qui doit être fait. Si vous attribuez des tâches à des personnes (par opposition à des rôles), vous vous empêchez potentiellement de livrer une histoire, même si le développeur ne fait rien - car l'AQ est goulot d'étranglement.

-1

Divisez la tâche en plusieurs tâches et saisissez-les en tant que tâches où chacune est gérée par une personne différente.

Tâche d'origine: réparer quelque chose

Nouvelles tâches: (enfant du parent de la tâche d'origine)

  • Dev A - Résolution du problème
  • Dev B - Aider Dev A à résoudre le problème (c.-à-d. Programmation de paires, révision de code)
  • Dev A - dev teste le correctif à l'aide du Dataset X
  • Dev B - dev teste le correctif à l'aide du jeu de données Y

question stipule que les sous-tâches ne sont pas autorisées
gnat

je n'ai jamais voulu dire une sous-tâche en soi .. je veux dire diviser la tâche en tâches et les faire toutes enfant d'une histoire ou d'un bug .. je reformulerai ma réponse ..
Asim Ghaffar

bien le casser comme vous le décrivez a déjà été suggéré et expliqué dans au moins deux réponses précédentes (voté en haut en ce moment): "C'est 3 tâches, pas une ..." "Vous êtes en train de confondre tâches et histoires ..."
moucher
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.