Sprint review

La sprint review est faite en présence des deux développeurs et du product owner. Elle est similaire à la sprint rétrospective mais avec l'avis du product owner. Vous trouverez ici les PV de nos reviews.
Le product owner sera désormais nommé PO, le dev1 (ScrumMaster + view) sera D1 et le dev2 (model) sera D2.

Sprint 1 - Register/Login

PO : Quel est votre ressenti pour ce premier sprint ?
D1 : Après livraison, j'ai testé sur des environnements spéciaux (une machine avec des droits restreints sur le lecteur C: par exemple) et l'installer ne fonctionnait pas toujours.
D2 : Vous trouverez une bonne description de notre ressenti dans notre sprint rétrospective.
PO : Globalement, j'ai été assez content de votre travail;
Tout d'abord pour le livrable, la notion of DONE a été bien respectée, à part pour les diagrammes d'UML et de séquence qui manquaient. Le wiki est prêt pour accueillir la suite du projet et était très complet, félicitations !
Au niveau du code, il était bien commenté et les sources ont été citées. Mais vous pouvez plus travailler votre code pour qu'il soit mieux orienté-objet.
Pour le IceScrum, je ne m'attendais à ce que tous les sprints soient déjà planifiés. Par contre il ne faut pas clore les sprints, laissez le product owner s'en occuper car cela met les stories en DONE et plus en IN REVIEW.
D1 : Pour le prochain sprint, pouvons-nous supprimer le JSON pour la fenêtre de connexion (LoginRegister) ? Nous trouvons peu sensé de rouvrir cette fenêtre à un emplacement spécifique alors que le dernier utilisateur à l'avoir ouverte n'est pas forcement l'utilisateur actuel.
Nous pensons donc utiliser une propriété du formulaire (LoginRegister) pour qu'il se rouvre au même endroit où il a été fermé et stocker la position de la fenêtre de la bibliothèque (MyLibrary) dans un JSON.
PO : C'est OK, vous avez mon accord.

Sprint 2 - Add game to library

La review fut un peu chaotique car le programme avait de gros problèmes. Après un accord passé avec le PO, les devs D1 et D2 n'ont pas besoin de rédiger le PV de la Sprint review du Sprint 2.

Sprint 3 - View library

PO : Nous allons commencer par tester l'application.
PO : Si j'essaye de me loguer au premier lancement de l'application, une erreur de la base de données survient.
D1 : En effet, je crois que la création de la DB se fait au premier register. Comme vous essayez de vous loguer, le programme cherche la BD avant de l'avoir créée.
PO : Nouveau problème! Dans le formulaire d'ajout de jeu, si je génère une erreur et qu'après je confirme de bonnes datas, l'erreur est toujours présente au prochain lancement de la fenêtre.
D1 : En effet, il faut absolument régler ça pour le release finale.
PO : Vous avez un gros problème dans votre appli : quand j’édite un jeu et que je confirme, il me l'ajoute à ma bibliothèque plutôt que modifier l'entrée sélectionnée.
D1 : Il est clair que nous devons résoudre ce bug pour la release finale.
P0 : Maintenant voyons les stories IceScrum. En effet l'UPDATE du CRUD ne marche pas, comme nous l'avons constaté. Il y a aussi la story "Documentation code" où il vous manque toujours les diagrammes de séquence.
Apparition soudaine de D2 qui a eu 22 minutes de retard à cause de Travys
PO : Bonjour D2, nous en sommes aux fonctionnalités pas réussie. Comme nous l'avons vu avec D1, il faut revoir votre UPDATE ainsi que le champ d'erreur du formulaire.
PO : D1, créez les stories du Sprint 4 dans votre Backlog IceScrum et ajoutez les problèmes rencontrés pendant la review à vos Issues GitHub.
D1 : D'accord, bonne journée.
PO : Bonne journée.
D2 : Bonne journée.