Note du traducteur : Ce chapitre est extrait du livre Agile Game Development (ISBN 0321618521, copyright 2010 Clinton Keith), il est reproduit et traduit avec la permission de l’auteur et de Pearson Education.
Cette traduction existe également au format epub et pdf.


 

[Pour sa nouvelle rubrique, Gamasutra présente un chapitre extrait du livre Développement agile de jeux vidéos avec Scrum de Clinton Keith, développeur et consultant Scrum senior, dans lequel il explique les tenants et les aboutissants de l’agilité. Dans ce chapitre, il aborde l’intégration des processus Scrum au sein des équipes, y compris les bonnes pratiques et les pièges éventuels.]

Pendant plus de 20 ans, j’ai travaillé sur la création de différents produits, des chasseurs F-22 aux jeux vidéos. Les moments les plus marquants de ma carrière sont clairement gravés dans ma mémoire par les équipes projets avec lesquelles j’ai pu travailler. Ces équipes avaient la caractéristique de prendre du plaisir au travail et à avoir une productivité plus importante que le reste de la compagnie ou des autres équipes du projet pour lesquels nous travaillions à l’époque.

Un de ces moments marquants fut de travailler avec l’équipe projet du premier Midtown Madness. L’équipe était largement composée de développeurs qui n’avaient jamais travaillé sur un jeu auparavant. Microsoft, notre éditeur, et le studio pour lequel nous travaillions, Angel Studios, nous avait laissés toute lattitude pour développer le jeu. En conséquence, les plus infimes détails étaient laissés à notre appréciation. L’abandon de notre projet n’était jamais très loin, et … dans certains cas, cela s’est joué à quelques heures près. Nous devions faire nos preuves.

Ce qui en émergea fût une équipe ayant une vision commune, un sentiment d’appartenance et de la fierté. Nous avions travaillé dur sur ce jeu. Par exemple, tous les jours à 18h00, nous débutions une partie du jeu en réseau, puis à 20h00, nous nous réunissions dans une salle de conférence pour discuter de l’amélioration de l’expérience de jeu.

Il m’arrivait souvent d’avoir une idée qui surgissait dans ma tête au milieu de la nuit, et au petit matin, je me dépêchais de revenir au boulot pour l’essayer, souvent pour trouver mes coéquipiers déjà présents, qui étaient arrivés encore plus tôt voire même qui avaient passé toute la nuit à travailler sur leur propre idée.

Même si nous passions de longues heures sur le jeu, cela ressemblait plus à un passe-temps pour lequel nous nous passionnions plutôt qu’un travail, mais jamais nous ne l’avons ressenti comme un “travail de forçats”.

Le jeu que nous avons livré fut un succès, mais la véritable récompense fut l’expérience de travailler avec cette équipe. La plus grande partie de l’alchimie de cette équipe reste un mystère à mes yeux. Il ne semble pas qu’il y ait une formule pour savoir comment de telles équipes peuvent être créées, mais j’ai trouvé qu’il est assez facile d’empêcher la formation de telles équipes. L’idée maîtresse de Scrum est de permettre, si possible, à de telles équipes de se former, et de les accompagner dans leur croissance.

Ce chapitre explorera certains des principes de base de Scrum et des pratiques pouvant aider ces équipes et comment de grands projets de plus de 100 personnes peuvent utiliser ces pratiques et permettre aux individus de ces équipes d’avoir toujours une vision commune, un sens de l’appropriation, et de la fierté. Il explorera aussi les différentes structures d’équipes qui ont été formées sur de grands projets de jeux vidéos.

Le présent chapitre décrit le rôle central des équipes dans Scrum, le rôle de l’encadrement, et comment de petites équipes Scrum peuvent monter en charge sur des projets de grande taille.

Grandes équipes

Les grandes équipes sont l’un des facteurs les plus importants pour la création d’un jeu réussi. Les grandes équipes sont aussi les équipes les plus difficiles à monter. Elles ne peuvent pas être créées à travers la seule application de règles ou de pratiques. Un leadership au niveau du studio et du projet est obligatoire pour faciliter leur éclosion.

Les grandes équipes partagent les caractéristiques suivantes :

Elles suivent une vision et un but commun : Tout le monde dans l’équipe comprend l’objectif et le but de son travail.

Les compétences des membres de l’équipe se complètent : Les membres de l’équipe dépendent les uns des autres pour accomplir leurs objectifs en utilisant leurs compétences respectives dans un but commun.

Elles font la démonstration d’une communication ouverte et sans risque : Les membres de l’équipe doivent se sentir dans un environnement de confiance pour discuter de tout avec tout le monde.

Elles partagent la prise de décision, la responsabilité, et la transparence : L’équipe réussit ou échoue ensemble, et non individuellement. Chacun mérite son poste dans l’équipe au quotidien. Il n’y a pas de place pour les titres ou les égos.

Elles prennent du plaisir ensemble : Les membres de l’équipe passent du temps ensemble et apprécient la compagnie des uns et des autres. Ils prennent soin les uns des autres.

Elles livrent de la valeur : Les grandes équipes sont fières de leur travail et le résultat livré est systématiquement de grande valeur.

Elles démontrent un engagement commun : Les grandes équipes partagent une même cause. Quand un membre a un problème, toute l’équipe donnera un coup de main pour l’aider à s’en sortir. En conséquence, les grandes équipes livrent de la valeur parce qu’elles font attention à l’ensemble plutôt qu’à leurs parties respectives. Les grandes équipes sont engagées sur leurs objectifs. Elles vont au-delà de ce qui est nécessaire pour accomplir un objectif dans lequel elles croient.

Scrum créé un cadre de travail, avec ses pratiques et ses rôles, pour soutenir ces équipes. Elles exigent de la part de l’encadrement et de la direction, facilitation et soutien, pour pouvoir évoluer. Les grandes équipes sont peu répandues. Elles créent des expériences – comme celle mentionnée en introduction du chapitre – pour lesquelles des personnes se battent pendant toute leur carrière pour en faire partie.

Pour faire un gâteau, certains ingrédients sont nécessaires avant de commencer. Si un de ces ingrédients, oeufs, farine et ainsi de suite, vient à manquer, vous ne pourrez pas faire un gâteau. Toutefois, la manière dont ces ingrédients sont préparés et cuisinés ensemble pour faire le gâteau est la différence principale entre un gâteau de mariage inoubliable et un truc cuit dans un four “Easy-Bake” (“Mon premier four”, four pour jeunes filles pour apprendre à cuisiner - NdT).

Le leadership et le talent sont les ingrédients nécessaires pour faire un grand jeu vidéo, mais comme pour le gâteau, la manière dont ces ingrédients sont préparés ensemble, dans une équipe par exemple, est le facteur déterminant de la qualité du jeu. Scrum ne donne pas les ingrédients pour (faire - NdT) les grandes équipes mais les aide à “mélanger et à cuire” ce qui est disponible là pour réaliser cet objectif.

Une approche Scrum des équipes

À travers ses principes et ses pratiques, Scrum crée les conditions permettant à de telles équipes d’atteindre l’excellence :

Les équipes pluri-disciplinaires : permettent aux équipes de livrer des fonctionnalités et des mécaniques ayant clairement de la valeur pour les clients et les parties prenantes

L’auto-gestion : permet aux équipes de sélectionner la quantité de travail sur laquelle ils peuvent s’engager à chaque sprint et à faire ce travail par tout moyen qu’ils jugent appropriés

L’auto-organisation : permet aux équipes d’avoir un degré d’autorité et de responsabilité pour sélectionner leurs membres

Un vrai leadership : influer du leadership à travers du tutorat et des facilitations pour libérer tout le potentiel possible de l’équipe.

Les principes et les pratiques seront examinés dans le reste de cette section.

Expérience

“L’interaction de l’équipe est au coeur de Scrum. Une réunion quotidienne autour du tableau des tâches est interactive, vibrante, collaborative, visuelle et tactile. C’est une manière visuelle de montrer l’objectif vers lequel l’équipe est en train de se battre et les progrès qu’elle fait. Elle, chacun et tous les membres de l’équipe, sont égaux.”

“L’objectif leur appartient. C’est un travail d’équipe. Ils se rassemblent autour du tableau pour se coordonner les uns avec les autres, pour honorer la contribution des autres à l’effort [^1], et pour corriger la trajectoire en cours lorsqu’elle sort de sa course. Ils argumentent, discutent, partagent, apprennent, s’améliorent constamment, célèbrent, se renforcent les uns les autres, et trouvent des solutions.”

“Il y a autre chose que Scrum fait pour l’équipe : il créé de la transparence. Étant donné que Scrum dépend de la collaboration et de l’avancée continuelle, les problèmes sont gérés par l’équipe au fur et à mesure de leur apparition au lieu d’être gérés plus tard ou d’être mis sous le tapis.”

“Un environnement hiérarchisé, cloisonné ne créera jamais une équipe. Une équipe travaille ensemble vers un objectif commun. Un groupe travaille ensemble vers un objectif qui lui est donné. Scrum est bruyant et salissant. Il vit, il respire, il s’étire, il se transforme et il s’étend. L’interaction est le coeur de l’équipe. Le coeur de Scrum est l’équipe.”

– Shelly Warmuth, écrivain indépendant et concepteur de jeu

Équipes pluri-disciplinaires

Lorsque les divers documents ont été écrits et les plannings créés, les priorités des plannings de chaque discipline s’accordent rarement. Les développeurs lisent souvent le document de conception et conçoivent des systèmes basés sur les objectifs indiqués dans le document. La complexité et le risque priorisent ce travail, et non la valeur de la fonctionnalité.

