Bonjour messieurs les LinuxFRiens,
je m'expose ici au risque d'être blamé d'un RTFM, mais j'aimerais savoir si qqn peut me conseiller une bonne URL à propos de la gestion de projet libre.
Je suis navré, mais je ne suis pas sur que ce soit le bon forum, mais je ne suis pas sur qu'il y en ait un ...
<anti-troll> J'utilise sourceforge pour développer un outil déstiné à aider les MAOistes, en comblant certaines lacunes de Windows et en apportant qq nouvelles idées </anti-troll>
(Pour le moment only sous windows, mais nous avons choisi WwWidget au cas où :p )
Et cela est mon premier projet, est je voudrais être sur de ne rien oublier afin de ne pas voir mon projet s'égarer et ceci pour cause mon manque de compétence en gestion de projet.
Je suis pour le moment encore un peu novice mais j'entre à EPITA à la rentrée ainsi j'espere que tout s'améliorera mais j'aimerais être sur de respecter les règles les plus élementaires. J'espere que quelques project manager sympathiques se dévoueront :p
Le site du projet http://nahlwe.sf.net(...) et la page sur sf :
http://sf.net/projects/nahlwe(...)
(Sources pas encore sur le CVS, car peu de code, mai cela ne devrait pas tarder :p, dsl je n'ai pas d'experience de CVS non plus, j'ai ke 18 ans :( ;p )
Merci par avance pour votre attention,
Elthariel
# Mmmmh
Posté par Larry Cow . Évalué à 4.
Pour la gestion de projet libre (comprendre: projet de développement de logiciel libre, hein), je dirais surtout qu'il ne faut pas mettre la charue avant les boeufs: tant que vous êtes en "petit comité", la bonne vieille page sourceforge/gna/savannah/trac et une bonne communication au sein du groupe suffit amplement. C'est d'ailleurs d'autant plus facile quand le groupe a possibilité de se voir physiquement régulièrement.
En revanche, c'est vrai que dès que le nombre de contributeurs augmente, il vaut mieux assurer une gestion de projet un peu plus fine pour éviter que le projet ne s'enlise. Par exemple, organiser des rencontres sur irc, user et abuser des mailing-lists, mettre en place une politique plus stricte de vérification des patchs avant intégration en CVS ou release (ceci étant particulièrement important si, en plus d'avoir plein de contributeurs, tu as plein d'utilisateurs lambdas, qui comprendraient mal que "leur" soft cesse de fonctionner après une mise à jour), etc.
Mais mettre en place ce genre de choses peut s'avérer un peu lourd sur un projet de peu de personnes, et le principal est à mon avis de se permettre de migrer vers des méthodologies bien strictes, mais de ne pas trop s'empoisoner la vie avec. En gros, pas tomber dans le "génie logiciel" sans nécéssité absolue, mais avoir un code suffisament bien organisé et commenté pour pouvoir y venir le cas échéant.
Un écueil à éviter, particulièrement si ceci est un projet scolaire en devenir, ne pas oublier qu'un travail de groupe est fait pour être fait par ... le groupe. Ca a l'air con, dit comme ça, mais on en a tous fait l'expérience un jour, du groupe de projet complètement déséquilibré avec un mec qui fait tout et les autres qui rament pour essayer de servir à quelque-chose. Cette situation est très courante (au moins dans les projets libres EPITA que j'ai pu voir) et particulièrement frustrante pour les deux parties: celui/ceux qui avancent ont l'impression (justifiée) de tout faire, et les autres ont passent leur temps à essayer de comprendre l'existant, et sont toujours en retard d'un wagon. Idéalement, dans ces cas-là, les "tracteurs" ont intérêt à s'arréter un temps pour racccrocher les "remorques", sinon le projet risque fort d'aller dans le mur.
D'ordre plus général, je vais enfoncer un paquet de portes ouvertes:
* toujours commencer par une bonne phase de réflexion "sur papier" et au moins partiellement en groupe. Le but est d'arriver à une spécification à peu près claire du produit, que ce soit d'un point de vue fonctionnel (le logiciel doit faire ça) que technique.
* ne pas non plus pousser la réflexion trop loin. Vient toujours un moment où les spécifications sont remplies de "à voir", "à tester", "je sais pas si ça peut marcher". Que ces intérrogations viennent du fonctionnel (relativement rare) ou de la technique, il n'y a pas cinquante manières de savoir: il faut tester. Un bout de code fait à l'arrache pour démontrer la faisabilité est généralement suffisant.
* Dès que le fonctionnel est prêt (ça devrait être la première chose disponible), commencer à réfléchir à des manières de tester le résultat. Il ne s'agit pas d'implémenter une batterie de test (pas encore), mais d'avoir une idée de ce qu'on devra trouver dans la-dite batterie de test. Parce que, en fin de projet, tu as rarement le recul nécéssaire pour établir une liste objective de points à tester.
* Dans un projet professionnel, on dit généralement que le fonctionnel ne doit pas dépendre de l'implémentation. Dans un projet à but pédagogique (que ce soit scolaire ou personnel), la chose est nettement moins évidente ;)
* Avant de commencer à coder pour de bon, prendre un peu de temps pour réflechir à la structure du projet. Des choses aussi bêtes que "les en-têtes vont dans tel répertoire, les sources dans tel autre". Mais c'est toujours suant de devoir déplacer des bouts de projet complets pour éviter la nécrose (et CVS n'aide pas vraiment ce genre de pratique, en plus).
* Essayer au maximum de coder au même endroit, géographiquement, au moins au début, et surtout si certains maitrisent mal la programmation ou les outils utilisés. Ca permet une saine émulation.
* Ne pas trop hésiter à jeter un bout de code qui sent mauvais. Même si on a passé des heures dessus, le réecrire proprement prendra généralement beaucoup moins de temps la deuxième fois, et on gagnera un temps fou par la suite.
* Toujours dans les enfonçages de portes ouvertes: user et abuser du papier ou du tableau blanc: ca aide beaucoup à éclaircir les idées, et ça peut permettre (si les gribouillis sont human-readable) de servir de base de communication.
Les points que j'ai énoncé ici sont plus du ressort de la gestion de projet en général que de la gestion de projet libre en particulier, mais un bon projet libre, particulièrement tant qu'il est géré par une petite équipe bien circonscrite, peut se gérer selon la manière générale. Les spécificités du libre, qui ne sont en outre pas une obligation, concernent la gestion des contributions externes (patchs, bug reports, etc.), qu'il sera largement temps de commencer à gérer quand vous en aurez :)
Maintenant, si je puis me permettre deux-trois commentaires sur ton projet: le sujet est intéressant, mais plutôt ambitieux (il me semble). Si tu maîtrises bien des choses comme le MIDI, ou que tu disposes de bonnes librairies pour faire le boulot à ta place, pas de problème. En revanche, dans le cas contraire, ne compte pas trop sur ton passage à EPITA pour combler tes lacunes: tu y verras des choses d'ordre beaucoup plus général, et devras travailler ces aspects par toi-même.
(bon, avec un post comme ça, je vais me facher avec les ingénieurs en génie logiciel, les pro-epita, les anti-epita, les gens-qui-n'aiment-pas-lire-des-textes-trop-longs, ... misère)
# Petite précision
Posté par Larry Cow . Évalué à 2.
[^] # Re: Petite précision
Posté par Julien BALLET (site web personnel) . Évalué à 1.
Je suis relativement content de voir que la logique m'a conduit à réaliser naturellement une bonne parties des étapes que tu m'a citée.
Par contre, je n'ai pas pour le moment l'intention de le transformer en projet pédagogique, cela correspond plutot à la satisfaction d'un besoin sur mon ordinateur qu'il ne m'a pas paru possible de résoudre autrement Et puis le 2e programmeur qui m'a rejoint puisqu'il travailait sur un projet analogue entre à EPITA aussi, mais en cycle ingénieur, donc cela regle tout de suite le problème (il "connait" d'ailleurs MIDI _ET_ nous avons une bonne librairie:-).
En tout cas je te remercie de tout ces bons conseils dont je vais m'employer à appliquer la part qui ne l'est pas déjà, notamment, l'emplacement des fichiers sources :p Juste à temps avant ke je n'up les premieres sources ... Encore merci.
Je prends bien note de tes conseils ... Aurais-tu un compte sur sf.net ? Que je garde un contact :)
Elthariel.
[^] # Re: Petite précision
Posté par Larry Cow . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.