213 lines
9.9 KiB
Markdown
213 lines
9.9 KiB
Markdown
---
|
||
title: "Semaine 09"
|
||
date: 2014-11-03T13:15:29+01:00
|
||
---
|
||
|
||
Journal d'un formateur en bootcamp - semaine 9
|
||
|
||
Semaine 9
|
||
=========
|
||
|
||
*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 ?
|
||
|
||
Ceci est [l'histoire d'une de mes expriences en tant que formateur dans
|
||
un bootcamp](https://yaf.github.io/journal-d-un-formateur-en-2015/).
|