Comment estimer une tâche de programmation si vous n’avez aucune expérience en la matière [fermé]

J'ai de la difficulté avec la direction à demander des estimations sur des tâches de programmation utilisant des contrôles tiers avec lesquels je n'ai aucune expérience préalable.

Je comprends vraiment pourquoi ils voudraient les estimations, mais j'ai le sentiment que toute estimation que je donne sera soit a) trop courte et me donne une mauvaise image, soit b) trop longue et me donne une mauvaise image.

Quelle estimation ou réponse pourrais-je donner à la direction pour les retirer de mon dos afin que je puisse continuer à faire mon travail!

La meilleure réponse que vous puissiez donner est de demander du temps pour créer un prototype rapide pour vous permettre de donner une estimation plus précise. Sans une certaine expérience avec un outil ou un problème, toute estimation que vous donnez n'a essentiellement aucun sens.

En passant, il y a très rarement un problème à donner une estimation trop longue. Des problèmes imprévus surviennent, les priorités changent et les exigences sont «mises à jour». Même si vous n'utilisez pas tout le temps que vous avez demandé, vous aurez plus de temps de test ou pourrez publier "tôt".

J'ai toujours été beaucoup trop optimiste dans mes estimations, et cela peut mettre beaucoup de stress dans votre vie, surtout lorsque vous êtes un jeune programmeur sans l'expérience et la confiance en soi pour dire des vérités inconfortables aux patrons.

Je vais vous révéler un secret. Même si vous étiez un expert de cette technologie, votre estimation sera probablement très inexacte. C'est la nature de la bête lorsqu'elle fait quelque chose qui est une tâche intrinsèquement de R&D. Malheureusement, la direction essaie souvent d'appliquer un modèle de fabrication et exige des estimations précises. Pour illustrer mon propos, considérons la difficulté d'estimer avec précision les deux efforts suivants:

A) Fabriquez un autre parapluie 11K qui est exactement le même que le 2K que vous avez produit le mois dernier. B) Concevez un nouveau type de parapluie et construisez le premier.

Le développement logiciel est B, mais ils demandent une estimation en supposant A.

