Quelle est la marge d'erreur acceptable lors de l'estimation de la durée d'un projet?

L'entreprise dans laquelle je travaille vise à avoir une marge d'erreur maximale de 10%. Ils s'attendent à ce que les analystes ne manquent pas l'estimation de plus ou moins de 10%.

Je ne sais pas quoi en penser, car je n'ai rien à comparer.

Quelle pourrait être une bonne base de référence à mesurer si nous estimons trop faux, pour plus ou moins? Combien (en%) pensez - vous est bien à de manquer?

Sauf si vous estimez quelque chose de très similaire à ce que vous et vos collègues avez fait auparavant, +/- 10% est ridiculement optimiste. Votre direction n'a pas beaucoup d'expérience avec les logiciels ou ne connaît pas les grandes limites de l'estimation des logiciels . Ce document est accompagné de pièces justificatives , et de nombreux experts peuvent être trouvés.

Examinons un système beaucoup plus simple qu'un projet logiciel typique: Rubik's Cube. Vous pouvez résoudre n'importe quelle position en 20 coups , max. Mais puisque vous faites une estimation, vous ne pouvez regarder un cube donné que quelques minutes avant de donner la solution. Pouvez-vous donner une bonne estimation? Non, l'estimation d'un processus prend parfois plus de temps que le processus.

Un autre système simple: Pinocchio. Automate en bois, son museau grandit quand il profère un mensonge. Que se passe-t-il lorsque Pinocchio est au repos, puis dit "Mon nez se développe"? Certains systèmes ne se prêtent pas à la prédiction, ils sont indécidables.

Ces deux problèmes sont intégrés à la plupart des systèmes logiciels. Pour cette raison, vous n'obtiendrez jamais d'estimations proches de +/- 10%.

Mon conseil est de donner une estimation fortement matelassée, de travailler comme un esclave pour que le projet se fasse aussi rapidement que possible, puis d'avoir l'air occupé jusqu'à ce que vous soyez à moins de 10% ou moins. À ce stade, annoncez un succès spectaculaire.

Je serais très hésitant sur toute sorte de "marge d'erreur cible" car cela dépend vraiment du projet. Si vous essayez d'estimer le temps qu'il faudra pour installer, configurer et personnaliser un nouveau système CRM où personne ne sait exactement quels types de personnalisations vont être nécessaires et quels types de changements de processus métier seront nécessaires et la société n'a pas d'antécédents de grands projets similaires, votre marge d'erreur devrait être assez grande (c'est-à-dire que vous pourriez deviner que cela prendra 18 mois +/- 50% et citer 9-27 mois). Au fur et à mesure que le projet avance, les spécifications deviennent plus claires, les décisions sont prises concernant les processus métier, vos développeurs deviennent plus à l'aise, etc. ces marges d'erreur devraient se resserrer. Si vous essayez d'estimer la durée de construction du 101e site de commerce électronique de base lorsque vous " ve a une bonne histoire des 100 premiers, vous vous attendez à pouvoir donner une estimation beaucoup plus précise. La plupart des projets, cependant, vont se situer quelque part au milieu.

Maintenant, si vous citez un seul numéro plutôt qu'une plage, la réponse est probablement de commencer à citer la plage afin que la personne qui effectue l'estimation puisse spécifier la précision à laquelle elle s'attend.

Une bonne base de référence serait basée sur des données réelles que vous avez collectées.

La première étape consiste à enregistrer toutes les estimations . La deuxième étape consiste à enregistrer les résultats réels . Soyez honnête, ne soyez pas tenté de «s'ajuster automatiquement» au réel. Rassemblez suffisamment de ces informations et vous disposez de données pour établir la qualité statistique de vos estimations. Notez que cela peut / variera énormément selon qui a fait l'estimation et qui a effectué le travail. Ce n'est qu'en faisant cela que l'on peut raisonnablement s'attendre à donner une «marge d'erreur» qui est autre chose que des ordures.

Cela ne s'arrête pas là non plus; l'analyse des causes de la non-estimation des estimations peut aider à améliorer la précision de vos futures estimations. Remarque: Ils restent des estimations et, à ce titre, ne sont que des estimations .

L'estimation ne se termine pas non plus après la première estimation; c'est quelque chose qui peut être ajusté au fur et à mesure que le projet progresse à mesure que l'on acquiert plus de connaissances, ce qui réduit la marge d'erreur possible au fur et à mesure. Plus vous êtes ouvert à la communication, les premières surprises sont discutées - ce qui amène les gens à être moins surpris et à laisser plus de temps pour ajuster le projet ou les attentes des clients.

Deuxièmement, peut-être une meilleure façon de gérer la marge d'erreur est de « confiance interne » plutôt que de simplement% de marges d'erreur. Vous avez ensuite basé votre date de livraison estimée sur un intervalle de confiance plutôt que sur une date unique.

PERT est un exemple d'un cadre pour gérer l'estimation basée sur un raisonnement statistique. Par exemple:

"Sur la base de ce que je sais maintenant, nous avons un niveau de confiance de 90% que nous pouvons délivrer en 8 mois. 95% de confiance en 10 mois, 99% de confiance en 2 ans, etc."

Remarque ici: plus ils ont confiance en vous, plus l'estimation sera grande. En fonction de la complexité (c'est-à-dire de la précision avec laquelle vous pourriez être), cela pourrait être une petite différence entre 80% et 90%, ou cela pourrait être énorme!

