La règle de quatre-vingt-dix-quatre-vingt-dix dans la pratique


24

Les 90 premiers pour cent du code représentent les 90 premiers pour cent du temps de développement. Les 10% restants du code représentent les 90% restants du temps de développement.

- Tom Cargill, Bell Labs

Qu'est-ce que cela signifie exactement dans la pratique? Que les programmeurs font beaucoup de travail et qu'ils donnent 180% d'eux-mêmes ou?


2
Nous savons tous que soit 100% est redéfini en le dépassant, soit 1,8 fois un montant connu. Dans ce cas, cependant, je dirais que c'est probablement une hyperbole. Le deuxième quatre-vingt-dix pour cent est là pour le rendre mémorable et ajouter une ligne de punch à la fin de la citation.
AJFaraday

1
L'estimation du temps de développement change au milieu de la phrase.
milleniumbug

Le 180% est le temps et le budget que le projet finit par coûter.
Agent_L

1
Je pense qu'il est parfaitement clair ce que cette question demande malgré la phrase finale maladroite.
Matthew James Briggs,

2
Cette citation est censée être lue comme une blague, dans ce contexte, elle a du sens. Cela signifie que les 10 derniers% prendront beaucoup plus de temps que vous ne l'imaginiez
Richard Tingle

Réponses:


40

Imaginez-le comme ceci: lorsque vous commencez à travailler sur un logiciel, vous pouvez écrire d'énormes quantités de code en un temps relativement court. Ce nouveau code peut ajouter une énorme quantité de nouvelles fonctionnalités. Le problème est que, souvent, cette fonctionnalité est loin d'être "terminée", il peut y avoir des bogues, de petites modifications (petites dans les petites entreprises) et ainsi de suite. Ainsi, le logiciel peut sembler presque terminé (90%), car il prend en charge la majorité des cas d'utilisation. Mais le logiciel a encore besoin de travail. Le point de cette règle est que, malgré l'impression que le logiciel est presque terminé, la quantité de travail pour amener ce logiciel dans un état de fonctionnement correct est aussi importante que pour atteindre cet état "presque terminé". En effet, la correction des bogues prend souvent du temps mais ne produit pas beaucoup de code.

Le problème est que la plupart des développeurs estiment que le logiciel se trouve dans un état "presque terminé", car cela est relativement simple par rapport à l'estimation réelle de l'effort total du logiciel.


3
Une grande partie de la raison de l'illusion 90-90 est que les ingénieurs logiciels visualisent souvent le chemin du succès - la remise des cas d'erreur et d'exception est une réflexion après coup. Si la conception d'origine ne prend pas en compte les cas d'erreur à faible probabilité, elle devra probablement être révisée avant que le logiciel puisse être considéré comme terminé.
Rumbleweed

1
+1 mais je pense que le deuxième paragraphe a besoin de texte en gras parce que c'est la partie vraiment importante de la leçon :)
Bob Tway

20

C'est une référence à un scénario commun, qui se produit malheureusement encore aujourd'hui:

  1. Il est demandé à l'équipe d'estimer (c.-à-d. De deviner) la quantité de travail nécessaire pour écrire tout le code,
  2. Le projet se poursuit avec de nombreuses pressions internes et externes pour "respecter les délais et le budget",
  3. Ainsi, pour un pourcentage significatif du projet, «dans les délais» est signalé. Cela est souvent aggravé par la sélection des tâches faciles en premier pour garantir de bons progrès.
  4. Puis, à un certain stade, un point critique est atteint où la réalité doit être acceptée: le projet ne sera pas achevé à temps et la date de sortie est repoussée (souvent plusieurs fois).

"90%" est un chiffre arbitraire, mais il fait bien le point: les estimations sont des suppositions et seront probablement fausses (souvent très fausses) et la nature humaine nous assure presque toujours sous-estimé, donc les choses dépassent.


14
Ce que l'on appelle "agile" ne résout rien au problème; il le distribue simplement parmi les articles plus petits, où exactement le même rapport se produit sur une échelle absolue plus petite, même si Cargill était facétieux. L'essentiel est que chaque projet comporte quelques petites choses qui prennent beaucoup de temps de développement.
Blrfl

3
@Blrfl La réponse n'implique pas que l'agilité résout le problème des estimations difficiles, mais elle atténue ses conséquences en faisant des estimations plus petites.
Eric

Ce n'est pas seulement un problème de gestion des ressources, je pense. Il est très facile de prototyper rapidement et sale les 90% d'un projet, mais les 10% restants prendront beaucoup de temps, car c'est souvent ici que nous nous soucions d'être pleinement conformes aux exigences initiales. Je suis dans des systèmes embarqués et je peux donner une démo d'un produit au vendeur plusieurs mois avant la sortie du produit, et il ne verra presque aucune différence entre la démo et le produit final, mais à coup sûr, la démo n'est pas livrable. Bugs, optimisation, fonctionnalités avancées, consommation d'énergie, c'est leother 90%
Tim

