vendredi 6 janvier 2012

Planning prévisionnel

Pour mener un bien un projet, il est nécessaire d'avoir un minimum de visibilité sur les différentes étapes à venir et sur la durée de chaque tâche; c'est le rôle du planning.

Je vous invite très fortement à réaliser un diagramme de Gantt, un outil permettant de visualiser graphiquement l'avancement de votre projet. Il permettra à toute votre équipe de comprendre facilement l'ordonnancement des tâches et d'avoir une idée des deadlines.

  

1/ Commencez par effectuer une liste des tâches à réaliser, par exemple (très grossier):

  • Tâche 1 : Réaliser le cahier des charges
  • Tâche 2 : Développer le jeu
  • Tâche 3 : Faire une phase de test
  • Tâche 4 : Corriger les éventuels bugs découverts pendant les tests
  • Tâche 5 : Lancer le jeu
  • Tâche 6 : Faire la promotion du jeu
Libre à vous de définir la précision de votre planning, par exemple ma tâche numéro 2 (développement) peut facilement être décomposée en plusieurs dizaines de tâches ("développement portail web", "développement interface d'administration", "développement de la fonctionnalité d'attaque", etc.). Pour une vue globale du projet, il est plus simple de s'en tenir à un nombre limité de tâches (sinon cela sera illisible). Vous pouvez ensuite décomposer chaque étape dans un autre document annexe.

2/ Réalisez le chiffrage 

Le chiffrage consiste à affecter à chaque tâche une durée maximale. Par exemple, on va estimer que la tâche n°1 devrait durer 8 semaines et que la tâche n°3 prendra 3 semaines. 

En réalité on réalise normalement le chiffrage en "jour-homme", une unité de mesure qui représente le travail effectué par un homme en un jour. Ainsi une tâche de 10 JH (pour 10 Jours-Hommes) prendra 10 jours si une seule personne y est affectée, mais seulement 5 jours si deux personnes y travaillent (10 JH / 2 Hommes = 5 jours).

Voici le chiffrage de notre exemple :
  • Tâche 1 : Réaliser le cahier des charges -> 8 semaines
  • Tâche 2 : Développer le jeu -> 15 semaines
  • Tâche 3 : Faire une phase de test -> 3 semaines
  • Tâche 4 : Corriger les éventuels bugs découverts pendant les tests -> 2 semaines
  • Tâche 5 : Lancer le jeu -> 1 jour
  • Tâche 6 : Faire la promotion du jeu -> ?
3/ Réalisez votre diagramme

Dans un diagramme de Gantt on représente chaque tâche par une barre dont la taille est proportionnelle à sa durée. On y visualise également les notions de dépendances : par exemple la tâche B ne peut commencer que si l'on a terminé la tâche A auparavant, etc. Dans notre exemple on a la dépendance suivante 1 -> 2 -> 3 -> 4 -> 5. C'est très discutable, car en réalité on peut essayer de paralléliser au maximum en débutant le développement avant la fin du cahier des charges. On va par exemple faire la promotion du jeu (tâche n°6) dès le début des développements.

Si vous n'avez pas de logiciel permettant de réaliser un diagramme de Gantt sous la main, je vous invite à télécharger le logiciel GanttProject (libre) : ici 

Créez vos tâches dans la liste de gauche du logiciel, définissez vos dates, et vous devriez obtenir quelque chose dans ce style :
cliquer pour agrandir
Cette vue nous permet de voir facilement les dépendances entre les tâches et de se projeter dans le temps pour savoir où en sera (en théorie) le projet dans un ou deux mois. C'est un outil de communication très utile et je vous conseille d'en réaliser un (et de le tenir à jour) et de le propager régulièrement au sein de votre équipe.

Gardez à l'esprit que votre planning ne sera probablement pas respecté au jour près, et c'est tout à fait normal. Les imprévus font que les choses ne se déroulent jamais comme prévues au début du projet !

