Réaliser une estimation pour un projet de développement

Estimer ou ne pas estimer, telle est la question.

Dans le parcours professionnel d’un développeur, il est inévitable qu’on lui demande d’évaluer la durée requise pour mener à bien diverses tâches.

Cette question, semblable à l’énigme du nœud gordien, a le pouvoir de déclencher de véritables dilemmes métaphysiques. À tel point que certains développeurs préfèrent de nos jours tout bonnement éviter de se livrer à ces estimations !

Il ne s’agit pas ici de débattre de la validité de réaliser ou non de telles estimations. Si je devais donner mon opinion, je dirais qu’il est en effet illusoire de fournir une estimation précise. Cependant, dans un univers où tous les services sont monnayés et où chaque projet requiert une date de livraison, il est ardu de remporter la bataille pédagogique contre des clients habitués à la tarification fixe.

Nous, en qualité de développeurs, nous trouvons donc contraints de nous adapter et de trouver une approche capable de prendre en considération le degré de risque inhérent à la gestion temporelle d’un projet de développement.

À première vue, nous pourrions tabler sur 60 jours…

Estimer une simple tâche est déjà un exercice en soit mais qu’en est il lorsqu’un client arrive avec une nouvelle idée (tenant parfois sur une serviette en papier, rédigée rapidement pendant un repas de travail..) ?

Lorsque nous sommes confrontés à une idée de projet complexe, il est essentiel de la découper en scénarios plus petits et plus gérables afin de faciliter l’estimation du temps de réalisation. Ce processus de décomposition permet de mieux évaluer chaque aspect de la tâche et d’anticiper les éventuels défis qui pourraient surgir en cours de route. Voici comment j’aime procéder :

  1. Comprendre l’idée dans son ensemble : Avant de commencer à découper l’idée, je prend le temps de bien comprendre la vision globale du projet. Quels sont les objectifs principaux ? Quelles sont les fonctionnalités clés ? Cette compréhension approfondie m’aide à identifier les différentes étapes nécessaires pour réaliser le projet.

  2. Identifier les principales fonctionnalités : je divise l’idée en principales fonctionnalités ou composants. Chacun de ces composants peut être considéré comme un scénario potentiel. Par exemple, dans le développement d’une application e-commerce, les fonctionnalités pourraient inclure la création de comptes utilisateurs, la gestion du catalogue de produits, le processus de paiement, etc.

  3. Prioriser les scénarios : Une fois les fonctionnalités identifiées, j’évalue leur importance et leur complexité. Je les classe par ordre de priorité, en commençant par les éléments essentiels qui apportent le plus de valeur au projet. Cela permettra de se concentrer d’abord sur les parties cruciales et de laisser les aspects moins critiques pour plus tard. L’objectif est d’identifier ce qu’on appelle souvent le MVP (Minimum Viable Product).

  4. Décomposer les scénarios en tâches plus petites : Chaque scénario peut être à son tour décomposé en tâches plus petites et spécifiques. Par exemple, si l’une des fonctionnalités est la création de comptes utilisateurs, les tâches pourraient inclure la conception de l’interface utilisateur, la mise en place de la base de données, la gestion des authentifications, etc.

    La décomposition en tâches plus petites est un travail conséquent. En général je l’effectue en phases successives, ponctuées d’aller-retours avec le client afin d’affiner notre vision commune du projet et de son futur déroulement.

  5. Estimer le temps pour chaque tâche : Une fois que j’ai décomposé les scénarios en tâches, j’estime le temps nécessaire pour accomplir chaque tâche.

En découpant l’idée en scénarios et en estimant le temps pour chaque tâche, on obtient une vision plus précise du temps nécessaire pour réaliser le projet dans son ensemble. Cette approche permet de mieux gérer les risques, d’ajuster les priorités et de communiquer de manière plus transparente avec les parties prenantes concernant le déroulement du projet.

Verre à moitié vide ou moitié plein ?

Dans le domaine des estimations, une méthode largement utilisée est celle des “estimations à 3 points”. À ce jour elle reste ma préférée grâce à sa simplicité et à sa grande accessibilité.

Cette approche vise à prendre en compte l’incertitude inhérente aux estimations en fournissant une fourchette de temps plutôt qu’un simple chiffre.

Les trois points clés de cette méthode sont :

En utilisant cette méthode, l’estimateur peut calculer une estimation pondérée qui tient compte de la probabilité de chaque scénario. Cela offre une vision plus équilibrée et nuancée de la complexité de la tâche et aide à prendre en compte les risques.

Toutefois, en revanche, cette méthode ne dicte pas le niveau de confiance à adopter lors de la présentation du devis au client. Telle est une tâche qui vous revient : quel risque êtes-vous prêt à endosser, en harmonie avec les limites budgétaires de votre client ? Selon votre décision, la tarification à définir se situera en général quelque part entre l’estimation optimiste et le scénario pessimiste.

Au delà des plages de B4:L1…

La méthode d’estimation à 3 points à l’avantage d’être très facilement implémentable avec n’importe quel tableur (LibreOffice Calc pour ne citer que lui).

Cependant, lorsque nous visons à interagir avec nos clients et collègues au sein de l’équipe les feuilles de calcul ne sont plus exactement à l’état de l’art en terme de travail collaboratif, surtout quand le medium de transfert est le courriel…

Afin de simplifier cette dimension du processus, j’ai élaboré un prototype préliminaire d’application, baptisé Guesstimate, qui repose sur les principes fondamentaux de l’estimation à 3 points.

À ce stade du développement, Guesstimate permet:

Guesstimate - Exemple d'estimation

Une démonstration du prototype est disponible ici, si vous désirez le tester par vous-même.