Paire Programmation / Collaboration dans une petite entreprise

Je travaille dans une petite entreprise de développement en tant que développeur principal. Nous avons deux autres développeurs, ainsi que mon patron qui est développeur, mais ne fait plus vraiment beaucoup de codage.

Le problème que j'essaie de surmonter est multiforme. Nous avons tous tendance à travailler sur nos propres projets sans grande collaboration entre nous. En fait, en tant que développeur le plus avancé, je demande plus l'avis / l'aide des autres que le mien, car j'apprécie la contribution d'un œil extérieur.

Je veux accroître notre collaboration et je leur ai exprimé cela. En grande partie parce que je voudrais leur montrer certaines choses sur la façon de devenir de meilleurs développeurs et de suivre de meilleures pratiques. Mais étant donné les types de personnalité de nos autres développeurs, je pense qu'ils sont plus à l'aise de travailler seuls.

J'ai lu sur la programmation par paires, et j'ai lu (dans certains forums) que cela ne fonctionne pas bien quand un développeur est plus avancé que les autres (ce que je suis). Et pourtant, j'estime qu'il est impératif que nous commencions à collaborer pour que notre travail ne soit pas si disparate.

Ma question est de savoir si quelqu'un a déjà été dans une situation similaire et qu'est-ce qui a fonctionné pour lui?

Je me rends compte que ce n'est pas une situation unique, mais je suis prêt à essayer plusieurs approches.

Nous travaillons tous dans un espace commun, les développeurs n'ont pas de bureaux / cabines individuels.

Puisqu'il a déjà été expliqué dans d'autres réponses pourquoi la programmation par paires n'est pas une solution pour vous , je vais discuter de ce que nous avons actuellement expérimenté et je suis satisfait des résultats.

À mon avis, ce que vous pouvez faire pour accroître la collaboration, c'est d'avoir deux personnes ensemble sur chaque projet. Chacun d'eux travaille sur une partie différente du projet, mais parce que ces parties doivent être intégrées, les deux développeurs doivent collaborer. Cela nécessite également que les deux programmeurs discutent de l'architecture (couches et interfaces) du projet, puis décident de jouer différents rôles.

Et, si cette approche limite le nombre de projets que votre entreprise peut gérer à la fois, vous pouvez attribuer à cette paire de collaborateurs deux projets simultanément.

Nous avons récemment expérimenté cette approche, ayant l'un d'eux à développer des modèles + intégration avec les API et l'autre programmeur gérant les vues et les contrôleurs . Nous avons trouvé les avantages suivants de ce paramètre:

1. La structure du code donne de bien meilleurs résultats que si un seul travaille sur tous les aspects du projet.
2. Nous n'avons pas à leur rappeler de commettre du code dans le référentiel, etc.
3. Ils doivent faire un effort pour tester le code de chacun, au lieu de se fier uniquement à notre AQ dédié.

À mon avis, la programmation par paires n'est pas la solution au problème que vous soulevez.

Il y a deux rôles distincts dans une programmation par paire. L' observateur est là pour revoir et commenter le code écrit par le conducteur . Si vous essayez de transmettre des idées pour améliorer les décisions prises par vos programmeurs débutants, je me demande dans quelle mesure vous pouvez trouver leur capacité à examiner de manière critique le code que vous écrivez lorsque vous jouez le rôle de pilote.

Sans cette dynamique, l'avantage de la programmation par paires est perdu.

En tant que programmeur principal, je vous suggère d'envisager un programme plus solide de formation et de développement des employés avec votre patron. Vos programmeurs juniors devraient recevoir un cadre pour améliorer leurs compétences. En règle générale, vous pouvez utiliser des méthodes telles que les éclaircissements, rédiger un document de normes de codage, séparer les tâches autonomes de votre propre travail et vous assurer que les processus de révision de code appropriés sont en place.

TL; DR : Je ne pense pas que la programmation par paires fonctionnerait pour vous. Au lieu de cela, vous devriez essayer de sensibiliser les gens à la qualité à long terme de leur code et de leur donner envie de trouver des réponses. Cela doit être fait de manière informelle.

Sur la culture et la qualité

Je pense que ce problème ne concerne pas la méthodologie de programmation mais plutôt la culture . D'après mon expérience, la culture est possible de diriger, mais rarement en en parlant aux gens. C'est-à-dire qu'essayer de forcer un certain flux de travail sur des personnes qui n'ont pas évolué naturellement ou qui sont trop éloignées de la pratique existante est susceptible d'avoir des conséquences négatives.

En d'autres termes, vous ne voulez pas ressembler au costume qui résonne avec les derniers mots à la mode, même quand vous l'êtes finalement. La plupart des programmeurs que je connais vous identifieraient mentalement comme du bruit de fond. Ne soyez pas une abeille d'entreprise.

À mon avis, la principale question que vous devriez vous poser est: "suis-je satisfait de la qualité et de la valeur commerciale du code que mon organisation publie?" et si la réponse à cette question est négative, vous devriez vous demander "comment puis-je changer cela?".

En fin de compte, la qualité et la valeur sont des définitions humaines auxquelles seuls vous ou quelqu'un d'autre dans votre organisation pouvez (et devriez) penser.

Programmation en binôme et microgestion

Donc, au risque de paraître un peu avancé et sévère, il me semble que la lecture de la programmation par paires vous a fait penser à une forme de microgestion , ou l'inverse. MM est une recette infaillible pour aliéner la plupart des gens.

