Ce que j'ai appris sur la gestion de projets en me plantant des dizaines de fois

Ce que j'ai appris sur la gestion de projet en me plantant des dizaines de fois

Avec le recul, je suis un très mauvais maker, au sens où j’ai sorti très peu de jeux, et ce ne sont pas vraiment des grands jeux. J’ai également abandonné des dizaines de projets de jeux à des stades de développement différents. Cependant, ces multiples échecs ont nourri ma curiosité envers la gestion de projet. Et, tout comme les étudiants apprennent l’anatomie en disséquant des cadavres, il est très instructif d’apprendre la gestion de projet à l’aide de projets échoués.

Le but de cet article est de faire en sorte que vous réussissiez à réaliser vos projets de création de jeu vidéo en équipe. Dans cette optique, je présenterai différents cadres théoriques de la gestion de projet, je partagerai mon expérience et celles de différents makers interviewés, et j'essaierai de rendre le tout orienté vers la pratique (création de jeux vidéo en équipe) et pas trop bullshit.

---

 
Qu’est-ce qu’un projet ?

Il y a un projet dès lors qu’il y une ambition de réaliser quelque chose qui n’existe pas.

• Créer un jeu, c’est un projet.
  
• Faire une présentation en groupe pour un cours, c’est un projet.
  
• Monter une startup, c’est un projet.
  
• Se mettre au sport et bien manger pour 2019, c’est un projet.
  
• Pendre le linge à 18h, c’est un projet.
  

Cet article se concentrera sur les projets en équipe. C’est-à-dire, où plusieurs personnes se regroupent pour le réaliser.

La gestion de projet, c’est l’art qui consiste à gérer l’équipe et le contenu du projet lui-même, pour s’assurer de le réaliser complètement en temps et en heure. Gérer un projet, c’est donc faire en sorte que les participants au projet fassent bien le projet jusqu’au bout, dans un délai de temps raisonnable.

• C’est un processus actif. Gérer un projet, ça prend du temps, et c’est prenant.
  
• C’est du management, de la gestion, de l’encadrement. Bien qu’elle ait un impératif de résultat (« il faut réaliser le projet ! »), la gestion de projet n’est pas une activité productive.  
  
• Il y a des mauvaises et des bonnes gestions de projet. On peut évaluer la gestion de projet.
  

Notons qu’il n’y a pas toujours un chef de projet, c’est-à-dire quelqu’un qui s’occupe à temps plein de la gestion du projet. Certes, pour les projets d’industrie lourdes, il y aura toujours un, voire plusieurs chefs de projet. Mais quand on parle d’un multimaker à 5 ou 6, il n’y a pas forcément quelqu’un avec la casquette « chef de projet ».  De même dans une startup, ou quand vous prenez de bonnes résolution (« mon projet pour 2019, c’est de me mettre au sport »). Dans ces cas-là, la nécessité d’une gestion du projet apparaît d’elle-même, indépendamment de la composition de votre équipe. Ce n’est pas parce que tous les membres de l’équipe sont des graphistes, et qu’aucun n’est officiellement nommé « chef de projet », qu’ils n’ont pas besoin de gérer leur projet.

C’est mon premier point. Le besoin de gérer un projet apparaît dès lors qu’il y a un projet. Il n’y a pas qu’une manière de gérer un projet. Contrairement aux idées reçues, gérer un projet ne prend pas forcément la forme d’une hiérarchie pyramidale avec plein de chefs de projets.

Pensez à Wikipédia.

• C’est un projet : construire une encyclopédie libre de droit et collaborative sur internet.
  
• Il y a une gestion de projet : elle prend la forme de discussions entre passionnés autour de portail spécialisés. Les meilleurs contributeurs se voient confiés des rôles administratifs.
  
• Il n’y a pas un grand chef de projet. Jim Walles, le fondateur de Wikipedia, n’est pas le chef de projet suprême, auquel on doit rendre des comptes.
  

Ainsi, quand on mène un projet, on est obligé de le gérer : ce n’est pas qu’une lubie de manager. Mais la gestion de projet peut se faire de plein de façons différentes. Bien qu’il y ait de bonnes façons ( = qui marchent) de gérer un projet, et de mauvaises ( = qui ne marchent pas), il n’y a pas forcément une manière parfaite de gérer un projet qui marche pour tous les projets.  

Comment gérer un projet ?

Depuis le temps qu’on entreprend des projets, on a pu constater qu’il y a bien des gestions qui marchent, et d’autres qui ne marchent pas. Et mieux gérer un projet s’apprend. C’est même le sujet de diplômes de nombreux masters dans le milieu où j’étudie. Je vais essayer d’en faire une présentation expresse.

Fondamentalement, gérer un projet revient à optimiser deux composantes : les actions et le temps.

• Les actions. Réaliser un projet, c’est enchaîner des actions par des humains dans le bon ordre. Par exemple, en créant un jeu, il faut créer des graphismes, programmer les ennemis, concevoir les niveaux… Notez qu’on peut découper chaque action en plein de sous-actions. Créer un les graphismes, c’est créer les graphismes des ennemis, des items, des héros…
  
• Le temps. Chaque action prend un certain temps à être réalisé. Construire un mur ne se fait pas instantanément. De plus, certaines actions doivent être réalisées avant les autres pour les rendre possibles ; par exemple, si on construit une maison, on doit d’abord poser les fondations avant de monter les murs.
  

Un modèle de gestion de projet est une manière théorique de concevoir et d’optimiser ces deux composantes. Ci-dessous, je vais vous présenter les deux grandes familles de modèle, principalement utilisés dans l’industrie car ils marchent.

1- Les grands modèles de la gestion de projet

1-a La gestion de projet en cascade

La gestion de projet en cascade est un modèle hérité de la construction et du BTP. C’est un peu la vision caricaturale qu’on a de la gestion de projet. Il en existe de nombreuses variantes et évolutions (cycle en V…), mais j’essaierai ici de rester simple.  

Par exemple, imaginons qu’on construise une maison.

1. D’abord, de janvier à février, les géomètres étudient le terrain.
   
2. Ensuite, de février à avril, les architectes dessinent les plans.
   
3. Puis, d’avril à août, les ouvriers bâtissent l’édifice.
   
4. Enfin, en septembre, les décorateurs installent les meubles.
   

L’idée est la suivante : des blocs d’actions bien spécifiques sont réalisés entièrement, les uns après les autres. Ils ne se superposent pas dans le temps : on n’installe pas les meubles avant d’avoir dessiné les plans. On ne revient pas en arrière : une fois que les ouvriers ont bâti l’édifice, les géomètres n’ont plus leur mot à dire. Ces blocs d’actions sont en général plus abstraits et spécifiques à une industrie.



Le modèle en cascade est très rassurant car personne n’avance à l’aveugle. À chaque étape, on a une liste d’instructions bien spécifiques et une idée très claire de ce qu’il faut accomplir. Tout ce qu’il faut faire est consigné dans des documents bien écrits. Le modèle en cascade est aussi très intuitif : on le comprend très facilement.

