Comment communiquer efficacement dans une petite équipe de développement? [fermé]
Je travaille dans une petite équipe (4-5 développeurs) sur un seul projet. Chaque membre de notre équipe développe une fonctionnalité différente de notre projet et ils sont très indépendants. En fait, certains membres utilisent des technologies que d'autres membres ne connaissent pas. C'est toujours un seul projet et il y a beaucoup de logique métier commune.
De plus, la plupart des membres ignorent complètement ce que font les autres et comment ils le font. D'une certaine manière, nous parvenons à éviter la réplication de code (crédits pour notre chef d'équipe, mais même il n'est pas complètement conscient de ce qui se passe). Je me demande, ce qui est une bonne pratique pour garder toute l'équipe sur la piste ce qui se passe. Par exemple, si quelqu'un de l'équipe quitte ou manque quand une correction importante doit être faite - c'est difficile pour les autres à gérer.
Nous avons une politique, pour mener des révisions de code, mais seuls les chefs d'équipe et un membre de l'équipe y participent. Les autres membres" réguliers " n'y participent pas.
En outre, nous avons une "newslist" pour checkin-s engagée dans le contrôle de la source par nos membres, mais cela semble trop ennuyeux à traiter et il semble que personne ne prenne le temps de lire ce que les autres viennent de commettre (et ce n'est pas efficace, pour être juste).
Donc, je me demande Quelle est une bonne pratique dans ce domaine. Quelle expérience avez-vous? Est-il une solution à tout ?
EDIT: Permettez-moi de clarifier un peu. Notre équipe travaille depuis plus de 2 ans et le projet est presque 5 ans. Donc, nous ne pouvons pas commencer le développement agile, même si nous pourrions vous quelques pratiques agiles (comme la réunion de stand-up, je trouve cela très utile en effet).
En outre, notre équipe fait partie d'une plus grande entreprise, nous avons donc établi une pratique de team-building. Et nous ne nous détestons pas:) - nous sommes amis, nous parlons de la vie sociale et des activités. les discussions professionnelles sont ce qui nous manque.
8 réponses
Les réunions de Stand-Up chaque jour (Gardez-les courtes) avec tout le monde présent aident tout le monde à comprendre ce que l'autre fait. Cela aide également le gestionnaire à se débarrasser de la gestion, aide à prévenir thrashing , et met un peu de pression sur chaque individu sans que le gestionnaire ait à le faire. (Vous voulez faire quelque chose pour que vous ayez l'air bien devant vos pairs demain matin). Certaines méthodologies comme Scrum formaliser ce.
Passez en revue le code avec différents membres de l'équipe. L'un des membres de l'équipe non-gestionnaire est-il plus expérimenté? Avoir cette personne faire l'examen du code avec d'autres serait bien; il / elle partagerait leur expérience et être quelqu'un d'autre (en plus du gestionnaire) qui sait la plupart de ce qui se passe. Il n'y a pas de loi qui dit dans un examen par les pairs une personne doit être plus âgée que l'autre et être celle qui déclare le code Bon ou mauvais. Je pense cependant que si deux "pairs" font du code examen, ils devraient juste paire-programme pour commencer.
Si vous essayez d'écrire du code de qualité, certains morceaux de code pourraient se prêter à des paire de programmation. Les gens de XP disent que vous devriez le faire tout le temps, mais je crois que c'est plus utile parfois et d'autres fois. Par exemple, lorsqu'un développeur est plus expérimenté que l'autre, cela aide au mentorat. Aussi, quand il y a un domaine spécifique où vous voulez que les connaissances soient diffusées. (Une seule guy comprend une partie du système; la prochaine fois qu'il a besoin de révision, demandez à ce gars de le faire avec l'autre personne qui tape .) en outre, parfois une partie du système est vraiment importante , et l'avoir conçu correctement est beaucoup plus important que les lignes de code par minute. C'est un excellent endroit pour avoir deux têtes sur le problème, et à la fin deux personnes ont une connaissance intime de ce code clé au lieu d'une.
Quelque chose comme une fois par semaine, avoir quelqu'un présenter une courte conversation pendant le déjeuner sur quelque chose d'intéressant qu'ils font. Cela peut générer une grande discussion, promouvoir la confiance et le respect mutuel, mais ce qui nous intéresse ici, c'est qu'il favorise la sensibilisation.
Valeur, support et croient en bon code . Certains magasins (les gestionnaires principalement) necroient pas vraiment au bon code, et cela conduit les gens à sortir du code (merdique), même si les développeurs pourraient faire du bon code. La Communication sur le code est beaucoup plus facile si les développeurs sont satisfaits du code qu'ils fabriquent, si vous implémentez une nouvelle technologie de temps en temps, et si un travail de qualité aide votre carrière.
Et plus sur la programmation par paires. La partie clé de la programmation par paires pour cette discussion est que pair-progrmaming favorise code partagé et la connaissance croisée. La raison pour laquelle je mentionne les endroits spécifiques où la programmation par paires est particulièrement utile est parce que la Politique "Nous allons faire de la programmation par paires" réussit environ 10% du temps. Les autres 90%, les partisans de la pratique ne peuvent pas donner une réponse assez bonne quand un grand gestionnaire demande: "pourquoi toutes ces personnes sont-elles assises aux mêmes bureaux?"Les avantages de la programmation par paire doivent être 200%+ qu'un seul programmeur le fait, parce que vous utilisez deux personnes. Fait au bon moment , la programmation par paires peut augmenter votre rapport solution / buck; au mauvais moment, elle peut de la diminuer.
Les techniques agiles comme la programmation par paires et les réunions quotidiennes de stand-up sont de bons moyens formels d'obtenir une communication.
Mais il semble que ce que vous devez vraiment faire, c'est juste amener les gens à se parler. Les développeurs ont tendance à être introvertis, vous devez donc travailler à cela. Déjeuner ensemble. Regardez par-dessus les épaules de l'autre. Demandez conseil les uns aux autres (même lorsque vous n'en avez pas besoin). Demandez à l'autre au sujet de ces technologies étranges que tout le monde ne comprend pas. Rassembler pour les tests d'intégration.
Je suis dans une situation similaire sur mon lieu de travail. Certains membres de l'équipe sont, comme vous l'avez dit, très indépendants et ne partagent aucune idée ou pratique avec d'autres membres de l'équipe. Je trouve cela très peu professionnel et globalement blessant pour l'équipe.
Bien sûr, il est inévitable d'avoir des membres plus compétents que d'autres, et, dans le monde de la programmation, certains membres auront du mal à mettre leur ego de côté. La meilleure chose à faire est d'avoir des réunions programmées et des revues de code dans lesquelles tout le monde est impliqué. Avoir un site de documentation central où les gens peuvent afficher certaines techniques qu'ils utilisent. Si vous trouvez quelque chose que vous pensez peut être utile au reste de l'équipe, téléchargez-le sur le site et envoyez un e-mail à tout le monde. La Communication est la clé.
Ce qui pourrait vous aider sont des stand-ups quotidiens (du développement agile). Cela ne prend que quelques minutes et fondamentalement tous les membres présentent aux autres l'état de leur travail, les problèmes qu'ils traitent et les plans pour demain.
Je pense que stand-ups est un bon début pour vous. Vous pouvez trouver plus d'informations, par exemple à Martin Fowler-ce N'est pas seulement debout: modèles de réunions quotidiennes Stand-up
Dans notre équipe, nous avons des réunions de progrès chaque semaine. Cela permet de découvrir ce que les autres font et où chacun est placé dans la grande image.
Parfois, il est suivi D'un mini événement social lorsque nous partageons un gâteau fait maison. Le nom de la personne qui apporte le gâteau la prochaine fois est écrit dans les minutes de progress meeeting.
Teambuilding
Allez faire un barbecue ensemble, jouer au baby-foot, trouver une activité d'équipe en plus du travail que tout le monde aime. Cela enseignera aux gens à se faire confiance plutôt qu'à être "indépendants" et multipliera par 10 l'effet de toutes les autres pratiques d'équipe utiles, comme la scrum-meeting ou la programmation par paires.
Voici quelques pensées du haut de ma tête (petite entreprise, trois programmeurs; utilisé pour travailler dans une équipe d'environ 20).
- une sorte de rapport d'avancement pour que tout le monde puisse voir sur quoi tout le monde travaille. "Ce sur quoi j'ai travaillé" les réunions fonctionnent pour certaines personnes, mais je ne suis pas un fan d'entre elles - elles sont trop régimentées, et une réunion assise à cet effet peut souvent se transformer en une perte de temps et/ou être sujette à disparaître.ratholes. À mon travail actuel, nous avons une travail cron qui nous rappelle d'envoyer nos emails de progression hebdomadaires: dans ceux-ci, nous sommes censés dire ce que nous avons accompli, les prochains éléments de notre liste de tâches (avec des estimations le cas échéant), tous les problèmes que nous avons rencontrés.
- notifications sélectives de validation . Très peu de gens paient plus qu'un coup d'œil rapide aux mails de validation à l'échelle de l'entreprise (même dans ma petite équipe) - mais si vous pouvez permettre à chaque développeur de surveiller uniquement les champs dans lesquels ils travaillent, ils peuvent probablement en garder une trace. (Vous ne devrait pas avoir trop de gens travaillant sur le même morceau de code à la fois, de toute façon. Trop de cuisiniers et tout ça.)
- une sorte de système de billetterie pour fournir une liste de tâches peut être utile. Cependant, vous devez être très clair sur la façon dont cela est géré, en particulier sur vos processus de création et de fermeture des tickets.
- documentation interne. C'est un problème difficile; certains développeurs détestent, certains écrivent beaucoup trop, et certains écrivent juste assez. Au moins la moitié du problème est en indexation et présentation; ce n'est pas bon si l'information dont vous avez besoin est enfouie cinq couches de profondeur dans un document impénétrable intitulé "méfiez-vous du Léopard". Je suis un fan de wikis à cet effet car ils sont si faciles à utiliser.
- au-dessus d'une certaine taille d'équipe, vous pourriez trouver qu'il devient un emploi à temps plein pour quelqu'un de gérer votre documentation. Dans un lieu de travail précédent, nous avons dépensé l'argent sur un appareil de moteur de recherche, en explorant continuellement nos sites intranet, ce qui était merveilleux.
Nous sommes dans une situation similaire (un long projet et sommes tous amis), et avons eu des problèmes similaires. Les pratiques suivantes nous ont permis d'améliorer beaucoup:
- les rencontres quotidiennes sont un must. Dans mon expérience un bien conduit meeting quotidien est la meilleure chose à encourager la communication entre les Equipe. Tout le monde sait ce que font tous les membres de l'équipe et peut vous aider avec tout problème.
- Un wiki est également essentiel. Vous pouvez mettre en place des pratiques standard et les technologies qui sont utilisées au sein de l'équipe. Pour avoir tout le monde activement participer, le chef attribue à tous les membres de l'équipe quelque chose à écrire et maintenir dans le wiki. Il est particulièrement efficace lorsque chacun écrit sur quelque chose qu'ils aiment particulièrement ou est intéressé par.
- Essayez d'avoir toute l'équipe présente, ou tous les membres qui sont disponible, dans les réunions où les exigences/caractéristiques sont analysées, priorisé, etc. Peu importe si certains membres de l'équipe le sont pas spécifiquement travailler dans la zone du projet. Cela va donner contexte pour tout le monde et une vision plus large du projet. Il permettez-leur (et encouragez-les) à participer à ces discussions projet dans son ensemble, et ne pas se concentrer uniquement sur la partie qu'ils travaillez sur. Cette pratique motivera beaucoup de discussions, tous d'entre nous quand on leur donne une chance et la connaissance (il ne faut qu'un très petit montant) ont une opinion et aiment commenter tout tout à l'intérieur projet.
- la pratique finale qui motive beaucoup de "boutique" parler, c'est que chaque deux semaines un membre donne une petite présentation sur une technologie ou technique. Généralement, il comprend des exercices pratiques, et le temps discuter et de poser des questions.