Jeremi, notre stagiaire sur les Applications XWiki et Google SummerOfCodiste (cad qu'il a passé une selection drastique) sur OXYD chez Codehaus avec comme mentor Vincent Massol, trouve encore le temps pour relooker son blog (joli) et pour nous parler de son utilisation des méthodes agiles sur XWiki et OXYD.
J'aime beaucoup son article car c'est un bon résumé de la façon dont on procède sur les projets Open-Source et en particulier sur XWiki. Chez NetValue, cela faisait longtemps qu'on regardait de prêt les méthodes agiles en ayant pas mal de difficulté pour migrer nos projets sur ces méthodes. Quand j'ai démarré XWiki, d'entré j'ai commencé avec le développement dirigé par les tests (TDD ou Test-Driven-Development). Je dois dire que cela m'a rendu plus d'une fois des services et aujourd'hui que de nouveaux developpeurs arrivent sur le projet, il beaucoup plus facile de les faire rentrer sur le projet. Les tests sont en effet le meilleur endroit pour comprendre ce que le code d'un logiciel complexe fait.
Dans la méthode XP, ce que je trouve le plus intéressant dans l'utilisation des tests, est la règle qui consiste à "faire le developpement le plus simple qui répond aux tests et rien de plus". Souvent, comme les tests sont simples et ne prennent pas en compte tous les cas, le developpement le plus simple est en réalité "faux" ! C'est justement ainsi qu'on sait que les tests n'ont pas une couverture suffisante et qu'il faut les améliorer. La méthode est très incrémentale ce qui en fait une bonne méthode pour l'apprentissage.
L'Open-Source est un gros utilisateur des méthodes agiles et en particulier des tests. Il y a une raison très simple à cela. Sans les tests, la réutilisation de code Open-Source par des developpeurs qui n'ont pas participé au developpement est casiment impossible, en tout cas sans casser l'usage précédent qui était fait du logiciel. Les tests sont le moyen de permettre la distribution du developpement et l'amélioration du logiciel tout en respectant l'usage fait par les premiers utilisateurs. C'est un élément essentiel de la gestion de la qualité et de la pérénité des logiciels Open Source.
Tout bon developpeur saura que la qualité d'un logiciel ne se mesure pas uniquement au nombre des bugs à un moment donné, mais aussi dans une mesure très important à sa résistance aux modifications. La resistance aux modifications, c'est la capacité du logiciel à subir des modifications pour faire de nouvelles choses sans remettre en cause fondamentallement l'architecture ni introduire des tonnes de bogues.
Cette qualité est non-mesurable par un utilisateur du logiciel qui ne comparerait que l'utilisation réelle du logiciel à un moment donné. Elle n'est mesurable que par les developpeurs et les chefs de projets.
Souvent les startups qui se lancent font la course à la fonctionnalité au détriment de la qualité et comme leurs developpements sont fermés on ne connait pas la qualité réelle de leur travail. Avec l'Open Source c'est très différent, comme on peut voir non seulement le code mais aussi les méthodes de travail des équipes, on peut juger beaucoup plus facilement de la qualité du logiciel.
Et d'ailleurs c'est le cas, dans le monde Open Source, et en particulier dans le monde Java, les developpeurs et utilisateurs se ralient autour des logiciels qui ont un processus de developpement à l'état de l'art ! Et l'état de l'art dans l'Open-Source, ce sont les méthodes Agiles et le developpement dirigé par les tests.
Je doute que se soit le cas de beaucoup de boîtes au code fermé ! Et en tant qu'utilisateurs, il faut exiger des entreprises qu'elles ouvrent le capot et montrent comment elle developpent, de la même façon que les projets Open-Source le font.
