Comment convaincre un développeur qu'un jeu de balle peut l'aider dans son métier ?

Pour cette année 2014, je me suis fixé un objectif simple : montrer le jeu Soft(ware)Ball à un public de développeurs bien plus large que ceux qui sont familiers du monde des méthodes agiles.
Il faut dire que l'année dernière fut assez exceptionnelle pour moi. J'ai proposé ce jeu comme atelier dans un grand nombre de rassemblement autour de l'agilité (Agile France, Global Scrum Gathering Paris, Agile Tour Montpellier, Agile Tour Bordeaux, Agile Grenoble) et il a été accepté partout. J'en profite d'ailleurs pour remercier tous les organisateurs pour m'avoir fait confiance.

Un jeu apprécié par le public des méthodes agiles

Le jeu a été globablement apprécié, avec de nombreux retours constructifs qui m'ont permis de l'améliorer au fil du temps.
Certains y ont vu un bon moyen pour apprendre la programmation. D'autres ont trouvé intéressants les mécanismes utilisés pour représenter des problèmes récurrents en développement logiciel (exemple : le coût du refactoring).
Certains m'ont dit qu'ils allaient réutiliser des idées dans leurs ateliers. D'autres m'ont dit qu'ils essaieraient peut être ce jeu avec des étudiants.
Dans tous les cas, le ressenti positif des participants a largement dominé[1].

Il y a deux choses dont je suis particulièrement satisfait, voire assez fier :

  • C'est un jeu accessible à tout le monde. Que l'on soit développeur ou pas ne change pas grand chose. J'ai eu une formidable session à Montpellier avec un grand nombre de non-développeurs. En fait, pendant le déroulement du jeu, même s'il s'agit de véritables problèmes de programmation, il est très difficile de savoir qui code tous les jours et qui n'a jamais écrit une ligne de code de sa vie.
  • C'est un jeu qui, sans ordinateur, met en oeuvre des principes et des pratiques qui sont loin d'être triviaux pour la plupart des développeurs : la responsabilité unique des composants, le polymorphisme, l'inversion de dépendances, les divers types de refactoring...

Un jeu qui peut toucher un public plus large ?

Avec mon élan de 2013, j'ai cru qu'il me serait possible en 2014 de toucher un public plus large, un public de développeurs qui n'accroche pas vraiment aux événements "méthodes agiles".
Le résultat de ce début d'année est un peu déprimant : 3 propositions comme atelier sur des conférences "développeurs" et toutes ont été refusées[2].
Cela ne va pas m'empêcher de continuer à proposer cet atelier-jeu sur d'autres événements mais ces refus m'amènent à plusieurs interrogations.

Ma première interrogation, c'est "Est-ce que ma présentation du jeu est en phase avec l'objectif recherché ?".
Voici mon "pitch" actuel :

Software development is a cooperative game of invention and communication (Alistair Cockburn)

Profitez d'une partie de Soft(ware)Ball pour découvrir des pratiques et des principes popularisés par les méthodes agiles : refactoring, programmation en groupe, responsabilité unique, ouvert/fermé, inversion de dépendances...
Et si vous les connaissez déjà, vous les redécouvrirez sous un jour nouveau car les katas que vous déroulerez se feront sans clavier ni écran : une équipe, un ballon, un peu d'intelligence collective, et tout devient possible !

Plus d'informations sur softwareball.org (mais n'en regardez pas trop car les jeux sont plus intéressants quand on les découvre en équipe)

Une expérience humaine :

  • L'apport du jeu dans tout apprentissage, même les plus proches de la technique et du code source.
  • Une expérience de programmation collective. Premier pas vers le "Mob Programming" ?

Et un regard nouveau sur des techniques éprouvées :

  • L'importance du refactoring dans toute base de code. Le coût engendré par sa pratique et sa non-pratique.
  • La responsabilité unique des composants pour une meilleure réutilisabilité
  • La simplification de code (notamment la suppression des "if-then-else") à travers le polymorphisme et l'inversion systématique des dépendances.

