Une critique du manifeste Agile. (3/3)

Ceci est la suite de l’article Une critique du manifeste Agile. (2/3) que je vous recommande fortement d'avoir lu pour comprendre celui-ci.

Nous nous retrouvons comme promis pour la fin tant attendue de cette critique du manifeste Agile, le recueil officiel des valeurs et principes de la méthodologie.

Cet article servira de conclusion plus générale, et compilera tous les points mis en lumière dans les articles précédents.

Rappel des principes

Mais d'abord, pour ceux qui veulent se rafraichir la mémoire (ou qui ont eu la flemme de lire les deux autres articles ☹), voici un rappel des 12 principes et ce que j'en ai tiré.

1. Satisfaction du client : apprendre son domaine métier pour pouvoir mieux identifier ses besoins en se mettant dans sa peau.
2. Acceptation des changements :
   • Concevoir une codebase flexible en maitrisant les bonnes pratiques architecturales.
   • Entretenir une relation donnant-donnant avec le client où il comprend les conséquences de chaque changement d'exigence.
3. Cycles de développement : délivrer de la valeur ajoutée le plus tôt possible tout en tenant le client continuellement informé de l'avancement du projet.
4. Collaboration avec le client : apprendre son domaine et lui demander régulièrement des retours sur le travail effectué.
5. Équipe motivée : identifier les causes de démotivation et intervenir, ou négocier avec les personnes qui le peuvent (direction, parties prenantes…).
6. Dialogue en face à face : privilégier les moyens de faire persister l'information, surtout quand ça concerne les exigences.
7. Mesure d'avancement : établir un cahier des charges complet et garder une trace de toutes les exigences accomplies.
8. Rythme soutenable : négocier les délais avec les parties prenantes en argumentant que ce rythme est nécessaire pour garantir la qualité du produit.
9. Excellence technique : concevoir une codebase à la fois flexible, robuste, facilement maintenable et sans bugs.
10. Diminution du travail inutile : identifier les causes et les résoudre (composants non réutilisables, exigences vagues, manque de communication interne…).
11. Équipe autoorganisée : faire ses preuves auprès de la direction afin d'obtenir leur confiance.
12. Amélioration continue : faire régulièrement des rétrospectives du travail accompli, en identifiant des problèmes et en mettant en place des actions préventives.

Voilà littéralement ~4500 mots résumés en 259, ce qui est toujours plus que le manifeste 😜

Les problèmes du manifeste Agile

Ce qu'il faut d'abord comprendre, c'est que je n'ai rien à reprocher au concept d'Agile en tant que tel.

Comme je l'ai dit au début, le développement n'est pas fait pour une méthode en cascade classique, car les logiciels sont trop susceptibles de changer en cours de route. Si l'équipe projet veut vraiment satisfaire son client à 100%, il faut trouver un moyen d'être plus flexible.

Instaurer ce courant de pensée et le formaliser dans un manifeste était une excellente idée, mais c'est à la rédaction que tout a foiré. C'est comme avoir un super scénario avec des personnages incroyables et écrire un mauvais livre.

Il y a 5 gros problèmes assez liés qui, pour moi, ruinent complètement le manifeste Agile.

Trop de superficialité

Le manifeste expose des concepts extrêmement complexes, mais ne donne aucun détail sur leur signification dans le contexte d'Agile.

Prenez la satisfaction du client. Tel quel, ça ne veut rien dire du tout, on peut le satisfaire en résolvant son besoin, en lui obéissant au doigt et à l'œil ou lui glissant une boite de chocolats sous la table.

Avec des concepts aussi larges, on peut interpréter tout et n'importe quoi, et c'est pour ça qu'autant d'équipes Agiles foncent droit dans le mur. C'est à se demander si les auteurs eux-mêmes étaient sur la même longueur d'onde.

En détaillant plus ses principes, il aurait restreint ces concepts pour guider les développeurs vers une direction plus claire, tout en leur laissant la liberté de les appliquer comme ils veulent.

C'est d'autant plus rageant qu'Agile est à la base conçue pour du développement logiciel, mais le manifeste est si générique qu'il pourrait tout aussi bien s'appliquer au monde de la cuisine.

Pas de mise en application

Que le manifeste ne donne aucun outil concret pour appliquer sa méthodologie, soit, ce n'était pas le but.

Mais mettre les développeurs sur la piste pour l'appliquer n'aurait pas été de refus. C'est comme donner une liste d'ingrédients sans la recette.

Prenez l'amélioration continue, qui est pourtant mon principe favori. Le terme rétrospection n'est même pas évoqué alors que c'est la base de n'importe quelle méthode d'amélioration continue.