Le mieux que vous puissiez faire est de diviser la tâche en les plus petits morceaux possibles (pas plus d'une demi-journée chacun), puis de tripler le nombre final que vous avez trouvé. (Méthode Spolsky)

Alternativement, Steve McConnell a tout un livre (sans doute plusieurs) sur cet aspect du génie logiciel. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

Steve McConnell (et d'autres) parle du cône d'incertitude . En gros, vous fournissez une estimation qui ressemble à ceci:

Le travail prendra entre 3 et 9 semaines, 4 semaines étant la plus probable.

Au fur et à mesure de l'avancement du projet, vous pouvez affiner votre devis. Au fur et à mesure que vous faites plus de travail et que vous comprenez mieux l'effort requis, vous pouvez affiner votre estimation pour qu'elle soit plus précise.

Cela a fonctionné pour moi, mais cela peut nécessiter des efforts pour que les autres parties prenantes du projet comprennent le processus.

Vous voudrez peut-être envisager de donner à la fois une estimation et un niveau de confiance, c'est-à-dire que c'est 50/50 que cela prendra 3-6 mois ou 6-9 mois ou 75% de chances d'être fait en 9 mois et 90% que vous serez fait en un an.

Une autre chose que vous voudrez peut-être envisager est d'utiliser l' approche « sagesse des foules ». Faites le tour et demandez à 25 à 50 personnes combien de temps ils pensent que cela prendra et faites la moyenne de leurs estimations. Le Planning Poker de Mike Cohn est, je pense, très similaire à cela, bien que difficile à planifier avec un seul développeur.

Décomposez votre estimation en:

• Connus connus ; combien de temps faudra-t-il pour faire ce que vous savez faire. Vous devriez être en mesure de donner cette estimation avec un degré élevé de confiance.
• Inconnues connues ; combien de temps pensez-vous qu'il faudra pour faire ce que vous ne savez pas faire. Vous pouvez utiliser une méthode comme celle du dacracot pour donner différents niveaux de confiance sur cette estimation.
• Inconnus inconnus ; c'est le trou noir en temps réel. Ce sont les choses qui se dressent aux moments les plus inopportuns et vous mordent le cul. Fournissez une fourchette pour l'estimation avec une justification basée sur les risques que vous anticipez.

Offrez d'ajuster l'estimation et certains jalons en cours de route. Toute inconnue inconnue deviendra une inconnue connue, les inconnues connues devraient devenir connues au fur et à mesure que vous gagnerez en expérience, et l'estimation de vos connaissances connues peut être ajustée en fonction des progrès réalisés à ce jour. Vous pouvez faire une première estimation, puis réévaluer lorsque vous avez terminé à environ 25%, puis à nouveau à 50%, puis à nouveau à 85%. À chaque étape, votre estimation devrait commencer à converger vers le temps réel que prendront les tâches.

J'utilise un système d'étiquetage défini pour mes estimations ... classe A, classe B et classe C.

L'estimation de classe C est la première qu'ils obtiennent. Il est ouvertement indiqué comme plus ou moins 50% en raison d'inconnues. S'ils veulent que je continue à leur donner une classe B, alors j'ai besoin d'argent pour faire des recherches.

La classe B est de plus ou moins 25%. Parfois, cela suffit et ils me donnent de l'argent pour construire. Sinon, moins d'argent et plus de recherche.

La classe A est de plus ou moins 10%, la finale et aller ou pas aller. Si c'est un aller et que je m'éloigne trop de l'estimation je l'avoue souvent et tôt.

Je pense que si vous supprimez l'expression "qui utilisent des contrôles tiers avec lesquels je n'ai aucune expérience préalable", vous aurez peut-être une meilleure description de votre problème plus général.

Si «Agile» nous a appris quelque chose, c'est que, si la direction s'attend à ce que vous estimiez les projets de cette façon, et vous «aurez mauvaise mine» si vous dites qu'il ne peut pas être fourni parce que vous n'avez pas assez d'informations, vous êtes sur l'autoroute pour FAIL.

Le plus gros problème sera les problèmes sur lesquels vous n'avez aucun contrôle et que vous n'avez même pas encore identifiés. Combien de fois avez-vous regardé en arrière et vous êtes-vous dit: "Eh bien, j'ai frappé mon estimation juste sur le bouton - au troisième essai, après avoir compris que ... et que j'avais besoin d'une version ... et que la base de données serait activée des vacances pendant une semaine et que le chef de projet aurait besoin de moi pendant ... pendant une semaine et que ma femme était enceinte et ... ».

J'essaierais vraiment de dire: «Je peux identifier les facteurs de risque critiques et proposer une liste de contrôle des produits livrables pour les tester dans xx jours. À ce stade, je vous donnerai une autre estimation incrémentielle.»

Et ce serait vraiment bien si vous pouviez suggérer qu'ils devraient "Veuillez insister pour que je n'essaie jamais de vous donner une estimation crédible de ce type à l'avenir. Renvoyez-moi si j'essaye."

(Surestimé, mais seulement légèrement.)

N'essayez même pas d'estimer. Votre estimation ne sera en aucun cas correcte. Ce n'est après tout qu'une estimation.

Je vous recommanderais plutôt de diviser la fonctionnalité en petits morceaux (pas plus de, disons 1 à 2 jours) et d'essayer de fournir ces pièces sous forme de code fonctionnel, complet, testable et précieux au client / gestionnaire. De cette façon, il verra par lui-même vos progrès au jour le jour. Cela signifie également qu'il peut en fait décider d'arrêter le développement une fois satisfait et le considérer comme terminé, même s'il n'a peut-être pas atteint tous les objectifs.

Jetez un œil aux pratiques agiles «Planification des versions» et «Planification des itérations» pour obtenir des informations plus détaillées sur cette approche.

Gardez à l'esprit que si vous demandez une estimation de temps plus longue mais que vous la faites dans le temps, cela semble bien mieux que de sous-estimer et d'avoir à demander une prolongation.

J'essaierais de me moquer d'un prototype pour que vous ayez une meilleure idée du temps que cela prendra. Soyez honnête avec votre direction afin qu'elle puisse prévoir des retards imprévus dans la courbe d'apprentissage.

EDIT: Vous pourriez également voir si vous pouvez obtenir une date limite plus "itérative". Dans "Pensée et apprentissage pragmatiques", Andy Hunt fait valoir que les gens sont des experts en projets plus proches de la fin du projet et les moins bien informés au tout début. Cela n'a pas beaucoup de sens de faire toute votre conception et votre estimation du temps au tout début lorsque tout le monde est le moins bien informé sur le projet. Si vous «itérez» les délais et résolvez le problème par morceaux, vous aurez plus de succès.

Une bonne part d'estimation précise est la connaissance de soi. Si vous avez écrit beaucoup de code, si vous avez dû apprendre beaucoup d'API, vous commencez à avoir une idée des questions telles que:

• Combien de temps me faut-il pour apprendre une nouvelle API?
• Combien de temps me faut-il pour apprendre une nouvelle langue?
• Combien de temps me faut-il pour apprendre un nouvel ensemble d'outils (compilateur / éditeur de liens / IDE)?
• Combien de temps me faut-il pour mettre en œuvre une tâche typique?
• Combien de temps me faut-il pour tester mon travail?
• Combien de temps me faut-il pour déployer mon travail?

Tout au long de cela, vous devriez avoir une idée de choses telles que:

• Combien de bogues typiques vous créez et comment ils sont classés (c'est-à-dire faciles, difficiles, impossibles)
• Combien de complications sont introduites (c.-à-d. Besoin de refactoriser en raison du manque d'API tierce ou d'API boguée; besoin de reconcevoir en raison d'une mauvaise compréhension des capacités; outils / processus de construction non standard)
• Combien de temps est perdu en raison d'interruptions / de problèmes extérieurs

Sur la base de toutes ces choses, vous serez en mesure de développer une idée du temps que prendra quelque chose et d'être en mesure de formuler vos hypothèses ("En supposant que l'API est saine ...") même face à des informations terriblement incomplètes.

Estimez combien de temps vous avez besoin pour en apprendre suffisamment pour faire une meilleure estimation, par exemple, "Je ne sais pas: je n'ai jamais travaillé avec cela auparavant. Il me faudra probablement insérer votre estimation ici afin de déterminer ce que vous devez en savoir plus sur ce que je devrais savoir avant que je puisse vous donner une bonne estimation pour l'utiliser pour terminer votre projet .

Lors de la programmation, j'ai toujours pris ce que je pensais vraiment qu'il me faudrait et le multiplier par 3 pour fournir une estimation. Si je pense que je peux faire un travail en 1 semaine, je dis au client qu'il en faudra 3 - si je pense que cela me prendra vraiment 3 semaines, je dis au client 9 semaines.

En faisant cela, je me suis mis à «sous promesse, sur-livrer» - si vous réussissez à le faire, votre vie sera bien meilleure et vos clients seront extrêmement heureux.

Dans votre cas, vous voudrez certainement avoir au moins un peu de compréhension de ce dans quoi vous plongez avant de fournir une estimation. Peut-être aurez-vous même besoin de fournir une estimation du temps qu'il faudra pour fournir une estimation. Multiplier par 3 garde les clients heureux.

Décomposez-le en choses avec lesquelles vous avez une certaine expérience. Le fait de le découper vous donnera une meilleure idée de ce que vous savez et de ce que vous ne savez pas.

Une fois que les pièces sont suffisamment petites pour pouvoir être considérées comme des tâches définies uniques, certaines d'entre elles ne seront pas du tout estimables. Pour ceux-ci, faites d'abord un prototype ou laissez-vous simplement un temps raisonnable, en fonction de la taille de la pièce. Si vous constatez que vous avez des pièces inestimables de plus de 2 à 4 semaines de travail, recommencez à les découper en premier.

Finalement, vous arriverez à des solutions technologiques très étranges (qui, selon vous, devraient fonctionner, mais que vous ne savez pas avec certitude), et à beaucoup de travail à faire pour sauvegarder ces choses, une fois que cela fonctionne. Il y aura quelques éléments de conception manquants, pour lesquels il est préférable de choisir une bibliothèque bien connue ou un algorithme très simple pour la version initiale.

Si vous ne pouvez pas décomposer les tâches, vous devriez engager quelqu'un avec suffisamment d'expérience qui le peut (car votre manque d'expérience vous hantera également d'autres manières). Si vous ne pouvez pas embaucher quelqu'un, vous devriez simplement négocier pendant une longue période au hasard (6 mois à 2 ans) et vous diriger directement vers un prototype en désordre (jusqu'à ce que vous ayez réussi à vous donner suffisamment d'expérience pour savoir ce qui est juste et ce qui est bien. faux). Mais, si vous finissez par vous y prendre, il est important de ne pas vous leurrer et de penser que vous le faites de la bonne «façon». Les prototypes étaient destinés à être jetés. Espérons qu'une fois le compte à rebours du prototype terminé, vous êtes prêt à le construire pour de vrai.

Paul.

Vous n'avez qu'à deviner un nombre extérieur et à évaluer immédiatement, faites-leur savoir que des informations futures peuvent affecter vos estimations, mais que vous les tiendrez à jour.

Pendant que vous évaluez, tenez-les informés - soit par le biais d'un document publié sur le Web ou par des mises à jour hebdomadaires, mais incluez toujours une "date de fin estimée" mise à jour et les raisons (le cas échéant) des extensions.

La plupart des gestionnaires devraient comprendre que - en demandant des dates de fin, ils disent vraiment «donnez-nous une idée de la façon dont nous pouvons planifier notre emploi du temps» et «ne prenez pas une éternité».

Si vous finissez par étendre plus d'une ou deux fois, réévaluez l'ensemble de votre emploi du temps en fonction de vos nouvelles connaissances que vous craignez d'estimer.

J'ajouterais à ce que RB a dit, lorsque je me trouve dans cette situation, j'évalue combien de temps cela prendrait avec des outils que je connais, puis je double cette estimation pour intégrer une courbe d'apprentissage.

La partie importante est de communiquer à la direction que l'estimation est une estimation , s'ils font pression pour une estimation plus précise ou s'ils essaient de - cher Dieu - de vous vendre une limite de temps (il ne vous faudra sûrement que 2 jours pour construire le vaisseau spatial. Entreprise, vous êtes bon vous êtes) COLLEZ À VOS ARMES , ne compromettez pas votre estimation, ou le fait qu'elle n'est pas fiable.

Si la direction vous écrase et limite la tâche par exemple «Eh bien, cela doit être fait en 2 jours», faites-leur à nouveau savoir que c'est leur estimation, qui est exactement aussi fiable que la vôtre.

Mettez tout cela par écrit.

Je fais pas mal de l'estimation dans mon travail et c'est un vrai défi. L'un de mes plus grands défis est d'estimer le temps qu'il faudra à un développeur différent pour accomplir une tâche sans savoir à quel point ce développeur sera qualifié.

Alors que vous pourriez voir un certain succès initial avec la méthode «sous promesse, livraison excessive», vous constaterez qu'avec le temps, vous serez surenchéri par d'autres personnes qui suivent l'école de pensée «plus de promesse, moins de livraison». Le manque de précision reviendra vous mordre de toute façon. La précision est étroitement liée à l'expérience et limite le nombre d'inconnues de la technologie.

Une chose que je suggérerais, c'est de se faire une idée du type de budget contre lequel votre estimation fonctionnera. Si vous avez un petit budget, ne devenez pas fou avec une technologie inconnue et restez fidèle à ce que vous savez. Si votre budget est un peu plus flexible, vous pouvez vous permettre d'expérimenter un peu.

Reconnaissez également qu'il y aura des tâches où tout ce que vous pouvez fournir est un Wild Ass Guess (WAG). Pour ceux-ci, vous devez définir un temps minimum pour votre estimation et indiquer clairement que vous ne savez pas quel est le maximum. Souvent, ce type d'estimation est une raison suffisante pour que certaines fonctionnalités / demandes soient supprimées par la direction.

C'est une compétence indispensable que le chef de projet et le programmeur peuvent avoir (et bien sûr maîtriser!), J'ai trouvé un article, Estimer les tâches de développement logiciel rendues (un peu) plus faciles , que j'espère aider pour une meilleure estimation des tâches du projet.

Toutes les réponses ci-dessus ont couvert à peu près tout ce qui concerne l'établissement de l'estimation elle-même.

Une chose que je voudrais souligner est de garder une trace de votre estimation (une petite feuille de calcul Excel à la Joel, ou même un document Bloc-notes si c'est très simple), et à la fin de chaque jour, mettez-la à jour avec les chiffres les plus précis que vous pouvez maintenant fournir . Même si vous n'avez pas besoin de renvoyer cela à vos patrons, le garder à jour vous donne une meilleure idée de la façon dont les choses progressent et, plus important encore, vous aurez une bonne idée des raisons pour lesquelles votre estimation change au fur et à mesure que le travail progresse. .

Cela vous permettra de mieux estimer à l'avenir, à la fois pour cette technologie spécifique et pour d'autres que vous n'avez pas utilisées auparavant, simplement parce que cela vous oblige à un certain niveau à remarquer lorsque vos attentes changent à intervalles réguliers et à déterminer pourquoi cela s'est produit. .

Estimer la durée de quelque chose fait partie de votre travail. Tant qu'il s'agit d'une estimation plutôt que d'une date limite, vous ne devriez pas vous inquiéter. Il n'y a personne de mieux placé pour fournir une estimation que la personne qui va écrire le code. Si vous ne pouvez pas fournir une bonne estimation, vous devez informer la direction du risque lié à votre mauvaise estimation afin qu'elle puisse reconsidérer s'il vaut la peine de prendre le risque de programmer contre ces contrôles tiers inconnus.

C'est une situation très courante: la nécessité de faire face à l'inconnu. Une manière utile d'aborder ce problème est de réaliser qu'en plus des tâches de programmation proprement dites, vous avez un certain apprentissage à faire - et la direction doit en être consciente.

Lorsque vous êtes dans une situation comme celle-ci, le projet devient soudainement un projet de R&D et une durée plus longue que la normale ne vous fera pas mal paraître, puisque vous apprenez et produisez des programmes. Je ne sais pas à quelle vitesse vous apprenez ou de quelles ressources vous disposez pour résoudre les problèmes que vous pourriez rencontrer (Stack Overflow est l'une des options dont vous disposez).

Je dirais que vous devriez estimer comme d'habitude, puis multiplier soit par 1,5 (si vous êtes un apprenant rapide et avez accès à des ressources pour résoudre vos questions), soit par 2,5 si vous êtes un apprenant moyen et ne comptez que sur vous-même.

J'espère que ça aide!

Faites de votre mieux pour diviser la tâche en morceaux gérables. Avec un peu de chance, il existe des tâches spécifiques liées au composant tiers impliqué et d'autres qui sont moins couplées (et donc plus faciles à estimer). Donnez à la direction les estimations fractionnées et indiquez où vivent les estimations les plus incertaines.

Je suis entièrement d'accord avec celui qui a suggéré de jouer et d'en prototyper certains. Définissez une période fixe pour l'activité de prototypage. ("J'ai besoin de deux jours pour améliorer cette partie de mon estimation.")

Pouvez-vous donner une fourchette? 40-60 heures, quelque chose comme ça?

Plus les tâches sont petites, plus c'est difficile, si vous pouvez les regrouper, vous aurez un peu plus de "slop" car les erreurs peuvent s'équilibrer à la fin du projet.

Regardez n'importe quel domaine avec lequel vous avez de l'expérience et utilisez-le comme guide. "La dernière fois qu'il fallait créer une fonctionnalité qui a changé la base de données, il m'a fallu X". Bonne chance.