L’une des premières décisions que nous, de notre projet, implémentations à Segue est « Qui méthodologie de développement devrions-nous utiliser? »C’est un sujet qui fait l’objet de nombreuses discussions (et de débats souvent houleux)., Si ce n’est pas quelque chose avec lequel vous avez travaillé auparavant, une définition de la méthodologie de développement est en ordre; en termes très simples, c’est une façon d’organiser le travail de développement de logiciels. Il ne s’agit pas d’un style de gestion de projet ou d’une approche technique spécifique, bien que vous entendiez souvent ces termes tous jetés ensemble ou utilisés de manière interchangeable.

Les deux méthodologies de base les plus populaires sont:

1. Waterfall: (ugh, nom terrible!,), qui pourrait être plus correctement appelée l’approche « traditionnelle”, et
2. Agile: un type spécifique de développement rapide d’applications et plus récent que Waterfall, mais pas si nouveau, qui est souvent implémenté en utilisant Scrum.

ces deux méthodes sont utilisables et matures. Ayant été impliqué dans des projets de développement de logiciels depuis longtemps, voici mes réflexions sur les forces et les faiblesses de chacun.

la méthodologie Waterfall

Waterfall est une approche linéaire du développement logiciel., Dans cette méthodologie, la séquence d’événements est quelque chose comme:

1. rassembler et documenter les exigences
2. conception
3. Code et test unitaire
4. effectuer des tests système
5. effectuer des tests d’acceptation utilisateur (UAT)
6. résoudre les problèmes
7. livrer le produit fini

dans un vrai projet de développement en cascade, chacun de ces éléments représente une étape distincte du développement logiciel, et chaque étape se termine généralement avant le prochain peut commencer., Il y a aussi généralement une porte d’étape entre chaque; par exemple, les exigences doivent être examinées et approuvées par le client avant que la conception puisse commencer.

Il y a de bonnes et de mauvaises choses dans L’approche en cascade. Du côté positif:

• Les développeurs et les clients sont d’accord sur ce qui sera livré au début du cycle de vie du développement. Cela rend la planification et la conception plus simples.
• Les progrès sont plus facilement mesurés, car toute la portée du travail est connue à l’avance.,
• tout au long de l’effort de développement, il est possible pour différents membres de l’équipe d’être impliqués ou de poursuivre d’autres travaux, selon la phase active du projet. Par exemple, les analystes commerciaux peuvent apprendre et documenter ce qui doit être fait, tandis que les développeurs travaillent sur d’autres projets. Les testeurs peuvent préparer des scripts de test à partir de la documentation des exigences pendant le codage.
• Sauf pour les examens, les approbations, les réunions, etc., une présence de client n’est pas strictement exigée après la phase d’exigences.,
• étant donné que la conception est terminée au début du cycle de développement, cette approche se prête aux projets où plusieurs composants logiciels doivent être conçus (parfois en parallèle) pour être intégrés à des systèmes externes.
• enfin, le logiciel peut être conçu complètement et avec plus de soin, sur la base d’une compréhension plus complète de tous les livrables logiciels., Cela fournit une meilleure conception logicielle avec moins de probabilité d ‘” effet fragmentaire », un phénomène de développement qui peut se produire lorsque des morceaux de code sont définis et ajoutés ultérieurement à une application où ils peuvent ou non bien s’adapter.

Voici quelques problèmes que nous avons rencontrés en utilisant une approche en cascade pure:

• un domaine qui manque presque toujours est l’efficacité des exigences. Rassembler et documenter les exigences d’une manière significative pour un client est souvent la partie la plus difficile du développement logiciel, à mon avis., Les clients sont parfois intimidés par les détails, et des détails spécifiques, fournis au début du projet, sont requis avec cette approche. De plus, les clients ne sont pas toujours en mesure de visualiser une application à partir d’un document d’exigences. Les Wireframes et les maquettes peuvent aider, mais il ne fait aucun doute que la plupart des utilisateurs finaux ont du mal à assembler ces éléments avec des exigences écrites pour arriver à une bonne image de ce qu’ils obtiendront.,
• Un autre inconvénient potentiel du développement Pure Waterfall est la possibilité que le client soit insatisfait de son produit logiciel livré. Comme tous les livrables sont basés sur des exigences documentées, un client peut ne pas voir ce qui sera livré jusqu’à ce qu’il soit presque terminé. À ce moment-là, les changements peuvent être difficiles (et coûteux) à mettre en œuvre.

la méthodologie Agile

Agile est une approche itérative du développement en équipe. Cette approche met l’accent sur la livraison rapide d’une application dans des composants fonctionnels complets., Plutôt que de créer des tâches et des horaires, tout le temps est « encadré” en phases appelées « sprints ».” Chaque sprint a une durée déterminée (généralement en semaines) avec une liste de livrables, prévu au début du sprint. Les livrables sont classés par ordre de priorité en fonction de la valeur métier déterminée par le client. Si tous les travaux planifiés pour le sprint ne peuvent pas être achevés, le travail est recalculé et les informations sont utilisées pour la planification future du sprint.