Cependant, à part pour des cas très particuliers, le modèle en cascade est un très mauvais modèle.

• Il a une vision caricaturale des blocs d’actions. Il demande d’anticiper tout ce qu’on va faire dans le projet, très précisément… avant même de commencer ! Le résultat, c’est que c’est très souvent abstrait ou déconnecté de la réalité.
  
• Il ne prend pas en compte le facteur humain. Un projet en cascade serait exécuté parfaitement par des robots.
  
• Il n’optimise pas le travail en parallèle ou en interaction. L’ouvrier ne veut rien entendre de l’architecte.
  
• Il est très vulnérable aux erreurs. Par exemple, si en posant les fondations, on se rend compte que les géomètres ont mal étudié le terrain, alors les géomètres doivent refaire tout leur travail et les architectes aussi.  
  

Dans le jeu-vidéo et le développement logiciel, c’est un modèle qui a été très critiqué et que je ne recommande pas. Si votre planning de projet ressemble à :

1. D’abord, écrire toute l’histoire et les dialogues
   
2. Ensuite, dessiner tous les graphismes
   
3. Puis, faire toutes les maps
   
4. Enfin, intégrer tous les combats
   

Alors vous avez de très forte chances de ne jamais terminer votre projet.

Par exemple, l’organisation du multi-maker G. Rémy Unleashed était : chacun réalise un chapitre, l’un après l’autre, et à la fin on a un jeu complet. Après 7 ans de développement et un jeu toujours pas vraiment terminé, on peut se permettre de remettre en question la pertinence du modèle en cascade pour le jeu vidéo.  

1-b La gestion de projet agile

La gestion de projet en cascade a, entre les années 1970 et 1990, beaucoup muté pour résoudre les défauts mentionnés ci-dessus. Le résultat était une structure où les postes de gestion ont enflé sans pareil : des contrôleurs de la qualité de la direction des contrôles, des chefs des opérations de la gestion de l’encadrement, de gestionnaires de managers et de managers de gestionnaires… Certes, on gérait mieux les projets. Mais la complexité était folle.

En 2001, des développeurs de logiciels se sont dit « fuck it » et ont rédigé le Manifeste pour le développement agile de logiciels. Ils y posaient 12 principes pour rompre avec la gestion de projet en cascade, inadaptée au développement de logiciels.

Le principe de la gestion de projet agile (ou les méthodes agiles) est de prendre le contrepied de la gestion de projet en cascade. Le modèle en cascade visait à tout prévoir à l’avance, et ensuite d’exécuter parfaitement ce qui était prévu. Les méthodes agiles, a contrario, essaient d’avancer à petit pas, sans grand plan prédéfini, mais avec une approche toujours très rationnelle de ce qu’il faut faire à court terme.


C’est la Crise ! un jeu de Alex RE qui s’inspire un peu de la gestion de projet agile

Plus techniquement, la gestion de projet agile se fait par un enchaînement de cycles appelés « sprints ». Un sprint dure une ou deux semaines, puis de plus en plus longtemps avec le temps. Tous les sprints sont organisés de la même façon :

1. On organise un scrum, une réunion de début de sprint.
   
   
   
   • D’abord, on rédige (ou récupère) une liste de « user stories ». Par exemple : « En tant que joueur, quand je rencontre un monstre, je veux pouvoir l’affronter dans un combat ».
     
   • Ensuite, on évalue la difficulté de réalisation de ces user stories. Si elles sont trop compliquées à faire, on les décompose en d’autres user stories.
     
   • Puis, on sélectionne les user stories à réaliser pendant le sprint. Il faut d’abord choisir les plus essentielles, qui donneront le maximum de résultats pour le moins d’effort, et remettre à plus tard les plus accessoires.
     

Enfin, après le scrum, l’équipe réalise sans interruption ces user stories pendant le temps restant du sprint.

À la fin, on fait un compte-rendu du sprint (ce qu’on a réussi, ce qu’on a raté). Et aussi on va boire un coup entre potes pour se féliciter les uns les autres.

Quand le sprint est terminé, on recommence, en regardant quelles user stories on a bien réalisées, pour lesquelles on a eu des soucis, comment résoudre ça, etc.

Regardons comment la méthode agile résout les problèmes du modèle en cascade :

• Il n’y a pas besoin de prévoir tout le projet dès le début : on avance petit à petit.
  
• Il tire profit des humains. Pour rédiger de bonnes user stories, il faut faire preuve d’empathie, d’imagination, et de créativité.
  
• Il maximise le travail en parallèle et les interactions. À chaque sprint, on s’assure que toutes les équipes soient occupées. Et au début de chaque sprint, on les met autour d’une même table pour discuter entre elles.  
  
• Si quelque chose ne se passe pas comme prévu, on le sait dès le prochain sprint, et on peut le corriger bien plus vite.
  

L’élégance de ce modèle est qu’il structure la gestion de projet, sans pour autant trop la structurer. Et c’est un très bon modèle pour l’industrie du développement logiciel. La plupart des startups et des entreprises tech utilisent ou incorporent des méthodes agiles.

Toutefois, il n’est pas utilisable dans tous les contextes :

• Il est très contre-intuitif. Il demande de la formation et de l’accompagnement. En voulant bien faire, certaines personnes qui connaissent mal les méthodes agiles peuvent faire n’importe quoi (généralement mal rédiger les user stories). Il y a également une forte résistance au changement.
  
• Ça ne marche pas pour les grands projets. Les méthodes agiles sont optimisées pour l’échelle micro. À l’échelle macro, il est souvent plus cohérent d’utiliser le modèle en cascade (ou d’autres modèles dérivés).
  
• Pour des petits projets (Ludum Dare, projets en classe, pendre le linge à 18h…), on n’a pas forcément le temps ou la motivation de mettre en place tous les rituels de la gestion de projet agile. On n’a pas toujours la foi de créer un tableau Jira pour un projet perso ou fun.
  

Pour la création de jeu-vidéo amateurs, je recommanderais d’utiliser la méthode agile pour des projets de long terme. Et c’est d’ailleurs, dans l’industrie, ce qui se fait la plupart du temps. Mais je suis à peu près certain qu’à moins de payer vos équipes, vous ne les convaincrez pas d’adopter la méthode agile.

harusame, en 2015 a écrit:

Ah non, on n’utilise pas trello, j’ai l’impression d’être au boulot sinon ^^

1-c Quel modèle pour la création de jeu vidéo amateur en équipe ?

Maintenant, vous, en tant que créateur de jeu-vidéo, vous vous demandez : quel modèle choisir ? À cette question, il n’y a pas de bonne réponse. Pourquoi ?

• Le modèle de gestion de projet a des implications créatives. Il faut choisir la manière d’organiser son projet en fonction du projet que l’on souhaite réaliser.
  
• Les deux modèles présentés précédemment ne sont que des références. Vraisemblablement, le bon modèle pour votre projet est un modèle hybride. Inspirez-vous de ce qui vous plaît de chaque côté pour créer votre propre modèle.
  

Résumons synthétiquement les deux modèles présentés précédemment.