J'ai essayé d'utiliser les mots qui me parlent qui m'inciteraient à découvrir un tel jeu mais est-ce le bon message pour un public un peu différent ?

Une énigme : le développeur de 2014

Ma deuxième interrogation, c'est "Est-ce qu'une conférence pour développeurs est le bon endroit pour un tel jeu ?".

J'ai cette désagréable sensation de ne pas être totalement à ma place dans ce genre de conférences.
En 2013, j'ai participé à Mix-IT et j'ai essayé d'en retirer le maximum mais je dois avouer que j'ai soigneusement évité la plupart des sessions colorées "développeurs" car elles sont, à mon goût, trop fortement orientées outils de développement.

C'est quoi une sessions colorée "développeur" ? Facile : c'est une session qui contient dans son titre le nom d'une techno "hype".
"Les subtilités d'AngularJS", "au coeur de la JVM", "les nouveautés de Groovy", "Un peu de git sur ma branche", "Gradle et Maven sont dans un bateau", et les best-sellers de l'année : "Les lambdas dans Java 8"[3] et "Docker va tous nous sauver"[4].
Bref, vous l'aurez compris. Ce défilé de technologies toutes plus clinquantes les unes que les autres m'ennuie profondément et j'ai donc systématiquement l'impression de ne rien avoir en commun avec tout ça.

Le problème, c'est que, si ce n'est pas le bon endroit, je ne sais pas où aller parler à des développeurs !

Ce qui m'amène à ma troisième et dernière interrogation : "Est-ce que le développeur λ de 2014 peut être intéressé par ce que j'ai envie de lui raconter ?".

Et c'est probablement le noeud du problème. Si les gens viennent en majorité chercher des démos de technos, ils ne sont peut être pas dans un état d'esprit propice à réfléchir plus en profondeur au principes qui sous-tendent l'activité de développement logiciel ?

Alors, on fait quoi ?

Une option serait de laisser tomber. Je suis dans une phase où mon boulot m'apporte des nouveautés et des perspectives passionnantes. Quel besoin ai-je d'aller me faire ch... à essayer de faire passer des idées qui sont, je le sais, très importantes voire essentielles, à des gens qui n'en ont rien à f..... ?

Une autre option serait de continuer à faire mûrir le jeu en restant dans une optique "apprentissage de la programmation". J'ai du mal à croire en cette option là car le principal obstacle à franchir pour amener quelqu'un à coder, c'est, je crois, d'établir un contact avec la machine, pas de rester dans des concepts trop abstraits.

Et puis, il y a cette histoire d'équilibre dans la Force qui me travaille depuis trop longtemps. Cet équilibre passe par l'ouverture des développeurs à autre chose que leurs jouets technologiques.

Donc voilà. Si tu as lu jusqu'ici et que tu as un conseil ou une idée pour m'aider à avancer, les commentaires ci-dessous et les réseaux sociaux sont là pour ça...
D'avance, merci !

Notes

[1] Pour la petite histoire, un des retours les plus négatifs, c'était au Global Scrum Gathering où un participant a écrit : "trop de programmation, pas assez de Scrum" :-)

[2] Devoxx France, Mix-IT et Devoxx UK. Pour être précis, on m'a proposé d'être en "backup" sur Mix-IT. Pour les deux autres, je ne sais même pas si ça aurait pu passer ou s'ils ont jugé le truc trop ésotérique.

[3] Vu l'enthousiasme que semble générer cet ajout au langage, si un jour il y mettent un équivalent de LINQ, on frôlera l'orgasme...

[4] Ces titres de sessions sont fictifs. Toute ressemblance avec des sessions existantes ne serait que pure coïncidence

Xavier Nopre

Bonjour Olivier,

Merci pour ce partage qui est intéressant et qui interpelle ...

J'ai découvert ton jeu à Agile France l'an dernier, dans ses premières versions je crois, je suppose qu'il a évolué depuis. Et pourtant, il était déjà bien intéressant !

