Dans un projet informatique:
- Qui devrait participer à l'estimation du temps? Développeur, chef d'équipe, scrum master et etc?
- Quel vote devrait être le plus compté?
Dans un projet informatique:
Réponses:
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.)
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 .
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".
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.
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.