Essentiel pour les programmeurs : compétences en estimation du temps de projet

Présentation

Une PM m'a récemment parlé d'un dilemme auquel elle a été confrontée : "Les ingénieurs logiciels ne peuvent jamais estimer combien de temps prendront leurs projets. Que dois-je faire ? Deux autres PDG m'ont dit la même chose récemment. À un niveau élevé, le problème est que les ingénieurs, les chefs de projet, les managers, les relations publiques et tous les autres ont des perspectives différentes en matière d'estimation du temps. Ce à quoi la plupart des ingénieurs pensent instinctivement, c’est le temps minimum qu’il faudra pour écrire un prototype utilisable si tout se passe comme prévu. Mais ce que les gens en aval veulent savoir, c'est quand le projet sera prêt à être publié - et c'est une toute autre histoire.

Une PM m'a récemment fait part d'un dilemme auquel elle a été confrontée : « Les ingénieurs logiciels ne peuvent jamais estimer la durée de leurs projets. Que dois-je faire ? Deux autres PDG m'ont récemment dit la même chose.

"Pourquoi les programmeurs ne peuvent-ils pas estimer avec précision la durée d'un projet ?" 》(http://blog.jobbole.com/24924/), nous le comprenons tous profondément. Une fois, j'ai rencontré un projet qui devait prendre deux jours, mais qui a finalement pris quatre mois. Dans ce cas, même en utilisant l'estimation empirique du « temps double », il existe toujours une différence d'un ordre de grandeur. Cela affecte vraiment l’entreprise. J’ai vu des entreprises entières avoir du mal à organiser un événement de lancement, pour ensuite devoir le reporter de plusieurs mois.

À un niveau élevé, le problème est que les ingénieurs, les PM, les managers, les relations publiques et tout le monde ont des perspectives différentes lorsqu'il s'agit d'estimer le temps. Ce à quoi la plupart des ingénieurs pensent instinctivement, c’est le temps minimum qu’il faudra pour écrire un prototype utilisable si tout se passe comme prévu. Mais ce que les gens en aval veulent savoir, c'est quand le projet sera prêt à être publié - et c'est une toute autre histoire.

Pour les ingénieurs, comprendre le temps nécessaire à l'estimation d'un projet est le parcours d'une vie. Ignorer ce problème entraînera des problèmes pour vous et pour toutes les personnes avec lesquelles vous entrerez en contact directement ou indirectement. Estimer avec précision la durée d'un projet vous permettra de vous démarquer, et vos collègues associeront cela à votre professionnalisme, votre stabilité et la qualité de votre travail.

Pourquoi avons-nous besoin d'une estimation du temps

Tout d'abord, permettez-moi de répondre à une question souvent posée par les ingénieurs : "Pourquoi avons-nous besoin d'estimer le temps ?" De nombreux ingénieurs se plaignent (à juste titre) qu'il s'agit d'un coût indirect. « Si j’y vais à plein régime, je terminerai le projet plus rapidement !

Il y a deux raisons principales : les dépendances externes et les priorités.

Dépendances externes

Aucune campagne efficace ne fonctionne en vase clos. Les projets ont souvent des dépendances externes, telles que la collaboration avec des équipes non-ingénieures (communications, finances, relations publiques, service client), d'autres équipes d'ingénierie ou même les utilisateurs finaux eux-mêmes. La coordination de ces dépendances externes relève généralement de la responsabilité du manager, du PM ou du PDG. Cela signifie que les personnes les plus qualifiées pour effectuer des estimations de temps (les ingénieurs) ne sont pas celles qui ont le plus besoin d'informations sur le temps pour les estimations. Cette asymétrie conduit à une contradiction fondamentale.

Priorité

L'estimation du temps est également essentielle pour prioriser le travail. « Si l'argent en vaut la peine » est un indicateur important du projet sans une véritable estimation, il est impossible de déterminer si l'argent en vaut la peine. Même si la fonctionnalité sur laquelle vous travaillez est la meilleure au monde, si vous prenez le temps de faire une estimation approfondie, vous réaliserez peut-être que cela prendra beaucoup de temps.

Supposons que vous travailliez sur un projet qui rendra le site Web 50 % plus rapide, mais que dans le même laps de temps, deux projets peuvent être réalisés qui rendront chacun le site Web 40 % plus rapide. Si vous ne prenez pas le temps de faire une première estimation, vous ne saurez jamais que vous pouvez créer un site Web plus rapide !

Premiers pas avec l'estimation du temps

Maintenant que tout le monde s’accorde sur le fait qu’une estimation du temps est la plupart du temps nécessaire, parlons techniques.

Nous sous-estimons le temps car nous pensons « combien de temps me faudra-t-il pour écrire cette version de base ? »

Mais il offre quelque chose de plus que la simple version de base. Tenez également compte du temps nécessaire pour écrire, tester, déboguer et peaufiner. N'oubliez pas que des choses comme les réunions, les entretiens, la révision du code et l'envoi d'e-mails prennent également du temps.

Une autre raison de sous-estimer le temps est que nous rencontrons presque toujours des « inconnues » lors du codage qui sont impossibles à prévoir et à prendre en compte pleinement. Peut-être que l'IDE se met à jour, interrompt le projet et que vous passez la journée à le réparer. Ceci ne peut pas être pris en compte dans les estimations de temps.

Cependant, nous pouvons encore faire mieux que notre intuition initiale. Voici comment je procède :

Première étape : Élaborer un plan technique Avant de commencer les travaux, vous devez déjà disposer d'un plan technique ou d'un document de conception qui peut vous aider dans tout projet important. Vous pouvez l'utiliser pour faire savoir aux autres ce que vous faites et obtenir des commentaires. L’élaboration d’un plan technique est l’étape idéale pour lancer des estimations de délais. Lorsque vous aurez terminé les détails techniques de la conception, des problèmes inconnus seront découverts et vous réviserez comme par magie le temps estimé. Peut-être vous rendrez-vous compte que vous devrez peut-être mettre à niveau une bibliothèque que vous utilisez vers une nouvelle version, ce qui peut ajouter une journée à votre travail. Vous réaliserez peut-être même que la bibliothèque que vous envisagez d’utiliser n’existe pas réellement et que vous devez l’écrire vous-même.

La granularité est importante ici. Si une étape vous semble vague ou peu claire, vous l'avez peut-être sautée (vous devriez en savoir plus) ou devez-vous la diviser en étapes plus petites. Dans le même temps, si une étape est trop granulaire, elle peut être vulnérable dans la pratique et rendre l’ensemble du plan inefficace.

Pour connaître les aspects à prendre en compte dans la planification technologique, veuillez vous référer à cet article d'Alicia Chen « Que voulez-vous dire par « nous avons besoin de plus de temps » ? L'un des points clés est d'éliminer toute ambiguïté potentielle avec le Premier ministre ou d'autres parties prenantes afin que vous n'ayez pas à recommencer parce que vous avez fait quelque chose de mal.

Étape 2 : Ajoutez un budget temps pour chaque étape

Estimez le temps d'exécution de chaque étape de la solution technique. Cela implique généralement de creuser dans les détails (« Quelqu'un a-t-il déjà implémenté ce que fait cette bibliothèque ? »). Selon la nature du projet, la présentation d'un prototype simple peut aider à exposer de nombreux problèmes potentiels futurs.

