您如何在小型开发团队中有效沟通？

Question

我在一个项目的小团队（4-5名开发人员）中工作。我们团队的每个成员都在开发我们项目的不同功能，他们是高度独立的。事实上，一些成员使用其他成员不了解的技术。它仍然只是一个项目，其中有许多常见的业务逻辑。

此外，大多数成员完全不知道其他人在做什么以及如何做。不知何故，我们设法避免代码复制（我们团队领导的信用，但即使他不完全清楚发生了什么）。我想知道，让整个团队保持正常运转状态的良好做法是什么。例如，如果团队中的某个人在应该进行重要修复时退出或丢失 - 其他人很难处理。

我们制定了一项政策，用于进行代码审核，但只有团队领导和团队中的一名成员参与其中。那里的其他“常规”成员不参加。

此外，我们的成员在源代码控制中提交了一个“checkin-s”新闻列表，但这似乎太无聊了，看起来没有人花时间阅读其他人刚刚提交的内容（而且它是无效，公平）。

所以，我想知道这件事的好习惯是什么。你有什么经历？有解决方案吗？

编辑：让我澄清一下。我们的团队工作了2年多，该项目已有近5年的历史。所以，我们不能开始敏捷开发，虽然我们可以为你提供一些敏捷实践（比如站立式会议，我觉得它非常有用）。

此外，我们的团队是大公司的一部分，因此我们建立了团队建设实践。并且我们彼此不讨厌 :) - 我们是朋友，谈论社交生活和活动。 专业会谈是我们所缺少的。

Answer 1

• 站立会议每天（简短地说）与在场的每个人一起帮助每个人了解彼此在做什么。这也有助于管理者完成一些管理工作，有助于防止thrashing，并且在没有经理必须这样做的情况下对每个人施加一点压力。 （你想要完成一些事情，这样你明天早上就会在同龄人面前表现得很好）。像Scrum这样的一些方法正式化了这一点。

• 与不同的团队成员进行代码审核。非经理团队成员之一是否更有经验？让这个人与他人进行代码审查会很好;他/她会分享他们的经验并成为其他人（除了经理），他们知道发生了什么。在同行评审中没有法律规定，一个人必须比另一个人更高级，并且是宣称代码是对还是错的人。我认为，如果两个“同行”正在进行代码审查，那么他们应该首先进行配对编程。

• 如果您尝试编写一些高质量的代码，某些代码可能会适用于 pair-programming 。 XP的人说你应该一直这样做，但我相信它有时候和其他时候会更有帮助。例如，当一个开发人员比另一个更有经验时，这有助于指导。此外，当有特定区域您希望知识传播时。 （只有一个人理解系统的一部分;下次需要修改时，让那个人用其他人打字。）此外，有时系统的一部分非常重要，并且正确制作它比每分钟代码行更重要。这是一个有两个问题的好地方，最后两个人非常了解这个关键代码，而不是一个。

• 每周一次，有人在午餐时间发表短谈，谈论他们正在做的有趣事情。这可以产生很好的讨论，增强信心和相互尊重，但我们在这里感兴趣的是它提升了意识。

• 价值，支持和相信良好的代码。有些商店（主要是经理）不会真正相信良好的代码，这导致人们只是破坏（糟糕的）代码，即使开发人员可以做得很好码。如果开发人员对他们正在制作的代码感到满意，如果你偶尔实施一些新技术，以及质量工作有助于你的职业生涯，那么关于代码的沟通就会变得容易得多。

更多关于结对编程。对于这个讨论，结对编程的关键部分是配对编程促进shared code和交叉知识。我提到结对编程特别有用的具体位置的原因是因为策略“我们要进行结对编程”大约有10％的时间成功。其他90％的人，当一位大经理问道：“为什么所有这些人坐在同一张桌子上？”时，这种做法的支持者无法给出足够好的答案。结对编程的优势必须是200％以上，而不是只有一个程序员，因为你使用两个人。在正确的时间完成 ，结对编程可以提高您的解决方案/降压比;在错误的时间，它可以减少它。

Answer 2

成对编程和每日站立会议等敏捷技术是发生沟通的正式方式。

但听起来你真正需要做的就是让人们互相交谈。开发人员往往是内向的，所以你必须在这方面工作。一起吃午饭。看看彼此的肩膀。寻求彼此的建议（即使你不需要）。互相询问那些并非每个人都能理解的奇怪技术。收集集成测试。

