Discussion :

[christ_mallet]

Je n'ai jamais travaillé en groupe, mais comment fait on pour développer à plusieurs, du style à 10 personnes, je pense au développement sur les logiciels libres mySQL.

[DrQ]

Généralement il y a toujours une personne qui pilote et qui répartit les taches. Ainsi ca évite que quelqu'un piétine sur le boulot de l'autre.
En plus de ça il faut établir au départ un ensemble de règles et de méthodes de travail afin que tout le monde développe de la même facon.

[Epictète]

Tu as besoin d'un logiciel de gestion de versions/dévelopement en équipe, si nécessaire avec partage sur Internet.

Il y à de nombreuses solutions, par exemple dans le libre tu peux installer un serveur CVS : http://www.cvshome.org/

Sinon encore dans le libre tu peux aussi utiliser un service tout pret :

http://sourceforge.net/

SourceForge est un service gratuit pour les développeurs Open Source. SourceForge offre l'accès le plus simple aux meilleurs services CVS, listes de diffusion, gestion des bugs, forums de discussion, gestion des tâches, hébergement de site, archivage de fichiers, sauvegardes complètes, etc. via une interface d'administration entièrement par le web.

[christ_mallet]

Merci, mais comment on répartit le travail, et comment on le réassemble après.

[Epictète]

Merci, mais comment on répartit le travail

Comme chacun veux, en général cela se fait sur le forum

> et comment on le réassemble après.

Chacun travaille en parrallèle sur les modules, le source au complet est dispo sur le serveur sourceforge et sur cvs, n'importe qui peut compiler l'ensemble du projet quand il veux.

Lis la doc de CVS, ou pourquoi ne pas lire cette doc en français sur ce sujet :

"Développement en équipe"
http://www.developpez.biz/downloads/...fr/teamdev.zip

Le développement en équipe devient fiable si vous utilisez le contrôle de versions. Le contrôle de versions empêche les pertes de données accidentelles en mettant en oeuvre un véritable suivi des versions et des révisions. Deux raisons majeures justifient l’utilisation du contrôle de versions : • Il permet à plusieurs développeurs de travailler sur le même ensemble de fichiers sans qu’aucun n’écrase les modifications apportées par les autres. • Il fournit des historiques et des informations de suivi des versions tels que quiconque ayant les droits d’accès nécessaires peut savoir à quel moment une modification a été effectuée. Si vous avez besoin de revenir en arrière ou de vous référer à d’anciennes versions, quelle qu’en soit la raison, le contrôle de versions vous le permet.

[DrQ]

Et bien c'est ce qui s'appelle de l'organisation.
Généralement un projet avec plusieurs personnes commence a être conséquent. De ce fait tu découpes ton programme en plusieurs fichiers source. Ainsi chacun fait sa partie et une fois que tu as avancé ta partie tu la mets avec le reste du code qui est fait par les autres. Pour effectuer tes essais tu n'as qu'à compiler tous les fichiers sources.

Ensuite tu peux travailler encore plus indépendemment, et chacun crée une librairie avec une interface de programmation connue de tous. Ainsi tout le monde se cale sur cette interface et ainsi celui qui développe peut faire évoluer sa librairie sans que ça n'est de répercution sur les autres car les fonctions n'ont changé de nom même si le code derrière a changé.

[zephan]

Si chacun travaille sur un programme source... comment s'entendre pour que les modules puissent communiquer entre eux... variables externes ? communication entre objets, messages windows

[voila]

ce que tout le monde oubli c'est qu'avant le developpement, il y a l'analyse, la modélisation( uml pour les traitement, merise pour les données, PERT pour le chemin critique et surement d'autre .... ), la rédaction de l'analyse fonctionnelle, specification ET vient enfin le developpement.

Le dev est surement la partie la plus lourde ( en durée et en ressource )dans un projet ( quoi que les tests doivent etre plus important normalement ) mais si à la base tout ce qui devait etre fait précédement n'est pas la, tu vas droit dans un mur donc toutes les questions d'organisation, répartition des taches, conformité des données entre developpeur etc ... se décident dans l'étude d'un projet.

[LLB]

Si chacun travaille sur un programme source... comment s'entendre pour que les modules puissent communiquer entre eux... variables externes ? communication entre objets, messages windows

Il vaut mieux faire différentes unités, que l'on compile toutes ensembles. Elles peuvent communiquer avec des variables/procédures/fonctions globales.

[sbeu]

Connaissez vous un site qui explique simplement comment mettre en place un serveur CVS sous Win2000?

[christ_mallet]

Dans le même genre de question, connaissez vous un bon bouquin ou texte sur le concept d'architecture de logiciel ?, non pas au sens architecture technique (cad l'agencement des briques matérielles trouvables sur le marché).

[Twofy]

Si chacun travaille sur un programme source... comment s'entendre pour que les modules puissent communiquer entre eux... variables externes ? communication entre objets, messages windows

Pour ça, il faut une charte de code, et si possible une concertation des codeurs.

Si vous avez peurs d'utiliser les mêmes identifiants, vous pouvez utiliser les namespaces, qui sont très pratiques (mais bon, c gro$oft donc j'aime pas!! )

[fabszn]

Hello,

Generalement pour developper une application a plusieurs.
Lors dela conception , il faut definir des interfaces ( terme utilisé en java..) permettant d'utiliser des objets independement de leur implementation.

Voila , une petite infos qui est bien utile...

[nyal]

franchement je suis pas trop pour le cvs. ce n est pas tres pratique quand il y a beaucoup de personnes. à 20 sur le cvs et chacun change les fichiers , ca devient le bordel.

