---
title: "Jour 17"
date: 2014-09-30T13:15:29+01:00
---

[kataGarros](http://codingdojo.org/kata/Tennis/) en Ruby (l'autre choix était
[FizzBuzz](http://codingdojo.org/kata/FizzBuzz/) en Python). Intéressant de les
voir sur un nouvel exercice. Attention, certains parlent de fizzbuzz comme une
technique. Faut-il varier plus rapidement les sujets ?

Fait les groupes. Affichage des autoévaluation sur post-it. On parle des
projets en même temps (suite à demande). Faire les groupes avant serais
bien mieux, quitte à faire des mouvements au fur et à mesure. De même
que les projets doivent-être mieux préparés. Au final, nous reprenons
les tickets d’autoévaluation pour masquer les noms et faire une
répartition par niveau. Phase intéressante et qui fonctionne.

Les critères relevés par eux ne sont pas tous à prendre au même niveau:
l’anglais, il faut en avoir un ou deux qui s’en sortent, pas besoin de
faire un groupe équitable sur le sujet, même chose pour linux et/ou
l’environnement de travail peut-être ? Nous basons, avec quelques élèves
les groupes sur les critères web et langages, en s’assurant que anglais,
com/équipe, env de dev et linux/term soit aussi corrects dans chaque
groupe.

Répartition des projets par moi directement, un peu au hasard. J’aurais
du faire complètement au hasard ! Les groupes commencent à discuter. Je
décèle un groupe un peu limite. Analyse de situation: il manque les
critères de leadership potentiel et de confiance en soit. Dans un
groupe, 4 à 5 personnes en manque de confiance, avec un leader caché
derrière. Alors qu’un autre groupe à 5 personnes trop confiante et
potentiel leader. Faut-il changer les goupes tout de suite ?

Toujours pas préparé les visites/rencontre.

Peut-être qu’il faut découvrir les projets au fur et à mesure, en
proposant directement une tache ou deux à effectuer, en mode
présentation grand public ?

Peut demander à chaque groupe de présenter un projet devant les autres:
c’est quoi ? ça fait quoi ?