La règle de quatre-vingt-dix-quatre-vingt-dix dans la pratique
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?
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 passe à l'état "presque terminé", car cela est relativement simple par rapport à l'estimation réelle de l'effort total que le logiciel prendra.
C'est une référence à un scénario commun, qui se produit malheureusement encore aujourd'hui:
- Il est demandé à l'équipe d'estimer (c.-à-d. De deviner) la quantité de travail nécessaire pour écrire tout le code,
- Le projet se poursuit avec de nombreuses pressions internes et externes pour "respecter les délais et le budget",
- 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.
- Puis, à un certain stade, un point critique est atteint où la réalité doit être acceptée: le projet ne sera pas terminé à 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.
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é")
- concentration sur la complexité algorithmique du code à écrire, au détriment du volume de travail (sous-estimation de 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"
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:
- Le premier développement de 80% des produits représente 20% des efforts.
- 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 car 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.
Je trouve Wikipedia explication assez éclairante:
Cela ajoute jusqu'à 180% dans une allusion ironique à la notoriété des projets de développement logiciel dépassant de manière significative leurs calendriers (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 dures. En d'autres termes, il faut à la fois plus de temps et plus de codage que prévu pour faire fonctionner un projet.
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 allez bien jusqu'à ce qu'il soit déjà trop tard (la date limite est proche)".
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 éléments doivent être gérés dans le cadre du 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é".