[Article] Parallèle avec la gestion de projet

[Zamentur]

Bonjour à tous,
Donc voilà j'ai suivi récemment un cours sur la gestion de projet. Bien que c'était de la gestion de projet général pour les entreprises et non de projet informatique amateur, il y a certaines choses qui peuvent à mon avis être utile. L'idée étant de présenter des outils je vous laisse ensuite faire à votre sauce.


#Introduction
Pour commencer, on va se demander ce qu'est un projet...
Pour moi, c'est une démarche destinée à obtenir un produit qui n'est pas dans nos habitudes de faire.

Autrement dit çà s'applique tout à fait à un jeu par navigateur, sauf si vous avez déjà réalisé le même type de jeu. En gros dés que vous avez l'expérience et la structure ce n'est plus vraiment un projet. Mais je pense que rares sont ceux qui peuvent prétendre çà; moi même j'ai beau avoir déjà réalisé un jeu en ligne, la nouvelle version étant vraiment très différente je considère avoir besoin d'une organisation projet.

Bon vous me direz jusqu'ici on a pas grand chose c'est pas çà qui va aider à mener à bien son jeu...

#La note de clarification
La note de clarification a pour but d'expliquer de façon synthétique le projet, cette note doit contenir:

• Un nom de projet ne serais ce que temporaire: çà permet de communiquer mais aussi de se donner de la motivation en visualisant le projet; un projet nommé est en quelques sortes un projet que l'on pense concrétiser
  

  Al-Gol

