Comment répondre quand on vous demande un devis?


652

En tant que programmeurs, on nous demande constamment «combien de temps cela prendra-t-il»?

Et vous savez, la situation est presque toujours la suivante:

  • Les exigences ne sont pas claires. Personne n’a procédé à une analyse approfondie de toutes les implications.
  • La nouvelle fonctionnalité va probablement briser certaines hypothèses que vous avez faites dans votre code et vous allez commencer à penser immédiatement à tout ce que vous pourriez avoir à refactoriser.
  • Vous avez d'autres tâches à accomplir dans le cadre de missions antérieures et vous devrez produire une estimation tenant compte de ces autres tâches.
  • La définition du "fait" n'est probablement pas claire: quand sera-t-il terminé? 'Terminé' comme juste fini de le coder ou 'terminé' dans "les utilisateurs l'utilisent"?
  • Peu importe votre degré de conscience de toutes ces choses, parfois votre "fierté du programmeur" vous fait donner / accepter des délais plus courts que vous ne le supposiez au départ. Surtout lorsque vous ressentez la pression des délais et des attentes de la direction.

Beaucoup d’entre eux sont des problèmes organisationnels ou culturels qui ne sont pas simples et faciles à résoudre, mais en réalité, on vous demande une estimation et ils s’attendent à ce que vous donniez une réponse raisonnable. Cela fait partie de votre travail. Vous ne pouvez pas simplement dire: je ne sais pas.

En conséquence, je finis toujours par donner des estimations que je réalise ensuite que je ne peux pas remplir. Cela s'est produit d'innombrables fois et je promets toujours que cela ne se reproduira plus. Mais c'est le cas.

Quel est votre processus personnel pour décider et livrer un devis? Quelles techniques avez-vous trouvé utiles?



4
Si les exigences ne sont pas aussi claires, vous pouvez estimer avec une marge d'erreur de 50% (plage plus large). Si les exigences sont claires, vous pouvez estimer avec une marge d'erreur de 20%. Une autre bonne stratégie qui a fonctionné pour moi est de scinder un projet en étapes. Cette façon de procéder est plus facile à estimer et il vous suffit d’estimer la première étape. Lorsque vous êtes sur le point d’estimer la prochaine étape, vous comprenez beaucoup mieux le projet. En outre, la confiance entre vous et votre entrepreneur devrait être meilleure. J'écris aussi toujours mes hypothèses et conditions préalables. N'écrivez jamais "cela fonctionnera sur IE8 ou supérieur", soyez précis.
Francisco Goldenstein

Sergio, "En conséquence, je finis toujours par faire des estimations que je réaliserai plus tard que je ne peux pas remplir. C'est arrivé d'innombrables fois, et je promets toujours que cela ne se reproduira plus. Mais ça arrive." A quel point vous sentez-vous amélioré aujourd'hui?
Remigijus Pankevičius

4
@ r.pankevicius Honnêtement, je viens d'arrêter de donner des estimations: rclayton.silvrback.com/software-estimation-is-a-losing-game
Sergio Acosta

2
Je pense qu'il est également important de voir la nuance entre "estimations" et "délais". Une estimation n'est pas un engagement, donc une erreur mineure ne devrait pas être trop problématique. J'ai écrit un long post sur ce blog au cas où cela vous intéresserait: marcgg.com/blog/2015/08/27/deadlines-estimates-software-startup
marcgg

Réponses:


390

Du programmeur pragmatique: De compagnon à maître :

Que dire lorsqu'on lui demande une estimation

Vous dites "je vais revenir à vous."

Vous obtiendrez presque toujours de meilleurs résultats si vous ralentissez le processus et passez un peu de temps à suivre les étapes décrites dans cette section. Les estimations données à la machine à café (comme le café) reviendront vous hanter.

