journal-d-un-formateur-en-2015/journaux/semaine-09.md

---
title: "Semaine 09"
date: 2014-11-03T13:15:29+01:00
---

*Du 3 au 7 novembre 2014.*

## Jour 41 — Lundi 8 novembre 2014

Petit point matinal sur le planning, rappel de notre séjour à
l'[Archipel](http://www.larchipel.paris/larchipel/aurore/) prévu pour
jeudi et vendredi prochain. Évocation de la partie chasse aux blattes.
Décision de le reporter au lundi 10, nous faisons le pont, le mardi 11
tant férié. 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](http://www.python.org) sur NumberToRoman du coup. En expliquant
chaque étapes. Pour aller plus doucement, je ne participe pas. Après une
pause, nous attaquons un RomanToNumber en
[Haskell](https://www.haskell.org/). Intéressant.

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…

## Jour 42 — Mardi 4 novembre 2014

Aujourd’hui, c’est un jour spécial, et pourtant nous n’avons rien fait
de bizarre…

Quelques questions sur [Git](https://git-scm.com/) et
[Github](https://github.com) (workflow de base). Ils ont besoin de voir
et d'exprimenter sur le sujet. Puis un dojo en
[Ruby](https://ruby-lang.org) (fibo). Certains disaient: Facile ! mais
finalement, ils n'ont 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.

## Jour 43 — Mercredi 5 novembre 2014

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.

## Jour 44 — Jeudi 6 novembre 2014

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 ?

## Jour 45 — Vendredi 7 novembre 2014

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 ?