Pour la défense de la programmation par paires: la programmation par paires ne concerne pas un gars qui regarde par-dessus l'épaule d'un autre gars. C'est aussi micro que la direction. PP est sur l' utilisation de deux esprits penser à deux niveaux en même temps - une personne traite de haut niveau , vue d'ensemble des problèmes tandis que l'autre prend soin des écrous et des boulons nécessaires pour produire le code de travail. Et à mon humble avis, cela fonctionne rarement bien si les deux participants ne sont pas en mesure de changer de place. Ils devraient avoir une expérience similaire pour avoir un arsenal professionnel similaire de concepts et un vocabulaire professionnel partagé (nous ne sommes pas liés à l'esprit - pour l' instant , muhahaha).

Pour votre situation, je dirais que puisque vous êtes une petite équipe et que vous êtes la seule à avoir une expérience réelle (c'est à quoi ressemble votre message pour moi), la programmation par paires ou la révision de la plupart du code la plupart du temps ne le ferait pas ça marche pas. Vous n'avez que 24 heures par jour. Au lieu de cela, certaines solutions que vous pourriez envisager:

• Encouragez-les à participer à SO sous la balise de langue appropriée, ou à publier des extraits de code pour révision sur Code Review SE. Lancez un petit concours informel pour savoir qui peut gagner le plus de points de répétition SO par semaine.

  SO peut faire des merveilles pour les développeurs débutants car il fournit une rétroaction constante et suit le rythme cardiaque de la communauté.

• Jetez un œil à certains des codes qu'ils archivent et mettez-les au défi de manière informelle avec des questions concernant son évolution à long terme. La plupart des programmeurs débutants ne sont tout simplement pas habitués à penser à rendre leur code lisible et maintenable. Une fois que vous aurez saisi ces problèmes, ils rechercheront eux-mêmes plus d'informations auprès de vous ou d'autres sources.

Je ne pense pas que la programmation par paires soit quelque chose qui pourrait vous aider dans votre environnement. Ce n'est pas que cela n'aiderait pas à développer les développeurs les moins expérimentés - il y a même une question des programmeurs sur la programmation en binôme avec des ingénieurs de niveaux de compétences différents . Même s'il y a des avantages tels que le partage des connaissances et moins d'erreurs, la programmation par paires nécessite un investissement en temps plus important. Avec une équipe de trois développeurs et seulement quatre personnes ayant des antécédents / expériences de développement, le maintien d'une routine de programmation en binôme semble être difficile.

Je pense qu'une meilleure alternative dans votre situation est la révision des codes, surtout si vous les adaptez de manière appropriée. Un examen de code peut consister en une personne qui examine un petit morceau de code et fournit des commentaires à plusieurs personnes (même à toute l'équipe) dans une pièce pendant une heure ou deux pour parcourir la conception et la mise en œuvre d'un composant entier. Celles-ci peuvent être modifiées selon les besoins du travail effectué, notamment en fonction des connaissances, des expériences et des besoins de l'équipe. Vous pouvez toujours obtenir l'aspect de partage des connaissances en faisant participer plusieurs personnes à l'examen dans le but de trouver des problèmes, de fournir des suggestions et d'acquérir des connaissances en lisant les résultats de l'examen pour incorporer les commentaires dans leur propre travail, avant de les avoir examinés. .

Ma question est de savoir si quelqu'un a déjà été dans une situation similaire et ce qui a fonctionné pour lui.

Puisque vous invitez l'expérience, voici ce que j'ai fait. J'ai choisi l'approche à faible risque et j'ai demandé à quelqu'un de plusieurs décennies plus jeune que moi de passer du temps à travailler ensemble. Nous n'avons pas étiqueté l'activité. Personne, sauf moi, ne savait que nous essayions une nouvelle technique.

Je ne sais pas exactement quels détails rapporter, mais le processus a très bien fonctionné. Il voulait être encadré, ce dont je n'avais aucune idée à l'avance. Il a donc ouvert la communication dans les deux sens de manière très positive.

En fait, en tant que développeur le plus avancé, je demande plus l'avis / l'aide des autres que le mien, car j'apprécie la contribution d'un œil extérieur.

Il semble que vous puissiez définir cela comme une progression logique de ce que vous faites actuellement.

Quelques mois après avoir soulevé cette question, je dois dire que je suis satisfait de nos résultats. Mais ce n'est pas exactement celui que j'ai accepté au début. Gardez à l'esprit qu'il s'agit d'une petite équipe, donc cette solution ne conviendra pas à tout le monde.

J'ai trouvé qu'il valait mieux laisser tout le monde faire son propre travail. Et au fil du temps, nous avons développé une confiance mutuelle où, si nous rencontrons un problème, nous appelons les autres à notre aide. Je pense que personne ne veut travailler avec quelqu'un qui veille sur son épaule. Je m'assois parfois derrière quelqu'un et parfois je l' aide à traverser un problème sans être sollicité. Parfois, je n'ai rien à ajouter et je les ennuie peut-être un peu. Mais ils comprennent que je ne suis pas là pour les harponner. Je suis surtout là pour faire une pause dans ce que je fais et introduire un peu de collaboration.

Ce que j'ai trouvé, c'est que les BONNES personnes au fil du temps (dans une petite équipe) reprennent et se synchronisent avec ce que font les autres. Il n'est pas nécessaire de gérer micrologiquement ou de dire à quelqu'un ce qu'il fait mal tout le temps.

De temps en temps, asseyez-vous avec quelqu'un et résolvez un problème, que vous soyez un expert ou quelqu'un qui apprend, ou les deux. Expliquez pourquoi vous feriez ou ne feriez pas quelque chose d'une manière plutôt que d'une autre. Les bonnes idées se propagent généralement, tandis que d'autres sont laissées pour compte. Et à la fin de la journée, vous avez un groupe de personnes productif et cohérent qui peut travailler sur des choses différentes mais qui partagent un objectif commun.