Une critique du manifeste Agile. (2/3)

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

Comme promis, on se retrouve aujourd'hui pour la suite de ma critique sur le manifeste Agile, le recueil officiel des principes et valeurs fondamentales de la méthodologie.

Pour rappel, la dernière fois nous avions analysé les 3 premiers principes et conclu les choses suivantes :

1. Satisfaction du client : connaitre son besoin profond en apprenant son domaine métier afin de mieux pouvoir se mettre dans sa peau.
2. Acceptation des changements :
   • Concevoir une codebase flexible grâce aux 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 la valeur ajoutée dès qu'elle est prête tout en tenant le client informé de l'avancement, via une démo, des vidéos ou des présentations.

Sans plus tarder, place à la suite !

Analyse du manifeste Agile

4. Collaboration avec le client

Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
- Manifeste Agile

On commence sur une bonne note, car je suis effectivement d'abord avec ce principe, bien qu'il soit, comme les autres, assez vague.

Ici, travailler ensemble signifie principalement deux choses :

• Demander des retours du client sur le travail accompli, dans un but d'évolution continue du logiciel.
• S'entretenir avec lui afin de comprendre son métier, et ainsi pouvoir toucher son besoin au plus profond (principe n°1).

Après, il existe des situations où collaborer avec le client peut être compliqué, typiquement quand il n'est pas vraiment présent…

C'est notamment le cas si vous travaillez sur une application destinée au grand public ou à un marché cible. Obtenir des retours est un des plus grands défis, et demandes des moyens plus sophistiqués, telles que :

• Collecter des données d'utilisation, afin d'obtenir son retour d'expérience en temps réel sans même le déranger.
• Construire une communauté qui s'engage où les utilisateurs font spontanément des demandes d'amélioration et signalement de bug, et sont plus à même de répondre aux sondages. C'est souvent le cas dans les projets open source.
• Être soi-même un représentant des utilisateurs, car après tout, c'est la meilleure manière d'identifier le besoin !

5. Équipe motivée

Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
- Manifeste Agile

Bien que je sois d'accord avec la deuxième partie, elle découle forcément de la première, car vous n'allez pas accorder votre confiance à une personne qui se fout royalement du projet.

Mais le problème avec la première partie, c'est qu'elle dépend beaucoup trop de facteurs dont nous, en tant que développeurs, n'avons pas le contrôle.

Si une cause extérieure démotive l'équipe, c'est assez compliqué de prendre des mesures pour empêcher cela, soit même.

La seule solution est d'aller négocier avec les personnes qui ont les moyens de résoudre les causes de démotivation.

Par exemple, si le passage en télétravail durant la crise de la COVID a démoralisé toute l'équipe, la solution est d'aller négocier avec la direction et trouver un compromis pour faire revenir l'équipe en présentiel tout en garantissant la santé du personnel (gestes barrières, port du masque, aération de la salle…)

Plus facile à dire qu'à faire, car ça demande de fortes capacités de communication, persuasion, négociation et leadership.

Mais dites-vous qu'au sein d'une équipe, ceux qui ont le courage de se confronter à la direction ou au client pour la prospérité d'une équipe sont extrêmement bien vus.

Après, il y a des situations où il n'y a rien d'autre à faire que d'accepter. Typiquement, si le client se fait racheter, et que la nouvelle politique le force à se retirer du projet, c'est très douloureux, mais il faut accepter et passer à autre chose.

Ma question est donc : comment respecter ce principe dans ces coups de temps là ? Vous avez 4 heures.

6. Dialogue en face à face

La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
- Manifeste Agile

Il s'agit surement du pire principe de ce manifeste, car c'est tout simplement faux. Le dialogue en face à face est peut-être la méthode de communication la plus simple, mais ce n'est certainement pas la plus efficace.

Ça s'explique par le fait que les paroles sont éphémères. Elles peuvent être oubliées, déformées (téléphone arabe), voire manipulées à des fins malhonnêtes (détournement cognitif).

Il est malheureusement très fréquent qu'un développeur essaye de faire croire à son chef ou au client qu'une exigence ne lui a pas été transmise, juste parce qu'il n'assume pas de ne pas avoir fait son travail. Et ça marche aussi dans l'autre sens.

Bien au contraire, il faut impérativement mettre en place des mesures afin de faire persister l'information. En voici quelques-unes :

