8INF862 – Gestion de projets informatiques
Juliette sort de sa chambre
Plan du document
Le présent document est un rendu pédagogique basée sur une expérience vécue par des étudiants du baccalauréat avec majeur en conception de jeu vidéo au cours du trimestre d’hiver 2018. Il s’agit d’illustrer et de commenter la méthode de gestion de projet qui fût utilisé lors du développement du jeu « Juliette sort de sa chambre »1. Les exemples qui illustrent ce document ont été générés lors du cours « gestion de projets informatiques » à l’été 2019 par l’étudiant Jean-Baptiste Pommeret.
Le plan du document est le suivant :
1. Introduction 2. Le contexte du jeu 3. Le « Backlog » du jeu 4. Les « tâches » du jeu 5. Le premier « sprint » du jeu 6. Le deuxième « sprint » du jeu 7. Le troisième « sprint » du jeu 8. Le quatrième « sprint » du jeu 9. Conclusion
1 Les caractéristiques du jeu sont expliquées dans une vidéo disponible sur Moodle(8INF862). Des documents additionnels détaillant le jeu ainsi que le « trailer », le code source et l’exécutable sont aussi disponibles sur Moodle.
8INF862 – Gestion de projets informatiques
1. Introduction
La conception et la réalisation du jeu constitue une première utilisation de l’approche « Agile : Scrum » pour l’équipe. En conséquence, l’équipe, sous la supervision du professeur Sylvain Boivin, a décidé d’adapter des éléments qui tapissent les méthodologies « Agile(s) »2.
Figure 1 : « Adaptatif : Agile »
Les processus et les artéfacts « Agile : Scrum »
Un développement « Agile : Scrum » utilise des processus qui produisent des artéfacts3. Dans un contexte pédagogique, le professeur joue en alternance les rôles de Product-Owner et de Scrum-Master. L’équipe est impliquée dans la réalisation du Product-Backlog car elle est souvent dépositaire de la vision du jeu. Cette vision est exprimée sous la forme d’User-Story(s). Toutefois, lorsqu’il faut trancher en cas de conflits, le professeur est l’ultime responsable du Product-Backlog. L’équipe est responsable de déterminer le contenu des Sprint-Backlog(s) à partir du Product-Backlog. Il s’agit de découper les User-Story(s) en une séries de tâches.
2 La figure 1 illustre les différents éléments issus des méthodologies « Agile(s) » 3 La figure 2 illustre l’idée générale « Agile : Scrum »
8INF862 – Gestion de projets informatiques
Les Daily-Scrum(s) sont plutôt rares dans le contexte du cours « réalisation de jeu » dû à l’absence d’un endroit commun pour le développement et aux horaires atypiques des étudiants. Les étudiants utilisent plutôt des outils de communications en continues4.
Figure 2 : Le flux « Agile : Scrum »
Tout au long du document, des annotations viendront lier les choix de l’équipe versus la méthodologie « Agile : Scrum » et le développement d’un jeu vidéo. Dans ce contexte, il est utile de savoir que l’équipe est multidisciplinaire :
Designer(s),
Artiste(s),
Développeur(s). Un designer doit concevoir une expérience globale de jeu :
Histoire,
Esthétique (asset(s)), mécanique(s) (Game Play),
Technologie(s). Un artiste doit concevoir et produire des asset(s) de jeu. Un développeur s’occupe de produire des mécaniques de jeu, les API(s) (entrées, graphiques, son(s)), les outils et les IA(s).
4 Dans le contexte actuel, il s’agit du logiciel « Discord »
8INF862 – Gestion de projets informatiques
2. Le contexte du jeu
L’animation du jeu est tributaire d’un ensemble de règles. L’objectif du jeu est appelée « règle principale ». Dans le jeu, il s’agit de « délivrer la princesse ». Les autres règles décrivent un ensemble d’actions permises afin de « délivrer la princesse » … Un premier prototype simple du jeu fût réalisé par un groupe de six étudiants au trimestre d’automne 2017 dans le cadre d’un cours de conception de jeu. Le prototype fut retenu pour être poursuivit au trimestre d’hiver 2018 dans le cadre d’un cours de réalisation de jeu avec une équipe renforcée de neuf étudiants au total. Afin de repartir du bon pied et d’intégrer au mieux les nouveaux venus, le développement recommença à partir d’un projet vide pour le premier sprint (sprint1). Ainsi, ce premier prototype peut être associé à un « MVP5 » de la méthodologie « Agile : Scrum ». Le PO6 et l’équipe de développement commencent par mettre en place un premier Backlog7 du jeu. Ainsi, l’équipe s’est inspirée sur une première vision du jeu à partir du GDD8 réalisé au trimestre d’automne 2017. À ce GDD, des nouvelles fonctionnalités viendront se greffer afin d’obtenir une nouvelle vision du jeu qui sera réalisée lors du trimestre d’hiver 2018. Le Backlog ainsi obtenu est une liste de Stories9 en vrac. Une Story est écrite sous la forme « En tant que ... je veux ... afin de ... »10. Dans le Backlog, il s’agira souvent de décrire une mécanique lié à un joueur11. Par exemple : « En tant que joueur, je veux utiliser un pouvoir afin d’améliorer mon personnage. ». Il arrive aussi qu’une story puisse décrire un outil qui sera utilisé par un développeur tout au long du projet. Par exemple : « En tant que développeur, je veux pouvoir compiler mon jeu. »12. Les story(s) de développeur sont normalement traitées dans les premiers sprints alors que plus les sprint(s) avancent, le développement se tourne vers les story(s) du joueur. Il faut toujours établir des critères « mesurables » afin d’établir clairement la réussite d’une story.
5 Minimum Viable Prototype 6 Il s’agit du Product-Owner 7 Dans ce document le Backlog correspond au Product-Backlog 8 Game Design Document : il s’agit du plan de jeu qui met en contexte les mécaniques, les asset(s) et les IA(s) 9 Une Story ou User Story est une courte action à réaliser lors d’un Sprint 10 La partie « En tant que » représente un humain ; il arrive souvent que la partie « afin de » soit oubliée 11 Dans le contexte du jeu, il y a deux rôles humains qui sont susceptibles d’être impliqués dans une story : le joueur (90 %) et le développeur (10%) 12 Une bonne pratique est d’inclure cette story au début de notre projet
8INF862 – Gestion de projets informatiques
Étant donné que la réalisation du jeu limités dans le temps imparti par le trimestre (15 semaines), la saison13 sera composé de 4 sprints de deux semaines. En conséquence, le professeur suggère d’adopter le concept de « feature freeze »14 lors du dernier sprint. De plus, il faut noter qu’en plus des développeurs, l’équipe devrait inclure des artistes15 et des Game-Designer(s)16. Enfin, le jeu devrait aussi inclure des IA(s)17.
13 Une saison est constituée d’un ensemble de sprints liés entre eux. 14 Un « feature freeze » est un point temporel dans un cycle de développement logiciel où l'on décide d'interdire tout ajout de nouvelles fonctionnalités. Ce choix délibéré a généralement pour but de permettre de finaliser un état stable d'un programme pour aboutir à une livraison. (Wikipédia) 15 Les artistes sont responsables des assets 16 Les Game-Designer(s) sont responsables des scénarios qui expriment une expérience globale de jeu 17 Il s’agit de mécaniques ou d’avatars avec des comportements « intelligent »
8INF862 – Gestion de projets informatiques
3. Le Backlog du jeu
Un sous-ensemble18 du premier Backlog ressemblait à ceci :
18 Pour ne pas surcharger inutilement le document, nous illustrons la démarche avec 15 Story(s). 19 Ici, il peut s’agir d’un joueur ou d’une AI 20 Il s’agit plutôt d’une mécanique et non d’un outil 21 Ici, il s’agit d’un joueur 22 Ici, c’est plutôt à un joueur que cela s’adresse
Story Détail
S1 En tant que joueur, je veux marcher afin de progresser dans le niveau
S2 En tant que joueur, je veux sauter afin d’atteindre une plateforme en hauteur
S3 En tant que joueur, je veux attaquer afin de tuer les ennemis19
S4 En tant que développeur, je veux que le joueur puisse mourir afin d’augmenter le défis20
S5 En tant que joueur, je veux voir ma vie afin de connaitre ma situation
S6 En tant qu’ennemi21, je veux me déplacer afin d’atteindre un objectif
S7 En tant qu’ennemi, je veux attaquer un joueur, afin de lui faire des dégâts
S8 En tant que développeur, je veux différents niveaux pour permettre de progresser dans le jeu22
S9 En tant que développeur, je veux scénariser mon niveau
S10 En tant que joueur, je veux utiliser un pouvoir afin d’améliorer mon personnage
S11 En tant que joueur, je veux faire une roulade afin d’esquiver une attaque
S12 En tant que joueur, je veux ramasser un objet afin de progresser dans le jeu
S13 En tant que joueur, je veux voir la description de l'objet que j'ai collecté
S14 En tant que joueur, je veux activer un objet environnemental afin de progresser dans le niveau
S15 En tant que joueur, je veux entrer en interaction avec une princesse afin d’obtenir un pouvoir
8INF862 – Gestion de projets informatiques
À ce stade, le PO et l’équipe possèdent un Backlog exprimé sous forme de Story(s). Les story(s) servent à générer un dialogue autour du jeu à réaliser. Certains types de story(s) permettent au PO de décrire les « mécaniques »23 des joueurs. Par exemple : « En tant que joueur, je veux attaquer afin de tuer les ennemis. ». D’autres types de story permettent aux membres de l’équipe de développement de décrire des « outils » qui devront être réalisés lors des différents sprints de la saison. Par exemple : « En tant que développeur, je veux des options de triche afin de déboguer le jeu. ». Tous les types de story(s) sont considérés lors d’un sprint. Toutefois, les story(s) liées aux « outils » seront développés en amont du projet. Le PO et l’équipe procèdent à l’affinage du Backlog. Cette opération permettra d’ajuster la taille des story(s) dans le but de favoriser leur compréhension. Toutefois, avant de procéder à l’affinage du Backlog, le PO et l’équipe doivent d’abord prioriser chacune des story(s) présentes dans son Backlog. Le système MoSCoW est souvent utilisé :
Must24 Should25 Could26 Won’t27
Cela conduit à un second Backlog :
23 Une mécanique se compose de règles et les règles se composent de fonctions (ou tâches). Par exemple, la mécanique « avancer » et la mécanique « sauter » du jeu « Mario Bros » sont de mécaniques de type « cœur ». 24 On doit absolument l’avoir ! 28 On peut aussi penser que « plateforme en hauteur » est une option. Alors, on pourrait mettre « Could » 29 S’il s’agit de l’objectif principal, il faut mettre « Must »
Story Détail
S1 En tant que joueur, je veux marcher afin de progresser dans le niveau. — Must
S2 En tant que joueur, je veux sauter afin d’atteindre une plateforme en hauteur. — Should28
S3 En tant que joueur, je veux attaquer afin de tuer les ennemis. — Must
S4 En tant que développeur, je veux que le joueur puisse mourir afin d’augmenter les défis. — Must
S5 En tant que joueur, je veux voir ma vie afin de connaitre ma situation. — Should
S6 En tant qu’ennemi, je veux me déplacer afin d’atteindre un objectif. — Should29
8INF862 – Gestion de projets informatiques
Puis, le backlog est trié en ordre d’importance31 des story(s) :
Story Détail
S1 En tant que joueur, je veux marcher afin de progresser dans le niveau. — Must
S3 En tant que joueur, je veux attaquer afin de tuer les ennemis. — Must
S4 En tant que développeur, je veux que le joueur puisse mourir afin d’augmenter les défis. — Must
S7 En tant qu’ennemi, je veux attaquer un joueur, afin de lui faire des dégâts. — Must
S2 En tant que joueur, je veux sauter afin d’atteindre une plateforme en hauteur. — Should
S5 En tant que joueur, je veux voir ma vie afin de connaitre ma situation. — Should
S6 En tant qu’ennemi, je veux me déplacer afin d’atteindre un objectif. — Should
S12 En tant que joueur, je veux ramasser un objet afin de progresser dans le jeu. — Should
S14 En tant que joueur, je veux activer un objet environnemental afin de progresser dans le niveau. — Should
S8 En tant que développeur, je veux différents niveaux pour permettre de progresser dans le jeu. — Could
S9 En tant que développeur, je veux scénariser mon niveau. — Could
27 C’est une bonne idée, mais on l’aura pas, on n’aura pas le temps. 28 On peut aussi penser que « plateforme en hauteur » est une option. Alors, on pourrait mettre « Could » 29 S’il s’agit de l’objectif principal, il faut mettre « Must » 30 Si l’« objet environnemental » est optionnel, on pourrait mettre « Could » 31 Must, Should, Could, Won’t
Story Détail
S8 En tant que développeur, je veux différents niveaux pour permettre de progresser dans le jeu. — Could
S9 En tant que développeur, je veux scénariser mon niveau. — Could
S10 En tant que joueur, je veux utiliser un pouvoir afin d’améliorer mon personnage. — Could
S11 En tant que joueur, je veux faire une roulade afin d’esquiver une attaque. — Won’t
S12 En tant que joueur, je veux ramasser un objet afin de progresser dans le jeu. — Should
S13 En tant que joueur, je veux voir la description de l'objet que j'ai collecté. — Could
S14 En tant que joueur, je veux activer un objet environnemental afin de progresser dans le niveau. — Should30
S15 En tant que joueur, je veux entrer en interaction avec une princesse afin d’obtenir un pouvoir. — Won’t
8INF862 – Gestion de projets informatiques
Story Détail
S10 En tant que joueur, je veux utiliser un pouvoir afin d’améliorer mon personnage. — Could
S13 En tant que joueur, je veux voir la description de l'objet que j'ai collecté. — Could
S11 En tant que joueur, je veux faire une roulade afin d’esquiver une attaque. — Won’t
S15 En tant que joueur, je veux entrer en interaction avec une princesse afin d’obtenir un pouvoir. — Won’t
Par la suite, nous avons estimé l’effort de chaque story en points d’histoire. L’estimation en points d’histoire permet de réaliser cette étape plus facilement qu’avec une estimation en heure et de garder une certaine marge de manœuvre car un point d’histoire correspond à un intervalle de durée plutôt qu’une unique durée fixe. Nous avons choisi de faire correspondre à chaque point d’histoire un intervalle de durée entre 3 et 5 heures. Normalement, ces intervalles sont plus long mais comme c’est un projet scolaire sur lequel nous travaillons à temps partiel, la durée est ajustée en conséquence. Il est conseillé d’utiliser les nombres de la suite de Fibonacci32,33. Cela permet de mieux représenter l’incertitude dans l’estimation34. Le résultat de l’estimation de l’effort en points d’histoire conduit à un quatrième Backlog :
Story Détail
S1 En tant que joueur, je veux marcher afin de progresser dans le niveau. — Must — 2
S3 En tant que joueur, je veux attaquer afin de tuer les ennemis. — Must — 5
S4 En tant que développeur, je veux que le joueur puisse mourir afin d’augmenter les défis. — Must— 2
S7 En tant qu’ennemi, je veux attaquer un joueur, afin de lui faire des dégâts. — Must — 5
S2 En tant que joueur, je veux sauter afin d’atteindre une plateforme en hauteur. — Should — 2
S5 En tant que joueur, je veux voir ma vie afin de connaitre ma situation. — Should — 1
S6 En tant qu’ennemi, je veux me déplacer afin d’atteindre un objectif. — Should — 3
S12 En tant que joueur, je veux ramasser un objet afin de progresser dans le jeu. — Should — 3
S14 En tant que joueur, je veux activer un objet environnemental afin de progresser dans le niveau. — Should — 2
32 Elle doit son nom à Leonardo Fibonacci qui, dans un problème récréatif posé dans l'ouvrage Liber abaci publié en 1202, décrit la croissance d'une population de lapins : « Un homme met un couple de lapins dans un lieu isolé de tous les côtés par un mur. Combien de couples obtient-on en un an si chaque couple engendre tous les mois un nouveau couple à compter du troisième mois de son existence ? » (Wikipédia) 33 La suite de Fibonacci est une suite d'entiers dans laquelle chaque terme est la somme des deux termes qui le précèdent. Ses premiers termes sont : 0, 1, 1, 2, 3, 5, 8, 13, 21, ... (Wikipédia) 34 Les estimations sont toujours basées sur l’expérience et une technique appelée « Planning Poker ».
8INF862 – Gestion de projets informatiques
Story Détail
S8 En tant que développeur, je veux différents niveaux pour permettre de progresser dans le jeu. — Could — 8
S9 En tant que développeur, je veux scénariser mon niveau. — Could — 3
S10 En tant que joueur, je veux utiliser un pouvoir afin d’améliorer mon personnage. — Could — 3
S13 En tant que joueur, je veux voir la description de l'objet que j'ai collecté. — Could— 1
S11 En tant que joueur, je veux faire une roulade afin d’esquiver une attaque. — Won’t — 2
S15 En tant que joueur, je veux entrer en interaction avec une princesse afin d’obtenir un pouvoir. — Won’t — 3
Maintenant, il s’agit de convertir cet effort en heure, ce qui conduit à un cinquième Backlog :
Story Détail
S1 En tant que joueur, je veux marcher afin de progresser dans le niveau. — Must — 2 — 10
S3 En tant que joueur, je veux attaquer afin de tuer les ennemis. — Must — 5 — 15
S4 En tant que développeur, je veux que le joueur puisse mourir afin d’augmenter les défis. — Must— 2 — 8
S7 En tant qu’ennemi, je veux attaquer un joueur, afin de lui faire des dégâts. — Must — 5 — 10
S2 En tant que joueur, je veux sauter afin d’atteindre une plateforme en hauteur. — Should — 2 — 5
S5 En tant que joueur, je veux voir ma vie afin de connaitre ma situation. — Should — 1 — 3
S6 En tant qu’ennemi, je veux me déplacer afin d’atteindre un objectif. — Should — 3 — 10
S12 En tant que joueur, je veux ramasser un objet afin de progresser dans le jeu. — Should — 3 — 7
S14 En tant que joueur, je veux activer un objet environnemental afin de progresser dans le niveau. — Should — 2 — 5
S8 En tant que développeur, je veux différents niveaux pour permettre de progresser dans le jeu. — Could — 8 — 20
S9 En tant que développeur, je veux scénariser mon niveau. — Could — 3 — 10
S10 En tant que joueur, je veux utiliser un pouvoir afin d’améliorer mon personnage. — Could — 3 — 10
S13 En tant que joueur, je veux voir la description de l'objet que j'ai collecté. — Could— 1 — 5
S11 En tant que joueur, je veux faire une roulade afin d’esquiver une attaque. — Won’t — 2 — 7
S15 En tant que joueur, je veux entrer en interaction avec une princesse afin d’obtenir un pouvoir. — Won’t — 3 — 6
8INF862 – Gestion de projets informatiques
4. Les tâches du jeu
À ce stade, il s’agit de mieux comprendre le sens des story(s) en les fractionnant en une série de tâches à accomplir. Ce qui se traduit dans le tableau suivant :
Story Tâches
S1 T1 : Modèle de la princesse — T2 : Implémenter les contrôles — T3 : Déplacer le modèle T4 : Animation de déplacement — T5 : Être bloqué par l’environnement — T6 : FX sonores et particules
S3 T1 : Implémenter les contrôles — T2 : Animation d’attaque T3 : Collision et dégâts de l’arme — T4 : FX sonores et particules
S4 T1 : Gestion des points de vie — T2 : Animation de mort — T3 : UI écran de mort
S7 T1 : Modèle des ennemis — T2 : Implémenter une IA — T3 : Animation d’attaque T4 : Collision et dégâts de l’arme — T5 : FX sonores et particules
S2 T1 : Implémenter les contrôles — T2 : Appliquer une force vers le haut T3 : Animation de saut — T4 : FX sonores et particules
S5 T1 : UI en nombre de cœurs
S6 T1 : Ajouter un état patrouille à l’IA — T2 : Déplacer le modèle T3 : Animation de déplacement Animation de déplacement — T4 : FX sonores et particules
S12 T1 : Modèle des objets — T2 : Implémenter des contrôles — T3 : Faire disparaître l’objet T4 : Gestion des inventaires — T5 : FX sonores et particules
S14 T1 : Modèle des objets — T2 : Implémenter des contrôles — T3 : Action des objets T4 : Animation de l’objet — T5 : FX sonores et particules
S8 T1 : Designer les niveaux — T2 : Créer les modèles du décors — T3 : Construire les niveaux
S9 T1 : Rédiger le scénario — T2 : Afficher les texte en jeu — T3 : Créer le système de cinématiques
S10 T1 : Animations des pouvoirs — T2 : Implémenter des contrôles — T3 : Effet des pouvoirs T4 : UI des pouvoirs disponibles — T5 : FX sonores et particules
S13 T1 : Affichage dans une fenêtre — T2 : Enregistrer l’objet comme connu T3 : Contrôles pour fermer la fenêtre
S11 T1 : Implémenter des contrôles — T2 : Animation de roulade — T3 : Déplacement de la princesse
S15 T1 : Implémenter les contrôles — T2 : Créer des modèles de la princesse T3 : Activer la disponibilité du pouvoir — T4 : FX sonores et particules
8INF862 – Gestion de projets informatiques
Dans le contexte du jeu, cela aidera à déterminer les backlog(s) des sprint(s). Cela ne respecte pas intégralement la méthodologie « Agile : Scrum », mais il a été décidé, en accord avec le Scrum-Master de travailler ainsi. Si l’on regarde de plus près les tâches associées à la story S1 :
T1 : Modèle de la princesse
T2 : Implémenter les contrôles
T3 : Déplacer le modèle
T4 : Animation de déplacement
T5 : Être bloqué par l’environnement
T6 : FX sonores et particules Il faut constater que la story S1 est très complexe et qu’elle renferme plusieurs types d’informations, à savoir :
Des Asset(s) (T1, T4, T6),
Des Règles (T2 + T3, T5). L’objectif étant d’essayer de regrouper les tâches similaires dans des catégories d’action. Ces regroupements ont permis de retrouver l’information et de partager le travail35. Cela donne le tableau suivant :
Story(s) Catégorie
S1, S2, S11 Déplacement de la princesse
S3, S4, S10 Combats de la princesse
S6, S7 Comportements des ennemis
S5, S13 Interface
S12, S14, S15 Interactions de la princesse
S8, S9 Narration
35 Le partage du travail demande d’assigner un responsable pour chaque story. Du plus, des critères de réussite mesurables doivent être établie pour chacune des story(s) du backlog
8INF862 – Gestion de projets informatiques
5. Le premier sprint du jeu
À ce stade, l’équipe est en mesure de planifier un premier sprint. Les objectifs du sprint sont de réutiliser ce qui pouvait l’être du prototype initial (MVP) et de ré-implémenter le reste d’une manière mieux organisée. Les graphiques du prototype initial seront conservés dans ce projet. Seule les tâches des story(s) de priorité Must ont été choisies pour ce sprint. Ce qui nous donne le backlog de sprint suivant :
Si l’on se base sur les estimations faites précédemment36, le premier sprint correspond à 14 points de travail ou 43 heures. Comme il s’agit d’un premier sprint, il est probable que la bouchée sera peut-être un peu grosse ! L’équipe a réparti les tâches en fonction des compétences de chacun. Par exemple, un étudiant (ÉA) se concentre sur l’aspect artistique car il est pratiquement le seul à avoir des compétences suffisantes pour ces tâches. Dans certaines situations, l’équipe a décidé d’associer un ensemble de tâche à plusieurs personnes en même temps. Cela semble être un moyen de limiter les cas où une personne se retrouve seule face à un problème et peine à avancer37. Malheureusement, cela a causé plus de problèmes que prévu38 ! Certaines tâches non pas été terminées avant la fin du sprint. L’équipe a identifié les raisons des retards pour chaque tâche non achevée ainsi que la décision concernant l’avenir de la tâche.
36 Voir le cinquième Backlog. 37 Les Daily-Scrum(s) et l’Extreme-Programming peuvent palier à ces problèmes 38 Comme cela est illustré dans la section SprintReview.
Story Tâches
S1 T1 : Modèle de la princesse — T4 : Animation de déplacement T2 : Implémenter les contrôles — T6 : FX sonores et particules T3 : Déplacer le modèle — T5 : Être bloqué par l’environnement
S3 T1 : Implémenter les contrôles — T2 : Animation d’attaque T3 : Collision et dégâts de l’arme — T4 : FX sonores et particules
S4 T1 : Gestion des points de vie — T2 : Animation de mort — T3 : UI écran de mort
S7 T1 : Modèle des ennemis — T2 : Implémenter une IA — T3 : Animation d’attaque T4 : Collision et dégâts de l’arme — T5 : FX sonores et particules
8INF862 – Gestion de projets informatiques
Le tableau suivant résume la situation :
Story Tâches Raisons Décision
S1 T5 : Être bloqué par l’environnement Bugs : certains angles de mur Reportée : sprint2
S3 T3 : Collision et dégâts de l’arme Inconsistance de la détection Reportée : sprint2
S4 T2 : Animation de mort Manque de temps : trop de tâches différentes Reportée : sprint2
Le PO, le SM39 et l’équipe ont fait une revue du premier sprint pour savoir quels sont les points à améliorer dans le fonctionnement de l’équipe pour le sprint suivant. Il a été constaté l’importance d’avoir un responsable non seulement d’une story, mais aussi d’une tâche… Le tableau suivant récapitule cette revue :
Positif Négatif Amélioration
Les tâches prévues sont réalisées Communication au sein de l’équipe 1 personne/1 tâche
L’équipe fonctionne bien Retard : problèmes liés à Git et découverte de SourceTree
Établir un canal Discord : commandes Git
Nous avons profité de ce qui avait déjà été réalisé antérieurement
Mauvaise division du travail Améliorer la communication au sein du groupe
39 Il s’agit du Scrum-Master
8INF862 – Gestion de projets informatiques
6. Le deuxième sprint du jeu
Pour le deuxième sprint, l’équipe terminera d’abord aux éléments inachevés du sprint précédent40. Puis, l’équipe s’attaquera aux story(s) de priorité Should. Ce qui donne le backlog de sprint suivant :
Story Tâches
S1 T5 : Être bloqué par l’environnement
S3 T3 : Collision et dégâts de l’arme
S4 T2 : Animation de mort
S2 T1 : Implémenter les contrôles — T2 : Appliquer une force vers le haut T3 : Animation de saut — T4 : FX sonores et particules
S5 T1 : UI en nombre de cœurs
S6 T1 : Ajouter un état patrouille à l’IA — T2 : Déplacer le modèle T3 : Animation de déplacement Animation de déplacement — T4 : FX sonores et particules
S12 T1 : Modèle des objets — T2 : Implémenter des contrôles — T3 : Faire disparaître l’objet T4 : Gestion des inventaires — T5 : FX sonores et particules
S14 T1 : Modèle des objets — T2 : Implémenter des contrôles — T3 : Action des objets T4 : Animation de l’objet — T5 : FX sonores et particules
S8 T1 : Designer les niveaux
Si l’on se base sur les estimations faites précédemment41, le second sprint correspond à environ 13 points de travail en sus des tâches à compléter issues du sprint précédent ou 35 heures supplémentaires. Comme il s’agit du second sprint, il est probable que l’équipe soit mieux rodée et que cela se réalisera comme prévue… À la différence du précédent sprint, l’équipe n’a attribué qu’une seule personne par tâche car il s’est avéré que travailler à plusieurs sur une même tâche avait été contre-productif. L’équipe a également choisi de commencer la tâche sur le design des niveaux car il est prévu de commencer cette étape au troisième sprint. Il fallait donc avoir un début de design pour ne pas prendre trop de retard42 au début du prochain sprint.
40 Cela est quelque peu en rupture du concept de « Time Boxing » de la méthodologie ! 41 Voir le cinquième Backlog. 42 Ceci n’est pas très respectueux de la méthologie … toutefois, c’est aussi une forme d’agilité !
8INF862 – Gestion de projets informatiques
Malheureusement, certaines tâches non pas été terminées avant la fin du sprint. L’équipe a identifié les raisons des retards pour chaque tâche non achevée ainsi que la décision concernant l’avenir de la tâche. Le tableau suivant résume la situation :
Story Tâches Raisons Décision
S6 T4 : FX sonores et particules L’implémentation du nouvel état dans l’IA :
plus de temps que prévue Reportée : sprint3
S12
T4 : Gestion des inventaires Volonté de retravailler le système : plus grande flexibilité
Reportée : sprint3
S8 T1 : Designer les niveaux Passages à retravailler : manque d’intérêt Reportée : sprint3
Le PO, le SM43 et l’équipe ont fait une revue du deuxième sprint pour savoir quels sont les points à améliorer pour le sprint suivant. Le tableau suivant récapitule cette revue :
Positif Négatif Amélioration
Nette amélioration en productivité : meilleure répartition du travail
Bug trouvé tardivement : stress et perte de temps
Tester plus souvent avec le reste du jeu
Les problèmes avec Git et SourceTree sont résolus
Problèmes de code ont pris beaucoup de temps à être résolu
Ne pas hésiter à demander de l’aide lorsque c’est nécessaire
43 Il s’agit du Scrum-Master
8INF862 – Gestion de projets informatiques
7. Le troisième sprint du jeu
Pour le troisième sprint, l’équipe termine d’abord les éléments inachevés du sprint précédent. Maintenant que les principales fonctionnalités sont en place, l’équipe travaille sur la partie narrative du jeu avec le scénario. Puis, l’équipe s’attaquera aux story(s) de priorité Could. La conception des niveaux du jeu se poursuivra lors de ce troisième sprint. Ainsi, en se basant sur les parties des concepts approuvées lors du dernier sprint, l’équipe amorce leur création en jeu. Comme deux niveaux différents sont prévus, l’équipe doit partager le travail entre différentes personnes. Cela donne le backlog de sprint suivant :
Story Tâches
S6 T4 : FX sonores et particules
S12
T4 : Gestion des inventaires
S8 T1 : Designer les niveaux — T2 : Créer les modèles du décors — T3 : Construire les niveaux
S9 T1 : Rédiger le scénario — T2 : Afficher les texte en jeu — T3 : Créer le système de cinématiques
S10 T1 : Animations des pouvoirs — T2 : Implémenter des contrôles — T3 : Effet des pouvoirs T4 : UI des pouvoirs disponibles — T5 : FX sonores et particules
S13 T1 : Affichage dans une fenêtre — T2 : Enregistrer l’objet comme connu T3 : Contrôles pour fermer la fenêtre
Si l’on se base sur les estimations faites précédemment44, le troisième sprint correspond à environ 15 points de travail en sus des tâches à compléter issues du sprint précédent ou 45 heures supplémentaires. Malheureusement, certaines tâches non pas été terminées avant la fin du sprint. L’équipe a identifié les raisons des retards pour chaque tâche non achevée ainsi que la décision concernant l’avenir de la tâche. Le tableau suivant résume la situation :
Story Tâches Raisons Décision
S8 T3 : Construire les niveaux Les niveaux selon les concepts et modèles
réalisés nécessite plus de temps que prévue Reportée : sprint4
S10
T3 : Effet des pouvoirs Bug avec le pouvoir de glace et les plateforme mobile
Reportée : sprint4
44 Voir le cinquième Backlog.
8INF862 – Gestion de projets informatiques
Le PO, le SM45 et l’équipe ont fait une revue du troisième sprint pour savoir quels sont les points à améliorer pour le sprint suivant. Le PO, le SM46 et l’équipe ont également fait le point sur tout ce qui était en jeu pour vérifier que l’on était bien satisfait de ce qui avait été fait après l’avoir testé plus longtemps. Comme l’écriture du scénario s’est fait plus facilement et rapidement que prévu, Le PO, le SM47 et l’équipe ont décidé de l’ajouté en jeu sous la forme d’une voix-off enregistrée. Une nouvelle story est donc ajoutée dans le backlog : « En tant que joueur, je veux entendre un narrateur raconter l’histoire comme dans un conte de fée. ». Le tableau suivant présente cette nouvelle story :
Story Détail
S16 En tant que joueur, je veux entendre un narrateur raconter l’histoire comme dans un conte de fée. — Must — 2 — 10
Cette story se décompose en tâche de la manière suivante :
Story Tâches
S16
T1 : Enregistrer les fichiers sons du narrateur — T2 : Système pour jouer la voix du narrateur
Le PO, le SM48 et l’équipe ont fait le point sur tout ce qui était en jeu pour vérifier que l’on était bien satisfait de ce qui avait été fait après l’avoir testé plus longtemps. Ainsi, plusieurs points à améliorer sont identifiés ... Le tableau suivant récapitule cette revue :
Positif Négatif Amélioration
Très satisfait du scénario écrit et de l’avoir fini aussi rapidement.
Les pouvoirs se sont avérés bien plus compliqués à faire que prévus.
Faire plus attention lors de l’estimation des tâches.
45 Il s’agit du Scrum-Master 46 Il s’agit du Scrum-Master 47 Il s’agit du Scrum-Master 48 Il s’agit du Scrum-Master
8INF862 – Gestion de projets informatiques
8. Le quatrième sprint du jeu
Pour le quatrième sprint, l’équipe termine d’abord les éléments inachevés du sprint précédent. Comme il s’agit du dernier sprint, l’équipe révise les éléments existant, c’est-à-dire les améliorer pour obtenir un jeu le plus propre possible qui se rapproche d’une qualité professionnelle. Enfin, l’équipe procédera aux tests finaux. Cela nous donne le backlog de sprint 49suivant :
Story Tâches
S8 T3 : Construire les niveaux
S10
T2 : Implémenter des contrôles
S16
T1 : Enregistrer les fichiers sons du narrateur — T2 : Système pour jouer la voix du narrateur
Polissage Tâches
P1 T1 : Modification et ajout de modèles décoratifs
P2 T1 : Ajustement des paramètres de l’IA pour correspondre aux niveaux définitifs
P3 T1 : Ajouts d’effets sonores aux endroits auxquels nous n’avions pas pensé plus tôt
P4 T1 : Ajustement des paramètres de déplacement et de saut de la princesse
Test Tâches
T1 T1 : Test du jeu pour trouver d’éventuels derniers bugs
Tous les objectifs fixés pour le dernier sprint sont atteints. Le narrateur est implémenté et le jeu est amélioré. Les petits bugs mineurs repérés lors de nos derniers tests sont réglés pour la plupart à l’exception d’un problème avec l’IA des ennemis. La correction du bug aurait nécessité de gros changements qui mettrait en danger tout le comportement des ennemis. Comme le bug est difficile à reproduire et n’affecte que très peu l’expérience de jeu, il ne sera pas corrigé afin de préserver l’intégrité du jeu.
49 Ici, il s’agit de trois types de tâches
8INF862 – Gestion de projets informatiques
9. Conclusion
Ce projet est une première utilisation de l’approche « Agile : Scrum » et de la conception d’un jeu vidéo. Il en ressort que la communication, la priorisation et la répartition des tâches est primordiale pour la réussite d’un jeu. L’équipe aurait dû laisser plus de temps sur la fin (au moins un sprint complet) pour réaliser le polissage du jeu. En ajoutant des nouvelles tâches lors du dernier sprint, l’équipe a laissé de côté certains aspects du jeu qui auraient mérités d’être améliorés. L’estimation des charges est l’une des principales raisons des retards. C’est un exercice compliqué qui requiert de l’expérience pratique et qui ne doit pas être négligé. En général, le jeu est un succès et l’approche utilisée a porté ses fruits !