Je n'ai malheureusement pas vraiment de réponses ou d'idées à t'apporter, juste des remarques.

Une des difficultés est qu'effectivement, ton jeu peut s'adresser à des développeurs et à des non-développeurs. Du coup, le risque est que chacun se dise que c'est plutôt pour l'autre et ne se sente pas concerné. J'ai un peu ce ressenti avec les sessions que je propose depuis l'an dernier, sessions qui peuvent s'adresser à différents publics, et malheureusement, c'est pas si simple ...

Une autre difficulté est directement liée à notre mentalité, nous les développeurs.

Il y a ceux qui font ce métier pour manger, sans passion, sans intérêt, on les oublie pour ton jeu.

Ensuite, il y a ceux qui "savent", qui n'ont pas grand chose à apprendre puisqu'ils sont "séniors" voire "experts" (en passant http://xnopre.blogspot.fr/2013/12/d... ... ;-) ...).

Il y a également ceux qui sont curieux, en mal d'apprendre, mais qui vont plus se tourner vers les nouvelles technos, vers le "hype", et auront du mal à s'intéresser aux notions de base du métier de développement logiciel, quelque soit la techno ou le langage, y compris celui qu'on utilise tous les jours.

Enfin, il y a ceux qui sont ouverts, à l'écoute, artisans, en recherche d'amélioration permanente, et qui donc devraient être fortement intéressés par ton atelier. Malheureusement, le "jeu" a la vie dur (ça n'est pas sérieux et ça ne permet pas d'apprendre, se dit-on), et effectivement, le réflexe est plus de se tourner vers les technos, ou du moins les mains dans le cambouis, par exemple pour découvrir le TDD, et c'est déjà pas si mal... Mais comment les interpeller pour une approche ludique et loin du clavier ? ....

Une idée, juste une : peut-être qu'un atelier comme le tien pourrait-être inséré au milieu d'une journée de formation pour développeurs, histoire de casser un peu le rythme, de prendre du recul, de voir les choses sous un autre angle ...

En tout cas, bon courage, tiens bon et tiens-nous au courant, car cette approche est intéressante !

Xavier

gregory

J'ai peur que la question importante pour le public que tu essaies d'atteindre se résume à:
"Est-ce que je peux l'inscrire sur mon CV ?"

Bien que personellement j'aime beaucoup ton jeu, j'ai l'impression qu'il ne flatte pas suffisament l'égo des participants.
J'entend par là qu'un dev. qui participe à une session "techno X blablabla" ne cherche pas vraiment des infos sur la "techno X" car il les trouvera en 5 mn. sur internet ou dans un bouquin mais plutôt le "blablabla" qu'il va pouvoir ressortir à son employeur, ses collègues... pour donner l'image qu'il "maitrise ce sujet".

J'espère me tromper, mais j'ai le sentiment que "connaitre" la techno X est plus "valuable" dans certains milieu de l'entreprise que de développer ses "savoirs être" ce qui semble être davantage le fond de ta présentation.

J'extrapole un peu avec "savoirs être" mais je veux dire par là que bien que ton jeu explicite des mécanismes techniques il me semble de part sa forme "jeu" (permet d'accepter plus facilement des règles) qu'il met l'accent sur les reflexes à acquérir face à certaines situations rencontrées son métier.
Et donc c'est davantage le comportement du developpeur qui est remis en cause plutôt son environnement technique, ce qui est beaucoup moins plaisant pour certains.

Veux tu vraiment t'adresser à des personnes qui foncièrement ne sont pas prêtes à changer ?

gregory 27 mars 2014 - 18:24
Oaz

Merci pour vos réponses.

@Xavier,

L'aspect "loin du clavier" doit en effet avoir une part de responsabilité. Quand on propose un tel jeu dans la catégorie "hands on" d'une conf, on se retrouve avec des lancers de balle face à des sessions qui sont quasiment toutes sur le même modèle "clavier+écran". J'essaie de réfléchir à une version "jeu sur table" qui paraîtrait moins bizarre mais pour l'instant je n'ai rien trouvé qui me convienne.

