Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

22/03/2007

Etre Agile...

J’ai souvent entendu que le business model de l’industrie du jeu vidéo était au mieux aberrant, au pire suicidaire. Et de fait, il m’a très vite semblé que la façon usuelle de produire débouchait un peu trop souvent sur des échecs pour ne pas mériter d’être remise en cause.

 

A l’heure actuelle, seule 20% des jeux produits rencontre un succès commercial. Compte tenu du coût moyen de production, c’est un niveau exceptionnellement bas ! Malheureusement, le développement d’un jeu se fait encore de façon bien trop monolithique, avec une inertie absolument incroyable.

 

Lost Garden revient sur la façon de faire dans les autres industries, et met en avant deux concepts qui me semblent fondamentaux : la diversification des projets (savoir repartir les risques) et la notion de « stage gate » (évaluer bien et souvent, adapter les objectifs et la direction du projet, et surtout savoir s’arrêter avant qu’il soit trop tard).

 

En d’autres termes, savoir être agile…

 

medium_Iteration-Diagrams-StageGatePortfolio-737228.jpg
medium_StageGate-Gate-Diagram-792656.jpg
 

...

 

Instead of taking 12 to 18 months to create and evaluate a new concept, they build and put new version in front of users every 2 to 4 weeks. They also work in high bandwidth environments where all the team members are close together and close to the customer. Team members converge on and build concensus around good ideas over a period of hours, not months. Teams become experts through intense hands-on problem solving and testing. This ends up building products much more likely to serve real needs than those imagined in Platonic specs by ivory tower experts.



Agile development is favored by small start up teams because the techniques greatly reduce the risk of an individual team failing. If you only have room for one shot at the target, you might as well steer your way to success using lots of rich information instead of launching blindly into the unknown. Long term, agile processes delivering more value sooner, with lower overall risk.



An agile project is intensely focused. In the rush of completing only high priority features, many alternative concepts never get the chance to be explored. Customers, a rather vague and argumentative bunch at best, are required to speak with one voice in the name of reducing noise and thrash for the team. For many teams struggling just to get software out the door, these traits are a godsend. The downside is that there is little concept of strategic portfolio management.

 

...

 
We’ve added three items to the traditional agile model.

  • Diverse seed teams: The first is the concept of multiple teams heading in different directions with different goals. There isn’t a single customer, but multiple customers driving multiple potential success strategies.

  • Kill Gates: The second item is the concept of gates every few iterations that kill poorly performing projects. It is better to return those resources back to existing projects than to continue investing. You can think of the success criteria that drives the gates as a set of reasonable constraints. The team is allowed to do whatever it desires as long as it meets the outlined constraints that are measured at each gate.

  • Concept banks: The third is the concept bank where old ideas are stored for possible recycling. You never know when the remnants of an old idea will nourish a strong new project.

 

[ Lost Garden ]

Commentaires

Le pire c'est que tout cela est tellement évident que parfois on se demande pourquoi on applique pas ces concepts. L'aspect de diversification est tellement primordial que j'ai parfois du mal à comprendre que certains studio refuse catégoriquement ce positionnement alors qu'il devrait faire part de la croissance organique de la société. Comme dit "grandir pour ne pas périr". Le problème c'est que trop de MBA, écoles de commerces et autres grandes écoles apprennent tout à leur étudiants sauf le "bon sens".

Écrit par : Pedro Guanaes | 22/03/2007

Pour ce qui est des MBA, je suis pas si sur qe toi Pedro. Au contraire, je pense qu'il y a trop d'autodidacte dans le millieu, et qu'on y gagnerai en rigeur.

Quand a Agile, le bon sens n'est pas forcement ce que l'on croit. Par exemple, la méthode qui est décrite ici recquiert un investissment "up front" qui n'est pas à la porté de toutes les bourses ^_^

Écrit par : Daz | 22/03/2007

