Salut et bienvenue dans ce nouvel épisode de Code Garage.
Je m'appelle Nicolas Brondin-Bernard et aujourd'hui on va parler de la méthodologie agile.
Alors quand on entend parler du mot agile, on peut penser à la méthode Scrum.
Des fois, il y a des gens qui pensent à l'extrême programming, on peut penser à l'artisanalogiciel.
Et certains et certaines pensent que ça se résume simplement à être capable de s'adapter
rapidement au changement d'un projet.
Mais en réalité, c'est quoi exactement la méthodologie agile ?
Alors d'abord, on parle bien de la méthodologie et non pas de méthode agile.
Parce qu'en fait, la méthode agile n'existe pas.
Alors ça peut vous surprendre, mais c'est la stricte vérité parce qu'il n'existe pas,
pardon, une méthode agile au sens propre.
Mais il existe une méthodologie.
Donc la nuance apparaît mince, mais elle est très importante.
Une méthode, c'est une manière de faire quelque chose.
La méthodologie, c'est l'étude de toutes ces méthodes.
Donc il faut voir la méthodologie agile comme un ensemble de valeurs, de règles que peuvent
choisir ou non une équipe projet et qui vont découler certaines méthodes.
Alors la preuve, on va dire, la plus imparable du fait que la méthode agile, ça n'existe pas,
c'est qu'il existe de nombreuses méthodes de développement que l'on qualifie d'agile.
Mais qui existaient avant la méthodologie agile.
On peut par exemple citer Scrum, Extreme Programming, RAD, Rapid Application Development,
ASD, Adaptative Software Development, etc.
Etc.
En fait, c'est en 2001 que 17 experts du développement logiciel,
dont certains créateurs des méthodes, justement, que j'ai cités, se réunissent pour trouver
un thème qui unifierait toutes leurs méthodes sous des valeurs communes.
Et c'est à ce moment-là que sera rédigé le manifeste agile.
C'est quoi le manifeste agile ? C'est un manifeste, c'est un texte qui résume les valeurs tirées
de ces méthodes de développement d'application et dont le but est de faire un pas de côté
par rapport aux anciennes méthodes de conception qu'on appelle des méthodes de conception en cascades,
Waterfall en anglais, qui viennent tout simplement à essayer d'estimer un projet
et de le faire par itération, mais toujours travaillé, on va dire justement en cascades.
La méthodologie agile, elle a quatre points qui sont quatre piliers, on va dire.
Et ces quatre piliers, ils se résument comme ça.
Les individus et leurs interactions avant les processus et les outils.
Les individus et leurs interactions sont plus importants.
Des logiciels opérationnels plus qu'une documentation exhaustive,
parce qu'effectivement, si vous avez une documentation qui ne fonctionne pas,
enfin, si vous avez, pardon, un logiciel qui ne fonctionne pas,
ça sert à rien d'avoir une documentation complète dessus sur un logiciel qui ne fonctionne pas.
La collaboration avec les clients plutôt que la négociation contractuelle.
La collaboration que ce soit au sein des équipes ou avec les clients
est vraiment un pilier central.
Et l'adaptation aux changements, plutôt que le suivi d'un plan
qu'on penseraient réfléchir hyper bien cadrer, mais qui au final va évoluer,
d'où le concept d'agilité qu'on entend très souvent.
Donc en fait, peu importe le nom de votre méthode de travail et de l'organisation de votre équipe,
si les valeurs que j'ai citées juste avant sont respectées,
en fait, vous travaillez avec une méthode qu'on peut qualifier de agile.
Alors si les valeurs que j'ai citées, elles sont un peu trop floues pour vous,
je vous conseille d'aller consulter les 12 principes qui accompagnent le manifeste agile
et qui décrivent la méthodologie dans des termes et des situations plus concrètes,
donc directement sur le site du officiel du manifeste.
Je vous mets le lien évidemment dans les notes de l'épisode.
Alors si on parle de pratique agile, on va en lister quelques-unes,
parce que le nom de toutes les différentes méthodes agile sont en fait une façade,
on va dire, pour une réalité dans le quotidien des développeurs et des développeuses.
C'est un ensemble de pratiques qu'on va mettre en place et qu'on va utiliser au jour le jour.
Donc parmi toutes ces pratiques, il y en a certaines qui prennent leur source
directement dans les valeurs de la méthodologie agile, le programming notamment,
dont j'ai fait un épisode que vous pouvez écouter.
On a aussi l'utilisation des user stories ou des récits utilisateurs.
On a l'intégration continue, le TDD, le Test Driven Development, le DDD,
le Domain Driven Development qui sont...
On pourrait croire que comme il y a Driven Development,
on pourrait croire que les deux sont antinomiques,
mais en fait, non, on peut les utiliser les unes avec les autres.
Le refactoring, ok, retravailler en gros la lisibilité et la performance du code,
et il y en a évidemment énormément d'autres.
Si jamais vous avez envie de découvrir l'ensemble de ces pratiques,
eh ben, je vous invite à découvrir chacune des méthodes dites agile
et donc de découvrir tous les principes et les pratiques qui sont mises en place dans ces méthodes-là.
Si vous avez deux choses à retenir,
c'est que l'agile, c'est une méthodologie, c'est un ensemble de valeurs extraites
de plusieurs méthodes de programmation d'applications déjà existantes
et mises sous une bannière, pardon, commune.
Et le plus important, c'est pas simplement de dire qu'on fait de l'agile,
mais de respecter les principes et les pratiques qui composent cette méthodologie au quotidien.
Voilà, j'espère que le concept de l'agile est plus clair pour vous.
J'espère que cet épisode vous aura été utile.
Et moi, je vous dis à la semaine prochaine pour un prochain épisode.
Salut !