Au commencement

Je vous invite à relire ces deux billets pour se remettre dans le bain: ici et là. Pour aller à l'essentiel, le but était de monter un projet d'envergure réelle pour affiner nos connaissances sur l'agilité, et de la méthode XP en particulier ainsi que son imbrication avec DDD. Le but n'était pas nécessairement lucratif dans un premier temps, mais vraiment d'avoir une assise suffisante pour parler d'agilité en général, avec l'idée de monter une association pour encadrer le tout.

Techniquement parlant, nous avions choisi Java comme langage, et niveau architecture, un assemblage maison de spring/hibernate conforme à l'idée que nous nous faisions de DDD et du "plus simple qui fonctionne". Comme organisation, nous avions XP comme base, sans jamais avoir touché à la plannification, et nous voulions toujours travailler en session plénière tous ensemble.

Gestion du changement

Le changement, vous vous en doutez, c'est un peu le cœur de tout ce nous avons tenté de mettre en place pendant cette année. Il y en a tellement eu que je ne sais pas vraiment par quoi commencer, mais je pense que globalement, il a eu lieu sur quatre grands axes:

  • Organisation
  • Environnement
  • Technique
  • Humanité

Organisation

Même si nous avions déjà pratiqué XP dans une certaine mesure, le fait est que c'était la première fois que nous tentions une mise en place complète et sans compromis. D'une part, la cliente n'avait jamais touché un projet informatique de sa vie, et d'autre part, nous n'avions jamais tenté de mener un planning agile.

Première excellente surprise: l'écriture des histoires, et la planification dans les itérations s'est passée le plus naturellement du monde. La logique de faire son marché en fonction de ses priorités, du coût des histoires et de la vélocité d'une itération a paru tellement naturelle à la client qu'elle se demandait pourquoi on en faisait autant toute une histoire. Je vous laisse apporter votre propre conclusion à ce constat. Je pense que nous avons vraiment eu le sentiment de travailler sur un "vrai" projet le jour ou Fabien a installé ce tableau dans le bureau. Nous avons aussi investi très tôt dans un tableau blanc pour faire notre mini "design corner".

La plus grande 'lutte" je pense que nous avons mené a été l'ajustement du temps de travail/temps des itérations/rythme de travail soutenable. C'était une équation difficile: nous ne voulions pas nous épuiser à la tâche, nous ne voulions que faire des sessions à 4 pour pratiquer le pair programming efficacement, et nous avions une première release en février 2009 avec mine de rien, un périmètre pas si mobile que ça. L'itération doit rester relativement courte, pour livrer régulièrement et éviter un effet tunnel, mais pas trop car avec le temps par semaine que nous passons, nous ne pourrions pas faire entrer les plus grosses histoires. Nous avons finalement trouvé un compromis acceptable avec des itérations deux mois, en travaillant 1 jour par semaine (un soir + samedi matin). Ramené à une échelle "normale", à savoir si nous étions 5 jours par semaine sur le projet, cela nous donne un temps effectif de... deux semaines. Cependant, étant donné la contrainte de temps, nous nous sommes tout de même permis de travailler chacun de notre côté sur les sujets "techniques". Personnellement, je trouve toujours ça dommage de ne pas intégrer ce temps travail dans la vélocité, mais il faut avouer que ça serait assez difficile.

Une autre grande question a été de savoir quelle serait notre unité de mesure pour les histoires et la vélocité. Je crois qu'aucun d'entre nous n'appréciait particulièrement l'approche par point et sa complexité induite, et nous avons donc préfér" nous acheminer vers des valeurs "concrètes". Cependant, plutôt que de parler en homme/jour, parler en pair/jour nous a semblé en fait plus direct étant donné que le pair programming est systématique. Pour la technique d'estimation, nous avons fini par commander un exemplaire de planning poker, et sa précision s'est révélée relativement démoniaque. D'ailleurs, un ex-collègue/ami/co-voitureur a fini du coup par sortir une version officielle iphone

Environnement

En plus d'avoir acheté un magnifique tableau, nous avons également fait évoluer l'environnement de développement en fonction des problèmes que nous rencontrions. Je pense que ces changements peuvent se résumer fondamentalement à

J'en avais un peu parlé là, mais effectivement nous avons fini par jeter ant pour passer à Maven. Nous avions des soucis de déploiement, des soucis de dépendances, et des soucis d'intégration à eclipse, Maven, a répondu à tout. Nous seulement il a fonctionné comme nous le voulions en un rien de temps, mais en plus nous avons pu le faire monter en puissant petit à petit en fonction de nos besoins. Vraiment pour moi, Maven est un de mes grands coup de cœur de l'année. Il a vraiment introduit une grande souplesse dans la gestion du build et de dépendances en effaçant la peine de l'édition des build.xml d'Ant.