Modèle en cascade	Méthodes agiles
Contrainte	Liberté
Directives	Débat
Prévision	Réaction
Exécution	Exploration
Structure	Adaptabilité
Familiarité	Étrangeté

Je vous conseillerai de garder, au minimum, les aspects suivants :

• Les réunions régulières des méthodes agiles. Voyez vous régulièrement, et ne quittez jamais une réunion sans savoir quand est-ce que vous vous reverrez. Dédiez un moment fixe dans votre emploi pour vous retrouver, faire le point, discuter tous ensemble. Même si ça ne prend que 5 minutes, vous créerez de l’attachement et du lien.
  
• Les instructions très claires du modèle en cascade. Consignez tous les aspects du projet sur lesquels vous avez pris des décisions dans un Game Design document afin de ne jamais vous sentir perdu. N’écrivez pas nécessairement des instructions très précises, mais notez les idées que vous avez pour ne pas les oublier, et pour créer une référence pour votre équipe.
  

Pour conclure, choisissez toujours comment vous organiser en fonction de ce que vous voulez réaliser. En effet, la gestion de projet a, étonnamment, beaucoup d’implications créatives. Le modèle en cascade aura tendance à donner beaucoup de cohérence à un projet, mais aussi à étouffer la créativité individuelle. Les méthodes agiles laisseront une plus grande part à la discussion, mais aboutiront parfois à un ensemble très bancal.

Prenez le temps d’y réfléchir au moment où vous commencer votre projet. Il est plus facile de choisir un modèle et de s’y tenir, que d’en changer en cours de route.

---

 
Comment gérer l’équipe du projet ?

Un projet est réalisé par une équipe. Indépendamment de la manière dont vous gérez le projet (cascade, agile, hybride...),

• Une équipe bien gérée réalise de bons projets.
  
• Une équipe mal gérée réalise de mauvais projets.
  

Le but de cette partie est de vous aider à bien gérer l’équipe du projet car, sans elle, pas de projet.

Dans le cadre de la création de jeux-vidéo amateurs, le projet dont on parle n’est pas un projet professionnel. C’est un side-project, un projet mené à côté, parce qu’il passionne, intéresse ou amuse. D’autre part, c’est un projet en équipe, dont vous êtes le responsable ou l'instigateur.

Vous vous rappelez, j’avais dit qu’on pouvait résumer la gestion de projet à l’optimisation de deux composantes : les actions et le temps. Dans des projets non-professionnels, deux autres composantes s’ajoutent : les compétences exclusives et la motivation.

• La motivation. Dans un projet non professionnel, les membres de l’équipe sont rarement payés. Et ils ont généralement plein d’autres obligations. Leur volonté de consacrer du temps à votre projet vacille facilement et ils peuvent, à tout moment, préférer aller boire des coups avec des potes plutôt que de travailler sur votre projet.
  
• Les compétences exclusives. Dans un projet non professionnel, on choisit rarement son équipe. Ce sont des amis qui se retrouvent pour un projet qui les amusent ou les enthousiasment. Par conséquent, le skillset, les compétences à disposition, correspondent rarement au standard de l’industrie, et il peut manquer des compétences cruciales. Par exemple, pour créer un jeu vidéo, une équipe de trois programmeurs peut se retrouver sans aucun artiste. L’un des programmeurs, le moins mauvais en dessin, devra donc endosser le rôle de l’artiste à un moment où un autre.
  
  

Ces deux composantes, motivation et compétences exclusives, sont les ressources les plus précieuses. Ce sont elles qui décident du sort d’un projet. Combien sont morts car, petit à petit, l’entrain et l’engouement ont disparu et le travail était remis à « plus tard » ? Combien de jeux amateurs sont morts car, suite à une dispute, le seul programmeur de l’équipe a quitté le projet ?

On peut toujours réduire l’ampleur d’un projet (diminuer le nombre d’actions) ou repousser la deadline (augmenter le temps). En revanche, retrouver des membres avec les bonnes compétences exclusives, ou raviver la flamme de la motivation, c’est bien plus dur.

Dans la création de jeux-vidéo amateurs en équipe, la vie et la mort du projet dépendent entièrement du bon-vouloir et de la cohésion de l’équipe. Bien gérer l’équipe, c’est bien gérer le projet.

2- Souder l’équipe

Pour bien gérer une équipe, le premier objectif est de la souder. C’est-à-dire, de créer un sentiment d’appartenance à une groupe, à un corps, à une même entité.

2-a Connaître les membres de son équipe

Parfois, les gens aiment se coller des étiquettes. Je suis graphiste. Je suis programmeur. Je suis musicien. Mais c’est toujours faux : ce sont tous des êtres humains. On ne saurait les réduire à leur pur rôle économique, à leur pure activité productive ; comme des robots. Pour travailler en équipe à l’accomplissement d’un projet, il est essentiel de faire preuve d’empathie avec les humains qui la composent.

Prenez le temps d’apprendre leur prénom et leur origine, d’écouter leur histoire et leur passé. Leurs études, leur lieu de naissance, leur travail… Sur internet, beaucoup préfèrent rester anonyme : dans ce cas, intéressez-vous à leurs passions, leurs précédents projets, leur humour, leurs références, leurs univers préférés, leurs questionnements… Parlez avec eux seul à seul, et encouragez les membres de votre équipe à faire de même.

Laissez-les se présenter comme ils le préfèrent, peut-être parfois en éclipsant certains épisodes. Bien sûr, ultimement, respectez leur vie privée : ne forcez personne à répondre à vos questions. Soyez ouverts, compréhensifs, empathique : pas de jugement ! Contentez-vous d’écouter et de sincèrement vous intéresser à la personne. Préférez une discussion naturelle (vos questions, leurs réponses) plutôt qu’un questionnaire ou un monologue. Profitez-en pour vous présenter également et potentiellement trouver vos points communs. Si vous pouvez le faire en face à face ou par audio, c’est encore plus sympa.

Une équipe dont les membres se connaissent bien, c’est un premier pas vers une équipe qui se fait confiance. Mais aussi qui a des attentes réalistes envers les uns les autres. Il ne faut pas en attendre ni en demander autant d’un lycéen en première L de 16 ans, que d’un ingénieur en aéronautique de 40 ans. Leurs obligations (familiales, professionnelles, scolaires…), leur motivations et leurs compétences ne sont probablement pas toujours comparables.  

De cette façon, naturellement, les plus expérimentés seront davantage tolérants avec les débutants, prendront peut-être plus la peine de les former ou de les aider. Ceux avec le plus de temps libre comprendront plus facilement pourquoi les plus occupés sont indisponibles. C’est autant d’accrochages et de disputes en moins.

2-b Établir une vision commune

Réunissez l’équipe autour d’une même table, et définissez ensemble le projet. Un objectif commun est très important pour souder une équipe.

D’abord, laissez chacun exprimer sa vision du projet : ses valeurs, sa mission, son ambition… Qu’est-ce que ce projet pour eux, mais aussi pourquoi ce projet est important pour eux. Encouragez l’honnêteté et le respect : les gens ont le droit d’être en désaccord les uns avec les autres.