oui je suis d'accord que c'est une méthode facilement applicable dans un studio mur qu'une jeune structure. Ma critique des MBA c'est qu'il y en a peu qui sont valable et bcp qui sont des pompes à fric qui te vende le diplome. Il en existe d'autre qui par contre te transmette les vrai valeurs.
Pour revenir à la technique agile, je pense que l'intérressant est surtout de se pencher sur la pérrinité de plusiseurs projet simultanément avec le principe du recylclage

Écrit par : Pedro Guanaes | 22/03/2007

Arf, on ecrit trop mal :-P LOL !!!! ^_^

Écrit par : Daz | 22/03/2007

Et la question qui va bien, pour un gros studio ok, mais dans un petit on fait comment ?

Par contre à force de lire des "kill gates" j'ai l'impression que tu aimes pas microsoft.

Écrit par : Whirly | 23/03/2007

LOL. Je n'ai rien contre billou, bien au contraire ^_^

Par conte, en effet, ca n'est pas une approche praticable sans un certain niveau d'investissement, donc en principe innacessible a la plupart des PME.

Mais ca ne veut pas dire que ça n'est pas une approche utile a un niveau plus atomique.

Par exemple, fut un temps, il n'etait pas rare de voir une équipe décidé de la présence d'une feature et d'une implémentation au cours d'une réunion, puis de devoir attendre 6 mois avant d'en voir une réalisation.

Si la feature n'était pas bonne, ou le choix de réalisation innapproprié, boum, 6 mois de perdu. Et le temps, c'est la seule chose qui ne se rattrape pas.

Ces derniers temps, on approche le problème un peu plus différement. Pour une feature donnée, on va essayer d'implémenter plusieurs technologies alternatives, avec une évaluation plus fréquente.

Les mauvais choix sont très vite écartés, les inconnus sont également très vite levé. De même, il est très vite possible de 'killer' tel ou tel features si le bénéfice s'avère inférieur au gain espéré.

Du coup, c'est vrai que ça a un coup en terme de schedule. Une feature donné prendra peut etre 8 mois au lieu de 6. Par contre, la garantie de succès est bien plus elevée.

Et de même, on réalise plus tôt que l'on s'est trompé dès le départ, ce qui permet de killer une feature au bout de 2 ou 3 mois au lieu de 6...

Evidemment, c'est une abstraction de la réalité, mais globalement, ça marche pas si mal ^_^

Écrit par : Daz | 23/03/2007

J'aime ce modèle de développement (darwinisme des features + consumer focused)
Tout ce qui peut permettre de s'en rapprocher est bien.

Mais même pour un gros studio ce n'est pas si simple...

L'argent me semble moins un problème que la frustration engendrée.

La vie des projets de jeu vidéo n'est généralement pas aussi manichéenne que
- Blanc : vous êtes des winners, vous passez le Kill Gate
- Noir : Votre projet est nul, vous êtes killé.

Comment gérer facilement des situations comme :

"Tu es DA et tu t'es investi comme un malade sur le projet, j'ai une bonne et une mauvaise nouvelle
- La bonne: Ton projet a passé le kill gate
- La mauvaise : tu es remplacé par X qui est meilleur que toi pour cette tâche"

Ou l'inverse :

"Tu as fait un boulot magnifique de DA sur ce projet. Bravo. Mais ton projet est killé car un peu trop niche. Tu va faire modeleur sur le projet Y".

Ou encore :

"Et les gars, votre projet, c'est de la balle. Bravo. Mais on va quand même le killer, car un projet plus avancé vient de passer l'ultime gate et ils ont instamment besoin de nouvelles ressources".

Etc.

Toutes ces situations, existent régulièrement dans le développement de jeu vidéo. Comment les gèrent-on si le modéle impose que cela devienne la norme.

Même si le jeu vidéo est essentiellement une industrie, beaucoup de gens que je connaîs bouffent/chient/rêvent le projet sur lequel il bossent.
Ils s'approprient le jeu.

C'est l'un des moteurs pour faire un bon jeu vidéo.
Comment ne pas le casser ?

Je suis avide d'articles qui traitent de ce problème (gestion humaine dans un studio qui a X projets en concurrence).

