Parmi les approches de gestion des projets informatique on trouve le fameux "Cycle en V" nommé aussi "Cycle en Cascade", qui un cycle de vie basé sur l’enchaînement de plusieurs étapes séquentielles reflétant une approche de livraison fermée, depuis les exigences centralisées dans un cahier de charge (CPS), la conception, la modélisation, le développement, les tests, jusqu'à la livraison finale chez le client.
Scrum à son tour, est un Framework et cadre méthodologique agile de gestion de projets et équipes défini par "Ken Schwaber" et "Jeff Sutherland", il s’inspire de valeurs et principes de l'agilité, et se base sur le principe itératif et incrémental basé sur un Product Backlog vivant, ordonné, simple, réduit, unique, et construit pas à pas permettant à chaque moment l’émergence de nouvelles demandes et fonctionnalités dites User Stories. L'utilisation de ce Framework est largement répandue dans le domaine de développement informatique.
Certaines entreprises ou équipes comprennent mal la définition de chaque approche et le déploiement d'une méthode agile adéquate à leur contexte et environnement de travail.
À travers cet article j'essaye de mettre en évidence la réalité dans laquelle plusieurs organisations et entreprises se retrouvent dans leur transformation et cheminement vers l'agilité. il s'agit d'une redoutable redondance de l'histoire de développement en cascade, en essayant de fusionner les deux approches au même temps ce qui ne reflète pas la bonne utilisation de l'agilité.
En fait, chaque approche a une définition claire, des principes, et des objectifs, alors en essayant de fusionner les deux cela va mettre en péril plusieurs principes et aspects du Framework "Scrum", et même le "Scrum Guide" interdit clairement les personnalisations pouvant changer ou massacrer les lignes directives fondamentales de ce Framework.
Le "Water Scrum Fall" est tout simplement la fait d'enfermer le "Scrum" dans un "Cycle en V", tout en gardant la notion de cahier de charge initial donc un Scope fixe et figé dès le départ et pas discuté et variable comme le cas pour le Product Backlog.
On garde le même principe des étapes séquentielles, par contre au niveau de celle de développement on va introduire le "Scrum" pour mettre des cycles itératifs, sachant qu'il y aura qu'une seule livraison finale, du coup l'équipe va être amenée a faire des tests globaux à la fin.
Dans ce cas de figure, l'équipe va attendre la validation globale du cahier de charge pour commencer à découper ce besoin ferme en petits morceaux afin de l'introduire pas à pas dans les Sprints, pas de négociation, pas de discussion, ce qui est contre le concept de rédaction et finalisation des User Stories.
Conclusion :
Le "Water Scrum Fall" existe toujours chez certaines équipes, alors que ce n'est pas de l'agile, par contre on perd beaucoup en terme de l'agilité et du Framework Scrum si on l'adopte ce mode de travail.
Je n'ai pas fait cet article pour massacrer le "Cycle en V", mais chaque approche à ses propres caractéristiques et principes, et on doit être capable de choisir celle adéquate pour notre contexte, soit l'agilité, soit le mode en cascade qui fonctionne encore bien chez certaines entreprises.
Opmerkingen