Discussion :

[valholl]

Bonjour à tous,

Je suis nouveau dans cette communauté et je remercie déjà tout un chacun pour le travail accompli jusqu'ici et à venir.

J'ai lu avec beaucoup d'intérêt un certain nombre de posts et j'ai eu la chance de voir pas mal de choses qui me tiennent à cœur sur ce forum et pour lesquelles je me suis permis de m'inscrire car je tiens à faire part de mon expérience dans le domaine. Je veux parler de la gestion technique de projet.

J'espère que je ne vais pas faire de hors sujet, et je pense que ce sujet doit pouvoir condenser pas mal de choses qui ont déjà été dites.

Je ne suis pas non plus une référence de ce que je vais annoncer, certainement que pas mal de personnes vont me prendre pour un fou voire un hérétique, à vous de voir.

Je vais tout d'abord me présenter, puis présenter mes idées.

* Qui je suis ? *

Je suis développeur pour les marchés des télécommunications et aussi responsable d'équipe, de projet pour l'aspect technique ainsi que de support client; je m'occupe aussi du "fault reporting" et je prends part aux discussions techniques en tant que consultant sur des nouveaux projets. J'ai plusieurs années d'expérience dans le domaine (mais ce n'est pas pour cela que je suis un puits de science absolue).

* Pourquoi ce sujet ? *

Beaucoup de gens se lancent dans des projets sans trop savoir au-devant de quoi ils vont. Pourtant, la gestion de projet fait partie de la vie de tous les jours: gérer son travail scolaire, faire ses courses, etc., sont des exemples simples de gestion de projet. Mon idée ici est de présenter quelques idées simples et efficaces à mettre en œuvre afin de permettre, à défaut de réussir complètement, de mener à bien un projet, en faisant usage de mon expérience de tous les jours. Et, à la fin, de vous expliquer comment je gère le projet que j'ai tout juste commencé il y a une semaine.

Note: travaillant dans une société internationale, le vocabulaire usuel est en anglais. Je tâcherai, autant que faire se peut, de traduire les termes employés.

Ce sujet se veut une sorte de "wiki" ouvert à tous. Chaque message posté et contenant un document, traitera d'un sujet. J'essaierai du mieux possible de traiter les concepts de manière chronologique.

Ce sujet ne sera pas neuf pour ceux qui ont déjà réagi de fort bonne manière à des présentations de projets.

Si d'aventure il apparaissait que mon sujet est un duplicata d'un autre, n'apporte rien au débat ou choque par ses propos, merci de me le signaler.

Je tiens, en conclusion de cette présentation, terminer en disant que ce sujet est une application de mon expérience d'entreprise. Il n'est en rien le discours de project managers réputés ou de livres spécialisés.

Bien à vous,
valholl

[valholl]

Bonsoir,

Comme promis, le premier sujet, à savoir les documents et la preuve de concept.

Il est disponible en pièce jointe.

Bonne lecture.

Bien à vous,
valholl

[N_I_C_S]

Salut,
déjà au début du doc. : "Personne de réfénrece : valholl" , c'est limite...
Ensuite, puisqu'on est entre nous, je m'interroge sur les raisons qui poussent une personne à livrer sans conditions et tout d'un coup le fruit "d'années d'expériences" (sans doute la fameuse méfiance française...).

[kremvax]

Salut valholl

C'est intéressant d'avoir ce genre de point de vue, c'est toujours bon de connaitre une méthodologie "pro".
Cependant, je relativiserai quand même sa portée ici, puisque la plupart des projets de jeux ici sont amateurs et pour une bonne partie même sans visée commerciale. De ça, il en découle :
- des équipe normalement plus petites (ou alors, c'est qu'il y a un souci au niveau de la gestion du recrutement)
- une efficacité moindre car peu d'amateurs travaillent à plein temps sur leur projet

