Project management 团队内的信息/知识流

我希望避免我的开发人员彼此不共享共同知识（他们遇到的问题的解决方案、酷提示、常见错误、实现特定目标的捷径、配置问题、部分需求等）的情况。我考虑的是这种缺乏沟通的情况是偶然的（由于误解或管理不当）——我没有考虑开发人员故意为自己保留知识的情况

我相信以下技术对于改善开发人员团队中的信息流非常有用：

• XP结对编程-由于结对内的知识交换（以及常规结对混合）
• 站立会议-因为有机会告诉其他人你在做什么以及你遇到了什么问题
• 由首席开发人员向团队/部门其他成员准备的培训/演示/指导
• “web 2.0工具”-公司/部门的技术博客，团队领导的专用twitter帐户，wiki等

还有其他想法吗？你在公司使用（或曾经使用）什么技术？您如何鼓励开发人员彼此分享知识？

信任

---

你可以“装傻”，但如果你不知道或不完全理解我说的话，请问我。如果我错了，请告诉我（我没有意识到这一点，因为我同样愚蠢。）

我非常支持结对工作。这是传递知识和保持沟通渠道畅通的好方法。试着把每一个项目的两人组合起来。

我在一家公司工作，那里每周五我们都会为开发人员举行午餐会。管理层将提供食物，而开发者必须分享他们的知识；展示你最近学到的一些工具或技术，或者演示你正在进行的项目，等等。 这并不局限于团队当时使用的技术，而是鼓励开发人员学习新技术并向团队演示

---

在我目前的工作中，我们每月举行一次IT小组会议，有时来自不同团队的开发人员会演示他们正在进行的项目。

我尝试过许多方法，我非常喜欢在项目上结对工作，以及与团队进行定期讨论或会议

然而，我也发现我能做的最好的一件事就是在开发人员之间培养一种持续沟通的文化。我试着让我的所有开发人员在工作时互相交流——甚至不必等到每周或每月的会议

对我来说，这有点棘手，因为我的大多数开发人员都不在同一个位置，所以我们有一个单独的XMPP聊天室设置，我们所有人在处理项目时都会登录。一些开发者（包括我自己）也会在我们的休息时间登录

我对办公室里的人也这么做——我们往往是相当安静的一群人，但我非常愿意让人们用问题打断彼此，或者随时找张椅子坐下进行头脑风暴

不过，这之所以奏效，部分原因是我尽量不将沟通局限于手头的工作或任何特定项目。我的感觉是人们会谈论其他与工作无关的事情，不管我是否鼓励这样做。不过，我宁愿在官方频道上谈论“水冷器”，而不是在外面

这使每个人都能更轻松地提出“似乎显而易见”的问题。而且，人们不断地问问题，因为他们就在那里，并且习惯于与每个人交谈。如果需要的话，很容易忽略，但也很容易抛出一个一般性的问题，看看是否有人有想法而不感到痛苦，等等

我的经验是，由于中断而损失的时间比由于有一群人总是渴望帮助解决手头的问题而节省的时间要少得多

内部twitter风格的实用程序。也许是一个维基如果你能让它工作，我个人觉得它有点太多了。但twitter则不同。“只是添加了一个扩展方法来转义rowfilter中的like子句”之类的东西

有些人可能会觉得它有点霸道，但它是实用程序的一个常见位置，因此您知道在哪里查找和字符串。CountOccurrencess并不是分散在整个代码库中

---

如果您有一个足够小的团队，使用足够多的SVN提交评论，并利用它们，那么生成RSS提要的工具（例如Trac）可以是促进交流的简单而有效的方法

这项工作有几个要求，很容易达到： -频繁提交（这本身就很好，因为它允许每个人从每个程序员的本地更改中获益，并尽早发现问题）； -使用冗长的注释（这对你来说很好，因为这样可以更容易地跟踪更改的内容，以防出现故障）； -确保每个人都真正阅读（甚至更好，通过RSS阅读器保持发布到）提要

当然，没有办法“回复”这样的评论，但是如果有人真的需要回复，很可能是在这个人和提交人之间，所以邮件通常就足够了

另一个有用的工具是，让每个开发人员，比如说，每周一次，就一个他/她非常熟悉的主题，为其他程序员写一个10点左右的建议列表。

我将补充一些

• 雇佣合适的人——如果你想创造一个强大的动力，这一点至关重要（社交人士需要付出更多的努力）
• 验尸前和验尸后。我们使用wiki来实现这一点，为每个项目创建一个页面，将其划分为重复出现的部分（好的和坏的）。在每个里程碑结束时，让团队开会进行