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.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Comment Développer en équipe ?
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.
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.
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.
Merci, mais comment on répartit le travail, et comment on le réassemble après.
Comme chacun veux, en général cela se fait sur le forumMerci, mais comment on répartit le travail
> 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.
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é.
Normes de communication entre les modules
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
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.
Il vaut mieux faire différentes unités, que l'on compile toutes ensembles. Elles peuvent communiquer avec des variables/procédures/fonctions globales.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
a propos de CVS
Connaissez vous un site qui explique simplement comment mettre en place un serveur CVS sous Win2000?
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é).
Pour ça, il faut une charte de code, et si possible une concertation des codeurs.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
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!!)
Developpement a plusieurs personnes..
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...
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
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 finiEnvoyé par nyal
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 luiCa 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.
tout ce que vous avez dit est excellemment vrai, seul détail auquel je crois: c'est qu'il faut définira d'avance:
-les objectifs clairs et nets
-la mission de chacun (par eemple chcun s'occupe d'une rubrique)
-la définition des variables (pour éviter les bugs)
-et un rassemlement périodique des projets (codes) pour éviter la perte des informations ou les hors-sujets d'un ou plusieurs programmeurs.
bon courage mes amis, c'est un ecellent travail, sa fait 6 mois que j'apprends e vous des choses etremement importantes et pointues; bravo
Bonjour,
de la façon que l'on fonctionne ou jetravail, c'est que nous avons développer un petit programme qui nous permet de réserver une partie du programme. Lorsque la partie est réservé, personne n'y a accès. On fait les modifications et on "libère" le module en question en disant ce que nous avons changer. Pour ce qui est des variables globales, elles sont dans un fichier et nous pouvons le réserver de la même façon que pour les autres modules
Merci et bonne journée
Pour ma part je suis amené à travailler avec des electroniciens, ce qui est source de pas mal de conflits. Cela semble évident mais se fixer des objectifs chiffrés et datés et faire preuve d'un minimum d'empathie permet de résoudre bien des problèmes
Bon fini les vacances ... avant de retiourner au taff (en equipe svp) voila ce que je preconise pour resussir un projet en groupe :
- definir le projet sur le fond ( des specs et encore des specs ), sans cela pas de projet en equipe !
- repartir les taches entre les acteurs et leur assigner un role clair et precis de maniere a ce que chaque acteur sache ce qu'il a faire
- dresser un planning initial et l'actualiser regulierement
- prioritiser les taches peut d'averer critique pour la reussite globale
- informer regulierement tous les acteurs de la progression du projet afin que chacun sache ce qui reste a faire et puisse gerer son travail personel. Sans s'enlisser dans la reunionite aigue, une petite reunion d'equipe s'impose. Elle peut etre virrtuelle ( irc, visio ... ) ou reele dans une vrai salle de reu avec du vrai café !
- disposer d'un outil de source controle valable ( cvs, perforce, clearchoze ) accessible par tous les membres de l'equipe et d'un bugtracker suffisament simple pour etre utlisé par toute l'equipe. aucun travail collaboratif ne peut se faire sans ces deux outils !
- une fois le projet commercialisé, prendre en compte le cout de maintanance amputé sur le dev en amont
Bonjour,
En passant il existe beaucoup de livres sur la gestion de
projets et le management.
La communication et savoir le maîtriser est très importante
quel que soit la taille du projet.
Développer en équipe c'est aussi savoir gérer les conflits
et tout un projet pourrais tomber à l'eau rien qu'à cause de
cela.
Je pense que, finalement, développer (seul ou en équipe)
est la face visible de l'iceberg.
Répondre avec citation
Partager