Dans la section, les auteurs recommandent le processus suivant:

  • Déterminez la précision dont vous avez besoin. En fonction de la durée, vous pouvez citer l'estimation avec une précision différente. Dire "5 à 6 mois" est différent de dire "150 jours". Si vous glissez un peu dans le 7ème mois, vous êtes toujours assez précis. Mais si vous passez au 180ème ou au 210ème jour, pas trop.
  • Assurez-vous de comprendre ce qui est demandé. Déterminez la portée du problème.
  • Modéliser le système. Un modèle peut être un modèle mental, des diagrammes ou des enregistrements de données existants. Décomposez ce modèle et construisez des estimations à partir des composants. Attribuez des valeurs et des plages d'erreur (+/-) à chaque valeur.
  • Calculez l'estimation en fonction de votre modèle.
  • Suivez vos estimations. Enregistrez des informations sur le problème que vous estimez, votre estimation et les valeurs réelles.
  • Les autres éléments à inclure dans votre estimation sont le développement et la documentation des exigences ou des modifications apportées aux spécifications, la création ou la mise à jour des documents de conception et des spécifications, les tests (unité, intégration et acceptation), la création ou la mise à jour des manuels de l'utilisateur ou des fichiers README avec les modifications. Si 2 personnes ou plus travaillent ensemble, cela entraîne des frais de communication (appels téléphoniques, courriels, réunions) et la fusion du code source. Si la tâche est longue, prenez en compte des éléments tels que les autres tâches, les congés (vacances, congés maladie, congés de maladie), les réunions et les autres frais généraux lors du choix d'une date de livraison.

32
C'est également une grande partie de "Black Art of Software Estimation" de McConnells. Jamais de façon informelle.
Paul Nathan

12
Je recommande fortement le livre McConnell. Si possible, demandez à quiconque a besoin d'une estimation de votre part de répondre à son quiz d'estimation: codinghorror.com/blog/2006/06/… Vous pouvez le présenter sous forme de jeu, mais il est souvent utile de faire passer le message.
Paddyslacker

130
Vous pouvez toujours dire "je vous recontacterai". Si quelqu'un dit: "J'ai besoin d'une réponse", dites: "Si je vous donne une réponse maintenant, ce sera un mensonge. Je n'ai pas suffisamment d'informations pour le moment. Ce serait un mauvais service pour nous de faire quelque chose sur place. "
Andy Lester

15
@AndyLester - Il y a de nombreuses situations dans lesquelles, si VOUS ne donnez pas de réponse maintenant, quelqu'un d'autre le fera et prendra le projet et l'argent, ou vous accusera-t-il à la fin d'avoir manqué une estimation que vous n'aviez rien faire avec. C'est nul, et c'est faux, mais c'est malheureusement la réalité.
Joris Timmermans

3
@ThomasOwens Je n'utiliserais jamais d'estimation tirée de la hanche pour un contrat, mais j'utilise ces estimations avant l'étape du contrat. Je dois donner un ordre de grandeur avant que le client ne consacre son temps précieux à entrer dans les petits détails sanglants - si ce qu’ils envisagent de payer est inférieur de plusieurs ordres de grandeur à mon optimisme, il ne sert à rien. début.
Joris Timmermans

170

L'estimation de logiciel est la tâche la plus difficile en ingénierie logicielle, suivie de près par la détermination des exigences.

Il existe beaucoup de tactiques pour les créer, toutes basées sur l’obtention préalable de bonnes exigences. Mais quand ton dos est contre le mur et qu'ils refusent de te donner de meilleurs détails, Fake It:

  1. Regardez bien les exigences que vous avez.
  2. Faites des hypothèses pour combler les lacunes en fonction de votre meilleure estimation de ce qu'elles veulent
  3. Notez toutes vos hypothèses
  4. Faites-les asseoir, lisez et acceptez vos hypothèses (ou, si vous êtes chanceux, demandez-leur de vous donner et de vous donner de vraies exigences).
  5. Vous avez maintenant des besoins détaillés à partir desquels vous pouvez estimer.

C'est comme si ma mère menaçait quand j'étais enfant "Dépêche-toi de choisir des vêtements, ou je les choisis pour toi!"


J'ai posé une question de suivi concernant votre troisième point. programmers.stackexchange.com/questions/132970/…
k0pernikus

Combien de temps faut-il pour écrire de bonnes exigences?
Mmehl

142

