2.0 KiB
title, date
| title | date |
|---|---|
| Jour 17 | 2014-09-30T13:15:29+01:00 |
kataGarros en Ruby (l'autre choix était 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 ?