L'AgilitateurCréation de logiciels : de l'agilité à l'artisanat2021-10-09T15:11:31+02:00urn:md5:7668924f626a6543fa389f1b4e47e529DotclearRaconter l'histoire collectiveurn:md5:66eea5e713190d51d0fc9e1eb65932dc2019-10-27T19:30:00+00:002019-10-27T19:30:00+00:00Olivier AzeauEn français<p>Dans le monde professionnel, on a principalement deux sortes d'histoires. Les individus racontent leur histoire personnelle à travers leur CV et parfois sur les réseaux sociaux. Les entreprises, elles aussi, racontent leur histoire, souvent à travers une communication très contrôlée et réservée aux personnes "autorisées".<br />
Ce qui se passe entre les deux, les groupes, les équipes, est plus rarement raconté.</p> <p>Si l'équipe a la chance de réaliser un travail bien identifié, celui-ci peut se retrouver mis en lumière. Mais on reste souvent dans la communication de l'entreprise.<br />
Et il est normal, et sain, que les personnes qui sont derrière les réalisations veuillent en raconter un peu plus.<br /></p>
<p>J'aurais pu écrire à peu près la même chose que Guillaume sur ce produit ARIA eDoc. J'ai travaillé pendant plus de 10 ans dans l'équipe qui l'a créé. J'aurais juste rajouté que l'idée du produit a germé en janvier 2015. Les choses prennent souvent plus de temps qu'on ne l'imagine au départ et il est difficile de raconter quoi que ce soit sur un produit avant d'arriver à un impact tangible.</p>
<iframe src="https://www.linkedin.com/embed/feed/update/urn:li:share:6587328317869826049" allowfullscreen="" title="Embedded post" width="504" height="392" frameborder="0"></iframe>
<p><br />
Cela ne veut pas dire qu'on ne peut rien raconter dans l'intervalle. Il y a 11 ans, je faisais <a href="https://agilitateur.azeau.com/post/2008/12/03/Retour-d-exp%C3%A9rience">ma première communication publique sur le travail de cette équipe</a> à la communauté agile toulousaine naissante. Nous avions deux ans de Scrum derrière nous et un <a href="http://slides.azeau.com/20081212-scrumVMS/">bilan sous la forme d'un retour d'expérience</a> me semblait utile.<br />
J'ai recommencé quatre ans plus tard pour <a href="http://slides.azeau.com/20121025-Deux_ans_dans_le_flux.AT.Toulouse.svg">raconter la transition de Scrum vers un fonctionnement en flux</a> et tout ce que cela avait changé au sein de l'équipe.<br />
<br />
Le recrutement peut aussi fournir un cadre pour parler d'une équipe. Nous avions saisi cette occasion il y a deux ans sous le forme d'<a href="https://agilitateur.azeau.com/post/2018/01/19/Une-nouvelle-aventure">une annonce rédigée collectivement</a>.<br />
<br />
Je me réjouis de la reprise du flambeau par mes anciens collègues. La semaine dernière, à l'Agile Tour toulouse, Montaine a présenté l'évolution vers "le forum ouvert permanent" que nous avions initiée il y a un peu plus d'un an et, la semaine prochaine, lors de l'Agile Tour Bordeaux, <a href="http://agiletourbordeaux.fr/programme.html">Guillaume parlera de ses 10 ans avec le même code</a>.</p>
<iframe src="https://www.linkedin.com/embed/feed/update/urn:li:ugcPost:6593842284213612544" allowfullscreen="" title="Embedded post" width="504" height="510" frameborder="0"></iframe>
<p><br />
Je laisserai le mot de la fin à un tweet que j'ai vu ce week-end et qui tombe à pic.<br /></p>
<blockquote><p>On veut rester là où nous sommes reconnus, et non pas seulement tolérés.</p></blockquote>
<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Because you always want to stay where you are celebrated. Not tolerated. You want to grow. Never forget it is a trust game.</p>— JD (@JulienDollon) <a href="https://twitter.com/JulienDollon/status/1187835216137801743?ref_src=twsrc%5Etfw">October 25, 2019</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
Parcoursup, ou comment rater son "expérience utilisateur" avec un bon produiturn:md5:223b61445e281b968ebb6dcf93e8dd332018-06-01T08:25:00+01:002018-06-01T08:25:00+01:00Olivier AzeauEn français<p><img src="https://agilitateur.azeau.com/public/agilitateur/.feedback-2800867_960_720_m.png" alt="" style="float:right; margin: 0 0 1em 1em;" />Parcoursup, c'est le nouveau système d'orientation dans l'enseignement supérieur que tous les futurs bacheliers viennent d'expérimenter. Pour 2 utilisateurs sur 3, le calvaire n'est pas encore terminé, soit parce qu'ils espèrent encore avoir une meilleure affectation, soit, dans le pire des cas, parce qu'ils n'ont encore obtenu aucune place pour l'année prochaine.<br /></p>
<p>Sur le papier, Parcoursup est pourtant un bon système, bien meilleur que "Admission Post-Bac", son prédécesseur. Alors pourquoi génère-t-il autant de colère et de désarroi ?</p> <p>Quelques minutes sur twitter suffisent à comprendre l'ampleur de l'échec. Le nouvel outil d'orientation est devenu le <a href="https://twitter.com/search?f=tweets&vertical=default&q=%23ParcoursSupercherie">#ParcoursSupercherie</a>. Certains ont dépassé le stade de la grogne et commencent à bloquer des lycées...<br /></p>
<p>Quand on prend le recul nécessaire pour comparer le système actuel et le précédent, cette catastrophe est, au premier abord, très surprenante.<br />
Malgré le grand nombre de bacheliers supplémentaires (environ 28000) dus au "baby-boom" de l'an 2000, moins de candidats ont formulé un vœu pour entrer, ou se réorienter, dans l'enseignement supérieur. L'an dernier, <a href="https://www.lemonde.fr/campus/article/2017/03/28/hausse-du-nombre-de-candidats-en-premiere-annee-d-etudes-superieures_5101968_4401467.html" hreflang="fr">le chiffre de 853262 candidats avait été annoncé</a> pour APB. Cette année, ils ont été 812055 à formuler au moins un vœu sur Parcoursup.<br />
Il y a, par ailleurs, <a href="https://www.radioclassique.fr/magazine/articles/100-000-places-vacantes-lenseignement-superieur-frederique-vidal/" hreflang="fr">100000 places vacantes dans l'enseignement supérieur</a>. Il n'y a donc pas de problème de place dans l'absolu mais un problème d'adéquation de l'offre avec la demande.<br /></p>
<p>Il est aujourd'hui facile de critiquer Parcoursup, mais combien se sont penchés sur ce qu'était APB et sur ce qui a été amélioré ?<br />
APB était pensé pour maximiser le remplissage. Pour toutes les formations dites "non-sélectives", le critère de remplissage était relativement simple<sup>[<a href="https://agilitateur.azeau.com/post/2018/06/01/Parcoursup%2C-ou-comment-rater-son-exp%C3%A9rience-utilisateur-avec-un-bon-produit#wiki-footnote-1" id="rev-wiki-footnote-1">1</a>]</sup> : les candidats ayant trié leurs vœux, ceux qui ont classé la formation en vœu 1 sont pris les premiers, suivis par ceux qui l'ont mise en vœu 2 (s'ils n'ont pas eu leur premier vœu par ailleurs) et ainsi de suite jusqu'à ce que le nombre de places disponibles soit atteint.<br />
Parmi ces filières non-sélectives, certaines sont dites "en tension", ce qui signifie que il n'y a pas assez de place pour accepter tous les candidats l'ayant mis en 1er vœu. Dans ce cas là, on faisait un tirage au sort...<sup>[<a href="https://agilitateur.azeau.com/post/2018/06/01/Parcoursup%2C-ou-comment-rater-son-exp%C3%A9rience-utilisateur-avec-un-bon-produit#wiki-footnote-2" id="rev-wiki-footnote-2">2</a>]</sup><br /></p>
<p>Avec Parcoursup, la logique est sensiblement modifiée. Les candidats ne trient plus leurs vœux. Il n'est donc plus possible d'affecter automatiquement les candidats dans les formations.<br />
Les enseignants ont donc dû ordonner les demandes reçues et l'algorithme se retrouve largement simplifié : il se contente de faire des propositions aux candidats les mieux classés et met les autres en liste d'attente. L'énorme avantage, pour tous les candidats et pas seulement les mieux classés, c'est qu'ils vont pouvoir réellement choisir leur formation préférée et ne pas se retrouver automatiquement affectés. L'inconvénient, c'est que ça va prendre plus de temps pour arriver au bout.<br /></p>
<p>Les algorithmes d'affectation dans l'enseignement ne sont pas un problème simple. Si vous avez une grosse heure devant vous, <a href="https://www.youtube.com/watch?v=oprFPrZcNq4" hreflang="fr">cette excellente présentation en donne un aperçu</a>. Le principal défaut d'APB était que le rang dans lequel on mettait un vœu avait une grosse influence sur le résultat : le candidat naïf qui triait ses vœux sans autre stratégie que sa préférence était désavantagé par rapport à celui qui savait tirer parti de l'algorithme. Parcoursup est un énorme pas vers une meilleure solution.<br /></p>
<p>Mais alors, si Parcoursup est si bien que ça, pourquoi tant de réactions catastrophiques ?<br />
Une explication possible, c'est le marketing. Si <a href="https://www.lemonde.fr/campus/article/2017/12/13/melenchon-premier-opposant-a-la-reforme-de-l-acces-a-l-universite_5229019_4401467.html" hreflang="fr">les critiques d'un produit prennent le dessus dans les media 6 mois avant la sortie</a>, ce n'est jamais bon. Il n'est d'ailleurs pas utile que ces critiques soient justifiées . "Calomniez, calomniez, il en restera toujours quelque chose".<br /></p>
<p>La raison principale, c'est probablement l'"expérience utilisateur" des candidats lorsque les premiers résultats sont arrivés. Là où APB arrivait avec du positif <em>"Vous êtes pris dans cette formation. C'est peut être pas votre préférée mais on s'en fiche, c'est quand même génial, non ? Vous allez continuer vos études !"</em>, Parcoursup arrive avec du négatif <em>"Vous êtes en liste d'attente à peu près partout"</em>. De fait, la plupart des candidats sont, soit déjà admis dans leur formation préférée, soit encore en liste d'attente pour celle-ci. Seuls 3% des candidats se sont vus refuser tous leurs vœux car ils ne voulaient que des filières sélectives.</p>
<p>Le problème n'est donc pas le résultat final des affectations - il sera inévitablement au moins aussi bon que celui d'APB - mais la perception de ce résultat alors que la procédure n'en est qu'à ses débuts. Entre la peur de l'inconnu et la difficulté à se projeter dans l'avenir, les informations en apparence bonnes sont préférables à celles en apparence mauvaise.<br />
Parcoursup doit et peut s'améliorer sur ces points. Les mauvaises nouvelles doivent être masquées. On peut facilement imaginer quelques pistes :<sup>[<a href="https://agilitateur.azeau.com/post/2018/06/01/Parcoursup%2C-ou-comment-rater-son-exp%C3%A9rience-utilisateur-avec-un-bon-produit#wiki-footnote-3" id="rev-wiki-footnote-3">3</a>]</sup></p>
<ul>
<li>demander a priori à chaque candidat quel serait son choix définitif dans les cas où il n'aurait que 2 réponses positives et ce pour tous les couples de vœux effectués par le candidat.</li>
<li>la même chose mais dans seulement une 2ème phase, ce qui permettrait de limiter le nombre d'informations à saisir (les réponses négatives seraient d'entrée exclues)</li>
<li>la même chose mais au fil de l'eau ce qui limiterait encore plus les informations à saisir. Il faudrait toutefois demander des informations potentiellement inutiles pour noyer le poisson car si on ne demande au candidat que des informations sur les réponses positives, on retombe dans la même logique de peur "si on ne me demande rien sur cette formation c'est que je n'ai aucune chance de l'avoir"</li>
<li>on peut aussi mixer les approches : demande a priori + possibilité de changer d'avis en cours de route</li>
</ul>
<p>Dans tous les cas de figure, il semblerait utile de ne rien divulguer sur les réponses avant la fin des épreuves du bac. Qui a besoin d'en savoir plus avant début juillet ? Les quelques élèves qui ne se soucient pas du bac et se projettent déjà dans l'année suivante peuvent bien attendre 4 ou 5 semaines.<br /></p>
<p>Créer un système logiciel ne s'improvise pas. Ce sont même des métiers à part entière. Malgré toutes ses qualités théoriques, la conception de Parcoursup a oublié ces évidences.<br />
Il ne reste qu'à espérer que le mal n'a pas été fait, que la confiance dans le système restera, et que la mouture 2019 sera bien meilleure<sup>[<a href="https://agilitateur.azeau.com/post/2018/06/01/Parcoursup%2C-ou-comment-rater-son-exp%C3%A9rience-utilisateur-avec-un-bon-produit#wiki-footnote-4" id="rev-wiki-footnote-4">4</a>]</sup>.</p>
<div class="footnotes"><h4>Notes</h4>
<p>[<a href="https://agilitateur.azeau.com/post/2018/06/01/Parcoursup%2C-ou-comment-rater-son-exp%C3%A9rience-utilisateur-avec-un-bon-produit#rev-wiki-footnote-1" id="wiki-footnote-1">1</a>] en fait, c'est un peu plus compliqué mais je schématise...</p>
<p>[<a href="https://agilitateur.azeau.com/post/2018/06/01/Parcoursup%2C-ou-comment-rater-son-exp%C3%A9rience-utilisateur-avec-un-bon-produit#rev-wiki-footnote-2" id="wiki-footnote-2">2</a>] En théorie, le tirage au sort n'est pas limité au vœu 1 car c'est le moyen pour départager mais, en pratique, les cas sont probablement rares</p>
<p>[<a href="https://agilitateur.azeau.com/post/2018/06/01/Parcoursup%2C-ou-comment-rater-son-exp%C3%A9rience-utilisateur-avec-un-bon-produit#rev-wiki-footnote-3" id="wiki-footnote-3">3</a>] les spécialistes du domaine auront probablement de bien meilleures idées</p>
<p>[<a href="https://agilitateur.azeau.com/post/2018/06/01/Parcoursup%2C-ou-comment-rater-son-exp%C3%A9rience-utilisateur-avec-un-bon-produit#rev-wiki-footnote-4" id="wiki-footnote-4">4</a>] À titre personnel, je serai concerné par celle-ci en tant que parent. J'y porterai donc probablement une attention encore plus grande...</p></div>
Une nouvelle aventure ?urn:md5:987f6b9686cfda9b9131cf676e2300382018-01-19T08:30:00+00:002018-01-19T08:30:00+00:00Olivier AzeauEn français<p>On pouvait lire ceci en 4ème de couverture du livre :</p> <style>
.local {
margin-left: 40px;
}
.local p {
font-style: oblique;
}
</style>
<div class="local">
<p>2018. Le système d’information en oncologie ARIA® est utilisé par plus de 4000 hôpitaux dans le monde. Une des équipes participant à son développement s’est spécialisée dans la création de produits logiciels répondant aux besoins spécifiques de plusieurs pays.<br/>
Leur but ? Accompagner les personnels soignants et administratifs et faciliter leur transition vers plus d’efficacité pour guérir les patients.</p>
<p>Innovante, enjouée, solidaire. Les adjectifs ne manquent pas pour décrire cette équipe toulousaine du groupe Varian Medical Systems. On la dit aussi agile même si « extreme programming » serait plus précis pour qualifier ses pratiques de développement. La communication et le respect de la diversité des points de vue sont un effort de tous les jours.</p>
<p>Avec l’émergence permanente de nouveaux besoins et l’évolution de sa base technique qui oscille entre .NET et HTML5, cette équipe a aujourd’hui envie de se renforcer.<br/>
Son attention permanente à la formation continue et au bien-être au travail seront les atouts majeurs sur lesquels elle pourra compter pour franchir un nouveau cap.
</p>
</div>
<p>Le livre reste à écrire.<br />
Voulez-vous rejoindre Cécile, Chrystelle, Guillaume, Montaine, Olivier, Sophie et Stéphane dans leurs nouveaux défis ?<br />
Etes-vous prêts pour l’aventure ? Et, surtout, quelle place y tiendrez-vous ?<sup>[<a href="https://agilitateur.azeau.com/post/2018/01/19/Une-nouvelle-aventure#wiki-footnote-1" id="rev-wiki-footnote-1">1</a>]</sup><br /></p>
<div class="footnotes"><h4>Note</h4>
<p>[<a href="https://agilitateur.azeau.com/post/2018/01/19/Une-nouvelle-aventure#rev-wiki-footnote-1" id="wiki-footnote-1">1</a>] Le texte de cette annonce a été collectivement rédigé par l'équipe en question. L'annonce "officielle" est également <a href="https://sjobs.brassring.com/TGnewUI/Search/home/HomeWithPreLoad?partnerid=25044&siteid=5224&PageType=JobDetails&jobid=1219167#jobDetails=1219167_5224" hreflang="en" title="Software Engineer">visible en ligne</a>. Pour plus de détails vous pouvez directement <a href="https://agilitateur.azeau.com/contact" hreflang="fr" title="Contact">me contacter</a>.</p></div>
Des histoires et du code, une autre voie pour inciter à regarder ce qui se passe dans l'ordinateur ?urn:md5:1ac13165800a4a204db165828a6c05a32017-11-27T08:37:00+00:002017-11-27T08:37:00+00:00Olivier Azeau<p>Il existe aujourd'hui des dizaines d'outils pour donner envie aux novices, en particulier les jeunes, de comprendre ce qu'il y a derrière l'écran d'un ordinateur. Il y a toutefois une approche qui me semble encore sous exploitée : celle qui a fait germer une telle envie à quelques jeunes d'il y a 30 ans.</p> <p>Les jeunes d'aujourd'hui, malgré leur hyper-connexion, ne savent pas forcément plus que leurs aînés ce qui se passe dans un ordinateur. <a href="https://framablog.org/2013/06/11/francois-elie-education-conference/" hreflang="fr">François Élie le dit bien mieux que moi</a> :</p>
<pre>
Alors on nous rebat les oreilles avec la génération Y. Ces enfants qui auraient eu des cours d’informatique intra-utérins et qui sauraient tout déjà et qui n’auraient rien à apprendre et qui en savent plus que nous. J’ai commencé avec un ZX81 et je plains sincèrement ceux qui commencent avec un smartphone. Ils jouent avec, ils ont un clickodrome et avec des gigas de mémoire vive, ils en font moins que nous avec 1 kilo, j’avais même acheté 1 kilo supplémentaire pour faire plus de choses. La vrai génération Y c’est la nôtre, c’est la mienne, ce n’est pas celle d’aujourd’hui. Ce sont les gens qui ont vu naître l’informatique qui arrivait et qui quittait les gros ordinateurs, juste avant le verrouillage du PC, au moment où on échangeait du code, on apprenait, on apprenait de l’assembleur, on jouait avec.
</pre>
<p><br />
Les initiatives pour initier à la programmation aux jeunes d'aujourd'hui ne manquent pas.<br /></p>
<p>On peut les classer, à mon sens, en 3 catégories :</p>
<ul>
<li><strong>le graphisme et les jeux vidéo</strong>. Il y a une multitude d'outils ou sites web , <a href="https://scratch.mit.edu/">Scratch</a> en tête, qui permettent de rentrer dans la programmation en faisant bouger des trucs graphiques à l'écran qui réagissent à la souris ou au clavier. C'est l'approche la plus répandue et elle est désormais entrée dans les écoles et collèges.</li>
<li><strong>les objets connectés</strong>. Il y a de plus en plus de robots et objets divers que l'on peut aisément programmer pour agir sur (et réagir à) leur environnement. L'essor d'Arduino n'est pas étranger à cela.</li>
<li><strong>les mathématiques</strong>. La programmation présente dans les lycées est, avant tout, vue comme un auxiliaire des mathématiques. Il n'y a qu'à regarder les sujets de bac pour s'en convaincre.</li>
</ul>
<p>Maintenant regardons cet extrait de code, issu du guide du Thomson MO5 en 1984 :
<a href="https://agilitateur.azeau.com/public/agilitateur/education/MO5-Entrez-votre-nom.png"><img src="https://agilitateur.azeau.com/public/agilitateur/education/.MO5-Entrez-votre-nom_m.png" alt="" style="display:table; margin:0 auto;" /></a></p>
<p>Rien de graphiquement spectaculaire ni de mathématiquement compliqué.<br />
<br /></p>
<p>En 1984, il suffisait d'un petit programme qui donnait l'impression que l'ordinateur était intelligent pour piquer la curiosité et donner envie de voir ce qu'il y a derrière.<br />
Pourrait-il en être de même aujourd’hui ?<br /></p>
<p>J'ai fait un petit bricolage à base de <a href="https://developers.google.com/blockly/">Blockly</a> qui donne un environnement minimaliste de programmation limitée à du texte :<br /></p>
<h4><a href="https://histoires.mnt.space/">https://histoires.mnt.space/</a></h4>
<p>L'idée c'est de permettre, à partir de quelques blocs de code, de construire un échange textuel entre un humain et la machine à la manière de ce que l'on pouvait faire simplement avec des "PRINT" et des "INPUT" en langage BASIC.<br />
Si jamais vous l'essayez ou le faites essayer, je suis curieux d'avoir des retours sur la prise en main du machin (commentaires ci-dessous ou <a href="https://agilitateur.azeau.com/contact">formulaire de contact</a>).</p>10 ans d'Agile Tour à Toulouseurn:md5:b5e40176dec33203d1b700514b3afafc2017-10-06T07:27:00+01:002017-10-06T07:27:00+01:00Olivier AzeauEn français<p><img src="https://agilitateur.azeau.com/public/agilitateur/.logo_AgileToulouse_625x625_s.png" alt="" style="float:right; margin: 0 0 1em 1em;" />
Les 26 et 27 octobre prochains, je serai à <a href="http://la-grainerie.net/" hreflang="fr">la Grainerie</a> pour la 10ème édition de l'<a href="http://tour.agiletoulouse.fr/" hreflang="fr">Agile Tour Toulouse</a>.</p> <p>Je n'ai pas forcément envie de la jouer "ancien combattant" mais, il y a un peu plus de 10 ans, je participais au <a href="https://agilitateur.azeau.com/post/2007/03/16/SIGMAT-20" hreflang="fr">deuxième Séminaire d'Information Gratuit sur les Méthodes Agiles de Toulouse</a> organisé par <a href="http://www.aubryconseil.com/" hreflang="fr">Claude</a> et jamais je n'aurais cru que l'on serait encore là aujourd'hui. Ces séminaires étaient (à peu près) trimestriels et le 7ème d'entre eux, le 16 octobre 2008, fut en fait la 1ère édition de l'Agile Tour Toulouse. L'organisation se déroula, comme pour les autres séminaires, au <a href="http://www.lachunga-hoegaardencafe.fr/">QG historique</a> avec Claude, <a href="http://www.toltequeagile.com">Thierry</a> et Jean-Marie qui nous avait rejoint depuis peu.<br />
<br />
Agile Tour était <a href="http://at2008.agiletour.org/contact.html">une initiative parisienne</a> et on ne savait pas trop comment se positionner face à ce que l'on ressentait comme "Paris vient expliquer aux provinciaux ce que sont les méthodes agiles". Je crois que c'est Claude qui avait le mieux résumé la situation "on n'a pas forcément envie de le faire mais on n'a surtout pas envie que ça se fasse à Toulouse sans nous".<br />
Au final, nos craintes n'étaient pas tellement fondées et <a href="http://at2008.agiletour.org/programme_toulouse.html" hreflang="fr">le programme de cette première édition</a> avait quand même une belle gueule avec <a href="https://en.wikipedia.org/wiki/Philippe_Kruchten" hreflang="en">Philippe Krutchen</a> en tête d'affiche. Pour ma part, j'ai eu droit à débuter la 1ère présentation avec un historique des méthodes agiles. Je parlais pour la 1ère fois de ma vie face à un amphi de l'université Paul Sabatier plein à craquer. Je me souviens surtout du stress et je ne suis pas sûr d'avoir été très clair dans mes propos...<br />
<br />
Dans la foulée, la <a href="https://agilitateur.azeau.com/post/2009/03/26/Soci%C3%A9t%C3%A9-des-Innovateurs-pour-la-G%C3%A9n%C3%A9ralisation-de-M%C3%A9thodes-Agiles-de-Toulouse">Société des Innovateurs pour la Généralisation de Méthodes Agiles de Toulouse</a> était créée en janvier 2009 pour pérenniser l'organisation de ces événements. Ayant eu d'autres priorités, je ne me suis pas trop impliqué dans l'organisation des Agile Tour Toulouse suivants. J'ai quand même eu le plaisir d'y <a href="http://at2009.agiletour.org/en/at2009_toulouse_programmation.html">animer en 2009 un atelier de TDD</a> en profitant des installations de l'IUT de Blagnac. En 2010, j'y ai encore tenté du TDD mais cette fois le code était <a href="https://agilitateur.azeau.com/post/2010/09/05/Stub-et-Mock-montent-sur-sc%C3%A8ne">"joué" par des composants logiciels humains</a>.<br />
<br />
En 2011, l'Agile Tour Toulouse déménage à Diagora. Il y restera pendant 3 ans. Le bureau de l'association a été renouvelé et la nouvelle équipe emmenée par <a href="http://duffau.consulting" hreflang="fr">Frédéric</a> (et sa légendaire casquette) organise un événement d'une toute autre dimension : près de 500 participants, des "keynotes" et beaucoup plus de sessions en parallèle.<br />
C'est toujours l'occasion pour moi d'animer quelques sessions. En 2011, j'ai repris mes composants logiciels humains pour illustrer des principes de conception dans "Si t'es pas SOLID, t'es pas agile" et j'ai transformé les "apprenticeship patterns" en jeu de carte dans "Quand je serai grand, je serai artisan du logiciel". En 2012, avec "Deux ans dans le flux", je parle pour la première fois de l'équipe dans laquelle je travaille. 2013 est l'exception qui confirme la règle : étant l'animateur du comité de sélection, je choisis de ne proposer aucun sujet.<br />
<br />
L'association SIGMAT a été renommée en "Agile Toulouse" et s'est par la suite, dotée d'une direction collégiale mais s'il est une constante, c'est bien le changement. Chaque renouvellement majeur du bureau de l'association apporte son lot de nouveauté à l'Agile Tour. En 2014, pour la 7ème édition, cela sera un cadre original (la maison de la recherche et de la valorisation) et, pour la première fois, un événement sur 2 jours. Pour ma part, je trouve encore le moyen d'y animer un truc. Cette fois, ce sera la pièce de théâtre <a href="https://agilitateur.azeau.com/public/doublures-en-folie/doublures-en-folie.v1.html" hreflang="fr">"Doublures en Folie"</a>.<br />
L'année suivante, les 2 journées restent et le lieu devient encore plus original : <a href="http://la-grainerie.net/" hreflang="fr">un espace dédié aux arts du cirque</a>. Avec une présentation sur <a href="https://agilitateur.azeau.com/post/2015/10/25/%C3%87a-prendra-combien-de-temps" hreflang="fr">la question des estimations</a>, je m'essaie, avec plus ou moins de réussite, au format 20 minutes dans une salle assez impressionnante où l'espace dont dispose l'orateur est plus grand que celui où est entassé un public pourtant bien nombreux. En 2016, le format et les salles ne changent pas et j'y reviens pour présenter un sujet sur l'artisanat du logiciel.<br />
<br />
Ces dernières années ont aussi été celles d'une ouverture vers des intervenants qui ne sont pas issus du monde de l'agilité : <a href="https://fr.wikipedia.org/wiki/Dani%C3%A8le_Linhart" hreflang="fr">Danièle Linhart</a> en 2015, <a href="https://fr.wikipedia.org/wiki/Marc_Hal%C3%A9vy" hreflang="fr">Marc Halévy</a> en 2016.<br />
2017 sera dans la continuité de cette approche avec <a href="http://www.malarewicz.fr/" hreflang="fr">Jacques Antoine Malarewicz</a> et <a href="https://pedagogieagile.com/" hreflang="fr">Christian den Hartigh</a>.<br />
<br />
Je n'ai aucune information particulière sur cette 10ème édition mais je sais qu'elle sera à la fois dans la lignée des années passées et qu'elle apportera son lot de nouveautés.<br />
Si vous êtes encore en train de lire ce texte et que vous n'êtes pas encore inscrit, <a href="https://www.weezevent.com/agile-tour-toulouse-2017-jour-1">qu'attendez-vous donc pour le faire ?</a><br />
Et si vous êtes intéressés par la 2ème journée, dépechez-vous, <a href="https://www.weezevent.com/agile-tour-toulouse-2017-jour-2">il ne reste presque plus de places</a>.<br />
<br />
<br />
PS: si jamais vous venez le 26 octobre et que, malgré tout ce que j'ai pu écrire, la matinée ne vous enchante pas (ce qui serait étonnant), passez-donc me voir l'après-midi. J'animerai une session de jeu <a href="https://github.com/Oaz/MonEntrepriseAgile" hreflang="fr">"Mon entreprise agile"</a>.</p>Steve Wozniak is not boringurn:md5:675960135fc9e68c4c9d3948d022b4df2016-09-10T21:45:00+01:002016-09-10T21:45:00+01:00Olivier AzeauIn Englishanti-ifcsharpgolanggotorefactoring<p>I saw <a href="https://twitter.com/francesc/status/774438145433534466">this tweet</a> a few hours ago and found the piece of code quite interesting: a small algorithm with searches, logic, external interaction and a nice comment explaining the whole thing. I could have written this kind of code ten years ago. Today, my problem is that my eyes start bleeding when I bump into a mix of loop and conditions, especially when the mix cannot be easily tested.<br />
Let's try to write it differently.</p> <p>First, let's have a look at the code.
<a href="https://agilitateur.azeau.com/public/agilitateur/boringWozniakGoLang.jpeg" title="boringWozniakGoLang.jpeg"><img src="https://agilitateur.azeau.com/public/agilitateur/.boringWozniakGoLang_m.jpg" alt="boringWozniakGoLang.jpeg" style="display:table; margin:0 auto;" title="boringWozniakGoLang.jpeg, sept. 2016" /></a></p>
<p>We hope to write it in a different way but we first need a safety net to avoid changes in the code behaviour. We usually have test cases for that.<br />
Since this code uses a random number generator, we cannot really test it as is. A classic technique is to decouple the random number generator so that we can inject a fake one (called a 'stub') during the tests.</p>
<p>Since I don't know much about the Go language, I will first convert the code to a language I'm more familiar with (here C#). The two codes are almost identical.</p>
<pre class="brush: csharp;">
// GetRandomName generates a random name from the list of adjectives and surnames in this package
// formatted as "adjective_surname". For example 'focused_turing'. If retry is non-zero, a random
// integer between 0 and 10 will be added to the end of the name, e.g `focused_turing3`
public static string GetRandomName(int retry)
{
var rnd = new Random();
begin:
var name = string.Format ("{0}_{1}", left[rnd.Next(left.Length)], right[rnd.Next(right.Length)]);
if( name == "boring_wozniak" )/* Steve Wozniak is not boring */
{
goto begin;
}
if( retry > 0 )
{
name = string.Format ("{0}{1}", name, rnd.Next(10));
}
return name;
}
</pre>
<p>Now I can decouple the random number generation</p>
<pre class="brush: csharp;">
public static string GetRandomName(int retry)
{
var rnd = new Random();
return GetRandomName(retry, max => rnd.Next(max));
}
public static string GetRandomName(int retry, Func<int,int> rnd)
{
begin:
var name = string.Format ("{0}_{1}", left[rnd(left.Length)], right[rnd(right.Length)]);
if( name == "boring_wozniak" )/* Steve Wozniak is not boring */
{
goto begin;
}
if( retry > 0 )
{
name = string.Format ("{0}{1}", name, rnd(10));
}
return name;
}
</pre>
<p>At this point, we can write a bunch of tests. These tests will serve 2 purposes:</p>
<ul>
<li>provide a safety net for refactoring</li>
<li>document the program behaviour</li>
</ul>
<p>The 2nd purpose allows us to remove part of the comments: the examples ('focused_turing', 'focused_turing3') and the whys ("Steve Wozniak is not boring").<br />
They are better written as plain code because the code cannot lie.<br /></p>
<p>The full set of tests is <a href="https://github.com/Oaz/BoringWozniak/blob/master/Tests/Test.cs">here on github</a>.<br />
The tests are better than comments because when the code becomes wrong, for example, if remove the "boring_wozniak" condition, a good test tells me why the code is not correct:
<img src="https://agilitateur.azeau.com/public/agilitateur/SteveWozniakIsNotBoring.png" alt="SteveWozniakIsNotBoring.png" style="display:table; margin:0 auto;" title="SteveWozniakIsNotBoring.png, sept. 2016" /></p>
<p>Now we can try to remove the mix of loop and conditions.<br />
I have no problem with the use of goto but a mix of "goto" and "if" leads to unnecessary complicated code. Here, the goto serves a single purpose: loop over the names generation.<br />
Here is an alternate implementation where the loop is decoupled from the conditions:</p>
<pre class="brush: csharp;">
private static IEnumerable<string> RandomNames(Func<int,int> rnd, Func<string,string,string> format)
{
begin:
yield return format(adjectives[rnd(adjectives.Length)], surnames[rnd(surnames.Length)]);
goto begin;
}
</pre>
<p>Being given an enumeration of random names, the main logic becomes easier to write: we want the first name which is not "boring_wozniak" and we want to concatenate it with an optional suffix:</p>
<pre class="brush: csharp;">
public static string GetRandomName(int retry, Func<int,int> rnd)
{
var baseName = RandomNames (rnd, (adjective, surname) => string.Format ("{0}_{1}", adjective, surname))
.First (name => name != "boring_wozniak");
var optionalSuffix = (retry > 0) ? rnd (10).ToString () : string.Empty;
return baseName + optionalSuffix;
}
</pre>
<p>When the code is written this way, I no longer feel the need for a comment explaining what is going on. The logic is now written with immutable variables. We no longer have to scratch our head about this "name" variable whose value could change many times.<br />
The conditions are no longer if blocks and, as a consequence, have a narrow focus. One of them just just taking the first item verifying some predicate in an enumeration.
The other one is now a ternary conditional operator where we just choose between two values without any side effect.</p>
<p>Is the final code much better, as I tend to think, or am I just splitting hairs?
What do you think?</p>Agile Tour Bordeaux 2015 : merci !urn:md5:5ad3b4915417cc584ef799c1a8ff36502015-10-31T18:28:00+01:002015-10-31T18:36:16+01:00Olivier AzeauEn français<p>Je profite du train qui me ramène à Toulouse pour écrire un petit billet de remerciement pour les organisateurs d'<a href="http://agiletourbordeaux.fr/">Agile Tour Bordeaux</a> 2015.</p> <p>Après un trajet Toulouse-Bordeaux avec <a href="http://frederic-duffau.strikingly.com">Fred</a>, mon premier constat en arrivant à l'hôtel est que, non seulement l'entrée à la conférence est gratuite mais les orateurs sont particulièrement bien accueillis : un 4 étoiles à deux pas du lieu des festivités.<br />
<br />
Vendredi matin, le ton de cette 7ème édition est donné par <a href="http://ploum.net/">ploum</a> qui nous parle du "bonheur sans travail", un excellent contre-pied aux débats actuels sur le "bonheur au travail". Je ne vais pas résumer les propos. D'autres le font bien mieux que moi, <a href="https://twitter.com/AurelienMorvant/status/660014875251507200">en l'occurrence Aurélien</a> :<br />
<img src="https://pbs.twimg.com/media/CSjYBTuW4AAmsCc.jpg" alt="" /><br />
<br />
Je retiens aussi qu'il me faut lire cet ebook : <a href="https://ploum.net/lentreprise-qui-nexistait-pas/">L’entreprise qui n’existait pas</a>.<br />
Pour la première session de la matinée, je ne peux pas manquer <a href="http://ut7.fr/index.html#apropos">le binôme Emmanuel-Jonathan</a> qui ne cesse de m'étonner. Ce coup-ci, ils ont pris leur Javascript et ils ont fait danser des poulpes dans Minecraft... Si vous voulez en faire autant, <a href="http://gnancraft.net/">ça se passe par ici</a>. Au delà de l'aspect ludique, la possibilité de coder à plusieurs simultanément et dans le même environnement est une métaphore intéressante à creuser.<br />
J'enchaîne avec le "happy hour" d'<a href="http://ayeba.fr/ayeba/equipe/">Isabel et Fabrice</a>. Un bon contenu sur la communication non violente mais je m'attendais à une session un peu plus interactive. J'en ressors là aussi avec un livre à lire : "Les mots sont des fenêtres" de Marshall Rosenberg.<br />
Après le repas, c'est l'heure de la sieste. C'est aussi l'heure de <a href="https://agilitateur.azeau.com/post/2015/10/25/%C3%87a-prendra-combien-de-temps">ma session sur les prévisions et les maths</a>. Le point positif c'est qu'avec une bonne centaine de personnes, le sujet intéresse. Le problème, c'est que j'ai visiblement mal choisi le contenu : les quelques rappels mathématiques étaient superflus pour certains et insuffisants pour d'autres. Au final, leur valeur est discutable. Ils gagneraient à être remplacés par un peu plus de contexte comme me l'a suggéré <a href="http://opatou.blogspot.fr/">Olivier</a>.<br />
Le choix pour la dernière session est difficile mais mon intérêt pour la combinaison méthodes agiles/éducation m'amène à aller voir un troisième binôme : <a href="https://twitter.com/martine__b">Martine</a> et <a href="https://twitter.com/idetido">Irène</a> qui nous parlent de leur enseignement <a href="http://mmibordeaux.com/">en IUT</a>. Enseigner les méthodes agiles à des étudiants n'est pas encore la norme mais n'a rien d'extraordinaire. Par contre, utiliser les méthodes agiles comme outil pédagogique, ça c'est fort. Je me demande à quel point la pratique est répandue danss l'enseignement supérieur.<br />
La journée se termine avec <a href="https://twitter.com/alexismonville">Alexis</a> qui, en echo à la session d'ouverture, nous parle de la recherche du bonheur.<br />
<a href="https://twitter.com/bastien_gallay/status/660122800284303360"><img src="https://pbs.twimg.com/media/CSk6L45WIAAVAa6.jpg" alt="" /></a><br />
<br />
Mon samedi matin est consacré à l'<a href="https://github.com/ordre-des-developpeurs">"ordre des développeurs"</a>. Après la keynote de <a href="https://twitter.com/bodysplash">Jean-Baptiste</a>, un atelier "constituant" nous permet de partager notre vision sur un tel "ordre". L'idée est encore balbutiante mais elle ne demande qu'à être étoffée par tous ceux qui se sentent concernés. Elle gagnerait à sortir notamment des cercles "agiles" pour aller toucher un plus grand nombre de développeurs, mais ceci est une autre histoire...<br />
Le samedi après-midi il y a un <a href="https://fr.wikipedia.org/wiki/M%C3%A9thodologie_Forum_Ouvert">Open Space</a> et un <a href="http://codinggouter.org/">Coding Goûter</a> (ça c'est l'avantage de faire un évènement qui déborde sur une partie du week-end) mais je dois déjà partir la tête pleine d'idées et heureux d'avoir été là.<br />
J'ai bien évidemment oublié de parler d'un tas de choses mais, comme je le dis souvent, des journées comme celles-là, il faut venir les vivre...<br />
Un grand merci à l'équipe d'organisation !</p>Ça prendra combien de temps ?urn:md5:c196fa84da3651e2ad747cc8a9e223db2015-10-25T13:45:00+01:002015-10-25T14:46:58+01:00Olivier AzeauEn français<p><img src="https://agilitateur.azeau.com/public/agilitateur/.Crystal-Ball_s.png" alt="Crystal-Ball.png" style="float:right; margin: 0 0 1em 1em;" title="Crystal-Ball.png, oct. 2015" />
Ceux qui n'ont jamais entendu cette question n'ont jamais participé à un projet informatique.<br />
Est-elle légitime ? Peut-être. Il parait que le temps c'est de l'argent.<br />
Est-elle, pour autant, une bonne raison pour contraindre les développeurs à jouer les madames Irma et les rendre responsables de la moindre panne de boule de cristal ?</p> <p>Ce sont des questions auxquelles je tenterai de répondre dans les jours à venir en présentant une session lors de ces trois rencontres agiles :</p>
<ul>
<li><a href="http://agiletourbordeaux.fr">Agile Tour Bordeaux</a> les 30 et 31 octobre</li>
<li><a href="http://2015.agile-grenoble.org/">Agile Grenoble</a> les 19 et 20 novembre</li>
<li><a href="http://agiletoulouse.strikingly.com/">Agile Tour Toulouse</a> les 26 et 27 novembre</li>
</ul>
<p>Le sujet n'est pas nouveau : je l'avais partiellement traité en présentant nos "deux ans dans le flux"<sup>[<a href="https://agilitateur.azeau.com/post/2015/10/25/%C3%87a-prendra-combien-de-temps#wiki-footnote-1" id="rev-wiki-footnote-1">1</a>]</sup>. Nos pratiques basées sur des probabilités pour prévoir les dates de livraison de telle ou telle fonctionnalité n'ont que peu évolué depuis trois ans mais le sujet du <a href="https://twitter.com/hashtag/NoEstimates">#NoEstimates</a> a, lui, depuis lors, pris une certaine ampleur. Et quand, en juin dernier, l'organisation d'Agile Tour Bordeaux m'a proposé de venir parler de tout ça, j'ai bien évidemment sauté sur l'occasion de concevoir une petite session sur le sujet.</p>
<p>De mon point de vue, les équipes qui créent des logiciels doivent être autonomes sur tout ce qui les concerne de près. Le recours à un "Project Management Office" qui gère des plannings n'est pas viable quand la complexité augmente. Tout bon "artisan du logiciel" devrait donc avoir dans son bagage des outils pour permettre à une équipe de prédire le contenu et les dates des prochaines livraisons en ne se basant pas uniquement sur l'intuition du développeur.</p>
<p>J'ai donc fait le choix de privilégier un contenu plutôt axé sur la simplification des estimations et la mise en pratique de techniques probabilistes. Cela ne veut pas dire que les aspects plus fondamentaux du #NoEstimates (pourquoi estimer ?, pourquoi ne pas estimer ?...) ne sont pas importants mais beaucoup de choses ont été dites à leur sujet et je n'ai absolument pas envie de faire une session-débat sur ces questions.<br />
Je m’attellerai donc à décrire ce qu'est une <a href="https://fr.wikipedia.org/wiki/Variable_al%C3%A9atoire">variable aléatoire</a> (en faisant aussi peu de maths que possible...), à expliquer pourquoi les chiffres intervenant dans les prévisions sont des variables aléatoires et à proposer une méthode pour répondre de diverses manières -en fonction du but recherché- à la question "ça prendra combien de temps ?".</p>
<div class="footnotes"><h4>Note</h4>
<p>[<a href="https://agilitateur.azeau.com/post/2015/10/25/%C3%87a-prendra-combien-de-temps#rev-wiki-footnote-1" id="wiki-footnote-1">1</a>] A <a href="http://www.mix-it.fr/session/198/deux-ans-dans-le-flux">Lyon</a>, à <a href="http://2013.conference-agile.fr/sessions/deux-ans-dans-le-flux.html">Paris</a> et ailleurs</p></div>
Mouvement(s) Agile(s) ?urn:md5:553cf27815ce897f8e71d9e5c0ce73ef2015-08-16T11:30:00+02:002015-08-16T11:30:00+02:00Olivier Azeau<p>Y a-t-il un seul et unique "mouvement agile" qui se décline en de multiples sensibilités ?<br />
C'est en tout cas ce que pense <a href="https://twitter.com/pablopernot">Pablo</a> et il l'explique dans son dernier billet <a href="http://www.areyouagile.com/2015/08/mouvement-agile/">Mouvement agile</a> dont je vous conseille la lecture. Si ce n'est déjà fait, allez donc faire un tour là-bas avant de poursuivre ici.</p> <p>La description de Pablo, si j'ai bien compris, ne vise pas à donner un historique précis des diverses approches mais plutôt à donner une vision d'ensemble en connectant les diverses sensibilités.<br />
J'ai pour ma part un problème avec la vision quasi "Darwinienne" qu'il présente. Le Lean serait donc le grand-père de toutes les approches ? Software Craftsmanship serait un descendant de Extreme Programming ? Agile serait un maillon pour aller de Lean à Kanban et Lean Startup ?<br />
Dans l'esprit et a posteriori, on peut éventuellement trouver une filiation mais celle-ci n'est que théorique et, quoi que l'on en dise, elle ne correspond qu'à une description "agilo-centrée" dont nombre de software craftsmen, entreprises libérées ou lean startupers ne se réclameront pas.</p>
<p>S'il existe un mouvement agile, je le vois plutôt comme un ensemble de flux qui, potentiellement et ponctuellement, convergent vers quelque chose de commun, tout en gardant leur mouvement propre. S'il y a une "racine" commune à l'ensemble des approches agiles, elle sera dans le futur.</p>
<p>Voici donc mon schema à moi des mouvements agiles. Il n'est bien évidemment pas parfait et j'attends vos critiques constructives.<br />
<br />
<img src="https://agilitateur.azeau.com/public/agilitateur/mouvements_agiles.png" alt="mouvements_agiles.png" style="display:block; margin:0 auto;" title="mouvements_agiles.png, août 2015" /></p>
<p><br />
Quelques explications :</p>
<ul>
<li>Je différencie l'Agile Software Development (le mouvement initié par le manifeste de 2001 et limité au développement logiciel) d'un mouvement "Agile" plus global.</li>
<li>Scrum est présent deux fois :
<ul>
<li>une fois en tant que initiateur, parmi d'autres méthodes -dont la plupart ne figurent pas sur le schema- de l'Agile Software Development.</li>
<li>une autre fois par son "revival", à partir de 2005, comme outil de transition vers autre chose que le développement logiciel.</li>
</ul></li>
<li>Software Craftsmanship est une idée qui remonte aux Pragmatic Programmers et à Pete McBreen et dont on se met vraiment à parler dans l'Agile Software Development lorsque Bob Martin le met en avant.</li>
<li>La filiation entre Lean et Agile est (au moins) double :
<ul>
<li>Par le Lean Software Development de Mary Poppendieck qui est la première à faire le parallèle. Celui-ci se limite à un aspect purement logiciel.</li>
<li>Par le Kanban devenu méthode de gestion de processus à part entière quelques années après.</li>
</ul></li>
</ul>
<p>Le mouvmement agile, s'il existe, est donc quelque chose en construction, qui a plus ou moins démarré avec l'Agile Software Development et qui continue à être influencé par divers autres mouvements. Gardera-t-il son nom ? Quelles seront les prochaines influences qui apparaitront sur le schema ?
J'en imagine au moins deux :</p>
<ul>
<li>Le logiciel libre et, plus généralement, les "communs numériques". Les mouvements agiles ont cassé les frontières à l'intérieur des organisations. Les communs sont une voie pour casser certaines frontières entre les organisations.</li>
<li>Le revenu de base, évolution logique de la libération de l'individu par rapport au travail.</li>
</ul>"Education agile" à Toulouseurn:md5:3bbe16c325f116cf69365553e721abb02015-06-14T23:18:00+02:002015-06-14T23:18:00+02:00Olivier AzeauEn français<p>Mardi dernier, l'<a href="http://agiletoulouse.fr/">association Agile Toulouse</a> a lancé une commission "Education agile". Cette première rencontre faisait suite à la <a href="http://eduscrum.nl/en/links">traduction en français du guide eduScrum</a>.</p> <p><img src="https://agilitateur.azeau.com/public/agilitateur/education/.eduScrum_logo_s.jpg" alt="eduScrum_logo.jpg" style="float:right; margin: 0 0 1em 1em;" title="eduScrum_logo.jpg, juin 2015" />Tout à commencé il y a quelques mois quand je suis allé aux <a href="http://xpdays.net/">XP days Benelux</a>. J'y ai <a href="http://xpdays.net/Xpday2015/Mini%20XPDay/Program.html#session_259">rencontré des enseignants néerlandais</a> en collège/lycée qui, aidés par des agilistes, faisaient désormais exclusivement cours à leurs élèves avec une variante de Scrum nommée <a href="http://eduscrum.nl/">eduScrum</a>.<br />
Le guide eduScrum était disponible en plusieurs langues, mais pas en français. Avec quelques membres d'Agile Toulouse, nous avons remédié à cela. La traduction française est désormais disponible à l'adresse suivante : <a href="http://eduscrum.nl/en/file/CKFiles/Guide_eduScrum_1.0_fr.pdf">http://eduscrum.nl/en/file/CKFiles/Guide_eduScrum_1.0_fr.pdf</a></p>
<p>La suite logique, c'était de créer, au sein de l'association, une commission "education agile" ayant pour objet : <strong>"Favoriser l’adoption des méthodes agiles dans l'enseignement. Informer et initier aux méthodes agiles les enseignants désireux de les découvrir"</strong>.<br />
Une première réunion <a href="http://www.meetup.com/fr/Agile-Toulouse/events/222536582/">s'est tenue le mardi 9 juin</a>. D'autres suivront en fonction de l'intérêt porté au sujet. Le problème désormais c'est d'imaginer ce qui peut être fait concrètement.</p>
<p><br />
Les premières discussions ont beaucoup porté sur l'intérêt que pourrait présenter pour des enseignants une méthode comme eduScrum. Qu'est-ce qui pourrait inciter à l'utiliser ? On a un début de liste :</p>
<ul>
<li>Les classes hétérogènes où il est plus difficile de faire progresser tout le monde simultanément. On notera qu'eduScrum encourage explicitement la constitution d'équipes hétérogènes</li>
<li>Les cours où le travail en groupe est la norme : projets tutorés en IUT, <a href="http://fr.wikipedia.org/wiki/Travaux_personnels_encadr%C3%A9s">TPE au lycée</a>, etc.</li>
<li>Les cours à la mise en œuvre peu définie, et où donc les enseignants pourraient tirer profit d'une méthode clef en mains. On pensera, par exemple, aux <a href="http://www.reformeducollege.fr/epi">Enseignements Pratiques Interdisicplinaires</a> prévus par la réforme actuelle du collège où une grande latitude d'exécution devrait être laissée aux établissements.</li>
<li>Les contextes où la maturité des élèves pose problème. En mettant l'accent sur l'autonomie et la responsabilité, eduScrum peut aider à grandir.</li>
<li>Les contextes où il n'y a plus rien à perdre dans des classes où l'enseignant est à court d'options (fichu pour fichu, autant tenter autre chose...)</li>
</ul>
<p><br />
Il y a donc probablement, dans l'ensemble des enseignants, quelques uns qui pourraient être intéressés. Le problème, c'est que l'on ne sait pas les trouver ne serait-ce que pour évoquer l'existence d'eduScrum. Côté "communication", les idées ne sont pas légion.</p>
<ul>
<li>Trouver des enseignant individuellement par connaissances...</li>
<li>Contacter les institutions de l'éducation nationale : <a href="http://www.ac-toulouse.fr/">rectorat</a>, <a href="http://espe.univ-toulouse.fr/">ESPE</a>...</li>
<li>Proposer un article à un media lu par des enseignants, par exemple au <a href="http://www.cafepedagogique.net/">café pédagogique</a></li>
<li>En parler à des établissements qui sont dans une logique d'éducation alternative. Le collège <a href="http://www.ecolecollege-laprairie.fr/">La prairie</a> a notamment été mentionné.</li>
</ul>
<p><br />
On a aussi brièvement évoqué ce que l'association pourrait apporter à la mise en oeuvre de tout cela.</p>
<ul>
<li>Des présentations eduScrum/méthodes agiles en 1 ou 2h</li>
<li>Une demi-journée sur le sujet. L'association a, par exemple, <a href="http://www.aubryconseil.com/post/Mercredi-apres-midi-c-est-agile">déjà fait des après-midi "jeu agile"</a> à destination d'enseignants et étudiants.</li>
<li>Aider un enseignant à la constitution d'un backlog pour un sujet donné. Il s'avère que c'est probablement le point le plus bloquant pour démarrer avec eduScrum car la préparation du cours (faire un backlog avec ses items et leurs critères d'acceptation) s'écarte de ce dont les enseignants ont l'habitude.</li>
<li>Prendre un cours d'une matière donnée et, avec l'aide d'enseignants, écrire un exemple de backlog.</li>
<li>Créer un jeu pour découvrir la mécanique d'un sprint vue par un "eduScrum" product owner - peut être adapter le <a href="http://www.xp.be/businessvaluegame.html/">business value game</a> à un contexte eduScrum en réécrivant les backlog items ?</li>
</ul>
<p><br />
Tous ceux qui veulent participer à l'aventure, adhérents de l'association ou pas, sont les bienvenus pour faire avancer le Schmilblic. L'endroit idéal pour être tenu au courant des prochaines réunions, c'est <a href="http://www.meetup.com/fr/Agile-Toulouse/">le meetup de l'association</a>.</p>Après le lycée, les "algorithmes" débarquent au collègeurn:md5:08c2f879efe67db61340aa41f3186cf52015-05-29T08:19:00+02:002016-11-02T23:03:01+01:00Olivier AzeauEn français<p>La dernière réforme du lycée a fait une place de choix aux algorithmes. La réforme du collège, très présente dans l'actualité de ces derniers jours, prévoit de les introduire dès la classe de 5ème. Connaissant ce qui se fait au lycée, je redoutais un peu ce qui allait venir pour le collège.</p> <h3>Algorithmes au lycée</h3>
<p>Le <a href="http://eduscol.education.fr/pid24316/programmes-seconde-generale-technologique.html">programme actuel de la classe de seconde</a> est étudié depuis la rentrée 2009.
C'est avec celui-ci que les algorithmes ont pris une place à part entière dans l'enseignement des mathématiques. Auparavant, ils apparaissaient en filigrane dans les divers thèmes où l'on utilise une calculatrice programmable.<br />
Désormais, même si l'enseignement des algorithmes reste transversal aux divers contenus étudiés, "pratiquer une activité expérimentale ou algorithmique" fait partie des objectifs généraux et on attend des élèves de savoir décrire des algorithmes "en langage naturel ou dans un langage symbolique" et de les mettre en oeuvre sur une machine.</p>
<p>En regardant en détail le <a href="http://cache.media.education.gouv.fr/file/30/52/3/programme_mathematiques_seconde_65523.pdf">programme officiel de seconde</a>, on remarque que les capacités attendues se limitent à de la programmation <a href="http://fr.wikipedia.org/wiki/Programmation_s%C3%A9quentielle">séquentielle</a> et <a href="http://fr.wikipedia.org/wiki/Programmation_imp%C3%A9rative">impérative</a>. Bref, une suite d'instructions avec des variables et des boucles.</p>
<p><img src="https://agilitateur.azeau.com/public/agilitateur/education/Algorithmique_seconde.png" alt="Algorithmique Seconde" style="display:table; margin:0 auto;" title="Algorithmique Seconde, mai 2015" /></p>
<p>Quand on cherche un peu sur le web des informations sur cet enseignement, on trouve très facilement des documents qui expliquent <em>pourquoi</em> et <em>comment</em> enseigner les algorithmes. On ne trouve d'ailleurs que de ça. Le document historique, ce sont les <a href="http://www.dialogue.education.fr/D0015/Doc_ress_algo_v25.pdf">ressources pour la classe de seconde</a> qui date de 2009 et présente un très grand nombre d'algorithmes que l'on peut étudier. Depuis, il a fait beaucoup de petits.</p>
<h3>Et alors, ça donne quoi ?</h3>
<p>Je n'ai, par contre, pas réussi à trouver la moindre étude, le moindre bilan permettant de savoir, au bout de cinq ou six ans, ce qui était <em>réellement</em> enseigné et quel a été l'apport concret pour les lycéens.<br />
Le seul élément palpable, ce sont les sujets du bac. Ils sont le seul véritable baromètre de ce qui est effectivement appris au lycée puisque, aux yeux de la plupart élèves, ils sont la raison d'être des trois années d'étude. Et là, c'est la claque. A croire que tous les rédacteurs de sujet se sont donné le mot pour proposer le même algorithme, avec quelques variantes.</p>
<p>Grâce à un message sur <a href="https://fr.groups.yahoo.com/neo/groups/mathlyc/info">un groupe de discussion dédié à l'enseignement des maths au lycée</a>, j'ai même découvert une pépite : une présentation faite par un élève pour ses camarades sur <a href="https://xa.yimg.com/kq/groups/2538167/1662090558/name/Presentation%2Epdf">ce qu'il faut retenir concernant les algorithmes</a>.</p>
<p>Ce document expose huit exemples tirés de sujets de bac. Et pour tous, sans exception, il s'agit d'une boucle où une variable est incrémentée et une autre variable calcule le nième terme d'une suite définie par récurrence.<br />
Alors, bien sûr, il y a des variantes il faut parfois simplement comprendre l'algorithme ; il faut parfois le compléter. On trouve même un cas où il faut le modifier. Les conditions de sortie de l'unique boucle peuvent également varier (test sur la valeur du terme courant de la suite ou nombre d'itération prédéfini). Il y a même un cas où un esprit aventureux a rajouté une troisième variable pour calculer la somme des termes consécutifs de la suite.</p>
<p><img src="https://agilitateur.azeau.com/public/agilitateur/education/.reglesaretenir_m.png" alt="reglesaretenir.png" style="display:table; margin:0 auto;" title="reglesaretenir.png, mai 2015" /></p>
<p>On a donc introduit une grande nouveauté dans le programme de maths, au détriment de contenus qui ont dû en sortir, tout ça pour que des élèves de 15 à 18 ans apprennent vaguement à programmer un calcul itératif des termes d'une suite.<br />
Bel investissement...</p>
<h3>But wait... There's more!</h3>
<p>Forts de leur indéniable succès au lycée, les champions de l'algorithme dans l'enseignement secondaire ont décidé que le collège ne devait pas être en reste. Le <a href="http://cache.media.education.gouv.fr/file/CSP/04/3/Programme_C4_adopte_412043.pdf">futur programme de maths en cycle 4</a> (classes de 5ème, 4ème et 3ème) aura cinq thèmes :</p>
<ul>
<li>Organisation et gestion de données, fonctions</li>
<li>Nombres et calculs</li>
<li>Géomètrie</li>
<li>Grandeurs et mesures</li>
<li><ins>Algorithmique et programmation</ins></li>
</ul>
<p>Et alors là, on peut dire qu'ils se sont lâchés. Finies les ridicules petites instructions avec leurs boucles. En plus de la programmation séquentielle, on rajoute de <a href="http://fr.wikipedia.org/wiki/Programmation_%C3%A9v%C3%A9nementielle">l'événementielle</a> (clic souris, clavier...), de <a href="http://fr.wikipedia.org/wiki/Programmation_orient%C3%A9e_objet">l'orienté objet</a> (envoi de messages, clonage...) du mélange entre les deux (événements émis par un objet) et même <a href="http://fr.wikipedia.org/wiki/Programmation_concurrente">du parallélisme</a>.</p>
<p>Au niveau des types d'algorithmes, les calculs sur les suites récurrentes peuvent aller se rhabiller. Les collégiens vont coder des jeux, des correcteurs orthographiques et des carnets d'adresse. Ils vont même faire du chiffrement.</p>
<p>Je n'invente rien. Tout est dans le programme. La bonne nouvelle, c'est que les SSII vont désormais s'arracher les stagiaires des classes de troisième.</p>
<p><img src="https://agilitateur.azeau.com/public/agilitateur/education/algorithmique_cycle_4.png" alt="Algorithmique Cycle 4" style="display:table; margin:0 auto;" title="Algorithmique Cycle 4, mai 2015" /></p>
<p>Tout cela est très alléchant mais je vois mal comment le coupler avec le passage difficile de la fin de collège où, en mathématiques, il s'agit avant tout d'entrer dans le monde de la démonstration. Celui où on découvre que les maths servent à raisonner et à prouver des affirmations. Celui où on n'a pas trop de temps à gaspiller sur des sujets moins essentiels.<br />
Attendons de voir les sujets du brevet avec des exercices sur les algorithmes. Car les cours de maths feront comme au lycée : ils s'aligneront sur ce qui est effectivement évalué.<br />
A mon avis, on sera assez loin d'un chiffrage RSA en parallèle.</p>
<p>Il y a toutefois un autre problème avec ce thème "Algorithmique et programmation". Ceux qui connaissent le logiciel <a href="https://scratch.mit.edu/">Scratch</a> auront reconnu la quasi totalité des fonctionnalités de celui-ci, que ce soit sur les événements ou les objets. Et si le principal attendu en programmation pour la fin de cycle est de faire des "application ludiques", domaine privilégié de Scratch, on peut facilement imaginer le contenu du cours de maths pour cette partie là.</p>
<p>Je n'ai rien contre Scratch. Il m'arrive même de le <a href="http://dascritch.net/post/2015/03/05/Cryptoparty-de-printemps-%C3%A0-Utopia-Tournefeuille">faire découvrir aux enfants</a>.<br />
Ce qui me gêne, c'est que sous couvert d'un programme de maths de collège improbable qui, sur le papier, pourrait rivaliser avec celui d'un DUT informatique, on va, dans les faits, probablement faire du coding-goûter niveau école primaire.<br />
La <a href="http://www.education.gouv.fr/cid86831/college-mieux-apprendre-pour-mieux-reussir.html">ministre de l’éducation nationale dit</a> que le collège est "monolithique dans son approche disciplinaire, suscitant parfois l’ennui". Très bien. On va donc proposer des choses plus ludiques aux enfants, en enlevant du temps pour découvrir des mathématiques devenues ennuyeuses.</p>
<p>Je ne suis pas sûr que tous les collèges mettront en place ce programme de la même manière.<br />
Mais puisqu’on nous dit que cette réforme va combattre les inégalités...</p>Apprendre à coder : des blocs au texteurn:md5:956cd5ff07e9048cf8d0ae78942ebf1c2015-04-06T14:49:00+02:002015-04-06T14:49:00+02:00Olivier AzeauEn français<p><img src="https://agilitateur.azeau.com/public/agilitateur/scratch/des_blocs_au_texte/.j_apprends_a_coder_m.png" alt="J'apprends à coder" style="float:right; margin: 0 0 1em 1em;" title="J'apprends à coder" /><a href="https://scratch.mit.edu/">Scratch</a> est un formidable logiciel. Grâce à son système de programmation à base de blocs que l'on combine comme des briques Lego, il permet de transformer n'importe qui en programmeur en quelques minutes. Le revers de la médaille, c'est quand on atteint les limites des possibilités offertes par ces blocs de programmation. Le passage à une forme textuelle de codage peut être difficile car il impose un retour en arrière. Il y a beaucoup trop de choses à apprendre pour coder des trucs qui n'atteignent même pas le niveau de ce que l'on sait déjà faire avec Scratch.</p> <p>Scratch offre un environnement intégré où l'on va créer des objets graphiques et les animer. Il est très facile d'utilisation pour tout ce qui est programmation événementielle. On a les événements classiques liés à l'environnement (la souris, le clavier...) mais on a aussi l'envoi de messages définis par le développeur.<br />
Toutefois, quand on veut aller un peu plus loin sur les aspects algorithmiques impliquant des structures de données, ça se complique. Au delà des listes de valeurs simples, Scratch ne sait plus faire. Idem pour le partage de code entre objets. On en est réduit à mettre le code dans un objet séparé, appeler ce code via un événement et obtenir un retour via des variables globales. Ne parlons même pas de polymorphisme. Scratch offre une fonction de clonage d'objet mais si on veut un code différent pour chacun des clones, ce sera à coup de variables et de if/then/else.</p>
<p>Je vis régulièrement cette situation avec mes filles. "Papa, là je voudrais faire un truc qui fait ceci et cela". Je ne vois, bien évidemment, que ce qui me manque dans le langage des blocs pour faire quelque chose assez facilement et j'en suis donc réduit à trouver la meilleure astuce possible pour faire quelque chose d'approchant sans transformer leur projet en un monstre difficilement maintenable<sup>[<a href="https://agilitateur.azeau.com/post/2015/04/06/Apprendre-%C3%A0-coder-%3A-des-blocs-au-texte#wiki-footnote-1" id="rev-wiki-footnote-1">1</a>]</sup>.<br /></p>
<p>La solution se trouve donc dans la découverte d'un nouveau langage, avec un nouvel environnement, pour aller au delà de Scratch. J'ai aiguillé Sibylle (11 ans) vers <a href="http://www.codecademy.com/">Codecademy</a> où elle a fait avec enthousiasme quelques tutoriels sur HTML et JavaScript. Avec un tel environnement, le champ des possibles s'agrandit de manière spectaculaire... à condition que l'on veuille bien y passer quelques jours, voire semaines d'apprentissage là où 2 heures suffisaient avec Scratch. Sur Codecademy, au bout de 2 heures on arrive, si tout va bien, à coder un pierre/papier/ciseau en mode texte...<br />
Il existe probablement des bibliothèques qui faciliteraient la transition. J'ai un peu regardé <a href="http://phaser.io">Phaser</a> et <a href="http://createjs.com">CreateJS</a>. Il existe tellement de "moteurs de jeu" HTML/JavaScript que je ne sais où regarder. Si quelqu'un a une idée plus précise...</p>
<p>Mais ce qui aiderait vraiment à passer de Scratch à un langage textuel, ça serait la possibilité de garder les repères acquis dans Scratch pour découvrir un nouveau langage. J'ai décidé de tenter une expérience. A partir du <a href="https://scratch.mit.edu/projects/53754408/">jeu "Birds" écrit par Sibylle</a>, j'ai fait une version C#<sup>[<a href="https://agilitateur.azeau.com/post/2015/04/06/Apprendre-%C3%A0-coder-%3A-des-blocs-au-texte#wiki-footnote-2" id="rev-wiki-footnote-2">2</a>]</sup> en m'appliquant à avoir un code source lisible, au mot-près, par quelqu'un qui connaîtrait seulement Scratch.</p>
<p>Voici le jeu original :</p>
<iframe allowtransparency="true" width="485" height="402" src="//scratch.mit.edu/projects/embed/53754408/?autostart=false" style="display:block; margin:0 auto;" frameborder="0" allowfullscreen></iframe>
<p>Et voici <a href="https://github.com/Oaz/Birds">le jeu en C#</a> (utilisant le moteur <a href="http://www.monogame.net/">MonoGame</a>).<br />
Pour conserver les repères, j'ai juste écrit une petite API qui copie celle de Scratch. Avec MonoDevelop, on se retrouve dans un environnement qui est certes beaucoup moins interactif que celui de Scratch, mais avec un "lutin" (sprite) par classe, on s'y retrouve assez facilement.</p>
<p><a href="https://agilitateur.azeau.com/public/agilitateur/scratch/des_blocs_au_texte/MonoDevelop.png" title="MonoDevelop"><img src="https://agilitateur.azeau.com/public/agilitateur/scratch/des_blocs_au_texte/.MonoDevelop_m.png" alt="MonoDevelop" style="display:block; margin:0 auto;" title="MonoDevelop" /></a></p>
<p>Avec Sibylle, nous avons parcouru tous les lutins du jeu en ayant côte à côte les scripts Scratch qu'elle avait écrit et le code C#. Il n'y a eu aucun problème pour comprendre l'ensemble du code C# (sa connaissance de base du JavaScript a probablement aidé). Elle a eu, entre autres, cette remarque intéressante sur la correspondance entre les accolades du C# et les "creux" dans les blocs de Scratch.
<a href="https://agilitateur.azeau.com/public/agilitateur/scratch/des_blocs_au_texte/compare_csharp_scratch.png" title="Comparaison CSharp Scratch"><img src="https://agilitateur.azeau.com/public/agilitateur/scratch/des_blocs_au_texte/.compare_csharp_scratch_m.png" alt="Comparaison CSharp Scratch" style="display:block; margin:0 auto;" title="Comparaison CSharp Scratch" /></a></p>
<p>Cette expérience m'a conforté dans l'idée qu'un démarrage avec Scratch et ses blocs suivi d'une transition en douceur vers une approche de la programmation sous forme de texte est possible. Il ne manquerait que quelques outils pour, par exemple, convertir un projet Scratch vers une autre langage tout en gardant du code proche de l'API Scratch.</p>
<div class="footnotes"><h4>Notes</h4>
<p>[<a href="https://agilitateur.azeau.com/post/2015/04/06/Apprendre-%C3%A0-coder-%3A-des-blocs-au-texte#rev-wiki-footnote-1" id="wiki-footnote-1">1</a>] Il existe des gens qui développent des projets très compliqués avec Scratch. Il faut voir par exemple <a href="https://scratch.mit.edu/projects/10128407/">ce clone de Minecraft</a>. En fait, il faut surtout aller à l'intérieur pour apprécier tous les scripts illisibles pour toute personne autre que l'auteur.</p>
<p>[<a href="https://agilitateur.azeau.com/post/2015/04/06/Apprendre-%C3%A0-coder-%3A-des-blocs-au-texte#rev-wiki-footnote-2" id="wiki-footnote-2">2</a>] parce que c'est l'environnement que je maîtrise le mieux, donc celui où mon expérience serait réalisée le plus rapidement possible</p></div>
L'automne revient, les confs agiles aussiurn:md5:6081fccf60e05977db5cb49cd9bae8a12014-10-10T08:14:00+02:002014-11-29T22:44:52+01:00Olivier AzeauEn français <p>Divers événements m'ont tenu éloigné de ce blog pendant quelques temps.<br />
Je n'ai pas prévu de revenir tout de suite mais je ne pouvais pas ne pas parler des quelques conférences agiles auxquelles j'aurai le plaisir d'assister en octobre et novembre :</p>
<ul>
<li>16 et 17 octobre : <a href="http://tour.agiletoulouse.fr/">Agile Tour Toulouse</a>. Pour cause de diverses contraintes, je ne pourrai être présent que le 1er jour où je présenterai <a href="http://attls.herokuapp.com/event/31">"Doublures en folie"</a>.</li>
<li>20 et 21 novembre : <a href="http://2014.agile-grenoble.org">Agile Grenoble</a> avec, là encore, <a href="http://2014.agile-grenoble.org/programme.html#/session/256">"Doublures en folie"</a> qui devra faire face aux habituelles innombrables sessions en parallèle (10 cette année si j'ai bien compté ?!!!)</li>
<li>27 et 28 novembre : <a href="http://xpdays.be/">XP Days Benelux</a> à Eindhoven. A force d'entendre <a href="http://www.nayima.be/">Pascal Van Cauwenberghe</a> en vanter les mérites, j'ai décide d'aller voir à quoi cela ressemblait. Et j'aurai même la chance d'y animer (on ne s'en lasse pas) <a href="http://xpdays.be/Xpday2014/XPDays/Program.html#session_247">une partie de Soft(ware)Ball</a> :-)</li>
</ul>
<p>De quoi bien occuper les semaines à venir !<br />
(et c'est sans compter une douzaine de jours en Californie sur la fin octobre où je vais, entre autre choses, assister à une formation "Product Owner"...)</p>Doublures en folie : le making-ofurn:md5:6c5c0ea11b5cf51f9dfbd3b4d40b75782014-05-20T08:18:00+02:002014-05-20T08:18:00+02:00Olivier AzeauEn français<p>A la fin de cette semaine, le petit monde français des méthodes agiles se retrouve à Paris pour l'édition 2014 d'<a href="http://www.conference-agile.fr/">Agile France</a> (où on peut encore s'inscrire).<br />
Ce sera pour moi l'occasion de convier des participants à assister à une courte pièce de théâtre - et pour certains d'entre eux, la jouer...</p> <p>Comme toujours avant la "première" d'une nouvelle session, je passe les derniers jours à envisager des déroulements possibles et à changer d'avis sur la façon d'aborder le sujet.</p>
<p>Une pièce de théâtre... En ce qui me concerne un tel exercice d'écriture est une nouveauté. Après avoir <a href="https://agilitateur.azeau.com/post/2014/05/01/Doublures-en-folie">écrit une première scène</a>, la suite était plus compliquée.<br />
J'avais en tête la trame générale, un mini-kata en TDD, mais le code reste quand même plus facile à écrire que du théâtre. C'est donc ce que j'ai fait : j'ai déroulé mon code, <a href="https://github.com/Oaz/DoubluresEnFolie">disponible sur github</a>, en conservant une correspondance "une cycle de TDD = une scène" puis j'ai écrit un texte correspondant à ce code.<br />
C'est ce texte qui sera lu ou joué -selon l'humeur des participants- ce jeudi à Agile France.</p>
<p>L'idée de la session est de faire une sorte de boucle métaphorique : passer du code au théâtre pour analyser les scènes pour au final en tirer (peut-être) des enseignements sur les pratiques de code.
<img src="https://agilitateur.azeau.com/public/agilitateur/evenements/boucle-metaphorique-code-theatre.svg" alt="boucle-metaphorique-code-theatre.svg" style="display:block; margin:0 auto;" title="boucle-metaphorique-code-theatre.svg" /></p>
<p>Il parait qu'il y a un pitch des sessions en début de matinée. C'est ce qu'il me faudra essayer d'expliquer en quelques secondes !<br />
Par ailleurs, je n'ai aucune idée de la viabilité de l'exercice, mais au moins on aura essayé !</p>
<p>Pour l'instant, j'ai prévu le déroulement suivant :</p>
<ul>
<li>une courte introduction où j'expliquerai que l'étape 1 (l'écriture de la pièce à partir du code) est déjà faite</li>
<li>la session commencera réellement par l'étape 2, le passage du texte à l'interprétation qui devrait durer entre 15 et 20 minutes</li>
<li>dans un 3ème temps, nous prendrons une dizaine de minutes pour analyser ce que nous venons de voir : le déroulement de l'histoire, le comportement des personnages, leur implication, les liens qui se tissent entre eux</li>
<li>vient ensuite l'étape 4, une autre dizaine de minutes pour ramener notre analyse dans le monde du code et voir ce que l'on peut en tirer d'intéressant</li>
<li>l'étape 5, c'est le retour au code en utilisant les enseignements mais nous nous arrêterons là en faisant simplement une rétrospective sur l'exercice</li>
</ul>
<p>Et pour me mettre dans le bain de la fiction à venir, mes filles m'ont aidé ce dimanche à concocter une petite vidéo d'introduction...</p>
<iframe width="560" height="315" src="//www.youtube.com/embed/5gkmE0lfkrs?rel=0" frameborder="0" allowfullscreen></iframe>
Doublures en folieurn:md5:b33713c6ee29f48dc6b4abd7ecf915332014-05-01T11:06:00+02:002014-05-01T11:06:00+02:00Olivier AzeauEn français<p>Les 22 et 23 mai prochains, c'est <a href="http://2014.conference-agile.fr">Agile France 2014</a>.</p> <p><img src="https://agilitateur.azeau.com/public/agilitateur/evenements/.logo-agilefrance2014_s.png" alt="logo-agilefrance2014.png" style="float:right; margin: 0 0 1em 1em;" title="Logo Agile France 2014" />
L'édition de l'an passé était <a href="https://agilitateur.azeau.com/post/2013/05/26/Mon-premier-Agile-France">une grande première pour moi</a>. Si je n'avais dû aller qu'à un seul événement en 2013, cela aurait été celui-là.<br />
J'y ai tellement pris goût que j'ai décidé d'y retourner cette année, et, par chance, un des deux sujets que j'ai proposé a été retenu.<sup>[<a href="https://agilitateur.azeau.com/post/2014/05/01/Doublures-en-folie#pnote-498-1" id="rev-pnote-498-1">1</a>]</sup></p>
<p>L'idée est simple : on reprend le principe de <a href="https://agilitateur.azeau.com/post/2010/09/05/Stub-et-Mock-montent-sur-sc%C3%A8ne">"Stub et Mock montent sur scène"</a> mais on va encore plus loin.<br />
"Stub et Mock" était un atelier pour faire découvrir le TDD et les doublures en jouant divers rôles dans un scénario que l'on mettait au point petit à petit.</p>
<p>Dans <a href="http://2014.conference-agile.fr/sessions/doublures-en-folie.html">"Doublures en folie"</a>, il n'y a plus de place pour les tâtonnements.<br />
La session débutera par la lecture d'une courte pièce de théâtre et cette lecture sera suivie d'un débat.</p>
<p>Autant le dire tout de suite : je ne sais pas du tout dans quoi je me lance. J'ai rarement écrit de la "fiction" et jamais de pièce de théâtre.<br />
Il faut bien un début à tout...</p>
<div class="celtx">
<p class="sceneheading-single">Prologue<br>
</p>
<br>
<p class="action">CODEUR lit le livre xUnit Test Patterns.</p>
<p class="character">NARRATEUR<br>
</p>
<p class="dialog">Codeur est contrarié. Il s'est toujours considéré comme une virtuose du développement logiciel mais quand ses collègues lui ont dit qu'ils voulaient désormais pratiquer le TDD, il n'a pas eu le choix. Tests, Rouge, Vert, Refactor... Il devait assimiler tous ces mots nouveaux et il fallait le faire vite. Il s'attaque alors à la lecture de xUnit Test Patterns par Gerard Meszaros mais la fatigue le gagne...</p>
<p class="sceneheading-single">Scène 1 - un premier test<br>
</p>
<br>
<p class="action">Dans le calme d'un environnement d'exécution au repos, TEST fait les cent pas.</p>
<p class="action">CODEUR entre lentement dans cet endroit qu'il découvre à peine. SUT, CAPTEUR et CHRONO lui emboitent le pas.<br>
</p>
<p class="character">SUT<br>
</p>
<p class="dialog">Je me demande si on est au bon endroit<br>
</p>
<p class="character">CODEUR<br>
</p>
<p class="dialog">On verra bien. N'ayons pas peur. Avançons. Il parait que les environnements de test sont des endroits sûrs.<br>
</p>
</div>
<p>Pour ceux qui voudraient en lire un peu plus et me donner du feed-back, j'ai <a href="https://agilitateur.azeau.com/public/doublures-en-folie/doublures-en-folie.v1.scene1.html">mis en ligne le texte complet de la première scène</a>.<br />
Ça reste un premier jet. J'ai encore un peu de temps pour le perfectionner.<br />
Pour le débat qui suivra, j'envisage au moins deux parties. Une sur le fond (le TDD les doublures, etc.) et une autre sur la forme (la pièce de théâtre, les métaphores...)</p>
<p>Après mes diverses expériences des années passées (et <a href="http://www.softwareball.org/">SoftwareBall</a> qui est toujours d'actualité), ce "Doublures en folie" est une nouvelle étape dans ce que je pourrais appeler "Écrivons du code sans clavier ni écran". Il faudra que je formalise un peu ce truc un de ces jours, mais ceci est une autre histoire...</p>
<p>Dans l'immédiat, ce qui compte c'est <strong><a href="http://2014.conference-agile.fr">AGILE FRANCE 2014</a></strong>.<br />
<a href="http://2014.conference-agile.fr">Inscrivez-vous. Il reste encore des places.</a><br />
Et il y a, encore une fois, <a href="http://2014.conference-agile.fr/programme_2014.html">un programme assez incroyable</a> (j'y ai même vu une tranche horaire<sup>[<a href="https://agilitateur.azeau.com/post/2014/05/01/Doublures-en-folie#pnote-498-2" id="rev-pnote-498-2">2</a>]</sup> où il me faudra être simultanément dans six endroits).</p>
<div class="footnotes"><h4 class="footnotes-title">Notes</h4>
<p>[<a href="https://agilitateur.azeau.com/post/2014/05/01/Doublures-en-folie#rev-pnote-498-1" id="pnote-498-1">1</a>] Pour la petite histoire j'ai proposé un sujet sur lequel j'avais déjà du contenu pour y avoir réfléchi depuis quelque temps et un autre dont l'idée m'est venue en 30 secondes. Devinez celui qui a été retenu...</p>
<p>[<a href="https://agilitateur.azeau.com/post/2014/05/01/Doublures-en-folie#rev-pnote-498-2" id="pnote-498-2">2</a>] vendredi 11h30-12h30</p></div>
CQRS et ses modèlesurn:md5:8c0bc6b22aee4506d95aa2b9dc908a862014-04-27T11:23:00+02:002014-04-27T11:23:00+02:00Olivier AzeauEn français<p>La séparation des responsabilités entre les commandes -les actions qui changent l'état d'un système- et les requêtes -les actions qui n'en changent pas l'état- est un pattern intéressant mais il semble aller généralement de paire avec l'utilisation de deux modélisations distinctes pour les éléments manipulés par le système. Et je trouve cela un peu perturbant.</p> <p>Je suis loin de maîtriser les détails des approches CQRS. Ma connaissance se limite à la lecture de quelques articles. Le plus connu est probablement <a href="http://martinfowler.com/bliki/CQRS.html">celui de Martin Fowler</a> où la séparation entre les deux modèles est omniprésente.</p>
<p>Essayons de voir ce que cela donne sur un exemple simple de gestion de bibliothèque.
D'un côté j'ai un ensemble de commandes pour créer des adhérents et traiter le flux de leurs emprunts.</p>
<pre class="brush: csharp;">
namespace Commandes
{
public interface IBibliotheque
{
void CréerAdhérent (Adhérent adhérent);
void DémarrerEmprunt (Emprunt emprunt);
void CloreEmprunt (Emprunt emprunt);
}
}
</pre>
<p>Ces commandes utilisent un modèle "riche" dans lequel sont implémentées les règles de gestion nécessaires aux commandes : types d'adhérents, date limite de retour des emprunts, etc.</p>
<table>
<tr>
<td>
<pre class="brush: csharp;">
namespace Commandes
{
public class Adhérent
{
public long Numéro;
public string Nom;
public string Ville;
public bool EstEtranger {
get {
return Ville == "Paris";
}
}
}
}
</pre>
</td>
<td>
<pre class="brush: csharp;">
namespace Commandes
{
public class Emprunt
{
public long Identifiant;
public long NuméroAdhérent;
public string Description;
public DateTime DateDébut;
public DateTime DateLimite {
get {
return DateDébut.AddMonths (1);
}
}
}
}
</pre>
</td>
</tr>
</table>
<p>D'un autre côté, on a un ensemble de requêtes qui permettent d'interroger le système.</p>
<pre class="brush: csharp;">
namespace Requêtes
{
public interface IBibliotheque
{
IEnumerable<RésuméAdherent> RechercheAdherents (string recherche);
IEnumerable<RésuméEmprunt> RechercheEmpruntsEnCours (string recherche);
}
}
</pre>
<p>Ces requêtes, qui, en l'occurrence, vont principalement servir à de l'affichage d'ensembles d'éléments nécessitent un modèle manipulant beaucoup moins d'informations et peu ou pas de règles de gestion.</p>
<table>
<tr>
<td>
<pre class="brush: csharp;">
namespace Requêtes
{
public class RésuméAdherent
{
public long Numéro;
public string Nom;
}
}
</pre>
</td>
<td>
<pre class="brush: csharp;">
namespace Requêtes
{
public class RésuméEmprunt
{
public long Identifiant;
public string Description;
public string NomAdhérent;
}
}
</pre>
</td>
</tr>
</table>
<p>Les commandes et les requêtes vivent donc dans deux mondes séparés. Elles n'ont techniquement rien en commun. Elles ne se rencontrent que lors de l’enchaînement de plusieurs actions au plus près de l'interface utilisateur.<br />
Voici quelques "histoires utilisateur" qui pourraient exister dans une application utilisant ces commandes et ces requêtes :</p>
<table>
<tr>
<td>
<pre class="brush: csharp;">
public void UnAdhérentVientEmprunter ()
{
var adhérents = requêtes_.RechercheAdherents ("Dupont");
var adhérentTrouvé = adhérents.ElementAt (12);
var emprunt = new Commandes.Emprunt
{
NuméroAdhérent = adhérentTrouvé.Numéro,
Description = "Un livre",
DateDébut = DateTime.Now
};
commandes_.DémarrerEmprunt (emprunt);
}
</pre>
</td>
<td>
<pre class="brush: csharp;">
public void UnAdhérentVientRapporter ()
{
var emprunts = requêtes_.RechercheEmpruntsEnCours ("Un livre");
var empruntTrouvé = emprunts.ElementAt (5);
var emprunt = new Commandes.Emprunt
{
Identifiant = empruntTrouvé.Identifiant
};
commandes_.CloreEmprunt (emprunt);
}
</pre>
</td>
</tr>
</table>
<p>Tout cela est bien sympathique, mais me laisse un goût d'inachevé.</p>
<p>Pourquoi, dans une partie de code qui raconte une histoire, et qui devrait donc ne parler strictement que du "métier", je me retrouve à introduire une distinction entre les commandes et les requêtes ?<br />
Est-ce que je vais parler de cette distinction à un utilisateur du système si nous voulons ensemble valider de tels scénarios d'utilisation ?<br />
Et pourquoi suis-je obligé dans ces scénarios de faire intervenir le numéro des adhérents ou les identifiants des emprunts ?<br />
D'ailleurs, que se passerait-il si le métier n'avait que faire de ces données d'identification ? Devrais-je tout de même les inclure dans les deux modèles ?<br />
L'identifiant des emprunts est, en pratique, complètement inutile pour notre utilisateur. Il n'est là que pour exprimer le lien entre nos deux modèles.<br />
On pourrait presque dire la même chose du numéro d'adhérent. Il aura peut être un sens pour l'utilisateur mais on pourrait aussi se trouver dans des cas où une identification plus naturelle le rendrait complètement insignifiant.<sup>[<a href="https://agilitateur.azeau.com/post/2014/04/27/CQRS-et-ses-mod%C3%A8les#pnote-497-1" id="rev-pnote-497-1">1</a>]</sup><br /></p>
<p>Bref, en ce qui me concerne, le code ci-dessus, n'est pas du code métier.<br />
Si je voulais des scénarios se limitant au langage de l'utilisateur, il me faudrait écrire quelque chose dans ce genre :</p>
<table>
<tr>
<td>
<pre class="brush: csharp;">
public void UnAdhérentVientEmprunter ()
{
var adhérents = bibliotheque_.RechercheAdherents ("Dupont");
var adhérentTrouvé = adhérents.ElementAt (12);
var emprunt = bibliotheque_.NouvelEmprunt;
emprunt.Emprunteur = adhérentTrouvé;
emprunt.Description = "Un livre";
emprunt.DateDébut = DateTime.Now;
bibliotheque_.DémarrerEmprunt (emprunt);
}
</pre>
</td>
<td>
<pre class="brush: csharp;">
public void UnAdhérentVientRapporter ()
{
var emprunts = bibliotheque_.RechercheEmpruntsEnCours ("Un livre");
var empruntTrouvé = emprunts.ElementAt (5);
bibliotheque_.CloreEmprunt (empruntTrouvé);
}
</pre>
</td>
</tr>
</table>
<p>Comment puis-je faire évoluer ma conception pour en arriver là ?</p>
<p>Tout d'abord, il me faut un seul service donnant accès à l'ensemble des commandes et des requêtes. Rien de compliqué à cela. Si pour des raisons techniques, ils doivent rester séparés, cela restera caché à travers une façade.</p>
<p>L'autre changement concerne l'interopérabilité entre les modèles.<br />
Dans mes deux scénarios, les commandes peuvent prendre en entrée des objets issus de requêtes, soit directement (CloreEmprunt), soit à travers un objet passé à une commande (l'adhérentTrouvé dans DémarrerEmprunt).<br />
Cela nous ramène à la multiplicité des modèles. En ce qui me concerne, je préfère travailler avec un modèle unique car la réalité de l'utilisateur est unique. Pour cela, je définis un seul modèle avec un ensemble d'interfaces.</p>
<table>
<tr>
<td>
<pre class="brush: csharp;">
namespace Modèle
{
public interface Adhérent
{
string Nom { get; set; }
string Ville { get; set; }
bool EstEtranger { get; }
}
}
</pre>
</td>
<td>
<pre class="brush: csharp;">
namespace Modèle
{
public interface Emprunt
{
Adhérent Emprunteur { get; set; }
string Description { get; set; }
DateTime DateDébut { get; set; }
DateTime DateLimite { get; }
}
}
</pre>
</td>
</tr>
</table>
<p>Les deux modèles précédents se transforment en implémentations techniques du modèle unique.</p>
<p>Pour les commandes, on retrouve à peu près la même implémentation incluant les règles de gestion.</p>
<table>
<tr>
<td>
<pre class="brush: csharp;">
namespace Commandes
{
public class Adhérent : Modèle.Adhérent, Identification.Adhérent
{
public string Nom { get; set; }
public string Ville { get; set; }
public bool EstEtranger {
get {
return Ville == "Paris";
}
}
public long Numéro { get; internal set; }
}
}
</pre>
</td>
<td>
<pre class="brush: csharp;">
namespace Commandes
{
public class Emprunt : Modèle.Emprunt, Identification.Emprunt
{
public Modèle.Adhérent Emprunteur { get; set; }
public string Description { get; set; }
public DateTime DateDébut { get; set; }
public DateTime DateLimite {
get {
return DateDébut.AddMonths (1);
}
}
public long Identifiant { get; internal set; }
}
}
</pre>
</td>
</tr>
</table>
<p>Pour les requêtes, on rajoute simplement des garde-fous visant à expliciter que certaines opérations ne sont pas disponibles</p>
<table>
<tr>
<td>
<pre class="brush: csharp;">
namespace Requêtes
{
public class RésuméAdherent : Modèle.Adhérent, Identification.Adhérent
{
public string Nom { get { return nom_; } set { throw NI (); } }
public string Ville { get { throw NI (); } set { throw NI (); } }
public bool EstEtranger { get { throw NI (); } }
public long Numéro { get; internal set; }
internal string nom_;
private Exception NI ()
{
return new NotImplementedException ();
}
}
}
</pre>
</td>
<td>
<pre class="brush: csharp;">
namespace Requêtes
{
public class RésuméEmprunt : Modèle.Emprunt, Identification.Emprunt
{
public Modèle.Adhérent Emprunteur { get { return emprunteur_; } set { throw NI (); } }
public string Description { get { return description_; } set { throw NI (); } }
public DateTime DateDébut { get { throw NI (); } set { throw NI (); } }
public DateTime DateLimite { get { throw NI (); } }
public long Identifiant { get; internal set; }
internal RésuméAdherent emprunteur_;
internal string description_;
private Exception NI ()
{
return new NotImplementedException ();
}
}
}
</pre>
</td>
</tr>
</table>
<p>Au passage, remarquons l'ajout d'interfaces pour rendre, là aussi, explicite le besoin d'identification technique des entités. Cette identification ne fait pas partie du modèle mais reste un détail d'implémentation nous permettant de mettre en oeuvre une sérialisation pour de la persistance ou pour tout autre besoin.</p>
<p>On remarquera aussi que les règles métier n'ont pas de raison d'être cantonnées à l'implémentation "commandes". On pourrait aussi utiliser des mécanismes d'héritage multiple (mixins, traits...) pour les rendre disponible sur toutes les implémentations.</p>
<p>Je dois ici remercier Jérôme pour avoir lancer une discussion qui m'a amené à écrire ce billet :</p>
<blockquote class="twitter-tweet" lang="fr"><p>Amis fans (ou pas) de <a href="https://twitter.com/search?q=%23CQRS&src=hash">#CQRS</a>, le design de la partie Query se résume donc à des transaction scripts et DTO selon vous ?</p>— Jérôme Avoustin (@JeromeAvoustin) <a href="https://twitter.com/JeromeAvoustin/statuses/458592082626875392">22 Avril 2014</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
<p>Pour moi, la réponse est donc : non, la modélisation des requêtes ne se résume pas à des DTO car je veux avoir un modèle unique. C'est un moyen de garantir une cohérence intrinsèque entre les diverses implémentations du modèle au sein du système sans avoir à pousser tout ce travail sur les scenarios utilisateur.</p>
<p>Pour moi, CQRS reste un pattern technique dont la présence permet l'optimisation des performances, à travers 2 mécanismes de persistance dédiés respectivement à la modification et à la lecture seule, ou l'amélioration de la fiabilité, en utilisant par exemple un système non destructif sur la partie accessible en écriture.<br />
Il permet probablement d'autres choses que je n'imagine même pas mais tant qu'il n'a aucune signification pour l'utilisateur, il n'a pas de raison valable pour transparaître dans la zone métier de mon système. C'est à cette condition de non ingérence des aspects de "technique informatique" que je pourrai faire évoluer ma modélisation du métier et sa validation par les utilisateurs.</p>
<p>Le code source qui a servi à écrire ce billet <a href="https://github.com/Oaz/Alexandrie">est disponible ici en intégralité</a>.</p>
<div class="footnotes"><h4 class="footnotes-title">Note</h4>
<p>[<a href="https://agilitateur.azeau.com/post/2014/04/27/CQRS-et-ses-mod%C3%A8les#rev-pnote-497-1" id="pnote-497-1">1</a>] Par exemple, dans une bibliothèque interne à un établissement scolaire on peut identifier "naturellement" l'élève avec son nom et le nom de sa classe</p></div>
Soyez intéressants ou disparaissez !urn:md5:ebd7c253398d3dead74e1411c4c0f0632014-04-10T08:18:00+02:002014-04-10T08:18:00+02:00Olivier AzeauEn français <p><img src="https://agilitateur.azeau.com/public/agilitateur/interesser.png" alt="interesser.png" style="float:right; margin: 0 0 1em 1em;" title="interesser.png, avr. 2014" />Un de mes récents billets <a href="https://agilitateur.azeau.com/post/2014/03/27/Comment-convaincre-un-d%C3%A9veloppeur-qu-un-jeu-de-balle-peut-l-aider-dans-son-m%C3%A9tier">"Comment convaincre un développeur qu'un jeu de balle peut l'aider dans son métier ?"</a> a suscité des réactions intéressantes mais deux d'entre elles, datant d'hier, sont particulièrement attrayantes.</p>
<h5>Intéressez-moi !</h5>
<p>Il y a tout d'abord ce billet de Jean-Baptiste <a href="http://www.arpinum.fr/2014/04/08/les-phases-du-programmeur/">"Les phases du programmeur"</a> (dont je conseille vivement la lecture) qui est sous-titré "comment intéresser un programmeur à la programmation propre".<br />
Ce billet n'est pas vraiment une réaction car Jean-Baptiste a juste rebondi sur un sujet connexe mais ce qui m'a frappé c'est l'approche focalisée sur la nécessité d'intéresser les développeurs à ce que l'on raconte.</p>
<p>L'autre réponse, c'est <a href="https://agilitateur.azeau.com/post/2014/03/27/Comment-convaincre-un-d%C3%A9veloppeur-qu-un-jeu-de-balle-peut-l-aider-dans-son-m%C3%A9tier#c29076">ce commentaire de "Razorgore"</a> qui peut se résumer par "Vous voulez intéresser les développeurs ? proposez-leur quelque chose qui les intéressera".<br />
Là c'est une réponse plus directe à une question que je n'ai même pas posée !<br />
Quand j'écris "Est-ce que le développeur λ de 2014 peut être intéressé par ce que j'ai envie de lui raconter ?", c'est au mieux une figure de rhétorique pour laquelle toute réponse est inutile car évidente.</p>
<h5>Oui, mais non en fait, ça ne marche pas comme ça</h5>
<p>Intéresser quiconque n'est pas mon but. Je fais des trucs qui m'attirent personnellement et c'est déjà beaucoup. Si au passage d'autres personnes veulent être de la partie, c'est mieux car c'est plus sympa de partager les choses mais c'est presque une coïncidence (et c'est mon seul gain dans l'histoire car je n'ai rien à vendre)<br />
Ma question n'était pas "Comment intéresser ?" mais "Comment convaincre ?". J'y vois une différence de taille.</p>
<p>Une précision : il n'y a rien de mal à vouloir intéresser les développeurs avec des conférences ou des ateliers centrés sur leurs préoccupations techniques. C'est encore mieux si on en profite pour montrer d'autres choses au passage, mais ce n'est tout simplement pas mon propos.</p>
<p>Si je prend le problème sous l'angle "je vais devoir trouver un moyen pour intéresser mon public de développeurs", je tombe invariablement du côté de la technique et du quotidien des développeurs. Et là j'ai perdu car mon intérêt est de s'en éloigner.<br />
Les raisons, pour faire court, sont qu'un jeu peut être envisagé comme une métaphore d'une situation réelle et en transposant sa façon de fonctionner dans la métaphore on peut découvrir de nouvelles perspectives utiles dans la situation réelle.</p>
<p>Il ne s'agit donc pas d'essayer d'intéresser quelqu'un mais de le convaincre qu'on gagne à sortir de sa zone de confort.<br />
Tant qu'on lui propose du code avec un clavier et un écran, même en y mettant du TDD et du SOLID, on reste dans la zone de confort.</p>
<h5>L'air du temps</h5>
<p>Tout cela m'amène inévitablement à penser à ce besoin permanent de susciter l'intérêt.<br />
Par exemple, j'ai l'impression qu'il est devenu impossible aujourd'hui à un enseignant de faire son métier sans qu'on lui demande d'intéresser ses élèves ou ses étudiants.</p>
<p>Comment arrive-t-on à faire des choses qui ne nous intéressent pas mais qui pourraient (sans aucune garantie) beaucoup nous apporter ?<br />
Il n'y a pas 50 réponses à cela. Je n'en vois qu'une : on le fait parce qu'on veut changer et s'améliorer.<br /></p>
<p>Donc, en ce qui me concerne, la seule question qui vaille encore la peine d'être posée, c'est, à mon avis, <a href="https://agilitateur.azeau.com/post/2014/03/27/Comment-convaincre-un-d%C3%A9veloppeur-qu-un-jeu-de-balle-peut-l-aider-dans-son-m%C3%A9tier#c29043">Grégory qui l'a le mieux formulée</a> : "Veux-tu vraiment t'adresser à des personnes qui foncièrement ne sont pas prêtes à changer ?"</p>12 propositionsurn:md5:f1c72a0453c02c1aa05305fd963808202014-04-04T08:12:00+02:002014-04-04T08:12:00+02:00Olivier AzeauEn français<p>Puisqu'on est dans une époque où <a href="http://www.redressement-productif.gouv.fr/rapport-tariq-krim-developpeurs-atout-pour-france">les talents des développeurs français ont le vent en poupe</a>, j'ai pensé moi aussi à quelques petits trucs simples mais qui pourraient améliorer les choses.<br />
Je vous les livre en vrac. Le numéro n'est là que pour les repérer. Il ne s'agit pas d'un ordre de priorité.<br />
Et en plus aujourd'hui, c'est <del>trolldi</del> vendredi.</p> <h5>(1) Instaurer un revenu de base pour l'ensemble de la population française</h5>
<p>Je ne vais pas détailler ce dont il s'agit. Le <a href="http://revenudebase.info">Mouvement Français pour un Revenu de Base</a> en parle bien mieux que moi.<br />
Dans le monde du numérique, un tel revenu permettrait de se passer des mécanismes d'aide aux entreprises que la complexité rend opaques. Pourquoi dépenser des sommes folles à tenter de sécuriser des entreprises et des emplois quand on pourrait se concentrer sur les personnes ?<br />
Il faut bien comprendre que le coût de démarrage dans le logiciel est quasi nul. Avec un revenu de base, tout créateur ayant une idée pourrait la développer, seul ou en collaboration, en étant moins dépendant des contraintes "alimentaires".</p>
<h5>(2) Simplifier le financement participatif en capital</h5>
<p>Le "crowdfunding" commence à se développer mais, aujourd'hui, il en est surtout question à grande échelle pour du don ou du prêt. Pour de la participation au capital d'une entreprise, il y a des systèmes comme <a href="http://www.wiseed.com/">WiSeed</a> ou <a href="http://www.smartangels.fr/">SmartAngels</a> mais ils restent réservés à des investissements conséquents et un public très limité là où il faudrait un système à plus large échelle et avec plus de lien humain.</p>
<h5>(3) Inciter à la collaboration long terme inter-entreprises</h5>
<p>Aujourd'hui le marché de l'informatique se résume bien souvent à des gros clients, que l'on nomme affectueusement "grands comptes", qui utilisent des entreprises de prestation de services : les SSII. En général, la relation se limite à une vision court-termiste de recherche du coût le plus bas. Ce principe de sous-traitance (et la pression qui l'accompagne) peuvent être répercutés sur 3 ou 4 niveaux. Exemple : un grand compte emploie une de ses rares SSII référencées, qui elle même emploie une autre SSII, qui elle même emploie un travailleur indépendant...<br />
Pour construire un meilleur environnement, il faudrait, à la manière de la "Toyota Way" ("Respect your extended network of partners and suppliers by challenging them and helping them improve"), privilégier tout ce qui va dans le sens d'une collaboration sur le long terme.</p>
<h5>(4) Faire respecter la loi sur le prêt illicite de main d’œuvre et le marchandage</h5>
<p>Ce sont des pratiques courantes dans le monde de l'informatique.<br />
Inutile d'en dire plus. Voir le site du <a href="http://munci.org">MUNCI</a> ou <a href="https://revolutionsociale.wordpress.com/about/">l'enquête de Nicolas Séné</a>.</p>
<h5>(5) Réformer le code de la propriété intellectuelle pour renforcer les droits moraux de l'auteur de logiciels</h5>
<p>Une loi de 1985 a introduit une distorsion entre les auteurs de logiciels et les autres.<br />
Alors que la plupart des oeuvres collectives (films, musique...) rendent publique la liste des créateurs qui ont contribué à l'oeuvre, dans le monde du logiciel, le créateur humain semble, la plupart du temps, ne pas exister. Les seules exceptions notables se trouvent dans le monde du jeu video et dans celui des logiciels open source.<br />
Si on veut que le métier de développeur gagne en visibilité et en respectabilité, il faut mettre en avant l'ensemble des personnes qui ont contribué à la création d'un logiciel.<br />
Aujourd'hui, un développeur définit typiquement sa propre valeur en termes de connaissances technologiques et encore trop peu en termes d'oeuvres réalisées et signées.</p>
<h5>(6) Introduire le mécénat global</h5>
<p>Le <a href="http://fr.wikipedia.org/wiki/M%C3%A9c%C3%A9nat_global">mécénat global</a> est une solution alternative au financement collectif de la création.<br />
La création de logiciels étant une activité de création parmi d'autres, elle profiterait de ce changement alors que le mécanisme actuel de taxe sur la copie privée est limité, de par son mode de gestion, à une frange très étroite des activités de création d'oeuvres de l'esprit.</p>
<h5>(7) Enclencher la décroissance normative</h5>
<p>Il est temps de rendre compte que l'inflation de tous les textes réglementaires a un impact difficile à mesurer dans l'activité informatique de nombreux secteurs (banque, assurance, santé...)
A l'échelle du pays, une partie difficilement mesurable mais probablement importante de l'effort informatique est bouffé par cette inflation.<br />
On est en plein dans le <a href="http://fr.wikipedia.org/wiki/Sophisme_de_la_vitre_cass%C3%A9e">sophisme de la vitre cassée</a>. Une diminution des règles induirait un gain de productivité immédiat.</p>
<h5>(8) Ouvrir effectivement les données de l'état et de toutes ses émanations</h5>
<p>L'"open data" est un terme à la mode mais sa mise en oeuvre reste soumise à la discrétion des entités concernées.<br />
Il serait pourtant simple de donner le droit aux citoyens d'aller chercher eux-mêmes les données là où elles sont. Dans les administration, les journée portes ouvertes devraient être une sorte d'état permanent.<br />
Par ailleurs, il faut en finir avec l'idée de valorisation des données publiques par les institutions. Puisque ces données sont publiques, il suffit de contraindre les institutions en question à les libérer.</p>
<h5>(9) Impulser la multiplication des initiatives visant à faire coder les enfants</h5>
<p>Ces derniers temps, des initiatives se sont développées (<a href="https://plus.google.com/u/0/105050554172452836044/posts">Programatoo</a>, <a href="http://codinggouter.org/">Coding Goûter</a>, <a href="http://www.devoxx4kids.org/france/">Devoxx4Kids</a>...) mais elles restent des cas relativement isolés.<br />
Il manque un relais -comme il en existe pour les sciences avec <a href="http://www.fondation-lamap.org/">la main à la pâte</a>- pour toucher un public plus large et se rapprocher de l'éducation nationale.<br />
Par ailleurs, la particularité des initiatives existantes est de ne pas venir du secteur public -recherche ou éducation- mais de professionnels de l'informatique. Il manquerait là aussi un cadre pour permettre à de tels professionnels d'intervenir à plus grande échelle auprès des enfants.</p>
<h5>(10) Développer l'apprentissage dès le lycée</h5>
<p>Contrairement à certains de nos voisins européens (Allemagne, Suisse, Europe du Nord...), la formation par apprentissage n'est que peu répandue en France. Et même si un effort de promotion a été réalisé ces dernières années, il reste focalisé sur des métiers à forte composante manuelle.<br />
En fait, on a un problème avec la dichotomie formation "professionnelle"/métiers manuels/études courtes d'un côté et formation "générale"/métiers intellectuels/études longues de l'autre côté.<br />
Il faut casser cette séparation en faisant valoir qu'un métier comme le développement logiciel nécessite simultanément des études poussées, avec notamment une formation avancée en mathématiques, et un apprentissage commençant très tôt au contact de professionnels pour en maîtriser le tour de main artisanal.<br />
La spécialité ISN qui vient d'être créée en filière S est un pas dans la bonne direction auquel il manquerait un côté professionnalisant plus marqué.</p>
<h5>(11) Favoriser le brassage des talents</h5>
<p>La France ne manque pas de développeurs mais elle manque de créateurs de logiciels qui oeuvrent à faire progresser leurs talents.<br />
Quelques entreprises américaines ont développé la pratique du <a href="http://en.wikipedia.org/wiki/Software_craftsmanship">craftsman swap</a> : l'échange ponctuel de développeurs pour permettre à ceux-ci de progresser dans leur pratique.<br />
Il faut créer un cadre légal pour un échange ponctuel de salariés et donner un droit aux personnes pour que le brassage se produise effectivement (à la manière du DIF qui donne un droit à la formation)</p>
<h5>(12) Généraliser les méthodes agiles</h5>
<p>Réformer le code des marchés publics pour rendre réalistes les projets logiciels dans l'administration.<br />
Réformer les programmes de l'enseignement supérieur en gestion de projet logiciel pour supprimer toute référence au cycle en V et à ses avatars.<br />
Et soutenir <a href="https://agilitateur.azeau.com/post/2009/03/26/Soci%C3%A9t%C3%A9-des-Innovateurs-pour-la-G%C3%A9n%C3%A9ralisation-de-M%C3%A9thodes-Agiles-de-Toulouse">toutes les associations dont le but est cette généralisation des méthodes agiles</a>.</p>Comment convaincre un développeur qu'un jeu de balle peut l'aider dans son métier ?urn:md5:dafc41df78a1b625141fbae5007c10c32014-03-27T08:04:00+01:002014-03-27T23:28:53+01:00Olivier AzeauEn français<p>Pour cette année 2014, je me suis fixé un objectif simple : montrer le jeu <a href="http://www.softwareball.org/">Soft(ware)Ball</a> à un public de développeurs bien plus large que ceux qui sont familiers du monde des méthodes agiles.<br />
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.</p> <h4>Un jeu apprécié par le public des méthodes agiles</h4>
<p>Le jeu a été globablement apprécié, avec de nombreux retours constructifs qui m'ont permis de l'améliorer au fil du temps.<br />
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).<br />
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.<br />
Dans tous les cas, le ressenti positif des participants a largement dominé<sup>[<a href="https://agilitateur.azeau.com/post/2014/03/27/Comment-convaincre-un-d%C3%A9veloppeur-qu-un-jeu-de-balle-peut-l-aider-dans-son-m%C3%A9tier#pnote-493-1" id="rev-pnote-493-1">1</a>]</sup>.</p>
<p>Il y a deux choses dont je suis particulièrement satisfait, voire assez fier :</p>
<ul>
<li>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.</li>
<li>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...</li>
</ul>
<h4>Un jeu qui peut toucher un public plus large ?</h4>
<p>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".<br />
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<sup>[<a href="https://agilitateur.azeau.com/post/2014/03/27/Comment-convaincre-un-d%C3%A9veloppeur-qu-un-jeu-de-balle-peut-l-aider-dans-son-m%C3%A9tier#pnote-493-2" id="rev-pnote-493-2">2</a>]</sup>.<br />
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.</p>
<p>Ma première interrogation, c'est "Est-ce que ma présentation du jeu est en phase avec l'objectif recherché ?".<br />
Voici mon "pitch" actuel :</p>
<div style="background: #f0f0f0; border:1px solid; padding: 0.5em;">
<p><em>Software development is a cooperative game of invention and communication</em> (Alistair Cockburn)</p>
<p>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...<br/>
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 !</p>
<p>Plus d'informations sur <a href="http://softwareball.org">softwareball.org</a> (mais n'en regardez pas trop car les jeux sont plus intéressants quand on les découvre en équipe)</p>
<p>Une expérience humaine :
<ul><li>L'apport du jeu dans tout apprentissage, même les plus proches de la technique et du code source.</li>
<li>Une expérience de programmation collective. Premier pas vers le "Mob Programming" ?</li></ul></p>
<p>Et un regard nouveau sur des techniques éprouvées :
<ul><li>L'importance du refactoring dans toute base de code. Le coût engendré par sa pratique et sa non-pratique.</li>
<li>La responsabilité unique des composants pour une meilleure réutilisabilité</li>
<li>La simplification de code (notamment la suppression des "if-then-else") à travers le polymorphisme et l'inversion systématique des dépendances.</li></ul></p>
</div>
<p>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 ?</p>
<h4>Une énigme : le développeur de 2014</h4>
<p>Ma deuxième interrogation, c'est "Est-ce qu'une conférence pour développeurs est le bon endroit pour un tel jeu ?".<br /></p>
<p>J'ai cette désagréable sensation de ne pas être totalement à ma place dans ce genre de conférences.<br />
En 2013, j'ai <a href="https://agilitateur.azeau.com/post/2013/04/29/En-revenant-de-Mix-IT-2013">participé à Mix-IT</a> 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.</p>
<p>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".<br />
"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"<sup>[<a href="https://agilitateur.azeau.com/post/2014/03/27/Comment-convaincre-un-d%C3%A9veloppeur-qu-un-jeu-de-balle-peut-l-aider-dans-son-m%C3%A9tier#pnote-493-3" id="rev-pnote-493-3">3</a>]</sup> et "Docker va tous nous sauver"<sup>[<a href="https://agilitateur.azeau.com/post/2014/03/27/Comment-convaincre-un-d%C3%A9veloppeur-qu-un-jeu-de-balle-peut-l-aider-dans-son-m%C3%A9tier#pnote-493-4" id="rev-pnote-493-4">4</a>]</sup>.<br />
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.</p>
<p>Le problème, c'est que, si ce n'est pas le bon endroit, je ne sais pas où aller parler à des développeurs !</p>
<p>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 ?".<br /></p>
<p>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 ?</p>
<h4>Alors, on fait quoi ?</h4>
<p>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..... ?</p>
<p>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.</p>
<p>Et puis, il y a cette histoire d'<a href="http://thecleancoder.blogspot.fr/2011/01/brining-balance-to-force.html">équilibre dans la Force</a> qui me travaille depuis trop longtemps. Cet équilibre passe par l'ouverture des développeurs à autre chose que leurs jouets technologiques.</p>
<p>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...<br />
D'avance, merci !</p>
<div class="footnotes"><h4 class="footnotes-title">Notes</h4>
<p>[<a href="https://agilitateur.azeau.com/post/2014/03/27/Comment-convaincre-un-d%C3%A9veloppeur-qu-un-jeu-de-balle-peut-l-aider-dans-son-m%C3%A9tier#rev-pnote-493-1" id="pnote-493-1">1</a>] 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" :-)</p>
<p>[<a href="https://agilitateur.azeau.com/post/2014/03/27/Comment-convaincre-un-d%C3%A9veloppeur-qu-un-jeu-de-balle-peut-l-aider-dans-son-m%C3%A9tier#rev-pnote-493-2" id="pnote-493-2">2</a>] 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.</p>
<p>[<a href="https://agilitateur.azeau.com/post/2014/03/27/Comment-convaincre-un-d%C3%A9veloppeur-qu-un-jeu-de-balle-peut-l-aider-dans-son-m%C3%A9tier#rev-pnote-493-3" id="pnote-493-3">3</a>] 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...</p>
<p>[<a href="https://agilitateur.azeau.com/post/2014/03/27/Comment-convaincre-un-d%C3%A9veloppeur-qu-un-jeu-de-balle-peut-l-aider-dans-son-m%C3%A9tier#rev-pnote-493-4" id="pnote-493-4">4</a>] Ces titres de sessions sont fictifs. Toute ressemblance avec des sessions existantes ne serait que pure coïncidence</p></div>
Duplication de code, refactoring et YAGNIurn:md5:abf537a67242b6878e3bfa9fce66dd392013-11-25T08:13:00+01:002013-11-25T08:29:02+01:00Olivier AzeauEn françaissoftwareball<p>En développement logiciel, la <a href="http://fr.wikipedia.org/wiki/Duplication_de_code">duplication de code</a> est un problème courant que l'on résout classiquement lors d'une étape de <a href="http://fr.wikipedia.org/wiki/Refactorisation">refactorisation</a>. Pour cela, encore faut-il identifier une duplication comme telle et accepter le coût de la refactorisation. En l'occurrence supprimer une duplication peut faire apparaître une abstraction que l'on jugera éventuellement, en se référant au principe <a href="http://fr.wikipedia.org/wiki/YAGNI">YAGNI</a> (You Aren't Gonna Need It), inutile.</p>
<p>La séquence "Right Angles" du jeu <a href="http://www.softwareball.org/">Soft(ware)Ball</a> permet de se confronter à ce dilemme.</p> <p>Cette séquence consiste à faire circuler un ballon en passant par les points A, B, C, D, E et F de l'aire de jeu dessinée ci-dessous.<br />
<br />
<img src="https://agilitateur.azeau.com/public/softwareball/rightangles1.png" alt="rightangles1.png" style="display:block; margin:0 auto;" title="rightangles1.png, nov. 2013" /></p>
<p><br />
La difficulté réside dans la découverte progressive de ce parcours. Lors de la première étape, on ne connaît l'existence que des points A et B et le trajet du ballon se limite à aller du point A au point B. Lors de la deuxième étape, on découvre le point C, puis le point D apparaît dans la troisième étape, etc.<br /></p>
<p>Lors de la première étape, la majorité des équipes<sup>[<a href="https://agilitateur.azeau.com/post/2013/11/25/Duplication-de-code%2C-refactoring-et-YAGNI#pnote-492-1" id="rev-pnote-492-1">1</a>]</sup> va au plus simple : un composant, appelons-le Nathan est positionné sur le point A et un autre composant, Emma, est positionné sur le point B.<br />
Nathan est programmé avec la règle : "Quand je reçois la balle, je l'envoie à Emma". Cela coûte 2 points et c'est le mieux que l'on puisse faire pour remplir le contrat.<br />
Emma n'a pas besoin d'être programmée car elle attrape implicitement la balle que Nathan lui envoie.<br />
<br />
<img src="https://agilitateur.azeau.com/public/softwareball/rightangles3.png" alt="rightangles3.png" style="display:block; margin:0 auto;" title="rightangles3.png, nov. 2013" /></p>
<p><br />
Lors de la 2ème étape, le point C apparaît et, là encore, la majorité des équipes va au plus simple. On rajoute un composant "Lucas" sur le point C et on programme Emma avec la règle "Quand je reçois la balle, je l'envoie à Lucas" qui coûte 2 points supplémentaires.<br />
<br />
<img src="https://agilitateur.azeau.com/public/softwareball/rightangles4.png" alt="rightangles4.png" style="display:block; margin:0 auto;" title="rightangles4.png, nov. 2013" /></p>
<p><br />
On peut continuer cette approche "facile" jusqu'au bout<sup>[<a href="https://agilitateur.azeau.com/post/2013/11/25/Duplication-de-code%2C-refactoring-et-YAGNI#pnote-492-2" id="rev-pnote-492-2">2</a>]</sup> et aboutir à la programmation suivante pour un coût total de 12 points :</p>
<ul>
<li>Nathan : "Quand je reçois la balle, je l'envoie à Emma"</li>
<li>Emma : "Quand je reçois la balle, je l'envoie à Lucas"</li>
<li>Lucas : "Quand je reçois la balle, je l'envoie à Lola"</li>
<li>Lola : "Quand je reçois la balle, je l'envoie à Enzo"</li>
<li>Enzo : "Quand je reçois la balle, je l'envoie à Chloé"</li>
<li>Chloé : "Quand je reçois la balle, je l'envoie à Nathan"</li>
</ul>
<p><br />
<img src="https://agilitateur.azeau.com/public/softwareball/rightangles5.png" alt="rightangles5.png" style="display:block; margin:0 auto;" title="rightangles5.png, nov. 2013" /></p>
<p>La plupart des équipes, toutefois, choisissent, à un moment donné de refactoriser le code pour supprimer une duplication en introduisant un programme "Quand je reçois la balle, je l'envoie au composant qui est situé à ma gauche" ou "Quand je reçois la balle, je l'envoie au composant qui est situé à ma droite". Chacune d'entre elles coûte 3 points mais elles sont réutilisables sans aucun coût supplémentaire.<br />
<br />
Par exemple, lors de la quatrième étape, on voit facilement<sup>[<a href="https://agilitateur.azeau.com/post/2013/11/25/Duplication-de-code%2C-refactoring-et-YAGNI#pnote-492-3" id="rev-pnote-492-3">3</a>]</sup> que Emma et Lola font exactement la même chose. Une équipe qui déciderait de refactoriser à ce moment là terminerait avec la programmation suivante pour un coût total de 9 points :</p>
<ul>
<li>Nathan : "Quand je reçois la balle, je l'envoie au composant qui est situé à ma gauche" (avec auparavant "Quand je reçois la balle, je l'envoie à Emma" utilisé jusqu'à la 5ème étape)</li>
<li>Emma : "Quand je reçois la balle, je l'envoie au composant qui est situé à ma gauche" (avec auparavant "Quand je reçois la balle, je l'envoie à Lucas" utilisé jusqu'à la 3ème étape)</li>
<li>Lucas : "Quand je reçois la balle, je l'envoie à Lola"</li>
<li>Lola : "Quand je reçois la balle, je l'envoie au composant qui est situé à ma gauche"</li>
<li>Enzo : "Quand je reçois la balle, je l'envoie au composant qui est situé à ma gauche"</li>
<li>Chloé : "Quand je reçois la balle, je l'envoie au composant qui est situé à ma gauche"</li>
</ul>
<p>Le meilleur score possible permet de terminer avec seulement un coût total de 5 points. Pour cela, il faut commencer le refactoring dès la 2ème étape (alors qu'on ne sait même pas s'il va être utile...)</p>
<ul>
<li>Etape 1 :
<ul>
<li>Nathan : "Quand je reçois la balle, je l'envoie à Emma" (2 points)</li>
</ul></li>
<li>Etape 2 :
<ul>
<li>Nathan : "Quand je reçois la balle, je l'envoie à Emma"</li>
<li>Emma : "Quand je reçois la balle, je l'envoie au composant qui est situé à ma gauche" (3 points)</li>
</ul></li>
<li>Etape 3 :
<ul>
<li>On déplace Nathan au point C, Emma au point D, Lola au point B et Lucas au point A (et positionné perpendiculairement à (AB)) ce qui nous permet de réutiliser l'ensemble des programmes déjà disponibles</li>
<li>Lucas : "Quand je reçois la balle, je l'envoie au composant qui est situé à ma gauche"</li>
<li>Lola : "Quand je reçois la balle, je l'envoie au composant qui est situé à ma gauche"</li>
<li>Nathan : "Quand je reçois la balle, je l'envoie à Emma"</li>
<li>Emma : rien</li>
</ul></li>
<li>...</li>
<li>Etape 6 :
<ul>
<li>Lucas : "Quand je reçois la balle, je l'envoie au composant qui est situé à ma gauche"</li>
<li>Lola : "Quand je reçois la balle, je l'envoie au composant qui est situé à ma gauche"</li>
<li>Nathan : "Quand je reçois la balle, je l'envoie à Emma"</li>
<li>Emma : "Quand je reçois la balle, je l'envoie au composant qui est situé à ma gauche"</li>
<li>Enzo : "Quand je reçois la balle, je l'envoie au composant qui est situé à ma gauche"</li>
<li>Chloé : "Quand je reçois la balle, je l'envoie au composant qui est situé à ma gauche"</li>
</ul></li>
</ul>
<p><img src="https://agilitateur.azeau.com/public/softwareball/rightangles6.png" alt="rightangles6.png" style="display:block; margin:0 auto;" title="rightangles6.png, nov. 2013" />
<br />
J'ai pu observer des équipes utilisant toutes entre 8 et 12 points pour arriver au bout de cette séquence.<br />
A chaque fois, la question de la refactorisation s'est rapidement posée et les réponses ont été variées : choix de code factorisé en passant à une approche plus générique ou attente de ce qui viendra après.<br />
A chaque fois, ces choix ont été collectifs avec des intentions opposées exprimées au sein de l'équipe.<br />
<strong>Cela montre que la notion de code dupliqué n'a pas une définition unique pour tout le monde, surtout si la suppression de la duplication induit un coût non négligeable.</strong></p>
<p>Pour ceux qui voudraient tenter l'expérience, cette séquence peut se jouer en environ une heure (20 minutes de présentation+30 minutes de jeu+10 minutes de debriefing). Le matériel (présentation du jeu, cartes, feuille de score) est disponible sur le site <a href="http://www.softwareball.org/">Soft(ware)Ball</a>. C'est d'ailleurs une bonne façon de découvrir le jeu avant d'attaquer des séquences plus difficiles.</p>
<div class="footnotes"><h4 class="footnotes-title">Notes</h4>
<p>[<a href="https://agilitateur.azeau.com/post/2013/11/25/Duplication-de-code%2C-refactoring-et-YAGNI#rev-pnote-492-1" id="pnote-492-1">1</a>] J'ai fait jouer cette séquence lors des <a href="http://agiletour-montpellier.fr/">Agile Tour Montpellier</a>, <a href="http://agiletourbordeaux.okiwi.org/">Agile Tour Bordeaux</a>, <a href="http://sessions.agile-grenoble.org/program#session_detail_76">Agile Grenoble</a>.</p>
<p>[<a href="https://agilitateur.azeau.com/post/2013/11/25/Duplication-de-code%2C-refactoring-et-YAGNI#rev-pnote-492-2" id="pnote-492-2">2</a>] une équipe l'a fait</p>
<p>[<a href="https://agilitateur.azeau.com/post/2013/11/25/Duplication-de-code%2C-refactoring-et-YAGNI#rev-pnote-492-3" id="pnote-492-3">3</a>] ce fut le cas pour toutes les équipes qui ont joué cette séquence</p></div>