Agilité et développement de jeu vidéo
- No Crunch -
1 : Le cadre
Présentation rapide du projet
Gearprod (créé fin 2017) propose des salles de jeu livrées clef en main aux exploitants. Les aventures Echo Squad sont des expériences à la croisée des chemins, entre escape game, jeu vidéo et attraction sensationnelle.
L’expérience prend la forme d’un simulateur ludique de sous-marin jouable jusqu’à 6. Les joueur·euse·s embarquent afin d’explorer le mystère des abysses d’un monde entre le 20000 lieues sous les mers de Jules Vernes et la légende de l’Atlantide.
Présentation rapide de l’équipe
Nous développons l’ensemble du produit : la partie physique (salle et décors), les interfaces électroniques et enfin le logiciel de jeu vidéo.
Notre équipe est de taille modeste, Julien est le lead développeur, son expérience de plus de 10 ans en tant que Gameplay programmer chez Ubisoft nous permet de structurer la partie JV (jeu vidéo). Gilles avec son background d’ingénieur informatique supervise l’ensemble des choix techniques, quant à moi je me concentre sur la partie design.
Lorsque nos besoins en développement augmentent nous faisons appel temporairement à des freelance ainsi que des stagiaires en fin d’études pour compléter l’équipe (Graphismes, programmation… ) Nous travaillons également avec Aymeric Schwartz pour le Sound Design
Présentation des enjeux et des défis
Echo Squad est un projet unique et ambitieux, c’est un principe de jeu innovant, qui n’a jamais été produit à cette échelle. Nous avons dû faire face à de nombreux défis, tant au niveau logiciel qu’industriel.
Notre jeu est passé de plusieurs premiers prototypes conçus de manière artisanale, à une première reproduction du concept en 2019 pour enfin arriver aujourd’hui à un stade de maturité industrielle qui nous permet d’améliorer sa qualité et sa rapidité de réalisation à chaque nouvelle itération.
Dans cet article nous allons détailler l’utilisation du cadre Agile SCRUM ainsi que ses adaptations chez Gearprod. Si vous n’êtes pas familiers de cette méthode de production je ne peux que vous encourager à jeter un œil au guide scrum qui constitue une très bonne introduction
2 : Construire et planifier : le Backlog
Construire son backlog efficacement
Le principal enjeu de la constitution du backlog se situe entre le “trop” et le “pas assez”
- Trop d’éléments détaillés font perdre du temps en raffinage d‘user stories qui ne seront pas incluses dans les 2 ou 3 prochains sprints (et peut être parfois abandonnées)
- Pas assez, et vous allez perdre du temps lors des sprint plannings puisqu’il faut consacrer de l’énergie à la rédaction des stories (et donc parfois se questionner sur le design) mais aussi en ayant une vision à moyen terme diminuée.
L’établissement de réunions et de discussions régulières sur la vision du produit et du projet peuvent aider à se focaliser sur les futurs efforts à produire. Je crois également que l’équipe bénéficie de la vision qu’un backlog peut donner sur les échéances à moyen terme. Il me paraît important de pouvoir dépasser un horizon d’un ou deux sprints en listant les sujets possibles sans trop rentrer dans le détail.
Le choix des outils
Nous n’avons pas encore trouvé d’outils satisfaisant à 100% nos besoins, il est très facile de perdre beaucoup de temps dans la mise en forme et la mise en œuvre des techniques de production sans pour autant avoir une vision claire de l’apport réel en productivité de ces méthodes.
Nous avons décidé de rester globalement sur le fil entre un outil trop complexe à gérer et une absence de formalisme. Notre préférence s’est portée dans un premier temps sur Taiga.io mais nous migrons notre organisation vers un CRM très configurable : monday.com afin de pouvoir centraliser l’ensemble des informations et des outils au même endroit.
L’outil doit permettre d’avoir une bonne vue d’ensemble ainsi qu’un appui aux équipes pour l’organisation quotidienne des tâches. Je crois qu’il s’agit vraiment de trouver un cadre hautement configurable qui obtienne un consensus global de l’équipe sur ce point
Des travers complexes à éviter
Les principales difficultés que nous avons rencontré sur la gestion de projet et la planification concernent souvent la mauvaise adéquation entre nos moyens et nos ambitions.
Il est très important de sans cesse prendre du recul afin de garder en ligne de mire l’objectif global. Les sprints qui fonctionnent doivent anticiper les imprévus, ménager du temps pour la prospective et la recherche de solutions. Certaines deadlines peuvent facilement torpiller les dynamiques de production, certains impératifs économiques doivent être rapidement pris en compte afin de ne pas perdre de temps dans des développements qui ne sont pas focalisés sur la valeur ajoutée du produit.
De gros avantages
Le cœur du bénéfice lié à la production en méthode agile est la capacité de l’équipe a effectuer de nombreux changements de cap sans pour autant perdre de vue l’objectif. Plutôt qu’un long marathon dont la route à été décidée au départ, l’organisation en sprint oblige l’équipe à prendre du recul toutes les 2 semaines (taille des sprints chez Gearprod) après chaque sprint démo.
Un backlog bien pensé, capable de donner une vue d’ensemble efficace sur les développements n’a pas pour seule fonction d’établir une liste de tâches. C’est un éclairage clair sur l’avancée des développements.
Ce point est la clef pour que l’équipe ne se sente pas trop dépassée par les nombreux changements que le projet peut prendre au cours de son avancée.
En résumé :
- Attention à l’équilibre “liste complète des features vs trop de détail des features”
- Mettre en place une solution pour avoir une vision globale du projet
3 : L’art délicat du “Scope”
Comment designer avec l‘équipe
Chez Gearprod nous avons une politique du consensus concernant la plupart des décisions ayant trait au design du produit. Je pense que Gilles a le projet d’un article complet sur ce sujet mais je vais succinctement résumer.
Le point central est de partir du principe qu’une idée qui obtient le soutien de toute l’équipe au sens large (commercial, graphisme, programmation, design…) sera toujours plus efficace qu’un parti pris clivant. C’est une démarche qui demande du temps, qui provoque parfois des discussions animées.
L’avantage est qu’avec cette méthode, nous réussissons à obtenir l’adhésion très forte de toute l’équipe au projet. Le temps consommé lors des nombreuses réunions de design est du temps gagné lors de la réalisation des tâches. Notre travail a du sens par rapport au projet global et l’équipe est en pleine capacité afin de comprendre cela.
Ecoute, dialogue, transparence et bienveillance sont au cœur de ce processus
Comment arbitrer
Sujet sensible et pourtant central dans le développement du produit, l’arbitrage est un point clef. Souvent au cœur de frustrations qui peuvent s’étaler sur plusieurs mois, l’exercice difficile demande pas mal de pragmatisme et de recul.
Clairement, il s’agit là de travailler un mode de pensée orthogonal, partagé entre nos désirs de concepteur·ice·s passionnés par ce que nous créons : notre moteur motivationnel principal. Et d’un autre côté celui de gearprod, société qui doit, afin de subsister, maximiser la valeur ajoutée du produit et son CA. SCRUM propose quelques solutions :
- Ne pas hésiter, même si cela paraît à tort une perte de temps, à découper et re-rédiger des stories en en plusieurs plus petites features, plus essentielles et dépourvues de superflu
- Bien définir les objectifs de sprint afin que l’équipe puisse se focaliser sur une démo construite autour d’un thème
- Anticiper les démos au regard des milestones afin de se focaliser sur les stories qui vont dans le sens des objectifs essentiels à ces passages obligés (Démonstrations B2B, pré requis techniques…)
En résumé :
- Nous fonctionnons par consensus
- Re découper les stories jusqu’à ce qu’elles soient digestes pour l’équipe
4 : Long terme vs court terme
Avoir une vision du produit à court terme
Au quotidien, le projet est mené avec l’objectif du sprint en cours en ligne de mire. Nous n’hésitons pas à faire une courte réunion d’avancement souvent à la fin de la première semaine afin de nous assurer de la réussite du sprint. Nous veillons à la bonne répartition entre stories et time box, un gros déséquilibre en faveur des time box est souvent un signe de réorganisation interne nécessaire qu’il faut savoir interpréter.
Nous accordons facilement 10% du temps de travail total à l’organisation et la gestion de SCRUM. Je pense qu’au tout départ nous avons pu y passer jusqu’à 25%. L’aspect positif c’est que l’expérience s’accumule rapidement et cela nous a permis de grandement gagner en efficacité.
En comptant les daily (à la mi journée chez nous) Nous consacrons souvent entre une demie journée et une journée complète à la préparation de la démo de fin de sprint. Ce temps est consacré aux dernières intégrations, ainsi qu’aux nombreux tests et corrections mineurs. Cela permet de lancer la démo de manière sereine
Tendre vers les objectifs à long terme
L’un des travers souvent pointé du doigt dans les critiques de l’agilité en production concerne le manque de temps de développement long propice à la R&D et à la créativité.
C’est un paramètre que nous avons pris en compte et nous avons beaucoup travaillé afin de régulièrement faire un équilibre entre dette technique et livraison des démos. Il est important d’avoir des objectifs en ligne de mire afin d’anticiper les verrous techniques qu’il va falloir lever.
Nous intégrons régulièrement des stories un peu en décalage des développements habituels afin de ne pas nous laisser dépasser par les évolutions du produit et ensevelis sous une dette technique trop lourde à porter.
Nous essayons d’appliquer la même philosophie lors de la rédaction des stories afin de bien veiller à ne pas fermer de portes qui nous enfermerait dans des impasses de développement
Recrutement et formation
Fonctionner avec une équipe à géométrie variable, qui grossit ou bien diminue selon les besoins implique beaucoup de méthodologie et une grosse partie du temps allouée à la formation.
A notre grand étonnement les standards de production agile Scrum ne sont pas très répandus. Tout du moins pas autant que nous pouvions le penser quand nous nous sommes lancés. Cela implique pour nous de passer beaucoup de temps à “évangéliser” nos recrues, freelance et stagiaires au mode de fonctionnement SCRUM.
Le côté positif de cet aspect est que cela nous pousse à une très grande rigueur dans la méthode, une très bonne connaissance de SCRUM.
Lorsque nous avons débuté l’aventure nous avions tous une volonté de travailler avec SCRUM sans grosse expérience appliquée du modèle, aujourd’hui je pense que chaque membre de l’équipe core est capable d’assumer le rôle de scrum master chez Gearprod.
En résumé :
- Les démos sont au cœur du processus, elles permettent à la fois de constater l’avancée du projet mais aussi une projection vers les futurs développement
- Le temps consacré par toute l’équipe à la production est un investissement important mais qui porte rapidement ses fruits
5 : Scrum pour les artistes
Comment adapter scrum pour les métiers artistiques ?
SCRUM est un cadre de production particulièrement bien adapté à la création logicielle, or, le jeu vidéo est constitué de beaucoup d’autres corps de métiers parfois très éloignés du code.
Lors de la création de la mission 1 d’Echo Squad nous avons fait le choix de sous-traiter entièrement la partie graphique du jeu. La question de l’intégration des artistes à l’équipe s’est donc posée plus tardivement.
SCRUM fonctionne vraiment bien avec les équipes homogènes et non spécialisées. Il nous a fallu réfléchir à un système hybride pouvant accueillir en son sein des profils qui ne sont pas transversaux.
Concrètement :
- Intégrer et surtout solliciter les artistes dans le processus d’écriture des stories liés au code, leur faire comprendre que leur avis compte.
- Pousser les développeur·euse·s à donner leur avis sur les stories artistiques surtout concernant l’intégration et les tests.
- Réduire les frottements liés aux outils en allouant du temps (time box) à chacun pour se former sur la philosophie des outils que nous utilisons (Moteur, versioning…)
Il me semble que cela est possible, ou bien souhaitable parce que l’équipe reste de taille relativement réduite (inférieure à 10). Au-delà il semblerait opportun de créer plusieurs équipes et faire du “scrum de scrum” tout en conservant le maximum de passerelles possible.
Definition of done
Nous avons mis en place une “Definition of done” propre aux stories qui ne contiennent pas directement le code. Celle-ci décrit sur 5 niveaux la qualité que nous souhaitons obtenir pour les features. Voici un rapide résumé du document qui contient davantage d’exemples et de détails :
- Niveau 1 : Blocking, placeholders, éclairage sommaire…
- Niveau 2 : Modé générale, texture de base, éclairage 3 points…
- Niveau 3 : Modé finale, placement des props, textures compatibles HDR… C’est l’étape avant polish
- Niveau 4 : Gold, on peut pousser en prod
- Niveau 5 : Money shot, on veut en mettre plein la vue
Comme pour la DOD liée au code, nous y intégrons des phases de review, d’intégrations et de tests afin de garder un haut niveau de qualité
En résumé :
- Quelques changements du cadre permettent de mieux intégrer les artistes aux équipes SCRUM
- Nous avons adapté la definition of done afin de simplifier le processus
6 : No crunch
Plus qu’une déclaration d’intention
Une bonne fois pour toutes, le crunch est un aveu d’échec pour une équipe et pour une entreprise. Le bénéfice à court terme ne vaut pas les dégâts sur le moral de l’équipe et la baisse de productivité à long terme.
C’est la théorie, pour la pratique il y a tout de même beaucoup de mesures à prendre…
- Avoir une réserve suffisante de Cash afin de parer aux imprévus, cela implique de prévoir à l’avance les périodes difficiles et arbitrer les dépenses au maximum
- Avoir passé suffisamment de temps sur la phase de conception du projet, “Fail Cheap”
- Avoir mis les moyens pour lever les incertitudes et verrous techniques pendant la pré-production “ Fail fast “
- Communiquer régulièrement la vision à l’équipe afin de s’entendre et s’accorder sur un objectif commun
- Etre transparent sur les enjeux, financiers et temporels afin de ne pas surprendre l’équipe si des changements de cap doivent avoir lieu tout comme des suppressions de features.
- Faire confiance à SCRUM, c’est beaucoup de temps consacré à l’organisation, cela fait très peur au début, un vrai saut de la foi.
- Gérer très en amont les deadlines, donc cutter les features / re-scoper le projet et prendre suffisamment de marge temporelle
- Accepter l’engagement des équipes sur la quantité de travail des sprints sans chercher à les influencer pour en ajouter toujour “plus”
S’obliger à faire un choix dans la production des features
Encore une fois, nous nous en remettons à la méthode. SCRUM nous pousse à faire des choix. Choisir un thème de démo, choisir une feature plutôt qu’une autre, redécouper une story afin de la rendre plus digeste et retirer le superflu.
C’est en réduisant ou en modifiant le scope que l’on peut agir réellement sur le crunch. J’ajouterais à cela l’importance de la réalisation rapide des démos successives qui permet de tester plus régulièrement le jeu. L’idée est de diminuer au maximum le risque inhérent à la conception d’un produit nouveau.
Confiance et motivation d’équipe
L’équipe est responsable de sa charge de travail. C’est elle qui fixe la quantité de stories qui seront accomplies pendant le sprint. Cet engagement collectif est primordial car il réduit la charge mentale individuelle et il force l’équipe à collaborer pour atteindre un objectif commun.
En résumé :
- Le crunch est contre productif
- Nous avons un panel de mesures nécessaires afin de l’éviter : confiance, transparence, bienveillance, organisation, communication…