Par exemple, si la conception identifie des personnages marchant sur les murs, alors ils conçoivent cette exigence dans le moteur du personnage. Cela demande beaucoup de travail de modifier le moteur physique et le moteur de la caméra. Ces changements sont considérés par les développeurs comme ayant une priorité élevée, car ils affectent le coeur même des moteurs. Par conséquent, ils commencent à travailler sur ces changements dès le début. Le problème est que la fonctionnalité “marcher sur les murs” n’est peut être pas très importante pour les concepteurs. La fonctionnalité pourra même être abandonnée lorsqu’elle sera vue.

Ce manque de synchronisation de priorités entre les disciplines conduit à des délais dans la prise de connaissance progressive du jeu : cette connaissance qui vient uniquement de l’utilisation de chaque mécanique présente dans un jeu opérationnel.

Scrum exige une synchronisation des disciplines à chaque sprint. Cela force à changer la manière dont chaque développeur travaille quotidiennement peu importe sa discipline. Une équipe pluri-disciplinaire utilise la valeur pour explorer une solution répondant aux besoins de la technologie, de la conception et de l’animation

Cette synchronisation pilote les changements dans le sens où chaque discipline travaille pour éviter qu’une discipline aille trop loin par rapport aux autres, par exemple en créant des architectures spéculatives.

Éventuellement, les développeurs d’une équipe Scrum peuvent adopter les pratiques du développement piloté par les tests, évoqués au chapitre 10 “Technologie agile”, pour permettre le développement priorisé par la valeur sans être pénalisé par le coût de changements tardifs que les conceptions préalables essayent d’éviter.

Les équipes Scrum pluri-disciplinaires minimisent les délais et les coûts qui se produisent dans les grandes organisations hiérarchiques orientées par discipline. Les membres de l’équipe partage le même objectif et ainsi les mêmes priorités, encourageant la collaboration. Les pratiques telles que la mêlée quotidienne renforce l’engagement de l’équipe vers l’objectif du sprint et la résolution des problèmes au quotidien qui ordinairement “passeraient entre les mailles du filet” des disciplines.

Auto-gestion

Scrum réponds aux problèmes de communication dans les grandes équipes non pas en ajoutant des couches supplémentaires de gestion mais en répartissant les personnes du projet dans de petites équipes. Les équipes Scrum sont généralement composées de 5 à 9 développeurs pluri-disciplinaires qui prennent en charges les fonctionnalités majeures du projet et qui créent des segments verticaux de ces fonctionnalités à chaque sprint. Les équipes gagnent à s’auto-gérer en :

  • Sélectionnant la quantité de travail à accomplir pour le sprint à venir et en s’engageant à le faire
  • Décidant de la meilleure façon de travailler ensemble
  • Estimant leur propre travail et en surveillant quotidiennement leur avancée vers l’objectif engagé
  • Montrant les objectifs du sprint atteints aux parties prenantes à chaque sprint
  • En prenant la responsabilité de leur performance et en trouvant des manières de l’améliorer

L’auto-gestion de l’équipe ne s’accomplit pas en une nuit. Cela exige du tutorat et de la pratique pour y arriver. Elle demande l’établissement d’une confiance entre l’encadrement et les équipes ainsi qu’une définition claire d’une ligne de partage des responsabilités.

Auto-organisation

L’auto-organisation de l’équipe est la pratique la plus difficile pour les équipes essayant d’atteindre l’auto-gestion. Les équipes auto-organisées sélectionnent leurs propres membres dont elles pensent qu’ils seront capables de les aider à obtenir de meilleurs résultats.

Les bénéfices de l’auto-organisation est une part essentielle d’une équipe auto-gérée. Quand les équipes “ont” la gestion de leurs membres, alors les engagements pris par l’équipe sont considérés avec un sentiment plus profond d’appropriation. Lorsque les personnes sont assignées à une équipe construite par l’encadrement, c’est quelque chose sur laquelle elles n’ont pas de contrôle, et, comme nous l’avons vu, une absence de contrôle empêche un engagement total.

Les équipes sont autorisées à changer leurs membres entre les sprints, et généralement elles le font avant le premier sprint d’une nouvelle livraison. Peu de temps après la discussion d’un planning de livraison avec l’équipe projet, elles négocient entre elles pour s’échanger des membres. Les équipes prennent en compte les éléments suivants lorsqu’elles s’auto-organisent :

Quels sont les objectifs de livraison et le planning de livraison initial ? Quelques fois les objectifs de livraisons exigent une réorganisation complète des équipes. Par exemple, un jeu orienté sur des mécaniques de jeu solo pourrait fonctionner avec un gameplay en ligne pour la prochaine livraison. En tout cas, cela pourrait exiger une redistribution des compétences.

Quelles disciplines et compétences sont exigées pour réaliser les objectifs de livraison ? Par exemple, si une équipe ayant implémenté un moteur de tir est maintenant chargée de créer l’intelligence artificielle (IA) qui réplique, elle doit faire venir un développeur d’IA. Si seulement quelques changements simples doivent être faits au code, peut-être qu’un développeur débutant sera le meilleur choix.

Quelles sont les priorités des objectifs de livraisons ? Si les équipes se disputent des individus, l’objectif de livraison le plus prioritaire détermine où les individus vont. Par exemple, si deux équipes, l’une s’occupant des tirs et l’autre du pilotage, ont besoin d’intelligence artificielle et qu’un seul développeur d’IA est présent, l’objectif le plus prioritaire détermine que ce développeur va en premier dans l’équipe du moteur de tir.

Est-ce qu’il existe une alchimie entre les membres de l’équipe ? Même si cela est souvent ignoré, l’alchimie des individus fonctionnant en équipe a un grand impact sur l’ensemble des pratiques. Par exemple, il est souvent avantageux pour les équipes d’avoir en leur sein une personne avec un franc parler, mais cela peut devenir un inconvénient lorsqu’il y en a deux ou plus. Les deux peuvent avoir le même niveau de compétence, mais réunis ensemble, tout simplement, cela ne fonctionne pas. Les équipes savent cela et devraient être capable de maîtriser la composition de leur équipe pour l’éviter.

Comme beaucoup d’autres pratiques Scrum, il n’est pas attendu d’une équipe qu’elle maîtrise l’auto-organisation dès le début. La plupart des studios débutant avec Scrum évitent tout d’abord cette pratique puis doucement avec le temps permettent à l’équipe un plus grand degré de liberté sur qui est ajouté ou enlevé de l’équipe

Éventuellement l’équipe prendra ses propres décisions, avec un encadrement influençant ses décisions et apportant son assistance en cas de conflits et sur les problèmes outrepassant l’autorité de l’équipe. Les récompenses sont immenses. Des équipes auto-organisées livrent des niveaux de performances inégalés et apprécient leur travail beaucoup plus que les équipes gérées de manière conventionnelle (Takeuchi et Nonaka 1986).

Lorsque les gens entendent parler pour la première fois d’auto-organisation, ils sont sceptiques. Cela leurs rappellent les souvenirs douloureux de l’enfance de ne pas être choisi dans l’équipe de sport. Les équipes inexpérimentées considèrent cette pratique comme un concours de popularité. Ils auront besoin de l’assistance de l’encadrement pour les aider à faire les meilleurs choix (cf. chapitre 16, “Démarrer en Scrum”). Les équipes agiles expérimentées, qui comprennent l’engagement d’équipe, finissent par faire les choix les plus pertinents qui leur permettront d’augmenter leur vélocité.

Occasionnellement, les équipes “auto-organisent le départ de ses membres” entre les sprints. L’équipe écarte ses membres peu performants ou qui ne jouent pas en équipe (voir encadré “Lorsque quelqu’un est viré d’une équipe”). Cela est nécessaire pour permettre aux équipes de prendre vraiment l’engagement et le contrôle de leur travail.

Lorsqu’une personne se fait virer d’une équipe

Il est assez rare pour une équipe de virer quelqu’un de leur équipe à l’unanimité. Généralement la personne virée a ignoré pendant plusieurs mois les retours de l’équipe et de l’encadrement sur son manque de travail d’équipe ou de performances. Toutefois, être écarté d’une équipe est un acte qui ne peut pas être ignoré. C’est une décision forte d’une partie de vos pairs.

Après cet évènement, une autre équipe voulant bien prendre cette personne doit être trouvée. Elle doit être mise au courant des problèmes ayant conduit à son éviction de l’équipe précédente. Les équipes ne peuvent pas être forcées d’accepter des personnes dont elles ne veulent pas.

S’il s’agit de sa première éviction et que d’autres équipes sont présentes, la personne pourra rejoindre facilement une autre équipe. La plupart du temps, soit la personne corrige les problèmes (ayant conduit à son éviction - NdT) et devient un membre utile de l’autre équipe, soit la personne trouve simplement une équipe avec laquelle l’alchimie est meilleure.

En de rares occasions, cela ne fonctionne pas bien non plus avec l’équipe suivante. Après quelques évictions, il est courant de constater qu’aucune autre équipe n’acceptera cette personne. C’est alors le devoir de l’encadrement que de la licencier. Certaines fois la personne a déjà compris le message et part avant que cela ne se produise.

J’ai vu cela arriver seulement en de rares occasions. C’est malheureux, mais c’est un avertissement aux équipes : elles contrôlent leurs destinées. Elles sont responsables et ont l’autorité nécessaire pour faire les changements qui améliorent leur performance. Quand cette autorité n’existe pas, cela ne permet pas à l’équipe d’atteindre son potentiel. Les équipes qui ne peuvent pas s’auto-organiser sentiront qu’elles sont enlisées avec leurs membres et qu’il n’y a rien qu’elles ne puissent faire là-dessus. Elles se sentent incapables de faire le changement dont elles ont besoin et qu’elles ne peuvent avoir le niveau d’engagement qu’elles pourraient avoir.