Du coup, les étapes très formelles que tu décris (gdd "brouillon", gdd "formel", proof of concept etc.) gagnent à être réalisées de façon informelle, via un forum par exemple, de façon à pouvoir avancer sans nécessairement devoir attendre une revue par X personnes, bref en s'affranchissant d'une gestion "administrative" façon entreprise. Aussi, le proof of concept se conçoit dans une optique commerciale, ce qui n'est pas toujours le cas chez les amateurs. Voilà pour mon avis, mais je répète malgré tout, c'est intéressant de connaitre ton approche.

[valholl]

Bonjour,

N_I_C_S> Faute de frappe, désolé, cela arrive (personne n'est parfait).
Je ne suis pas infaillible, comme je l'ai indiqué, et je ne viens pas en grand moralisateur... je donne mon approche et mon expérience, mais ce n'est en aucun cas "la seule et unique méthode de travail". Quant aux raisons, disons que je préfère simplement partager mes connaissances plutôt que de les garder pour moi. J'admets néanmoins que faire une faute à la première ligne, c'est assez boulet de ma part
Les années d'expérience, elles ne sont pas fictives. Des conditions? Pourquoi il y en aurait-il?

kremvax> Je suis partiellement d'accord avec ton point de vue. On peut croire que parce qu'il n'y a pas de visée commerciale (ou très peu), on peut s'affranchir d'un support formel. Néanmoins, je pense que c'est un mal nécessaire; l'avantage principal est que les designers étant rarement les développeurs, on obtient un point de vue qui diffère et qui évite de tomber dans des pièges car un développeur qui rédige un document de design le fera avec un point de vue développeur, ce qui n'est pas ce que l'on veut. Cela permet aussi de garder des traces qui évoluent d'une façon plus incrémentale que sur un forum où les idées avancent au fil des pages pour finir par se perdre dans le grand nombre de celles-ci.

EDIT: Néanmoins, je tiens à préciser une chose importante: je parle ici de support de design, je ne parle évidemment pas des discussions, réunions, checkpoints etc. qui peuvent se faire via chat, skype, forum... L'idée, c'est que ce qui en a découlé serve ensuite de point de départ pour créer un document ou en modifier un existant, assurant ainsi un suivi aisé. Car il est clair qu'il sera toujours nécessaire de discuter, partager des opinions..., sans quoi il ne serait pas possible de faire lesdits documents. C'est là où je te rejoins car en effet, il faut un support informel pour aboutir à un support formel. [fin de l'edit]

La taille de l'équipe? Personnellement, quand j'ai commencé à travailler dans mon entreprise nous étions une demie douzaine de développeurs pour implémenter plus de vingt services... Si les documents n'avaient pas été là à l'époque, nous n'aurions jamais mis la plateforme en service. Cela permet aussi de voir ce à quoi on n'avait pas pensé, etc. et de retomber sur une info rapidement quand on en a besoin.

Le proof of concept n'a pas pour moi qu'une seule portée commerciale; il permet d'éviter d'embarquer toute une équipe de personnes de tous profils dans quelque chose dont la faisabilité n'a pas été étudiée. C'est selon moi d'autant plus vrai pour un projet amateur où la plupart des personnes n'auront peut-être jamais fait cela de leur vie (ou en tout cas pas de manière si grande); dans une entreprise les personnes employées sont déjà compétentes et, comme il n'y a pas encore de contrat, il n'y a pas de budget, et donc on ne peut pas se permettre d'engager des personnes dessus sans savoir si c'est faisable ou non.

Néanmoins, pour te citer kremvax, n'oublions pas une chose: j'ai une expérience d'entreprise que je partage; vous avez une expérience de jeu que vous partagez. Au final, le but est bien entendu de voir, au travers des différents sujets traités, lesquels se recoupent, lesquels peuvent être améliorés et lesquels ne sont pas applicables. J'ai commencé mon projet il y a peu avec mon approche d'entreprise; nous verrons si l'avenir me donne raison ou pas. Car je pense que dans tous les cas, nous avons tous à y gagner.

En résumé: il faut relativiser et s'adapter aux besoins.

EDIT: J'ai oublié un point très important: les facteurs de risque, les plannings, les milestones, etc., sont facilités grâce au suivi par documents et au proof of concept.

Bien à vous,
valholl

[3DArchi]

Salut,
Quelques remarques d'ordre général.
* Le premier document que je créé est le document référentiel: un classeur qui regroupe tous les articles utilisés avec leur version,leur référencement et leur emplacement. Tout document du projet doit se retrouver là-dedans. C'est vrai pour les documents produits, mais aussi ceux utilisés: articles, livres, normes (interne à l'entreprise ou pas) ...
* Le saut de l'idée à la preuve de concept - chez moi, ça s'appele l'étude de faisabilité - est trop grande. L'idée doit d'abord être déclinée dans un CCTP, un Cahier des Clauses Techniques Particulières (ou tout autre vocabulaire qui te plaira), déclinant les exigences de haut niveau attendues du projet. Par exemple: le jeu est un packman, il est multi-joueur, il doit tourner sur un mobile, il doit comporter une doc en français, il doit être distribuable sur Internet ... Ce sont des exigences à la fois sur ce qu'il contiendra mais aussi sur des aspects annexes (dans l'expl, la doc, le moyen de distribution). Certaines exigences peuvent être de haut niveau: 'une gestion de version est mise en place' ou carrément de plus bas niveau : 'le multi-joueur se fera en TCP'. Il faut faire attention à ne pas mettre des données de conceptions mais bien des exigences du projet qui servent à le cadrer. Typiquement, cette dernière exigence peut être pertinente dans certains projets mais absurdes dans d'autres!
* L'étude de faisabilité ne passe pas par du codage mais par l'expertise. Elle sert à positionner soit des limites, soit des risques.
* Le codage démarre trop tôt à mon avis. Il faut au - être passé depuis le CCTP vers des specs générales déclinant chacune des exigences du CCTP vers des exigences globales ou systèmes. Celles-ci sont ensuite déclinées en specs détaillées où on commence à préciser les choses. Ce n'est qu'à ce moment qu'on commence la conception. Sinon, beaucoup de risque d'aller/retour et de perte de temps à refaire 4 fois la même chose, découragement...
* Ne pas oublier d'associer systématiquement ce genre de document à leur contrepartie: les documents de validation. En gros, décrire comment sera testée chaque chose écrite. Cela permet de voir si on apporte de l'information ou non.
Voilà pour un début. Mais je pense qu'il y aurait encore beaucoup de choses à dire sur la gestion de projet.
En tout cas, félicitation pour ton idée et bon courage.

[Mat.M]

kremvax> Je suis partiellement d'accord avec ton point de vue. ...car un développeur qui rédige un document de design le fera avec un point de vue développeur, ce qui n'est pas ce que l'on veut. valholl

Kremvax a parfaitement raison : ici c'est un forum de développeurs/créateurs de jeu amateurs qui n'ont pas trop le temps de faire des specs.
Si tu travailles dans un gros studio que tu encadres 20 personnes par contre je dis d'accord.
Mais un projet amateur qui risque d'être inachevé je n'en vois pas trop la pertinence.
Et puis le secteur du jeu vidéo c'est pas comme pour un projet de gestion le point majeur et essentiel c'est la créativité , le game design.

C'est du conceptuel ,du artwork

La taille de l'équipe? Personnellement, quand j'ai commencé à travailler dans mon entreprise nous étions une demie douzaine de développeurs pour implémenter plus de vingt services... Si les documents n'avaient pas été là à l'époque, nous n'aurions jamais mis la plateforme en service. Cela permet aussi de voir ce à quoi on n'avait pas pensé, etc. et de retomber sur une info rapidement quand on en a besoin.

Ok c'est une phase sans doute essentielle dans le cycle de développement d'un projet chez Ubi Soft Ou Electronics Art mais pour une équipe de Indie Gamer de 2 ou 3 personnes je suis dubitatif

[valholl]

Bonsoir,

Tout d'abord, désolé d'avance pour la longueur, mais je tiens à discuter chaque point.

...
* Le saut de l'idée à la preuve de concept - chez moi, ça s'appele l'étude de faisabilité - est trop grande. L'idée doit d'abord être déclinée dans un CCTP, un Cahier des Clauses Techniques Particulières (ou tout autre vocabulaire qui te plaira)......

Nous avons en effet un document similaire (dont le nom m'échappe pour le moment) qui définit les responsabilités du supplier vis-à-vis du client et donc la globalité du projet en termes de demandes ("devra fonctionner sur du matériel X", "être compatible avec le software Y", etc.). Néanmoins, j'ai choisi de ne pas prendre la casquette client, j'ai donc mélangé le CCTP et la preuve de concept, honte à moi (mais c'est une tentative intéressante non?). Je dois d'ailleurs revoir ma preuve de concept, qui est bien trop légère à mon goût (en fait, légère de par la légèreté de mon CCTP, je vais donc devoir reprendre le travail à l'envers; mais disons qu'en gros, c'est la technologie qui a "conditionné" ce process de par l'absence de client - et je viens avec un "qu'est-ce qui est faisable avec X ?" plutôt qu'avec "pouvez-vous faire Y ?", alors que c'est ce dernier point qui est le bon, je l'admets). Quand j'y repense, le CCTP ressemble à ce que j'ai posté sur le forum de jeux vidéos où j'ai présenté mon idée... c'est par après que la demande "expertise" a mal tourné et c'est transformé en codage qui dictera à la fin ce qui est faisable ou pas (paradoxal). Je voudrais néanmoins préciser que parfois, je dis bien parfois, certaines personnes surestiment leurs capacités quand il s'agit de projets amateurs, autant du côté des développeurs que des autres intervenants, ce qui conduit souvent le projet à l'échec.

* L'étude de faisabilité ne passe pas par du codage mais par l'expertise. Elle sert à positionner soit des limites, soit des risques.

Tout à fait et c'est ce qui se passe en entreprise. Mais pour prendre un cas concret: dans mon projet, je suis en manque de développeurs et de designers, et donc faute d'experts je n'ai eu d'autre choix que de me porter sur mon principal développeur qui, plutôt que de faire une étude de faisabilité en terme d'expertise, a commencé à coder. Mais je suis tout à fait d'accord, cela aurait dû se passer comme cela (j'avoue, ce que je propose est un point de vue, qui n'est pas systématiquement applicable). Il y a aussi le problème du manque de ressources afin de réaliser l'expertise; dans le cadre d'un projet amateur cela coïncide avec les bonnes âmes qui auront accepté de se joindre au projet et qui, parfois, préféreront coder avant d'analyser (mais ce n'est pas une généralité). Cela rejoint aussi ma réponse précédente.

* Le codage démarre trop tôt à mon avis. Il faut au - être passé depuis le CCTP vers des specs générales déclinant chacune des exigences du CCTP vers des exigences globales ou systèmes. Celles-ci sont ensuite déclinées en specs détaillées où on commence à préciser les choses. Ce n'est qu'à ce moment qu'on commence la conception.......

De nouveau, je ne peux que rejoindre ton avis. En pratique, c'est ce qui se passe en entreprise. J'ai tenté de rassembler les deux approches - entreprise et amateur - sans prendre la considération client qui requiert le CCTP. Mon erreur se situe peut-être là: j'aurais dû me présenter comme un client demandeur, plutôt que comme un manager. Je pense aussi que je n'ai pas été clair assez sur ce point dans mes propos, mais à nouveau j'ai voulu éviter l'optique "demandeur externe" (et je te rassure: dans mon entreprise, c'est exactement comme tu le décris que cela se passe - et heureusement quand ce sont des millions d'euros qui sont en jeu).

* Ne pas oublier d'associer systématiquement ce genre de document à leur contrepartie: les documents de validation. En gros, décrire comment sera testée chaque chose écrite. Cela permet de voir si on apporte de l'information ou non.

Absolument. Je comptais discuter de la validation par après (dans un article traitant de la qualité, avec les tests cases, les hiérarchies, etc.) mais tu m'as pris de court.

Voilà pour un début. Mais je pense qu'il y aurait encore beaucoup de choses à dire sur la gestion de projet.
En tout cas, félicitation pour ton idée et bon courage.

Merci. C'est en effet un sujet à part entière, j'ai tenté de mélanger expérience professionnelle et projet amateur afin de voir jusqu'où la comparaison peut aller.

Kremvax a parfaitement raison : ici c'est un forum de développeurs/créateurs de jeu amateurs qui n'ont pas trop le temps de faire des specs.

Je ne me rappelais pas avoir indiqué que les développeurs devaient faire les specs. C'est là toute l'utilité d'une équipe de designers avant même de recruter les développeurs. C'est aussi pendant la phase d'étude du planning et d'allocation des ressources (humaines s'entend) qu'on déterminera combien de développeurs on requiert (on ne commence pas avant avec les programmeurs); de plus, la taille du design pourra aussi donner une bonne idée du nombre de ressources (ici je parle plutôt en termes de man/days). En revanche, lorsque c'est possible (typiquement, lorsque c'est le client qui fournit des specs de design), une review par un technicien programmeur est toujours la bienvenue. Evidemment, si en projet amateur on ne dispose que d'une équipe de programmeurs qui veulent se lancer immédiatement dans l'aventure, et si on néglige les aspects commerciaux, client, etc. qui n'entrent pas en ligne de compte, alors d'accord.

Si tu travailles dans un gros studio que tu encadres 20 personnes par contre je dis d'accord.
Mais un projet amateur qui risque d'être inachevé je n'en vois pas trop la pertinence.

A nouveau, à chacun son point de vue. Le mien, c'est: "et sans les documents, irons-nous jusqu'au bout?"

Et puis le secteur du jeu vidéo c'est pas comme pour un projet de gestion le point majeur et essentiel c'est la créativité , le game design.

Ok, mais gérer un projet c'est aussi s'imposer une ligne de conduite. Ce qui ne nuit pas nécessairement à la créativité (d'ailleurs, tous les programmeurs se doivent d'être créatifs, et ce à tout point de vue). Et de plus, pourquoi le jeu vidéo ne pourrait-il pas s'apparenter à une gestion de projet?

Evidemment, et c'est le mot d'ordre selon moi: à quel point un jeu vidéo amateur peut-il être dirigé par un process de gestion entreprise?

Je pense que j'ai peut-être été mal compris, donc je le dis et le répète: cette méthode n'est pas la méthode, c'est un débat afin de voir à quel niveau les deux esprits peuvent se rejoindre, pas seulement de dire "nous sommes des amateurs donc nous n'avons pas le temps pour le formel".

Merci néanmoins de faire avancer ce topic.

Bonne soirée,
valholl

[Nktug]

Voila mon idée perso :

Comme tu l'as cité dans ton premier post Valholl, il existe déjà des sites où l'on peut trouver ce genre de guide "administratif" de démarrage pour la création d'un projet de jeu ou quelconque.

Pourquoi cela ne se séduit pas ? Ne marche pas ?

Moi je pense que cela dépend toujours de l'initiateur du projet.
C'est qu'un développeur n'aura pas forcement la volonté, ni l'expérience pour rédiger des tels documents alors qu'une autre personne plus littéraire pourra te pondre cela sans problème.
Il est vraie également qu'on a trop tendance à passer par des forums sur y mettre ses idées ce qui fini par en faire un beau spaghetti.

Où sont les difficultés ?

Je pense également que tout le monde peut rédiger un document concernant sa vision du projet : "c'est un MMORPG qui fera ceci et cela ...".
Mais il faut être capable en tant que projet AMATEUR de faire avec les moyens du bord ... et les moyens du bord c'est l'expérience des personnes qu'on trouvera sur la toile.
Il y a donc toujours un pallier important entre les idées de départs et sa faisabilité.

Vous allez me dire qu'il faut justement le faire dans des docs techniques mais "on" (initiateur de projet amateur) a toujours un retard en terme de retour d'expérience qu'on a du mal à le faire.

Dans mon projet, on a eu 1ans de réflexion (selon le temps de chacun) pour finaliser les idées et surtout pour trouver des personnes ayant la volonté de surmonter les difficultés.
Il faut le dire ... LE GROS PROBLEMES des projets amateur c'est la difficulté.

= > Tout le monde veut intégrer un projet tout fait ou il y a juste à créer un monde pour dire qu'on y a participé.


Les solutions possibles !

Je considère qu'il ne faut pas chercher à faire des PPT ou des docs poussées.
Juste mettre les informations nécessaire de base pour au moins guider les nouveaux arrivant pour qu'ils aient une idée de l'orientation du projet.

Un autre conseil important : Dés qu'un point de vue est discuté puis validé sur le forum par exemple, il faut impérativement le noter dans votre documentation.

=> Dans mon projet, nous avons mis en place un wiki en parallèle du Forum. De cette manière nous pouvons également contrôler les modifications (un peu comme un versionning)


Mes conseils

1. Avoir des idées générales (vision idéale) mais revoir le tout à la baisse pour surtout avoir du concret et avancer petit à petit.
2. Savoir motiver les gens c'est la clé du survie d'un projet

[3DArchi]

Perso, je rejoint la démarche de valholl. Même dans un projet perso avec 1 ou 2 intervenants, si tu n'utilises pas un minimum de formalisme et de technique de gestion de projet, tu aboutis rapidement à un échec à mi-parcours. Car, sans ce genre de démarche, tu te sens rapidement débordé et la démotivation n'est pas loin...

[kremvax]

Perso, je rejoint la démarche de valholl. Même dans un projet perso avec 1 ou 2 intervenants, si tu n'utilises pas un minimum de formalisme et de technique de gestion de projet, tu aboutis rapidement à un échec à mi-parcours. Car, sans ce genre de démarche, tu te sens rapidement débordé et la démotivation n'est pas loin...

Dans mon cas personnel (celui que je connais le mieux) je ne crois pas que l'échec puisse venir d'un manque de formalisme. Mi-parcours, c'est déjà être allé très loin et je pense que les échecs arrivent généralement bien avant le mi-parcours, quand on remarque qu'on a manqué de lucidité sur certaines choses, qu'on a cherché à mettre la charrue avant les boeufs avec du recrutement à tout va, etc. Je me suis lancé dans un gros projet il y a 2 ans avec une motivation à bloc, seul, aujourd'hui je suis toujours seul dessus avec une motivation toujours à bloc et le projet avance bien, pourtant je n'ai jamais écrit de GDD formel, seulement des pages de brouillon que je mettrai en forme quand je recruterai des artistes. Il faut juste savoir ce qu'on veut, aimer ce qu'on fait et rester lucide. Je pense que dans des petites équipes de 2 à 4 personnes on peut très bien fonctionner ainsi.


Mais en fait, on est dans un faux débat. On ne peut pas dire "telle ou telle méthode est meilleure", car quand on parle d'une équipe de 3 ou 4 amateurs comme dit Nktug on fait avec les moyens du bord, donc si parmi l'équipe il y a des individus plus doués pour le management alors il y aura du managemenent, mais si l'équipe se compose de 2 codeurs et 2 graphistes, leur demander de pondre 5 documents avant de commencer, de faire des rapports d'activité tous les 15 jours etc. ce sera ça la source de démotivation. Bref, on fait avec les compétences qu'on a et vive le système D, c'est ça aussi la beauté de la chose

[Mat.M]

C'est aussi pendant la phase d'étude du planning et d'allocation des ressources (humaines s'entend) qu'on déterminera combien de développeurs on requiert (on ne commence pas avant avec les programmeurs); l

