Livrable
À la fin de chaque sprint, chaque équipe doit fournir un livrable accompagné d’une présentation orale et d’une démonstration du jeu.
Le format de la présentation et de la démonstration est assez libre tant qu’elles soient claires, fluides et qu’elles remplissent les objectifs suivant.
Présentation orale¶
La présentation orale doit :
Rappeler les objectifs du sprint.
Résumer ce qui a été réalisé, partiellement réalisé, ou non réalisé en donnant des justifications claires.
Mettre en évidence les difficultés rencontrées et les solutions proposées.
Donner une vision pour le prochain sprint au vue de l’avancement courant du projet.
Démonstration¶
La démonstration doit :
Présenter une version jouable du jeu correspondant à l’état du sprint.
Montrer les fonctionnalités implémentées durant le sprint.
Mettre en évidence le Minimum Viable Product (MVP).
Contenu du livrable¶
Une grande partie de l’évaluation du contenu du livrable se fera sur le pourcentage de fonctionnalités implémentées par rapport aux issues du Sprint Backlog.
Toutefois, la jouabilité, l’expérience du joueur, la qualité du développement et si le livrable correspond bien à un MVP seront aussi considérés.
MVP¶
Un Produit Minimum Viable (MVP) doit inclure :
Un personnage contrôlable.
Des commandes de bases.
Un environnement de jeu simple.
Une mécanique de jeu centrale.
Une condition de défaite/victoire.
Une boucle de jeu complète (écran de début, une partie jouable, écran de fin).
Un tutoriel.
Qualité du développement¶
Le livrable doit être proprement codé :
Bonne utilisation et respect des conventions de GitLab.
Organisation claire des répertoires (Scenes, Scripts, Prefabs, etc.) et sous-répertoires.
Bonne utilisation de l’API Unity (Layers, Animations, Colliders, Events, Prefab, etc.).
Nommage clair, méthodes courtes, scripts cohérents, code lisible.