Le programme que j’avais prévu pour la deuxième semaine était assez vague. Je leur avais donné un cahier des charges très léger, une organisation rapide. Il fallait maintenant qu’ils puissent coopérer pour le réaliser. Je souhaitais par ailleurs qu’ils atteignent via ce projet d’autres objectifs pédagogiques, c’est-à-dire que ce projet ne leur permette pas que d’apprendre à coder en java mais aussi à utiliser des méthodes agiles et collaboratives, en suivant au mieux les cinq principes agiles (ce qui n’est pas toujours évident même pour l’enseignant).

Une séance de brainstorming était un bon moyen de les laisser s’exprimer (et laisser exprimer le prof demandeur) sur la manière d’aborder le projet. En effet, à l’aide des quelques lignes que je leur avait données, il n’y avait pas moyen de savoir qui fait quoi, comment et quand ?

Et donc j’imaginais assez bien leur questionnement sur tous ces sujets : comment se mettre d’accord sur le rendu, sur la complexité technique, sur la répartition des taches ?

A l’issue de cette séance, ils ont pu dégager cinq problématiques pour aborder le projet ( et j’ai laissé faire !! Et ça, je vous le promets car je me suis souvent pincé les lèvres. Ce n’est pas toujours facile, en tant que prof, on a tendance à vouloir tout contrôler !) :

  • fonctionnalités du logiciel
  • cohésion
  • management
  • qualité
  • technique

Sans s’en rendre compte, cette séance permet de s’échauffer et de démarrer de bons pieds. On a en fait tous les mêmes préoccupations et on y voit plus clair !

Les fonctionnalités du logiciel ont été vues comme le premier point à traiter. Chaque groupe a décidé d’un jeu qu’il souhaitait développer. Ensuite, je leur ai proposé de dessiner l’interface du jeu au tableau ainsi que du ‘launcher’. Cela a permis de partager avec tout le monde la vision du logiciel. J’ai pu en tant que client faire mes petites modifications. Mais, j’ai joué très peu le rôle du client exigeant car je ne suis pas vraiment un client mais un ‘client-prof’. Mon exigence porte plutôt sur l’apprentissage des méthodes que sur la réponse à une demande cliente précise.

Pour éviter de traîner des heures sur cet atelier, je l’ai minuté. Je réduirai, d’ailleurs pour une prochaine fois. Par manque de temps, j’ai dû reporter au sprint suivant la planification des user’s stories.

Ce premier sprint s’est terminé par un premier rendu (eh oui nous sommes à l’école !) de description des fonctionnalités du logiciel avec un diagramme UML (si-si) et de jolis textes pertinents l’accompagnant.

D’ailleurs, à ce propos, si vous avez des commentaires à me soumettre sur la différenciation entre user’s stories et user case, je suis preneuse ! Je trouve cela vraiment très proche et je suis étonnée que les users’ stories ne s’inspirent pas de l’UML pour l’aide à son élaboration et son découpage en tâches….