Comment les programmeurs estiment-ils le temps de développement de leur projet ?

L'estimation du temps du projet est cruciale pour la réussite ou l'échec du projet. La gestion du temps de projet comprend les différents processus nécessaires pour terminer le projet à temps. Cependant, dans les projets réels, des retards se produisent souvent et les estimations sont très inexactes.

L'estimation du temps est intrinsèquement difficile. L'estimation de chaque programmeur sera légèrement différente du temps réel requis. Le temps estimé est court, ce qui indique que certaines choses ont été ignorées (compilation, tests, soumission de code). On estime que le temps dépassé indique que la tâche est trop vaste et difficile à comprendre.

Pour les programmeurs débutants, cette erreur d'estimation prête à confusion. Ils sous-estiment souvent certaines tâches et surestiment certaines tâches légèrement plus difficiles. Je pense que pour un programmeur expérimenté, une tâche devrait prendre entre une demi-heure et 24 heures. Les tâches qui dépassent 24 heures doivent être fractionnées. Lorsque les programmeurs y réfléchissent, ils peuvent penser que cela prendra 60 heures, mais en fait, même les programmeurs très expérimentés doivent diviser les tâches en modules contrôlables, puis analyser et prendre des décisions.

Un autre point important à comprendre est que l'expérience en programmation n'est pas la même que l'expérience en estimation du temps. Un programmeur qui n’a jamais fait d’estimation de durée ne sera pas doué pour estimer le temps. Sans comparer le temps réel requis avec le temps estimé, vous ne pourrez pas acquérir l'expérience d'une estimation correcte du temps à partir d'autres informations de retour.

Les techniques d'évaluation sont utilisées par chaque programmeur. Pour améliorer cette compétence, vous pouvez vous entraîner sur chaque tâche que vous entreprenez. Faites une estimation du temps que prendra le développement au début de la tâche et comparez-le avec le temps qu'il vous faudra réellement à la fin. De cette façon, vous améliorez non seulement votre compréhension des détails de la tâche, mais vous améliorez également vos compétences en estimation du temps.

Loi de Hofstadter : Cela prend toujours plus de temps que prévu, même si l'on prend en compte la loi de Hofstadter.

Les PM se plaignent souvent de la raison pour laquelle les développeurs de l'entreprise ne peuvent jamais estimer le temps de leur propre projet ? ! Cependant, les programmeurs astucieux y sont habitués depuis longtemps. J'ai même vu un projet qui devait être réalisé en 2 jours finir par prendre 4 mois, ce qui est assez exagéré même selon la règle empirique du « doubler le temps ». À un niveau élevé, le problème est le suivant : les ingénieurs, les chefs de projet ou d'autres personnes ont des approches et des manières différentes de penser l'estimation du temps.

La première réaction de la plupart des ingénieurs est le temps minimum qu'il faudrait pour écrire un prototype si tout se passe comme prévu. Ce que le PM ou tout autre personnel en aval veut savoir, c'est quand le projet sera prêt et combien de temps faudra-t-il pour qu'il soit publié ? Ce sont donc deux histoires totalement différentes.

Donc pour les ingénieurs, maîtriser l'estimation du temps est une compétence essentielle, ce qui signifie que vous êtes un développeur professionnel, stable et efficace.

Pourquoi une estimation du temps est-elle nécessaire ?

Dépendances externes

Rien de valable ne se produit dans le vide. Les projets ont généralement des dépendances externes, telles que la communication avec les équipes fonctionnelles (finances, relations publiques, support client) et la communication avec les clients. La coordination de ces dépendances externes incombe souvent au PM ou au PDG, ce qui signifie que les personnes les plus qualifiées pour faire des estimations de temps (les ingénieurs) ne sont pas celles qui ont le plus besoin de faire ces estimations. Cette asymétrie crée des tensions fondamentales.

Priorité

La mesure du temps est également essentielle pour déterminer les priorités. La rentabilité est un indicateur important dans le domaine de l'ingénierie. Même si la fonction sur laquelle vous travaillez est la plus puissante au monde, si le calcul du temps montre que sa mise en œuvre prendra beaucoup de temps, alors la priorité de cette fonction ne sera pas. être trop élevé.

Supposons que vous travaillez sur un projet qui rendra le site Web 50 % plus rapide une fois terminé, mais en même temps, vous auriez pu terminer 2 projets, et chaque projet pourrait rendre le site Web 40 % plus rapide. Si vous ne prenez pas le temps de faire des calculs préliminaires, vous ne saurez jamais où construire un site Web plus rapide !

Estimation du temps primaire

En supposant que nous soyons parvenus à un consensus sur le fait que l'estimation du temps est très importante, continuons à examiner comment estimer. Souvent, nous sous-estimons le temps que cela prendra parce que nous nous demandons « combien de temps faut-il pour écrire un prototype ? »

