Conventions pouvant être utilisées pour le travail à distance dans un projet d'équipe

Question

Quelles conventions recommanderiez-vous lors d'un travail à distance (par exemple via CVS ou SVN) sur un projet d'équipe? Plus précisément, que peut-on faire pour éviter que quelqu'un ne procède à des changements à grande échelle, ce qui pourrait être nécessaire, et risquer de créer de la confusion ou de retarder les autres membres de l'équipe? Si un test est nécessaire, comment doit-il être effectué afin que le code ne soit pas pollué avec des instructions qui devront être effacées avant que l'application ne passe en production? Je m'intéresse à tout ce qui a trait à la méthodologie, mais aussi à tous les petits trucs qui pourraient améliorer la communication, comme laisser des commentaires TODO dans le code source.

Answer 1

La communication est plus importante que la convention. Mon équipe est divisée, la moitié en Europe et la moitié aux États-Unis, et notre succès vient de communication claire, régulière:

• appel quotidien de conférence de 15 minutes où tout le monde dit que la région où ils travaillent. Suivi par un résumé par courriel.
• Conférence vidéo hebdomadaire de 2 heures où quelqu'un présente un travail complexe. Comme chef de file, je parle de chaque tâche avec un développeur pendant au moins quelques minutes avant de commencer, de vérifier avec eux au moins une fois par jour par téléphone, par messagerie instantanée ou en personne; et attendez un bref examen lorsque la tâche est terminée. Le point n'est pas de vérifier sur eux pour s'assurer qu'ils ont bien fait * - ils n'auraient pas été embauchés si nous n'étions pas sûrs à 100% qu'ils pouvaient.

Le point est que communication rituelle établit une habitude de base de communication régulière et qui maintient tout le monde dans la synchronisation. Les bits obligatoires rendent tout le monde suffisamment à l'aise pour décrocher le téléphone ou approcher un collègue chaque fois qu'il travaille sur quelque chose que l'autre pourrait avoir besoin de savoir.

Veuillez également ne pas laisser de commentaires TODO dans le code source. Lancez une exception UnsupportedOperationException/NotImplementedException jusqu'à ce que vous soyez prêt à l'implémenter, puis implémentez-la complètement.

* Cela ne veut pas dire parfait. Il y a toujours une meilleure conception, une meilleure façon de coder quelque chose, et une communication continue facilite la rétroaction continue.