---

Planifier tout le projet avant de le comprendre ? Cela pourrait vous surprendre !

Sans Scrum, nos équipes construisaient et livraient des produits logiciels et matériels totalement inadaptés aux demandes client.

À certaines périodes, des entreprises tierces nous imposaient la façon de construire nos produits ou services logiciels.

Capability Maturity Model (CMM), ISO 9001:2008 et d’autres variantes tentaient de nous aider à construire les bons logiciels de la bonne façon.

Leur réussite n’est pas le sujet de ce livre. Il se concentre sur le processus et les mérites de Scrum, plutôt que critiquer des procédures presque disparues.

Je dois cependant préciser que ces cadres d’amélioration antérieurs à Scrum recommandaient une démarche par phases appelée modèle d’ingénierie logicielle en cascade.

Chaque projet devait commencer par l’analyse des besoins pour comprendre les attentes et souhaits du client.

Puis nous concevions, implémentions et testions les exigences avant de maintenir le logiciel en production, jusqu’à la fin du cycle d’ingénierie.

Mais la réalité ne se déroulait pas ainsi !

Méthode en cascade et cadre Scrum

Les phases du modèle classique de développement logiciel en cascade

Tout retard imprévu dans une phase de la cascade affectait inévitablement les suivantes.

Les études montrent que, dans plus de 80 % des projets logiciels échoués examinés, la cascade était un facteur critique d’échec. Mais pourquoi ?

Comme illustré à gauche, la cascade impose une séquence stricte : une phase doit finir avant la suivante. Revenir en arrière est généralement coûteux, long, pénible et frustrant pour l’équipe.

Le calendrier est fixé au début et le produit livrable arrive seulement à la fin. Une phase en retard retarde toutes les autres.

Pour éviter cela, les chefs de projet tentent de tout anticiper et de définir très tôt des exigences complètes et détaillées. C’est difficile au début et nombre d’exigences changent, ou devraient changer, pendant le projet.

Dans les grands projets complexes, les études montrent qu’environ 60 % des exigences initiales changent. D’autres sont réalisées comme prévu alors que le client n’en a pas vraiment besoin. Elles consomment temps et argent qui auraient mieux servi des fonctionnalités à plus forte valeur.

Le découpage pousse à estimer chaque phase séparément, alors qu’en réalité elles travaillent ensemble et en parallèle.

Personne ne peut raisonnablement supposer que le développement est terminé avant le début des tests. C’est pourtant ainsi que la cascade fonctionnait malheureusement.

La cascade peut convenir à de petits projets simples. Pour les projets plus grands et complexes, elle est très risquée, voire insensée. Elle est souvent plus coûteuse et toujours moins efficace que Scrum pour développer et livrer des logiciels.

C’était avant Scrum. Les allers-retours du logiciel entre équipes, sans professionnels compétents en Scrum, rendaient notre travail bureaucratique, complexe et improductif.

Le produit en souffrait, mais aussi le moral des employés et leur engagement envers notre mission.