Agile Grenoble 2012, ma journée chez les binômes

Binômes

J'assistais jeudi pour la première fois à Agile Grenoble.

Ce qui était bien

  • Le binôme Rémy Sanlaville/Johan Martinsson et leur refactoring du Gilded Rose Kata chez les développeurs anonymes. Près de 70 personnes dans une salle prévue pour 40 (ne jamais sous-estimer l'attrait d'une session pour développeurs) et un public assez enthousiaste comme l'indiquait le ROTI à la sortie de la salle.
  • Le binôme Emmanuel Gaillot/Jonathan Perret pour leur évocation des travers du pair programming. Là encore la (même) salle est plus que comble même si le public semble avoir moins accroché. Pour ma part, je me suis régalé. Il fallait peut-être avoir un minimum de recul sur la pratique pour apprécier pleinement la session contrairement à la précédente qui pouvait mieux parler à tous les développeurs ? Et j'en profite pour souhaiter une bonne continuation à ut7.
  • Le binôme Christophe Grand/Laurent Petit et leur introduction au langage Clojure. J'ai trouvé le rythme de la session un peu trop lent à mon goût mais je suis très content d'y avoir participé car je ne connaissais pas du tout le langage. Et, surtout, je n'ai pas été surpris par leur style de conception ce qui me conforte dans mon approche pour l'instant très limitée des langages fonctionnels.
  • La keynote de Gojko Adzic. Elle n'apportait rien de fondamental pour qui a lu quelques uns de ses articles mais elle faisait plaisir à voir. Une vraie keynote : des idées fortes, un rythme soutenu, quelques exemples biens choisis, bref, un bon moment.
  • La logistique. Un vestiaire qui m'a bien dépanné. Un repas bien au dessus de ce que l'on a à Agile Tour Toulouse et pour, parait-il, un coût moindre...

Ce qui était moins bien

  • Le nombre de sessions en parallèle. Neuf, c'est définitivement beaucoup trop pour ce genre de conférence où il est généralement difficile de se faire une idée du contenu exact des sessions. Et, le pire, c'est qu'il n'y avait absolument aucune classification ou thématique associée à chaque session. Bref, un vrai labyrinthe. Je me suis rabattu sur ce qui m'avait l'air le plus technique possible pour éviter de perdre mon temps.
  • Un retour d'expérience de la Société Générale déguisé en keynote pour débuter l'après-midi. Ca a sûrement intéressé des gens mais de là à l'imposer à tout le monde... En plus impossible pour moi de sortir sans faire se lever 5 ou 6 personnes...
  • Le retour d'expérience de Laurent Sarazzin (celui de la keynote subie donc). Tant qu'à être là j'ai, difficilement, essayé d'écouter cet improbable sac de noeuds. Passons sur "la boite à cons" dont le terme me semble particulièrement mal choisi (c'est un "coach" qui a inventé ce nom ?). Je retiendrai cette phrase qui m'a choqué : "les managers deviennent des story tellers". Impossible pour moi d'imaginer un voyage vers l'agilité via des techniques à la frontière de la manipulation mentale. Bref, nous n'avons pas les mêmes valeurs.
  • L'impression de grand fossé entre le monde des communicants et des organisants d'un côté et les codeurs de l'autre. Ce sentiment n'a rien de nouveau mais certains éléments anodins ne font rien pour arranger les choses. Je pense par exemple aux "personas" censées guider les gens vers les sessions faites pour les gens comme eux. Je pense à la 2ème keynote (oui, toujours la même) où est évoquée la classification des cultures d'un Michael Sahota qui, à mon avis, se trompe lourdement sur le Software Craftsmanship.

Les questions (que je me suis) posées

Les lecons (re-)apprises

Remerciements

  • Au staff en rouge pour son implication tout au long de la journée. Je garderai cette image d'une salle de conf transformée quelques minutes en atelier pour le Clojure hands on.
  • Aux personnes rencontrées et avec qui j'ai pu discuter. Impossible de toutes les citer sans en oublier mais je remercie ici Michael, Charles et Jean-Baptiste sans qui je n'aurais pas autant apprécié mon séjour.

Ils en parlent aussi

Pour aller plus loin

Notes

[1] Bug ou pas bug, la valeur que retire l'utilisateur du produit est une mesure de la qualité

Jérôme

Salut Olivier,

Merci pour ton retour :)
Une question : je n'ai pas trop compris ton sentiment négatif sur les personas.
Qu'est ce que tu reproches ? le principe ? la façon dont ils étaient faits ? leur nombre ? leur efficacité ?etc.
Car de l'extérieur, ça me paraît plutôt être une idée géniale.
Mais ton retour m'intéresse pour AT Montpellier.