Quand vous voyez la performance des équipes qui ont réalisées leur potentiel, vous arrêtez de vous posez la question sur la valeur de ces pratiques. Cela demande d’effectuer un saut dans l’inconnu pour leur permettre de le faire dans vos studios. Malheureusement, certains n’atteignent pas ce point et ne voient pas le potentiel des grandes équipes se réaliser.

Effectif de l’équipe

La littérature Scrum recommande des équipes ayant une taille comprise entre sept et neufs membres (Schwaber 2004). Cette recommandation est basée sur des études (Steiner 1972) et une expérience vécue montrant des piques de productivité sur ces tailles d’effectifs.

Un défi pour le développement agile de jeux est de construire des équipes pluri-disciplinaires n’excédant pas ces bornes. Pour quelques équipes, le nombre de disciplines désirées pour réaliser un objectif peut être trop important. Par exemple, l’effectif souhaité pour une équipe réalisant un prototype pourrait être le suivant :

  • Deux artistes pour les niveaux
  • Un artiste pour les accessoires
  • Un artiste pour les textures
  • Un animateur
  • Un concepteur de sons
  • Un artiste conceptuel
  • Un concepteur de niveau
  • Un concepteur de gameplay
  • Un développeur pour les graphismes
  • Un développeur pour le gameplay
  • Un développeur pour l’intelligence artificielle

Voici une équipe de 12 personnes qui commencent à montrer quelques-uns des problèmes évoqués dans de plus grosses équipes. Par exemple, quelques membres sont plus susceptibles que d’autres de ne pas parler ouvertement et de ne pas être entendu. De par son engagement et sa responsabilité commune, cela freine l’ensemble de l’équipe dans l’augmentation de sa performance.

Un autre problème avec les grosses équipes est que des sous-équipes ou des bandes ont tendance à se former. J’ai été dans une équipe telle que celle décrite précédemment. Les graphistes et les artistes formaient des cabales séparées qui érigeaient des barrières de communication. Lorsque je visitais l’un de ces groupes, il en critiquait un autre.

Ces critiques n’étaient pas mises sur le tapis entre les deux factions, et les problèmes restaient cachés. Cela a eu un impact majeure sur la qualité des niveaux du prototype produit et sur la vitesse à laquelle ils étaient créés. L’intervention du Scrum Master a fini par résoudre ceci, mais une petite équipe aurait sûrement corrigé elle-même le problème plus tôt.

Une équipe comme celle-ci pourrait considérer de se scinder en deux équipes, chacune ayant des objectifs plus restreints qui “organise” le développement des niveaux du prototype, mais qui introduit des questions de dépendance et de responsabilité. J’encourage les équipes à essayer différentes organisations pendant quelques sprint, et si cela ne résout pas les problèmes, ils peuvent se reformer à nouveau en une grosse équipe.

Quelques studios ont utilisés des équipes de trois à cinq personnes et ont indiqués que cela fonctionnait très bien.

Tracer la limite

Au studio High Moon, nous avons établis quelques “lois” qui avaient pour objectifs de décrire les pratiques et les règles sur lesquelles les projets et leurs équipes auraient autorité et sur lesquelles ils ne l’auraient pas. Nous faisions référence à ces lois sous la dénomination de “lois de l’état” définissant l’autorité d’une équipe et d’un projet et de “lois fédérales” qui définissent les décisions qui sont faites pour eux.

Pour les lecteurs étrangers, aux États-Unis les lois fédérales sont valables dans le pays entier, alors que les lois de l’état valent à l’intérieur d’un état. Si les deux rentrent en conflit, les lois fédérales prévalent.

Un exemple de loi fédérale a été l’utilisation pour l’ensemble du studio d’une technologie définie pour le moteur et le pipeline. L’encadrement du studio ne voulait pas que les équipes créées un moteur et des pipelines différents pour leurs propres jeux. Nous voulions capitaliser à partir de la compréhension des individus d’une technologie commune au fur et à mesure de leur migration d’un projet à un autre. Un exemple de loi de l’état fût la manière d’organiser le projet lui-même en de petites équipes et d’implémenter les items du product backlog.

Gouvernance

Lorsque j’étais enfant, mon père décida de m’apprendre à nager, comme son père lui avait appris, en me jetant dans un lac, à un endroit où je n’avais pas pieds. Après avoir regarder les bulles remontées pendant trente secondes, il plongea et me sortit de l’eau. Je n’ai pas appris à nager ce jour-là. En fait, j’ai appris à éviter d’essayer pendant le reste de l’été.

Avec mes enfants, nous avons adopté une approche plus graduelle pour les accompagner à affronter des défis de plus en plus grand en natation : de la nage du petit chien pendant quelques secondes à l’aller-retour dans un bassin de taille olympique.

La gouvernance dans une organisation agile est un défi similaire. Les organisations agiles doivent monter en gouvernance à chaque niveau et trouver une approche, entre le micro-encadrement d’équipes et les jeter là où elles n’auront pas pieds, qui leur apportera la voie vers le succès. Ces deux extrêmes conduiront à l’échec.

Conduite de projet

Les responsabilités des personnes en charge des projets (développeurs seniors, artistes confirmés, designers en chef et ainsi de suite) peuvent changer au fur et à mesure de l’adoption de l’agilité par les équipes.

Conception et planification : Les responsables définissent toujours la conception (gameplay, technique, concept, et ainsi de suite) pour leur propre discipline en concertation avec les autres disciplines et supervisent comment la conception est implémentée.

Allocation de ressources : Les responsables estimeront l’effectif nécessaire dans leur discipline pour le projet, sur quels domaines ils travailleront, et approximativement à quel moment ils travailleront dessus, mais ceci ne sera que des estimations. Graduellement, les équipes prendront ensuite la responsabilité d’identifier les zones de besoins par sprint et par livraison.

Gestion et création de tâches : Les responsables ne prendront plus en charge la scission du travail en tâches qu’ils estiment, assignent et suivent. Les équipes gèrent ceci elles-mêmes. Les responsables participent toujours à la planification du sprint et assistent les membres de leur discipline à améliorer les compétences d’identification et d’estimation des tâches.

Revue et promotion : Même si les responsables peuvent continuer à faire un entretien de chaque membre de leur discipline régulièrement, généralement sur une base annuelle, la performance de l’équipe devient une part plus importante des indicateurs pour l’entretien (cf. section “Entretiens”).

Tutorat: Les responsables travaillent avec des développeurs moins expérimentés pour améliorer leur productivité. Le rôle de responsable se modifie du simple encadrement à travers les outils de gestion de projet vers un autre où ils “viennent et voient” ce qu’il se passe avec chaque développeur aussi fréquemment que possible (voir la section “Tutorat”).

L’auto-gestion des équipes défie la définition du rôle du responsable. Il est difficile pour beaucoup de responsables d’abandonner la prise de décisions détaillées pour les équipes au quotidien et leur permettre de risquer l’échec, même pour de petits défis. Toutefois, les bénéfices de l’accroissement des comportements d’auto-gestion deviennent apparents lorsque certaines tâches courantes qui étaient de la responsabilité du responsable, telle que la création, l’estimation et le suivi de tâches sont pris en main par l’équipe. Par exemple, une équipe projet de 80 développeurs génère et nécessite un suivi d’environ 1 600 tâches pour un sprint de quatre semaines. [1] Il s’agit d’un volume écrasant d’informations détaillées à gérer pour n’importe quel comité de décision et cela monopolise le temps de ses membres au détriment de devoirs plus essentiels par rapport à leur rôle de responsables.

[1] 10 équipes - 8 personnes - 1 tâche par jour - 20 jours par sprint

Tutorat

Le rôle le plus important du responsable est de tutorer les développeurs à améliorer leur manière de travailler. Un exemple : des développeurs seniors se mettent par deux avec des développeurs juniors pour leur enseigner comment améliorer leurs pratiques de développement et de conception.

Souvent, les développeurs juniors implémentent des solutions de simulations beaucoup trop coûteuses en ressources CPU. Je me souviens d’un développeur débutant ayant pour tâche d’implémenter l’effet du vent. Il commença par implementer un moteur complexe de gestion de la dynamique des fluides qui utilisait 90% du CPU pour simuler la présence de milliers de particules d’air. Un développeur senior intervint et lui montra quelques trucs pour produire un bon effet en quelques heures exigeant peu de ressources CPU.

Scrum créé les opportunités pour des responsables pour continuer à travailler sur des jeux et de montrer par l’exemple à la place de le faire par la feuille de calcul. Plutôt que passer la moitié de leur journée avec un outil à créer et à suivre des tâches, les responsables interagissent avec les personnes pour travailler avec eux individuellement.

Entretiens

Un autre rôle critique du responsable est d’offrir un accompagnement de carrière pour les développeurs dans leur discipline. Dans les entreprises utilisant une structure d’encadrement matricielle, cela prend la forme d’un entretien d’activité et de négociation salariale annuelle. Cela renforce l’esprit de performance basée sur la discipline sur la performance basée sur l’équipe.

Par exemple, si un artiste est évalué sur la productivité de création d’éléments graphiques des artistes de l’année passée, alors ces derniers se focaliseront sur la rapidité de création d’éléments graphiques pour améliorer cette métrique. En conséquence, lorsqu’un équipier interrompt un artiste à propos d’un problème sur un jeu , cela réduit le nombre d’éléments qu’ils créent ; l’artiste essaiera alors de s’isoler pour réduire ces interruptions en vue d’avoir un meilleur entretien d’activité. Cela n’est pas un cercle vertueux.

