Juliette sort de sa chambre - UQACdimsboiv.uqac.ca/JEUX/guides/processus_exemple.pdf · 8INF862 –...

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.


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 »


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 »


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


É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 »


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


À 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

http://www.apple.com/ca/fr




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






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 ».






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






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


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


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


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


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é !


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 :


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 :


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


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 :


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.


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 :


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



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


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 !

Juliette sort de sa chambre - UQACdimsboiv.uqac.ca/JEUX/guides/processus_exemple.pdf · 8INF862 –...

Documents

Transcript of Juliette sort de sa chambre - UQACdimsboiv.uqac.ca/JEUX/guides/processus_exemple.pdf · 8INF862 –...