Comment estimer le temps que vous consacrez aux tâches consistant principalement à résoudre un problème?

Bien qu'il soit relativement possible pour un développeur expérimenté d'estimer le temps nécessaire à la mise en oeuvre du code lorsque le modèle et le problème résolus par le code sont bien compris, comment pouvez-vous faire une bonne estimation lorsque, bien que l'objectif final soit bien compris, la mise en œuvre est théorique à 95% / résolution de problèmes et a très peu de mise en œuvre?

Mon travail consiste souvent à accomplir des objectifs bien définis. Cependant, je dois trouver le moyen d'atteindre cet objectif et tant que je n'aurai pas compris la solution, les obstacles supplémentaires éventuels ne sont pas clairement définis. Plus spécifiquement, je travaille souvent sur la génération de code ou sur des outils de manipulation de code automatisés. Une fois la solution entièrement résolue et l'outil perfectionné, il effectuera directement 95% des modifications réelles très rapidement. Cependant, je n'ai aucun moyen d'estimer le nombre de problèmes supplémentaires à résoudre pour que l'outil de génération ou d'analyse traite les cas extrêmes imprévisibles.

Pour des raisons de planification, mon entreprise souhaite avoir une meilleure idée du temps que cela prendra, mais comme je ne sais pas combien de problèmes supplémentaires pourraient survenir lors de la résolution de chaque étape de la solution. Je ne sais pas comment je peux aborder pour donner une meilleure estimation.

Avant d’aller trop loin, permettez-moi de dire que Estimation du logiciel: démystifier l’art noir est une excellente ressource pour ceux qui s’intéressent ou pensent à des estimations. Les deux images ci-dessous sont extraites de ce livre, de même que le cœur des idées présentées ci-après.

Comme vous l'avez noté, les estimations jouent un rôle important dans la capacité de prévoir et de planifier le travail avec précision. Ne pas avoir d'estimations rend aveugle le business sur le temps qu'il faudra pour quelque chose. Il n’est pas rare que les entreprises aient une idée complètement fausse du temps que cela prendra - ce qu’elles pensent être facile prend entre six et huit semaines et ce que l’on pense être difficile, c’est un bidouillage vendredi après-midi.

La première chose à faire est de donner une estimation. Une estimation en soi n’est pas un chiffre unique, c’est un engagement. "Combien de temps va prendre ABC" -> "Environ 5 jours" signifie que c'est environ 5 jours. Cependant, une bonne estimation est une fourchette dans laquelle vous êtes sûr à 90% de l'avoir dans cette fourchette. Si vous voulez dire "je suis à 90% sûr que cela prendra entre 1 et 5 jours", dites-le. Ne travaillez pas avec "Je pense que cela prendra entre 1 et 10 jours, donc 5 jours est probablement une moyenne" - ce n'est pas une estimation et vous vous tromperez 50% du temps.

Eh bien, 50% ou plus du temps, les programmeurs sont des sous-estimateurs notoires pour la durée des tâches.

Considérons le cône d'incertitude:

^{_{Image tirée de http://www.construx.com - article intégral disponible à l' adresse http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/}}

Sachez que la première estimation dans cette plage est 16x. Cela revient à dire "je pense que cela prendra entre un après-midi et deux semaines" - mais vous ne le savez pas encore. Au fur et à mesure que vous avancez légèrement dans la conception, la plage se réduit à 4x. Cela ne signifie pas que cela prendra une semaine, cela signifie que vous diriez plutôt "après avoir examiné cela un peu, cela prendra entre trois semaines" - oui, l'estimation a augmenté, mais aussi la fourchette de l'estimation est allée vers le bas.

Pour chaque estimation que vous donnez, vous devez être sûr à 90% que l'estimation se situe dans cette plage. Vous pouvez vous tromper - 10% du temps, il tombera en dehors de cette plage.

Il y a plusieurs façons d'estimer la taille des projets. En le comparant à des projets antérieurs, en utilisant un proxy (je pense que cela prendrait 1000 lignes de code qui prendraient autant de temps à écrire), en utilisant des points de fonction (convertir en LOC ...), en obtenant des estimations de plusieurs personnes, puis l'affiner de manière itérative ... certains travaillent pour certains projets, d'autres pour d'autres projets.

Un chapitre très important de ce livre que j'ai mentionné en haut est le numéro 23 qui traite des politiques d'estimation et des relations avec les gestionnaires et les dirigeants.

La clé d'une estimation est le processus itératif qui consiste à l'affiner après y avoir travaillé un peu.

Donner une estimation trop précise trop tôt dans le processus peut être très sujet aux erreurs. Si vous n’êtes pas sûr de cela, donnez une estimation large puis revenez avec une autre estimation après un certain temps pour approfondir le problème et éventuellement décrire comment vous allez le faire, en regardant la quantité de code que vous avez écrit pour. le dernier problème similaire et d'autres facteurs qui auront une incidence sur l'estimation.

Les estimations nécessitent un peu de réflexion - ne donnez pas les estimations du brassard. Celles-ci comportent souvent d' énormes erreurs par rapport à ce que cela prend quand on y pense un peu.

De Comment répondre quand on vous demande un devis?

Que dire lorsqu'on lui demande une estimation

Vous dites "je vais vous revenir."

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.

À partir du chapitre 4 de Software Estimation:

Notez que dans ce cas, les estimations après un peu de révision sont systématiquement moins sauvages et sujettes aux erreurs que les estimations spontanées. Ne faites pas d'estimations spontanées. Asseyez-vous et réfléchissez à la tâche à effectuer et faites l’estimation après quelques réflexions.

Boss : AJ, nous avons 3 chiens, 2 lapins, une catapulte et une nonne. Nous devons trouver un moyen de faire passer les 7 (oui, la catapulte aussi) par-dessus un mur de 20 pieds et de pénétrer dans le lac de l'autre côté sans que les chiens mangent des lapins et sans noyer la religieuse. Combien de temps faudra-t-il pour trouver la solution?

Voyez-vous, le problème pour estimer le temps qu'il faudra pour résoudre un problème est qu'il faut différentes personnes pour un temps différent. Si vous avez l'habitude de résoudre des problèmes similaires, vous pouvez effectuer une estimation en fonction du temps écoulé auparavant. Si vous ne le faites pas, vous ne faites pas d'estimation, vous ne faites que deviner.

En outre, le problème peut même ne pas avoir une solution acceptable. Ou peut-être que la solution nécessitera une autorisation supplémentaire qui pourrait gâcher tout le projet. Ou peut-être que la solution change toute la nature perçue du problème, de sorte que la solution devient totalement inutile.

La morale de l'histoire est la suivante: si vous ne possédez pas assez d'informations pour faire une estimation raisonnable, alors ne le faites pas . Pas encore. Obtenir plus d'informations. Recherche plus. Typiquement, il est parfaitement correct de dire: "Je vous répondrai dans 2 jours avec des chiffres plus solides."

Lors de la conception d'une solution pour un client, je ne signerai pas de contrat tant que la conception générale ne sera pas complète et que je saurai à quoi ressemblera la solution et combien de temps durera le projet. Cela signifie que je risque d'avoir fait un travail de conception initial pour lequel je ne suis pas payé (si le projet n'aboutit pas), mais c'est mieux que de risquer une sous-facturation significative du travail effectué. .

Je vous suggérerais d'essayer quelque chose à mi-chemin entre les réponses de tylerl et de MichaelT avec ce qui suit:

• diviser le travail à effectuer en 3 ou 4 phases. Les phases devraient être:
  1. Analyse du problème
  2. Prototypage de solution
  3. Solution du monde réel
  4. Évaluation de sortie (test)
• fournissez une estimation uniquement pour la phase 1 (analyse) en fonction de votre expérience, ou pour les phases 1 + 2 (analyse + prototype) à votre direction. Ensuite, fournissez-leur une estimation pour les phases 3 + 4 lorsque les phases 1 et 2 du problème sont terminées (ou au moins suffisamment avancé pour que vous puissiez avoir confiance en votre estimation).

La raison derrière cela est que vous savez, par expérience, qu'il vous faut X jours pour analyser une base de code donnée (probablement en fonction de sa taille) et disposer de plusieurs outils ou scripts de base en cours d'exécution (et peut-être en échec). Ensuite, le nombre d'erreurs devrait vous fournir des informations sur la difficulté réelle de la tâche à accomplir.

Ce n'est peut-être pas exactement ce que la direction souhaite, mais je pense qu'il est toujours préférable de faire des estimations que vous allez réellement rencontrer.

Comme cette question concerne principalement les types de travail de recherche, demander aux développeurs de logiciels une approche courageuse. Un indicateur commun est qu'un développeur de logiciels prend deux fois plus de temps que son estimation est probablement un bon développeur. Cela dit, les tâches de recherche (et de conception d'architecture) font vraiment partie de la programmation et sont souvent ignorées / réduites au minimum. Ils sont aussi souvent difficiles à estimer.

La première question que je me poserais, est-ce un problème qui peut être résolu? Ce n'est pas un problème d'intellect ou de puissance cérébrale, mais une réalité pratique. À moins que vous soyez dans le monde des coups Google lune, où l' échec est un résultat attendu, la dure réalité est que je vais devrait livrer ce , quel que soit ce tour être. Une règle approximative semble être que nous savons déjà ce que 90% de la solution doit être?

La deuxième question que je voudrais poser, quoi d’autre serait utile de savoir dans la réflexion sur la solution? C’est vraiment une façon de vérifier deux fois si nous en savons suffisamment pour proposer une solution acceptable. Cela peut générer une série de tâches d’établissement des faits qui aident à mieux définir la solution, chacune d’entre elles étant généralement assez facile à définir et à estimer.

La troisième question est: qui est le mieux adapté dans l'équipe pour ce genre de problème? Celui qui aura cette tâche assaillira le résultat avec son propre style. Donner ce genre de problème à un programmeur qui a 10 millions de questions au début d'une tâche, puis s'en va et livre quelque chose d'une première fois (bien que lentement) peut être un meilleur choix que de lui donner le programmeur qui lance rapidement la mise en œuvre , mais quand il y a un problème, c'est seulement découvert à la fin du processus.

Ensuite, la tâche réelle consisterait à réfléchir aux solutions, mises en œuvre et approches possibles, et à disposer d’une échelle de temps fixe dans laquelle elles doivent faire rapport.

Lorsqu'ils rendent compte, vous avez alors le choix entre un ensemble plus large de solutions possibles, de donner le feu vert à la mise en œuvre d'une solution ou de réfléchir, car la solution n'est toujours pas définie suffisamment clairement.

Avec des questions de recherche pour lesquelles il n’est pas clair qu’il existe une réponse, et encore moins une idée claire de ce qui doit être fait, je propose habituellement de passer un certain temps à cela.

"Je ne sais pas si c'est même possible, mais je pourrais passer deux jours à la recherche. Cela ne nous apportera probablement pas de solution, mais peut-être que je pourrai exclure certaines choses et que j'aurai probablement une idée. quelles pourraient être les prochaines étapes concrètes et le type d’investissement de temps qu’elles impliqueraient. Nous pourrons ensuite décider s’il est judicieux de faire un autre pas. "

Alors mettez l’incertitude dans le sens opposé - l’estimation est bien précise (je vais passer deux jours), il n’est tout simplement pas précis de savoir ce qui sera réalisé à ce moment-là.

Timeboxing, fondamentalement.