Après un dernier retour difficile du client, l’équipe, sur conseil du prof (du coach agile) devait mettre l’accent sur la communication, sur les tests unitaires et la réalisation de la principale fonctionnalité que je n’avait toujours pas vue jusqu’ici : pouvoir lancer depuis le lanceur principal l’ensemble des jeux !

J’ai vu pendant cette semaine une nette différence, les équipes ont commencé à se mélanger, à se conseiller, à communiquer. L’équipe d’intégration qui communiquait déjà, a intensifié ses échanges et surtout été plus proche des équipes pour régler les problèmes d’intégration au plus tôt. Ils ont également demandé que chaque équipe remette leur version finale 1/2 heure avant la démonstration.

Par contre, je n’ai pas vu apparaitre de planification du style kanban ou autre. Je ne suis pas intervenue sur ce point. Je les ai laissés gérer leur propre organisation. A priori, cela avait l’air de fonctionner sans.

Après recul, je me rends compte maintenant que les étudiants dont le niveau en Java était moins avancé avait été placé systématiquement (quelque soit le groupe) sur des tâches de tests unitaires. Ils avaient l’air assez isolés et moins investis dans le projet.

Cette scission un peu particulière va à l’encontre du principe de pair-programming. Là, je pense que j’aurais dû intervenir en tant que coach agile (j’y pense maintenant seulement !). L’année prochaine je n’y manquerai pas…

17h15 : La démonstration débute. L’équipe est prête. Cette fois c’est beaucoup plus convaincant.

Les jeux se lancent. Les principales fonctionnalités des jeux sont implémentées avec quelques bugs empêchant le fonctionnement mais il reste une semaine et clairement l’état d’avancement des jeux est bon. Je demande un certain nombre de modifications mineures qui concernent essentiellement l’ergonomie du lanceur : double click, design. Je remarque aussi la mauvaise implémentation du “soufflé n’est pas joué” du jeu de dames.

Globalement le client est plutôt confiant !

Retrospective
Ce qui a marché Ce qui a moins marché
La cohésion est meilleure. Meilleure planification des livrables. Git fait ses preuves pour quelques groupes. Pas de tests unitaires significatifs. Quelques modifications d’ergonomie à prévoir et une règle de jeu erronée. Git n’est pas convaincant pour l’équipe d’intégration (dommage !). Certains n’arrivent pas à accéder au serveur Git à cause d’un problème de proxy…