Apparemment je suis un incompris : tu parles d'allocation de ressources c'est bon pour une grosse boite pas pour une petite équipe !
C'est bon pour une start-up ( et encore ! ) qui lève des millions pour un projet pas pour un petit jeu amateur.
Franchement une personne qui va passer son temps pour un projet de jeu vidéo à faire des documents word en tête détaillés paragraphes et sous-paragraphes sera presque considérée comme nuisible parce qu'elle n'apportera rien de concret et ne fera pas avancer le schmilblick.
Sauf si tu as un projet de jeu et que tu vas voir des Buissness-angels là je dis d'accord il faut faire des documents pour faire un buissness plan.
Je suis d'accord qu'il soit nécessaire de formaliser mais juste un simple document texte ( je déteste viscéralement les specs au format word c'est incompréhensible et inbuvable ) suffit.
Pas besoin de se lancer dans une bureaucratie kafkaienne !
Un jeu vidéo c'est un noyau de gens qui vont à l'essentiel un ou des programmeurs qui travaillent sur le noyau et des grahistes qui font les graphismes.
Surtout que il me semble souvent les studios de jeu sont sous pression parce qu'il y a un ou des titres à finir pour Noel.
Bon enfin s'il y a des personnes qui souhaitent se lancer dans une telle démarche après tout elles sont libres de faire ce qu'elles veulent.

Dans mon projet, on a eu 1ans de réflexion (selon le temps de chacun) pour finaliser les idées et surtout pour trouver des personnes ayant la volonté de surmonter les difficultés.
Il faut le dire ... LE GROS PROBLEMES des projets amateur c'est la difficulté.

Un an c'est excessivement trop.
C'est que votre équipe n'a pas de projet précis tout le monde est dans le flou tout le monde veut faire plein de chose pour arriver à rien au final..

[valholl]

Bonsoir (et désolé pour le délai, beaucoup de travail et peu de temps libre),

Je pense qu'il est clair que toutes les écoles se côtoient sur ce sujet. Et je pense aussi que, pour résumer:

Mais en fait, on est dans un faux débat. On ne peut pas dire "telle ou telle méthode est meilleure", car quand on parle d'une équipe de 3 ou 4 amateurs comme dit Nktug on fait avec les moyens du bord, donc si parmi l'équipe il y a des individus plus doués pour le management alors il y aura du managemenent, mais si l'équipe se compose de 2 codeurs et 2 graphistes, leur demander de pondre 5 documents avant de commencer, de faire des rapports d'activité tous les 15 jours etc. ce sera ça la source de démotivation. Bref, on fait avec les compétences qu'on a et vive le système D, c'est ça aussi la beauté de la chose

Je pense que tout est là. Je suis développeur mais pour mon projet perso j'ai abandonné la programmation à d'autres personnes, pas fautes de compétences (quoique je suis peut-être plus doué dans les telecoms que dans les jeux video, allez savoir) mais parce que 1) je voulais gérer le projet dont j'ai imaginé le concept et 2) laisser faire des personnes motivées, qui ont envie d'apprendre, de participer à une expérience de jeu vidéo et qui ont déjà les compétences dans les domaines requis.

