Qui devrait participer à l'estimation du temps?

9

Dans un projet informatique:

  1. Qui devrait participer à l'estimation du temps? Développeur, chef d'équipe, scrum master et etc?
  2. Quel vote devrait être le plus compté?
Amir Rezaei
la source
2
Si vous faites Scrum : (a) il n'y a pas de chef d'équipe. (b) l'équipe doit estimer collectivement en utilisant Planning Poker. (c) et le gars qui fera probablement la tâche devrait être suivi. Une équipe Scrum est interfonctionnelle et les tâches ne sont pas attribuées, mais si le gars qui maîtrise la base de données dit que cela devrait prendre 3 jours. Cela devrait probablement prendre 3 jours.
1
Vous devez savoir qu'une estimation n'est pas une décision, mais une prédiction (souvent difficile). Il n'y a pas de hiérarchie. Il n'y a pas de votes.
user281377
@ammoQ Le problème est que de nombreux chefs de projet ont cette décision!
Amir Rezaei
2
Ouais, c'est une idée fausse mentale courante. Bien sûr, vous pouvez prendre une décision sur le calendrier, mais vous devez alors estimer (c.-à-d. Prédire) la qualité et l'exhaustivité archivables à la place.
user281377
@ user281377 J'aime ce que vous avez: le principe d'incertitude de Heisenberg pour le développement de logiciels.
K.Steff

Réponses:

8