Oaz

Salut Jérôme,

Je crois que les personas sont la bonne réponse à une mauvaise question.

Si la question est "quelles sont les sessions où l'on va évoquer le plus de choses ayant un rapport direct avec le travail d'un profil type X dans une entreprise classique ?" alors, effectivement les personas sont une bonne réponse. Elles vont permettre à des chefs de projet d'aller rencontrer d'autres chefs de projets dans une session où un ex-chef de projet devenu scrummaster raconte l'évolution de sa vélocité lors des 10 premiers sprints de son projet (on peut trouver des situations similaires avec des développeurs, des chefs de produit, etc.)

Maintenant si, depuis mon monde de bisounours, j'essaye de définir différemment l'utilité d'une conf agile, je peux poser une autre question : "comment puis-je amener des personnes de divers horizons mais partageant une communauté d'intérêt à se rapprocher au travers d'une démarche de découverte ou d'approfondissement de l'agilité ?" je n'aurai pas la même réponse.
L'approche thématique de l'AT Toulouse me parait être bien plus adaptée au sens où elle donnait des pointeurs sans être clivante. On s'est juste planté en oubliant de préciser (voire de déterminer pour chaque session) le niveau découverte vs approfondissement.

Oaz 10 novembre 2012 - 16:29
pablo

décidément j'aime bien le positionnement de Mr Oaz. Je ne suis pas toujours d'accord mais il me semble singulièrement cohérent.

Les réponses à tes questions :) :) :)

1) rien compris, je ne sais pas ce que c'est
2) c'est pas plutôt l'inverse ?
3) beaucoup (mais c'est aussi à eux de changer les choses car 100% de ce code provient de développeurs).
4) euh, comment dire.

pablo 11 novembre 2012 - 10:48
Oaz

Salut Pablo,

Merci pour les réponses aux questions :)
Le problème des questions 1 et 4, c'est que quand on passe la journée à voir du code, ben on se pose des questions relatives au code...

Et pour la question 3, je suis bien d'accord. Le programmeur du XXIème siècle, c'est un peu le médecin du XVIIème siècle. S'il veut gagner un peu de respect, il a du chemin à parcourir.

Oaz 11 novembre 2012 - 16:09
Rémy Sanlaville

Salut Olivier,

Concernant la question que tu te poses "Que vaut la règle 5 ("One dot per line") des Object Calisthenics ? Surtout si l'on considère les DSL internes", je vais essayer de donner une réponse.

En premier lieu, c'est bien que tu te poses des questions, les règles sont faites pour cela ;-)
Revenons à la règle 5 "One dot per line" qui correspond à la loi de Déméter (qui peut être résumée en "Ne parlez qu'à vos amis immédiats"). L'idée est faciliter la maintenance évolution en ne cassant pas l'encapsulation des classes.

Concernant les DSLs comme on a pu le montrer dans la solution 4 : quality.doIncreaseBy(1).when(daysBefore, greaterThan(10)); - bien que nous ayons deux appels de méthodes sur une même ligne (Two dots) on reste conforme à la loi de Déméter même si cela ne respecte pas la règle 5. En effet, les DSL (comme par exemple FEST) ont la particularité de retourner l'instance de la classe de la méthode qui est appelée. Du coup, même si on a bien plusieurs appels chaînés (comme dans FEST) cela reste sur la même instance et cela ne casse pas l'encapsulation de la classe.

Comme indiqué, le but n'est pas de respecter à 100% les règles (contraintes), mais elles sont là pour lever un drapeau et nous faire réfléchir (une chance pour sortir de notre cadre de pensée).

En espérant avoir pu répondre à ta question.

Rémy Sanlaville 12 novembre 2012 - 00:28
Alex

Salut Olivier

