Estimation pour projets mobiles — définition, méthodes d'évaluation des tâches
L'estimation est une évaluation quantitative de l'effort nécessaire pour accomplir une tâche, développer une fonctionnalité ou livrer un projet dans son ensemble. Dans le développement mobile, les estimations sont utilisées pour la planification des sprints, la détermination des coûts et la gestion des attentes du client. Selon le Project Management Institute, 2024, l'erreur d'estimation dans les premières phases d'un projet peut atteindre 100 %, ce qui fait de l'estimation l'une des disciplines les plus complexes du développement.
Points clés
- Estimation — évaluation de l'effort d'une tâche, utilisée pour la planification et la tarification.
- Méthodes principales — Planning Poker, T-Shirt sizing, estimation analogique, modèles paramétriques.
- La précision dépend de la phase — en prévente, erreur jusqu'à 100 %, en sprint jusqu'à 20 %.
- Problème principal — sous-estimation systématique de la complexité due à l'optimisme et aux risques non pris en compte.
- Meilleure pratique — estimation collective de l'équipe par décomposition et données historiques.
Qu'est-ce qu'une estimation ?
L'estimation (de l'anglais estimate — évaluation) est une prédiction de la quantité de temps ou d'effort nécessaire pour accomplir une tâche. Dans le développement mobile, les estimations peuvent être exprimées en heures, en jours, en story points ou en termes monétaires. Le but d'une estimation n'est pas une prédiction exacte, mais la réduction de l'incertitude pour la prise de décision.
En quoi une estimation diffère d'un engagement
L'estimation est une prévision avec une marge d'erreur. L'engagement est une promesse d'achever une tâche à une date précise. La différence est cruciale : une estimation dit « probablement 5 jours », un engagement dit « nous le ferons en 5 jours ». Les gestionnaires confondent souvent ces concepts, transformant une estimation en délai sans droit à l'erreur.
L'estimation comme outil de communication
Le processus d'estimation n'est pas moins important que son résultat. Lorsque l'équipe discute de l'estimation d'une tâche, les exigences cachées, les dépendances et les risques apparaissent. Même si le chiffre final est inexact, la discussion permet à tous les participants de comprendre la tâche. C'est pourquoi les méthodes d'estimation collective (Planning Poker) sont plus efficaces que les méthodes individuelles.
Méthodes d'estimation en développement
Il existe plusieurs méthodes d'estimation, chacune adaptée à différentes phases du projet et niveaux de détail. Le choix de la méthode dépend des données disponibles et de la précision requise.
| Méthode | Type | Précision | Quand l'utiliser |
|---|---|---|---|
| Planning Poker | Expert, collectif | Élevée (en sprint) | Estimation des tâches de sprint |
| T-Shirt sizing | Expert, rapide | Moyenne | Estimation préliminaire des epics |
| Estimation analogique | Basée sur l'historique | Moyenne | Tâches similaires passées |
| Trois points (PERT) | Probabiliste | Supérieure à la moyenne | Tâches à forte incertitude |
| Paramétrique | Basée sur des formules | Dépend des données | Tâches répétitives mesurables |
Planning Poker
Le Planning Poker est la méthode d'estimation la plus populaire en Agile. Chaque développeur reçoit un jeu de cartes avec les nombres de Fibonacci (1, 2, 3, 5, 8, 13, 21). Après avoir discuté de la tâche, tout le monde montre sa carte simultanément. Si les estimations divergent, les développeurs avec l'estimation minimale et maximale expliquent leur logique, puis un nouveau vote a lieu. Cette méthode élimine le biais d'autorité et produit une estimation plus précise.
T-Shirt sizing
Le T-Shirt sizing est une estimation approximative par taille de t-shirt : XS, S, M, L, XL, XXL. Cette méthode est utilisée pour l'estimation rapide de grandes tâches (epics) dans les phases précoces lorsque les détails sont inconnus. Plus tard, chacune de ces tâches est décomposée et estimée en Planning Poker. Le T-Shirt sizing prend 5 à 10 minutes par tâche, mais ne fournit qu'un ordre de grandeur.
Estimation à trois points (PERT)
PERT utilise trois estimations : optimiste (O), pessimiste (P) et la plus probable (M). L'estimation finale est calculée par la formule : (O + 4M + P) / 6. Cette méthode tient compte de l'incertitude et donne un résultat plus réaliste qu'une estimation unique. PERT est particulièrement utile pour les tâches à haut risque ou avec de nouvelles technologies.
Précision de l'estimation : attentes vs réalité
La précision de l'estimation dépend de la phase du projet et de la quantité d'informations connues. Plus l'estimation est faite tôt, plus la marge d'erreur est grande — c'est normal et doit être pris en compte dans la planification.
Cône d'incertitude
Le Cône d'incertitude (Cone of Uncertainty) est un modèle qui décrit comment l'erreur d'estimation diminue au fur et à mesure que le projet avance. Dans la phase de concept, la marge d'erreur est de 400 % (une tâche peut prendre de 1 à 4 mois). Dans la phase de sprint, elle est de 20 % (1 à 1,2 mois). Comprendre ce modèle aide à ne pas exiger d'estimations précises dans les phases précoces.
Facteurs affectant la précision
- Complexité de la tâche — est-ce une technologie nouvelle ou familière ? L'inconnu multiplie la marge d'erreur par 2 à 3.
- Taille de la tâche — les petites tâches (jusqu'à 2 jours) sont estimées plus précisément que les grandes. La décomposition améliore la précision.
- Expérience de l'équipe — une équipe qui a travaillé ensemble pendant 6+ mois estime 30 à 50 % plus précisément qu'une nouvelle équipe.
- Données historiques — disposer de métriques de velocity et de cyclométrie améliore la précision des prévisions.
Estimation relative vs absolue
L'estimation relative (en story points) est plus précise que l'estimation absolue (en heures) car les personnes sont meilleures pour comparer des tâches que pour estimer le temps. « Cette tâche est deux fois plus complexe que celle-là » est un jugement plus fiable que « cette tâche prendra 8 heures ». Les estimations relatives ne dépendent pas d'un développeur spécifique et conservent leur précision lorsque le responsable change.
Comment améliorer la précision de l'estimation : meilleures pratiques
La précision de l'estimation peut être améliorée par une approche systématique, une discussion collective et l'analyse des erreurs passées. Il existe plusieurs pratiques éprouvées.
Décomposition en 1 à 2 jours
Toute tâche estimée à plus de 2 jours doit être décomposée en sous-tâches. Le principe : si une tâche ne peut pas être estimée avec plus de 50 % de précision, elle est trop grande. Divisez-la en étapes, chacune compréhensible et estimable. Après la décomposition, l'estimation totale est souvent 1,5 à 2 fois plus grande que l'estimation initiale.
Données historiques et métriques
Tenez un historique des estimations et comparez-le avec l'effort réel. Par exemple : « les tâches estimées à 3 story points prennent en moyenne 4 jours, pas 2 ». Utilisez la vélocité de l'équipe pour les prévisions : si l'équipe termine 20 story points par sprint, ne planifiez pas 30. L'analyse de la précision des estimations passées est le meilleur entraînement pour la compétence d'estimation.
Ancrage et calibrage
L'ancrage est un effet psychologique où la première estimation exprimée influence tous les participants. Pour éviter l'ancrage dans le Planning Poker, tout le monde montre ses cartes simultanément, pas à tour de rôle. Le calibrage est la comparaison régulière des estimations avec les résultats réels : après 10 à 20 sprints, l'équipe apprend à estimer plus précisément grâce au retour d'information.
Estimation ajustée au risque
Chaque tâche contient des risques cachés : maladie du développeur, problèmes d'API, changements d'exigences. Ajoutez un facteur d'ajustement au risque à votre estimation : pour les tâches à haut risque, un multiplicateur de 1,5 à 2 ; pour les risques faibles, 1,1 à 1,2. Montrez de manière transparente au client quels risques ont été pris en compte et comment ils affectent les délais.
Erreurs courantes d'estimation
Les erreurs d'estimation se répètent dans la plupart des équipes, quelle que soit leur maturité. Connaître ces erreurs est le premier pas vers leur correction.
Biais optimiste
L'erreur la plus courante est d'estimer selon le meilleur scénario : « si tout se passe parfaitement, nous le ferons en 3 jours ». En réalité, rien ne se passe parfaitement : bugs, questions sur les exigences, tâches dépendantes. Solution : estimez selon le scénario le plus probable, pas l'optimiste. Utilisez PERT pour tenir compte de la variabilité.
Estimation sous pression
Lorsqu'un gestionnaire dit « nous en avons besoin pour vendredi », le développeur ajuste inconsciemment l'estimation à cette échéance. L'estimation sous pression est toujours sous-évaluée et entraîne des dépassements de délais. Solution : l'estimation doit précéder l'échéance, pas l'inverse. D'abord l'équipe estime, puis les parties conviennent des délais.
Confusion entre complexité et temps
La complexité de la tâche (combien réfléchir) et le temps (combien faire) sont des métriques différentes. Une tâche peut être simple mais longue (créer 10 écrans) ou complexe mais rapide (trouver un bug dans du code legacy). Les story points estiment généralement la complexité, tandis que le temps est dérivé de la vélocité de l'équipe.
Ignorer les changements de contexte
Un développeur ne travaille pas 8 heures d'affilée sur une seule tâche : les réunions, les revues de code, l'aide aux collègues et les tâches administratives consomment 30 à 50 % du temps de travail. Les changements de contexte doivent être pris en compte dans l'estimation : en réalité, un développeur écrit du code 3 à 4 heures par jour.
Questions fréquentes
Pourquoi les estimations en informatique sont-elles si imprécises ?
Le développement est un processus créatif avec une forte incertitude. Contrairement à la construction ou à la fabrication, où chaque étape est connue, en informatique chaque tâche est unique. Les inconnues inconnues (unknown unknowns) sont la principale cause d'imprécision. Même une équipe expérimentée se trompe dans 30 à 50 % de ses estimations. C'est normal et doit être pris en compte dans la planification.
Faut-il estimer les tâches en heures ou en story points ?
Les story points sont meilleurs pour la planification des sprints car ils sont relatifs et ne dépendent pas de la personne qui exécute. Les heures sont nécessaires pour les contrats et les rapports externes, mais sont moins précises. La combinaison optimale : les tâches sont estimées en story points et les délais sont convertis via la vélocité de l'équipe en jours calendaires.
Comment estimer les tâches avec de nouvelles technologies ?
Pour les tâches avec des technologies inconnues, utilisez d'abord un Spike (recherche limitée dans le temps). Après la recherche, l'équipe comprend la complexité et peut fournir une estimation réaliste. Appliquez un multiplicateur de 2 à 3 à l'estimation habituelle et ajoutez une marge de 50 % pour les difficultés imprévues.
Comment réagir si un client trouve l'estimation trop élevée ?
Montrez la décomposition — divisez la tâche en sous-tâches avec des estimations individuelles. Expliquez en quoi consiste le temps : développement, tests, revue de code, documentation. Proposez des alternatives : réduire le périmètre, simplifier les fonctionnalités ou diviser en phases. Ne réduisez jamais une estimation sans modifier les exigences.
À quelle fréquence faut-il réestimer les tâches ?
La réestimation est nécessaire lorsque de nouvelles informations apparaissent sur une tâche : découverte d'exigences supplémentaires, contraintes techniques trouvées ou changements de priorités. Pendant un sprint, les tâches ne sont pas réestimées — l'accent est mis sur l'achèvement. Entre les sprints, le backlog est réestimé lors du grooming.
Résumé
- Estimation — prévision de l'effort, base de la planification et de la gestion des attentes.
- Méthodes principales — Planning Poker, T-Shirt sizing, PERT, estimation analogique.
- Précision par phase — cône d'incertitude de 400 % au début à 20 % en sprint.
- Meilleures pratiques — décomposition en 2 jours, données historiques, prise en compte des risques, calibrage.
- Erreurs courantes — optimisme, estimation sous pression, confusion entre complexité et temps, ignorance des changements de contexte.
- Règle clé — l'estimation est donnée par celui qui fera la tâche ; l'estimation collective est plus précise que l'estimation individuelle.
Nous développerons une application mobile clé en main
IT Sectr crée des applications iOS et Android pour les startups et les entreprises depuis 2017. Nous vous conseillerons et vous proposerons la meilleure solution.
Lisez aussi