Donc finalement, si le manifeste ne fournit rien pour appliquer sa méthodologie, rien ne m'oblige à le connaitre pour m'en sortir vu que je n'aurais qu'à suivre une méthode plus concrète.

Manque de nuance

En plus de sa superficialité, le manifeste ne prend absolument pas en compte la complexité d'un projet informatique, et se contente d'avis tranchés comme un mauvais discours politique.

L'acceptation des changements est le pire. Combien de codebases ai-je vu partir à la poubelle au bout d'un an juste parce que les développeurs ont voulu appliquer ce principe à la lettre ?

Arrête un peu, si le manifeste avait tout nuancé, tu te serais plaint en disant qu'il ne sait pas où il va.

Oui, c'est vrai. Par contre, s'il avait pris le temps de détailler ses principes, en expliquant par exemple comment et dans quelles mesures il faut accepter les changements, alors je n'aurais rien eu à dire.

Ce n'est pas le cas, et je ne pense pas avoir loupé la deuxième page.

Trop idéaliste

La plupart des principes ne fonctionnent que dans des situations tellement fantaisistes qu'il est plus difficile de les atteindre que de respecter le principe en lui-même.

L'équipe motivée est le plus absurde. Super conseil, encore faut-il travailler avec les bonnes personnes, les bons clients, les bons managers, les bonnes circonstances socio-économiques… Bref, au moindre pépin, ce principe part en fumée.

En fait, le manifeste ne fait qu'expliquer comment bien agir dans des bonnes conditions, alors que la vraie difficulté est de pouvoir agir dans de mauvaises conditions, c’est-à-dire la quasi-totalité des projets qui ont besoin d'agilité.

Mauvaise terminologie

De tous les problèmes de ce manifeste, ce doit être le pire.

Utiliser des termes compréhensibles la règle d'or pour écrire des textes aussi importants. Pourtant, le manifeste Agile, malgré sa petite taille et ses 17 auteurs expérimentés, arrive à se planter sur quasiment tous les principes.

Dans le genre carrément ambigu, on a :

• Satisfait
• Fréquemment : à intervalle régulier ou non ?
• Opérationnel (un oscar pour celui-ci)
• Travailler ensemble
• Bonne conception
• Simplicité : expliqué dans le principe n°10, mais clairement inapproprié
• …

Et ce n'est pas un problème de traduction, les termes anglais sont tout aussi tordus.

Certains penseront que je racle le fond du bol, mais avoir des termes clairs est la seule manière de s'assurer que l'on parle bien de la même chose.

Faites l'expérience : demandez à tous les développeurs que vous connaissez si les itérations Agiles doivent être de taille fixe ou non. Personne n'est d'accord, et c'est impossible de le savoir en lisant le manifeste.

Avant d'écrire cette critique, je trouvais le manifeste médiocre tout au plus. Mais après avoir passé autant de temps à le décortiquer, mon opinion s'est vraiment noircie, car tout ce qui ne va pas avec le manifeste aurait pu être évité.

Au début, j'avais défini le manifeste Agile comme étant un guide pour accompagner les développeurs dans cette démarche, mais c'est faux.

C'est triste à dire, mais si vous ne faites que suivre ces principes sans rien d'autre, vous finirez inévitablement par faire du Dark Agile.

Comment être Agile ?

Mais au final, peut-être j'en attendais trop de ce manifeste.

Peut-être que son but n'est pas d'être suivi à la lettre, mais simplement de donner un cadre de réflexion par rapport aux projets informatiques. C'est une discussion dans les commentaires de mon premier article me l'a fait réaliser.

Voici une citation de l'Académie française en faveur de cet argument.

[…] rappelons que la méthode est une manière de conduire sa pensée […], alors que la méthodologie est, elle, l’étude des méthodes de recherche et d’analyse propres à une science, à une discipline.
- Académie française

Autrement dit, le manifeste étant le fondement de la méthodologie, son intérêt n'est pas d'être appliqué tel quel, mais de donner une ligne directrice à ses implémentations : les méthodes Agiles.

On peut facilement le comparer à la Déclaration des Droits de l'Homme et du Citoyen.

Prenons le premier article du texte :

Les hommes naissent et demeurent libres et égaux en droits. Les distinctions sociales ne peuvent être fondées que sur l'utilité commune.
- Déclaration des Droits de l'Homme et du Citoyen, 1789

Vous remarquerez qu'on retrouve à peu près les mêmes problèmes que dans le manifeste :

• Concepts complexes (égalité, liberté…), mais pas détaillés.
• Juridiquement inapplicable, car il ne donne pas les clefs pour comprendre quand il y a une atteinte à cet article.
• Termes confus (utilité commune, distinctions sociales, hommes…).

Effectivement, à titre individuel, cette déclaration ne sert à rien. Mais elle est la pierre angulaire d'autres textes, tels que la constitution française, qui, eux, sont applicables dans le monde juridique.