Les responsables dans les environnements agiles ont introduits des entretiens d’activités fréquents faits par les pairs de l’équipe pour compléter, si ce n’est remplacer, le processus d’entretien annuel. Cela favorise le retour d’informations et l’introduction du travail d’équipe et de la collaboration pluri-disciplinaire. Les rôles des responsables pour chaque discipline seront décrits en détails dans les chapitres suivants.

Les rôles de directeur

L’industrie du jeu est remplit de rôles de directeurs, tels que directeurs artistiques, directeurs techniques, et ainsi de suite. Généralement, ces rôles sont donnés aux membres d’une discipline qui montrent un haut degré de compétence mais qui ont aussi l’autorité sur le travail, plutôt qu’un groupe de personne.

Souvent, ces rôles existent pour superviser et approuver ou désapprouver le travail fait dans leur domaine. Les équipes Scrum doivent ajuster leurs pratiques pour répondre aux besoins de ces rôles, tels que décris dans le chapitre 11, “Art et audio agiles”.

Équipes de jeu et collaboration

Le développement de jeu exige un haut niveau de collaboration entre les différentes disciplines. Par exemple, dans un jeu, un personnage est animé, a des mouvements physiques, des textures, des modèles, des sons et des comportements qui doivent travailler ensemble pour produire un tout. Une seule discipline ne peut accomplir toutes ces fonctions toute seule. Elle doit travailler de manière rapprochée avec les autres disciplines pour créer les fonctionnalités.

Malheureusement, lorsque les équipes grossissent, les disciplines ont tendance à se regrouper ensemble. Cela retarde l’intégration de leur travaille et conduit à de nombreux problèmes. Scrum se concentre sur le développement de fonctionnalités intégrées fréquemment, conduisant ainsi à une collaboration rapprochée pluri-disciplinaire. La collaboration pluri-disciplinaire quotidienne conduit les développeurs à penser à eux-mêmes en tant que développeurs de jeu d’abord et seulement ensuite, en tant que développeur informatique, concepteur, artiste, testeur, producteur.

Dans cette section, nous examinerons les différentes structures d’équipes qui sont utilisées par les équipes agiles de jeu pour promouvoir la collaboration à travers un projet et à travers les disciplines.

Collaboration, interrompue

Il existe une grande diversité de moyens dans les entreprises pour essayer d’élaborer un esprit d’équipe dans de grosses équipes pluri-disciplinaires. Par le passé, j’ai moi-même participé à quelques-uns de ces exercices potentiellement dangereux.

Je me rappelle encore de ce jour où lors un exercice de construction d’équipe, j’ai failli être sérieusement blessé. C’était sur un terrain de paintball situé dans les hautes terres de chaparral (le chapparal est une sorte de maquis - NdT) à l’est de San Diego. J’étais allongé sur le dos, quasiment à court de munitions, pendant qu’une trentaine d’ingénieurs en électronique essayaient de me tirer dessus.

J’étais un jeune ingénieur en informatique travaillant pour une compagnie d’avionique militaire. Durant ma carrière dans l’industrie de la défense, je fus témoin de l’animosité entre les ingénieurs en électronique et les ingénieurs en informatique. Du point de vue des ingénieurs en électronique, nous n’étions pas de vrais ingénieurs et nous étions sur-rémunérés. Ils considéraient souvent notre code comme un “mal nécessaire”. Nous considérions que les ingénieurs en électroniques avaient une attitude élitiste et étaient dépassés dans leur approche technique.

Personnellement, je croyais que les ingénieurs en électronique nous détestaient parce que nous étions souvent les héros d’un projet. Le logiciel que nous écrivions contournaient souvent les défauts de leurs matériels menaçants le projet en phase finale.

La partie commença par la constitution de deux équipes. Bien sûr, une équipe fut celle des ingénieurs en électronique, et l’autre, la nôtre, celle des ingénieurs informatique.

Je ne mentirais pas en disant que nous étions les meilleurs ce jour-là. En fait, nous ne l’étions pas. Je ne trouverai pas d’excuses et ne les accuserai pas d’avoir tricher, même s’ils apportèrent quelques gadgets étranges avec eux. À vrai dire, l’équipe de développement perdit la plupart des parties, et nous avons été battu à plate couture.

J’ai affronté le plus grand défi lors de la dernière partie. Nous étions en train de jouer un match d’élimination dans un petit “village” en contreplaqué. Le but du jeu était pour une équipe d’éliminer chaque joueur de l’équipe opposée pour gagner.

Ce fut un nouveau bain de sang pour l’équipe de développement. Nous avons été rapidement décimé. J’ai survécu en me cachant avec plusieurs autres développeurs sur le toit d’une hutte en contreplaqué. Trois murs nous offrait un couvert partiel, et la seule manière de monter sur le toit était une trappe accessible depuis la pièce en bas.

Un par un, mes compagnons d’infortune furent tués par des démonstrations héroïques de bravoure et aussi d’ignorance de l’importance d’un couvert. J’étais content de faire profil bas et de survivre.

Tout à coup, les arbitres soufflèrent dans leurs sifflets pour signaler la fin de la partie. Ils croyaient que tous les ingénieurs en informatique étaient morts ! Je sautais, et rugissais de défi à ce que je pensai être un ou deux ennemis rescapés.

Mon rugissement mourut rapidement dans ma gorge lorsque je vis que la quasi-totalité de l’équipe ennemie des 30 ingénieurs en électronique était encore en vie. Des secondes interminables semblèrent défiler alors que nous nous jaugions respectivement. Et puis l’un des arbitres annonça, “La chasse est ouverte !” et il siffla dans son sifflet. Je n’oublierai jamais la vue de ces ingénieurs en électronique, qui hurlèrent avec une rage jubilatoire de nerd courant vers moi alors que j’allais me planquer à nouveau à couvert.

J’ai tenu un certain temps. J’ai même réussi à tuer quelques-uns de ces ennemis ingénieurs. J’aimerai dire que j’ai été le héros ce jour-là, mais cela ne devait pas être le cas. Quelqu’un finit par m’atteindre. Les ingénieurs en électronique achevèrent ainsi leur victoire sur nous, et nous sommes retournés travailler avec des sentiments d’antagonisme renouvelés.

Equipes par fonctionnalité

Les équipes par fonctionnalité sont des équipes pluri-disciplinaires qui développent les fonctionnalités de base du jeu. Par exemple, une petite équipe pluri-disciplinaire telle que présentée en figure 8.1 pourrait prendre la responsabilité des mécanismes de pilotage.

Un bénéfice majeure des équipes par fonctionnalité est le sentiment d’appropriation qu’elles éprouvent. Pour la plupart des développeurs, participer au développement complet de quelques mécanismes est bien plus satisfaisant que de participer à la réalisation partielle de plusieurs. Pour beaucoup de développeurs, cela donne un plus grand sentiment d’accomplissement.

Figure 8.1 : un exemple d'équipe de mécanismes de pilotage

 

Une équipe par fonctionnalité devrait avoir toutes les personnes dont elle a besoin pour développer les mécanismes. En pratique, c’est difficile à accomplir. Quelques fois, les équipes doivent partager des disciplines rares. Un exemple : l’artiste des effets spéciaux (FX) qui est utilisé 25% du temps par une seule équipe à la fois. Souvent ce genre de personne est partagé par plusieurs équipes.

Équipes fonctionnelles

Les équipes fonctionnelles sont composées de développeurs qui sont pour la plupart de la même discipline et qui travaillent toujours sur une fonctionnalité clé. Quoique moins communes que les équipes par fonctionnalité, les équipes fonctionnelles présentent des avantages.

Un exemple est celui de l’équipe plateforme composée principalement de développeurs. Ces développeurs sont des experts dans l’optimisation de la performance pour une plateforme particulière telle que la PlayStation 3 (PS3) ou la Xbox 360. Concentrer ces individus dans une seule équipe concentre l’effort sur des problèmes difficiles qui seraient trop coûteux pour des équipes par fonctionnalité pour qu’elles les résolvent toutes seules. Par exemple, si les développeurs PS3 sont répartis sur plusieurs équipes, alors leurs efforts pour créer un produit PS3 seront insuffisants.

Des équipes fonctionnelles sont utilisées habituellement pour des travaux d’infrastructure ou de fondations. Utiliser des équipes fonctionnelles pour un travail de plus haut niveau pluri-disciplinaire conduit souvent à des solutions qui sont plus adaptées pour la discipline que pour le jeu.

Un exemple d’équipe fonctionnelle pauvrement pensée fut celle formée pour créer l’intelligence artificielle d’un jeu. Cette équipe était composée de développeurs d’intelligence artificielle qui voulait créer la meilleure intelligence artificielle architecturée possible. Malheureusement, leur effort conduisit à une fonctionnalité d’intelligence artificielle qui fut livré aux autres équipes qui, ni ne comprirent comment l’intelligence artificielle fonctionnait, ni ne bénéficièrent de l’ensemble des fonctionnalités qui y étaient incluses. À la fin, l’équipe se sépara, et les développeurs en intelligence artificielle ont été dispersés sur l’ensemble du projet pour implémenter l’intelligence artificielle dont les diverses équipes avaient besoin.

Équipes de production