6 commentaires:

  1. Merci beaucoup pour l'idée du diagramme ! :)

    RépondreSupprimer
  2. Je suis moi-même développeur d'un jeu amateur (http://blog.ba-17.com) mais le développement est mon métier. Je ne saurais vous conseiller de ne pas utiliser la méthode décrite ci-dessus.
    Cette méthodologie de gestion de projet dite classique ou en V (période de spécification-validation puis réalisation-test) n'est pas adaptée aux projets informatique notamment les petits.
    Par expérience, il est inutile de tout spécifier avant et de commencer le développement après. Une fois dans le code vous aurez changé d'avis ou vous vous serez rendu compte d'une erreur.
    Pensez plutôt par cycle de 1 semaine à 1 mois dans lesquels vous insérez une liste des tâches les plus prioritaires. Cela vous permettra d'arriver rapidement à un résultat.
    Ceci est un aperçu des méthodes dites agiles et croyez-moi ça change tout.
    Ca va un peu de pair avec un article écrit ici même sur les raisons d'arrêt d'un projet. Le fait d'avoir des deadlines trop lointaines décourage beaucoup...

    RépondreSupprimer
    Réponses
    1. Si cela peut te rassurer, le développement est également mon métier et selon moi la méthode en V est tout à fait appropriée au développement de la première version d'un jeu web. C'est encore plus vrai si l'équipe n'a aucune formation et aucune expérience en développement et en méthodologie car la méthode agile ne s'improvise pas (scrum, XP etc). Se lancer directement du développement sans prendre le temps de bien définir ses specifications c'est prendre le risque de faire n'importe quoi et d'arriver à un résultat chaotique...

      Après, je suis tout à fait d'accord sur le besoin d'un développement itératif APRES la première mise en production, avec des cycles assez courts (1 semaine à 1 mois comme tu dis). Il est alors inutile d'utiliser cette gestion en V (un peu lourde il est vrai) car le périmètre est normalement bien moins ambitieux que celui de la première MEP.

      Pour résumer, je pense que la première version doit se faire en V, en prenant bien le temps de poser le périmètre et ses specs. Puis il convient de faire des petites update fréquente via des itérations.

      En gros je suis d'accord que la gestion en V est "lourde", mais quand on n'y connait rien, je pense que même si cela fait un peu "peur", ça évite d'aboutir à du grand n'importe quoi (notamment au niveau source)...

      Supprimer
    2. Il est vrai que les méthodes agiles nécessitent une grande rigueur d'application sinon c'est la catastrophe assurée. Cependant la première étape de spécification peut être réalisée en méthode agile. On peut très bien lister les étapes de façon macro, les prioriser et enfin détailler la plus prioritaire en tâches.

      Le plus important est d'avoir des retours le plus souvent possible, afin de permettre le changement. Cela évite de constater une incohérence fonctionnelle, une issue technique... trop tard. Il ne sert à rien de spécifier sur le long terme. Vous pouvez être sûr que ça ne se passera pas exactement comme prévu. De toute façon vous ne pouvez pas voir tous les détails fonctionnelles tant que vous ne travaillez pas sur le sujet.

      Je te rejoins par contre pour les personnes sans connaissance particulière en gestion de projet un cycle en V est mieux que rien et surtout plus simple à appréhender (ça se résume à un GANT presque).

      Mon conseil serait de commencer par un cycle en V pour un projet amateur mais sur une planification courte ne dépassant 2 ou 3 mois, voir plus loin de façon détaillée serait trop anticiper.

      Supprimer
    3. Je suis entièrement d'accord avec toi, il ne faut pas voir trop "gros" et se limiter à quelques mois de cycle sur la première version. Certains projets de jeu amateur peuvent durer 2, 3 ans avant la première mise en production et l'équipe a vraiment intérêt à être motivée...

      J'ai d'ailleurs appris récemment l'abandon d'un jeu qui avait l'air vraiment superbe mais malheureusement un poil trop ambitieux. Résultat, un jeu qui ne verra jamais le jour malgré plusieurs années de boulot.

      Et oui, même avec un cycle en V tu reviens souvent sur les specs, pour moi elles ne sont pas du tout figées.

      Commencer par un V avec quelques semaines de specs et quelques mois de dev, mettre en production, puis enrichir via des itérations rapides avec des périmètres limités (quelques semaines de dev max).

      Supprimer
    4. Putain vous parliez déjà d'agile en 2012 et moi je découvre ça que maintenant T_T

      Supprimer