Moi je conseille de bien discuter avant et pendant et faire des linkages tres souvent pour voir le fonctionnement.

on link pas au dernier moment les modules car les gens vont dire :
non mais moi mon module il fonctionne. bah le mien aussi ... tata titatat puis on s engueule et on rejette la faute sur l autre car chacun a un module qui fonctionne tout seul mais pas avec les autres

donc le seul conseil, c est de faire des reunions de maniere reguliere et avoir un bon chef de proj qui c est faire bouger les choses et prendre des decisions quand ca va mal (le cas qui arrive c est les mecs qui ont pas fait leur module en temps et en heure tout en disant c est bon il sera fait)

la chose primordial, c est un excellent chef de proj

allez hop bye

[DrQ]

on link pas au dernier moment les modules car les gens vont dire :
non mais moi mon module il fonctionne. bah le mien aussi ... tata titatat puis on s engueule et on rejette la faute sur l autre car chacun a un module qui fonctionne tout seul mais pas avec les autres

En tant que chef de projet, je ne suis pas d'accord avec ce que tu dis ou du moins pas en partie. Personnellement j'essaie que le développement se fasse avec des languages objets. Donc le tout c'est d'établir des interfaces de discussion entre les différents modules. Et chacun développe dans son coin. Par contre il est vrai qu'il faut tester l'ensemble du projet régulièrement mais ça ne sert à rien de le faire si tout le monde n'est pas prêt. Pour regrouper tous les modules ou même une partie des modules, il faut que chacun d'eux soit opérationnel à 110% (les 10% en plus c'est pour forcer les développeurs à passer du temps sur les tests avant de dire que c'est fini ). Si tu groupes le module A et B et que B utilise A. A a un souci et plante, du coup B va dire c'est pas moi (ce qui est normal). Mais si A n'avait pas planté B aurait pu planter chose que tu n'as pas pu voir. D'où le risque de regrouper trop souvent.

donc le seul conseil, c est de faire des reunions de maniere reguliere et avoir un bon chef de proj

Là dessus je suis entièrement d'accord. Une mise au point régulière permet de primo de voir où ça en est, et de faire bouger ce qui se reposent un peu trop. Mais l'idéal c'est quand le chef de projet est développeur. Ben vi comme ça si lui est à la bourre sur le dev tout le monde se fout de lui Ca met de l'ambiance dans l'équipe !!

Au fait ce que j'ai dit ici, ça marche pour de petite équipe (je dirai jusqu'à 15), après le chef de projet endosse des responsabilités beaucoup plus importantes et n'a pas le temps de passer trop de temps avec les développeurs.

[Shaym]

Pour ceux qui veulent utiliser CVS sous Windows2000 :

http://www.cvsnt.org/ (service CVS sous windows2000)

http://www.tortoisecvs.org (client GUI CVS)

http://www.componentsoftware.com/products/csdiff/?404;http://www.componentsoftware.com/products/csdiff/intro.htm
(Un Visual Diff bien foutu et surtout gratuit)

et enfin la doc à lire absolument avant d'attaquer le CVS :
http://cvsbook.red-bean.com/ (l'avantage de ce bouquin, c'est qu'il apprend à se servir de CVS ainsi que des méthodes de travail en équipe.En tout cas, il a répondu à toutes mes questions) Excellent livre.

Je finirais sur cette phrase extraite de ce livre :

I can't imagine programming without it... that would be like parachuting without a parachute! -Brian Fitzpatrick on CVS

NB : J'utilise ces outils formidables pour mes développements sous Delphi.

--Shaym

[pyorg]

J'ai vu qu'il y ait aussi http://www.wincvs.org.

Quels sont vos avis sur ces éditeurs CVS graphique:

• Quel est le meilleur?

• Vaut il mieux passer par les lignes de commandes?

A++

[bouddha_66]

bonjour,
ne pensez-vous pas que l'utilisation d'un framework de haut niveau (comportant des objets très détaillés et une normalisation des nommages et des interfaces graphiques) permet aussi de faciliter le développement à plusieurs (en restreignant un peu la liberté des développeurs ).
cependant, cela n'empeche pas d'utiliser cvs ou d'autres outils de ce type ...

[Marc Lussac]

bonjour,
ne pensez-vous pas que l'utilisation d'un framework de haut niveau (comportant des objets très détaillés et une normalisation des nommages et des interfaces graphiques) permet aussi de faciliter le développement à plusieurs (en restreignant un peu la liberté des développeurs ).

Oui

cependant, cela n'empeche pas d'utiliser cvs ou d'autres outils de ce type ...

Exact.

La tendance en grand comptes c'est de faire les 2.

[olrt]

Bonjour,
Mis à part le côté outils de dévoppement, de contrôle de code source,
etc ...

Il faut organiser le travail des développeurs en tenant compte de leur expérience respective et des parties qu'ils souhaitent réaliser.

Ainsi les développeurs plus expérimentés pourront faire la conception
de l'architecture applicative, c'est-à-dire le socle sur lequel reposeront
tous les développements.

Les développeurs moins experimentés seront conseillés par les plus
expérimentés lorsqu'ils seront amenés à utiliser l'architecture ainsi
définie.

Les développeurs experts sur une techno pourront s'occuper de
réaliser les tâches les plus techniques.

Par ailleurs je pense qu'un développeur est beaucoup plus productif
lorsqu'on lui laisse le choix des parties du logiciel sur lequel il va
travailler. Ceci dans l'esprit : on fait mieux ce que l'on aime faire.

Cependant il est vrai que de nombreuses entreprises ne fonctionnent
pas comme cela.