J'ai fait du développement pour un gars qui tenait beaucoup à vouloir des estimations précises. Ce sur quoi nous avons décidé, qui a très bien fonctionné, était ceci:

  • J'ai facturé tout le temps que j'ai passé à estimer. Cela représentait environ 20-25% de ce que j'avais facturé.
  • J'ai fait un examen extrêmement détaillé des tâches. Pas de tir de la hanche. Je suis allé dans le code, j'ai découvert quelles lignes devaient être changées, quelles autres parties du programme cela affecterait, combien de tests il faudrait faire pour s'assurer que tout fonctionnait toujours. Je pense chaque pièce en unités de 0,1 heure (6 minutes).
  • Je lui ai envoyé mon estimation pour chaque tâche avec cette ventilation détaillée.

20-25% de la facturation semble beaucoup.

Mais il me demandait de changer XYZ, pensant que cela prendrait environ 2 heures. En 1 heure d'estimation détaillée, je déterminais que cela prendrait 8,5 heures. Alors, il déciderait si cela valait 8,5 heures de salaire. Sinon, il a économisé 7,5 heures par rapport à ce qu'il lui aurait coûté si je l'avais fait sans estimation.

Et s'il ne voulait investir les 8,5 heures, le travail de détail , je l'ai fait pour l'estimation était le travail que je l' aurais dû faire de toute façon.

J'ai découvert qu'avec cette méthode, j'étais capable de réaliser la plupart des tâches à temps ou même tôt, sans avoir à surestimer fortement. Comme le temps était si minutieusement décomposé, je pouvais dire très tôt si je glissais. Si je franchissais les barrages routiers de façon à pouvoir dire après trois heures que ma tâche de 8 heures et demie en prenait 12, je pourrais lui en parler avant qu'il ne se soit écoulé plus de temps, de sorte qu'il puisse réévaluer et retirer la fonctionnalité s'il était préoccupé par le coût. .

Était-il nickel et diming? Non, j'ai considéré que le laisser utiliser son argent là où il voyait le plus d'avantages. Et j'étais heureux d'avoir de l'expérience en estimation, pour laquelle j'avais toujours été terrible.


12
Cela ressemble à une technique très adéquate. En fait, lorsque vous faites une estimation pour votre propre entreprise, le temps estimé est également payé dans le cadre de votre salaire. Cependant, je crains que le problème ne réside dans le fait que la plupart des entreprises veulent des estimations de tâches beaucoup plus volumineuses que celles pouvant être exprimées en parties d'une heure. Merci pour votre réponse. (Es-tu le même Kyralessa du joel sur les cartes de logiciel?)
Sergio Acosta

1
Oui, le même.
Kyralessa

@SergioAcosta le point est que vous utilisez le temps d'analyse / estimation pour décomposer la tâche en fragments plus petits. C'est la meilleure réponse, à mon humble avis.
NimChimpsky

7
Donc, s’il s’agit d’un projet de 5 mois, vous devriez l’estimer pour un mois ou plus. Les gestionnaires n'accepteront probablement pas cela :)
Darius.V

@ Darius.V, vous faites valoir un bon point. Dans ce cas, les décisions du client étaient oui ou non pour des caractéristiques particulières, pas globalement pour un oui ou un non pour l'ensemble du projet. Cette technique est certainement plus difficile si faire tout le projet ou non dépend de l’estimation globale. D'un autre côté, si vous budgétisez six mois pour un projet, mais que le projet peut durer un an, préférez-vous le savoir au bout de six mois ou de deux ou trois ans?
Kyralessa

64

On nous demande souvent une «estimation approximative» lors de réunions où nous avons une idée très large et très large de ce qu’ils aimeraient faire. Je dis toujours: "Si vous voulez une réponse aujourd'hui, c'est un an et un million de dollars. Si vous souhaitez me donner beaucoup plus de détails et un peu de temps pour les examiner, je peux alors les affiner pour vous."

Ils obtiennent presque toujours le point.


7
Quand ils disent que c'est trop, je fais semblant de réfléchir pendant une minute, puis je dis: "Tu as raison! Il est 18 mois et 2 millions".
CyberFonic

55

Cela dépend de ce que l'estimation est pour.