Les équipes de production sont des équipes pluri-disciplinaires utilisées pour les projets de développement de jeu qui sont entrés en phase de production. Ces équipes ont un flux de travail plus défini pour créer du contenu et appliquent certaines des pratiques lean et kanban décrites au chapitre 7, “Planification de projet de jeu vidéo”.

Les équipes de production peuvent échanger des membres selon les besoins avec les autres équipes de production pour maintenir un flux continu de création d’éléments. Les équipes de production se forment souvent à partir d’équipes par fonctionnalité telle la transition mécanique de la pré-production à la production. Par exemple, la plupart des développeurs pourraient quitter l’équipe de pré-production de niveaux lorsque le jeu entre en production, pour être remplacés par plus de modeleurs, d’artistes de textures, et de concepteurs audio.

Équipes d’infrastructure partagée

Les équipes d’infrastructure partagées offrent des services de support tels que des services de développement de moteur, de cinématiques et d’audio sur lesquels plusieurs jeux reposent. Ces équipes sont dominés par une discipline tels que les compositeurs dans une équipe audio, mais ont aussi d’autres disciplines dans l’équipe, tels que des développeurs, pour supporter les pipelines et les outils.

Un question fréquemment posée est comment les équipes d’infrastructure partagée (IP) devraient s’organiser dans un environnement agile de projet. Étant donné qu’elles supportent plusieurs équipes, elles reçoivent des requêtes pour des fonctionnalités qui ne peuvent pas être facilement priorisées comme elles peuvent l’être pour une seule équipe.

De la confusion et des conflits peuvent survenir entre l’équipe IP et leurs “clients”, les jeux dépendant d’eux.

Il existe des pratiques valables pour ces équipes :

  • Les équipes IP doivent avoir leur propre backlog et leur propre product owner. Avoir plus d’un product backlog et plus d’un product owner est une recette pour aller droit au désastre. L’équipe devrait bénéficier de tous les avantages que les autres équipes agiles ont : un backlog compréhensible et une seule vision.
  • Les équipes clients devraient identifier les priorités pendant la planification de livraison et inclurent l’équipe IP (ou du moins leur responsable et leur product owner) dans le planning de livraison. Les équipes IP ont généralement besoin d’une planification ayant un horizon à plus long terme qu’un seul sprint.
  • Les équipes IP devraient inclure le support dans leur vélocité que cela concerne ou pas les tâches. Réserver un certain pourcentage de votre bande passante pour des maintenances inattendues est essentiel.
  • Prêter des membres de l’équipe IP à une autre équipe pour un sprint est autorisé, mais cela devrait être identifié dans le planning de livraison. Il est très important d’avoir des membres de l’équipe IP voyant sur le terrain comment leur “produit” est utilisé.
  • Idéalement, le product owner IP devrait être à un niveau de responsabilité exécutif (ou être en contact fréquent avec eux) pour arbitrer les conflits de priorités entre produits. Décider de supporter un jeu au détriment d’un autre est une décision (stratégique) au niveau de l’entreprise et cette décision devrait avoir l’aval des dirigeants du studio. Par exemple, le directeur technique de l’entreprise devrait être le product owner de l’équipe IP.
  • Avec son propre product owner et son propre backlog, une équipe IP pourra avoir le sentiment d’être une véritable équipe et prendre la pleine possession de son travail.
  • Les équipes IP sont aussi le modèle pour des “équipes de support en direct” supportant un ou plusieurs jeux livrés. Par exemple, une équipe qui supporte des jeux massivement multi-joueurs et leurs grandes communautés de joueurs.

Équipes outils

Un équipe outils est composée de créateurs d’outils (développeurs, artistes techniques, testeurs) dont les clients sont les utilisateurs d’un ensemble d’outils et de pipeline communs.

Comme pour une équipe d’infrastructure partagée, une équipe outils apporte souvent son support à plusieurs projets et a son propre product backlog.

Les équipes outils ont un autre avantage, celui de livrer des outils à des clients qui sont dans le même bâtiment qu’elles, et pas uniquement aux parties prenantes qui les représentent. Avoir des utilisateurs d’outils qui peuvent participer à la définition, à la priorisation, à la planification, et aux revues du backlog est un avantage majeur pour les développeurs de l’outil. Le développement de l’outil peut bénéficier grandement de l’utilisation d’une approche agile et se dérouler de manière encore plus exploratoire.

Équipes d’experts

Une équipe d’experts est un ensemble de développeurs d’une seule discipline. À la différence des autres équipes, elles ne peuvent pas avoir leurs propres objectifs de sprint. Elles existent pour supporter les équipes qui réalisent. Par exemple : des animateurs experts qui supporteraient une équipe par fonctionnalité ayant besoin d’un grand nombre d’animations pour un seul sprint.

Un autre avantage d’une équipe d’experts est d’offrir un centre de service pour la production artistique. Cela est connu aussi sous le nom d’approvisionnement interne. Les artistes et animateurs d’environnements sont beaucoup demandés pendant la production, et les équipes d’experts permettent de réguler les exigences en ressources dans un studio de développement important.

Lors d’une livraison, les équipes d’experts demandent plus de planification et d’encadrement afin d’être certain qu’elles seront pleinement utilisées. Les équipes d’experts sont plus communément utilisées en fin de pré-production ou en production.

Équipes d’intégration

C’est un défi que de partager une vision commune dans des projets importants comportant plus de 40 développeurs. La vision au sein de ces différentes équipes peut dériver, même avec à une hiérarchie de product owners. En conséquence, certains projets ont des “équipes d’intégrations” intégrant dans une expérience unifiée les mécanismes développés initialement par les équipes par fonctionnalité.

Ces équipes sont structurellement similaires aux équipes par fonctionnalité. La différence est qu’elles sont responsables du thème global du jeu. Par exemple, dans un jeu de course-action, l’équipe principale prendra en charge les mécanismes de pilotage de l’équipe qui l’a développé, une fois que ceux-ci seront suffisamment matures. À partir de ce point, elles modifient et maintiennent les différents mécanismes afin qu’ils fonctionnent facilement ensemble.

Objection : équipes d’experts et équipes principales – Cela ne fait pas vraiment très “Scrum”

Idéalement, chaque équipe devrait être une équipe fonctionnelle, mais le nombre même de spécialités requises pour le développement de jeu conduits à des équipes d’experts et principales. L’objet de Scrum est de permettre davantage aux équipes de trouver la manière de faire mieux plutôt que de “suivre les règles à la lettre”.

Scrum distribué et à grande échelle

Même si la taille de l’équipe idéale oscille entre cinq et neuf personnes, généralement les projets modernes de développements de jeux exigent plus de développeurs. Quelques fois les développeurs sont dispersés sur plusieurs sites. Scrum a des pratiques lui permettant d’escalader plusieurs équipes Scrum distribuées.

Cette section examinera les pratiques couramment utilisées pour faire monter en change Scrum : tenir une réunion de Scrum de Scrums, mettre en place une hiérarchie de product owners, aligner les dates de sprint, créer des communautés de pratiques, et éviter les dépendances. Elle se conclura par une discussion sur les défis et les solutions du développement distribué.

Le problème avec les grosses équipes

Les tailles des équipes projets des jeux PC et consoles ont radicalement grossies depuis “le bon vieux temps” du développeur solitaire qui concevait, codait, illustrait, orchestrait, et testait le jeu tout seul jusqu’aux équipes projets d’aujourd’hui qui dépassent souvent les 100 personnes. Malheureusement, l’efficacité d’un projet de 100 personnes n’est pas généralement équivalente à 100 fois le projet fait par une personne seule. La perte d’efficacité a plusieurs sources, la principale étant la surcharge de communication.

Considérez la combinaison de deux personnes communiquant sur un projet. Ces “lignes de communication” grossissent beaucoup plus vite que le nombre de personnes sur le projet (cf. figure 8.2). Par exemple, un projet avec 100 personnes a 4 950 lignes de communications possibles entre ses membres. [2] Cela est beaucoup trop important pour être maîtriser par n’importe quel individu dans l’équipe afin de savoir à qui parler lorsqu’une question ou un problème survient. En conséquence, des hiérarchies d’encadrement sont créés pour superviser cette complexité.

Figure 8.2 : Taille de l'équipe et lignes de communication

 

De telles hiérarchies créent des barrières entre deux personnes qui ont doivent résoudre des problèmes rapidement. Par exemple, si un animateur a besoin de corriger le code d’une animation, il doit envoyer une requête pour le changement à son responsable.

Ce responsable à son tour, passe la requête à un chef de projet. Le chef de projet envoie une requête au responsable des développeurs qui communique alors le changement à un développeur qui fait le changement. La totalité du processus dépend grandement de la rapidité de chaque lien dans la chaîne de communication et de la précision avec laquelle l’information est passée. Malheureusement, ce n’est pas ce qui arrive généralement.

[2]La formule pour les lignes de communication est n*(n1)/2, où n est le nombre de personne dans le projet.

Scrum de Scrums

La pratique centrale pour la montée en charge de Scrum est la réunion de Scrum de Scrums. La figure 8.3 montre comment un gros projet peut être divisé en sous-équipes et comment chaque équipe envoie un membre de son équipe au Scrum de Scrums.

Figure 8.3 : La réunion de Scrum de Scrums

 

La réunion permet à un ou plusieurs représentants de chaque équipe de se réunir pour informer les autres équipes de leurs avancées et de leurs obstacles. Le membre de l’équipe participant à la réunion dépend souvent de la nature des éléments à remonter au Scrum de Scrums. Le Scrum de Scrums est très efficace pour identifier les problèmes communs ou potentiels qu’une équipe peut résoudre pour toutes les autres.

