Agilité, Banyuls & Rugby : AOSud !

27 March 2012

Vue de l'hôtel

Voilà un moment que je n’oublierai pas de sitôt ! Et un moment que j’attendais particulièrement ! C’était effectivement l’occasion de pouvoir échanger en face-à-face, notre mode de communication préféré, avec des personnes ayant une longue expérience de l’Agile, mais aussi des histoires et des trajectoires différentes. Et c’est justement cette diversité qui a alimenté les discussions que nous avons eues.

Pour ma part, je suis arrivé avec un paquet de sujets ! Evidemment, je n’ai pas participé à tout, mais je suis venu avec l’envie de participer et d’apporter ma pierre, et ne pas rester simplement en écoute.

Les estimations sont-elles utiles ?

J’ai démarré avec quelques uns de mes camarades autour de la question « Estimer/Estimation : est-ce réellement utile ? ». Nous avons mis un peu de temps pour bien faire le tour de la question. Finalement, ce qu’il en est sorti est que le fait d’estimer est non seulement important mais primordial, ne serait-ce que pour savoir si la User Story doit être découpée ou non. Nous sommes également arrivés au consensus sur le fait que l’estimation elle-même, même si elle peut permettre de se projeter, n’avait que peu de valeur, et qu’il ne fallait évidemment pas la prendre pour un engagement. Là où les avis divergent c’est sur l’unité de l’estimation. Certains sont proches de leur jours.homme idéaux, une majorité continue avec les points, d’autres utilisent les tailles de t-shirt ou même une échelle à deux valeurs (gros et petit).

Personnellement, j’utilise jusque là les points. Mais il est vrai que les dérives qui tendent à calculer le coût du point m’énervent de plus en plus, car c’est contre-productif comme l’explique très bien Pablo ici. Aujourd’hui j’aurais tendance à utiliser les tailles de T-shirts, toujours en planning poker, car l’exercice est intéressant pour le consensus. Par contre, il me reste une question en suspend : comment faire pour effectuer une projection sur le coût, le délai OU le périmètre ?…

Scrum vs XP : le match !

J’ai poursuivi avec une session « crevage d’abcès » sur le combat de chapelles Scrum vs XP. De combat il n’y a eu, et le débat a vite tourné à la question « Qu’entendons-nous par Agilité » ? Quelles valeurs voulons-nous faire passer ? ». Nous avons notamment pointé du doigt que les objectifs de l’une et de l’autre approche sont différents. Scrum a pour objectif d’améliorer la façon de concevoir et réaliser des produits, donc plutôt orienté business (mais pas que). Et XP a pour objectif le changement social, et que tout le monde (clients, développeurs, managers, etc.) y trouvent son compte. Certes Scrum est ce qu’il se vend le mieux, même si Kanban se rapproche, notamment en France. Le problème est que certains consommateurs de Scrum s’arrêtent aux pratiques et font de l’augmentation de la productivité un objectif.

Du monde autour de cette question !

Nous sommes arrivés au consensus qu’à travers notre action à tous, coachs et consommateurs d’Agilité, nous devons mieux faire passer le message autour des valeurs, et que l’objectif productivité ne sera qu’une conséquence de l’abnégation à appliquer ces valeurs. Je pense écrire un billet sur le sujet, pour bien les placarder ! Donc à tous : quand vous vous posez une question sur une pratique, reposez-là en utilisant les valeurs telles que la communication, l’inspection/adaptation, le courage, et mon préféré : le feedback. Vous trouverez par vous-mêmes la réponse.

Agile Occitanie

Nous avons parlé d’initiatives communes des groupes locaux du Sud et plus particulièrement d’Agile Occitanie. Nous avons en effet beaucoup d’atomes crochus et une volonté d’agir ensemble, en témoigne cet Agile Open Sud. Une initiative assez simple pour le moment autour de l’organisation des Agile Tours, bien résumée par Thierry sur son blog.

Coding dojo

Le vendredi soir, tentative de coding dojo, malheureusement tombé à l’eau A CAUSE des breaking change entre Ruby 1.8 et Ruby 1.9 ! Aie aie aie ! Rapide rétrospective : quand on improvise un dojo, il faut s’appuyer sur des bases solides : un environnement prêt, un langage totalement maîtrisé par quelqu’un et accessible à tous, et un kata simple et connu.

Café, tartines, et tests unitaires

On est repartis le samedi matin avec une session sur les tests unitaires et une question farfelue qui en appelait d’autres : « doit-on tester les méthodes privées ? ». J’avoue que c’est celle dont j’ai le moins de souvenirs ! Il faut dire que je ne me ferai jamais au matin, et il me faudra toujours 1h pour émerger ! Je me souviens simplement que les points de vue divergeaient sur la question : « dois-je déplacer mes tests lorsque mon refactoring m’amène à créer une nouvelle classe ? ». Là dessus, mon avis, comme celui de beaucoup d’entre nous, était qu’il était préférable de le faire.