Pour une estimation initiale de haut niveau pour une analyse de rentabilisation, les éléments clés sont les suivants:

  1. La vitesse. Quelle que soit la méthode utilisée, elle doit être rapide. Le problème est que les parties prenantes ne savent pas si cela vaut la peine de faire le projet - c'est pourquoi elles ont besoin des chiffres pour l'analyse de rentabilisation. Si l'analyse de rentabilité était solide, ils n'auraient pas besoin de vos estimations. La majeure partie de ces projets ne se concrétisera pas. Il est donc important de ne pas consacrer trop d’efforts à l’estimation.
  2. Donner une gamme. Faites-le large. Vous n'avez pas eu le temps d'analyser les exigences, d'organiser des ateliers avec les parties prenantes et de valider les hypothèses. Un large éventail indique au destinataire de l'estimation "Les projets logiciels sont naturellement complexes et risqués - si vous souhaitez une estimation correcte, vous devez me donner plus de détails et plus de temps". Le problème avec l'attribution d'un nombre unique ou d'une plage étroite est que cela vous tracasse en définissant les attentes avant toute analyse réelle.

Je trouve la meilleure technique pour choisir un projet comparable qui "se sent" la même chose. "Feel" est totalement subjectif - mais avec ce type d'estimation, mon expérience me dit que vous ne trouverez pas de mesures objectives. Ensuite, fournissez une large gamme. J'ai lu des livres qui disent qu'une plage de -50% à + 100% est bonne, mais cela dépend de nombreux facteurs.

Pour une estimation détaillée de bas niveau:

  1. Vous avez besoin d'une base. Si la base de référence n'est pas stable, l'estimation n'a pas de sens.
  2. Bottom up est le meilleur. Obtenez une ventilation détaillée du travail, estimez chaque composant, puis regroupez-le en un plus grand nombre. Je trouve que la planification du poker est une excellente technique ici.
  3. Document contingence. Indiquez clairement où une éventualité (le cas échéant) est ajoutée. Est-il ajouté à chaque élément de campagne? Ou à l'ensemble de l'estimation? Ou à des risques spécifiques? Ou n'y en a-t-il pas?
  4. Énoncez vos hypothèses. Valider autant que possible en fonction du délai.
  5. Indiquez explicitement ce qui est inclus et exclu dans l'estimation. Par exemple, la révision est-elle incluse? Les retards techniques sont-ils inclus?

25

Quelques conseils du côté obscur de celui qui a appris à la dure.

Les exigences ne sont pas claires. Personne n’a procédé à une analyse approfondie de toutes les implications.

Ne faites pas d'estimation à ce stade. On n’estime pas combien de soldats sont nécessaires pour gagner une bataille sans avoir la moindre idée du nombre d’ennemis. L'estimation est faite après le dépistage. Ceci est sauf si vous avez déjà combattu cet ennemi.

La nouvelle fonctionnalité va probablement briser certaines hypothèses que vous avez faites dans votre code et vous allez commencer à penser immédiatement à tout ce que vous pourriez avoir à refactoriser.

C’est à vous qu’il incombe d’en tenir compte, sauf si vous vous attendez à ce que les autres possèdent l’expertise nécessaire dans ce domaine.

Vous avez d'autres tâches à accomplir dans le cadre de missions antérieures et vous devrez produire une estimation tenant compte de ces autres tâches.

Idem que ci-dessus, même pour un travail imprévu créé par un coéquipier slob à côté de vous avec une procédure de test quasi inexistante qui provoque un problème de code que vous ne pouvez pas prédire à l'avance. C'est une météo.

La définition du "fait" n'est probablement pas claire: quand sera-t-il terminé? 'Terminé' comme juste fini de le coder ou 'terminé' dans "les utilisateurs l'utilisent"?

Comprenez les besoins de l'utilisateur ici, pensez comme un utilisateur. Ne faites pas ce que font vos pairs s’ils estiment qu’une tâche doit être "exécutée", simplement parce qu’une fonctionnalité de base avec un flux de travail barebone qu'aucun utilisateur ne peut tolérer est ce qu’ils considèrent être "réalisée" . Pensez-y du point de vue de l'utilisateur, car c'est tout ce que le client pour lequel vous faites une estimation comprendra généralement. Estimez en fonction des besoins complets de l'utilisateur, et non des besoins techniques barebone. Et réalisez que vos clients demandant des estimations seront totalement inexacts sur la façon dont ils formulent les choses et comprennent les aspects techniques de ce que vous dites.