Par exemple, l’équipe technologie moteur travaille souvent avec plusieurs autres équipes pour améliorer la technologie du moteur. Des changements sur cette technologie génèrent régulièrement des problèmes après livraison pour les autres équipes à cause d’anomalies non détectées.

Au Scrum de Scrums, les changements imminents sur la technologie utilisée sont évoqués afin que tout problème qui survient soit rapidement identifié et résolu. Dans ce cas de figure, un responsable technique de l’équipe de cette technologie partagée assiste à la réunion pour évoquer les changements en attente.

Le Scrum de Scrums est différent des réunions d’équipes quotidiennes Scrum.

Il n’est pas obligatoire qu’elle soit quotidienne : Elle peut être hebdomadaire ou bi-hebdomadaire. Le groupe qui se rencontre devrait décider de la fréquence la plus adaptée.

Son objectif est la résolution de problèmes : La réunion n’est pas limitée à 15 minutes. Les solutions potentielles sont décidées en réunion. Cette réunion est peut être le seul moment où ces personnes se rencontrent pendant la semaine, et les problèmes qu’ils évoquent ont un impact fort sur le projet.

Les questions sont différentes : La réunion commence avec chacun des participants répondant à des questions légèrement différentes.

  • Qu’est ce que l’équipe a fait depuis la dernière fois que nous nous sommes rencontrés ? Chaque représentant de l’équipe décrit, en terme générique, ce que son équipe a réalisé depuis la dernière réunion du Scrum de Scrums.
  • Qu’est ce que l’équipe fera ensuite ? Les représentants de chaque équipe évoquent ce que leurs équipes accompliront ensuite.
  • Qu’est ce qui empêche l’équipe d’avancer ? Quels sont les obstacles qui causent des problèmes à chaque équipe ? Il y a généralement des problèmes que l’équipe ne peut résoudre seule ou qu’elle communique aux autres équipes.
  • Est ce qu’il y a une équipe qui empêche une autre équipe d’avancer ? Comme dans l’exemple précédent sur le moteur, les équipes qui font souvent des changements peuvent impacter les autres équipes. Peut être qu’une équipe est en train de réaliser un changement sur le moteur d’animation qui sera utilisé par toutes les autres équipes plus tard dans la journée. Si les personnages commencent à se déplacer bizarrement après cette livraison, alors avoir eu la connaissance de ce changement pourra faire gagner beaucoup de temps pour trouver l’origine du problème.

En réponse aux deux premières questions du Scrum de Scrums, il est important d’évoquer la progression de la totalité de l’équipe et non pas la progression de chaque individu de chaque équipe. Sinon la réunion prend trop de temps.

Le Scrum de Scrums n’a pas de product backlog, mais il maintient un backlog succinct des obstacles communs aux équipes qui doit être passé en revue à chaque réunion. Un exemple d’obstacles communs est l’absence d’un artiste d’effets spéciaux du studio pour maladie et dont l’absence impacte plusieurs équipes. Beaucoup d’obstacles identifiés prennent des jours à résoudre, leur suivi est donc un atout.

Un Scrum master pour le Scrum de Scrums n’est pas nécessaire, mais les équipes désignent souvent l’un des leurs à ce rôle pour que la réunion reste sur la bonne voie.

Une hiérarchie de product owners

La demande de disponibilité d’un product owner pour les équipes de jeu peut être supérieure à celle demandée dans les autres secteurs économiques. La raison est que les équipes ont un besoin viscéral de savoir si le “fun” qu’elles sont en train de créer correspond au “fun” que le product owner souhaite. Des questions telles que : quel devrait être le degré de “dynamisme” d’une réaction du moteur physique ou quelle doit être la “vivacité” de la transition de l’animation - sont subjectives et demandent des retours quotidiens de la part de la personne ayant la vision du jeu : le product owner.

Dans de gros projets, avec une douzaine d’équipes ou plus, cela crée un problème. La disponibilité du product owner devient rapidement insuffisante, et il ne peut pas maintenir une vision commune du jeu sur toutes les équipes. Sans une vision commune, chaque mécanique s’éloignera de la vision originelle au fur et à mesure de son évolution, et le jeu deviendra moins cohérent et moins attrayant.

Pour un product owner, déléguer une partie de son périmètre dans un gros projet, est une pratique efficace. Et établir une hiérarchie de product owners est une des façons de le faire. Un responsable product owner guide le projet, et chaque mécanique essentielle a un product owner. Figure 8.4 montre un exemple d’une hiérarchie de product owner.

Le responsable product owner supervise les deux product owners qui travaillent avec une ou deux équipes Scrum. Le responsable product owner continue de travailler avec les équipes directement, par exemple avec l’équipe d’interface utilisateur, mais il délègue la responsabilité “product owner comme cochon” aux équipes qui ont leur propre product owner (NdT : la phrase “product owner comme cochon” fait référence à la fable du cochon et du poulet sur la gestion de projet ici en vo et là en vf)

Chaque product owner travaille au quotidien avec ses équipes pendant le sprint, les aidant à planifier le sprint afin de s’assurer qu’ils réalisent l’objectif du sprint. Par exemple, en tant que product owner dans une équipe implémentant la mécanique de pilotage, mon rôle incluait de montrer à l’équipe la vision commune pour la mécanique. Cela demandait souvent des débats sur l’équilibre entre un ressenti simulation vs un ressenti arcade pour les contrôles, la physique du véhicule, et l’environnement.

Figure 8.4 : Un exemple de hiérarchie de product owners

 

Les product owners doivent s’assurer que la vision est commune sur la totalité du projet. Cela comprend de fréquentes réunions entre eux, y compris les réunions de Scrum de Scrums, pour répondre à toutes les questions relatives à la vision du jeu.

Les product owners prennent les directives de la part du responsable product owner entre les sprints et le planning de livraison. Il y a souvent une divergence d’opinion entre les product owners sur la meilleur voie à suivre pour atteindre les objectifs de livraison. La perspicacité du product owner d’une équipe est inestimable pour trouver la meilleure voie, mais le responsable product owner est responsable pour garder une vision cohérente du jeu sur l’ensemble des mécaniques et des fonctionnalités.

Un product owner d’équipe crée une vision commune sur un gros projet et s’assure de la cohérence de la vision partout.

Les équipes d’intégration sont un type d’équipe aidant à garantir qu’une vision commune sur un gros projet soit maintenu lors de l’intégration des fonctionnalités et des mécaniques.

Synchroniser les dates de sprint

Les différentes équipes Scrum travaillant sur un projet peuvent synchroniser leurs planifications de sprint et revoir les dates ou avoir des calendriers indépendants. La figure 8.5 illustre la différence entre les deux dispositions.

Pour les équipes, avoir des calendriers indépendants présentent quelques avantages. Le plus important est que les équipes n’ont pas à lutter pour obtenir de la disponibilité de la part du product owner. Pour les équipes ayant des calendriers synchronisés, il peut être difficile de planifier la disponibilité du product owner, et tout spécialement lors de la planification du sprint suivant.

Malgré cela, il est généralement plus pertinents de synchroniser les sprints (Cohn 2009). Les avantages pour le jeu vidéo sont les suivants :

Les équipes peuvent échanger des membres : Après la revue de sprint, personne n’a d’engagement sur un objectif de sprint quelconque, il devient alors facile pour les équipes de s’échanger des membres en vue du prochain sprint.

Une vue intégrée du jeu est encouragée : Les équipes avec une date de revue de sprint identique peuvent intégrer tout le travail en un seul build afin que la totalité du jeu soit passée en revue. Cela encourage davantage la collaboration inter-équipe ainsi qu’une vue intégrée du jeu.

Une hiérarchie de product owners dans des équipes importantes éliminent le problème de disponibilité insuffisante du responsable product owner lorsque les équipes qui utilisent des sprints synchronisés doivent planifier leur prochain sprint.

Figure 8.5 : sprints indépendants et synchronisés

 

Communautés de pratique

Un autre défi créé par les gros projets Scrum est la perte potentielle de communication causée par l’éparpillement de la discipline ou de l’expertise fonctionnelle dans plusieurs équipes pluri-disciplinaires. Par exemple, si les développeurs des graphismes sont répartis sur plusieurs équipes, qu’est-ce qui les empêchent de résoudre les mêmes problèmes sur les graphismes différemment ?

Nous avons connu ce problème quand tous les développeurs d’intelligence artificielle ont été répartis sur trois équipes par fonctionnalité. Chaque équipe a implémenté sa propre machine à état d’intelligence artificielle. Une équipe avait implémenté un système à base de script, une autre avait implémenté un système à base de C++ et une troisième équipe en avait développé un qui était manipulé à travers une interface graphique.

La solution est d’établir des communautés de pratique qui peuvent partager la connaissance et élimine la duplication de l’effort. La figure 8.6 montrer comment les développeurs d’IA répartis dans plusieurs équipes Scrum peuvent former une communauté de pratique d’IA.

Chaque communauté peut décider à quelle fréquence elle doit se réunir et solutionner les problèmes auxquels elle est confrontée. La communauté d’IA pourrait discuter de solutions communes qu’elle pourrait implémenter.

Les Scrum masters peuvent former une communauté pour partager les améliorations des pratiques de leur équipe. Les graphistes pourraient former une communauté pour se plaindre de tous les autres.[^3]

Les communautés de pratiques ne peuvent pas avoir leurs propres objectifs de sprint ou avoir du travail en dehors de leurs propres équipes. Leur seul objectif est de partager l’information.

Figure 8.6 : une communauté de pratique d'IA

 

Éviter les dépendances

