Un manifeste pour une nouvelle approche
Nous l’avons vu précédemment, les méthodologies dites “agiles” existaient déjà bien avant l’apparition d’Internet pour le grand public : les usines Toyota utilisaient déjà la méthode Kanban pour optimiser la production de voitures. Plus tard, lorsque les projets informatiques se sont densifiés et ont accumulé les ralentissements, certains gestionnaires de projets ont adapté des méthodes utilisées par l’industrie à leur secteur. D’autres ont inventé les leurs, mettant le produit et l’interaction avec le client au centre de la planification.
Des débats ont émergé sur la pertinence des méthodologies séquentielles, perçues comme lourdes et poussiéreuses, face à d’autres pratiques qui commençaient à émerger.
Ces discussions ont débouché sur la rédaction d’un document, le Manifeste Agile (Agile Manifesto), au début des années 2000. Il définit des valeurs et des principes partagés par tous les signataires et qui vont à l’encontre des méthodes séquentielles, alors utilisées dans tous les secteurs et reconnues comme étant les plus performantes. Il s’agissait d’une prise de position considérable !
Les valeurs
Les valeurs du manifeste sont les suivantes :
Les individus et leurs interactions sont plus importants que les processus et les outils,
Un logiciel qui fonctionne est mieux qu’une documentation exhaustive,
Collaborer avec les clients est préférable à la négociation contractuelle,
S’adapter au changement est mieux que de suivre un plan.
Puisque vous avez déjà un bon aperçu des méthodologies séquentielles, prenez une minute (ou plus…) pour relire les valeurs unes à unes et mesurer les changements que cela suppose.
Ces valeurs sont relativement théoriques, mais elles découlent sur des principes très pratiques dans la gestion d’un projet au quotidien.
Les principes
Le Manifeste comprend douze principes que je vous laisse lire tranquillement. Allez-y, ce n’est pas long ! 😉
Les pratiques
Les quatre valeurs et les douze principes sont partagés par toutes les pratiques Agiles. Pourquoi avoir plusieurs méthodologies ? Tout simplement car les projets et les équipes sont différents, il faut donc avoir une palette de méthodes qui puisse s’adapter à tous les cas.
Selon Claude Aubry, auteur du plus célèbre guide sur Scrum (dont nous parlerons plus tard), une pratique est “une approche concrète et éprouvée qui permet de résoudre un ou plusieurs problèmes courants ou d’améliorer la façon de travailler lors d’un développement. [...] La notion de pratique prend toute son importance avec l’utilisation des méthodes agiles. À côté des valeurs et des principes qui sont universels, les pratiques sont le reflet de la mise en oeuvre sur le terrain.”.
Il existe une soixantaine de pratiques au total. Voici celles qui sont les plus utilisées :
User stories
Pair Programming
Continuous integration (CI)
Acceptance Testing
Iteration Planning / Planning Game / Sprint Planning
Daily Stand-Up Meeting / Daily Scrum
Détaillons-les succinctement.
User stories
Une user story est une fonctionnalité écrite du point de vue de l’utilisateur et très succincte. Elle raconte ce que fera l’utilisateur dans notre programme sous forme d’histoire.
Pair Programming (programmation en binôme)
Un écran, un code, deux programmeurs. Le binôme se met d’accord sur une fonctionnalité à développer et le fait ensemble. Les avantages sont multiples : meilleur code, collaboration renforcée et communication facilitée.
Continuous Integration (intégration continue)
Cette pratique naît du principe “Livrer fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.”
Chaque fonctionnalité est intégrée à la précédente, ajoutée au programme en production, au lieu d’être développée dans son coin comme c’est le cas en séquentiel. Cela permet de toujours avoir un logiciel qui marche et de le voir se développer, ce qui motive l’équipe et les utilisateurs.
Acceptance testing (tests d’acceptation)
Avant de passer à la story suivante, quelqu’un doit valider que celle-ci est bien terminée. Mais comment faire ? En suivant les tests d’acceptation. Ces derniers donnent les conditions à réunir pour déclarer une story terminée.
Planning game
Chaque User Story correspond à une nouvelle étape de développement (nous reviendrons sur ce point plus tard). À la différence des méthodologies séquentielles, le planning des méthodologies agiles est flexible et redéfini à chaque nouvelle User Story. L’équipe se réunit et estime la durée de réalisation de chaque User Story. Évidemment, les premières estimations sont assez éloignées de la réalité mais plus l’équipe travaille ensemble plus leurs estimations s’affinent. Elles itèrent pour arriver, au bout de quelques mois, à des estimations très justes.
Daily stand-up meeting
L’équipe se réunit chaque jour et chaque membre présente, très rapidement, ce qu’il a fait la veille, ce qu’il fera aujourd’hui et un point bloquant. C’est l’occasion de partager son travail et de recevoir des retours de la part de ses collaborateurs. Pour éviter que cela ne dure plus de 30 minutes, tout le monde reste debout ! 👣
Les méthodes
Les pratiques sont regroupées en méthodes. Il en existe environ 8 que je vous laisse découvrir dans cet excellent article, les plus populaires étant :
Dynamic systems development methods (DSDM) : une approche incrémentale et itérative qui comprend une intégration constante des clients,
Feature Driven Development (FDD) : une méthodologie légère dont l’objectif est de créer un logiciel qui s’adapte efficacement aux changements de demandes,
Extreme Programming (XP) : une méthode très pragmatique et centrée sur les pratiques,
Scrum : la méthode agile la plus populaire et la plus largement utilisée. Il s’agit d’une stratégie de développement très flexible quand une équipe travaille ensemble pour atteindre un but commun. Nous la verrons plus en détail dans le prochain chapitre !
Mais avant, fêtons Noël sous le signe de l’agilité ! Uncle Bob (Robert Martin, un des signataires du Manifeste Agile) a créé en 2013 cette superbe vidéo qui reprend toutes ses pratiques. Enjoy !