Peu importe votre degré de conscience de toutes ces choses, parfois votre "fierté du programmeur" vous fait donner / accepter des délais plus courts que vous ne le supposiez au départ. Surtout lorsque vous ressentez la pression des délais et des attentes de la direction.

Ne fais pas ça! Vous parlez comme un travailleur acharné et motivé, et peut-être même quelqu'un qui cède facilement à la contrainte.

Le problème ici est le suivant: supposons que Joe et vous avez fait une estimation de temps pour la même tâche (mais entre deux employés distincts ne connaissant pas les deux estimations à la fois). Vous estimez vaillamment, "une semaine" . Ce n'est pas grave, pensez-vous, vous travaillerez plus de 100 heures par semaine, en heures supplémentaires non rémunérées. Maintenant, vous avez trois jours de retard.

Pendant ce temps, Joe estime 5 mois. Vous pensez que c'est ridicule, vous pensez pouvoir retirer ceci en une semaine. Combien travaille Joe? 10 heures par semaine? ... sauf qu'il termine à temps dans exactement 5 mois.

Devinez qui est perçu comme le crétin? C'est vrai, vous. Joe semble être un excellent ouvrier, vous ne semblez pas fiable maintenant. Peu importe que vous ayez pu obtenir un résultat encore meilleur dans environ 7% du temps que Joe a pris. Ce qui compte, c’est que vous disposiez de 3 jours de congé par rapport à une estimation d’une semaine.

Ne vous trompez jamais du côté de l'estimation la plus serrée. Err du côté de l'estimation la plus souple. Votre entreprise doit se faire une réputation et ne sera pas basée sur la longueur de vos estimations mais sur l’exactitude de vos estimations. Il est facile d’être précis avec une estimation trop longue, vous avez juste plus de temps pour travailler sur le problème et le résoudre mieux. Une estimation trop courte ne laisse aucune marge de manœuvre, vous la rencontrez désespérément ou vous vous faites avoir.


2
C'est une excellente réponse, cela me donne des indications très utiles sur la façon d'estimer et de considérer les choses, merci
mboullouz

18

"Deux semaines!"

Sérieusement. Ma première estimation est toujours deux semaines. Parce que j'ai une sorte de blocage mental bizarre qui me fait penser que tout sonne comme si ça allait durer deux semaines.

J'essaie de contourner le problème , d'essayer de réfléchir vraiment au temps qu'il faudra, de tenter quelque chose, d'essayer d'identifier tous les points chauds potentiels et les éléments qui semblent trop noirs pour que je puisse effectuer une estimation précise. Et essayez de reconnaître que si ma réponse est "Deux semaines!", J'ai probablement échoué.

Pratiquement tous les bons managers que j'ai eu ont appris à reconnaître "Deux semaines!" comme une réponse qui nécessite une légère gifle verbale en réponse.


3
C’est probablement pour cette raison que la plupart des équipes font des sprints de 2 semaines :)
Cristian E.

17

Une entrée de blog explique comment garder une trace de la précision de vos estimations précédentes, puis la prochaine fois que vous direz à quelqu'un "ça fera deux semaines", vous pourrez consulter votre historique et voir combien de temps il durera. effectivement pris la dernière fois que vous avez dit "ça va être deux semaines".

Je n'ai pas essayé moi-même, mais j'aimerais bien voir à quel point mes estimations sont précises.


2
Joel's Fogbugz va plus loin et analyse vos données pour vous en utilisant une planification basée sur des preuves. En d'autres termes, chaque développeur entre combien de temps il pense que chaque tâche va prendre et, plus tard, combien de temps elle a pris, et indique la précision de chaque développeur avec ses estimations pour produire une courbe de probabilité pour une date d'achèvement.
Chris Buckett

Ouais, alors fais un peu de GDD - Gauge Driven Development et ruine tout
Claudiu Constantin

