Guillaume Benoit as Elproducer
Marine Freland as MeyiahPetit compte-rendu du salon FGO (Future Game On) qui s’est déroulé à Paris porte de Versailles, le 9 et 10 septembre.
Tout d’abord, je tiens à remercier Thomas Demachy (http://www.indeegogames.com) pour cette incroyable opportunitée qui m’a été offerte d’être confériencière.
(non, non! je n’insulte personne)
J’ai pu parler de mon expérience en matière de méthodes agiles au sein d’Eden Games et ai même rédigé un papier à ce propos. Il ne reste plus qu’à voir si je me décide à le poster ou pas 😉 . Mon sujet portait surtout vers le rapport entre le game design et les méthodes agiles dont voici un petit résumé :
J’ai découpé ma présentation en 3 parties. Chaque partie correspond à une expérience unique au sein d’Eden games avec une équipe particulière et un projet distinct. J’ai appliqué quelques principes des méthodes agiles, et ai adapté ma propre méthode au projet et à l’équipe.
(Cliquez pour télécharger) : Methodes agiles – Retour sur une première expérience.
Ces 3 parties sont donc :
1. Le chef de projet n’est pas un game designer
2. Le chef de projet doit être un game designer… de méthodes
3. Les outils de communications mis en place
Personnellement je pense que la seconde partie est celle qui pourrait remplir un bouquin à elle seule. A partir du moment où on parle d »Agile », cela consiste a une faculté d’adaptation et de créativité du chef de projet vis à vis de l’équipe et du projet. Je pense donc que pour aller plus loin dans les méthodologies et application de celles-ci, il faut être aussi créatif que responsable.
Enfin comme nous travaillons dans le milieu du jeu vidéo, un métier de passion pour la plupart des développeurs ce qui les rend bien souvent eux-même joueurs on en vient à se dire : Quoi de mieux qu’un joueur pour lancer de nouveau challenges de production ?
Voila,quelques idées encore à méditer pour ma part…
Enfin, pour tous ceux qui sont venus me voir après la conférence, ou encore ceux qui m’ont écrit par e-mail : je tiens à vous remerciez pour vos remarques et le fait d’avoir partagé vos points de vue avec moi.
Et n’oubliez pas que si vous avez « Un planning waterfall itératif » c’est qu’il y a anguille sous roche! 😉 (petite blague qui m’a permis de voir ô combien de personnes dans la salle comprenaient de quoi je parlais, certains sont même venus par la suite se présenter en ajoutant « je fais parti de ceux qui ont compris la blague! » – et ça fait plaisir)
Ce salon et surtout cette conférence furent très enrichissants, j’ai pu rencontrer beaucoup de monde et partager mes idées.
Mais la personne qui m’aura le plus marqué par sa conférence ainsi que par sa manière de présenter (très dynamique et originale) n’est autre que Jason Della Rocca (http://www.realitypanic.com/).
Un grand merci à tous les participants et aux organisateurs !
Pour le jeu 
Un article très intéressant pour rebondir sur les propos de Marine concernant le but et le maintien de l’outil de communication: http://tinyurl.com/2g44pom
Je serais très intéressé par la lecture du papier encore à poster. Vous n’avez pas une vidéo de la conférence ?
Un petit bonjour à Guillaume, il semble que votre affaire marche !
Bonjour, le document à été mis en fichier joint sur l’article en question
Cdlt,
Marine
Merci Marine, j’ai globalement trouvé la lecture de ce document très intéressante. Et comme tu sais à quel point j’aime chipoter, je me permets quelques observations:
– J’avoue ne pas avoir totalement compris ton second exemple (équipe de taille moyenne, p.4 à 6). Tu dis avoir opté pour un découpage du projet en sprints, mais une équipe répartie en pôles de compétences dont l’organisation reste monolithique… Dans ce cas, en quoi la méthodologie de production est elle « agile » ? En quoi est-ce plus agile que le fameux planning « waterfall itératif » que tu évoques ironiquement (si ce n’est que la visibilité, limitée à quelques sprints, est moindre qu’en waterfall) ? La présence de ton tableau blanc, que l’on pourrait juste décrire comme un planning visuel et dynamique accessible à toute l’équipe, suffit-elle à rendre toute l’organisation du projet « agile » ? Pourquoi ne pas avoir opté pour un système de « TaskCells », adaptation encore plus souple des « Scrum Teams » que l’on retrouve dans des projets de taille modeste appliquant la philosophie Lean ?
– Question de vocabulaire : je trouve plutôt discutable l’affirmation récurrente selon laquelle « le chef de projet est le game designer de ses méthodes ». Bien évidemment, je ne peux qu’adhérer au propos global selon lequel le chef de projet se doit de créer des méthodes et des outils propres à chaque production et à chaque équipe. En revanche, pour moi il s’agit là d’un simple travail de design (qui signifie déjà « conception » en soi), qu’il s’agisse de process design (conception des méthodes) ou de software/tools design (conception logicielle/conception d’outils). Mais ça ne peut être considéré comme du « game » design seulement si l’on décide que ces outils et méthodes de production doivent comporter une réelle teneur ludique, ce qui est tout à fait envisageable afin d’en rendre l’utilisation plus agréable et/ou attirante pour l’équipe. Dans ce cas précis, effectivement, le chef de projet devient également game designer dans un sens très proche du game designer de serious games. Mais le simple fait d’être capable de concevoir des méthodes qui feront naître une forme d’émulation au sein de l’équipe ou un outil dont l’interface sera intuitive et simple d’accès (« user friendly ») fait normalement partie des compétences pré-requises d’un chef de projet ; cela ne suffit pas à le transformer totalement en un game designer, qui lui se préoccupe aussi de bien d’autres choses (compulsions motrices, sensation de plaisir & sentiment de progression, récompense utilisateur, etc…).
– Dans le prolongement de ta réflexion sur les outils de planification agiles et collaboratifs (Hansoft, Agile Team, IceScrum, Agile Team, etc…) et du lien posté par Guillaume, plus ça va et plus je suis convaincu que le principal problème pour les utilisateurs réfractaires (amis graphistes… :P) est le logiciel en lui-même. Mieux encore que la solution développée en interne, je crois qu’il faudrait un moyen de supprimer l’outil en tant que logiciel indépendant pour l’intégrer au reste de la chaîne de production afin que l’équipe n’ait pas à s’en préoccuper une seule seconde. Par exemple, tout le monde utilise déjà un client mail avec agenda incorporé (Outlook, Thunderdird + Lightning…) ? Alors en début de sprint chacun reçoit sa liste de tâches directement dans son agenda. Un logiciel de gestion de version est utilisé sur le projet (Perforce, SVN…) ? Alors au moment où les utilisateurs font un submit de leurs fichiers, une fenêtre leur propose de lier cette soumission à l’une des tâches qui leur est assignée. Etc… La seule véritable interface servirait à administrer tout ça et ne serait accessible que pour les chefs de projets et autres managers/administrateurs (avec bien sûr la possibilité pour l’équipe d’accéder à une vue globale du planning semblable à ton tableau blanc). En tout cas, je ne vois pas comment faire plus simple et plus efficace, le problème étant que ça demande de pouvoir accéder aux sources d’une partie des outils logiciels afin d’y apporter les modifications nécessaires à l’intégration du tool. Reste que je trouve l’idée extrêmement séduisante!
En tout cas, continuez à maintenir ce WordPress en vie et à en propager l’adresse, je suis certain que sa lecture peut s’avérer utile à de nombreuses personnes! 😉
Merci pour tes commentaires, l’intérêt que tu as portée à ce document, et à pousser même encore plus loin la réflexion.
Ce document étant mon premier, voici quelques réponses simples à tes questions en espérant ne pas te décevoir 😉
Pour le second exemple, il faut savoir que pour des équipes qui n’ont jamais travaillé en « agile » des périodes transitoires sont importantes – je pense – afin de ne pas non plus bousculer complètement leur environnement de travail. D’ou un découpage par pôle des compétences et non par grandes tâches.
De plus, l’équipe étant assez petite, il s’agissait principalement pour tout le monde de la « même grande tâche » (exemple le niveau X pour tout le monde, avec quelques éléments génériques malgré tout). Une équipe un poil plus grande aurait été un excellent moyen effectivement de tester un découpage différent.
De plus, il s’agit là d’un retour sur mon expérience, et je pense que tu es bien placer pour comprendre que les premières expériences sont pas toujours « faciles » :
Etant le petit nouveau (ou la petite nouvelle dans mon cas) qui doit faire ses preuves, qui VEUX faire ses preuves, il faut faire des choix, (et je ne pense pas avoir pris des mauvais), même si je ne suis pas parti pour du SCRUM en tant qu’agile. J’ai même quelques gros doutes quand à l’utilisation du mot « Scrum » de nos jours que tout le monde met à sa sauce et vois comme la méthode messie de la gestion de production. A la lecture de certaines personnes, on à l’impression de sentir : « Soit C’est SCRUM soit c’est pas agile ou alors c’est n’importe quoi) Alors que loin de là….
La méthode scrum est plus ou moins figée et à fait ses preuves, mais n’ai malheureusement pas tout jour facile à implémenter selon les équipes et les projets, et je pense que PEU de personnes sont capables (que ça soit par la connaissance totale ou la possibilité de le faire réellement en entreprise) de la mettre en place.
Elle demande que le chef de projet ai toute la confiance de son équipe comme de ses supérieurs car elle demande des changements radicaux quand à leur organisation. En tant que junior, il est difficile de se permettre de tels changements et je me suis orientée (comme dit avant) en proposant des transitions..
Pour ta question de vocabulaire, je trouve que tu as toi même la réponse dans ta réflexion. J’ai eu à peu près la même et je suis contente que tu ai postée toute la réfléxion.
Tu serais étonné (ou tu l’ai déjà) de voir le nombre de chef de projets/producteurs qui n’ont pas ces compétences que tu juges « pré-requise » dans le milieu du jeu vidéo. (Et je suis de ton avis)
Seulement, il ne s’agit pas de le transformer en game designer, mais qu’il réponde aux mêmes questions que celui-ci : compulsions motrices du projet, sensation de plaisir & sentiment de progression des équipes, récompense utilisateur, etc…) pour reprendre ce que tu as mis, orientée équipe.
Et je persiste à penser qu’il y à une bonne matière à travailler (donc encore merci pour ta reflexion) car il ne s’agit là que d’une idée qui m’a suivi pendant l’écriture mais qui n’a pas encore était (ou alors je ne l’ai pas encore vu) vraiment développer. Cela me tient à coeur.
Je n’ai pas développé beaucoup de détails quand à l’outil interne à Eden Games car, n’ayant pas eu de retours sur le sujet, je ne savais pas si je pouvais rentrer dans les détails. Cependant, je suis tout à fait d’accord, il est clairement indispensable que cet outil soit un liant, et intègre les outils déjà utilisé par les utilisateurs. Mais pour lier tous les outils ( 3DSMax, Maya, Outlook, etc.) il faut un développement.
Oups, déjà 5 jours que tu as répondu et je n’avais pas vu ! 🙂
En tout cas, merci pour ces éclaircissements ; effectivement, l’argument de la période de transition pour l’équipe vers plus d’agilité se défend totalement. Et je suis totalement d’accord au sujet de l’utilisation abusive du terme « Scrum ». D’ailleurs, personnellement, je préfère parler plus largement de « philosophie Lean », que je trouve généralement plus adapté.
Du coup, l’une des préoccupations au cœur des méthodes agiles étant la satisfaction du client, peux-tu commenter un peu de l’accueil que ton publisher (en l’occurence Atari je suppose) a réservé à ces diverses initiatives ? Intérêt et soutient ? Ignorance ? Incompréhension ? Hostilité ? NDA tu peux pas en parler ?
Bon, et sinon, à quand le prochain papier ? 😉
Merci à toi 😉 J’adore parler Méthodes de prod!
Prochain papier?, quand j’aurais eu/vu d’autres expériences à raconter ou alors peut être pousser la réflexion sur un sujet, pour le moment je me concentre sur d’autres projets.
Ah et pour Atari… hum… dur dur d’en parler de manière politiquement correcte à cause d’un changement à tout va des dirigeants. Donc je passe 😉