Découpe la semaine 9 en jours
This commit is contained in:
Yannick Francois
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Jour 42 — Mardi 4 novembre 2014"
|
||||
date: 2014-11-04T13:15:29+01:00
|
||||
---
|
||||
|
||||
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.
|
||||
|
||||
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: "Jour 43 — Mercredi 5 novembre 2014"
|
||||
date: 2014-11-05T13:15:29+01:00
|
||||
---
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Jour 44 — Jeudi 6 novembre 2014"
|
||||
date: 2014-11-06T13:15:29+01:00
|
||||
---
|
||||
|
||||
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 ?
|
||||
|
||||
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
title: "Jour 41 — Lundi 8 novembre 2014"
|
||||
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…
|
||||
|
||||
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "Jour 45 — Vendredi 7 novembre 2014"
|
||||
date: 2014-11-07T13:15:29+01:00
|
||||
---
|
||||
|
||||
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 ?
|
||||
|
||||
@@ -1,200 +0,0 @@
|
||||
---
|
||||
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 ?
|
||||
|
||||
Reference in New Issue
Block a user