Ou comment s’initier au numérique et aux enjeux connexes sans se prendre au sérieux tout en étant apprenant et contributeur ?

Pour cela vous aurez besoin de parcourir 2 notions et méthodes de travail/apprentissage :

  • Le pair programming, ou comment apprendre à 2 sur une seule machine avec une ou un facilitatrice/facilitateur. Cela renforce le processus de collaboration et incite à l’apprenance sans pré-jugé.
  • Le mob programming, ou comment “une foule” autour d’une même machine utilise l’intelligence collective pour apprendre et transmettre avec une ou un facilitatrice/facilitateur. Cela renforce la capacité à travailler en équipe, la découverte de nouvelles compétences et sert d’expérience sociale.

Ces deux notions seront rapidement développées ci-après.

Avant propros

Je tiens à remercier particulièrement et chaleureusement Stéphane Langlois qui a permis et facilité beaucoup de ces séances, ainsi que Maxime Lahtuilière pour l’année dernière, enfin toutes et tous les participant.e.s à ces ateliers.

Il sera, dans la suite de cet article, question de pourquoi et comment organiser ces espaces-temps de collaborations et d’apprenance. Les détails techniques ayant été documentés en direct lors des séances par les participants eux-mêmes, dont je fais partie, vous pouvez cliquer sur les diiférents proposés liens pour avoir accès à ces détails techniques et aux documentations des codes. L’objetcif est double :

  • Vous pouvez vous servir de ces ressource pour vous entrainer au code
  • Vous pouvez utilisez ces méthodes pour reprdouire et/ou adapter ce type de séances.

Différents atéliers, sous différents formats pour s’acculturer à la programmation informatique, codes, séucirtés et enjeux, se sont déroulés lors d’IndieCamps entre 2016 et 2017, comme à Névez, ruralité de fait en Finistère, par exemple :

Mettre en place une séance {presque} n’importe où

C’est le point fort de cette démarche : Agilité & Frugalité.

Vous avez besoin :

  • L’envie de transmettre et d’apprendre quelque soit votre niveau avec un zeste de curiosité ;-)
  • 1 ordinateur minimun pour une séance en Mob programming
  • 1 ordinateur par binôme en Pair programming
  • 3 personnes minimun dont 1 qui facilite. 8 à 10 personnes au plus pour un personne aguérrie à la facilitation afin de conserver une qualité de séance et un confort de rapport humain.

Niveau requis

Pour les séances listées ci-avant les niveaux étaient mélangés allant de la découverte pure et simple au niveau développeur confirmé. La diversité fait la richesse et chacun apprend de l’autre.

Facultatifs mais facilitant la séance :

  • 1 connexion internet. Vous pouvez aussi faire cela en ‘localhost’ mais vous perdrez la cerise d’utilisation de git/github. L’essentiel avec les moyens du bord pour transmettre de la connaissance et des savoir-faire.
  • Un compte github
  • 1 pico projecteur, prejetez n’importe où (murs, rideaux, draps de lit, volet fermé…)!, câbles et connectiques c’est bien aussi
  • Prises de courant 220 volt si vos appareils ne sont pas chargés

Un spot où se poser :

Bars - café, tiny house, grange, appartement, gare de village… Inventez ! Pour une groupe d’écoliers, du collège jusqu’au bac +5 c’est assez important d’exprimer leurs apprenances dans des espaces inconnus ou atypiques.

  • Lorsque vous faites répéter un geste ou une méthode au mieux vous perfectionnez un acquis.
  • Lorsque vous faites une exploration de zones jusqu’alors inconnues, esapce physique ou intellectuel, vous apprenez et faites l’acquisition de nouvelles compétences.

Donc que vous soyez en itinérance, comme pour un WalkingDev, dans un camp aux participants hétéroclites ou dans un gîte en pleine montagne, retenez qu’il ne sagit en aucun cas d’imposer un court par un “Aujourd’hui on fait du code !”. Cela serait un imposition de savoir descendant.