Answer 3

我的工作场所情况类似。正如您所说，团队的一些成员高度独立，不与团队中的其他成员分享任何见解或做法。我发现这对团队来说是非常不专业和整体伤害。

当然，让一些成员比其他成员更熟练是不可避免的，并且在编程世界中，一些成员将难以将他们的自尊放在一边。最好的办法是安排每个人参与的预定会议和代码审查。有一个中央文档站点，人们可以发布他们使用的某些技术。如果您认为某些事情对您团队的其他成员有用，请将其上传到网站并发送电子邮件告诉所有人。沟通是关键。

Answer 4

什么可以帮助你每天站立（从敏捷开发）。只需几分钟，基本上所有成员都会出现在他们工作的其他状态，他们处理的问题以及明天的计划中。

我认为站立对你来说是一个好的开始。您可以找到更多信息，例如在Martin Fowler - It's Not Just Standing Up: Patterns of Daily Stand-up Meetings

Answer 5

在我们的团队中，我们每周都会举行进度会议。这样可以发现其他人的行为以及每个人在大局中的位置。

当我们分享自制蛋糕时，有时会举行一场迷你社交活动。下次带蛋糕的人的姓名写在进度会议记录中。

Answer 6

<强>团队建设

一起做烧烤，玩桌上足球，除了每个人都喜欢的工作之外，找一些团队活动。这将教会人们相互信任，而不是“独立”，并将每个其他有用团队实践的效果乘以10，如scrum会议或结对编程。

Answer 7

以下是我头脑中的一些想法（小公司，三个程序员;曾经在一个约20人的团队中工作）。

• 某种进展报告，以便每个人都能看到其他人正在做的事情。 “我一直致力于”会议为某些人工作，但我不是他们的粉丝 - 他们太过严格，为此目的举行静坐会议往往会浪费时间和/或者容易在ratholes中消失。在我目前的工作中，我们有一个cron工作，提醒我们发送我们的每周进度电子邮件：在这些我们应该说我们已经取得了什么，我们的待办事项列表中的下几个项目（适当的估计），我们遇到的任何问题遇到了。
• 选择性提交通知。很少有人只是粗略地看一眼公司范围的提交邮件（即使是在我的小团队中） - 但如果你能让每个开发人员只监控他们正在工作的领域，他们可能会跟踪它。 （不管怎么说，你不应该有太多的人同时处理同一段代码。太多的厨师和所有这些。）
• 提供待办事项列表的某种票务系统可能会有所帮助。但是，您需要非常清楚如何管理它 - 特别是您的流程用于发起和关闭门票。
• 内部文件。这是一个难题;一些开发人员讨厌它，有些开发人员写得太多了，而有些开发者写得足够多。至少有一半的问题在于索引和呈现;如果您需要的信息被隐藏在一个标题为“小心豹子”的难以理解的文档中五层深处，那就不好了。我非常喜欢wiki，因为它们很容易使用。
• 超过一定规模的团队，您可能会发现有人管理您的文档成为全职工作。在之前的工作场所，我们将钱花在搜索引擎设备上，不断抓取我们的内部网站点，这非常棒。

Answer 8

我们处于类似的情况（一个长项目，都是朋友），并有类似的问题。以下做法使我们能够改进很多：

• 每日站立会议是必须的。根据我的经验，进行得很好 每日站立是鼓励之间沟通的最佳选择 球队。每个人都知道所有团队成员正在做什么，并且可以提供帮助 有任何问题。
• 维基也很重要。你可以提出标准做法和 团队内部使用的技术。让每个人都积极参与 参与，领导者为所有团队成员分配一些东西 关于维护wiki的内容。它特别有效 每个人写一些他们特别喜欢的东西 感兴趣的。
• 尝试让整个团队在场，或者是所有成员 可用于分析需求/功能的会议， 如果团队的一些成员是，那么无关紧要 没有具体在该项目的工作领域工作。这会给 每个人的背景和更广阔的项目愿景。它会 允许（并鼓励）他们参与这个讨论 作为一个整体的项目，而不仅仅是集中在他们的部分 正在努力。这种做法将激发大量的讨论 我们当有机会和知识时（它只需要一个非常小的 金额）有意见，喜欢评论所有内容 该项目。
• 激励很多“商店”谈话的最后做法是每一个 两个星期，一些成员给出了关于某些技术的简短介绍 技术。通常它包括实践练习和时间讨论 并提出问题。