Je me permettrai aussi de répéter, comme l'a indiqué kremvax, que c'est "chacun sa méthode", moi je présente mon point de vue en tant qu'employé d'une entreprise.

A l'attention de Mat.M: non tu n'es pas un incompris, je suis d'accord avec ton point de vue, mais je ne serais pas aussi systématique en disant que ce genre de process est seulement bon pour les "grosses boites" comme tu dis. Je travaille dans une grosse boite (qui emploie plusieurs dizaines de milliers de personnes dans le monde) mais je suis dans une petite équipe (nous sommes 3), ce n'est pas pour autant que nous négligeons l'aspect management. Mais soit, nous ne sommes pas ici dans une entreprise, en ce qui me concerne j'ai décidé de gérer mon projet amateur comme une société le ferait, je ne pense pas être nuisible pour autant (à l'inverse, les personnes qui ont rejoint le projet trouvent cela plutôt sérieux).

En bref, j'aurai le mérite d'essayer cette méthodologie sur mon projet, je continue d'avoir mon opinion, que partage visiblement aussi 3DArchi, un bon formalisme bien géré ne prend pas plus de temps que des discussions sans fin quand il n'y en a pas, donc en somme il en faut mais pas trop, il faut faire de la gestion de projet mais pas trop, en clair il ne faut pas tomber dans les extrêmes.

Bien à vous,
valholl