• Le contexte: c'est à dire dans notre cas l'origine du projet, comment les initiateurs en sont arrivé là, la date de naissance du projet(important si vous voulez fêter votre anniversaire), bref sur quel terrain on joue
  

  Valentin a toujours était passionné par la création de jeu virtuel ou non, après divers éssaie et la création dun premier site internet à 15 ans, il a créé Ragol Online avec Leo. Ragol Online était un jeu en ligne développé en PHP, il représente à peu prés 4000 heures de développement. Après 3 ans de jeu, Ragol Online souffrant de divers problèmes (panne d'hébergeur, nombre de joueur en dessous du seuil de jouabilité, problème de maintenance) et une idée de nouvelle version ayant émergé depuis la version alpha, Valentin décide de fermer le jeu estimant trop complexe de corriger les problèmes en maintenant la communauté active. L'idée est donc alors de relancer celle ci une fois la nouvelle version prête et en s'appuyant des acquis du jeu.

• Données d'entrée: il s'agit d'indiquer tous les documents à disposition

  - le wiki d'Al-Gol rassemble de nombreuse note sur le projet de v2
  - le jeu Ragol Online ainsi que sa version alpha PSOFrance rassemble un historique de l'évolution de la première version et permet l'étude des points faible de la première version, il constitue aussi une ressource non négligeable sur le scénario écrit au fur et à mesure du temps par la communauté
  - le forum d'Al-Gol rassemble certaine participation et remarque de joueur impliqué
  - le dépôt subversion contient un prototype du portail d'entrée ainsi que d'un module de gestion de texte avancé
  - un livret de la préfecture sur la création d'association
  - divers graphismes
  - un trailer de présentation
  - les forum jeuweb tour de jeu et créajeu
  - divers documentation technique en ligne

• Objet du projet:Une description synthétique du projet ainsi que la phase dans laquel on se place (etude de faisabilité, avant projet, définition, réalisation)
  

  Le but est de créer la nouvelle version du jeu Ragol Online, en prenant en compte les nombreuses idées amassées durant les 5 dernières années. On se situe au début de la réalisation.

• Produit du projet: on décrit les livrables du projet c'est à dire ce que l'on doit avoir à la fin du projet
  

  - un jeu sur l'univers hérité du jeu Ragol Online
  - une structure capable de porter ce dernier ainsi que sa communauté
  - une stratégie pour obtenir une communauté de joueur actif et prenant part à l'entretient du jeu lui même
  - un portail de présentation de l'évolution passé et futur du jeu (WIP)
  - des ressources pour la création de projet similaire
  - la création de gadget autour (module iphone/firefox, livre dérivé t shirt etc...)

• Objectif: il s'agit d'écrire les objectifs (si possible chiffré) de cette création

  Performance: le jeu doit pouvoir se jouer via un navigateur sans ramer. (si cet objectif n'était pas atteint le jeu serait alors à installer)
  Éthique: le jeu s'assurant au maximum de sa non addiction
  Originalité: le jeu doit se démarquer des autres, il doit pouvoir servir de laboratoire à de nouveau concept interactif (écriture communautaire, web-documentaire, figure de style virtuel etc...)
  Cout: pour le moment Valentin le principal porteur ne souhaite pas un cout supérieur à 1000€.
  Maintenance: un projet pérenne, c'est à dire que le projet devra être en mesure de continuer sa route même si des membres porteurs doivent lâcher le jeu.
  Délais: indéfini pour l'instant, la façon de le faire étant aussi importante que le produit fini.

• Acteur: on décrit les acteurs du projet (partenaire etc...)

  - Maitre d'ouvrage(client): Valentin
  - Maitre d'œuvre(chef de projet):Valentin
  - Équipe de réalisation: Valentin, Sylvain, Mathieu, Thomas
  - Partenaire graphisme: David
  - test, retour et idée: les anciens joueurs, les membres de jeuweb, les participants de SI28

• Conséquence attendue: là il faut définir ce que chacun attends d'un tel projet

  - réalisation d'une passion
  - amélioration des compétences techniques
  - carte de visite dans le monde professionnel
  - reconnaissance du travail comme artistique
  - création de nouveau concept interactif

• Contrainte du projet: les différentes contraintes qu'il va falloir respecter

  - le code devra être sous une licence judicieuse
  - le code doit etre modulable, évolutif et facile à maintenir pendant au moins 6 ans
  - Le projet devra être réalisé à l'aide d'actionscript et de PHP
  - un serveur dédié doit pouvoir faire jouer au minimum 500 joueurs
  - doit être créé sur le temps libre
  - pas de sacrifice possible pour passer sur un modèle payant

• une date un numéro de version et les auteurs du document:

  Valentin le 12/01/2010 version 1

Voilà avec une tel note vous devriez être capable de communiquer avec les différents membres de votre équipe, sur ce que vous comptez faire. Ça permet d'être sur que tous le monde à la même vision du projet. Et si vous êtes seul çà permet de se poser certaines questions que l'on a tendance à oublier.

#L'organigramme produit
Bon alors c'est simple l'organigramme produit permet de structurer votre projet en sous projet. En l'occurrence pour un jeu en ligne j'aurrai tendance à en faire 2: un pour le jeu en ligne proprement dit, et un autre pour l'ensemble du projet.

Voici donc un organigramme global du projet Al-Gol ou le but est justement de en rien oublier:


Et là un organigramme du jeu:


#Le système d'information
Bon sous ce nom pompeux se cache un trucs simple: l'outil qui vous permet de gérer vos documents, codes etc...

Pour bien faire cet outil devrait être en mesure de:

• garantir l'intégrité de vos données (que ce passe t'il si votre disque dur plante? si vous faites une fausse manip, si vous êtes inondé(cas extrêmes))
  
• gérer des meta données qui a créé le fichier, quand, historique
  

Bref il faut définir un trucs et être conscient des risques associés, à titre d'exemple quand j'ai créé Ragol il y a eu un jour une panne de 6 mois de l'hébergement ftp. J'avais ainsi perdu environ 1000 heures de programmation (il n'y avait pas que ragol).

Ce que je conseil c'est d'utiliser un système de gestion de version (subversion ou git par exemple). l'avantage c'est que grâce à çà vos donnée sont dans 2 lieu distinct et vous avez un historique des modifs. Pour la doc on peut aussi utiliser un wiki, mais attention à sauver les données!

Sinon un trucs que j'aime bien c'est organiser les fichiers selon l'organigramme produit, çà permet à tous le monde de se repérer rapidement.

#Le processus de déroulement de projet
Le processus de déroulement de projet à pour but d'identifier les grandes phases d'avancement de projet.
Dans le cadre d'un jeu en ligne on peut par exemple y voir des étapes de création, de betatest, de communication/référencement etc...

Il peut être avantageux d'indiquer des dates ou à défaut des temps de travail.

#L'analyse des risques
Il existe des nombreuses méthodes pour faire l'analyse des risques. Ici je présente un trucs qui me semble adapté, çà se décompose en 3 étapes:

• Lister les risques: le but étant d'imaginer tous les problèmes que l'on pourrait rencontrer

  • perte des données du projet
    
  • manque de ressource
    
  • erreur dans la conception du jeu
    
  • problème d'hébergement du projet
    
  • problème d'hébergement du jeu
    
  • perte de motivation
    
  • problème de copyright
    
  • bug trop fréquent
    
  • perte de l'essentiel
    

  NB: il faut essayer d'être le plus exhaustif possible, même si la définition de l'imprévu c'est justement que ce n'était pas prévu.
  
  
• Classer les risques: pour çà on va donner une note (1, 3 ou 9) à 3 composantes Gravité, probabilité d'Apparition, probabilité de non Détection

  G x A x D
  

  1. erreur dans la conception du jeu 9x3x9=243
     
  2. pertes de vue de l'essentiel 3x3x9=81
     
  3. bug trop fréquent 9x3x3=81
     
  4. perte de motivation 9x3x1=27
     
  5. manque de ressource(temps compétence) 3x9x1=27
     
  6. perte des données du projet 9x1x1=9
     
  7. problème d'hébergement du jeu 9x1x1=9
     
  8. problème de copyright 9x1x1=9
     
  9. problème d'hébergement du projet 1x3x1=3
     

• Explorer les plus critiques: ici l'idée est de chercher les causes du risques, ses conséquences et surtout les mesures possibles pour les prévenir

  #Erreur dans la conception du jeu
  Cause: pas assez de réflexion, oublie d'une composante, supposition erroné
  Conséquence: jeu pas assez attractif, mauvaise jouabilité, augmentation du temps de maintenance
  Recherche de solution: analyser suffisamment le projet, soumettre le projet aux avis extérieurs à chaque étape d'avancement
  
  #Pertes de vue de l'essentiel
  Cause: concentration de l'équipe sur des point trop précis (documentation, recherche du code parfait etc...), non classification des taches par ordre d'importance
  Conséquence: allongement de la date de sortie du projet, obsolescence des technologie lors de la sortie
  Recherche de solution: Tris des fonctionnalités par ordre d'importance, planification du temps passé par tache à défaut de temps en date
  
  #Bug trop fréquent
  Cause: Hypothèque sur la modularité du code, période test trop courte ou test absent
  Conséquence:mauvaise image du jeu, agacement des joueurs, problèmes de triche
  Recherche de solution: mise en place de test unitaire, procédure de test avant passage en production même pour les patchs
  
  #Perte de motivation
  Causeentiment d'impossibilité de réussite, déception sur la qualité, manque d'émulation
  Conséquence: arrêt ou ralentissement du projet
  Recherche de solution: avoir toujours un partenaire ou interlocuteur pour discuter du projet, développement itératif afin d'obtenir des choses à tester
  
  #manque de ressource(temps compétence)
  Cause: trop d'engagement autre pour continuer le projet, départ d'un coéquipier
  Conséquence:Non aboutissement du projet ou ralentissement
  Recherche de solution: recherche de coéquipier, inclusion de partie de projet dans le cadre de cours, appel à professionnel

Alors évidement dans l'exemple les valeurs sont adaptés à Al-Gol, vous ne trouverez surement pas les même risques ni les mêmes criticités associées

#La Planification
Bon déjà la planification c'est pas du tout évident car c'est pas comme dans des cas école ou on vous donne une liste de tache avec les durées de réalisation de ces dernières et leurs contraintes.
A partir de ce genre de liste on peut effectivement déduire si on peut etre en retard sur une tache ou non sans impacter le projet et tracer un Gant permettant de visualiser le projet.
Je pense que faire une tel liste pour un projet amateur c'est très dure. Et si c'est possible je pense qu'il faut indiquer le temps en temps passé et non en date de l'année. Ainsi on peut voir si on y passe plus de temps que prévu.

Il est toutefois possible de fixer des objectif daté pour se motiver.

Si vous êtes capable de définir une tel liste la méthode PERT peut vous intéresser.

#Le développement itératif
Bien souvent on entend sur ce forum, définis d'abord ce que tu veux faire et ensuite passe à la programmation. Bien souvent, je suis en accord avec cette remarque car elle concerne une petite partie du jeu et que le créateur ne sait pas comment avancer parce qu'il n'a pas pris le temps de réfléchir à ce qu'il voulait arriver.

En prenant cette remarque à la lettre on pourrait définir complètement et de façon approfondie son jeu et ensuite passer au code. C'est ce qui s'appelle un développement en cascade, le problème c'est que de nombreux projets pro adoptant cette démarche échoue. La raison est simple c'est que çà prend énormément de temps et qu'au final on a rien de concret, en plus on peut avoir conçut quelques choses d'inadapté ou de trop conséquent par rapport à l'utilisation qui en sera faite. Et bien sur çà on ne s'en rend compte que quand on fait les tests...

Voilà pourquoi de nombreux chefs de projet informatique conseillent d'adopter une méthode de développement itérative. En fait l'idée c'est de faire une succession de développement en cascade, chacun devant aboutir à quelques chose de testable. Cela permet ainsi d'avoir des retour et de redresser la barre en cas de problème.

Évidement au début on sera quand même plus dans la définition qu'à la fin, de même le produit testable peut n'être qu'un simple test nécessaire à la poursuite du projet.

Notez que pendant une itération il ne s'agit pas d'avancer globalement sur le jeu, mais d'avancer sur quelques points précis. Pour décider quel points sont à explorer, il est conseiller de regarder pour chaque points:
- la dépendance des autres modules
- le risque (utilisation d'une technologie inconnue, partie sensible d'un programme etc...)

Ce choix se fait donc au début de l'itération et en tenant compte des résultat et retours des itérations précédentes.

Dans le milieu pro une itération classique est censé durer de 3 semaines à 3 mois selon le projet. Je vous laisse juger de la durée de vos itérations mais un projet contient au moins une dizaine d'itération sinon çà devient du développement en cascade et vous risquez de retomber dans les travers cité précédemment.

Pour en savoir plus, voici un article sur le processus unifié

#Mise au point avec l'équipe
Pour que vous n'ayez pas de problème d'équipe et aussi pour que le projet avance vous devrez sans doute prévoir des réunions pour discuter de votre projet. A moins bien sur que vous ne codiez dans la même pièce mais çà arrive rarement dans les projets amateurs.
Lors de ces réunions il faut s'assurer que tous le monde à ses raisons de continuer et s'épanouit dans ce qu'il fait, ainsi vous garderez plus facilement votre équipe entière.
Comme dit précédemment une réunion à chaque itération semble plutôt une bonne idée afin d'avoir le retour de tout le monde. Pendant cette réunion il faut choisir les points à explorer et démarrer la phase de définition associé.

Évidement, tout çà est simple à écrire mais c'est un peu plus complexe à mener: bien souvent on se disperse. C'est là ou çà peut être utile de faire un ordre du jour afin de bien voir ce qu'il reste à faire dans la réunion et de laisser la parole à tous.

Sinon, il y aura des moments dans la définition ou il faudra laisser cours à la créativité, un outil simple comme le brainstorming peut éventuellement aider. Pour Al-Gol on en avait par exemple fait un sur la problématique à quoi peut ressembler la manipulation de l'iphone du futur, on en ait arriver à l'idée de la puce cérébrale et des neurones.

Dans certains cas, vous ne pouvez pas faire de réunion physique. Je sais de quoi il s'agit pour avoir mener à bout Ragol avec un gars rencontré sur un autre jeu en ligne. C'est pas grave aujourd'hui webcam, chat, et présentation en ligne permettent largement de s'organiser. Vous pouvez compléter grâce au mail et forum.
Je n'ai qu'un conseil si vous êtes plus de 2 sur un chat texte il vaut mieux que l'un des membres anime la réunion en donnant la parole sinon c'est vite complexe.
Ne perdez cependant pas de vue qu'il peut être utile de se rencontrer IRL ne serais ce que pour se connaitre.

Enfin le fait de coder seul chez vous de votre coté ne vous empêche pas d'utiliser un chat vocal en même temps, non seulement çà permet d'avancer plus vite mais en plus çà améliore la motivation.

#Conclusion

Si vous voyez des choses à compléter, je souhaite que ce tuto soit participatif, je n'ai sommes toutes que peu d'expérience dans la gestion de projet. Je pense qu'il faudrait notamment un point sur la gestion de bénévole.

Et surtout j'espère que çà vous aidera à analyser la situation selon votre projet et éviterai de tomber dans les pièges.
NB: j'ai pris comme exemple mon projet Al-Gol, si par hasard vous voyez des points qui cloche merci de me le signaler sur mon wip

[Vorkosigan]

De maniere generale, organiser les choses dans sa tete... ca aide (h) donc faire toutes ces choses ne peuvent qu'aider.
Maintenant, j'aurais tendance a dire que la gestion de projet a tendance a generer beaucoup de paperasse la plupart du temps pour pas grand chose. Documenter c'est bien, faire de la paperasse non. Et dans le cas d'un jeu en ligne amateur... c'est encore pire.

Par ailleurs dans le cas d'un jeu benevole, beaucoup de choses ne sont pas figees ou figeables... En plus c'est un projet essentiellement solitaire meme si d'autres personnes interviendront certainement. En general les gens avec qui tu finiras ne seront pas ceux avec qui tu auras commence. Donc en gros je pense que les regles different de projets professionnels.

Le Nom : c'est une bonne idee de nommer les choses

Le Contexte : normalement tous les participants a ton projet connaissent le contexte...

Les Donnees d'entrees : C'est a mon avis aussi une perte de temps de lister ca.

L'objet du projet : C'est indispensable

Le Produit du Projet : Mouif... Le Produit Numero 1 c'est le jeu... Le reste ne me semble pas necessaire.

Objectifs : Indispensable.

Acteurs : C'est la qu'on atteint les limites d'un projet realise dans son temps libre. Dans un projet normal il faut s'assurer d'avoir toutes les ressources pour realiser ce projet. Dans notre cas non. Les gens arrivent et repartent, avoir un graphiste au debut du projet ne garantit pas d'en avoir un 3 mois plus tard quand on en aura besoin. Les autres pareil. La ressource numero 1 c'est toi, les autres peuvent changer. Il te faut plutot chercher les ressources quand tu en as besoin.

Consequence attendue : Chacun aura ses objectifs... et les lister peut etre utile, ou non. Ce qui est le plus important c'est ce que tu souhaites faire, toi.

Contraintes du Projet : C'est souvent bien de les lister... mais en l'occurence pas celles que tu as listees. :heuuu: Disons qu'elles n'apportent pas grand chose

Pour le reste, j'ai deja des remarques sur quelques points que tu as prevu d'aborder...

L'avancement en cascade : je ne sais pas si tu parles de developpement iteratif ou de cycle en V. Mais en ce qui me concerne je suis persuade que ce qui convient mieux a notre domaine, c'est l'iteratif ou l'extreme programming. L'iteratif permet d'avoir rapidement quelque chose de presentable, de demontrable, de maintenir la motivation de l'equipe, d'avoir des retours... L'extreme programming est plus souple.

Enfin bonne continuation

[Zamentur]

De maniere generale, organiser les choses dans sa tete... ca aide (h) donc faire toutes ces choses ne peuvent qu'aider.
Maintenant, j'aurais tendance a dire que la gestion de projet a tendance a generer beaucoup de paperasse la plupart du temps pour pas grand chose. Documenter c'est bien, faire de la paperasse non. Et dans le cas d'un jeu en ligne amateur... c'est encore pire.

Par ailleurs dans le cas d'un jeu benevole, beaucoup de choses ne sont pas figees ou figeables... En plus c'est un projet essentiellement solitaire meme si d'autres personnes interviendront certainement. En general les gens avec qui tu finiras ne seront pas ceux avec qui tu auras commence. Donc en gros je pense que les regles different de projets professionnels.

Je suis d'accord que la paperasse ne sert à rien, mais là il s'agit pas de çà il s'agit de checker son projet pour éviter d'en oublier une partie (et çà arrive très souvent dans le cadre des jeu en ligne)
Sinon un jeu en ligne n'est pas forcément solitaire, il y a quand même pas mal d'équipe. Et si l'équipe n'est pas fixe c'est une raison de plus pour avoir des documents clairs.

Le Contexte : normalement tous les participants a ton projet connaissent le contexte...

Oui et non, par exemple David qui m'a fait quelques graphismes ne connaissait pas du tout le projet. Il m'a fait des graphisme en échange d'un book, et donc pour lui c'est important de savoir çà pour se faire une idée.

Le Produit du Projet : Mouif... Le Produit Numero 1 c'est le jeu... Le reste ne me semble pas necessaire.

Je ne suis pas d'accord la plus part de nos projet implique une communauté. Et pourtant beaucoup de gens se présente ici sans même se poser la question sur la façon de créer cette communauté.
On vois aussi trop souvent des projet qui ne prennent pas en compte le fait qu'il faudra ensuite animer le jeu et le maintenir
Pour le reste, çà dépend du projet, j'ai pris comme exemple Al-Gol du coup j'ai précisé ce que çà implique, je me doute que la plus part n'ont pas pour objectif de tester de nouveau concept

Acteurs : C'est la qu'on atteint les limites d'un projet realise dans son temps libre. Dans un projet normal il faut s'assurer d'avoir toutes les ressources pour realiser ce projet. Dans notre cas non. Les gens arrivent et repartent, avoir un graphiste au debut du projet ne garantit pas d'en avoir un 3 mois plus tard quand on en aura besoin. Les autres pareil. La ressource numero 1 c'est toi, les autres peuvent changer. Il te faut plutot chercher les ressources quand tu en as besoin.

C'est pas tout à fait vrai, déjà parce qu'il y a des vrai équipes du coup plusieurs personnes à indiquer. Par ailleurs la note de clarif peut être mise à jour, donc si quelqu'un s'en va on enlève et c'est tout
Enfin on peut toujours faire appel à un pro pour réaliser une partie...

Contraintes du Projet : C'est souvent bien de les lister... mais en l'occurence pas celles que tu as listees. :heuuu: Disons qu'elles n'apportent pas grand chose

Je suis d'accord là j'avais pas trop de contraintes en vue, mais je tenais à ce qu'il y ai l'item contraintes

[Vorkosigan]

Je suis d'accord que la paperasse ne sert à rien, mais là il s'agit pas de çà il s'agit de checker son projet pour éviter d'en oublier une partie (et çà arrive très souvent dans le cadre des jeu en ligne)

Une partie de quoi ? Une partie de l'equipe (style "il manque un graphiste") ? Ou une partie des specifications ?
Ce que je voulais dire c'est qu'autant avoir de bonnes specs voir un bon design sont important... autant decrire des choses comme le contexte ou les acteurs, ca me semble inutile et trop de boulot.

Sinon un jeu en ligne n'est pas forcément solitaire, il y a quand même pas mal d'équipe. Et si l'équipe n'est pas fixe c'est une raison de plus pour avoir des documents clairs.

Oui il y a beaucoup d'equipes... mais leur caracteristique numero 1 sont leur instabilite. Il y a quelques exceptions, surtout si l'objectif est de monter un truc pro... mais la plupart du temps, il y a une voire maximum 2 personnes permanentes. Les autres sont de passage.

Oui et non, par exemple David qui m'a fait quelques graphismes ne connaissait pas du tout le projet. Il m'a fait des graphisme en échange d'un book, et donc pour lui c'est important de savoir çà pour se faire une idée.

Mouif... ce qui est plus important pour lui c'est de connaitre le theme du jeu et l'univers de ton jeu, non ? Lui dire que tu as cree une premiere version du jeu il y a 15 ans mais que le serveur c'est casse la figure... euh comment dire c'est peut-etre pas indispensable non ?

Je ne suis pas d'accord la plus part de nos projet implique une communauté. Et pourtant beaucoup de gens se présente ici sans même se poser la question sur la façon de créer cette communauté.

La plupart du temps, la communaute est une consequence, pas une partie du projet car tu ne peux pas garantir qu'elle aimera ton jeu.

Je suis d'accord là j'avais pas trop de contraintes en vue, mais je tenais à ce qu'il y ai l'item contraintes

OK

-----------------------------
Au passage je ne dis pas que ton cours de gestion de projet est nul ou pourri, juste que dans la gestion de projet il faut savoir ce dont on a besoin. On peut tout prendre mais ca nous prendra un temps fou, et je doute que ton chef apprecie que tu passes 200 jours sur un projet avec 120 jours de doc ou de maintenance de doc.
Et dans les jeux en ligne amateurs, la problematique est la meme... tu n'as pas de chef certes, mais tes ressources (personnes, temps, motivation) sont limitees. Et il vaut mieux aller a l'essentiel rapidement.

Enfin tu verras avec le temps, lorsque j'ai commence a faire de la gestion de projet, j'etais un peu extremiste... et sincerement ce que je pronais donnait plus de resultats que ce qui se passait sans moi... mais petit a petit on a rendu les choses moins lourdes et plus efficaces.

[Ter Rowan]

Quelques remarques :

Valentin a toujours était passionné par la création de jeu virtuel ou non, après divers éssaie et la création dun premier site internet à 15 ans, il a créé Ragol Online avec Leo. Ragol Online était un jeu en ligne développé en PHP, il représente à peu prés 4000 heures de développement. Après 3 ans de jeu, Ragol Online souffrant de divers problèmes (panne d'hébergeur, nombre de joueur en dessous du seuil de jouabilité, problème de maintenance) et une idée de nouvelle version ayant émergé depuis la version alpha, Valentin decide de fermer le jeu estimant trop complexe de corriger les problèmes en maintenant la communauté active. L'idée est donc alors de relancer celle ci une fois la nouvelle version prête et en s'appuyant des acquis du jeu.

L’un des points importants de ton contexte est « les divers problèmes ». A mon sens il faudrait les détaillés plus, les explications devraient être poussés ici :
Quelle type de panne, nombre du joueur en dessous mais depuis le début ou essoufflement ?, quels problèmes de maintenance (code ? backgroud ? « help desk » ? ^^)
Je pense comme toi que l’aspect communautaire peut pour certains jeux, être une composante, une fonctionnalité, importante du jeu (dans le sens pas de communauté = pas de jeu). Ca dépend complètement du jeu, du coup précise le contexte (communauté trop petite, ou trop inactive, ou trop d’insultes de k12, etc…)

Cette note doit donner un sens au projet (de la même manière en management on a une note qu’on appelle note de sens, qui se rapproche fortement) Le contexte doit montrer les problématiques du passé, sur lesquelles tu appuieras l’objet et les fonctionnalités de ta cible (tu démontres la cohérence de ta démarche)

[

Le but est de créer la nouvelle version du jeu Ragol Online, en prenant en compte les nombreuses idées amassées durant les 5 dernières années. On se situe au début de la réalisation, l'équipe adopte depuis peu une démarche par prototype issue de la méthode UP.

Vire la seconde phrase, l’objet n’est pas d’appliquer/tester/réaliser un POC de la méthode UP. L’objet est de réaliser un jeu. Enrichie par contre des fonctionnalités très fortes ( 2 – 3) genre Jeu de rôle, de plateau, d’élevage, s’appuyant sur une communauté ( si la communauté est un besoin dans ton jeu et non une conséquence) etc..

- un jeu sur l'univers hérité du jeu Ragol Online
- {non c’est une contrainte} une structure capable de porter ce dernier ainsi que sa communauté
- {ajouter ‘une stratégie pour obtenir’ le livrable n’est pas la communauté, ce n’est pas l’équipe projet qui la forunité} une communauté de joueur actif et prenant part à l'entretient du jeu lui-même
- {ajouter ‘les outils nécessaires au fonctionnement de la communauté : forum ….’ A toi de voir lesquels}
- {non c’est une contrainte} un code modulable, évolutif et facile à maintenir pendant au moins 6 ans
- {non c’est un objectif} un projet pérenne, c'est à dire que le projet devra être en mesure de continuer sa route même si des membres porteurs doivent lâcher le jeu.
-{non c’est une contrainte ou un objectif :/} un jeu s'assurant au maximum de sa non addiction
- des ressources pour la création de projet similaire
- {non c’est un objectif} un jeu pouvant servir de laboratoire à de nouveau concept interactif (écriture communautaire, web-documentaire, figure de style virtuel etc...)
- {non c’est une contrainte} un code sous une licence judicieuse
- la création de gadget autour (module iphone/firefox, livre dérivé t shirt etc...)

Tu constateras que pour moi il y a bien peu de produits attendus mais c’est normal, soit tu rentres plus dans le détail du jeu (liste des fonctionnalités majeures), soit tu restes à un niveau générique, j’ai juste rajouté dans les produits les outils communautaires (mais peut être sont ils inclus dans le jeu

{non c’est une contrainte, l’objectif pourrait être ‘plus rapide que le marché’ et encore on pourrait discuter, là tu es juste dans une utilisation standard donc pas un objectif – a moins que tu décides d’ouvrir si cela rame} Performance: le jeu doit pouvoir se jouer via un navigateur sans ramer.
Originalité: le jeu doit se démarquer des autres
Cout: pour le moment Valentin le principal porteur ne souhaite pas un cout supérieur à 1000€.
Délais: indéfini pour l'instant, la façon de le faire étant aussi importante que le produit fini.

- Maitre d'ouvrage(client): Valentin
- Maitre d'œuvre(chef de projet):Valentin
- Équipe de réalisation: Valentin, Sylvain, Mathieu, Thomas
- Partenaire graphisme: David
- test, retour et idée: les anciens joueurs, les membres de jeuweb, les participants de SI28

- réalisation d'une passion
- amélioration des compétences techniques
- carte de visite dans le monde professionnel
- reconnaissance du travail comme artistique
- création de nouveau concept interactif

Je ne sais pas trop quoi dire sur ce point. A mon sens c’est important mais ça ne doit pas être la liste de ce que chacun attend mais plutôt ce que tous doivent trouver

- Le projet devra être réalisé à l'aide d'actionscript et de PHP
- un serveur dédié doit pouvoir faire jouer au minimum 500 joueurs
- doit être créé sur le temps libre
- pas de sacrifice possible pour passer sur un modèle payant

Bah les contraintes en plus sont dans les autres modules

Valentin le 12/01/2010 version 1

Bon il est tard je continuerais çà à un autre moment, je prévois notament de parler de:

• processus de déroulement de projet
  
• d'analyse des risques
  
• peut être de Planning (au moins à partir de la beta de communication)
  
• des dangers de l'avancement en cascade
  
• et peut être de certains outils de réunion virtuel ou non
  

J’attend la suite

A noter sur une prestation informatique industrialisée standard le temps de développement représente moins de 50% des charges d'un projet, le pilotage entre 15 et 20, le reste étant entre la documentation et les tests. Donc ne pas se décourager sur ces points

[Zamentur]

La plupart du temps, la communaute est une consequence, pas une partie du projet car tu ne peux pas garantir qu'elle aimera ton jeu.

Le jeu et la communauté sont très liè certes, mais je ne pense pas qu'il faille uniquement se baser sur la qualité du jeu. Du moins je suis persuadé qu'il faut au moins une fois penser de ce point de vue.
Comment vais je faire venir des gens?
Pourquoi les gens vont jouer?
Pourquoi ils ne joueraient pas?
Est ce que je compte uniquement sur la qualité de mon jeu, pour créer ma communauté?
Ai je prévu qu'il faudra passer du temps à animer cette communauté?

Au passage je ne dis pas que ton cours de gestion de projet est nul ou pourri, juste que dans la gestion de projet il faut savoir ce dont on a besoin. On peut tout prendre mais ca nous prendra un temps fou, et je doute que ton chef apprecie que tu passes 200 jours sur un projet avec 120 jours de doc ou de maintenance de doc.
Et dans les jeux en ligne amateurs, la problematique est la meme... tu n'as pas de chef certes, mais tes ressources (personnes, temps, motivation) sont limitees. Et il vaut mieux aller a l'essentiel rapidement.

Enfin tu verras avec le temps, lorsque j'ai commence a faire de la gestion de projet, j'etais un peu extremiste... et sincerement ce que je pronais donnait plus de resultats que ce qui se passait sans moi... mais petit a petit on a rendu les choses moins lourdes et plus efficaces.

Bon comme j'ai dit ici, je présente des outils, libre à vous ensuite de les adopter. J'ai pas dit que je les appliquais tous(en même temps les plus gros projet pro que j'ai fait ont duré 2 mois). Mais bon je parle pas d'y passer 120 jours là, l'ensemble de la démarche est faisable en 2 à 4h, sans le planning (car là çà dépend un peu du besoin).

Ça va paraitre idiot mais j'aurais suivie çà pour Ragol (4000 h de code+ 1000h d'animation), ben j'aurais peut être gagné 1000 heures. Donc çà peut valoir le coup, on ne peut pas dire que ma note de clarification soit si complexe que çà à rédiger (moi çà m'as pris 1h avec les explications de la partie en plus)

[Vorkosigan]

Le jeu et la communauté sont très liè certes, mais je ne pense pas qu'il faille uniquement se baser sur la qualité du jeu. Du moins je suis persuadé qu'il faut au moins une fois penser de ce point de vue.
Comment vais je faire venir des gens?
Pourquoi les gens vont jouer?
Pourquoi ils ne joueraient pas?
Est ce que je compte uniquement sur la qualité de mon jeu, pour créer ma communauté?

Ton jeu est similaire a une creation artistique... le succes n'est jamais garanti et ne se calcule pas a mon avis. Bien sur il faut prevoir du temps pour faire de la pub mais son succes ou non n'est pas maitrisable.

Ai je prévu qu'il faudra passer du temps à animer cette communauté?

Ca me semble evident qu'il faut prevoir du temps pour la maintenance du jeu, repondre aux questions des joueurs... voire plus.

Ça va paraitre idiot mais j'aurais suivie çà pour Ragol (4000 h de code+ 1000h d'animation), ben j'aurais peut être gagné 1000 heures. Donc çà peut valoir le coup, on ne peut pas dire que ma note de clarification soit si complexe que çà à rédiger (moi çà m'as pris 1h avec les explications de la partie en plus)

Mouif... ca vient peut-etre de ton inexperience en gestion de projet avant Ragol. C'est vrai qu'il y a en effet beaucoup de choses evidentes auxquelles on ne pense pas au debut.
De mon cote il y a quelques annees je gerais des projets de R&D plus de l'ordre de 14-20 Homme-Mois et lorsqu'il y avait une modification majeure a apporter au projet je me retrouvais a devoir modifier une dizaine de documents... C'est tres lourd.
Puis ma boite est passee au modele CMMI et ca s'est grandement ameliore :good: On a vire plein de documents... et on est devenus plus efficaces aussi bien lors du developpement que lors de la maintenance.

La je fais des audits sur des projets industriels beaucoup plus consequents et le principal probleme rencontre est la doc non a jour...

Enfin tu verras avec le temps de toutes manieres. Un peu de gestion de projet c'est toujours mieux que rien du tout

[Zamentur]

Bon j'ai pris en compte vos remarques, notamment concernant produit/objectif et contrainte j'avais aussi le pré-sentiment que c'était pas top ce que j'avais mis.

Ca me semble evident qu'il faut prevoir du temps pour la maintenance du jeu, repondre aux questions des joueurs... voire plus.

Et pourtant beaucoup de créateur débutant considère qu'ils passeront plus de temps à créer leurs jeu qu'à l'administrer. Comme si la phase de production n'existait pas...

C'est pour çà que je met çà, en fait c'est pour çà que je fais cet article. Un jeu en ligne c'est assez vaste et on a tendance a tellement se concentrer sur sa création qu'on en oublie le reste qui même si il demande moins de temps demande d'être fait. Et je dis pas çà uniquement parce que moi j'ai oublié des trucs sur Ragol, je le dis parce qu'on le voit beaucoup sur ce forum.

[Vorkosigan]

Et pourtant beaucoup de créateur débutant considère qu'ils passeront plus de temps à créer leurs jeu qu'à l'administrer. Comme si la phase de production n'existait pas...

Sur le forum il y a quand meme un paquet de rigolos qui ne connaissent pas grand chose aux jeux en ligne ou a la programmation... mais je ne pense pas que cela soit vraiment un probleme pour eux de ne pas bien apprehender la phase de production car je doute qu'ils y arrivent :non:
ahahaha

[Zamentur]

Et pourtant à bien y réfléchir, quand j'ai commencé Ragol avec Léo j'étais "un rigolo". J'avais juste réalisé un petit trucs en php qui permettait de créer des recettes de cuisine.

Je savais pas ce qu'étais une session, ni qu'on pouvait faire des images en php. Et pourtant à force de persévérer j'y suis arrivé. En partie parce qu'à raison je croyais que j'avais mes chances de réussir.
Et je pense qu'à première vu comme çà beaucoup ici n'aurait pas cru en mes chances.

Et quand j'y regarde aujourd'hui je me dis que pour un jeu en ligne ceux qui ont le plus de chance d'aboutir ne sont pas forcément les plus compétents. Bien sur çà joue mais la motivation et la disponibilité sont tout aussi importante.