Forum Programmation.autre Manager un projet libre sous windows (pr le moment)

• # Mmmmh

  Posté par Larry Cow le 24 août 2004 à 11:43. Évalué à 4.

  

  Si tu rentres à EPITA à la rentrée, et vu ton age, on peut supposer que tu es futur sup. Dans ces conditions, il serait intéressant de savoir si tu comptes présenter Nählwë comme projet libre. Si c'est le cas (et sauf précision contraire de la part des responsables pédagogiques), il serait préférable que, jusqu'à la fin de ton année, seul ton groupe travaille sur ce projet. Accepter des contributions extérieures sur un projet scolaire, dans la pratique ça peut certainement passer, mais ça reste sujet à caution. Voilà pour ça, je dis peut-être de la merde et tu as peut-être l'intention de gérer ça en parallèle de ton projet libre.
  
  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 le 24 août 2004 à 11:47. Évalué à 2.

  

  Je n'avais pas vu que vous aviez déjà préparé un découpage en tâche sur sourceforge, mea culpa. C'est clairement une bonne idée, mais ça nécessite de s'y tenir un minimum (sinon, au mieux ça ne sert à rien, au pire ça peut arriver à freiner).

  • [^] # Re: Petite précision

    Posté par Julien BALLET (site web personnel) le 25 août 2004 à 02:23. Évalué à 1.

    

    Merci bcp pour ces petites precisions, je suis ravi d'avoir pu avoir un LONG texte de réponse :p
    
    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 le 26 août 2004 à 01:03. Évalué à 2.

      

      J'ai jadis utilisé un "larrycow" chez sf.net, mais tu auras surement plus de succès en utilisant la redirection d'adresse de linuxfr.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.