Apprendre l'informatique en pratiquant en pair à pair dans un coin perdu

Apprendre l'informatique en pratiquant en pair à pair dans un coin perdu

- 11 mins

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 :

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 :

Différents atéliers, sous différents formats pour s’acculturer à la programmation informatique, codes, hytgiène, sécurités et enjeux numériques, 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é.

Un Tiers-Lieu(X) c’est ce que vous en faites ! Pas seulement 4 murs et 1 toit

Vous avez besoin

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 :

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.

Nous c'est sur ce spot que nous l'avons fait à Kerbors

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 :

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

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 :

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 vide 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

Merci à toutes les personnes qui soutiennent les efforts par leurs dons


Xavier Coadic

Xavier Coadic

Human Collider

rss framagit twitter github mail linkedin stackoverflow