Ces dernières années, nous avons connu un changement significatif dans les modèles de développement utilisés pour créer des produits numériques. En effet, certaines entreprises s'éloignent de la méthode en Cascade, précédemment prédominante, vers des méthodologies plus agiles telles que l'approche Scrum. Cet article examine de manière critique les deux approches pour déterminer les avantages et les inconvénients de chaque méthode et comment le testing QA s'y articule.
Une introduction à la Cascade
La méthode en Cascade est un modèle où les phases de développement suivent rigoureusement un ordre spécifique. La phase suivante ne peut commencer que lorsque la phase précédente a été conclue. D'une manière générale, l'approche en Cascade commence par une planification et un design étendus, suivis d'un codage et d'un test, et se termine par la publication. L'idée principale derrière la méthode en Cascade est que le processus de planification approfondi nie la nécessité d'apporter des ajustements importants lors du développement. À cette fin, la technique en Cascade tente de se préparer à tous les scénarii afin d'éviter des retards qui coûtent du temps et des ressources.
Une introduction à Scrum
L'approche Scrum (littéralement : mêlée au rugby) est tout à fait différente en ce sens où il ya un ajustement continu du processus de développement. Fidèle à sa nature agile, Scrum comprend les exigences et l'interaction continue entre les groupes autonomes créés selon les compétences. Contrairement à l’approche en Cascade, Scrum se développe par sprint au lieu d'un processus continu. Tel que défini par Scrum Alliance:
« Scrum est un ensemble de principes et de pratiques simples mais incroyablement puissants qui aident les équipes à livrer des produits en cycles courts, ce qui permet une rétroaction rapide, une amélioration continue et une adaptation rapide aux changements. Comme le premier cadre de développement Agile, Scrum a principalement été utilisé pour le développement de logiciels, mais il se révèle également efficace pour le développement dans d'autres secteurs aussi.»
Scrum se concentre sur la performance individuelle de chaque développeur au lieu de la fonctionnalité du processus de développement. En mettant l'accent sur l'autonomie, la méthode Scrum n'inclut pas souvent un chef d'équipe et le développement reste flexible. Cette flexibilité est très recherchée et, par conséquent, la méthode Scrum a été adoptée par de grandes entreprises bien connues dont Salesforce, Accenture, Vendesk, AutoZone, Wells Fargo, Walmart et Symantec (Source: Canvas Info Tech).
Forces et faiblesses de la méthode en Cascade
Même avec la migration récente vers l'approche Scrum, il existe encore des avantages considérables avec la méthode en Cascade. Tout d'abord, les spécifications élaborées permettent aux développeurs de détecter des dangers potentiels à l'avance. En raison de cette planification avancée, les ressources peuvent également être réparties efficacement si le développement reste sur la bonne voie.
De plus, le développement se déroulera correctement car le modèle a effectivement tout prévu. Cela permet de prévoir des possibilités qui ne sont pas disponibles lors de l'utilisation de Scrum pour créer un produit. Bien sûr, des contingences ne peuvent être effectuées pour tous les scénarios, de sorte que la méthode en Cascade n'est pas à l'abri de problèmes inattendus. Fondamentalement, l’approche en Cascade est un processus organisé avec des zones de responsabilité clairement définis.
Il y a des inconvénients marqués pour l'approche en Cascade du développement. Le premier inconvénient, et celui qui peut disqualifier la méthode en Cascade comme choix viable dans certains cas, est le temps considérable consacré au processus de planification. Parce que chaque élément de développement doit être planifié en avance, le codage peut être retardé de quelques jours ou même des semaines.
Un autre inconvénient est le niveau élevé de micro-gestion que la méthode en Cascade nécessite. Le processus déjà ralenti, par rapport à Scrum, est encore entravé par la forte implication managériale requise par l'approche. Il est clair que le temps peut être un facteur important et la Cascade peut être considérablement plus lente du début à la fin que Scrum.
Forces et faiblesses de l'approche Scrum
Il existe également de nombreux avantages pour la méthode Scrum lors du développement. Contrairement à la méthode en Cascade, Scrum ne nécessite pas de planification significative et le développement peut commencer très rapidement. Avec Scrum, les exigences sont créées grâce à des histoires d'utilisateurs qui contiennent des descriptions des résultats escomptés liés aux critères d'acceptation des utilisateurs et au comportement de l'utilisateur.
De plus, Scrum est beaucoup plus flexible que l’approche en Cascade et est conçu pour traiter l'ambiguïté confortablement. Avec Scrum, les développeurs travaillent avec les storytellings d'utilisateurs et ne reçoivent pas de tâches rigides. De plus, les storytellings d'utilisateurs diminuent l'impact que les scénarii imprévus peuvent avoir sur le projet, car les développeurs peuvent facilement pivoter et continuer vers leur objectif.
Les inconvénients de Scrum sont faciles à voir. Si une équipe ne peut pas détecter les risques potentiels lors de leur planification de sprint, si un testeur n'est pas impliqué dans les processus de développement dès le début, si une équipe manque de communication ou de responsabilité, cela entraînera inévitablement des problèmes. En ce qui concerne ces problèmes, il n'y a pas de chef de projet pour gérer l'équipe de développement (Source: 4xxi Blog).
En outre, le manque de planification peut entraîner des goulets d'étranglement imprévus par rapport à la méthode en Cascade. Les développeurs Scrum peuvent être plus efficaces pour faire face aux goulots d'étranglement que leurs homologues en Cascade, mais cette flexibilité peut perdre son avantage s'il y a beaucoup plus de défis à surmonter.
Le Test pour chaque méthode
En ce qui concerne les tests, les deux méthodes reconnaissent l'importance que l'assurance qualité peut avoir sur le produit fini. Dans l'approche en Cascade, les tests d'acceptation des utilisateurs (UAT) sont effectués après l'intégration. Les tests QA mènent à un produit final fonctionnel sans bugs majeurs.
En Scrum, les tests et l'intégration se produisent simultanément. Cela économise du temps précieux si les développeurs essaient d'accélérer le processus de développement. Cependant, les tests en Scrum ont un challenge évident : il existe considérablement plus d'erreurs critiques dans le produit final. Avec la méthode en Cascade, vous avez des tests d'acceptation d'un utilisateur à la fin de la phase de développement.
Avec Scrum, vous pouvez planifier une phase UAT après chaque sprint ou après un certain nombre de sprints, en fonction de la complexité et de la longueur de chaque sprint. Par conséquent, il est important d'allouer le temps de test à l'avance selon le modèle de développement. Indépendamment de la méthode, les tests d’assurance qualité ont une partie essentielle de tout développement de produit et ne doivent jamais être négligés.
Conclusion
Alors, quelle méthode est la meilleure option ? La méthodologie qu’une société choisit dépend directement de plusieurs facteurs. Les compétences de votre équipe, le but et la portée du projet, ainsi que la préférence personnelle du gestionnaire peuvent jouer un rôle dans la détermination de la méthode la mieux adaptée à la tâche à accomplir. Cette décision devrait être envisagée avant la phase de développement actif du produit car le résultat en dépend fortement.
L’approche en Cascade est habituellement le choix correct en cas de date d’échéance stricte ou en recherchant des performances bien équilibrées. Scrum, d'autre part, est utile lorsque la sortie finale du projet est moins claire ou lorsque vous souhaitez une participation accrue des membres de l'équipe. Comme indiqué précédemment, lors de l'utilisation de la méthode en Cascade, une phase UAT plus longue après l'intégration devrait être anticipée.
Avec Scrum, il convient d'exécuter une courte phase de test après chaque sprint ou une fois par mois en cas de sprints hebdomadaires. La culture d'entreprise peut également jouer un rôle car certaines entreprises préfèrent la stabilité que la méthode en Cascade fournit et d’autres sociétés préfèrent l'adaptabilité et la créativité de Scrum. En fin de compte, la solution devrait être dictée par la situation.
Pour en savoir plus, n'hésitez pas à nous contacter. Nous vous invitons à découvrir notre livre blanc sur les tests en agile.