C'est vrai que c'est déjà pas si mal d'avoir des sessions "clavier+écran" qui ne soient pas orientées technos. On a celles sur le TDD. Il y en a aussi sur la taille des lots (le carpaccio...) et aussi quelques inclassables (le baby code retreat me donne vraiment envie)

Quant à l'insertion du jeu dans une journée de formation, il m'est difficile d'avoir un avis sur la question car cela ne fait pas partie de mes activités (et, par ailleurs, je serais un bien piètre formateur).

@Gregory,

J'ai pensé à ce problème "d'image" en écrivant le billet mais je n'ai pas osé en parler :-)
Effectivement, j'ai l'impression qu'une grande partie des sessions "techno" n'apportent rien que l'on ne pourrait trouver sur le web en autant de temps.
Et du coup j'ai du mal à comprendre la motivation qu'il y a derrière ces confs. Peut être n'y a-t-il rien de plus que "je veux aller passer quelques jours sympas avec des potes"=>"je dois le justifier à travers l'apprentissage de trucs valorisés par mon patron même si je sais que ça ne sert pas à grand chose" ?

Je ne suis pas sûr de comprendre ce que tu entends par "savoir être". L'aspect comportemental par rapport à une équipe de développeurs est présent (j'en parle un peu dans le pitch) mais je mets plus en avant l'aspect "augmenter la connaissance".
Je me suis rendu compte que le fait de dé-tricoter des notions telles que l'inversion de dépendances ou le refactoring pour les re-tricoter dans un jeu de balle m'avait permis d’accroître mon intimité avec le sujet. Ce sont des trucs qui deviennent plus naturels. C'est similaire à ce qui se produit quand on commence à bien connaître plusieurs langages de programmation sur des paradigmes différents et que l'on fait des connexions entre les similitudes et les différences. Et j'avais donc envie de partager cette chose-là.
Même si le terme est probablement trop fort, voire pompeux, j'y vois un intérêt pour une "épistémologie du développement logiciel"...

Du coup, je me suis aussi rendu compte que mon intérêt pour le développement logiciel en tant que moyen pour créer un produit et apporter des solutions à des utilisateurs n'était que marginal par rapport à sa "pure" capacité de génération de connaissances. Parce que cet accroissement de connaissances est, je crois, le moteur qui permet de créer de meilleurs produits et d'apporter de meilleures solutions.

Et quand j'en arrive là, je me demande effectivement si je peux m'adresser à des personnes qui ne sont pas prêtes à améliorer leur "moteur"...

Oaz 27 mars 2014 - 23:28
Florence

Le problème vient peut-être du type de conf pour développeur que tu vises. Je ne participe pas à ces confs (vie familiale), mais j'ai eu des échos comme quoi devoxxx c'est vraiment la conf pour les trucs nouveaux ou chelous qui ne servent pas dans la vie quotidienne du développeurs. A côté de ça, tu as plein de conf bien plus accessibles qui présentent des choses bien plus terre-à-terre : les JUG, le Breizh camp, etc. Peut-être que ton jeu de balle y aurait plus sa place.

Florence 1 avril 2014 - 12:05
rguitter

Salut.

Pourquoi veux-tu étendre le public de ton jeu à des développeurs ?
La plupart sont des personnes qui font ça pour remplir leur gamelle: ils se posent bien plus souvent la question du comment que du pourquoi. Le mot même de jeu renvoie à l'amusement, t'en connais beaucoup des développeurs qui s'amusent.

Tu n'as pas pensé faire découvrir ce jeu (ou une version peut être modifié) à des enfants ? Quand je vois les quelques rares heures consacrées par l'école à ce sujet, je ne les trouve pas très folichonnes.

rguitter 1 avril 2014 - 16:21
Oaz

Merci !

@Florence,

A ma connaissance, le JUG, c'est surtout des événements en soirée.
En fait, j'ai aussi présenté le jeu lors d'un atelier en soirée de l'association Agile Toulouse et il y a une autre soirée en préparation pour Software Craftsmanship Toulouse.
Le problème de ce cadre là, c'est que je suis, en pratique, limité à Toulouse.

