如何在一个小型开发团队中进行有效的沟通？

Question

我在一个小组中工作(4-5个开发人员)，负责一个项目。我们团队的每一位成员都在开发与我们的项目不同的功能，而且他们是高度独立的。事实上，一些成员使用其他成员不知道的技术。它仍然是一个单一的项目，其中有许多共同的业务逻辑。

此外，大多数成员完全不知道其他成员在做什么和如何做。不知何故，我们设法避免了代码复制(我们的团队领导的学分，但即使是他也不完全知道正在发生的事情)。我想知道，什么是一个好的做法，使整个球队在轨道上正在发生的事情。例如，如果团队中的某个人退出，或者在需要进行重要修复时失踪--其他人很难处理。

我们有一个政策，用于进行代码评审，但只有团队领导和团队的一名成员参与其中。其他“正规”成员不参加，在那里。

此外，我们有一个“新闻列表”，用于我们成员在源代码控制中提交的签入，但这似乎太无聊了，无法处理，而且似乎没有人花时间阅读其他人刚刚提交的内容(公平地说，这是无效的)。

所以，我不知道在这件事上有什么好做法。你有什么经验？有什么解决办法吗？

编辑：让我澄清一点。我们的团队已经工作了两年多，而且这个项目已经有5年的历史了。因此，我们不能开始敏捷开发，尽管我们可以给您一些敏捷实践(比如站立会议，我发现它确实非常有用)。

此外，我们的团队是一个更大的公司的一部分，所以我们已经建立了一个团队建设实践。我们不恨对方， :) --我们是朋友，谈论社会生活和活动。专业讲座是我们所缺少的。

Answer 1

• 站立会议每天(保持简短)与在场的每个人一起帮助每个人理解对方在做什么。这也有助于经理摆脱一些管理障碍，帮助防止痛击，并给每个人带来一点压力，而不需要经理这样做。(你想做些什么，这样明天早上你就会在你的同事面前看起来很好)。有些方法，如Scrum，将此正式化。
• 与不同的团队成员一起进行代码评审。非经理团队成员之一是否更有经验？让这个人和其他人一起做代码评审会很好；他/她会分享他们的经验，并成为其他人(除了经理)，知道发生了什么事情。没有任何法律规定，在同行评审中，一个人必须比另一个人更高级，并声明代码正确或错误。不过，我认为，如果两个“对等方”正在进行代码评审，那么他们应该先对程序进行检查。
• 如果您正在尝试编写一些高质量的代码，那么某些代码可能会借给对程序设计。XP的人说，你应该一直这样做，但我相信它有时更有帮助，有时更有帮助。例如，当一个开发人员比另一个开发人员更有经验时，这有助于指导。此外，当有一个特定的领域，你希望知识被传播。(只有一个人了解系统的一部分；下次需要修改时，让他用另一个人打字。)而且，有时系统的一部分是非常重要的，正确地构建它比每分钟的代码行重要得多。这是一个在这个问题上有两个想法的好地方，最终两个人----对这个关键代码有了很好的了解，而不是一个。
• 就像每周一次，让一个人在午餐的时候做一次简短的谈话，，关于他们正在做的有趣的事情。这可以产生伟大的讨论，促进信心和相互尊重，但我们感兴趣的是，它提高了意识。
• 价值、支持和相信良好的代码。有些商店(主要是经理)并不真正相信好的代码，这导致人们只会中断(糟糕的)代码，即使开发人员可以编写出很好的代码。如果开发人员对他们正在开发的代码感到满意，如果您不时地实现一些新技术，如果高质量的工作对您的职业有帮助，那么有关代码的交流就容易得多。

更多关于配对编程的内容。本文讨论的对编程的关键部分是成对编程促进了共享代码和交叉知识。我提到对对编程特别有用的具体地方的原因是，“我们要做对编程的”策略在大约10%的时间里成功了。其他90%的人，这种做法的支持者，不能给出一个足够好的答案，当一个大经理问：“为什么这些人都坐在同一张桌子上？”双编程的优点必须是200%+，而不仅仅是一个程序员在做它，因为您使用的是两个人。在正确的时间完成，对编程可以增加您的解决方案/成本比；在错误的时间，它可以减少它。

Answer 2

灵活的技术，如对对编程和日常的站立会议，是实现沟通的良好的正式方式。

但听起来你真正需要做的就是让人们互相交谈。开发人员倾向于内向，所以你必须努力做到这一点。一起吃午饭。看着对方的肩膀。向对方寻求建议(即使你不需要)。问对方那些并不是每个人都能理解的奇怪的技术。集合进行集成测试。

Answer 3

在我的工作场所，我也处于类似的情况。正如您所说，团队的一些成员非常独立，不与团队的其他成员分享任何见解或实践。我发现这是非常不专业和整体伤害的球队。

当然，让一些成员比其他成员更熟练是不可避免的，在编程世界中，一些成员会很难把他们的自我推开。最好的做法是安排每个人都参与的会议和代码评审。有一个中央文档站点，人们可以在那里发布他们使用的某些技术。如果你想出了一些你认为对团队其他成员有用的东西，就把它上传到网站上，然后发一封电子邮件告诉每个人。沟通是关键。