Agile et Waterfall

• La documentation et les exigences détaillées des produits permettent aux nouveaux programmeurs de s’intégrer rapidement et facilement.
• La documentation fournit une portée claire du projet, permettant aux chefs de projet de communiquer les budgets, les délais et les étapes clés aux parties intéressées.

• Les clients peuvent avoir du mal à définir toutes leurs exigences dès le début du projet, ce qui entraîne des lacunes dans la documentation.
• Une collaboration minimale avec le client pendant le processus de développement peut entraîner des modifications coûteuses si le produit ne répond pas aux attentes.
• Les testeurs signalent les problèmes et les bugs plus tard au cours du processus, ce qui aurait pu éclairer une architecture de programme alternative.

Contrairement au développement en cascade, Agile est défini par son approche itérative de la gestion de projet. Au lieu de rédiger de longues exigences de projet dès le départ, une équipe agile décompose le produit en fonctionnalités spécifiques, et elles s'attaquent à chacune dans un délai spécifique, appelé sprint.

La gestion de projet agile nécessite une équipe transverse et auto-organisée qui se compose généralement de cinq à neuf membres. Ensemble, ils développent un logiciel exploitable au cours de chaque sprint, qui se combine avec d’autres codes fonctionnels des itérations précédentes. À la fin du délai de sprint, l’équipe présente son travail aux parties prenantes pour obtenir des commentaires, leur permettant d’être flexibles dans leur approche du développement logiciel. Comme l’équipe a accès à des commentaires fréquents, elle peut adapter la feuille de route du produit pendant le cycle de développement pour s’assurer que la fonctionnalité répond vraiment aux attentes des utilisateurs. Dans une approche en cascade, l’implication du client coïncide généralement avec la livraison du produit final, ce qui peut s’avérer coûteux lorsque les exigences sont mal interprétées ou mal documentées.

17 personnes ont estimé que le système de gestion de projet en cascade était très inefficace, et en 2001, leurs idées sur le processus de développement de logiciels ont abouti à un travail connu sous le nom de «Agile Agile Manifesto ». Ce document met en évidence des valeurs et des principes spécifiques à prioriser dans les flux de travail de développement logiciel, et il a donné un certain nombre de cadres des exigences Agile populaires, tels que Scrum, Kanban, Développement piloté par fonctionnalité (FDD) et Programmation extrême. Depuis, le développement logiciel agile a gagné en popularité, surtout lorsqu’il est comparé au modèle en cascade.

Inspiré par le rugby, l'Agile met l’accent sur le travail d’équipe pour répondre aux livrables, de la même manière que les attaquants doivent collaborer dans le cadre d’une mêlée pour prendre possession d’un balle de rugby. Les compétences de l’équipe Agile Scrum varient, mais elles comprennent généralement les rôles suivants :

• Propriétaire du produit : ce membre de l'équipe représente les besoins du client et de l'entreprise. En rédigeant des scénarios utilisateur, l’équipe peut comprendre comment une demande de fonctionnalité peut aider à résoudre un problème spécifique, et ces scénarios constituent le retard des tâches à accomplir pour l’équipe. Cette personne priorise également les stories en fonction de leur valeur pour le client, ce qui devrait, en théorie, se traduire par une valeur ajoutée pour l’entreprise. Bien que le Product Owner dirige l’équipe de cette manière, il ne fixe pas de délais ni n’instruit l’équipe sur la façon dont le travail doit être livré.
• Scrum master : ce membre de l’équipe facilite le processus global de développement agile. Comme un chef de projet, il permet à l’équipe de se concentrer sur ses tâches, veillant à ce qu’elle reste concentrée tout au long du projet. Il peut également agir comme une entité neutre pour arbitrer les désaccords entre les membres de l'équipe. Par exemple, les membres de l'équipe peuvent être en désaccord sur la quantité à accepter dans un sprint donné. Les propriétaires de produits, en particulier, peuvent faire pression sur les équipes pour qu'elles s'engagent à aller au-delà de ce qu'elles peuvent faire dans un délai donné. Dans ces cas, les scrum masters peuvent rappeler aux membres de l’équipe l’étendue de leur rôle au sein de l’équipe.

Les autres membres d'une équipe Agile peuvent varier, mais ils comprennent généralement des utilisateurs issus de diverses disciplines, telles que la conception, l’analytique, l’assurance qualité et le développement. Ensemble, ces personnes décident de la quantité de travail à entreprendre et de la manière dont elles vont l'achever.

Les méthodologies agiles dépendent également de la manière dont les équipes se réunissent. Des réunions spécifiques facilitent le workflow au sein de l’équipe. En voici quelques-uns :

• Planification du sprint  lors de cette réunion, l’équipe se réunit pour déterminer quelles histoires feront partie du sprint en cours. Le responsable produit donnera la priorité aux scénarios utilisateur, mais le reste de l’équipe devra se mettre d’accord sur le nombre de scénarios utilisateur à réaliser pendant cette période.
• Stand-up quotidien : ces brèves réunions sont également connues sous le nom de mêlées quotidiennes. Au cours de ces vérifications, chaque membre de l’équipe communique ses progrès individuels, tels que les tâches terminées, celles à venir et les bloqueurs ou dépendances qui peuvent entraîner des retards.
• Démo : cette réunion présente le logiciel fonctionnel que l’équipe a réalisé au cours du sprint, qui peut aller de deux à quatre semaines. Le propriétaire du produit déterminera si un témoignage utilisateur répond à la définition de « fait ». Si ce n’est pas le cas, le backlog produit peut être rationalisé pour tenir compte des éléments manquants. Ce fut également l’occasion pour l’équipe de s’adresser aux parties prenantes pour obtenir des commentaires.
• Rétrospective : ce temps est réservé à l'introspection de l'équipe, au cours de laquelle celle-ci détermine comment elle pourrait améliorer son workflow afin d'obtenir de meilleurs résultats à l'avenir

• La conception d'équipe favorise la collaboration.
• Le développement de produits adopte une approche de conception adaptative.
• Comme le code est testé à chaque itération dans la phase de développement, les défauts de code peuvent éclairer la conception future du logiciel.
• Tend à améliorer la satisfaction client, car les commentaires fréquents entraînent une priorisation accrue des besoins clients.
• Permet l’intégration continue, car chaque fonctionnalité constitue un logiciel en soi.
• Ce type de développement logiciel lean peut permettre de réduire les coûts, car il y a moins de risque de défaut d’alignement des clients et des produits.

• Une approche agile peut manquer de documentation complète. Il est donc difficile d’intégrer de nouveaux développeurs, de respecter les délais des projets pour les parties prenantes et de fournir des estimations de coûts précises.
• Peut être difficile à dimensionner.

Bien que les équipes de développement aient obtenu des résultats avec l’une ou l’autre approche de gestion de projet, les processus agiles sont certainement plus dynamiques. Il n'est pas difficile de comprendre pourquoi lorsque l'on observe les avantages qu'elle peut offrir aux entreprises d'aujourd'hui. Bien qu’un certain nombre d’outils de gestion de projet puissent aider les équipes à suivre l’avancement, IBM peut également fournir des systèmes permettant aux développeurs de coder de manière plus agile.