Cascade
Définition
Le cycle en cascade se caractérise par des phases séquentielles, qui se succèdent après la validation des livrables de la phase précédente.
La méthodologie Waterfall a largement été utilisée pour créer des logiciels. Elle suppose :
- une connaissance parfaite avant même de commencer
- que tout au long du développement le périmètre reste inchangé
- qu’on ne changera pas de direction au cours du développement
- les changements sont supposés être minimes.
La méthode Waterfall avait pour but de garantir que le produit final correspond à ce qui avait été spécifié au départ. Cette approche fonctionnait bien sur des applications complexes et monolithiques qui exigeaient de la discipline et des résultats clairs (année 70).
Le pivot vers la philosophie Agile
Le développement massif d’Internet a permis l’émergence de nombreuses petites entreprises qui créaient des applications web. Les équipes de développement de ces sociétés commençaient à remettre en question la méthodologie Waterfall et cherchaient des moyens d’être plus efficace.
Ayant une structure organisationnelle et un projet moins complexe qu’une enterprise “Legacy System”, elles pouvaient donc être à l’écoute et répondre plus rapidement aux besoins du client.
Les développeurs ont commencé à rejeter la planification de bout en bout et les spécifications prédéfinis. Nous sommes à la naissance de l’agilité :
- Un produit ne peut pas être entièrement spécifié au départ.
- L’économie est trop dynamique : l’adaptation du processus s’impose.
- Accepter les changements d’exigences, c’est donner un avantage compétitif au client.
Accepter l’incertitude
Affirmation
Il s’agit d’accepter une réalité et de comprendre que dans le développement logiciel tout n’est pas prévisible.
Chaque projet est une nouvelle expérience où il est très difficile de se mettre d’accord une fois pour toutes avec le client. En acceptant l’incertitude, on accepte également l’idée du changement :
- dans le périmètre du besoin
- dans la planification
- dans l’organisation de l’équipe
⇒ On s’adapte aux imprévus. En s’appuyant sur le feedback, *l’expérience- et le constat. Nous optons pour une démarche d’amélioration continue.
Accepter le changement
Affirmation
Accueillir le changement à bras ouverts plutôt que de le craindre et le combattre.
On sait que de nombreux paramètres sont imprévisibles lors du projet. Il s’agit donc de mieux contrôler cette imprévisibilité sans la nier en évitant d’être systématiquement obsédé par les plans initiaux obsolètes.
⇒ Une équipe agile se dote de pratiques et d’outils qui lui facilite l’accueil du changement.
Quelques chiffres
Une étude menée en 1995 nous révèle que :
- 16% des logiciels sont finis dans les temps et le budget alloué
- 31% sont abandonnées
- 53% dépassent le coût et/ou le délai
C’est dans un contexte de gaspillage et de transformation du numérique quand 2001 une équipe d’expert se réunir afin de rédiger le Manifeste Agile. Depuis, The Standish Group publie annuellement le CHAOS Report qui regroupe un ensemble de statistique sur les projets informatiques. Par exemple en 2015, on dénombrait 29% des projet finis en temps/budget, 19% abandonnés et 52% connaissaient des dépassements de coût/délais.