Il ne s'agit pas tant des personnes impliquées que des compétences qui doivent être présentes:

  • Une bonne compréhension du domaine problématique - ceci est particulièrement important lorsque les exigences sont ambiguës ou de haut niveau. En tant que programmeur qui n'a jamais travaillé dans les voyages pour estimer le travail concernant les classes de billets dans un avion et ils supposeront qu'il y en a 3 ou 4 (économie, affaires, d'abord etc.) mais si vous avez travaillé dans les voyages, vous saurez qu'il y en a des dizaines. Cela peut signifier qu'un analyste métier ou un utilisateur expert est impliqué, bien qu'avec le temps les développeurs eux-mêmes développent ce type de connaissances.

  • Une compréhension de la technologie et du travail qui sera impliqué - généralement un développeur mais un gestionnaire avec une expérience récente qui a la confiance de l'équipe peut souvent faire le travail. Idéalement, si vous obtenez la personne qui effectuera réellement le travail de cette façon, elle est incluse dans le devis.

  • Une compréhension du processus d'estimation - c'est la clé. Il faut comprendre comment faire une estimation décente, comment s'assurer qu'elle est correcte, vérifier les niveaux appropriés de contingence, vérifier le double comptage ou trop de remplissage. Habituellement, un PM, un gestionnaire de développement ou un développeur senior apportera cela, bien que dans certains processus, un modèle d'estimation solide puisse fournir les conseils nécessaires.

Ces compétences peuvent être chez une seule personne, mais parfois elles en auront besoin de trois ou plus, mais l'essentiel est de s'assurer que ces compétences sont présentes, pas que des personnes en particulier soient présentes.

Cela dit, en général, bien que je recherche plus de deux personnes, car vous voulez l'assurance supplémentaire que deux personnes ou plus vérifient le travail des autres.

Pour ce qui est du vote qui compte le plus, cela ne fonctionne pas comme ça. C'est une discussion et une négociation. Si un gestionnaire pense que les développeurs estiment trop élevé, il doit expliquer pourquoi et contester (et non faire pression) le développeur pour le justifier et ils doivent parvenir à un consensus. Si vous ne parvenez pas à cet accord, je dirais deux choses par expérience:

(a) N'allez pas avec le nombre que vous "voulez", c'est simplement demander des ennuis et ce que vous voulez n'a aucun impact matériel sur la rapidité avec laquelle le travail peut être fait.

(b) Dans à peu près tous les cas que j'ai vus où un développeur a été jugé sur une estimation, le nombre final est plus proche de ce que le développeur pensait que celui qui les dominait - en grande partie parce qu'ils ont ignoré le point (a) au dessus de.

(Cela dit, en agile, je crois, et certainement sous XP, la règle est que les développeurs contrôlent les estimations et c'est définitif. Si les utilisateurs veulent réduire les estimations, ils doivent changer l'exigence de quelque chose de plus simple.)

Jon Hopkins
la source
+1 pour le nombre que vous "voulez". Voyez ici .
Spencer Rathbun
1
Quelque chose de plus approfondi sur le "numéro que je veux": Estimation Games
K.Steff
2

Je ne sais pas s'il y a une réponse unique à cette question. Là où je travaille, il y a généralement deux ingénieurs de l'équipe qui mettront en œuvre la fonctionnalité / correction qui fournira une estimation. Ainsi, deux ingénieurs fournissent chacun une estimation "min", "max" et "attendue". Nous nous attendons généralement à ce que les deux estimations soient raisonnablement cohérentes, donc si elles sont très différentes, alors une discussion plus approfondie peut être nécessaire (peut-être qu'un ingénieur a fait des hypothèses que l'autre ne l'a pas fait, etc.).

Dans notre situation, le «vote» de personne n'est pas compté comme tel. Nous faisons généralement juste la moyenne des deux estimations (rappelez-vous, si elles ne sont pas déjà dans le même stade approximatif, alors nous rejetons les deux et recommençons les discussions, donc prendre la moyenne n'est pas un grand bond). Après tout, les estimations ne sont que des estimations, elles n'ont donc pas besoin d'être exactes .

Dean Harding
la source
1

D'après mon expérience, les estimations ont tendance à être faites par la personne qui effectuera probablement la tâche elle-même. Les équipes SCRUM doivent s'efforcer d'être interfonctionnelles, mais après un certain temps, certains types de tâches sont généralement effectués par les mêmes personnes.

Il est d'une importance vitale d'obtenir l'approbation de l'équipe sur toutes les estimations. Si un développeur estime qu'il possède une estimation, il s'efforcera de la respecter. Si les développeurs reçoivent une estimation qu'ils n'ont pas fait eux-mêmes et n'ont eu aucune contribution ou influence, ils ne ressentiront pas le même niveau de responsabilité et les découverts seront expliqués avec "Je vous ai dit que cela prendrait plus de temps".

bouillie
la source
0

Un projet a des exigences commerciales et des délais de haut en bas. Ce sont des «estimations données» pour la première itération.

Ces exigences doivent être partitionnées aux tâches les plus importantes ayant un coût connu à 100% (comme «activer la journalisation» = 2 heures = «télécharger log4j / SLF4J et brancher»).

L'estimation doit être faite au niveau le plus élevé possible qui dispose déjà de suffisamment d'expertise technique pour le faire.

Les estimations corrigées doivent remonter sous forme de «caractéristique visible de l'entreprise» = «cette quantité de temps» jusqu'à ce qu'elles atteignent le propriétaire de l'entreprise à un niveau approprié, capable d'abandonner / modifier les exigences ou d'assouplir les délais. Puis redescendez. Jusqu'à la convergence finale. Dans la pratique, les gens ont tendance à ignorer cette phase ou à la simplifier, ce qui peut à son tour créer des risques associés aux délais et opportunités manqués.

bobah
la source
1
"Un projet a des exigences commerciales + des délais venant de haut en bas. Ce sont des" estimations données "pour la première itération." - Malheureusement vrai et responsable du type de pression qui amène les autres à donner des estimations inexactes alors qu'ils essaient de respecter ces délais malgré le temps que cela prendra réellement.
Jon Hopkins
@Jon Hopkins - +1, juste point, mais j'ai décrit le processus idéal, en réalité, comme vous l'avez dit, les responsables techniques préfèrent parfois s'engager dans un calendrier irréaliste a priori et trouver des "justifications" pour les retards au fur et à mesure du projet
bobah
Je ne critique pas votre réponse - je dis simplement que cet élément particulier doit être pris en compte et que ceux qui estiment devraient, si possible en premier lieu, ne pas être informés de ces délais par crainte d'être influencés par eux.
Jon Hopkins
1
"Un projet a des exigences commerciales et des délais qui viennent de haut en bas." - À moins que les personnes au sommet soient des développeurs eux-mêmes ayant une expérience «dans les tranchées», c'est une recette pour la CATASTROPHE.
Vector
Avez-vous déjà remarqué que les équipes de la MLB ont toujours un ancien joueur comme manager dans l'abri? C'est parce que seul un ancien joueur comprend ce qu'il faut pour faire le travail et a la confiance des gars qui prennent le terrain.
Vector
-1

Qui ou qui devrait participer à l'estimation du temps? Développeur, chef d'équipe, scrum master et etc?

Je préfère que tout soit là dans l'estimation du temps et nous faisons de même ici

Qui ou dont le vote devrait être le plus compté?

Développeur mais toujours son travail d'équipe

Gopi
la source
-2

LES DÉVELOPPEURS SONT CHARGÉS DE LA MISE EN ŒUVRE DU PROJET! PERSONNE D'AUTRE!

Les développeurs qui font le travail réel et les chefs d'équipe de développement sont les seuls capables d'estimer correctement combien de temps cela prendra réellement. Seuls les programmeurs familiarisés avec la base de code réelle peuvent comprendre les difficultés et les pièges potentiels qui peuvent être rencontrés au cours du développement. Tout le monde est un «spectateur».

En outre, la seule façon de faire confiance aux développeurs pour fournir des estimations précises est lorsque les hommes d'affaires leur font confiance et comptent sur leur expertise de telle sorte que les développeurs savent qu'ils ne seront pas pénalisés si leur estimation ne répond pas aux attentes de l'entreprise.

Règle de base: cela prendra au moins 3 fois plus de temps que l'estimation de tout chef de projet ou homme d'affaires qui ne connaît pas intimement les défis du développement pratique et la base de code en question.

En tant que personne qui a travaillé en tant que développeur indépendant et en tant qu'employé dans de grandes sociétés pendant près de 20 ans, je le dis avec la plus grande certitude et au bénéfice d'une grande expérience amère.

Vecteur
la source
2
Veuillez améliorer cette réponse.
K.Steff