De la même manière, le manifeste ne sert qu'à guider les méthodes qui permettent d'appliquer ses principes en apportant un cadre bien défini avec des outils et des processus.

D'accord, donc si je comprends bien, je devrais suivre une méthode plutôt que le manifeste directement… Mais laquelle ?

Je vais devoir recourir à la réponse magique : ça dépend.

Quand on parle de méthodes de travail, quel que soit le domaine, on retrouve toujours deux grandes écoles :

Les conformistes

Ce sont ceux qui reprennent une méthode existante en l'adaptant à leur situation si besoin.

C'est de loin la solution la plus simple, car il n'y a rien à réinventer, et la plupart des méthodes ont déjà été testées et approuvées par d'autres équipes, mais elles sont difficiles à faire correspondre parfaitement à la situation.

Voici les plus connus, avec leurs grands points de différenciation :

• Extreme Programming (XP) : qualité du code.
• Crystal clear : collaboration interne.
• Scrum : traçabilité des exigences.

Ces méthodes sont généralement encrées dans la façon de faire d'une l'entreprise. Souvent, on vous le dira à l'entretien d'embauche, voir sur l'annonce de l'offre ce qui vous permet de savoir à quoi vous attendre.

Donc le meilleur moyen de tester ces méthodes, c'est de rejoindre une équipe qui les pratique déjà, car si vous voulez les instaurer vous-même… Bon courage, parce que ces méthodes sont assez lourdes et bousculent toujours les processus déjà en place.

Par exemple, si vous voulez que vos patrons embauchent un Scrum Master, ou que votre équipe passe à la programmation par pairs, vous allez avoir besoin d'une force de négociation à toute épreuve ! Mais qui ne tente rien n'a rien 😉

Les non-conformistes

Ce sont ceux qui créent leurs propres méthodes spécifiques au projet, en reprenant des éléments d'autres méthodes ou en en inventant de nouveaux.

C'est la solution la plus compliquée à implémenter, mais aussi la plus flexible, car quand elle est bien faite, elle s'adapte parfaitement au contexte.

C'est généralement ce que vous serez amené à faire si vous travaillez dans une équipe qui n'a aucune méthode et qui se contente de Code and Fix. En créant la vôtre, vous définissez votre niveau de souplesse et vous pouvez l'améliorer continuellement.

Mais créer une méthode n'est pas si simple, et vous risquez de faire pas mal d'erreurs, mais c'est comme ça qu'on s'améliore. Voici donc quelques conseils :

1. Apprenez énormément de processus et d'outils de travail en étudiant simplement les autres méthodes, Agiles ou non.
2. Définissez le cadre de votre méthode, c’est-à-dire les objectifs que vous voulez accomplir avec celle-ci (livrer le plus rapidement possible, faciliter la maintenance…). C'est justement le but du manifeste Agile, et malgré tout le mal que j'en pense, il peut être un bon point de départ.
3. Assemblez les outils qui soutiennent ce cadre.
4. Améliorez continuellement votre méthode en faisant une rétrospective des problèmes qu'elle n'a pas ou peu couverte, et en ajustant le tir.

Personnellement, je suis un grand fan de cette approche, et je pourrais consacrer un ou plusieurs articles à ce sujet !

Et pour ceux qui se demanderaient quelles techniques je conseille, je vous invite à relire cette critique depuis le début, en étant plus attentif cette fois-ci 😋

Voilà pour cette longue série sur le manifeste Agile. Finalement, outre mon grain de sel, il s'agissait plutôt d'un exutoire pour cracher une tonne de techniques et outils de gestion de projet que j'utilise au quotidien.

Et bien que je ne risque pas de reparler d'Agile de sitôt, je compte bien en détailler certains dans leurs propres articles, afin qu'ils puissent vous aider autant que moi !

Je tiens à remercier tous mes lecteurs, en particulier Frank Denniel pour sa force de débat, et sans qui cette partie aurait été un peu différente 😉

Pensez à partager ces articles pour générer des discussions autour de vous, car c'est comme ça qu'on fait bouger les choses, et suivez-moi sur Twitter @ITExpertFr pour vous tenir informé des nouvelles les plus croustillantes !

Et pour ceux qui ne se lassent pas de pratiques Agiles, voici quelques articles :

• Créer une application excellente : la méthode ultime.
• 12 types de développeurs ultra-efficaces.
• Obtenir un maximum de feedback utilisateur sans bavardage.

Quand à moi, je vous laisse, je vais donner à manger à mon éléphant de compagnie, ça fait un mois donc il doit avoir un peu faim.

À bientôt pour un nouvel article sur le blog des développeurs ultra-efficaces. Tchao !