Le BreizhCamp, ça à l'air sympa, mais la Bretagne c'est pas l'endroit le plus accessible :-) et en plus cette année ça tombe en même temps que Agile France. :-(

@rguitter,

Je ne vois pas vraiment comment le faire fonctionner avec des enfants... Et ce n'est pas faute d'être branché "programmation pour les enfants" mais, comme je l'ai écrit, je crois que l'apprentissage de la programmation doit en priorité passer par la machine.

Oaz 4 avril 2014 - 00:10
Razorgore

En fait, le développement est un processus créatif et non un processus fordiste/tayloriste.
Essaie plutôt de mettre 10 personne devant un grand tableau blanc et de leur demander de dessiner un dinosaure.

Le jeu de la balle permet de sensibiliser au problème de l'organisation et de la méthode, mais il pervertit beaucoup, ou oblitère, l'aspect créatif du métier réalisé.

Peut-être que pour intéresser les développeurs, il faudrait s'intéresser à leur métier... en prenant un exercice qui colle à leur réalité.

Ça permettra, par la même occasion, de sensibiliser le côté managérial à la problématique du développement, ce qui est juste indispensable à tout réussite agile. (d'ailleurs vous entendrez souvent "mais développer ce n'est pas pareil que dessiner", preuve même de la méconnaissance du travail qu'ils sont censés organiser)

Razorgore 8 avril 2014 - 16:32
Oaz

@Razorgore,

Le commentaire me surprend un peu...
Après tout, je ne fais que dire à 10 personnes : "Voilà une balle. Il faut qu'elle effectue tel parcours en marquant un maximum de points. Débrouillez-vous !"

D'après le ressenti des participants, la nécessité d'être créatif est justement un des points qui ressort du jeu !
Le seul aspect organisationnel présent dans le jeu, c'est la capacité à réagir aux changements de besoin (ce qui, si on reste sur l'exemple du dessin serait l'équivalent de "en fait, je voulais un diplodocus, pas n'importe quel dinosaure" qui surviendrait 2 minutes avant la fin du temps imparti)

Oaz 9 avril 2014 - 01:48
Razorgore

Houlà... soyons précis...
"processus créatif" et "être créatif dans le processus" se rapportent à deux choses complètement différentes dans nos discussions.
"processus créatif" = faire circuler une balle n'est pas un processus créatif.
"être créatif dans le processus" = pour imagine "comment" faire circuler la balle, il faut être créatif (dans l'a bouche de M. tout-le-monde = "faire travailler son cerveau pour trouver une solution").
(je souligne ici que c'est une des raisons pourquoi certains développeurs font les meilleurs "analystes en processus organisationnels", c'est un peu ce qu'ils font toute la journée)

Je vais le formuler autrement.
Les développeurs (intéressés par l'efficacité de leur travail à travers la collaboration des différentes parties) savent très bien ce qui cloche dans les projets, et ça n'a rien à voir avec ce qui est mis en évidence dans votre exercice.
Vous pouvez venir avec toute la bonne volonté du monde, si votre proposition n'a pas de but intelligible et pertinent, vous n'intéresserez pas les développeurs.

Dois-je vous rappeler que pour 90% d'entre eux (saviez-vous que 87% des statistiques sont inventées sur le moment pour servir son propos ?) le quotidien est un véritable îlot d'incompréhension et d'isolement ? La plupart, ce n'est pas ceux que l'on voit aux rendez-vous techniques. La plupart, ce sont ceux qui disent "oui" à tout même s'ils savent que c'est voué à l'échec ou complètement débile, parce qu'ils ont renoncé à se battre, à expliquer, parce qu'ils savent que c'est parler à des murs.

Je digresse, je digresse. Tout ça pour dire que, d'un point de vue de développeur, votre jeu est sans grand intérêt, soit parce que seule la technique les intéresse et qu'ils n'ont pas besoin d'apprendre une version dévoyée du refactoring, soit parce qu'ils savent que c'est irréaliste, soit parce qu'ils ont déjà compris les mécanismes depuis des lustres (ce sont des gens qui réfléchissent vraiment beaucoup, souvent).

Vous voulez intéresser les développeurs ? proposez-leur quelque chose qui les intéressera. Désolé pour la tautologie, mais j'ai du mal à comprendre votre étonnement face à un public peu réceptif. Il l'est parce que ça ne l'intéresse pas. Si vous voulez vraiment comprendre pourquoi, posez-vous les bonnes questions.

Enfin l'exercice est vendu comme quelque chose qui permet de comprendre le refactoring et autres choses techniques, alors que rien n'est moins faux. Le terme refactoring est ici extrait du domaine technique auquel il est propre pour désigner l'adaptation de la méthode ("refactoring de méthode" pourrait-on dire). Ce genre de procédé pourrait être qualifié de malhonnête par certains.

Quel est l'intérêt de tout mélanger ? Faire "hype" ? La flemme d'avoir une analyse poussée sur la pertinence de l'exercice ? Gonfler son CV ? Suivre la mode ?

Vous devez comprendre que le développeur est avant tout précis. Si votre vision du travail se résume à mélanger allègrement les concepts parce que le résultat est joli à regarder et qu'on peut conclure "c'était une super expérience" dans un flou artistique généralisé, alors passez vous vivez sur un plan parallèle à celui dans lequel évoluent les développeurs, et c'est peut-être la raison pour laquelle ils sont peu enclins à venir dans votre univers.

Encore une fois, si la précision des termes ne vous parle pas plus que ça (d'après ce que j'ai pu voir de votre réponse), si la précision des concepts n'est pas importante pour vous (vous semblez trouver l'exercice pertinent pour un développeur, voire représentatif de leur travail), alors il n'y a rien à faire du tout.

A la lumière de ces éléments, pensez-vous toujours que l'exercice est pertinent pour des développeurs ?
Pensez-vous toujours que ça peut les aider dans leur métier, si on le met à côté des problématiques auxquels ils sont confrontés depuis 40 ans ?

Je précise que je risque de ne pas répondre. Ça fait 10 ans que je déploie des trésors de patience pour expliquer les choses. Aujourd'hui je sais que c'est totalement inutile (tout le monde s'en fout d'être précis et de comprendre en profondeur, seul l'aspect compte), mais pour une raison inconnue je refuse d'abandonner cet espoir vain.

Ne prenez pas tout ça trop au sérieux, tant que les gens aiment et en ressortent heureux, c'est peut-être ça l'essentiel sur lequel vous devriez vous concentrer (avec les développeurs vous n'aurez que des ennuis). Ah mais ils sont une partie importante de votre vision de l'agilité ? Bah, faisons comme si ils plantaient des clous, ça sera plus facile à vendre.

Allez j'arrête ! C'est pas moi qui vais vous apprendre votre job, pas vrai ? ^^

Allez je suis gentil, voici la vraie raison : votre pitch vise à démontrer l'importance du refactoring (écarts de langage mis à part) ? ils connaissent déjà -> refus. Une couche de "mob programming" hype et marketing ? le marketing ils s'en foutent -> refus.
Pour comprendre ce qu'ils pourraient accepter, voir plus haut.

Razorgore 9 avril 2014 - 18:24
opatou

Bonjour Olivier,

Je ne connais pas (encore) ton jeu, mais ton propos me fait penser à plusieurs expériences personnelles :

La première me vient des cours de communication en école d'ingénieur : je crois que que l'on était deux (je dis ça pour me sentir moins seul) à trouver le cours intéressant. Les technos c'est ce qui intéresse les développeurs! A quoi ça sert de communiquer, collaborer lorsque l'on est seul devant un écran et avec un chef qui te dit ce que tu dois faire, et comment le faire...
Une attitude déprimante au regard de l'agilité.

L'autre souvenir qui me revient, ce sont les entretiens d'embauches que j'ai vécu comme développeur : on te demande d'être très pointu sur les technos (ce qui n'était pas mon cas), et quand je disais que faire du .net ou du java, c'est pareil, qu'il existe des objets, des librairies et qu'il suffit de savoir s'en servir au travers d'un ide que l'on maîtrise la plupart des recruteurs regardaient de travers.

Le point commun que je vois entre ces différentes expériences est que les intérêts et leur perceptions sont différents selon nos sensibilités.
Par exemple, le pitch de ton jeu m'attire beaucoup ainsi que les commentaires que j'ai pu lire, mais je sais qu'un jeu est pertinent et efficace pour apprendre. Il faut peut-être avancer masqué et le proposer avec une finalité qui va intéresser le public que tu vises :
Je vais donc écrire une grosse b^tise pour illustrer mon propos : présenter ton jeu dans un contexte différent : "découvrir les nouveautés de java 8 illustrées par un jeu de balles!"

opatou 11 avril 2014 - 19:35
Oaz

@razorgore,

J'ai répondu dans un nouveau billet.

@opatou,

Merci pour la suggestion :-)
Malheureusement, le jeu ne permet pas de découvrir les nouveautés de Java 8 ! Mais je comprends bien l'idée, il me reste à trouver une motivation technique en rapport avec le sujet...

Oaz 13 avril 2014 - 15:59
gregory

@Razorgore:
c'est quoi cet énorme troll ?

Si le refactoring et SOLID ça fait pas parti du quotidien des développeurs, on doit pas parler du même métier.

Puis connaitre SOLID c'est pas comme aller faire ses courses (ça c'est fait), après des années de pratiques tu te poses toujours des questions.

Enfin pour ta définiton de "refactoring", quoi dire... si ce n'est que tu n'en as pas fait un seul dans ta vie.
Là aussi, on a pas du faire le même jeu, quand je vois "duplication" je pense "code smell" puis "refactoring".
Le jeu permet de "voir" des "odeurs", et la réaction des participants est intéressante, ils appliquent un refactoring typique de ceux que l'on retrouve dans les catalogues des livres/sites sur le sujet.

@oaz
Entre ton premier essai au séminaire sigmat et la version actuelle du jeu, il y a l'air d'y avoir eu beaucoup d'améliorations, j'ai hate d'y jouer prochainement au SWT et j'espère qu'on pourra t'amener des retours intéressants.

gregory 15 avril 2014 - 11:54
rguitter

Désolé j'avais pas vu ta réponse à mon commentaire concernant l'apprentissage des enfants.
Je suis allé voir ton post ou tu parles de tes filles et de comment tu ne rates jamais une occasion de leur montrer ce qui se cache derrière. L'interface du jeu Chavanturier me rappelle un truc que j'ai déjà vu mais je ne sais plus ou, je m'étais fait la réflexion que c'était justement très bien pour un enfant :)

Pour en revenir à mon premier commentaire, disont que la cible n'était pas forcément des enfants, ce que je voulais dire c'est que cette cible n'est pas obligatoirement des développeurs. Les processus qui sont utilisés pour développer se retrouvent dans d'autres tâches et on peut parfaitement illustrer avec un point de vue (pas trop) technique un principe beaucoup plus large. Tu aurais alors en face de toi des personnes surement plus sensibles à ton approche. J'ai un copain qui avait donné une session lors d'une conférence agile à Bruxelles ou il présentait les travaux d'un psychologue du début du XX siècle suivi d'un ingénieur de chez Xerox (celui qui a inventé le principe GUI). Il expliquait par un simple jeu impliquant un verre d'eau, comme la mémoire musculaire (en fait le geste) avait une valeur qui précèdait même la valeur iconique des fenêtres. Il voulait par là expliquer pourquoi, en agile, le fait de bouger physiquement un post it sur un wall lors du stand up était important. C'était très intéressant, même pour un non agiliste :)

rguitter 3 juin 2014 - 16:44

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.