Petite précision, les personas ont été beaucoup apprécié par les personnes qui avaient du mal à choisir leurs sessions ... ce qui n'était manifestement pas ton cas :)

De même pour la 2ème Keynote qui a également été globalement appréciée, mais surement plus par le monde des "communicants et organisants" qui était bien présent et que tu ne portes pas vraiment dans ton cœur ... et qui pourtant font également beaucoup progresser la cause de l'agilité, et par voie directe celle des développeurs :)

Amitié
Alex

Alex 12 novembre 2012 - 11:48
Oaz

@Rémy,

Merci pour les détails.
Je crois que, en fait, j'ai un petit souci avec la loi de Demeter. Tant que je ne connais mes amis et les amis de mes amis qu'à travers des interfaces, j'accepte de leur parler à tous.
Le "parler à travers une interface" me semble être une connaissance suffisamment minimale si les interfaces en question sont suffisamment stables.

@Alex,

Pourtant, j'ai eu bien du mal à choisir mes sessions. J'ai juste choisi sans prendre de risque par manque d'information sur la plupart des sessions.
Et puis, comme je l'ai écrit, les personas peuvent être une bonne réponse. Tout dépend de la question. :)

Pour ce qui est des "communicants et organisants" (ce que je suis moi-même d'ailleurs devenu aujourd'hui, bien plus que codeur en tout cas), je suis juste parfois surpris par leur capacité à faire passer le produit logiciel au second plan, même si c'est pour faire avancer une cause...

Oaz 12 novembre 2012 - 16:06
Rémy Sanlaville

Intéressant comme réflexion concernant la loi de Demeter et le fait de n'utiliser que des interfaces.

C'est à creuser mais je dirais que même si je n'utilise que des interfaces je préfère éviter cela et suivre la loi de Demeter car je préfère ne pas rendre visible l'état interne de ma classe même si je retourne une interface. Imagine par exemple que tu veux passer d'une Collection à une Map. Cela pourrait avoir un impact important sur le reste de ton code.

De plus si tu souhaites avoir accès à l'état interne de ta classe c'est sans doute que tu veux demander à ta classe quelque chose de particulier. Autant faire en sorte de rendre visible cela au niveau de la classe et déléguer l'implantation à un collaborateur. Cela permettra de faire mieux apparaître ce que tu demandes à ta classe (tu auras un contrat plus claire) et voir si elle ne porte pas trop de responsabilité.

Rémy Sanlaville 12 novembre 2012 - 22:19
Oaz

Mais si je passe d'une collection à une map, c'est que mes interfaces ne sont pas si stables que ça :-)

En fait, ma vision actuelle de la conception de logiciels (que j'ai partagée dans une série de billets) fait que je m'intéresse relativement peu aux détails internes d'un composant (terme générique pour librairie, package, etc.) mais que je recherche un maximum de stabilité au niveau des concepts/interfaces qui font le liant entre les composants.
Du coup, partager des états internes à l'intérieur d'un composant ne me dérange pas plus que ça. La zone de partage est de toutes façons très limitée. Et pour les échanges inter-composants, vu que je fais l'hypothèse de la stabilité des interfaces, je n'ai pas de scrupules à enchainer les appels. :-)

Peut-être que je rate quelque chose mais pour l'instant cette approche fonctionne pas trop mal pour les logiciels sur lesquels je travaille.

Oaz 14 novembre 2012 - 18:34
Rémy Sanlaville

Si tu passes d'une collection à une map ce n'est pas que tes interfaces ne sont pas stables, c'est plutôt que le choix de l'implantation n'a pas été suffisamment bien encapsulé. C'est vrai que l'exemple collection et map était un peu facile (ne pas oublier la règle 8. Use first class collections).

Plus généralement si tu dois changer du code alors que le besoin n'a pas évoluer alors tu es en train de reprendre des choix d'implantation. Dans ce cas, le changement devrait être le plus centralisé possible.

En tout cas, si ton approche fonctionne plutôt bien sur tes logiciels c'est le plus important et cela signifie que tu gères plutôt bien la responsabilité et l'encapsulation de tes objets. On pourra sans doute en rediscuter un jour sur un de tes projets.

Rémy Sanlaville 14 novembre 2012 - 21:32

Fil des commentaires de ce billet

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.