11

Cela dépend de l'organisation et de la manière dont les estimations sont utilisées.

Si l'estimation a simplement pour but de donner une idée générale du moment où elle sera prête, je peux généralement faire une estimation rapide en fonction de mon expérience. Souvent, j'inclus toute estimation d'incertitude ou de variation possible avec la manière dont les modifications peuvent affecter d'autres zones du système et l'ampleur des tests de régression requis.

Si l'estimation est utilisée pour quelque chose de contractuel ou dans un scénario où un timing plus précis est requis, je décompose le travail en entier. Cela demande plus de travail et nécessite une réflexion plus approfondie sur la conception et les modifications du système, mais il est beaucoup plus précis, en particulier pour les travaux plus volumineux.

Dans les deux cas, la communication continue est la clé. Si vous rencontrez un événement inattendu, faites-le-lui savoir au lieu d'attendre la date limite. Si les exigences ne sont pas claires, assurez-vous de documenter votre compréhension et les fonctionnalités que vous prévoyez de fournir. Ceci est également utile avec toutes les hypothèses que vous faites. Et en ce qui concerne les priorités concurrentes, quand un travail en impose un autre, expliquez clairement en quoi cela affectera le calendrier.


2
+1 pour le besoin de communication continue. OMI, c’est la partie la plus utile du modèle Agile.
Scott Weldon

C’est la première réponse décente ici, tout simplement parce que c’est le seul cas de ce genre (je lis ce qui se passe de haut en bas) qui met l’accent sur la "communication continue". Tout le monde semble penser que la communication d'estimation est un événement ponctuel. C'est un mauvais conseil et une mauvaise approche de ces choses. Cette réponse est un bon conseil.
Adam Cameron

9

Des estimations pour quoi? Petites tâches ou solutions complètes.

C’est ce dernier cas que je fais rarement, mais je suppose qu’il faut ajouter un peu, demander au responsable d’en ajouter un peu et en faire une plage, avec une petite note à côté indiquant que ce qui précède est une estimation.

Petites tâches - Je trouve que la planification du poker fonctionne très bien (pas parfait, certaines tâches à 1 point ont pris beaucoup plus de temps et certaines tâches à 5 points prenaient des minutes, mais tout finit par s’égarer).


Yay, planifiez le poker!
Sean McMillan

7

Présentez une gamme basée sur ce que vous savez aujourd'hui. Utilisez le cône d’incertitude pour définir la plage autour de vos estimations initiales.

Chaque semaine, calculez combien il vous reste à faire, ré-estimez-le en fonction de vos connaissances. Une fois que vous avez obtenu un échantillon de la quantité de travail que vous effectuez chaque semaine, donnez un intervalle de confiance de 90% pour le reste, afin de donner une plage de dates (généralement) toujours plus étroite au fur et à mesure de l'avancement du projet et du volume de travail restant (espérons ) diminue.


7

Avec confiance. Je ne peux pas vous dire combien de fois j'ai raté une première rencontre avec un client en ne faisant pas preuve de professionnalisme lors de l'estimation. Même si les chiffres vous échappent, assurez-vous de toujours garder une estimation. Cela dit, veillez à ne pas vous estimer dans un trou. Différentes choses prennent différentes quantités de temps, d'efforts et de ressources à assembler. Voici un bon moyen de le faire:

Eux: Combien cela coûtera-t-il?

Moi: Cela dépend de ce que vous voulez que je fasse. Généralement, je commence ce genre de projet à environ X $.


6

Parfois, l'estimation représente un défi énorme pour vous et votre équipe, en particulier lorsque nous parlons d'estimation de projet logiciel.

Une fois que nous avions décidé de partager notre expérience et nos connaissances sur le processus d’estimation logicielle, nous avions défini quatre types d’estimations distincts :

  • chiffre approximatif
  • estimation de service
  • estimation des fonctionnalités
  • estimation composite

Bien sûr, ces types sont distincts. Ballpark est ce qu'on appelle souvent une "estimation". Il s’agit donc d’un nombre ou d’une fourchette approximatif qui donne une idée générale du coût et qui peut aider un prospect à décider s’il souhaite approfondir la discussion.