Étape 3 : Ajoutez beaucoup de temps supplémentaire

Vous disposez désormais d'une estimation préliminaire, mais tous les points que nous avons évoqués précédemment doivent encore être pris en compte.

• Débogage en déplacement : il y a toujours des bugs. Le débogage dépend en grande partie de votre expérience avec une base de code spécifique et de la maturité de la base de code.
• Réunions, entretiens, vacances, etc. : Peut-être que vous ne coderez pas tout le temps sur votre poste de travail. Combien d’heures faut-il réellement pour coder ? Vous devriez au moins regarder votre calendrier lors de l’estimation.
• Tests finaux et nettoyage des bogues : vous devriez généralement écrire des tests pendant le codage, mais de nombreuses équipes doivent effectuer une série de travaux de peaufinage ou de tests d'intégration avant la publication. Prévoyez un budget adéquat pour ces tâches dans l’estimation. Si le déploiement est effectué par étapes, le 1 % initial du contenu peut exposer des bugs qui doivent être corrigés, ce qui doit donc être pris en considération.
• Révision du code : de combien de cycles de révision du code le projet a-t-il besoin ? Combien de temps cela prend-il habituellement ? Assurez-vous d'avoir suffisamment d'évaluateurs disponibles (et vérifiez également leurs horaires). S'il s'agit d'un projet avec un seul évaluateur, il convient de lui demander d'accepter à l'avance d'avoir une réserve au cas où l'évaluateur serait en vacances ou trop occupé à un moment critique.