• Un cahier des charges pour donner la direction globale du projet et les grandes fonctionnalités.
• Un backlog pour répertorier toutes les tâches et les exigences.
• Des conversations enregistrées avec le client ainsi que des notes partagées que tout le monde peut consulter.
• Des comptes rendus de réunion avec les parties prenantes.
• De la documentation et des diagrammes sur le domaine métier.

• Un chat textuel ouvert pour les annonces et les discutions concernant les exigences.
• Des commentaires de code avec une documentation automatique.
• Un wiki pour le partage de connaissances.
• Des spécifications et contrats d'API pour guider le développement.

Pour preuve, regardez simplement les projets open source. Ils ne fonctionnent définitivement pas sur du dialogue en face à face, mais ça ne les empêche pas d'être agiles.

7. Mesure d'avancement

Un logiciel opérationnel est la principale mesure d’avancement.
- Manifeste Agile

J'ai vraiment beaucoup de mal avec ce principe, aussi simple soit-il.

Déjà, la terminologie est vraiment mal choisie. Un logiciel opérationnel n'est pas une mesure, mais un objectif. Le mot opérationnel lui-même ne désigne pas une mesure, mais un statut. Le logiciel est opérationnel ou ne l'est pas.

Et même avec ça, ce principe est toujours faux, car ça voudrait dire qu'à partir du moment où le logiciel devient opérationnel, alors l'objectif a été atteint, donc on peut clôturer le projet.

Or, comme j'ai expliqué dans le principe n°3, l'opérationnalité ne prouve rien. Ce qui compte, c'est sa valeur ajoutée.

Bon, dans ce cas, on a juste à dire que la valeur ajoutée d'un logiciel est la principale mesure d'avancement, et c'est réglé !

Ouais… Bof.

Il faut savoir qu'il est extrêmement difficile de mesurer la valeur ajoutée d'un logiciel. C'est possible en faisant une étude de retour sur investissement, mais c'est très long et compliqué. Généralement, on ne fait ça qu'une fois le projet terminé pour savoir si les résultats correspondent bien aux attentes, et non pas pour savoir où on en est.

Alors, comment mesure-t-on l'avancement ? Prenons un peu de recul pour répondre à une autre question : pourquoi mesure-t-on l'avancement ?

Après tout, l'équipe sait forcement à peu près où elle en est, et de même pour le client puisqu'elle est en étroite collaboration avec lui.

Il n'y a que deux entités qui sont vraiment intéressées par ces mesures :

• La direction, pour savoir si l'équipe travaille correctement, et prendre des mesures si ce n'est pas le cas.
• Les parties prenantes côté client, pour savoir s'ils doivent se retirer ou non.

Bref, la raison pour laquelle on mesure rigoureusement l'avancement d'un projet, c'est principalement pour donner une justification du travail accompli.

Donc le meilleur moyen de faire ça, c'est de comparer ce qui a été réalisé par rapport à ce qui a été prévu grâce à :

• La progression dans le cahier des charges, qui donne un sentiment d'avancement général sur le projet. Par exemple : 2 fonctionnalités terminées, 1 en tests et 2 en attente donnent ~55% d'accomplissement.
• La liste des exigences accomplies (backlog), pour montrer la quantité de travail qui a déjà été réalisée. C'est particulièrement pertinent lorsque l'équipe bloque sur une fonctionnalité et que le cahier des charges n'avance plus, pour montrer qu'elle ne se tourne pas les pouces.

8. Rythme soutenable

Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
- Manifeste Agile

Comme pour le principe n°5, ça dépend encore de choses qu'on ne maitrise pas forcément.

Typiquement, s'il y a une crise en production, on ne pas dire aux développeurs de garder un rythme normal pendant que des millions fondent comme neige au soleil.

C'est ce que je regrette avec ce manifeste, il suffit d'une petite brise de printemps pour que la plupart des principes s'effondrent.

De même, il faut compter sur le bon sens et l'honnêteté des parties prenantes pour que ce principe fonctionne correctement, ce qui n'est pas gagné. Quand j'ai vu qu'Orange faisait la promotion d'Agile, j'ai vraiment rigolé.

De la même manière que le principe n°2, il faut serrer la vis avec les parties prenantes. Il faut qu'ils comprennent que restreindre à mort les délais risque de planter le projet pour de bon.