Soyez clair dès le début sur vos ambitions pour ce projet. Si vous voyez ce jeu-vidéo comme l’œuvre de votre vie et le prochain Final Fantasy, dites-le. Si vous le voyez comme une blague entre potes, dites-le. Si vous le voyez comme un hobby pour vous occuper pendant les vacances et potentiellement remplir votre book, dites-le. Il vaut mieux éclaircir les désaccords le plus tôt possible, soit pour les résoudre à la racine, soit pour abandonner rapidement le projet et ne pas s’y consacrer en vain.

Évidemment, l’exercice est d’arriver, ensemble, à trouver une vision commune grâce à des compromis successifs. Prenez du temps pour la formuler élégamment. Cette vision guidera toutes les autres décisions dans le projet. Écrivez-la et mettez-la à disposition quelque part de très visible. Relisez-la fréquemment et, au fur et à mesure que le projet avance, précisez-la. Rappelez-la avant chaque réunion d’équipe, avant chaque réunion importante. Si vous avez un Game Design document, mettez-la à la première page.

Les meilleures visions du projet sont celles qui inspirent toute l’équipe, qui a envie de les compléter, qui perçoit ses articulations, qui veut les développer. Les mauvaises visions sont ternes, ennuyeuses, déjà vues. Une bonne vision n’est pas forcément compliquée. Une mauvaise vision n’est pas forcément simpliste. Une bonne vision est facilement compréhensible par votre équipe, indépendamment de sa spécialité ou de sa culture. Une mauvaise vision est technique, jargonneuse, obscure.  


Exemple de la formulation d’une vision par Mortis Ghost, dans sa version longue

Vous n’avez pas de vision pour votre projet ? Peut-être il faudrait en avoir une. Et si vous vous rendez compte que votre vision est nulle ? Il n’est jamais trop tôt pour abandonner.

2-c Passer des bons moments ensemble

Pour souder une équipe, finalement, rien ne vaut les fameux team buildings. Boire de l’alcool, manger, ou voyager ensemble sont des moyens quasi-magiques de catalyser l’esprit d’équipe.

Mais quand on crée une équipe par internet, c’est plus compliqué. On n’a pas forcément envie de révéler son identité, on habite parfois loin les uns des autres, on n’a pas toujours l’argent pour, on peut être mal à l’aise socialement, on peut tous avoir des âges différents… Il donc d’autant plus dur d’être sûr que tous les membres s’entendent bien entre eux.

Une solution très simple est de jouer aux jeux-vidéos ensemble, idéalement à des jeux en équipe comme LoL, Fortnite, Team Fortress 2, WoW, Minecraft, Terraria, etc. Terrasser en groupe un boss ou gagner une partie, surmonter des épreuves et des défaites, sera tout aussi efficace que de faire un lazergame en Espagne pendant un séminaire ; ou que sais-je encore.

C’est également un bon moment pour déceler les comportements des uns et des autres. De voir comment ils agissent en vrai, au-delà de comment ils se présentent. Sont-ils têtes brûlées, leaders, soutiens, analytiques, craintifs ? Comment communiquent-ils entre eux : sont-ils bavards, discrets, précis, flous ? Faites preuve d’empathie pour comprendre les humains avec qui vous allez travailler.

C’est aussi l’occasion de rapidement révéler des amitiés ou des inimitiés, des similitudes ou des complémentarités entre les membres de l’équipe. Si deux membres s’entendent déjà bien entre eux, il serait malin de les faire réfléchir et travailler ensemble. En effet, si deux personnes se focalisent sur une même tâche, alors ils travaillent, non seulement mieux, mais avancent aussi plus rapidement qu’une seule personne. Toutefois, trois personnes et plus en simultanée sur une même tâche, vont en général bien plus lentement qu’une personne seule, même s’ils travaillent mieux.

L’alchimie des duos est la plus impressionnante et est à exploiter. Pensez au duo Lennon/McCartney !

3- Le "chef de projet"

Votre équipe est réunie. Votre équipe est soudée. Maintenant, qui est le chef de projet ?

Plus généralement : qui est le leader ?

3-a Le leader met de l’ordre, mais n’est pas le seul à le faire

Un projet dans l’anarchie totale est voué à mourir. Il est donc nécessaire qu’une personne prenne la casquette du chef de projet, même si ce n’est pas officiellement, pour pouvoir mettre de l’ordre. Plus précisément, il doit prendre la casquette du leader, du meneur. C’est le terme que j’utiliserai dans la suite.

• Le leader est l’empêcheur de tourner en rond : il décide fermement et finalement. Il fixe les deadlines.
  
• Le leader conserve la vision du projet.
  
• Le leader est toujours confiant et optimiste. Il rassure les angoissés. Il sait où on va.
  
• Le leader est dans l’empathie. Il aide à résoudre les problèmes.
  
• Le leader crée du lien entre les membres de l’équipe. Tout le monde aime le leader.
  

Toutefois, un projet où une seule personne dirige tout seul, et joue au petit chef, est aussi voué à mourir.

• Les décisions arbitraires frustrent. Donner trop de pouvoirs à une seule personne le rend souvent fou.
  
• La vision du projet doit être partagée par tous les membres pour que l’équipe reste soudée. Sinon, les conflits, les mutineries et les cabales se multiplient.
  
• L’optimisme et la confiance du leader peuvent l’empêcher de voir la réalité : par exemple, un projet qui fonce droit dans le mur. Attention à l’effet tunnel.
  
• Si le moindre problème est renvoyé au leader, les membres ne sont plus autonomes. Ils se reposent entièrement sur le leader pour résoudre leurs problèmes. Le leader est débordé et ne peut plus travailler.
  
• Si le leader bien-aimé craque et quitte le projet, alors les autres membres, qui se retrouvent tout seuls, ne savent plus quoi faire sans lui et le projet meurt. La survie du projet ne dépend plus que du leader.
  

Ainsi, s’il est important qu’une personne prenne les commandes et guide l’équipe, il est tout aussi important que celle-ci sache déléguer et responsabiliser les membres de son équipe. Idéalement, chaque membre est le leader de son propre travail. Un bon leader réussit à créer cette situation où chaque personne a l’impression de n’obéir à personne d’autre qu’à elle-même.

Je recommanderais de se méfier de la solution de facilité, qui consiste à faire reposer tout le projet sur une seule personne (souvent, l’initiateur du projet). J’éviterais les étiquettes de type « chef de projet » ou « organisateur », et je préfèrerais celle « d’assistant », « facilitateur», ou, encore mieux : aucune étiquette du tout.

3-b Que faire en cas de crise ?

Dans un projet, il arrivera toujours un moment de crise, où la survie du projet est en jeu. Dans ces cas-là, on attend souvent une réponse du chef de projet : que faire ? Examinons les scénarios les plus fréquents.

Situation 1 : Quelqu’un ne respecte pas la deadline, disparaît, et bloque le reste du projet.

C’est la crise la plus commune. Par exemple, dans un multimaker, une personne a pris la main et ne donne plus de signe de vie. Ou bien, un des membres de l’équipe responsable d’une partie du projet disparaît soudainement.

