76 lines
3.5 KiB
Markdown
76 lines
3.5 KiB
Markdown
---
|
||
title: "Jour 41"
|
||
date: 2014-11-08T13:15:29+01:00
|
||
---
|
||
|
||
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…
|
||
|
||
|