Une équipe avec une pression de malade est une équipe qui va sauter tous les processus qualité : tests, réusinage, intégration continue… Et livrer du code de merde qui partira à la poubelle au bout d'un an.

Mais encore faut-il leur faire comprendre !

Mon conseil pour une négociation réussie, c'est de mettre l'accent ce qui LES concerne (la qualité du produit final) et de leur faire comprendre qu'on fait ça dans LEUR intérêt, quitte à leur donner la chair de poule.

Voici une anecdote, un de mes anciens collègues travaillait sur un appareil de manufacture. Le projet peinait et n'allait certainement pas être livré à temps.

Le chef de projet est venu le voir en lui sous-entendant qu'il allait devoir sauter quelques tests s'il voulait être dans les clous, ce à quoi mon collègue a répondu « et qu'est-ce qu'on fait si l'appareil tue quelqu'un ? ».

Quelques heures plus tard, le chef de projet appelait le client pour le prévenir du retard. Le client était furieux, bien sûr, mais on est potentiellement passé à côté d'une catastrophe.

Mais bien sûr, il faut que ce soit donnant-donnant. Si les développeurs ont mis le chantier en production, ils doivent agir quoiqu'il en coute.

Assumer ses erreurs, c'est la base du professionnalisme.

9. Excellence technique

Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.
- Manifeste Agile

Alors là, on est plus dans le vague, on est dans le tsunami !

Excellence technique et bonne conception sont des termes tellement larges que je ne sais même pas par où commencer. Donc voici en vrac quelques pistes d'apprentissage :

• Flexibilité : prévoir les changements.
  • Principes SOLID
  • Patrons de conception
  • Programmation modulaire
  • Architecture en couches
  • Clean Architecture
• Robustesse : empêcher la dette technique.
  • Encapsulation
  • Contrainte d'intégrité
  • Immuabilité et programmation fonctionnelle
• Maintenabilité : faciliter l'évolution et la correction.
  • Nommage des modules
  • Code léger
  • Cohérence de code
  • Commentaires de code
• Qualité : empêcher les erreurs.
  • Tests automatiques
  • Développement piloté par les tests
  • Revues de code
  • Réusinage
  • Programmation par paires

Plus que le manifeste, je vous invite fortement à lire les livres de ses auteurs qui regorgent de détails et de mises en pratique (pour une fois !).

Mais il faut aussi que les autres développeurs puissent suivre la cadence. C'est pour ça que toute équipe doit avoir une culture du partage de connaissances. Voici quelques pistes de réflexion :

• Avoir des Sages au sein de l'équipe qui servent de mentors à ceux qui manquent d'expérience.
• Programmer par paires en couplant des développeurs séniors et juniors, même si ce n'est que pour quelques semaines.
• Avoir un leader extrêmement expérimenté qui sert de modèle aux autres développeurs, et qui les guides à travers les décisions techniques les plus complexes.
• Faire des revues de code en groupe, car elles génèrent toujours des discussions techniques très instructives pour tout le monde.
• Consommer les mêmes ressources, livres, articles ou formations afin d'avoir une équipe qui évolue ensemble.

10. Diminution du travail inutile

La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
- Manifeste Agile

Contre toute attente, j'aime bien ce principe, car contrairement aux autres, il définit le terme principal dont il parle.

Ce principe n'est pas nouveau, et s'incorpore dans une démarche plus globale de diminution du gâchis, qui va bien au-delà du domaine de l'informatique.

Dans la pratique, on minimise le travail inutile en :

• Utilisant des composants réutilisables, tels que des bibliothèques. Qu'ils s'agissent de modules faits maisons, open source ou payants, l'important est de ne jamais coder 40 fois la même chose.
• Clarifiant le cahier des charges et le domaine métier, de sorte à ne pas produire un dur labeur qui sera effacé au premier changement d'exigence.
• Ayant une bonne communication au sein de l'équipe, pour éviter les situations embarrassantes où deux personnes travaillent sur la même chose sans le savoir.

Mais encore une fois, il y a un gros souci de terminologie, car le mot simplicité ne signifie pas réellement ce que prétend le manifeste Agile. Le Larousse le définit de la manière suivante : caractère de ce qui est formé d'éléments peu nombreux et organisés de manière claire.

Hors la conception d'un logiciel n'est pas quelque chose de simple. Elle demande de l'étude, des connaissances techniques pointues (principe n°9) et beaucoup d'expérience.