Écrit par : Serpico | 24/03/2007

Ah, Serpico, tes exemples sentent le vecu ;-) Soit tu en dis trop, soit tu en dis pas assez ^_^

Pour ma part, le seul "Uber Studio" pour lequel j'ai travaille, c'est Argonaut. Et vu comment ca a fini, j'y pense plus souvent comme un exemple de ce qu'il faut pas faire que l'inverse.

Ce qui ne m'empeche pas d'avoir vu mille fois (j'exagere bien sur) les exemples que tu nous donnes.

Pour ma part, mon experience est plus porte sur des studios independants. Dans ce contexte, il y a en general a chaque instant T un et un seul projet porteur, parfois AAA, parfois alimentaire.

En complement, souvent aussi, une poigne de projets plus ou moins avances vivotent en attendant leur tour. Dans ce cas la, ca n'est pas temps la kill gate qui menace que le pourrissement sur place.

Les projets sont vivants, ce sont des entites qui ont besoin de progresser continuement. Quand ils sont bloques par defaut de financement, ou de ressources humaines, ou tout simplement parce que personne n'ose les tuer, les effets peuvent etre devastateurs! ^_^

C'est pour ca que l'approche decrite dans cet article ne doit pas etre prise au pied de la lettre. Mais elle s'adapte bien en effet a un niveau plus atomique, au service d'une seul et meme vision.

Il y a bien sur un coup humain a cette facon de faire. Il n'est pas rare de froiser des egos, de ne pas etre compris, ou de decevoir quelqu'un qui s'est particulierement investi.

Ca m'arrive parfois de passer N semaines sur un probleme donne, en obtenant un resultat mitige a la fin. J'ai vu certaines features auxquelles je tenais beaucoup etre abandonne a ce moment la.

Mais killer plus tot, c'est aussi permettre au gens de tomber de moins haut. Et si cette approche est adopte des le depart avec des regles claires, il n'y a pas de raison pour que ca se passe mal.

Meme si je sais qu'au bout de N+T mois j'aurai pu resoudre le probleme de maniere satisfaisante, je sais aussi que je peux consacrer ces T mois a d'autres problemes, et obtenir d'autres resultats peut etre plus interessant sur le long terme.

Ca me permet de rester concentrer sur l'essentiel, le jeu que l'on est en train de produire...

Mais la gestion humaine, ca, c'est un art...

Écrit par : Daz | 24/03/2007

Tout mon propos concernait le côté macro :
- X équipes sur la grille de départ (généralement à des degrés d'avancement divers)
- 1 ou 2 élues au bout du compte.

-> C'est parfois vu comme une bonne solution à la fameuse phase d'inter projet...
Mais il y a les risques que je mentionne et que je ne saurais pas résoudre.

Mais d'un autre côté, ce n'est pas simple de commencer une conception avec trop de personnes (juste pour les employer).

Autant en profiter pour explorer tout le spectre des possibles, vu que la majorité des gens qui bossent dans le jeu vidéo ont plein de choses à proposer, à toutes les phases du développement d'un projet, et dans tous les domaines.

C'est dans ce sens que ton article m'intéresse (même si j'aimerais avoir des exemples vécus réussis :-) ).

Pour le côté micro que tu décris (au sein d'un même projet), je suis d'accord à 100%.

Il y a les features core que l'on ne peut supprimer sans ébranler l'ensemble du projet (elles sont généralement peu nombreuses).

Il y a toutes les autres features qui soutiennent la vision... qui sont toutes aussi importantes...
Mais celles là, on peut les couper, les modifier, en ajouter d'autres.

Quand tu dis que les projets sont vivants, c'est très vrai.
C'est pour cela que j'utilise la métaphore "darwinienne".

Si une feature qui me semblait intéressante n'évolue pas, alors que d'autres explosent, c'est qu'il y a un problème.

Si j'en ai la possibilité, et que la raison de son non-avancement n'est pas conjoncturelle, je la coupe au profit d'autres plus prometteuses...

Quel que soit le corps de métier, il faut régulièrement se poser la question,
- Si je ne conservais qu'un truc, lequel serait-ce ?
- Trois ?
- Dix ?

Bref, il faut prioriser en quasi temps réel, car le temps imparti pour sortir un jeu s'éloigne rarement :-)

Ps: Mes exemples précédents sont vécus, vus, imaginés :-)

Écrit par : Serpico | 24/03/2007

Je pense qu'il faut aussi voir ça en terme de feature et pas de projet car dans le cas de petites stuctures ce sont bien les features qui peuvent etre ou non gérer de la sorte.
En ce qui concerne un projet, je pense que dans beaucoup de cas la passion dépasse la raison, et c'est un problème qu'il faut savoir rapidement comprendre pour éviter les tensions dans les équipes ou les problèmes de développement. Savoir prendre du recul sur son propre travail n'est pas chose aisé et peu savent le faire mais c'est primordial pour comprendre les futurs déficiences d'un projet.
Un exercice simple est de se demander qu'elle sont les trois problème majeur que l'on va rencontrer et d'essayer de les résoudre. Cela peut etre tellement évident écrit comme ça mais la pratique veut que ce genre de pratique même si on les applique en début de projet finissent par être abandonné....

Écrit par : Pedro Guanaes | 24/03/2007

* Je pense que pour ce qui est des problèmes humains d'une telle méthode cela se situe plus au niveau de la justice perçu d'un tel dispositif. En gros il faut que le choix soit le plus impartiale possible (et pas genre "le projet de mon copain il est kiewl) et que les données initiales soient claires et respectés (genre vous avez 6 semaines, et pas 6 semaines mais deux pendant lesquelles on vous mettra sur un autre projet qui part en sucette).

* Dans un studio indépendant on a une gestion plus "au ras du bithume des budgets" ce qui veut dire que cette méthode devra passer la barrière de "l'utilité constaté" surtout à une époque où les éditeurs veulent controler de plus en plus l'usage que l'on fait de leur argent (ce que je ne considère pas en soi comme étant déplacé). Je pense que le changement à notre niveau sera de proposer ce genre de formules aux éditeurs et voir si on arrive à vendre ça.

* Au niveau de la gestion humaine, ce genre de cycle cours avec deadline à la fin risque de pas mal monter aussi la pression sur les épaules des gens avec le corrolaire du débordement des horraires. On risque de ressortir le presse agrume.

Écrit par : Whirly | 25/03/2007

Si je resume, nous convenons tous que cette approche doit etre adapte a l'echelle de l'entreprise, et doit prendre en compte le cout humain de la chose.

Chaque partie prenante dans cette affaire doit tenir ses engagements, et ne pas changer les regles du jeu de facon arbitraire ^_^

Je rejoint ta remarque Whirly sur le presse agrume --> s'imposer un cycle court, ca veut pas dire enchainer les 100 m, ca veut dire gagner un marathon kilometre apres kilometre.

De meme, Serpico leve la bonne comparaison: Si une approche "Darwiniene" peut etre benefique pour la progresion du projet, c'est souvent confondu avec la loi du plus fort, ou les plus forts en geule prennent le pouvoir, ou alors on blame le ou la responsable percu d'un probleme donne.

Etre agile, c'est etre agile ensemble. Autrement dit, les problemes de l'un sont les problemes de tous.

Malheureusement, je doit etre un grand naif sur la nature humaine... ^_^

Obtenir l'adhesion de tous dans une equipe de 20, c'est possible. Dans une equipe de 50, ca commence deja a etre la loi des clans. Et au dela, je n'ai honnetement aucune idee de comment ca peut fonctionner...

@Whirly: Je rejoint aussi ton commentaire sur "l'utilite constate" de la feature. J'ai souvent croise l'expression "bang for the buck", qui rejoint une deviation de cette meme idee. Je ferai un post la dessus bientot... :-)

Écrit par : Daz | 25/03/2007

Les commentaires sont fermés.