Mais la réflexion d’Olivier m’a interpelée. Lui le fait non pas dans le cas d’une extraction de classe mais d’une extraction de package… Au final, un package doit avoir une abstraction en frontale, représentée par exemple par des interfaces. Ce sont ces abstractions qui sont visées par les tests, et qui auront une certaine stabilité (limitant le travail de rework sur les tests). Tout ce qu’il y a à l’intérieur du package peut bouger en permanence, et donc moins enclin à faire l’objet de tests. On utilisera plutôt des classes concrètes dans ce cas, du fait de la grande instabilité. Cet avis est en train de faire son chemin, et je me laisserais ben tenter par une expérience de ce type.

Code Legacy : mais par quel bout le prendre ?

S’en est suivie une discussion très intéressante sur le code legacy, et comment s’y prendre. Finalement, nous nous sommes rendus compte que le problème n’est pas technique. Mon avis sur le sujet est de commencer par les tests (là ou c’est possible) et l’intégration continue, et de s’appuyer sur la couverture de code pour déterminer le bon moment pour refactorer le code. Après cela demande de la rigueur, des outils pratiques (merci Resharper), un peu de courage et une maitrise de concepts de développement clés.

La vraie problématique est de savoir comment faire en sorte que l’esprit « code propre » se propage, et comment chaque membre de l’équipe doit se l’approprier. Car refactorer du code c’est kiffant ! mais si c’est pour qu’il soit flingué quelques temps après, ça ne sert à rien. Il faut veiller à ce que l’équipe progresse de façon homogène, ou sinon, comme l’exposait JB, ne pas embarquer tout de suite les personnes que l’on a pas eu le temps de sensibiliser. Et il ne faut perdre personne, et surtout se méfier de ceux qui ont une grande « productivité », car s’ils ne sont pas au fait des critères de qualité de code, ils produisent des dégâts bien plus importants !

L'équipe rouge attaque, la verte défend ! Merci à Rui au passage !

L’image que j’utilise est celle du rugby, bien illustrée par Rui. Au rugby, l’objectif est de faire progresser la ligne d’avantage. Si un attaquant transperce le rideau défensif sans faire attention à son soutien, il va s’isoler et perdre le ballon, et donc reculer. Il doit donc faire attention à son soutien, et vérifier que l’équipe avance avec lui, et sinon faire tout son possible pour qu’elle ait le temps d’arriver à son niveau, notamment en levant la tête et en ralentissant. Il doit simplement en être de même dans une équipe de développement, surtout lorsque quelqu’un arrive pour refactorer du code. car l’objectif de l’équipe est bien de faire avancer le produit, et non juste l’un de ses membres. Et pour cela son arme privilégiée est le pair programming.

Et aussi…

J’ai aussi participé à la session sur la création de jeux. L’idée est d’utiliser le concepteur de jeu Kodu pour faire passer des messages sur des concepts du développement Agile comme le pair programming ou le TDD. J’avoue ne pas avoir été convaincu du truc, mais je demande à voir une fois qu’un atelier sera fait !

On a enfin terminé tranquillement la journée, avec évidemment une rétrospective, à laquelle Claude, Romain et moi avons échappée pour ne pas rater le début du match de rugby ! Nous l’avons toutefois faites entre nous, et pour ma part, il a vraiment manqué un gros dojo ! J’avoue être un peu frustré d’avoir cotôyé tant de gens brillants sans en profiter pour cela. Bref, ce n’est que partie remise !

Un grand merci !

Je ne remercierai donc jamais assez (de mémoire) Thierry pour son sourire éternel, Claude en tant que fidèle de la boucherie ovalie, Romain et Olivier pour nos discussions dans la voiture, JB et Mickaël malgré leur attirance pour le Bordeaux, Antoine pour son « require relative » et ses photos, Oliver pour avoir supporté notre français, Stéphane pour son enthousiasme débordant, Olivier pour ses avis à « contre-pied » intéressants, Rui pour avoir supporté des excités, Alexis pour sa bonne humeur, Yannick pour son calme, Anthony pour le courage d’être venu à Banyuls en béquilles, Guillaume pour être aussi branché code, Christophe, Pedro et Loïc que j’ai assez peu croisés au cour des discussions, et bien sûr Pablo et son bandjo pour m’avoir permis de venir !

Bien évidemment, je ne pourrai pas rater la prochaine édition ! 🙂

En complément, les autres retours sur le sujet :

Fabrice
Claude
Thierry
Pablo
Des photos
Alexis
Rui
Antoine
Jean-Baptiste
Une petite rétro en photo de Yannick 
La liste twitter de (presque) tous les présents