En utilisant un mot comme simplicité, il y a un risque d'induire en erreur les gens et de les décourager à réfléchir à des architectures complexes, mais pertinentes dans leur contexte. C'est le même problème que j'ai avec le principe YAGNI.

Ça peut mener à de la sous-ingénierie, et causer des catastrophes le jour où les exigences changent (principe n°2).

Donc, diminuer le travail inutile ? Oui et encore oui. Mais ne vous privez d'une architecture complexe si elle correspond parfaitement aux besoins du client. Essayez plutôt de trouver des manières de la rendre intuitive et facile à utiliser !

11. Équipe autoorganisée

Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.
- Manifeste Agile

J'ai vraiment un problème avec le terme équipe autoorganisée. C'est un des concepts les plus infects du monde de l'entreprise moderne, même hors de la sphère Agile. Tout le monde parle de ses bénéfices, mais personne n'explique comment en créer une.

La vérité, c'est qu'encore une fois, ça dépend de choses dont on n'a pas la main. Une équipe ne peut pas choisir elle-même d'être autoorganisée. La seule entité qui le peut, c'est la direction.

Je ne vais pas m'y attarder, car je ne ferais que répéter mes arguments pour les principes n°5 et n°8, mais dites-vous que si vos supérieurs ne croient pas en la puissance des équipes autoorganisées, il sera très difficile de les convaincre (ce qui ne doit pas vous empêcher d'essayer).

Parce qu'au final, ce principe voit juste, les équipes autoorganisées sont réellement efficaces.

Après tout, qui d'autre connait mieux les objectifs du projet et le travail à réaliser que l'équipe elle-même ? Quand les décisions sont prises sur place, il y a tout de suite moins de friction et plus de pertinence, et donc plus de productivité.

Voici un conseil pratique pour ceux qui recherchent un poste de développeur.

Pendant votre entretien d'embauche, si la personne chargée de vous recruter est le chef de votre future équipe, et que vous pouvez discuter de tout ce que vous voulez avec lui, c'est très bon signe. Par contre, si l’on ne vous laisse pas adresser un mot aux développeurs, méfiez-vous !

12. Amélioration continue

À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.
- Manifeste Agile

On termine cette critique en bons termes, car je n'ai pas grand-chose à dire sur ce principe.

C'est de très loin le meilleur de ce manifeste. Il est clair, sans ambigüité, et c'est un très bon conseil.

De manière générale, la rétrospection est la meilleure manière d'apprendre et de progresser dans n'importe quel domaine.

Ça fonctionne très bien en équipe, en repassant en revue les problèmes rencontrés et en mettant en place des solutions pour les empêcher de réapparaitre, mais aussi à titre individuel avec des méthodes telles que la pratique délibérée.

Quels outils utiliser pour faire l'amélioration continue ? À vrai dire, on s'en fout un peu. Personnellement, je me contente d'un document markdown qui ressemble à ça.

L'avantage est qu'il me permet de savoir quel genre d'action prendre pour chaque point d'amélioration (agir, surveiller, éliminer…). De plus, une fois terminé, je n'ai qu'à le ranger à un endroit accessible par toute l'équipe afin d'historiser notre progression.

Voilà pour cette critique du manifeste Agile, une bonne chose de faite !

Jusqu’à maintenant, j'ai surtout parlé de la méthodologie principes par principe. Le but de la dernière partie sera de faire un bilan sur plus général sur le manifeste, afin de voir ce qu'il faut garder en tête pour avoir une démarche Agile sans foncer droit dans le mur.

Une fois de plus, j'invite mes lecteurs à laisser leurs commentaires, critiques et partages d'expériences ci-dessous. J'ai eu des retours très intéressants sur la partie précédente et je vous en remercie 😊

Merci d'avoir lu cet article jusqu'au bout. Surtout, pensez à le partager, car c'est le meilleur moyen de soutenir le blog 💙 et suivez-moi sur Twitter @ITExpertFr pour avoir la suite dès que c'est cuit !

Et pour ceux qui veulent plus de concret dans les pratiques Agiles, voici quelques articles qui devraient vous intéresser.

• Créer une application excellente : la méthode ultime.
• Comment instaurer des standards de code (sans se faire d'ennemis) ?
• Pourquoi toujours faire UNE SEULE chose ?

Quant à moi, je vous laisse, je pars manger des nouilles chinoises chez mon voisin italien, ne cherchez pas.

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