Discussion :

[mathieu]

Bonjour,

Je viens bientôt commencer un projet assez important (je développe seul) et j'ai du mal à définir une durée ce qui embête mon patron. En discutant avec cougar2 par message privé je lui ai demandé s'il connaissait un logiciel de gestion de projet qui pourrais m'aider à m'organiser et il m'a répondu cela :

Pour la gestion de projet, il y a bien longtemps que je n'utilise plus de logiciel...
Aujourd'hui nous décomposons chaque projet en page utilisateur. Nous donnons à nos clients un nombre de jour de dev par page.
Chaque page doit être validée pour passer à la page suivante...
Je me suis aperçu que les clients/utilisateur déviaient sans arrêt du cahier des charges initial c'est pour cela que je préfère cette solution.
De plus, sur de long projets, le client aime bien voir quelque chose même si ce n'est pas global... ça le rassure !
C'est assez basique comme solution mais bon ...
J'ai toujours en mémoire le souvenir de notre plus gros client qui ne voyant rien venir (on avançait pourtant bien sur toute l'analyse/schémas des bases etc ... mais rien de visuel) a annulé sa commande !
Bien souvent, dans la gestion du temps sur un projet, on est en retard parce que le client n'a pas validé une étape. Mais on a la tracé de nos demandes et les dates de ses réponses ... C'est un paramètre que l'on intègre dans le calcul du temps nécessaire...

Désolé donc, je ne connais pas de bon soft de gestion de projet.

avec mes précédants projets j'ai déjà remarqué que les clients ont tendance à demander toujours plus s'il n'y a pas de limite claires donc j'ai penser organiser ça de la façon suivante :
1)réalisation du design de toutes les vues de l'application
2)validation du design par le client
3)et après seulement commencer le développement

Mais la méthode de cougar2 m'a aussi séduite donc j'aimerais connaître votre avis et votre expérience sur ce sujet. Et surtout comment travailler efficacement avec le client sans abuser de son temps en lui présentant des trop petits bouts ?

[grafikm_fr]

Bon,

Ce que je vais dire peut paraitre basique, mais vu le nombre de fois où ca a pas été respecté lors d'un projet, vaut encore mieux le dire...

En fait, tu as tres grosso modo deux facons de faire:

1) Une fois que le cahier des charges a été défini, tu te fais un petit graphe d'ordonnancement. Pas besoin de logiciel, du papier quadrillé (millimetré de preference) et des crayons suffisent...
Tu aboutis à un diagramme GANTT d'avancement et là tu determines le chemin critique

Avantage: formalisé, rigoureux etc. Le client peut également avoir un aperçu du logiciel (maquette)
Inconvenient: suivant le type du soft, il se peut que le client ne voie pas de résultat avant un bout de temps, ce qui peut eventuellement le mettre en rogne. C'est au chef de projet de gerer ca...

2) La deuxieme méthode c'est de raisonner par un developpement en spirale. On pond un premier proto, on le valide, on passe les modif, on fait un bout en plus, ca fait le deuxieme proto qu'on valide etc...

Avantage: Le client voit l'avancement au fur et à mesure.
Inconvenient: Pour peu que tu sois bordelique dans tes dev (comme moi quoi), tu regretteras très rapidement cette méthode.

Globalement, la méthode a utiliser depend énormement du langage.
Pour un bon RAD comme VB ou Delphi (et un peu moins .NET), la méthode 2) est bien mieux. Par exemple, c'est très facile en VB de dessiner l'interface bien avant d'avoir pondu 1 seule ligne de code.

En revanche, si tu codes dans un environnement lourd et chiant du style JAVA/C++/C#/J2EE et j'en passe, la 1ere méthode est vivement conseillée si on ne veut pas aboutir un fatras incompréhensible de modifs et de révisions... (à moins d'utiliser un truc comme CVS naturellement).

Dans tous les cas, je ne pense pas (à moins que ton prog soit vraiment très gros) qu'il y ait besoin de logiciel. Une feuille de papier suffit...

{edit} Concernant le taf avec le client, c'est une question de feeling. Profite de la réunion de lancement pour bien sonder le terrain. Ca devrait te fournir les éléments necessaires pour opter pour l'une ou l'autre des méthodes...{/edit}

Voila, ce n'etait que mon avis mais bon...
grafikm_fr[/b]

[Erwy]

M'ouis d'experience, montrer ne serait qu'un enchainement d'interface(meme avec des donnees codees en "dur" dans des fichiers(xml....)), ce n'est pas mal.
Quand c'est possible separer l' "interface", (succesion d'ecran ici), du reste peut etre payante.Apres tout c'est ce qu'aura le client ou la MOA, donc ca lui permet de "visualiser ces besoins", et lui donne une impression d'avancement.

[mathieu]

en fait j'ai l'impression que je me suis un peu orienté vers la 2ème solution qu'à proposé grafikm_fr parce que j'ai fini par faire une décomposition des tâches de ce genre pour faire une estimation du temps que je vais mettre :

• Structure de base du logiciel
• Étude des données (conception base de données)
• Pages de gestion des joueurs
• Ajout/modification d'un joueur
• Suppression d'un joueur
• ...

... et ainsi de suite avec un décomposition écran par écran pour avoir le maximum de détails
ce que je pense que je vais faire c'est une présentation au client dès qu'un partie principale sera terminée (j'ai 4 grandes parties avec 1 à 1.5 semaine par partie)

pour l'interface graphique ca m'embete un peu de tout faire au début parce que ca prend beaucoup de temps (même si en théorie ca devrai faire partie du cahier des charges de départ) et ca peut laisser croire au client qu'on est déjà plus avancé que l'avancement réél. par contre au moment de coder la page je commence toujours par faire le design

au sujet de CVS je l'utilise déjà et personnellement je ne l'utilise pas si il n'y pas au moins 4 tables (je programme actuellement beaucoup en PHP/MySQL)