En matière de développement de logiciels, il y a toujours cette question à un million de dollars : quelle méthodologie utiliser, Waterfall ou Agile ? Tout le monde a une opinion à ce sujet, et souvent, préférer une méthodologie revient à ne pas considérer l'autre comme une option valable. Waterfall est arrivé en premier, Agile est apparu plus récemment, mais nous sommes loin de parvenir à un consensus sur la solution la mieux adaptée aux besoins de développement.
Est-ce que Waterfall est mort ? Est-ce qu'Agile a définitivement pris sa place ? L'un est-il meilleur que l'autre ?
En partant des bases, nous examinerons l'état actuel des deux méthodologies en matière de développement de logiciels, en répondant à certaines des questions les plus courantes concernant chacune d'elles. Tout bien considéré, il sera également expliqué pourquoi, chez Imaginary Cloud, nous avons choisi Agile au lieu de Waterfall dans notre processus de développement.
Le Méthodologie en cascade a été nommé d'après ses phases séquentielles organisées de manière descendante (similaires à de véritables cascades), représentant les différentes étapes du développement logiciel d'un bout à l'autre. Il a été publié en 1970 par l'informaticien Winston Walker Royce et prévoyait à l'origine cinq phases distinctes : exigences, conception, mise en œuvre, vérification et entretien.
Certaines variantes du modèle original sont apparues au cours des décennies suivantes, mais la logique de Waterfall est restée la même. Lorsqu'une phase est terminée, sa sortie devient l'entrée de la phase suivante, qui commence immédiatement après la première. Il envisage tous les points essentiels qui composent développement de logiciels, et sa simplicité l'a rendu très facile à comprendre et à adopter immédiatement.
Waterfall s'assure que chaque phase est terminée avant de passer à la suivante. La raison ? Pour éviter de commencer le développement avant la fin des travaux de conception, ce qui pourrait entraîner d'éventuelles incongruités des deux côtés. En outre, il est possible d'estimer le coût et les efforts nécessaires à l'ensemble du projet dès le début de la phase des exigences grâce à ce modèle.
Alors que le modèle Waterfall était loin d'être la seule approche possible du développement logiciel, ce n'est qu'en 2001 qu'il a connu un changement de paradigme fondamental. Qu'est-ce qui l'a causé ? Développement logiciel agile.
Les principes du développement logiciel incrémental étaient déjà utilisés dans le cadre de différents processus éparpillés. Pourtant, ce n'est qu'en 2001 avec le Manifeste pour le développement de logiciels agiles, que le développement logiciel Agile (comme nous le savons) a été introduit et popularisé. Ce document très simple, élaboré par un groupe de développeurs de l'Utah, a certainement enfreint les conventions et les limites du développement logiciel, offrant une véritable alternative à la méthode Waterfall.
Vous trouverez ci-dessus un exemple parfait de ce que l'Agile vise à être. Les différents cycles, nommés conventionnellement sprints - chercher à générer de la valeur de manière cumulative, en s'inscrivant dans une perspective plus large menant à l'achèvement du projet. C'est là qu'elle diffère le plus de la méthode Waterfall.
Agile cherche à être plus flexible, en permettant des incréments réguliers et en minimisant le temps nécessaire à la planification en se concentrant sur délais plus courts. Chaque itération ajoute de la valeur au produit et fournit un logiciel fonctionnel au fur et à mesure de sa fin, planifiant l'étape la plus proche de manière plus détaillée que les autres qui suivront.
Différents sous-ensembles adoptent la philosophie Agile, comme cela s'est passé avec les variantes de Waterfall. DSDM (Dynamic Systems Development Method), FDD (Feature-Driven Development), XP (Extreme Programming) et, probablement le plus populaire, Scrum, s'appuient tous sur la méthode Agile pour exécuter les processus de développement logiciel.
Indépendamment des opinions divergentes, c'est un fait qu'Agile a changé la façon dont développeurs de logiciels ont décidé de leur approche à l'égard de nouveaux projets. Sachant ce que chaque méthodologie représentait, qu'est-ce que cela signifiait pour Waterfall ?
Presque autant de personnes disent que Waterfall est morte que celles qui disent qu'Agile est une tendance insignifiante. Il n'y a rien de mal à avoir des opinions différentes, mais revenons aux faits :
Le Enquête Stack Overflow La photo ci-dessus montre à quel point Agile est, sans aucun doute, le premier choix des développeurs de logiciels. En plus d'être le premier choix utilisé par 85,4,9 % de la communauté, le sous-ensemble populaire Scrum prend la deuxième place avec 62,7 %. Plus bas, Waterfall se trouve à la sixième place, avec 15,1 % d'utilisation.
À première vue, cela ne semble pas bon pour Waterfall. Nous pouvons clairement affirmer que l'Agile est la méthode la plus populaire, et il n'y a aucun moyen de contester ces chiffres. Cependant, c'est une erreur d'ignorer un pourcentage aussi élevé de développeurs qui utilisent Waterfall. Nous ne dirions pas, par analogie, que Huawei est une marque hors de propos car elle ne détient que 14,6 % de part de marché dans l'industrie de la téléphonie mobile, derrière Apple et Samsung.
Cependant, il est un fait que Agile a exposé quelques faiblesses et failles du modèle Waterfall en soulignant à quel point il est difficile de résoudre les problèmes lors des phases précédentes et combien un processus complet est nécessaire pour disposer d'un logiciel fonctionnel. Tout cela avec une grande incertitude entre les deux.
Au fur et à mesure que le message se répandait, c'est devenu cool d'être agile, tout le monde voulait y participer, et tous les processus sont devenus agiles en conséquence. Personne ne se vante de ses processus Waterfall. Du marketing et de l'économie aux logiciels conception et développement, chaque entreprise souhaite que tout le monde sache qu'elle est agile, même si elle-même ne sait pas ce que cela signifie. C'est ce qui est à l'origine de toute l'erreur qui soutient l'argument selon lequel Waterfall n'est plus pertinent.
Tout le monde semble passer à côté de l'essentiel : ni Waterfall n'est mort, ni Agile n'est la solution universellement supérieure méthodologie pour le développement de logiciels. Adopter l'un plutôt que l'autre pour être meilleur n'est qu'une illusion qui masque souvent l'inexistence d'un processus approprié.
Waterfall est certainement le meilleur choix pour les projets stables, car une planification minutieuse est effectuée au départ, en tenant compte de tous les aspects (internes et externes) qui peuvent influencer l'exécution du projet. Quelle que soit la dimension du projet, Cascade est le choix le plus adapté lorsque l'environnement extérieur est stable et peu susceptible de subir des changements tout au long du plan.
Pour ce type de projets, Waterfall était la meilleure approche avant l'entrée en scène d'Agile, et c'est toujours le cas aujourd'hui. Si vous pouvez planifier un projet à l'avance dans un environnement à faible risque, il n'y a aucun avantage réel à le diviser en plusieurs sprints pour générer de la valeur chaque semaine. Il est préférable de se concentrer immédiatement sur le résultat final.
Sinon, Agile est la voie à suivre pour les projets qui nécessitent un processus plus flexible, compte tenu de leur nature instable et imprévisible. En d'autres termes, si la vision du produit et ses caractéristiques respectives peuvent changer en raison de facteurs externes (par exemple, la dynamique du marché, etc.), il est préférable de créer et d'adapter le produit en utilisant Agile. C'est également la meilleure méthode pour s'assurer que le projet ne reste pas en développement pendant plusieurs mois avant de présenter un résultat. À la fin de chaque sprint, il y aura un point de contrôle dans lequel propriétaire du produit peut tester et approuver le travail terminé.
Dans les projets évolutifs qui adoptent Waterfall, l'absence de points de contrôle appropriés crée des risques car il est plus difficile de résoudre les éventuels problèmes détectés à la fin du développement. Le temps supplémentaire alloué à la planification de l'ensemble du projet ne garantit pas le bon déroulement des phases de conception et de développement jusqu'à la fin, car la plupart des problèmes sont aussi indésirables qu'imprévisibles.
Choisir l'un ou l' Waterfall contre Agile devrait être plus qu'un simple geste marketing. Il doit tenir compte de tous les aspects qui peuvent influencer un projet et de la précision a priori de la définition d'un produit. Choisir le mauvais outil pour le travail peut entraîner des coûts supplémentaires en temps et en efforts.
Chaque défi de développement logiciel a ses particularités et, généralement, la phase des exigences de toute méthode est le moment où les cartes sont posées. Cependant, avant de passer directement à l'action, vous devez connaître quelques questions concernant la nature du projet.
Des méthodes telles que Waterfall et Agile existent en tant qu'approches différentes pour résoudre des variantes des mêmes problèmes. En fonction de leurs particularités, plusieurs projets peuvent être mieux développés et mieux adaptés à l'un ou à l'autre.
Dans l'ensemble, pourquoi préférons-nous Agile à Waterfall ? Compte tenu de ce que nous avons vu jusqu'à présent, j'espère que nous avons tous dépassé les explications telles que « Waterfall est mort, vive Agile ». En règle générale, l'un n'est pas meilleur que l'autre et, la plupart du temps, c'est une erreur de penser le contraire. Nous avons essayé Waterfall pendant longtemps, et nous sommes passés à la méthode Agile lorsque, compte tenu de la nature de la plupart de nos projets, nous avons trouvé que c'était le meilleur choix.
Dans notre Processus de développement agile, nous avons adopté une méthodologie Scrum, un sous-ensemble de la méthode Agile, et avons procédé à quelques ajustements pour répondre aux besoins spécifiques de nos clients. Nous pensons que c'est la meilleure option pour nos projets, car nous envisageons à la fois la possibilité d'y mettre fin par un MVP (Minimum Viable Product), qui relèverait de la phase de preuve de concept, ou d'aller plus loin grâce à une série de sprints qui ajouteront de la valeur ajoutée au produit.
Une fois de plus, ce serait une erreur de penser qu'il s'agit du meilleur processus possible à adopter pour chaque projet, et c'est la raison pour laquelle nous le révisons et l'adaptons à nos besoins si nécessaire. C'est ce qui nous a amenés à passer de Waterfall à Agile en premier lieu, et si nécessaire, d'autres améliorations seront apportées. Cependant, il ne s'agit jamais de créer des solutions universelles, car un tel concept n'existera jamais dans développement de logiciels.
Il est clair que Waterfall n'est pas mort et qu'Agile n'est pas le meilleur choix en soi. C'est la façon la plus simple de voir les choses et la plus dangereuse de gérer le développement de logiciels. Tout dépend de vos besoins spécifiques et de la meilleure façon d'atteindre les objectifs souhaités. Toute discussion ultérieure à ce sujet crée un bruit inutile.
Ce qui s'est passé ces dernières années, c'est qu'être agile est considéré comme un avantage. Une caractéristique notable à laquelle une entreprise peut s'associer et qui prouve instantanément sa qualité. Ce n'est pas tout le monde qui est agile, et personne ne sait ce qu'est l'Agile. Pourtant, toute cette agitation fait qu'il est plus difficile pour quiconque de vraiment comprendre ce que sont les méthodologies Waterfall et Agile sont tout à fait à propos de.
La meilleure façon d'aller au-delà de l'apparence et de réellement faire la différence dans un processus de développement logiciel est de bien comprendre les besoins de chaque projet, de choisir la méthode qui lui convient le mieux et de s'adapter en conséquence.
Gestionnaire de contenu, éditeur de texte et présentateur d'idées stratégiques, tout en étant un fervent amateur des arts cinématographiques et de la narration visuelle.
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