Dans ces cas-là, les avis sont clairs : abandonnez la partie du projet tenue en otage. Faites sans.

emz0 a écrit:

Le gars a pris le jeu et n'a plus donné de nouvelles. Donc on a fait sans et il est crédité dans le générique pour une "partie inexestistante".

À partir de quand pouvez-vous prendre une décision aussi radicale ? Dès lors que le délai n’est plus respecté. En effet, si vous connaissez bien les membres de votre équipe, alors vous vous êtes entendus sur des deadlines réalistes. Le non-respect de celles-ci est disqualifiant.

Toutefois, c’est un problème qu’il vaut mieux régler en amont :

• Au lieu d’imposer une deadline, demandez à la personne de combien de temps elle a besoin, et laissez la se fixer la deadline elle-même. Nous sommes plus susceptibles de respecter nos propres engagements que ceux qui nous sont imposés.
  
• Entendez-vous sur des deadlines plus courtes que nécessaire. Imaginons : vous avez besoin que le membre termine son travail pour dans 15 jours. Ne le dites surtout pas à la personne ; exigez-lui un rendu pour dans 7 jours. Si elle prend du retard et ne le rend qu’après 10 jours, elle sera en réalité en avance sur le vrai planning. C’est un mécanisme à utiliser avec parcimonie : il est machiavélique, usant mentalement, et (sur le long terme) incite à ne pas respecter les deadlines.  
  
• Prenez régulièrement des nouvelles de l’avancement, essayez de l’aider dans sa progression, etc.
  
• Ne confiez pas des tâches trop importantes à une seule personne : faites travailler les gens en binômes pour que chacun motive l’autre à continuer.
  
• Au lieu de donner une seule deadline pour une grosse tâche, découpez les tâches importantes en plein de petites tâches et donnez une deadline à chacune d’elle.
  
• Ne confiez pas des tâches cruciales à une personne peu impliquée ; préférez les attribuer aux plus motivés.
  

Situation 2 : Deux moitiés de l’équipe sont en désaccord sur un aspect du projet.

Par exemple, une moitié de l’équipe veut que le personnage principal soit naïf, l’autre qu’il soit cynique. Certains veulent une fin tragique, d’autre un happy end. Certains veulent un FPS, d’autres un RPG. Certains veulent que le héros soit roux, d’autres qu’il soit brun.

Avant d’enclencher toute prise de décision et de trancher entre les deux camps, posez ces questions :

• Est-ce que c’est vraiment important ? Les makers ont tendance à faire des fixettes sur des détails. Prenez du recul. Si c’est un détail qui pourra être changé par la suite, dites que vous déciderez plus tard et choisissez l’option la moins contraignante.
  
• Est-ce que c’est vraiment contradictoire ? Deux idées sont parfois moins en désaccord qu’on ne le croit. Il est parfois possible d’inclure les deux côtés de l’idée dans le jeu, puis de laisser le joueur choisir lequel explorer. On peut aussi trouver un compromis ou un entre-deux. Avant de trancher, étudiez la liste des options alternatives.
  
• Quel est le vrai problème ? Étudiez la racine du problème. Pourquoi un tel conflit éclot ?
  
  
  
  • Est-ce un désaccord entre deux visions différentes du projet ? Prenez un moment pour mieux la définir.
    
  • Est-ce un problème entre deux membres qui ne s’entendent pas ? Par exemple, un membre qui n’en aime pas un autre refuse toutes ses idées. Isolez les personnes concernées et prenez un moment pour les réconcilier.
    
  • Ce conflit n’est-il pas la conséquence d’un autre aspect du projet mal réfléchi ou mal défini ? Par exemple, si vous vous demandez s’il vaut mieux tuer un personnage ou le laisser survivre à une catastrophe, demandez-vous : est-ce que ça valait la peine d’introduire ce personnage précédemment ? Parfois, résoudre un problème consiste à supprimer la source du problème.
    
  
  
  

Finalement, si après toutes ces étapes, le conflit subsiste, vous pouvez trancher le débat : donner raison à une des parties et tort à une autre. Attention, cette étape doit arriver à la fin, après avoir exploré toutes les autres options possibles ! Deux méthodes de prise de décision classiques :  

• Le vote démocratique. La majorité des membres de l’équipe décide.
  
• La décision arbitraire. Le chef de projet (parfois : le plus compétent ou le plus concerné) décide tout seul.
  

Le tout est, in fine, de prendre une décision affirmée. Quand une décision est prise, il faut clore le débat et entériner la décision : on ne reviendra pas dessus. Il faut être très clair sur la décision prise : « voilà ce qui a été choisi, maintenons on avance ».

Des décisions définitives, qui orientent le projet, valent mieux que des décisions molles. La contrainte génère la créativité. Toutefois, essayez d’éviter d’avoir à recourir à des décisions démocratiques ou arbitraires : dans les deux cas, il y a des déçus qui perdent de la motivation. Il vaut mieux construire ensemble une décision consensuelle.

Situation 3 : Avec du recul, le projet tel qu’on l’a réalisé est vraiment nul.

Il est très démotivant de réaliser soudainement qu’après plusieurs mois de développement, le projet est nul. Il est mauvais. Pas amusant. Ennuyeux. L’idée de base était bancale. La réalisation est peu soignée, etc. Le moral de l’équipe est au plus bas, et la tentation d’abandonner le projet est forte. Mais il faut y résister.

• D’abord, faites un constat objectif de la situation. Qu’est-ce qui ne va pas ? Quels sont les défauts ? Ne cherchez pas encore de raisons ni de solutions : contentez-vous de faire l’inventaire de ce qui n’est pas bien. Il faut vraiment rester superficiel dans cette partie. Le but est que toute l’équipe se mette d’accord sur ce qui ne va pas, avant de chercher des causes ou des solutions. Si vous sautez cette étape, les membres pourront trouver des raisons ou des solutions contradictoires.
  
• Ensuite, comprenez les raisons. Si ceci ne va pas, pourquoi ? Plusieurs symptômes ne sont-ils pas liés à un même mal plus profond ? Quelles sont les raisons nodales, les dynamiques globales ? L’idée est de trouver des problèmes généraux, de prendre du recul et de s’éloigner des détails.
  
• Finalement, réfléchissez à des solutions. Il est important que ça arrive en dernier lieu, après que tous aient accordés leur violon. Triez les problèmes : lesquels allez-vous résoudre car les plus importants ? Lesquels allez-vous ignorer car les moins décisifs ? Quelles solutions auront le plus d’impact ?
  

4- Maximiser l’implication

Dans la partie précédente, je vous ai expliqué comment gérer un conflit dans votre équipe. Mais il y a une autre situation qui, paradoxalement, est bien pire que le conflit : l’indifférence.

Quand il y a un conflit entre les membres d’une équipe, c’est le signe que, certes, ils ne s’entendent pas ; mais que tout de même, le projet est important pour eux. Ils tiennent au projet, ils veulent le faire aboutir. Mais quand règne l’indifférence, c’est le signe que plus personne ne tient au projet, et c’est donc le signe d’un projet mort. Si vous êtes le responsable d’un projet ou son instigateur, votre enjeu, tout le long de la vie du projet, est que les gens y soient impliqués, y accorde de l’importance, y tiennent.