Faites-moi confiance même avec Agile merde frappe le ventilateur et explose!
JonH

2
Suppression de la réflexion après coup sur l'agilité car cela distrait clairement les gens du point principal de la réponse.
David Arno

7

J'ai entendu une version différente de cela (également appelée "règle 90-90") qui se présente comme suit:

Après avoir implémenté 90% des fonctionnalités, je dois encore implémenter les 90% restants .

Les deux versions font référence à la difficulté d'estimer correctement l'effort de développement de produits logiciels et aux pièges courants dans lesquels les gens ont tendance à tomber:

  • jeter des statistiques là où des estimations sont nécessaires et essentiellement deviner ("J'ai 80% terminé")
  • se concentrer sur la complexité algorithmique du code à écrire, au détriment du volume de travail (sous-estimer l'effort requis pour les tâches courantes)
  • étapes manquantes ("hors de vue, hors de l'esprit")
  • sous-estimer l'effort pour maintenir et modifier le code existant
  • sous-estimation de l'effort requis pour le code passe-partout / "colle"

6

Cette règle complète la règle 80-20. Maintenant, il existe de nombreuses interprétations différentes de la règle 80-20, mais les deux que j'aime le plus sont:

  1. Le premier développement de 80% des produits représente 20% des efforts.
  2. 80% des erreurs sont dans 20% du code.

En pratique, cela signifie ce qui suit: le développement commencera et se poursuivra jusqu'à un certain point où les premiers retards seront remarqués. Les retards peuvent être de diverses natures:

  • Contrôle de qualité médiocre, entraînant des bugs
  • Exigences supplémentaires que le client a rencontrées en cours de route (et les raisons peuvent également être multiples)
  • Exigences peu claires dès le départ, ce qui entraîne la suppression de certaines parties du développement précédent (ce qui peut également entraîner des bogues de régression)
  • Sous-estimations initiales dues à une portée peu claire, une erreur humaine ou des circonstances imprévues. Ces circonstances imprévues peuvent être des arrêts de travail, des démissions, des pannes matérielles ou, dans des cas extrêmes, des éruptions volcaniques (une fois que nous avons dû retarder un projet parce que nous ne pouvions pas voler sur place en raison d'une éruption volcanique en Islande).

L'essentiel est qu'il est beaucoup plus facile de s'approcher de l'objectif que de l'atteindre réellement.


1
La règle 80-20 est également connue sous le nom de en.wikipedia.org/wiki/Pareto_principle
Peter M. - signifie Monica

4

Je trouve l' explication de Wikipedia assez éclairante:

Cela s'ajoute à 180% dans une allusion ironique à la notoriété des projets de développement logiciel dépassant considérablement leur calendrier (voir estimation de l'effort de développement logiciel). Il exprime à la fois l'allocation approximative du temps aux parties faciles et difficiles d'un projet de programmation et la cause du retard de nombreux projets comme le manque d'anticipation des parties difficiles. En d'autres termes, il faut à la fois plus de temps et plus de codage que prévu pour faire fonctionner un projet.


1

Qu'est-ce que cela signifie exactement dans la pratique? Que les programmeurs font un travail substantiel et qu'ils donnent 180% d'eux-mêmes ou?

Non, les programmeurs font toujours la même quantité de travail par unité de temps. La citation concerne la sous-estimation des coûts et des dépassements. Le 180% est le temps et l'argent que le projet finit par coûter.

Cela signifie à peu près "Cela vous prendra deux fois plus de temps" et "Vous penserez que vous vous portez bien jusqu'à ce qu'il soit déjà trop tard (la date limite est proche)".


1

En pratique, cela signifie que les gens se mentent à eux-mêmes.

Si un programmeur dit "nous avons terminé à 90%", cela signifie que 90% des efforts pour créer les fonctionnalités ont été dépensés.

Si un chef de projet dit "nous avons terminé à 90%, j'ai juste besoin de quelqu'un pour le terminer", cela signifie qu'ils sont à 90% dans le budget (et probablement à 50%). C'est un client sans argent, avec des attentes élevées et une mauvaise attitude.

La différence est qu'il faut plus d'efforts que les fonctionnalités de codage pour terminer un projet: qa, correction de bogues, modifications de copie, déploiement.

Ces choses doivent être gérées dans le projet et relèvent de la responsabilité du chef de projet. Cela surprend souvent les nouveaux PM qui se tournent vers "90% de fonctionnalités complètes" seulement pour se rendre compte qu'ils ne sont qu'à mi-chemin du "projet terminé".

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.