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".

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é.

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.

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.

Ç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.

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.

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