Préferez vous appuyer sur une notion de réciprocité ou de gagnant-gagnant. Ce qui donne quelque chose ressemblant à “Tiens, aujourd’hui je fais du JavaSrcipt (par exemple), cela intéresse des personnes un atelier pour apprendre en faisant ?” ou “Qui a envie d’essayer un truc sur un langage que j’ai découvert il y a peu, qui voudrait tester un format d’atelier que vous pourriez refaire ensuite par vous même ?”

Pensez à quelques tips importants :

  • Parler succintement de l’intérêt du langage informatique abordé pour que les apprenants y voient un gain dans leurs pratiques.
  • Donner à comprendre à quoi cette nouvelle compétence peut servir.
  • Préciser le temps de l’atelier, court de préférence, et son heure de démarrage pour que chacun puisse s’organiser à sa guise.
  • Expliquer que ce format peut être reproduit par les appreants et même détourné pour d’autre discipline. Passer d’appreants à passuer de savoir-faire est valorisant mais surtout cela permet d’apprendre encore et toujours plus.

Plus on partage, plu son reçoit

Il ne vous reste plus qu’a préparer un exercice pratique avec un objectif de réalisation, par exemple une page web (en langage de votre choix) qui affiche des portaits avec un bouton suivant et un bouton déja vu pour découvrir la PROSAPAGNOSIE. Si vous avez accés à internet, vous pouvez préparer un backlog, logistique arrière de projet, dans les “Projects” d’un repository github. Nous reviendrons sur ce point plus tard. Sans connexion internet, un terminal ouvert et un éditeur de code (sublime text, gedit ou visual code studio…) devraient vous suffire.

L’atelier

Ceux qui seront là feront l’atelier Il n’y a pas vraiment d’organisateurs en chef Chaque participant peut porter une responsabilité collective si cela lui convient Chauqe participant honore la loi des deux pieds, si vous n’êtes ni en train d’apprendre, ni de contribuer, passez à autre chose !

Les formats courts sont les meilleurs ? En tout cas, apprenants comme facilitateur sont là pour se faire plaisir et non pas pour s’épuiser. À vous de doser votre atelier en fonction de votre objectif de transmission mais privilégiez un objet d’apprentissage qui tient entre 45 minutes et 2 heures grand max. Que cet objet soit de comprendre le fonctionnement de JavaScript, ou l’uilsiation de ‘const’, soit découvrir un nouveau langage et ses implications, soit de s’améliorer dans les pratiques collaboratives dédiées à la programmation, Ou encore l’acculturation à la sécurité informatique, essayez de fixer des objectifs cohérents avec le temps d’attention et la sollicitation d’apprenance collective. C’est peut-être la tâche la plus ardue finalement ?

Les étapes

Dans votre préparation, via le fameux backlog, vous devez préparer des “User Stories” (US). Dans les méthodes agiles, un récit utilisateur ou user story est une phrase simple dans le langage de tous les jours permettant de décrire avec suffisamment de précision le contenu d’une fonctionnalité à développer. Autrement dit “Aficher un portrait sur une page web” ou “Faire défiler un série de portrait toute les X secondes sur une page web”. Placez toutes ces US dans la première colonne du backlog denommée “À faire”. Vous aurez préparé deux autres collones “En cours”, pour les foncionnalité en développement, “Fait”, pour les développments relus - déployés - fonctionnant.

Voilà, vous avez un tableau de bord pour les apprenants et un guide pour la ou le facilitatrice/facilitateur. Essayez pour chaque US d’avoir un temps de code assez court pour conserver de l’espace alloué au contexte et aux explications. Si toutes les US ont un temps de code équivalent cela donne un équilibre à votre atelier. Cependant vous pouvez choisir, avec une difficulté de programmation croissante, un temps de coding augmentant (sans torturer ni vous ni les apprenants). Gardez toujours de l’espace pour le contexte et les explications.

Tips:

Vous n’avez pas internet et github ? Feuille de papier, vitre et posca, tableau au mur etc. C’est toujours bien d’improviser et s’adapter aux circonstances et à l’environnement :-)

Voir également :

En Pair programming

