Remarque: Avant de poser cette question, j'ai fait une recherche exhaustive et j'ai trouvé de petits bits de la réponse dans diverses autres questions, par exemple:
Cependant, j'ai l'impression que cette question n'a pas été directement adressée (si elle l'a, s'il vous plaît laissez-moi savoir).
Tracez-vous l'heure dans Scrum en fonction des heures / jours consacrés à une tâche ou simplement si cette tâche est complète ou non? Pouvez-vous ajuster ces tâches et estimations?
Contexte: Notre nouveau VP de développement est venu d'un environnement Scrum, nous apprenons donc tous sur le processus, mais l'une des choses qu'il a apportées avec lui est le concept de très soigneusement Citer des estimations des heures réelles Chaque tâche doit avoir besoin de compléter, dans l'intention de devenir plus précise avec nos estimations au fil du temps: une fois qu'un projet a commencé, nous ne pouvons donc pas ajouter de nouvelles tâches ni ajuster les estimations horaires sur ces tâches.
Mais c'est ce que je crois comprendre que les pratiques agiles, en particulier Scrum, étaient basées sur le concept de tâches étant des godets qui stockent des objectifs livrables individuels et que vous ajoutez / supprimez / ajustez-les au fur et à mesure que les besoins des clients évoluent après chaque sprint.
Je me rends compte que cela pourrait potentiellement être argumentatif, mais je suppose que regarder Scrum comme processus, un seul de ces concepts est la philosophie "correcte" pour ce système.
9 Réponses :
Je ne sais pas si notre implémentation est "correcte", mais ce que nous faisons est:
Puis, pendant le sprint après chaque jour de travail, nous ajustons les temps sur les tâches que nous travaillons, de manière à montrer le nombre d'heures que nous pensons est laissée avant que la tâche ne soit effectuée . Cela signifie que si j'ai une tâche de 6 heures, travaillez-y pendant une journée complète (nous considérons 6 heures une journée complète), puis sentez-vous que j'ai encore 2 heures avant que ce soit fait, alors je supprime les "heures restantes" De 6 à 2. Dans le cas où la tâche est en boîte temporelle, nous devons vérifier les heures réelles utilisées à la place, bien sûr.
Assurez-vous de faire attention et d'estimer les tâches à fond. Fondamentalement, vous ne mesurez pas vraiment le temps, car il est sujette d'erreur. Le meilleur moyen est d'utiliser des estimations de temps de tâches comme Mais gardez les estimations du temps pour voir réellement quelles tâches doivent se diviser ou rejoindre.
Les réponses que je vois ici ne sont pas mauvaises, mais je ne pense pas qu'ils ont vraiment abordé votre question.
Je pense que vous demandez: " devrait je suive les heures totales effectivement dépensées sur une certaine tâche?" La réponse est: "Vous pouvez si vous en avez besoin, mais cela ne fait pas partie de Scrum."
Scrum est un processus très léger. Il définit / ne nécessite que ce qui est nécessaire pour faire du travail Scrum. Vous pouvez (et, dans de nombreux cas, devriez-vous probablement) recouvrir d'autres processus au-dessus de Scrum afin de répondre à vos besoins organisationnels. Par exemple, si le suivi des heures totales effectivement dépensés sur une tâche vous permet de mieux estimer des tâches similaires à l'avenir (comme cela semble que votre VP veut), cela pourrait être une bonne raison pour suivre les heures totales, à condition qu'il ne puisse pas interférer trop avec le travail productif. Ou peut-être avez-vous besoin de connaître les heures totales à des fins de facturation. Donc, juste parce que Scrum n'exige pas que quelque chose ne signifie pas que vous ne devriez pas le faire.
Toutefois, aux fins de Scrum lui-même, il n'est pas nécessaire de suivre les heures totales consacrées à une tâche. Il n'est pas nécessaire pour aucun des artefacts Scrum, qui ne suivent que la quantité de temps estimée restante.
C'est une réponse très agile. Il y a beaucoup de raisons pourriez-vous ajouter plus de suivi explicite du temps passé en tête de Scrum. Le plus courant est probablement la comptabilité des coûts. C'est-à-dire que possible, mais les équipes dans des seaux comptables significatifs.
Tracez-vous l'heure dans Scrum en fonction des heures / jours consacrées à une tâche ou simplement si cette tâche est complète ou non?
Je suivez le travail estimé restant estimé . Ceci est une information indispensable. Sans cela, vous ne pouvez pas dessiner l'organigramme. Sans le tableau de brûlures, vous ne savez pas "où" vous êtes, vous ne savez pas si votre sprint est toujours sur la bonne voie ou non. Cela rendrait cet outil de décision assez inutile. Oui, le graphique de brûlure
n'est pas un outil de suivi, c'est un outil de décision. Pouvez-vous ajuster ces tâches et estimations?
Bien sûr!
En fait, L'équipe possède les estimations , personne d'autre, et c'est le travail du Scrummaster de garger que ce principe soit appliqué. Cela devrait déjà répondre à la question. Mais il y a d'autres raisons.
Comme je l'ai dit, un arriéré de sprint et un graphique de brûlure sont des outils de décision et devraient donc être représentatifs de l'endroit où vous êtes vraiment. Si vous cachez la réalité, si vous n'êtes pas transparent, ces outils ne vous aideront pas à prendre une décision précieuse, elles seront inutiles. Pensez-y, quel est le point d'avoir de bons chiffres si elles sont inutiles? Quel est le point d'avoir un "beau burndique" si cela ne reflète pas la réalité.
Donc, lors d'un sprint, les membres de l'équipe devraient évidemment mettre à jour les estimations des travaux restants dès qu'ils peuvent le faire (vers le haut ou à la baisse). Si une estimation de tâche était initialement 6h, mais l'équipe découvre que plus de travail doit être fait et que la tâche prendra réellement 8h, l'équipe doit mettre à jour le carnet de sprint en conséquence. Si quelqu'un a passé 4 heures sur une tâche initialement estimée à 4h, mais il faut encore 2h de travail, ces 2h doivent être signalés sur le carnet de sprint. Si l'équipe découvre une tâche qui doit être faite mais qui n'a pas été identifiée, l'équipe doit ajouter cette tâche et son estimation à l'arriéré Sprint. Et n'étant pas précis dans le début n'est pas un problème, tant que vous mettez à jour l'arriéré avec les connaissances recueillies au fil du temps. Plus tôt vous faites ces mises à jour, plus tôt vous serez en mesure d'adapter et de prendre des décisions.
Cela dit, il peut être utile de conserver "l'estimation initiale" et de le comparer au "temps réel passé à compléter". Mais pas pour le suivi, seulement pour aider l'équipe à faire de meilleures estimations. En fait, je conseillerais de ne pas le faire si vous passez à Scrum. Il y a souvent beaucoup d'autres obstacles à résoudre, de nombreuses autres choses à améliorer d'abord lorsque vous apprenez des valeurs et des principes de Scrum. Et si vous le faites, méfiez-vous des démons à la cascade. Soyez prêt à les combattre, ils peuvent revenir très vite.
J'ai choisi cette réponse car elle répond pleinement à tous les critères de la question, ainsi que de donner une bonne quantité d'informations amicales. Merci Pascal!
Nous utilisons le Pomodoro Technique pour suivre le temps restant. L'un de ses avantages est que le temps passé est enregistré de manière disciplinée.
Après avoir estimé d'histoires dans des points d'histoire, nous estimons les tâches en termes de pomodilies et utilisez cette estimation (qui peut être réestimée par ad hoc) pour juger du temps restant. À la fin du sprint, il est facile de voir quelles tâches nous avons à l'origine estimé le moins de précision et améliorez comment nous estimons à l'avenir, en raison de la façon dont nous marquons le nombre de pomodoriens estimés et complétés sur chaque post-it.
En termes de sprint, les heures estimées restantes sont juste une mesure de progrès afin que nous puissions voir où nous sommes brûlés. Ils sont un indice pour que nous soyons sur la bonne voie ou non. Le score qui compte est des points d'histoire terminés.
Nous suivons à la fois le temps passé à travailler sur les tâches et le temps restant pour les compléter. Le temps restant permet de déterminer les progrès réalisés lors du sprint et d'anticiper si nous pourrons atteindre l'objectif de Sprint. Nous mettons à jour le temps restant pour les tâches, en l'ajustant (parfois en augmentant) quotidiennement.
Le temps passé est - supposément - pour la micro-gestion. Il donne également à l'équipe une chance d'obtenir des commentaires sur l'exactitude des estimations - et de s'améliorer à l'estimation - et de montrer comment les interruptions empêchent l'équipe de travailler sur le carnet de sprint et, par conséquent, ralentissez-la.
Dans le processus Scrum, les objectifs livrables individuels sont appelés éléments d'arriéré et peuvent être considérés comme un godet de tâches. Les éléments d'arriéré sont hiérarchisés par le propriétaire du produit, estimé par l'équipe, d'abord dans son ensemble, puis de tâche par tâche. Le contenu, la portée, la priorité et l'estimation des éléments d'arriétrie peuvent être révisés.
Nous estimons à la fois les éléments d'arriétrage et les tâches des unités de temps (jours ou semaines pour les éléments d'arriéré, heures pour les tâches) et nous appliquons un facteur de mise au point (le ratio de temps dédié au fonctionnement des tâches de sprint). Pour le temps non passé à travailler sur des tâches pour atteindre l'objectif de Sprint.
Je dois ajouter quelque chose ici parce que
Mais l'une des choses qu'il a apportées avec lui est le concept d'estimations très soigneusement citée des heures réelles que chaque tâche doit avoir besoin de compléter, dans l'intention de devenir plus précise avec nos estimations au fil du temps: Ainsi, une fois qu'un projet a commencé. Nous ne pouvons pas ajouter de nouvelles tâches ni ajuster les estimations horaires sur ces tâches.
est juste simple
pas Scrum, donc je ne sais pas où votre VP a obtenu ses informations. Les tâches (connaissent sous forme d'éléments d'arriéré Sprint) ne sont pas créées avant de planifier le prochain sprint. Ils sont créés juste à temps et certainement pas avant le début du projet. Avant le démarrage du projet (Sprint 0), le propriétaire du produit crée l'arriéré du produit et le remplit avec des histoires. Il peut y ajouter à tout moment pendant le projet. C'est sa façon de gérer. L'équipe estime ces histoires à peu près les unes contre les autres dans des points d'histoire ou une autre mesure relative (jours idéaux?). L'estimation des tâches en heures n'est qu'un outil utilisé par l'équipe pour déterminer le nombre d'histoires à s'engager dans le sprint, puis à parcourir des progrès pour prédire le succès (Burndown). Une fois qu'une équipe a gélifiée et a une vitesse historique; il peut décider de ne pas faire tout le suivi des heures du tout et de suivre seulement leur burndown points d'histoire ou d'histoires #. L'estimation des heures est une forme de déchets en soi si l'équipe n'en a pas besoin pour obtenir un engagement envers les objectifs du sprint.
Je demanderais au VP ce que ces estimations "très prudentes" vont accomplir.
Par définition, un élément est effectué lorsque toutes les tâches à remplir afin de mettre en œuvre pleinement cet élément sont disponibles à 0 heure. Ce que vous devez suivre dans le sprint reste des heures restantes sur les tâches restantes. Pas les heures passées sur une tâche. Pourquoi? Parce que notre connaissance de la durée de vie de quelque chose est imparfaite et que nous gagnons peu en essayant de trouver une estimation super précise lorsque nous devrions travailler sur le produit.
Vous êtes toujours autorisé à ajouter des tâches sous un élément d'arriétrage Sprint lorsque vous identifiez plus de travaux à effectuer pour mettre en œuvre complètement l'élément et vous devez mettre à jour les heures restantes à l'achèvement quotidiennement (ou les définir à 0 une fois que vous avez complété la tâche).
Vous devez indiquer à votre VP que vous connaissez lorsque vous allez expédier le produit en fonction de vos informations les plus précises (aujourd'hui) est beaucoup mieux que de définir un numéro / une estimation dans le passé et de ne jamais la mettre à jour. Cela ne signifie pas ré-estimer des histoires d'utilisateurs (ne faites pas cela jusqu'à la fin de la sortie), cela signifie que la mise à jour de l'arriéré Sprint avec de nouvelles tâches et la meilleure estimation de la mesure où des tâches actives seront complètes pendant les heures restantes.
BTW, la manière de travailler sur des estimations précises consiste à planifier votre libération à l'aide des points d'histoire, créez un plan d'itération basé sur votre vitesse d'équipe estimée, puis à mettre à jour continuellement le plan d'itération en fonction de la sortie à la fin de chaque sprint. . Après avoir très peu de sprints, vous obtiendrez une idée très précise de la vitesse réelle de l'équipe, ce qui facilite la prévision de la tâche lorsque vous expédierez votre libération avec la portée souhaitée ... ou la portée doit être complétée par la date du navire d'origine. Utilisation des données du projet réelles de votre projet actuel pour prédire l'achèvement du projet est une meilleure pratique de génie logiciel, car c'est le moyen le plus précis de faire une prédiction.
Je vote pour fermer cette question comme hors-sujet car il ne s'agit pas de la programmation.
Wow! 8 ans plus tard! Je pense que logicielgowEgineering.stackexchange.com est devenu une chose de 6 ans il y a une autre? Donc, c'était avant qu'il y ait eu un autre endroit pour cela.
Nous nettoyons simplement de vieilles questions.
Non, cela a du sens totalement: devrait-il être migré là-bas?
Vous ne pouvez pas migrer de vieilles questions, il y a une fenêtre de temps pour la migration