Nous avons du par extension changer Cruise Control pour qu'il parle à maven, et déjà que nous n'étions pas pleinement satisfait de lui, quand nous avons découvert hudson et son intégration rapide et facile avec maven, nous avons fait le pas tout de suite. Adieu la configuration obscure, bonjour la simplicité.

Notre serveur maison commençant à se faire faiblard, et étant donné que nous avons déjà du mettre une version de production à disposition, nous avons également craqué pour la location d'une dedibox. Nous en avons profité pour tout migrer dessus: hudson, svn, intégration, prod, postgresql, samba; bref la totale. Le temps de build et le temps de synchronisation des sources a pris un gros coup de boost grâce à ça.

Il y a eu aussi des tentatives de changement avortées. Nous avons notamment pensé à utiliser Jetty plutôt que tomcat, mais sa faible intégration avec eclipse nous a pour le moment repoussés.

Technique

Le changement technique a été permanent. J'entends par là que nous avons appliqué au maximum de nos capacités le principe de design incrémental, et nous avons avancer majoritairement en nous concentrant sur l'histoire courante, sans penser aux hypothétiques besoins futures, confiant de notre capacité à intégrer les besoins futurs. . Il n'y a pas de secret, TDD et le refactoring sont les pierres angulaires qui nous ont permis une telle confiance. Notre connaissance des tests a largement grandi par ce projet, et je m'appuie maintenant enfin de manière intensive sur les outils de refactoring proposés par eclipse. Bref, je suis plus productif.

Nous avons cependant du faire face il y a peu a une énorme erreur et ses conséquences. Nous nous sommes cassés les dents il faut le dire sur la gestion documentaire. Pour faire simple, nous devions gérer des documents, et pouvoir les éditer en place (si on clique sur le lien depuis l'application web, alors open office doit s'ouvrir et permettre de sauvegarder à distance les modifications). Nous avons alors fait quelques recherches, et nous sommes partis pour utiliser Alfresco. Nous savions qu'il faisait beaucoup plus de chose que nous le voulions, mais nous nous sommes dit que nous aurions besoin de ces fonctionnalités plus tard (première erreur). Alors a commencé un long calvaire pour l'apprentissage d'Alfresco, son déploiement et son intégration dans le projet. Peut être que nous nous y sommes très mal pris, mais le fait que nous peinions énormément à avancer sur le sujet. Nous avons commencé à douter de notre choix, mais nous nous sommes acharnés en disant "après tout le temps qu'on a investit, on ne peut pas s'arrêter, on y est presque" (deuxième erreur). A quelques jours à peine de la fin de l'itération, nous avons décidé de jeter Alfresco et de faire les choses en faisant le strict minimum qui fonctionne: création nous-mêmes des documents et partage via samba. Nous sommes allés vite, mais pas assez. Bilan des courses: itération incomplète, et qualité que vaguement au rendez-vous.

Je pense avoir cité nos deux grandes erreurs dans cette affaire:

  • Avoir voulu utiliser un outil disproportionné pour d'hypothétiques fonctionnalités futures
  • S'être acharné dans notre erreur car nous avions fait pas mal de travail dessus. Il ne faut pas hésiter à jeter le code.

Nous sommes tout de même content d'avoir eu le "courage" de jeter malgré tout 1 mois de travail, mais je pense qu'il y a encore des leçons à tirer de cette erreur, et nous n'avons pas fini de payer la dette engendrée.

Humanité

Oui je parle d'humanité, car j'ai l'impression que cette année nous a changé. Non seulement, en tant qu'équipe, nous avons je pense construit une connivence qui est pour grande part le secret de la rapidité d'avancement: nous sommes synchronisés sur les mêmes objectifs, nous nous comprenons en peu de mot, et même si je n'aime pas faire dans le guimauve, je pense que nous nous sommes forgés une amitié très solide (pour la plupart nous ne nous connaissions pas l'année dernière).

Cette année a radicalement changé je pense ma manière d'être professionnellement parlant, et le projet m'apporte la confiance absolue que ce je tente de mettre en place fonctionne très bien. J'y vois maintenant très clair sur ce qu'est mon travail, et sur ce que je veux faire.

Conclusion

Pendant cette année, nous avons avancé vite, très vite. Sur une échelle de temps "normale", en à peine deux moi, nous avions une application entièrement fonctionnelle donc la cliente se servait quotidiennement. L'intransigeance sur la qualité nous a permis de garder un rythme soutenu et de produire vite malgré une grosse contrainte de temps.

Nous avons fait des erreurs, nous avons appris, mais après cette année, ma confiance envers XP et DDD est devenue quasi inébranlable. D'ailleurs, il était prévu que nous fassions une petite conférence sur la complémentarité XP/DDD, mais ça sera pour un autre billet :) La forme du projet a également évolué, car nous voulons dans un futur plus ou moins éloigné gagner notre vie avec. D'un projet associatif nous sommes donc maintenant face à un projet commercial.