La programmation en binôme (de l’anglais pair programming), parfois appelée programmation par paires ou binômage, est une méthode de travail dans laquelle deux développeurs travaillent ensemble sur un même poste de travail. La personne qui rédige le code est appelée conducteur (driver). La seconde personne, appelée observateur (observer), assiste le conducteur en décelant les imperfections, en vérifiant que le code implémente correctement le spécifications et demandes et il peut suggérer des alternatives de développement. Les rôles s’échangent régulièrement pendant la séance de programmation. Par exemple, le driver est celui qui se sent le moins à l’aise avec l’US à développer. Les rôles s’échanges à chque US.

La personne qui facilite prend les rênes de l’introduction de la séance, elle explique le pair programming et invite les apprenants à se mettre en binôme. Le cas échéant, elle peut utiliser un pico projecteur et sa propore machine pour plus de confort. la ou le facilitateur/facilitatrice explicite l’objetcif globale, les enjeux et le contexte puis la première US. Elle fixe un temps de travail, sans qu’il soit obligaoire, pour réalisation du développement. Et hop c’est partie !

Une US démarré est placée dans la colonne “EN cours”.

Après chauqe US, chaque binôme fait une démo flash, c’est à dire expose et explique sa réalisation au reste du groupe. Le groupe corrige si besoin et apporte des compléments d’informations si besoin. La personne en charge de la facilitation veille au dialogue contributif (les débats c’est pour l’après atelier (^v^) ) et complète le contexte et les informations au besoin.

Une US terminée, revue, relue, fonctionnelle et acceptée est placée dans la colonne “Fait”.

Répéter à chaque US jusqu’au devellopement souahité intialement, ou à minima jusqu’à l’acquistion des compétences désirées. Une petite synthèse, si tout est documenté en directe par les apprenants l’effet d’acquisition de compétence est renforcé, un petit debreif et Hop un bon moment passé qui pourra être reproduit et/ou adapté par les participants.

Voir églamement : “Animer une retrospective

En Mob Programming

Mob Programming c’est faire travailler toute une équipe sur une seule tâche. Les développeurs vont, à tour de rôle, coder sur une seule machine avec un écran visible par tous.

Les propositions de base pour Mob programming par rapport au pair programming :

  • La personne qui facilite fait la même chose
  • Au clavier, l’apprenant qui se sent le “moins légitime” sur l’US
  • Le groupe participe à l’amélioration et conseil du Driver
  • US par US avec demo à chaque fois
  • Rôle tournant, en essayant que tous passent surle clavier quitte à changer de Driver en cours d’US
  • Documentation est un grande valeur ajoutée
  • Synthése des savoir-faire et enjeux abordés, debreif pour vérifier l’acquisition

Cependant, si vous avez internet et que vous utilisez github (ça marche aussi pour le mode pair programming), vous pouvez rajouter l’utilisation de git en ligne de commande (et hop ! Une compétence plus transmise lors de l’atelier) ainsi que l’intéret vraimment vraimment vraimment chouette d’envoyer les Pull Request, demande de modification de fichier, dans les US du Backlog (rappelez vous l’explication ci-avant). Cela fut réalisé lors de Atelier apprendre JavaScript en Mob Programming à Kerbors dans une cabane, tard dans la nuit, au bord de mer avec très peu, voir pas d’internet.

Pull Request vide et/ou dans une user story

Pourquoi faire ? Et quels gains ?

Ouvrir une pull request avec une page de code ou de text quasi vie revient à ouvrir un fil de discussions et de contributions pour favoriser :

Écriture collaborative Archivage des contributions techniques directement liées avec les discussions ainsi qu’avec les dates Offre une documentation plus compléte en terme de contexte qu’un github/wiki intégrée dans le backlog (to do, en cours, fait) > > Avec des users stories = suivi facilité de l’évolution des taĉhes avec collaborations et bonne base de documentation

Tips:

Utiliser ce principe avec travis, outil d’aide à l’intégration continue, pour suivre la qualité des contributions sur les pull requests permet une qualité de travail de haute qualité sur du code collaboratif.


Des suggestions, corrections, améliorations à proposer ? Ouvrez une ISSUE, titrez votre idée puis décrivez là avec détails.

Des envies de se rencontrer : xcoadic[at]protonmail[dot]com