Enfin - bonne chance;) Si vous résolvez un jour une «marge d'erreur maximale» dans l'estimation de logiciel, vous pouvez spécifier quelque chose comme «toutes nos estimations seront +/- 10%», assurez-vous de commander un film au box-office pour le reste de nous dans l'industrie du logiciel. Je pense à quelque chose comme un croisement entre Office Space et The Matrix: D

Cela dépend en fait beaucoup de la taille et de la complexité du projet.

Si votre estimation de projet est de 1 semaine - 10% est raisonnable. Cela signifie +/- 1/2 journée.
Si c'est 1 mois, 10% est fragile - d'après mon expérience, il est impossible de prévoir ce que vous découvrirez en 1 mois.

Plus d'un mois - tous les paris sont désactivés :).

Ce sont par développeur - donc pour une équipe de 4 développeurs 1 semaine == 1 mois.

Pour une équipe de 4 développeurs, la plupart du temps, il est bon de proposer une liste de fonctionnalités qui peuvent être effectuées en 1 mois, et être à moins de 10% pour ces fonctionnalités. Ensuite, réestimez pour le mois suivant.

J'ai fait quelques hypothèses naïves ici

1. Tous les développeurs peuvent travailler en parallèle.
2. N'ont pas été considérés comme testeurs - ils devraient avoir un peu de temps pour tester
3. Tous les développeurs sont égaux - Frontend, Backend, Designers etc ...

Vous devez en tenir compte ... mais c'est l'idée générale.

Il y a beaucoup de variables:

1. Quelle est la durée du projet?

2. Comment le projet sera-t-il géré? Cascade? Agile? SCRUM?

Je suppose de la question Waterfall. Si tel est le cas, vous êtes à peu près censé échouer d'un certain pourcentage compte tenu de la demande de marge.

Si la réponse est une méthodologie Agile, en particulier quelque chose comme SCRUM. Peu importe le pourcentage de marge. Une marge d'erreur de 50% sur un Sprint de 2 semaines est de 1 semaine, sur un Sprint de 1 semaine, elle est de 2,5 jours, les deux scénarios les plus extrêmes. En effet, la date de livraison est réestimée à chaque Sprint, et elle deviendra de plus en plus précise au fil du temps, au lieu de moins en moins.

Avec Waterfall, la marge d'erreur de 50% n'est pas inconnue non plus, mais sur un projet de 12 mois qui est de 6 mois, et il n'est pas vraiment découvert / admis, c'est si mauvais jusqu'à 10 mois dans le 12.

À l'époque où je dirigeais des équipes logicielles, à peu près autour de la frontière Crétacé / Tertiaire, nous étions en fait proches d'atteindre +/- 10% sur l'estimation. Il était d'environ +/- 15% si ma mémoire est très douteuse. Mais c'était parce que nous estimions des choses que nous avions déjà faites : un firmware de communication en temps réel relativement simple qui prenait des octets de A et les déplaçait vers B en utilisant un langage que nous connaissions, dans un environnement en temps réel conçu par nous , parler à du matériel conçu en interne par des gars à quelques bureaux de là. Beaucoup de légères variantes sur le thème ci-dessus, pendant des années .

S'attendre à atteindre ce type de taux d'erreur dans l'estimation normale d'un projet logiciel est, franchement, ridicule . Quand vous le voyez apparemment atteint, c'est parce que les gens surestimaient et rembourraient (faisaient des trucs supplémentaires et des projets pour animaux de compagnie pour utiliser le budget), ou sous-estimés et travaillaient comme des chiens le soir et le week-end pour rattraper le temps.

Vous avez probablement entendu la chose à 300%, n'est-ce pas?

Je l'utilise en fait. Entièrement basé sur ce que j'ai vu depuis des années. Quand j'entends un jour ou deux, c'est une semaine ou plus à faire vraiment . Et testé. Dans tous les environnements. Documentation mise à jour. Utilisabilité testée. Testé pour les performances. Testé en charge. Quelques heures, c'est vraiment plus une journée.

Je pense que nous sommes vraiment mauvais à estimer à cause de:

• Aider les autres
• Être interrompu
• Former de nouvelles personnes
• D'autres choses à venir
• Tomber malade ou malade
• Couvrir les personnes qui partent
• Besoin de vacances ou de congés
• Être distrait par les autres
• Être retenu par d'autres groupes
• Être trop optimiste sur réaliste
• Ne pas allouer de temps pour travailler sur des échecs de test intermittents
• Exclure facilement le temps de test, en particulier la rédaction de tests automatisés

Donc, au plus haut niveau, avec des gens d'affaires qui ont besoin de meilleures estimations que 300%, ce que nous finissons par faire, c'est de viser des estimations raisonnablement bonnes, mais au prix d'être de niveau plus élevé et plus général. "Nous aurons une fonction d'édition d'utilisateur" même si la version 1 ne signifie que pour 1 groupe d'utilisateurs pour changer 1 champ.

En ce qui concerne "Quelle est la marge d'erreur acceptable lors de l'estimation de la durée d'un projet?"Je trouve que cette approche, utilisée dans de nombreux environnements agiles, aide à changer la question en ce qui concerne les fonctionnalités minimales pour obtenir une version alpha ou bêta en direct, puis l'itérer.