À l’intérieur d’un sprint, les dépendances inter-équipes peuvent empêcher les équipes d’atteindre leurs objectifs. Considérons une équipe dont l’objectif de sprint est d’implémenter une mécanique pour escalader les murs mais qui dépend d’une autre équipe pour fournir l’animation.

À cause de la séparation des équipes et des objectifs, il est probable que l’équipe mécanique donnera son travail à l’équipe d’animation quasiment à la fin du sprint plutôt que de collaborer avec eux au quotidien. Au mieux, cela limite le nombre d’itérations de développement de la mécanique. Au pire, les objectifs de l’équipe d’animation pour son propre sprint pourrait les empêcher de rendre l’animation de l’escalade du mur dans les temps.

Lorsque les projets commencent à utiliser Scrum, les dépendances sont assez fréquentes, et elles sont la source de nombreux obstacles et échecs de sprints. Au fil du temps, les équipes changent leur composition pour réduire les dépendances et établir d’autres pratiques pour en prévenir les impacts.

Changer la composition pour créer des équipes pluri-disciplinaires plus autonomes est la solution la plus facile. S’il est nécessaire pour l’équipe implémentant les mécaniques de travailler à plein temps sur l’animation pendant la totalité du sprint, alors le mieux est qu’un animateur la rejoigne.

Dans la plupart des cas, il n’y a pas assez de travail pour justifier l’ajout d’un spécialiste à plein temps dans une équipe. Dans ces situations, les équipes peuvent partager des spécialistes pendant un sprint ou se les échanger entre les sprints. Faire ce type d’échange exige un peu plus de planification et d’anticipation pour éviter des demandes de disponibilité du spécialiste qui se chevauchent. Il y a deux instances où cela est fait : aux réunions de planification de livraison et aux réunions d’anticipations.

Planification de livraison

Pendant la planification de livraison, les équipes identifient les objectifs potentiels de sprint pour les prochains sprints. À partir de ces objectifs, ils identifient les sprints où les spécialistes à temps partiels ou une concentration de disciplines (telle qu’un groupe d’artistes de textures) pourraient être nécessaire. Souvent cela révèlera des besoins conflictuelles entre les équipes.

La meilleur manière de les résoudre est d’élever ou d’abaisser les priorités des stories à la source de ces conflits. Par exemple, si deux équipes exigent le même artiste d’effets spéciaux à temps complet pendant le même sprint, le product owner doit changer la priorité d’une des stories exigeant le travail d’effets spéciaux de manière suffisante pour changer le sprint d’une équipe afin de supprimer ce chevauchement.

Planification à long terme

La planification de livraison n’identifie pas d’objectifs spécifiques pas plus loin que quelques sprints parce que les changements sont plus que probables. En conséquence des réunions régulières d’anticipation sont tenues pendant la livraison pour mettre à jour les objectifs des prochains sprints.

La planification d’anticipation prend une heure ou deux à chaque sprint. Elle peut être combinée avec les réunions de priorisations. Elle identifie les changements de composition d’équipes qui peuvent être nécessaires et tous les conflits potentiels que le product owner et les équipes doivent contourner.

Emprunter un ingénieur son

Notre équipe était en train de travailler sur la mécanique de pilotage. Nous étions capable d’implémenter la majorité des effets sonores simples nous-même. Toutefois, l’objectif du sprint d’ajouter un environnement sonore complexe pour la locomotive approchait. Cela exigeait un moteur de son qui devait être réaliste sur l’ensemble du régime moteur et harmonieux lors des changements de vitesse.

Notre locomotive étant un moyen de transport sous licence, c’était un problème vraiment difficile à résoudre, car les physiques de la locomotive (le nombre de tour par minute [TPM] et la courbe de couple) ne correspondaient pas à ceux de la vraie. Nous avons demandé à l’équipe experte en sons si nous pouvions emprunter l’un de leur ingénieur sons pour le sprint. Nous avons légèrement changé nos objectifs avec le product owner pour trouver un sprint où l’équipe pourrait le libérer. Cela a bien fonctionné pour les deux équipes.

Les problèmes quotidiens nécessitant l’intervention d’un spécialiste d’une autre équipe surviennent généralement sans prévenir. Par exemple, l’un de nos projets avait un développeur de scripts d’interfaces utilisateur capable d’implémenter rapidement des changements d’interfaces utilisateur. Une autre équipe lui demandait de l’aide quasiment tous les jours pendant plus ou moins une heure. À cause de la demande pour l’avoir, son équipe devrait lui permettre d’être présent seulement la moitié de son temps pendant le sprint.

Des demandes comme celle-ci peuvent être gérées pendant les réunions de Scrum de Scrums décrites précédemment. Que le spécialiste puisse aider ou pas une autre équipe pendant un sprint dépend de l’équipe à laquelle appartient le spécialiste.

Scrum ne résout pas le problème des spécialistes qui deviennent des goulots d’étranglements, mais il rend ces problèmes transparents et par conséquent plus facile à résoudre. Dans le cas du développeur de scripts d’interfaces utilisateur, la solution pourrait être d’embaucher plus de personnes qui peuvent scripter ou former les autres pour être capable d’écrire des scripts d’interfaces utilisateur. La solution idéale dépend du projet et des besoins du studio.

Équipes distribuées

Pour réduire les coûts et aider à équilibrer les demandes d’effectifs, les studios répartissent fréquemment le développement des jeux. Avec ce modèle, les équipes distribuées sur deux ou plusieurs sites développent les mécaniques et les fonctionnalités principales du jeu en parallèle. Cela est différent de l’externalisation, qui se concentre principalement sur la répartition de certains types de travail de production, tels que la création d’élément ou le support technique.

Les défis du développement distribué sont principalement ceux de la communication, qui sont les plus à même d’impacter les équipes distribuées.

Cette section examine les défis auxquels font face les équipes distribuées et certains des outils agiles disponibles pour les surmonter.

Défis

Fréquemment, trois défis affectent les équipes distribuées :

Elles manquent d’une vision commune : À cause de leur éloignement physique, il arrive le plus souvent aux équipes distribuées d’être confrontées à une divergence de vision. Cette divergence amène à des travaux incompatibles ou sources de conflits des équipes.

Elles collaborent moins : les équipes physiquement éloignées ne peuvent pas collaborer aussi étroitement que les équipes co-localisées. Si les différences de fuseaux horaires sont suffisamment importants, obtenir une réponse à une seule question peut prendre une journée.

Les bénéfices peuvent être effacés par l’itération et les dépendances : Les baisses de coûts potentiels des équipes distribuées sont facilement perdus quand le temps et les efforts sont gaspillés par les retards de l’itération et les dépendances entre les équipes.

Un équipe de conception que je connaissais avait fait cela … et ils étaient capables de la garder presque constructive !

Outils agiles

Beaucoup des pratiques agiles qui ont évoquées précédemment peuvent aider les équipes agiles à surmonter ces défis. Elles donnent aux équipes l’opportunité de maintenir une vision commune, d’accroître la collaboration, et d’éviter d’aller sur des voies différentes.

Les équipes Scrum se synchronisent par lieu géographique. Généralement chaque équipe distribuée est une équipe Scrum distincte. Il y a des cas où il est avantageux d’avoir des membres d’une équipe Scrum ailleurs pour partager la connaissance et créer des liens entre les différents sites (Cohn 2009), mais de manière générale, il est préférable d’avoir chaque équipe Scrum co-localisée.

Lorsque chaque équipe Scrum est co-localisée, elles peuvent collaborer plus efficacement sur un objectif de sprint commun. De telles équipes ont besoin d’un product owner de proximité mais elles devraient trouver des moyens pour tenir une revue de sprint ou des réunions de planifications avec d’autres équipes et avec le responsable product owner soit en personne soit par visioconférence.

Scrum de Scrums communs. Une réunion de Scrum de Scrums par audio ou une visio conférence est vitale pour les équipes distribuées. Il n’est pas obligatoire qu’elles se déroulent quotidiennement mais elles devraient se tenir au moins une fois par semaine.

Si les équipes sont réparties sur plusieurs fuseaux horaires, l’heure de la réunion ne devrait pas être fixée à un créneau pénalisant systématiquement une équipe plus que les autres. L’heure de la réunion est changée régulièrement afin que les participants des différents sites puissent arriver plus tôt ou rester plus tard.

La planification de livraison en commun. Il est vitale pour une planification de livraison d’être réalisée et partagée au plus haut niveau possible des équipes. Souvent cela se traduira par la venue en avion d’une ou plusieurs personnes de chaque site à un seul endroit où la réunion se tiendra. C’est souvent un coût nécessaire et inévitable dans les équipes distribuées. Soit vous dépensez de l’argent en vols et en hotels, soit vous dépensez encore plus à cause des coûts occasionnés par la divergence des objectifs.

Il existe plusieurs façons d’organiser cela en fonction de la manière dont les équipes sont réparties. L’encadré “Récit du développement global d’un jeu” raconte l’histoire de l’organisation des livraisons d’une entreprise sur trois continents et seize fuseaux horaires.

Améliorer le partage des builds, des éléments, et du code. Un problème avec les gros projets est comment partager le volume important de changements qui se produisent. De fréquents petits changements peuvent perpétuellement casser le build, et de gros changements faits à des semaines d’intervalles peuvent amener les équipes à s’arrêter pendant plusieurs jours en cas de pépins.