Rappelez-vous : il s’agit d’un projet non professionnel, pour lesquels ses membres ne sont pas payés. Ce n’est pas comme un travail, où l’employé raisonne en ces termes : « si j’abandonne ce projet, je suis renvoyé de mon travail, je n’ai plus d’argent, je ne peux pas payer ma nourriture et mon loyer, et je meurs. » Ici, le raisonnement est plus généralement l’inverse : « si j’abandonne ce projet, j’ai bien plus de temps libre pour mes autres hobbys, pour mon travail ou mes études, et j’y gagnerai beaucoup plus. »

Dès lors, comment maximiser l’implication des membres de l’équipe dans un projet ?

4-a Choisir les bonnes personnes

Conseil évident. Si vous voulez maximiser l'implication des membres de votre équipe, commencez par choisir des membres qui pourront s'impliquer.

D'une part, parce qu'ils trouveront dans votre projet des choses à faire, des endroits où s'impliquer. N'engagez pas un artiste 3D si vous comptez faire un jeu d'aventure textuel.

D'autre part, parce qu'ils ont déjà réussi à s'impliquer dans des projets. Si une personne est connue comme étant tout le temps absente, qu'elle se présente comme "jamais à l'heure" et qu'en plus vous apprenez qu'elle sera très occupée les six prochains mois... Ça vaut peut-être le coup de la laisser en dehors de votre équipe. Pour vous comme pour elle.

N'ayez pas peur de faire appel à des gens qui ne sont pas makers. Les communautés RPG maker ne sont pas très grandes et il peut être tentant de rester entre-soi. Cependant, il y a des talents bien plus grands ailleurs, en dehors du monde du jeu vidéo même, qui pourront beaucoup plus vous aider dans votre projet que n'importe quel vieux maker.

4-b Déléguer en responsabilisant

Si vous réalisez un projet en équipe, vous ne réalisez pas un projet tout seul. Donc, il vous faut déléguer un certain nombre « d’actions » (au sens : d’actions à entreprendre pour terminer le projet, des tâches). Toutefois, déléguer ne signifie pas laisser-faire, abandonner sans instruction un travail à quelqu’un. Mais déléguer ne signifie pas non plus surveiller minutieusement, scruter quelqu’un, et lui dicter mot à mot son travail.

C’est une des tensions fondamentales du management en général que j’aimerais introduire : le juste équilibre entre contrôle et laisser-aller.

• Trop de laisser-aller, et tout s’écroule. Les deadlines ne sont pas respectées. Les membres oublient le projet et sa vision. Ils prennent des libertés sans rapport, s’orientent dans de mauvaises directions. Ou bien, sont perdus, ne font plus rien, ne savent pas quoi faire. Rien n’avance.
  
• Trop de contrôle, et tous s’étouffent. Les gens sont micro-managés et le détestent. Le manager perd son temps à résoudre des détails. Il n’y a pas de confiance. L’équipe est infantilisée et ne développe pas ses compétences. La créativité de l’équipe est ruinée.
  

Par conséquent, un bon manager manie avec intelligence contrôle et laisser-aller, notamment quand il s’agit de déléguer des tâches.

Déléguer, c’est-à-dire confier une tâche (une série d’actions dans une fenêtre de temps donnée) à une personne, doit toujours se faire en la responsabilisant pour cette tâche. Si le membre ne se sent pas personnellement responsable de la bonne exécution de cette tâche, il ne l’exécutera pas ou l’exécutera mal. Il convient donc de responsabiliser les personnes auxquelles on délègue des tâches.

Comment responsabiliser ? Examinons les outils à la disposition du manager.

Laisser-aller	Contrôle
Encourager l’initiative	Établir une liste d’objectifs tangibles
Faire confiance au travail en autonomie	Se réunir à intervalles réguliers, fixer des deadlines
Faire parler l’autocritique	Donner des conseils et recommandations
Valoriser la recherche	Exiger des résultats
Laisser chercher	Donner la solution
Féliciter les réalisations	Punir les manquements

Pour simplifier, il faut savoir user sagement de la carotte et du bâton. Quelles méthodes sont les plus efficaces dépend entièrement de l’autorité dont dispose le manager sur son équipe, et in fine de la composition de l’équipe elle-même.
 
Toutefois, attention à ne pas caricaturer ces conseils. Féliciter ne signifie pas glorifier, et punir ne signifie pas châtier. De plus, globalement, il vaut mieux rester positif et ne pas trop punir. Aujourd’hui, le contrôle a mauvaise presse et on décourage bien plus facilement qu’on n’arrive à encourager. Il serait de mauvais ton de frustrer définitivement un membre de son équipe à cause d’une mauvaise remarque.

4-c Faire de votre équipe les héros d’une histoire

Dans le jeu vidéo amateur, vous ne pouvez pas offrir à votre équipe des richesses. Mais vous pouvez leur faire vivre une aventure fantastique. Une épopée incroyable au bout de laquelle ils auront accompli quelque chose dont ils seront fiers.

emz0 a écrit:

En fait, je crois que ce qu'ont en commun la plupart des makers - je suis peut-être naïf - ce n'est pas tant la quête d'une gloire éphémère que le besoin d'exprimer quelque chose. Et beaucoup se trouvent dépassés par un projet qu'ils sont incapables d'achever. Les projets communs pallient à ça car tu peux compter sur le reste de l'équipe pour prendre le relais.

Dès le début du projet, donnez un nom et un symbole à votre équipe. Chargez ce nom de toute la force possible et de toute la grandeur imaginable. Rendez les membres fiers de faire partie de votre équipe, et dites toujours "nous" avant "je".

L'implication et l'attachement à un projet ne sont pas rationnels. Pour les créer, il vous faut donc faire appel à des choses non rationnelles : des histoires, des rêves, des ambitions, des défis...

4-d Soyez subtils

Ultime conseil. Pour maximiser l'implication, quelques ruses de manipulation peuvent vous servir. Notamment, faites émaner les ordres de la part des membres de votre équipe eux-même, plutôt que les leur imposer. C'est-à-dire, au lieu de dire "demain, je veux que ce soit fini", suggérez-le.

Citation :

"À ton avis, ce sera fini pour quelle date ?
- Hm, je ne sais pas, tu en as besoin pour quand ?
- J'en aurais besoin demain.
- Très bien, je l'aurai fini pour demain alors."

À court terme, ce genre d'astuces vous permettront d'obtenir des faveurs expresses de la part de personnes peu impliquées. Cependant, à long terme, ce dialogue se résumera plutôt à :

Citation :

"À ton avis, ce sera fini pour quelle date ?"
Message vu hier à 20h23

Donc n'abusez pas de la manipulation. Elle ne remplacera pas tous les points décrits précédemment.

Conclusion
« AristA, tu écris beaucoup, mais, finalement, qu’est-ce que je dois retenir ? »

