Temps d'estimation des tâches

Question

Nous venons de commencer à faire de la mêlée dans mon entreprise. Nous passons un peu de temps à estimer l'effort en utilisant le poker de planification, puis lorsque les tâches détaillées sont élaborées, une estimation de temps est mise sur chaque tâche. Le problème que nous avons est que les estimations de temps sont constamment fausses (généralement sur estimé). Bien que nous soyons tous d'accord sur un effort, il est beaucoup plus difficile de s'entendre sur le temps d'une tâche - ce qui prend une personne par heure peut prendre trois heures à quelqu'un d'autre. Nous finissons par aller quelque part au milieu.

Qui devrait proposer l'estimation du temps pour une tâche et quand cela se produit-il?

Est-ce juste quelque chose dont nous avons besoin de plus de pratique, ou faisons-nous le mal?

Answer 1

Les personnes effectuant réellement le travail estiment le coût impliqué. Si vous utilisez le temps brut comme une métrique pour l'estimation, les méthodologies Agile froncent les sourcils. Votre équipe devrait utiliser une abstraction pour estimer les coûts, tels que les «points». Vous pouvez commencer avec une ligne de base approximative de 1 heure par point avec un minimum de 1 point. Ensuite, les développeurs peuvent faire des estimations brutes de combien de temps quelque chose devrait prendre. Glissez-les ou toute autre personne sur le poignet s'ils parlent en heures ou dans une autre unité de temps. Le fait est que, à mesure que le développement progresse à travers plusieurs sprints, les chefs de projet peuvent ajuster les estimations de temps «ponctuelles» fournies par l'équipe pour correspondre à la réalité. Cela peut même être fait par développeur individuel. Les participants deviendront de mieux en mieux estimés à mesure que les projets progresseront. Donc, puisque les Sprints sont un processus itératif, les estimations de temps s'améliorent avec plus d'itérations.

Cela soulève une autre question: pourquoi vous inquiétez-vous du temps? Le temps est essentiellement le coût dans le modèle Waterfall. En Agile, l'objectif est de développer des logiciels à VALUE sans coût. Les points de la raison sont utilisés est que c'est une base de comparaison abstraite que les propriétaires d'entreprise, les gestionnaires de projet et les créateurs (les développeurs) peuvent tous voir dans une lumière abstraite. Les propriétaires d'entreprise peuvent examiner les points disponibles dans un sprint donné - et en connaissant les points disponibles - ils peuvent choisir les fonctionnalités les plus importantes. C'est toujours une décision difficile, mais encore une fois, l'objectif est de se développer vers la valeur et loin de la boxe du temps ou de la farce.

Answer 2

"Qui devrait arriver avec l'estimation de temps pour une tâche et quand cela arrive-t-il?" Cela dépend de la façon dont vous dirigez votre équipe. Laissez-vous les membres de l'équipe s'autogérer, donc les tâches sont assignées quand une personne l'attrape pendant le sprint? Vous devrez peut-être continuer à utiliser le temps nécessaire en fonction des capacités d'un développeur moyen de l'équipe. Avez-vous un chef d'équipe qui attribue les tâches aux personnes telles qu'elles ont été créées pendant la réunion de planification du sprint? Laissez la personne assignée estimer le temps nécessaire pour terminer la tâche.

Je suis d'accord pour retirer du temps de l'estimation de l'effort est un peu déroutant. La grande question est: qu'importe que vous surestimiez le temps de la tâche? Est-ce que l'équipe reste assise pendant 4-5 jours à la fin d'un sprint sans rien à faire? Si c'est le cas, rendez-vous chez le Product Owner et dites-lui que l'équipe souhaite ajouter un ou deux petits objets dans le Sprint. Normalement, vous n'ajoutez pas d'éléments à un sprint en cours, mais Scrum est un framework pour gérer le travail, et tant que l'équipe ne signe pas l'ajout des nouveaux éléments, il n'est pas nécessaire de laisser Scrum travailler pour votre équipe ... .pas forcer votre équipe à travailler pour Scrum. De plus, vos questions semblent indiquer que votre équipe a une plus grande vélocité que ce qui est planifié. Si votre sprint de 2 semaines (10 jours de travail) a une vélocité de 10, mais que votre équipe en a fini avec tout le jour 7, placez vos points d'histoire sur le prochain sprint à 11 ou 12.