lorsque le travail est terminé, il peut être examiné et évalué par l’équipe du projet et le client, à travers des builds quotidiens et des démos de fin de sprint., Agile s’appuie sur un très haut niveau d’implication client tout au long du projet, mais surtout lors de ces revues.

certains avantages de L’approche Agile sont faciles à voir:

• Le client a des occasions fréquentes et précoces de voir le travail livré, et de prendre des décisions et des changements tout au long du projet de développement.
• Le client acquiert un fort sentiment d’appartenance en travaillant intensivement et directement avec l’équipe du projet tout au long du projet.,
• si le délai de mise sur le marché d’une application spécifique est plus important que la publication d’un ensemble complet de fonctionnalités au lancement initial, Agile peut produire plus rapidement une version de base du logiciel de travail qui peut être construite par itérations successives.
• Le développement est souvent plus axé sur l’utilisateur, probablement le résultat d’une orientation plus fréquente de la part du client.,
• Pour plus D’avantages en matière de développement Agile, veuillez consulter 8 Avantages du développement logiciel Agile

et, bien sûr, il y a quelques inconvénients:

• Le Très haut degré d’implication des clients, bien qu’excellent pour le projet, peut présenter des problèmes pour certains clients qui n’ont tout simplement pas
• Agile fonctionne mieux lorsque les membres de l’équipe de développement sont entièrement dédiés au projet.,
• étant donné Qu’Agile se concentre sur la livraison en boîte à temps et la redéfinition fréquente des priorités, il est possible que certains articles devant être livrés ne soient pas terminés dans le délai imparti. Des sprints supplémentaires (au-delà de ceux initialement prévus) peuvent être nécessaires, ajoutant au coût du projet. En outre, la participation du client conduit souvent à des fonctionnalités supplémentaires demandées tout au long du projet. Encore une fois, cela peut augmenter le temps et le coût global de la mise en œuvre.,
• Les relations de travail étroites dans un projet Agile sont plus faciles à gérer lorsque les membres de l’équipe sont situés dans le même espace physique, ce qui n’est pas toujours possible. Cependant, il existe une variété de façons de gérer ce problème, telles que les webcams, les outils de collaboration, etc.
• La nature itérative du développement Agile peut conduire à un refactoring fréquent si la portée complète du système n’est pas prise en compte dans l’architecture et la conception initiales. Sans ce refactoring, le système peut souffrir d’une réduction de la qualité globale., Cela devient plus prononcé dans les implémentations à plus grande échelle, ou avec des systèmes qui incluent un haut niveau d’intégration.

faire le choix entre Agile et Waterfall

alors, comment choisir? Tout d’abord, nous changeons un peu le jeu (ce que font la plupart des organisations de développement de logiciels) en définissant notre propre processus. Chez Segue, cela s’appelle notre cadre de processus, et c’est une variation de la méthodologie traditionnelle en cascade., Nos modifications incluent l’utilisation du prototypage dans la mesure du possible pour fournir au client une meilleure vue de son produit fini au début du cycle de conception/développement. Cela contribue à améliorer la compréhension des exigences de l’équipe et la communication avec le client. Une fois le cadre principal de l’application terminé selon les exigences de haut niveau, nous continuons à développer et à tendre la main au client pour le raffinement des exigences. De cette façon, nous nous efforçons d’être aussi itératifs que possible sans compromettre notre architecture système globale.,

Nous tenons compte des facteurs suivants pour déterminer la méthodologie à utiliser:

Les facteurs ci-dessus ne sont pas également pondérés; chacun est évalué en fonction du projet et des circonstances.

bien que nous commencions à voir l’adoption massive de diverses méthodologies agiles dans l’entreprise (même les agences du DoD et fédérales), il y a encore beaucoup d’organisations qui tardent à faire le changement., Il est également très courant pour l’organisation de passer à une approche Agile plus hybride qui combine aspect Agile et Cascade. Le guide de pratique Agile a été développé spécifiquement pour aider l’organisation à comprendre et à évaluer l’utilisation des approches agiles et hybrides. Le Project Management Institute (PMI) qui a développé le guide Project Management Body of Knowledge (PMBOK) a collaboré avec Agile Alliance pour regrouper les deux guides en une seule offre pour aider les organisations, les gestionnaires et les dirigeants à accroître leur agilité dans le processus de développement.,

Une fois que nous avons décidé de la méthodologie de base à utiliser, nous pouvons affiner le processus pour mieux répondre aux objectifs de notre projet. En fin de compte, bien que la façon dont nous faisons notre travail soit importante, fournir un produit solide et maintenable qui satisfait notre client est ce qui compte vraiment.