BodySplash.fr

Au détour d'une conversation, un collègue nous a dit qu'il trouvait que Maven n'était pas un outil agile. Je dois avouer que je suis de plus en plus en grand suppprter de maven donc, forcément j'ai été choqué.

La raison évoquée était que quand on veut changer le comportement de base de maven, on rencontre beaucoup trop de résistance. Que ce besoin soit légitime ou pas, le fait est qu'effectivement maven était un frein dans ce cas. Mais l'agilité n'est pas une question d'outil. L'agilité est une question de s'améliorer et de réduires les résistences. Il n'y a pas d'outil magique, de balle d'argent, qui va permettre d'être agile du jour au lendemain. Dans notre cas, Maven a réduit la friction du processus de compilation et de déploiement, tout en nous permettant de gérer de manière plus saine nos dépendances. En gros, ça a été un franc succès, mais seulement je pense car nous avions expérimenté les limites d'Ant. Le grand intérêt de Maven, c'est justement ses conventions qui permettent de s'abstraire de beaucoup de la verbosité d'ant, pour ne parler que de la compilation. Enfin, il ne faut jamais oublier que tenter de tordre un outil ou d'essayer de l'utiliser dans une optique qui n'était pas la sienne n'est jamais une bonne idée.

Cette conclusion est assez conventionnelle, et on peut la lire finalement dans n'importe quel bon article sur l'agilité, mais il est, je trouve, toujours intéressant d'arriver par soit même aux mêmes conclusions.

J'aimerai aborder le sujet de scrum vs XP ici.

Je me bats contre cette vieille légende qui veut que Scrum couvre la gestion de projet, et XP le développement. Alors oui, Scrum ne couvre que la gestion de projet, mais XP couvre tout. Oui, oui, oui et encore oui, XP parle de gestion de projet, la preuve en image là ou là

Scrum je trouve, favorise cette vieille séparation développement/gestion tout en ignorant royalement l'importance de la mise en place de bonnes pratiques. Il se trouve qu'actuellement, je n'ai effectivement pas croisé d'environnement ou Scrum avait était mis en place seul, sans les pratiques issues d'XP pour le développement. Mais dans un futur pas si lointain que ça, quand l'agilité aura été reprise et vendue par des commerciaux ne voyant là qu'une offre de plus, je crains fort que l'importance de cet équilibre ne passe à la trappe. C'est pour cette même raison que le débat existe sur la certification Scrum.

XP est un tout cohérent, convaincu de la nécessité de ne rien délaisser: ni la gestion, ni le développement. De fait, XP me paraît plus agile que ne l'est Scrum. Dans le contexte ou il est encore difficile de vendre l'agilité, certains disent donc que mieux vaut vendre Scrum, la méthode fait moins peur. L'agilité était avant tout un changement radical de la manière d'envisager notre métier, et un ensemble de valeurs fortes, continuer à nourrir les fausses croyances me semble préjudiciable.

Ce que j'ai pu modestement observer jusque là, c'est qu'une adoption complète d' XP donne d'excellents résultats à tous les niveaux: qualité du projet, humeur et efficacité de l'équipe, sérénité globale etc etc; Une adoption par compromis ne donne qu'un sentiment mitigé chez tous les acteurs du projet, qui se demandent alors ou est ce fameux gain tant promis par l'agilité, car la différence n'est du coup, pas vraiment bluffante. La puissance d'XP est dans la synergie de TOUTE ses pratiques.

Pour conclure, ce qui m'attriste le plus dans cette histoire, c'est que nous devrions normalement nous concentrer à essayer de nous améliorer, plutôt que de juger de qui est le plus agile. Cependant, il me semble que ce grand virage vers l'agilité ne peut être entrepris par quelqu'un que s'il a toutes les cartes en main.