Avec les équipes co-localisés, ce problème est déjà assez grave. Avec les équipes distribuées, les défauts réparties sur des builds, des éléments et du code partagés peuvent être désastreux. Lorsque la réponse à une seule question peut prendre une journée, suivre un problème et avoir l’expertise nécessaire pour le solutionner peut prendre des jours au lieu d’heures ou de minutes. Un soin tout particulier doit être pris pour protéger les équipes distribuées des défauts extérieurs. Cela demande de mettre un accent particulier sur l’amélioration des pratiques de commit et de tests décrites au chapitre 9 “Itérations plus rapides”.

Processus et outils. Les méthodes agiles valorisent “les individus et leurs interactions plutôt que les processus et les outils”. Une répartition plus large d’une équipe peut gêner les interactions et mettre un poids plus importants sur les processus et les outils. Les équipes distribuées utilisent souvent plus d’outils pour suivre et afficher l’avancée du sprint, et les backlogs de produit, et partager la connaissance. Les wikis et les autres outils de documentation sont utiles et davantage utilisés avec les équipes co-localisées.

Récit du développement global d’un jeu

CCP Games, le développeur et l’éditeur d’EVE Online, a été fondé en 1997, les développements sont éclatés entre Reykjavik en Islande, Atlanta aux États-Unis et Shanghai en Chine. L’entreprise a grossi à plus de 400 employés et héberge plus de 300 000 abonnées sur un seul monde en ligne.

À l’automne 2008, CCP a entrepris le développement de sa dixième extension dénommée Apocrypha. Apocrypha était l’extension la plus ambitieuse de l’univers d’EVE. Cette extension a ajouté des fonctionnalités techniques majeures et a étendu de manière significative la taille du monde d’EVE. L’objectif de l’entreprise était de livrer l’extension dans les six mois suivants un cycle de développement de quatre mois (cf figure 8.7).

Figure 8.7 : le calendrier Apocrypha

 

Cet objectif ambitieux exigeait que les studios de développement mondiaux de CCP travaillent en parallèle. Développés simultanément sur trois continents, les fonctionnalités et le contenu devaient être rassemblés de manière cohérente pour atteindre l’objectif. Normalement cela devrait être le début du récit d’un désastre, mais CCP a relevé le défi. CCP a adopté de longue date les méthodes agiles et plus particulièrement Scrum.

Dans le cas d’Apocrypha, avec plus de 120 développeurs répartis dans 13 équipes Scrum sur trois continents, 9 product owners étaient nécessaires. Ces products owners prenaient leur directive pour le jeu d’un comité de projet basé en Islande.

Planification de la livraison

Les parties prenantes identifièrent deux cycles de développement pour livrer l’extension en mars 2009. Idéalement, chaque développeur devrait être présent pour la planification de la livraison, mais il était quasiment impossible de rassembler les 120 personnes des quatre coins du globe en un seul endroit, donc CCP devait trouver des pratiques innovantes pour réaliser la planification de la livraison.

Les réunions de planification de livraison d’Apocrypha se déroulèrent en une seule session de 12 heures. Un réseau de visioconférence en haute définition facilita la réunion et permis que chacun puisse y prendre part.

Étant donné que la plus grande partie des membres de l’équipe de développement était à Reykjavik, y compris le groupe de gestion de projet, la réunion se déroula là-bas. Elle débuta à 9 heures. À cause du décalage horaire, il était bien trop tôt pour les développeurs d’Atlanta d’y participer. L’équipe de développement de Shanghai et le groupe de Reykjavik échangèrent en premier car c’était déjà la fin de la journée à Shanghai. Quelques heures plus tard, l’équipe de Shanghai partirait, et l’équipe d’Atlanta se joindrait à la discussion sur la livraison (cf. figure 8.8).

Figure 8.8 : superposition des heures de réunion

 

Vous pouvez voir un extrait vidéo de cette réunion étonnant de Reykjavik sur YouTube.

Il est important de noter que les contraintes de fuseaux horaires et les contraintes de vidéo-conférence ne permettaient qu’à deux équipes de se réunir à la fois. Dans le cas présent, Atlanta et Shanghai ne pourraient pas se réunir ensemble. Pour éviter les problèmes potentiels, deux développeurs de de l’équipe de Shanghai firent le vol jusqu’à Reykjavik pour participer en personne à la réunion et représenter leurs équipes de Shanghai.

Chaque paire de site voudraient discuter des objectifs de livraisons et commencer à les scinder en de plus petits objectifs de taille raisonnable pour les rentrer dans un sprint. Le réseau de conférence permettaient à plusieurs réunions simultanées de se tenir. C’était indispensable, beaucoup de questions survenant durant ce processus exigeaient pas mal de discussions au niveau de l’ensemble du personnel ou de chacune des équipes.

L’objectif de la réunion de planification de livraison était de générer un ensemble d’objectifs potentiels de sprint pour chacune des 13 équipes qui accompliraient la livraison BHAGS (acronyme de Big Hairy Audacious Goal - Vision à très long terme - source : Wikipedia - NdT) Cela ne serait pas la dernière fois que ces équipes communiqueraient. Les problèmes quotidiens étaient communiqués, et un build du jeu était montré en démonstration à chaque sprint d’une durée de deux semaines. Des changements du plan de livraison étaient faits à chaque sprint pour l’ajuster face aux réalités du développement.

Après deux livraisons, Apocrypha était prêt à passer les tests finaux et à passer à la phase de polissage, et le 10 mars 2009, elle fût livrée dans les temps.

Résoudre les problèmes

Une équipe de développement distribuée à travers le monde peut réussir la création d’un produit de grande qualité dans les limites du budget et du temps imparties. Les ingrédients bruts de cette réussite peuvent être résumés en plusieurs points :

Une vision locale et un sens de l’appropriation : Scrum permet aux différentes équipes pluri-disciplinaires de s’approprier leur objectif de sprint et de le réaliser indépendamment les unes des autres. Avoir un product owner sur site qui est responsable de la vision de ce que l’équipe est en train de créer est indispensable.

Une méthodologie de développement itératif : la création d’une version intégrée du jeu, potentiellement livrable toutes les deux semaines à partir du travail réalisé à travers le monde oblige les problèmes à remonter à la surface et à démontrer de réels progrès. Sans cela, les problèmes critiques pourraient restés cachées jusque tard dans la vie du projet, trop tard pour éviter les retards et les sur-coûts.

Une communication à bande-passante élevée : la communication dans de grosses équipes co-localisées est assez difficiles. Dans de grosses équipes distribuées, cela peut être le défi majeure. Les équipes doivent avoir les outils pour communiquer efficacement, tel qu’un système de conférence en réseau, fiable et omniprésent, de même qu’une méthodologie permettant la transparence à l’instar de Scrum.

Toutefois, les équipes distribuées ne seront jamais aussi efficaces que les équipes co-localisées. Ce qui est perdu en communication quotidienne en face à face ne peut être rattrapé à travers des réunions téléphoniques. Mais elles peuvent s’en rapprocher suffisamment pour s’assurer que les équipes soient productives.

Résumé

Il n’existe pas de formule unique pour créer les meilleurs équipes possibles sur un projet de jeu vidéo. Les équipes et les pratiques décrites ici résultent de l’adaptation des rôles existants de Scrum et de l’équipe pour améliorer la manière dont les personnes travaillent ensemble et comment une vision est unifiée et partagée. Explorer les rôles et les structures de l’équipe est un processus continu.

Les équipes doivent utiliser la pratique de la rétrospective pour trouver des axes de progrès sur la manière dont elles travaillent ensemble et collaborent avec les parties prenantes du jeu. En permettant aux équipes de s’approprier et de faire actes d’autorité sur certains aspects de leur vie quotidienne, ils sont plus à même de prendre la responsabilité de leur travail. Cela n’arrive pas en une nuit. Dans un certain nombre de cas, cela prend des années et cela créera des chocs frontaux avec la culture d’entreprise de l’encadrement du studio. Les résultats en valent la peine.

Scrum peut monter en charge sur des projets de toute taille mais il conduit à des changements au niveau de la structure de l’équipe, du rôle du propriétaire du projet, et à de nouvelles pratiques tel que le Scrum de Scrums.

Scrum mène aussi à des changements sur les disciplines, focalisant l’équipe sur les changements sur la manière de travailler quotidiennement pour améliorer la communication et le rythme de l’itération Cela mène aussi à des changements sur la manière dont chaque discipline travaille. Le reste de la partie de ce livre abordera ces changements.

L’objectif est de créer des équipes qui peuvent s’approprier davantage le développement et avoir une plus grande détermination sur ce qu’ils font.

Lecture additionnelle

DeMarco, T., et T. Lister. 1999. Peopleware: Productive Projects and Teams, Second Edition. New York: Dorset House Publishing.

New York: Dorset House Publishing._ 2003. The Wisdom of Teams: Creating the High-Performance Organization. Cambridge, MA: Harvard Business School Press._

Larman, C., and B. Vodde. 2009. Scaling Lean and Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Boston: Addison-Wesley.

Leffingwell, D. 2007. Scaling Software Agility: Best Practices for Large Enterprises. - Boston: Addison-Wesley.

Schwaber, K. 2007. The Enterprise and Scrum. Redmond, WA: Microsoft Press.

Ce chapitre est un extrait du livre “Développement agie de jeu avec Scrum” écrit par Clinton Keith, publié par Pearson/Addison-Wesley Professional, Mai 2010, ISBN 0321618521, Copyright 2010 Clinton Keith; pour consulter la table des matières, consulter ce lien.


Auteur : Clinton Keith
Source : Agile Game Development With Scrum: Teams
Date de parution originale : 26 août 2010


Traducteur : Nicolas Mereaux
Date de traduction : 22/12/2014
Relecteurs : Fabien Bataille, Stéphane Wojewoda


Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.