En règle générale, les clients ont besoin d'un chiffre approximatif au début du projet. Et notre conseil est le suivant: discuter du projet et fournir des chiffres approximatifs ne devraient être que des étapes bien à franchir pour recevoir une estimation composite (qui est flexible, on peut utiliser une estimation de type composite pour l’ensemble du processus de développement). vous souhaitez ajouter, supprimer ou remplacer des fonctionnalités, des services, etc.).

Tout le monde devrait garder à l'esprit les risques inhérents à l'estimation du développement logiciel: sous-estimation, surestimation, scénario d'échec total, etc.

Vous pouvez en lire plus sur notre blog!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

J'espère que cette information vous aidera!


5

Je finis toujours par donner des estimations que je réalise plus tard que je ne peux pas remplir. Cela s'est produit d'innombrables fois et je promets toujours que cela ne se reproduira plus.

On dirait qu'on vous demande un engagement, pas une estimation. Ce sont des choses différentes, mais si vous pouvez gérer vos engagements de manière fiable, votre crédibilité et votre carrière en bénéficieront vraiment.

Quelques conseils basés sur mes ~ 10 ans d'expérience:

  • Toujours fournir une plage (c.-à-limite inférieure et supérieure). Cela communiquera votre niveau d'incertitude
  • Si vous avez une très grande incertitude, demandez un report (par exemple, une journée d'analyse et ensuite une plage plus étroite)
  • Si la tâche est trop volumineuse, divisez-la et fournissez une plage pour chaque pièce.

4

Tout d’abord, si une tâche m’était assignée, je la diviserais en sous-tâches. J’estimerais le temps pour chaque sous-tâche et probablement avec des sous-tâches, je serais capable de trouver le domaine problématique et donc de pouvoir prédire combien de temps prendre dans une certaine mesure.

Cependant, toute la planification n’aiderait que dans une certaine mesure. Ce n'est que lorsque vous commencez à coder que vous pouvez trouver les problèmes exacts


1

Si vous réalisez de nombreux projets pour le même patron ou client, vous pouvez essayer d’évaluer en complexité au lieu de semaines ou de mois, éventuellement en tailles de t-shirt. Identifiez quelques projets antérieurs et attribuez-leur les tailles S, M, L, XL.

Et ensuite, demandez-vous: à quel projet cela ressemble-t-il? Et puis, au lieu de répondre avec "2 Mois", vous pouvez répondre avec "ça sonne comme un L pour moi" (ou quel que soit le calibrage de votre projet).

C'est assez facile à comprendre, et il est également clair qu'il y a beaucoup d'incertitude dans ces suppositions.

Ensuite, lorsque les exigences changent, vous pouvez dire "ce changement donne l'impression que cela ressemble davantage à un XL".


c'est assez intelligent (si vous êtes autorisé à l'utiliser): je préfère utiliser une approche similaire mais simplement généraliser avec des valeurs de temps, je vais donc répondre "cela prendra environ une semaine" ou "cela va être une question de jours "pour quelque chose de petit et éviter de répondre lorsque le projet va être plus grand qu'un mois et nécessite une estimation correcte
Edoardo

0

Un peu tard, mais lorsque j'étais dans l'armée, on nous avait demandé d'utiliser le PERT pour établir des estimations. Cela nécessite une certaine expérience dans votre domaine et dans la tâche à accomplir. Il était étonnamment précis lors de la détermination du temps d’achèvement estimé lors de l’entretien et de la réparation de dispositifs électroniques (radios complexes et équipements de communication par satellite), où un certain nombre de choses peuvent être erronées ou trouvées et doivent être réparées au cours de l’entretien courant. Les estimations étaient importantes car d’autres unités pourraient ne pas fonctionner jusqu’à ce qu’elles aient reçu leur équipement de communication. Celui que j'ai utilisé est cette calculatrice PERT en ligne gratuite


1
Ce lien Free Online PERT Calculator ne fonctionne plus.
Krokodilko

@krokodilko J'ai mis au point un nouvel outil PERT qui est davantage adapté aux estimations de logiciels: estimations.rokkincat.com .
argot le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.