Quand je disais que je me suis planté des dizaines de fois, je ne rigolais pas. Chaque conseil de cet article fait écho à une fois où je ne l’ai pas appliqué. Et où les choses se sont mal passées ensuite. Je pourrais parler très longuement de gestion de projet car j’en ai mal géré beaucoup.

Concluons. Imaginons, demain, vous montiez un projet avec quelques amis. Que faire ?

1. Apprenez à connaître votre équipe : Je suis Jacques, ingénieur informaticien, fan de Naruto et j’ai peur des brocolis.
   
2. Définissez une vision commune et des objectifs à terme : En 4 mois, nous allons créer le meilleur jeu de morpion multijoueur mode Battle Royale de tout l’écosystème Unix !
   
3. Donnez un nom à votre équipe et un symbole : Nous sommes les Pires Pirates Pépères, et notre symbole est une tête de mort avec un casque sur les oreilles. Nous allons changer le monde.
   
4. Définissez une fréquence de réunion : Tous les mardi après-midi, rendez-vous chez Jacques pour un goûter et un bilan de l’avancement du projet.
   
   
5. Consignez votre vision et toutes les décisions importantes dans le Game Design document :  Le mode Battle Royale du jeu de morpion se jouera UNIQUEMENT avec des croix et des ronds.
   
6. Décidez d’une manière de vous organiser en vous inspirant du modèle en cascade et des méthodes agiles : Nous commencerons par concevoir le moteur graphique en un mois, puis nous implémenterons progressivement l’intelligence artificielle pendant 2 mois…
   

Bref. Ces conseils restent généraux. Je n'ai pas abordé de questions très techniques (par exemple, comment utiliser git, trello, drive...) car je ne pense pas être le plus compétent dans ce domaine et de nombreuses ressources existent sur ce sujet.

En revanche, je n'avais jamais lu d'article dans la communauté sur cet aspect là. Pourtant, vu le nombre de projets abandonnés, je crois que c'est un sujet important à examiner et décortiquer. J'espère que ça vous a plu et je suis à l'écoute de vos observations

Merci monsieur AristA pour cet article très intéressant.

Bon, c'est un peu long, et il y a quelques poncifs, je me dis que le message serait plus percutant si c'était plus court et concentré sur les éléments les moins connus du grand public.

Mais c'est cool d'avoir des articles de fond sur E-m.

Au fait, on peut faire des projets agiles à l'échelle, Spotify est souvent une référence sur leur organisation en squads. Il y a aussi le framework SAFe utilisé en entreprise pour mettre en accord plusieurs projets agiles. (Bon, c'est un peu appliquer de gros process lourds aux méthodologies agiles qui se veulent légères et simples... mais apparemment ça marche.)

J'ai l'impression que les méthodologies agiles sont très peu utilisées dans l'industrie du jeu vidéo (et que, de manière générale, c'est une industrie en retard sur la gestion de projets, sur les tests automatisés, etc...). Mais je me base sur peu de choses, j'aimerais lire des articles et avoir des retours d'expériences des boîtes de développement (pas forcément très grosses) qui auraient fait le changement de méthodologie de projets.

Et puis il y a de gros clichés sur les projets en cycle en V ou les projets agiles. Je pense que chaque méthodologie convient à son contexte et son équipe. Il vaut mieux un cycle en V ou en cascade qui est bien mené qu'une fausse méthodologie agile qui peine tout le monde.

Un des éléments du manifeste agile qui résume bien pour moi cette méthodologie (et qui est assez conforme à mes valeurs) : "On favorise les humains et leurs interactions plutôt que les process et les outils".



Sinon, j'aimerais savoir de quels projets tu parles à chaque partie de ton argumentaire.

Concernant G.Rémy Unleashed, je ne dirais pas que le jeu a souffert de son côté "cascade". Effectivement, attendre qu'une personne ait fini sa partie pour faire la partie suivante c'est un processus bloquant qui empêche d'être efficace, et empêche les autres personnes de l'équipe de travailler. Je crois qu'il y a eu pas mal de retard pour la partie 6 par exemple... Mais c'était quelques semaines de retard, ça n'explique pas les 7 ans !

En outre, il y avait tout de même parallélisation du travail, notamment pour les parties de Garywiss (1, 7, 9) qui ont été toutes grandement améliorées/modifiées/développées après leur date de rendu officielle. Si c'était une bonne chose en termes de parallélisation du travail, c'en est une moins bonne pour s'assurer de la cohérence de l'ensemble.

Pour moi, le problème de ce projet était plutôt le manque de chef de projet (mettre des jalons aux parties, couper les passages inutiles, mettre en cohérence des éléments...) et le manque de deadline (s'inscrire aux Alex d'or a permis de nous motiver ces dernières semaines). En outre du fait que l'équipe s'est dissoute et que le projet ne nous permet pas de gagner notre vie donc qu'il est passé au troisième plan... derrière d'autres projets qu'on a commencés et toujours pas finis d'ailleurs.    



Il y aurait encore beaucoup à dire, mais je dois me laver et gagner ma croûte dsl.

J'avoue, c'est un peu trop long. Je pense que c'est une stratégie inconsciente pour me prémunir contre la critique : n'étant pas très confiant en moi sur le sujet, j'en dis beaucoup par crainte d'omettre.

Peut-être dans quelques temps, après avoir maturé et expérimenté les concepts présentés, je pourrais en faire une synthèse ! Ou bien, rédiger deux petites histoires, l'une d'un projet à la gestion catastrophique, l'autre d'un projet bien géré.

Je suis content que le sujet t'intéresse ! Je ne connaissais pas les modèles SAFe et de Spotify, ça a l'air stylé. Je ne sais pas non plus vraiment comment s'organise les projets du milieu du jeu vidéo. En revanche, je sais que beaucoup de gens sont dans la même position que toi et moi et ne savent pas comment s'organisent les projets dans les entreprises. D'où l'intérêt de présenter quelques méthodes, pour la culture, quoi.

Je pense aussi qu'une sorte de notice méthodologique, plus technique (installation de git, slack, trello, drive, etc.) pourrait être intéressante. Mais, d'expérience, c'est dur de convaincre les gens d'utiliser des outils qu'ils connaissent pas. Il est plus efficace d'utiliser des outils qu'ils connaissent pour ne pas trop les effrayer. En plus, la technologie évolue rapidement : difficile de prescrire un programme qui, dans 6 mois, sera obsolète.


Citer les projets auxquels je me réfère... Hm... J'aurais peur de me faire des ennemis, mdr.



Par rapport à G.Rémy. Sans vouloir le rentrer dans une case (la gestion de ce projet étant pour le moins éthérée ), pour moi ça ressemble plutôt à de la gestion en V. D'abord, tout le monde fait ses parties, les uns à la suite des autres, en s'appuyant sur le travail du précédent (la première branche du V). Ensuite, il y a un long travail d'homogénéisation, de contrôle, de correction de toutes ces parties précédentes (la seconde branche du V). C'est la seconde branche du V qui a pris le plus de temps. Le projet s'est créé très linéairement, et le chemin pour achever le jeu était, aussi, très linéaire.

