105 lines
9.8 KiB
HTML
105 lines
9.8 KiB
HTML
<!DOCTYPE html>
|
||
|
||
<meta charset="utf-8">
|
||
|
||
<title>Journal d'un formateur en bootcamp - semaine 9</title>
|
||
|
||
<h1>Semaine 9</h1>
|
||
|
||
<em>Du 3 au 7 novembre 2014.</em>
|
||
|
||
<h2>Jour 41 — Lundi 8 novembre 2014</h2>
|
||
|
||
Petit point matinal sur le planning, rappel de notre sjour lArc[hipel pr](http://www.larchipel.paris/larchipel/aurore/)vu pour jeudi et vendredi prochain. vocation de la partie chasse aux blattes. Dcision de le reporter au lundi 10, nous faisons le pont, le mardi 11 tant fri. Cela laissera juste le mercredi en mode pic-nique.
|
||
|
||
Plutôt que de faire la rétrospective et surtout la FOAD, les élèves préfèrent faire du code. Je me demande dans quel mesure les remarques sur le forum et autres ne les démotivent pas sur ce sujet…
|
||
|
||
Point aussi sur le tableau d’info avec les tickets à faire avancer.
|
||
|
||
Nous reprenons du code simple pour essayer de faire raccrocher certains. [Python](https://www.python.org/) sur NumberToRoman du coup. En expliquant chaque tape. Pour aller plus doucement, je ne participe pas. Aprs une pause, nous attaq[uons un ](https://www.haskell.org/)RomanToNumber en Haskell. Intressant.
|
||
|
||
Aprs le repas, Une lve se retrouve seule pour prsenter Go J[e ](https://golang.org/)la charrie un peu, mais elle sen sort bien. Elle fait une introduction et je complte. a nous permet de revoir des aspects bas niveau: gestion mmoire, pointeur. Je la chauffe en lui proposant de faire une dmo: un kata FizzBuzz. Nous arrivons crire quelques lignes, cest vraiment sympa. Ensuite, chacun essaie de faire avancer un ticket dans sa ligne.
|
||
|
||
Je continue de penser que le travail d’équipe est mal amorcé avec eux. D’ailleurs, est-ce que c’est en leur demandant de faire une équipe autonome que je vais vraiment leurs apprendre à travailler en équipe ?.
|
||
|
||
Nous voyons ensuite 5 personnes de chez Tigerlily. Ils nous exposent leurs faon de travailler avec P[ivotal ](https://pivotal.io/labs)et les pull requests. Est-ce que je devrais utiliser un outil dans ce genre pour leur assigner du travail par paire ?
|
||
|
||
Les soucis dans une organisation type une équipe de 24 personnes qui travail en paire ou plus, c’est:
|
||
|
||
Comment faire les équipes ?
|
||
|
||
Quand les renouveler ?
|
||
|
||
Quand et comment faire les démos/restitutions ?
|
||
|
||
Sélectionner le travail à effectuer ?
|
||
|
||
Faire les équipes et très dépendant des autres points. Pour faire les restitutions, le mieux serais un peu comme nous allons le faire jeudi prochain: tout le monde passe en une fois. Cela permettrais ensuite de regénérer des équipes/pair puis de les laisser prendre les taches à effectuer.
|
||
|
||
Reste comment faire la liste des trucs faisable ? Prendre un créneau ou deux pour faire la selection.
|
||
|
||
Les restitutions, pour bien fonctionner devraient se faire en… (7 * 60) / 12 = 35 minutes. Il faut prendre toute la journée et ne donner que 30 minutes à chaque paire. Dur dur dans certains cas je pense.
|
||
|
||
Nous verrons bien ce que donnerons les démos du jeudi prochain.
|
||
|
||
J’aimerais faire du flux continu, mais cela pose un soucis sur la façon de renouveler les équipes… Ce qui serait sympa c’est de ne pas limiter dans le temps, mais laisser les équipes essayer de fournir quelque chose. Au minimum une lecture de code dans un produit open source, au mieux un patch à proposer/accepter. Comment renouveler les équipes/pair dans ces conditions ? Peut-être en misant sur le fait que certains finiront plus ou moins en même temps. Les restitutions pourraient avoir lieu tout les débuts d’après midi, puis, on attend qu’au moins un ou deux autres équipes restituent pour regénérer des paires à partir de ceux qui ont terminé. A méditer…
|
||
|
||
<h2>Jour 42 — Mardi 4 novembre 2014</h2>
|
||
|
||
Aujourd’hui, c’est un jour spécial, et pourtant nous n’avons rien fait de bizarre…
|
||
|
||
Quelques questions sur [Git](h[ttps:/](https://github.com/)/git-scm.com/) et Github (workflow de base). Ils ont besoin de voir e[t de](https://www.ruby-lang.org/en/)xprimenter sur le sujet. Puis un dojo en Ruby (fibo). Certains disaient: Facile ! mais finalement, ils nont pas fini.
|
||
|
||
Ensuite, petit tour sur [Vim](http://www.vim.org/). Ils en entendent parler, ils veulent toujours le tester. Je leur explique que finalement cest pas forcement le plus facile. Honte moi, je leur[ prop](https://www.gnu.org/software/emacs/)ose de faire du Emacs ! :-)
|
||
|
||
Ensuite, je passe de groupe en groupe pour fixer des problèmes. Beaucoup liés au déploiement !
|
||
|
||
Ils sont parti pour le [Paris'rb](https://www.rubyparis.org/), moi je vais voir les eXtreme Programmeurs :-) Dailleurs, Betclic qui sponsorise les pizzas de ce soir, qui fait principalement du .net serais assez intress pour:
|
||
|
||
venir parler devant les élèves
|
||
|
||
un membre de leur équipe, jeune, souhaite donner des cours
|
||
|
||
les contrat pro, la diversité…
|
||
|
||
De trs bon changes, et du coup, jaimerais introduire C# [da](http://csharp.net-[tuto](http://www.mono-project.com/)rials.com/)ns le cursus (via Mono !). Sinon, les changes autour de Go donnent envie, une fois de plus, davoir loccasion de pratiquer ce langage.
|
||
|
||
<h2>Jour 43 — Mercredi 5 novembre 2014</h2>
|
||
|
||
Comme d’habitude, il n’y à pas grand monde à 10h… Est-ce que je dois être plus strict sur les horaires ? Je crois surtout que je n’accepterais plus de remarques sur le fait de ne pas coder assez. Un autre point sur ce sujet, c’est le fait de parfois devoir répéter, non pas parce qu’ils n’ont pas compris quelque chose, mais parce qu’ils n’étaient pas là. Peut-être que pendant (ou à la fin de) chaque slot, les élèves pourraient mettre sur un post-it ce qu’ils ont appris pendant la session. Nous pourrions du coup tracer une sorte de cartographie de ce qu’ils ont vu faut-il le faire en individuel ? C’est une idée à méditer encore un peu sûrement, mais ça semble une piste intéressante pour effectuer du suivi (pour nous) et montrer un avancement (pour eux) ainsi que des référents potentiel autres que le formateur pour échanger sur certains sujets.
|
||
|
||
Nous enchainons sur les deux dojos mais en plus petit groupe: 5 personnes. Je ne me mets pas dans la boucle de la matinée, et je n’impose pas une liste de sujets, je les laisse le proposer. J’ai juste ajouté une proposition pour qu’ils fassent du go, mais ils n’ont pas voté pour. Peut-être que nous pourrions avoir une mécanique de hasard pour désigner un sujet plutôt ? Même chose pour les groupes qui passent. Cela forcerais certains à venir coder ? Faut-il les obliger ?
|
||
|
||
J’ai décoincé un groupe sur Rails (pas forcement les bonnes pratiques). Mais seul le groupe a assisté. Le soucis c’est que du coup je risque de répéter la même chose avec les autres groupes. Est-ce un soucis ?
|
||
|
||
Des élèves me reparlent de l’atelier CV, et en profitent pour revenir sur l’aspect plusieurs langages. Ils ont peur de ne pas être à la hauteur quand il faudra passer des entretiens. Je leurs explique que de toute façon faire 6 mois que du ruby, ou 6 mois de moins de ruby, mais de plus d’autres langage ne changerait surement pas grand chose pour les entretiens. Le coté plusieurs langages peut même être un atout. Ce qui est important, c’est la pratique.
|
||
|
||
Il faut d’ailleurs que je travaille sur cet aspect de groupe de paire aléatoire avec choix de ticket de travail qui me semble finalement plus pertinent que faire des équipes dans l’équipe. Ils ne peuvent pas tout apprendre, et la gestion d’équipe viendra bien plus tard ! C’est à moi de le faire pour le moment.
|
||
|
||
Demain nous serons à Archipel pour faire les démo de fin de sprint. J’espère pouvoir en reparler avec eux à ce moment là. S’ils sont ok, je pense que je peux gérer les paires par tirage au sort manuel, mais pour ce qui est des projets, il me faut surement préparer un peu la listes des bugs qu’ils pourraient essayer de corriger.
|
||
|
||
<h2>Jour 44 — Jeudi 6 novembre 2014</h2>
|
||
|
||
Archipel, analyse des résultat de sprint. Demo par équipe. Il est sûrement plus facile de faire des choses sur un existant que de créer quelque chose de nouveau. Une des équipe n’a pas fait grand chose (voire rien). Beaucoup de problèmes de groupe semble-t-il. Nous abordons quelques soucis avec eux, sans aller trop loin.
|
||
|
||
Réunion autour de la FOAD. Des orientations prises qui devraient rendre le travail un peu plus efficace. Espérons que ce ne soit pas juste des bonnes intentions.
|
||
|
||
Attention, j’ai passé trop de temps à faire une scéance de Mob Programming pour résoudre un soucis, au lieu de leur dire de revoir leurs copie. J’avais réussi à le faire jusqu’à présent, mais là, je me suis un peu trop laissé aller. Le dernier groupe est un peu expédié du coup. Il faut bien tenir le chrono pour pas déborder. Être plus attentif, un élève me l’avait dit, je n’ai pas réagi.
|
||
|
||
Ce qui est intéressant avec des scéances comme celle-ci, c’est que des sujets apparaissent dans les discussions. Comment faire des démos efficaces si je demande à tous de travailler en binôme aléatoire ?
|
||
|
||
<h2>Jour 45 — Vendredi 7 novembre 2014</h2>
|
||
|
||
Rétrospective un peu longue (démarrée tardivement ?). Puis travail sur les projets. Pour le reste, toujours les même soucis qui ressortent : pas d’internet à Archipel, c’est chiant, gestion du bruit et des interruptions à Montreuil c’est chiant aussi. Comment faire mieux ?
|
||
|
||
Pour le moment, gestion des équipes. Faire du travail par paire sera peut-être plus efficace. Nous pourrions aussi améliorer la gestion des présentations de langages.
|
||
|
||
Là ils préfèrent mettre de la lecture de code à la place d’un dojo. Je laisse faire. Ça pourrait être complémentaire avec le fait de gérer des projets libre l’après midi.
|
||
|
||
Quid des clients (acacias for all et apedec/eco design fablab) et de la relation avec eux ?
|
||
|
||
<footer>
|
||
Ceci est <a href="https://yaf.github.io/journal-d-un-formateur-en-2015/">l'histoire d'une de mes expriences
|
||
en tant que formateur dans un bootcamp</a>.
|
||
</footer>
|