Lu sur le web :
Recently, we totally changed our design critique sessions. After carefully analyzing what was wrong with our previous format, we established the following pillars for our design critique sessions:
- It’s called Things That Rock
- It happens every week
- Everyone shows something
- No preparation needed
- 10 minutes per person
- Critique comes in the form of questions
- The session ends by a vote
Let’s go over each point in more details.
Intéressant. On rejoint un peu le système des revues de pair mais avec une autre approche, moins systématique et plus branchée sur comment partager l’expérience pour s’enrichir. J’aime beaucoup l’idée qu’en montrant ce qui fonctionne on finit par monter le niveau d’exigence.
Qui fait quelque chose de similaire côté développement ? Tout ce que j’ai vu finit par tourner dans des présentations de technos et moins dans le « voilà ce que j’ai fait ».
Une réponse à “[Lecture] How we run design critique sessions”
le 10 minutes par personne est pas mal, si l’équipe est petite. Imagine une équipe de 20 personnes x 10 minutes 200 minutes cela fait un meeting de 3h20 plus les entre-deux.
Un aspect intéressant de l’exercise est de permettre aux juniors de pouvoir progresser aussi. Pour du code, peut-être l’idée serait de donner une limite sur une fonction ou un module ou quelques lignes précises.
Aussi, j’aime bien les présentations qui vont dans le sens contraire, plutôt que les things that rock, j’aime écouter les gens qui me disent « j’ai fait cela et cela a tout pêté. » Ce qui me rappelle que j’ai, pour une mise à jour de copyright rapide dans les pages du site de la BNP géré par Calvacom en 1995, tout pêté avec une mauvaise regex et j’ai remplacé toutes les « lettres » du HTML par la « lettre+ 1 espace ». Tout cela bien sûr sur le site de Prod sans copie de sauvegarde. J’ai tout récupéré les 300 pages du site… dans mon cache de browser… impensable aujourd’hui. Site de la BNP en mauvais état pendant 2h en ligne.