Une fois que vous aurez commencé à ajouter tout ce temps supplémentaire à votre projet, vous commencerez à voir vos estimations de temps correspondre bien mieux qu'au début du projet. Oui, cela peut en fait prendre plus de temps que prévu et vous pourriez vous sentir obligé de raccourcir le délai. Mais les gens apprécieront vos estimations lorsqu’ils sauront qu’ils peuvent compter sur vous.

Étape 4 : Une fois le projet publié, examinez et résumez l'estimation du temps

Il semble douloureux de revenir sur le travail effectué une fois le projet terminé. Mais ce genre d’évaluation vous permettra d’en tirer beaucoup d’enseignements et de faire mieux la prochaine fois.

Quel processus s’est déroulé différemment que prévu ? Si un test d'intégration prend deux fois plus de temps que prévu, notez-le et prévoyez plus de temps pour le test la prochaine fois. Ou essayez d'améliorer le système de test intégré.

Vous verrez forcément vos estimations s'améliorer avec le temps. Vous pourriez même trouver des idées intéressantes en cours de route qui pourraient aider toute l’équipe.

En fin de compte, tout est question de communication

Vous devez informer les autres de votre emploi du temps et des autres changements à l'avance. Si vous informez vos responsables qu'une nouvelle vulnérabilité de sécurité existe dans une bibliothèque que vous utilisez un mois avant une version et que vous devez repartir de zéro, ils auront le temps d'informer les relations publiques, les finances ou les utilisateurs en conséquence que la version doit être modifiée. être reportée.

Les commentaires importants obtenus lors de la communication avec d'autres collaborateurs aideront à ajuster l'estimation du temps. Le concepteur pourrait dire : « Oh, si cette animation sophistiquée doit prendre toute la semaine, nous pourrions la supprimer entièrement. » Le PM pourrait ajouter : « Il s'agit simplement d'un prototype d'expérience de recherche sur les utilisateurs. Nous n'en avons pas besoin de trop. nettoyage des bugs pour cette itération. » Le responsable peut dire : « Vous avez passé la moitié de votre temps en réunion ? »

Pour les ingénieurs, ne faites pas de compromis sur des délais irréalistes juste pour plaire à vos supérieurs. Il est plus professionnel d'être franc sur votre temps estimé et vos changements.

Pour tous les autres, respecter le temps estimé est difficile et nécessite une démarche. Vous ne pouvez raccourcir le temps estimé qu'en vous asseyant et en supprimant des fonctionnalités ou des phases qui n'ont pas réellement besoin d'être publiées, et non en vous harcelant pour raccourcir le temps.

Nous ne pouvons jamais estimer parfaitement la durée d’un projet. La seule façon d’y parvenir est d’être ouvert, communicatif, empathique et d’établir des priorités de manière décisive.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!