Cependant, les éléments livrés sont souvent plus volumineux que le prototype, et vous devez également prendre en compte le temps consacré aux tests, au débogage et à l'optimisation. Il y a aussi des réunions, des entretiens, des revues de code, et même des envois d'emails qui prennent du temps.

Une autre raison de sous-estimer le temps requis est les problèmes inattendus qui ne sont souvent pas pleinement pris en compte, tels que les mises à jour de l'IDE qui vous coûtent une journée supplémentaire pour configurer l'environnement, etc.

Sur cette base, il est préférable de ne pas trop croire à la soi-disant expérience et à l'intuition.

Étape 1 : Élaborer un plan technique

Avant de commencer tout projet important, vous devez disposer d'un plan technique ou d'un document de conception. Le but de ce document est de faire savoir aux autres ce que vous faites et d'obtenir des commentaires. Lorsque vous remarquerez les détails techniques, vous aurez une idée plus claire du temps spécifique passé. Par exemple, la mise à jour d'une certaine bibliothèque vers une nouvelle version peut prendre une journée supplémentaire. Vous devez même écrire vous-même une bibliothèque.

La granularité est importante ici. Si quelque chose ne vous semble pas clair, vous devriez soit en savoir plus, soit le décomposer en étapes plus détaillées. En même temps, si une étape est trop détaillée, elle peut être trop fragile et l'ensemble du plan sera inefficace, vous devez donc saisir ce degré.

Si vous voulez savoir ce que vous devez considérer dans votre document, vous pouvez lire cet article d'AliciaChen. L’essentiel est de communiquer clairement avec le PM et d’éliminer toute ambiguïté, pour ne pas avoir à recommencer à la fin.

Étape 2 : Ajoutez des estimations de temps pour chaque étape de

Combien de temps faut-il pour mettre en œuvre chaque étape du document ? Cela implique souvent d'étudier les détails (existe-t-il déjà une bibliothèque pour cela ?). Ainsi, selon la nature du projet, réaliser d’abord un prototype simple peut aider à révéler de nombreux problèmes potentiels.

Étape 3 : Temps de tolérance aux pannes supplémentaire

Vous disposez désormais d'une estimation préliminaire du temps , mais il y a de nombreux autres facteurs à prendre en compte.

Débogage en déplacement : les bugs sont inévitables et dépendent de l'expérience du développeur avec une base de code particulière et de la maturité de la base de code. Réunions et jours fériés : de manière générale, vous ne codez pas pendant les réunions ou les jours fériés, alors combien de temps faut-il pour réellement coder ? Par conséquent, examinez attentivement le calendrier lorsque vous estimez le temps. Tests finaux : vous devez généralement tester pendant que vous codez, mais de nombreuses équipes doivent également effectuer des tests d'intégration avant la publication, alors prévoyez cette partie du temps dans votre estimation. Révision du code : combien de tours effectuez-vous généralement dans cette base de code ? Combien de temps dure chaque tour ? Combien de réviseurs doit-il passer par ? Faites attention au calendrier du réviseur pour garantir du temps pour les révisions de code.

Lorsque vous tenez compte du coût du délai de livraison, vous pouvez constater que votre estimation de temps correspond bien mieux au délai de sortie réel du projet. Même si cela peut en réalité être plus long, vous pourriez être contraint de raccourcir l'horaire. Mais lorsque les gens comprendront que vos estimations sont plus précises, ils vous feront davantage confiance.

Étape 4 : Estimation du temps de révision après la sortie

La révision est assez pénible Oui, mais revoir permet de faire mieux la prochaine fois. Que s'est-il passé sur chaque projet où le réel ne correspondait pas au temps prévu, trouvez la raison et améliorez-la.

En un mot, tout est question de communication. Communiquez à l’avance et fréquemment pour comprendre les horaires de chacun et l’évolution des besoins.

Communiquer avec les participants concernés tels que le PM peut également leur permettre de fournir des informations importantes pouvant affecter votre estimation. Un concepteur pourrait dire que l’animation prendra une semaine et devrait être coupée. Un autre PM peut également ajouter que ce prototype est uniquement destiné à la recherche des utilisateurs et que cette itération n'a pas à gérer trop de bugs.

Pour les ingénieurs, ne faites pas de compromis irréalistes sur des périodes de construction plus courtes. Être ouvert et honnête est plus professionnel. Cela peut être un processus pour le PM et d'autres de respecter le devis, mais sachez que vous ne raccourcirez pas le calendrier en harcelant.

L'estimation du temps d'un projet n'est pas facile, elle nécessite seulement une bonne communication, de l'empathie et une priorisation des fonctionnalités.