Les différentes méthodologies Agiles
Rappels
Institué par un principe simpliste : ne pas planifier l’entièreté du projet et laisser une place à l’intuitivité et à l’adaptation ; la méthodologie Agile recommande de ne se fixer que des objectifs à court (voire moyen) terme afin de pouvoir modifier et compléter les étapes et obtenir des livrables rapides. Le postulat est simple : il est impossible de tout prévoir, laissons donc une chance aux imprévus et au talent des développeurs pour s’adapter.
Si l’adaptabilité est un facteur essentiel à la réussite d’un projet sous l’égide de la philosophie Agile, il est important de constater l’apport élémentaire et absolu de la coordination entre client et chargé de projet. La satisfaction du product owner par la capacité des développeurs à améliorer le projet à chaque étape nécessite une implication totale de toutes les parties prenantes et la communication entre les différents acteurs prend alors son rôle premier : instituer un dialogue constructif.
Les avantages du mouvement et des méthodologies Agiles :
- Plus de flexibilité par la prise en compte des imprévus (retards, bugs, tests, changements d’idées, incompréhensions)
- La création d’une relation basée sur la confiance et non essentiellement sur un contrat.
- Une meilleure visibilité du client sur l’avancée du projet via les livrables rendus à court terme.
- Le contrôle des paramètres de création du projet (coûts, deadlines).
Les inconvénients du mouvement et des méthodologies Agiles :
Si un changement d’équipe est nécessaire, le fait d’avoir laissé une « trop » grande place au dialogue pourrait être un frein à la reprise du projet par une autre équipe. Cette dernière se retrouverait en manque d’information par suite du trop peu de documentation parallèle rédigée lors de la construction de ce même projet.
Aux vues de l’obligation d’une collaboration étroite entre décideur et exécuteur, les sociétés à forte hiérarchisation des tâches risquent de ne pouvoir s’adapter au moule des méthodologies Agiles.
L’obligation d’implication de toutes les parties prenantes. Intimement lié à la notion de hiérarchie et de disponibilité, il n’est pas rare que les dirigeants n’aient pas envie de s’impliquer sur ce qu’ils considèrent comme une tâche qui n’est pas de leur ressort.
Peu de vision à long terme. Cela peut poser en cas de budget serré puisque, si les coûts d’adaptation sont facilement identifiables grâce aux livrables rendus en délais courts, ce n’est pas le cas pour la globalité du projet. La flexibilité peut rendre un projet plus rentable mais peut aussi revenir très chère.
Retrouvez en détail les 8 méthodes Agiles les plus populaires.
eXtreme Programming (XP)
Objectif principal : réduire les coûts des modifications intempestives et des réparations de bugs.
Conçue par Kent Beck afin d’accélérer les développements des logiciels de la société Chrysler, elle a pour vocation la production d’un code aisément lisible et peu coûteux. Via l’utilisation de binôme, les chargés de projet (développeurs entre autres) effectuent des analyses poussées via des revues de code, du refactoring, des tests automatiques après chaque développement et une vulgarisation complète afin de faciliter les échanges avec la hiérarchie (porteur de projet).
Cette méthodologie se retrouve souvent complété par Scrum qui lui apporte une base temporelle viable.
Crystal
Objectif principal : Offrir des livrables rapidement afin que les utilisateurs puissent effectuer des tests ‘en surface’.
Imaginé par Alistair Cockburn, la méthode Crystal Clear n’est que peu usitée en France à cause de son manque de visibilité structurelle. Elle est composée de trois composantes primaires : le cycle de livraison, l’affrètement et la fin du projet. Spécifiquement adaptée aux petites équipes de développement (1 architecte et 2 à 6 développeurs), Crystal Clear impose une communication intime entre les participants. Les informations sont généralement disposées sur un paperboard à la vue de tous. Les livrables doivent être rendus toutes les deux semaines (1 mois max) et la tâche la plus importante demandée aux développeurs est la remise en question constante et la vérification incessante des process.
Rational/Agile Unified Process (RUP)
Objectif principal : apporter une réponse rapide aux besoins des users dans le cadre défini par le budget alloué. Par principe, elle est l’une des méthodologies les plus sécurisante puisqu’elle tend à modéliser les différentes étapes du développement d’un logiciel.
Cette méthode est divisée en quatre phases :
- Lancement / Création: évaluation des risques et planification
- Conception / Élaboration: définition de l’architecture système et pertinence
- Réalisation / Construction: production logiciel et documentation supporter plus phases tests
- Livraison / Transition: test du système et correction avant déploiement final
Le problème principal de cette méthode reste son coût d’investissement initial qui pousse les entreprises à ne l’utiliser qu’en cas de projet conséquent.
Test Driven Developement
Objectif principal : simplifier au maximum le code grâce à des tests préventifs.
En associant l’écriture de tests unitaires à la programmation et au remaniement du code, le TDD permet de simplifier le code source au maximum. Pour ce faire, les tests unitaires sont rédigés avant le code et basés sur CHACUN des éléments de la fonctionnalité.
Attention : le TDD doit être associé de façon automatique au langage de programmation usitée.
Behavior Driven Development (BDD)
Objectif final : réalisation de tests en vue de décrire le comportement attendu du système de façon compréhensible par toutes les parties prenantes.
Contrairement à de nombreuses autres méthodes présentes dans cette liste, l’intérêt du BDD n’est nullement d’expliquer les solutions techniques à apporter mais à comprendre l’enjeu des fonctionnalités destinées à l’UX. Ainsi, les ‘utilisateurs’ ont une place plus que prépondérante dans la compréhension des enjeux front. Les scénarios de tests sont donc co-écrits par les développeurs et les Product Owners.
Domaine Driven Design
Terme et concept introduit par Eric Evans, le Domain-Driven Design (conception pilotée par domaine en français) introduit le fait que la réalisation d’un logiciel ne peut dépendre que d’une parfaite coordination entre équipe technique et demandeur. En somme, c’est l’apparition d’un écosystème sociotechnique qui va permettre d’obtenir des résultats concrets et des livrables correspondant à la fois aux besoins client et serveur.
Les principes fondamentaux sur lesquels se base le Domain-Driven Design sont :
- Nous aider à comprendre la façon dont la loi de Conway se matérialise dans le processus de développement logiciel.
- Fournir des stratégies pour exploiter la loi de Conway afin d’obtenir de meilleurs résultats.
- Introduire des modèles éprouvés et reproductibles pour la modélisation de la logique métier complexe dans les logiciels.
Disciplined Agile Delivery
Objectif principal : Simplifier l’implémentation des processus liés à la gestion d’un projet incrémentale et itérative.
Afin d’en tirer le meilleur, cette technique doit être associée à des méthodes telles que Scrum ou Lean. En ce sens, elle est une méthode hybride principalement destinée à intégrer les méthodes Agiles au cœur d’une institution ou d’un projet.
Adaptative Software Development
Objectif principal : L’une des seules méthodes indépendantes de toute méthodologie ou langage de programmation, l’ASD vise avant toute chose à permettre aux équipes techniques de s’adapter au plus rapide aux exigences évolutives du marché.
Afin de déterminer les problématiques du marché et des demandes diverses du demandeur, l’ADS sert aux développeurs à faire évoluer le produit via une planification la plus légère possible et une formation continue.
Pour en arriver à un résultat probant, les équipes (en corrélation) doivent se développer selon trois phases : spéculation, collaboration, apprentissage. Il est même possible d’y apporter un quatrième socle, à savoir : modification des processus inhérents au projet.