Le projet ne s'est pas construit par une sorte de mosaïque collective, commençant par une esquisse de l'arc narratif principal, amélioré ensuite par les contributions individuelles au projet. Il n'y avait pas non plus de rituels propres aux méthodes agiles. Voilà pourquoi j'ai préféré le rapprocher de la gestion en cascade. Par exemple, une fois qu'Ephy a soumis sa partie, il a disparu. Comme un architecte disparaîtrait une fois les plans remis.

Par rapport à la parallélisation, j'ai peut-être simplifié : elle n'est pas exclusive aux méthodes agiles. C'était caricatural de ma part de l'opposer à la gestion en cascade. Prenons un exemple. Imagine une marque de vêtement. Chaque nouvelle ligne de vêtement est un projet. On peut gérer ces projets en cascade : recherche de tendances par des créatifs, dessins et maquettes de vêtements, fabrication, publicité, et commercialisation. Il serait ridicule de dire que les 300 000 pièces de la ligne de vêtements (par exemple) doivent tous avoir été fabriqués avant de commencer leur publicité. Ou bien, que les dessinateurs ne font RIEN avant d'avoir eu le résultat des recherches des créatifs, ou que les créatifs n'ont plus aucune influence sur les dessinateurs quand ils ont fini leur recherche. Ou encore, que d'abord il faille produire les 40 000 tee shirts avant de commencer à produire les 15 000 pantalons.

Ainsi, il y a très souvent de la parallélisation, à différentes étapes, même dans un projet en cascade. La parallélisation n'est pas caractéristique des méthodes agiles. Elle peut apparaître un peu partout dans les processus de travail. Toutefois, elle est souvent accidentelle ou mal optimisée. D'où le fait que paralléliser le travail en le confiant à Gary, ici, n'a pas super bien marché.

Mais par exemple, de la bonne parallélisation, c'est ce que tu as fait en mettant les fichiers sur github. Gary, toi et moi avons facilement pu commit nos edits, etc. Donc ça c'est smart. Ça c'est agile. Oui.

Concernant les autres tarres (chef de projet, deadline, équipe dissoute) du projet G.Rémy, les parties 2-, 3-, 4- de l'article leurs sont dédicacées

Mais ouais, G. Rémy c'est un cas d'école mdr Dans le même genre (projets avec beaucoup de retard), lire l'histoire de Duke Nukem ou Star Citizen

AristA a écrit:

En revanche, je sais que beaucoup de gens sont dans la même position que toi et moi et ne savent pas comment s'organisent les projets dans les entreprises.

Euh, j'ai quand même vu quelques projets informatiques dans des entreprises différentes. Mais pas de projets de développement de jeu, c'est vrai.

AristA a écrit:

Je pense aussi qu'une sorte de notice méthodologique, plus technique (installation de git, slack, trello, drive, etc.) pourrait être intéressante. Mais, d'expérience, c'est dur de convaincre les gens d'utiliser des outils qu'ils connaissent pas. Il est plus efficace d'utiliser des outils qu'ils connaissent pour ne pas trop les effrayer.

Grave, ça fait longtemps que j'aimerais me prendre du temps pour faire un tutoriel sur Git, sur les tests automatisés, etc. qui améliorent la vie des développeurs. (J'aimerais aller plus loin dans les scripts Ruby pour RPG Maker XP. J'avais essayé de faire des tests automatisés pour un script pour le jeu Polaris)

Mais pourquoi pas sur Trello, Slack et autres truc pour les aspects plus gestion de projet.

AristA a écrit:

Ensuite, il y a un long travail d'homogénéisation, de contrôle, de correction de toutes ces parties précédentes (la seconde branche du V). C'est la seconde branche du V qui a pris le plus de temps. Le projet s'est créé très linéairement, et le chemin pour achever le jeu était, aussi, très linéaire.

Je sais pas... ce qui me dérange avec cela c'est que la deuxième partie n'a pas été faite dans une même période de temps. Vu qu'il n'y avait plus de chef de projet (Daragonis), et pas d'équipe (tu l'évoques pour Ephy, mais c'est pas le seul), le projet a été oublié. Ce n'est pas la même chose que si la phase de correction avait duré 1 ou 2 ans, à raison de quelques heures de travail par semaine, et que le nombre de corrections était la raison de cette durée.

Ce que je veux dire c'est que pour moi les sujets "chef de projet, deadline, équipe dissoute" ont été des causes bien plus importantes (disons 90%) que le nombre de corrections à apporter. La longue phase de correction est une conséquence des points précédents.

Le nombre de corrections est aussi une conséquence du manque d'alignement des participants au projet. Ils ont tous leur manière de maker et c'est ce qui fait l'intérêt et l'amusement du jeu (le principe du cadavre exquis). Cependant, cela se fait au détriment d'une cohérence globale et parfois du plaisir du joueur. C'est là où peuvent aider, en amont, l'établissement de règles d'équipe ainsi que la supervision du chef de projet (validation régulière et demandes de correction au maker).

C'était le topic de règles du multimaker Les Contes de Pandora (je n'ai pas trouvé le topic en question) qui m'avait impressionné à l'époque par son exhaustivité, ce qui permettait d'avoir un ensemble cohérent (type de graphismes, nombre de morts et nouveaux personnages acceptés par partie, etc...). Cela peut sembler par contre contraignant pour les participants.

AristA a écrit:

Par exemple, une fois qu'Ephy a soumis sa partie, il a disparu. Comme un architecte disparaîtrait une fois les plans remis.

Je suis content que l'architecte qui s'occupe de mon appart' n'ait pas raisonné comme ça.



Je serais quand même curieux de ton avis sur ce qui aurait pu améliorer la gestion des 3 projets Jeu pour Relm, Projet 2016 et Bismillahdventure. (si on peut vraiment parler de projet pour ce dernier, qui est davantage un trip entre deux potes).

AlexRE a écrit:

Ce que je veux dire c'est que pour moi les sujets "chef de projet, deadline, équipe dissoute" ont été des causes bien plus importantes (disons 90%) que le nombre de corrections à apporter. La longue phase de correction est une conséquence des points précédents.

Le nombre de corrections est aussi une conséquence du manque d'alignement des participants au projet. Ils ont tous leur manière de maker et c'est ce qui fait l'intérêt et l'amusement du jeu (le principe du cadavre exquis). Cependant, cela se fait au détriment d'une cohérence globale et parfois du plaisir du joueur. C'est là où peuvent aider, en amont, l'établissement de règles d'équipe ainsi que la supervision du chef de projet (validation régulière et demandes de correction au maker).

Tout à fait d'accord avec toi

Un projet d'abord c'est une aventure humaine avant d'être une organisation.



Désolé si mon article laissait penser que pour G. Rémy, c'était autre chose.

Citation :

Je serais quand même curieux de ton avis sur ce qui aurait pu améliorer la gestion des 3 projets Jeu pour Relm, Projet 2016 et Bismillahdventure. Owi toutafé olala (si on peut vraiment parler de projet pour ce dernier, qui est davantage un trip entre deux potes).

J'ai des idées évidemment

Sniff