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?
programming-practices
theory
Josip Ivic
la source
la source
Réponses:
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.
la source
C'est une référence à un scénario commun, qui se produit malheureusement encore aujourd'hui:
"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.
la source
other 90%
J'ai entendu une version différente de cela (également appelée "règle 90-90") qui se présente comme suit:
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:
la source
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:
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:
L'essentiel est qu'il est beaucoup plus facile de s'approcher de l'objectif que de l'atteindre réellement.
la source
Je trouve l' explication de Wikipedia assez éclairante:
la source
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)".
la source
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é".
la source