团队内的信息/知识流[关闭]答案

【问题标题】：Information/knowledge flow within the team [closed]团队内的信息/知识流[关闭]
【发布时间】：2009-03-26 20:51:09
【问题描述】：

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

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

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

还有什么想法吗？您在公司中使用（或使用过）什么技术？您将如何鼓励开发人员在他们之间分享知识？

【问题讨论】：

我投票决定将此问题作为题外话结束，因为 - 这只是题外话，主题是如何管理团队，而不是如何编写代码

标签： project-management agile pair-programming

【解决方案1】：

信任。

您可以“看起来很愚蠢”，但如果您不知道或不完全理解我在说什么，请询问。如果我错了，请告诉我（我没有意识到，因为我同样愚蠢。）

【讨论】：

这可能看起来很傻，但确实如此。只需告诉我你为什么不赞成这个答案。你似乎有我没有的知识。
+1 - 我同意，人们需要随时提出任何问题。
我投了赞成票 :) 不是我 :)

【解决方案2】：

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

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

【讨论】：

这是一个绝妙的想法，尽管公司为他们的开发人员买午餐需要花费一些钱，但我敢打赌他们会发现在此期间创造的价值将远远超过成本。如果只有更多的公司意识到这一点！
顺便说一句，买午餐的公司是一家资金拮据的初创公司，最终倒闭了:)
我喜欢这个主意。特别是来自其他团队的项目演示 :)

【解决方案3】：

内部 twitter 式实用程序。如果你可以让它工作，也许是一个 wiki，我个人觉得它有点太多了。但推特不同。 “只是添加了一个扩展方法来转义 rowfilter 中的 like 子句”和类似的东西。
有些人可能会觉得它有点霸道，但它是实用程序的常见位置，因此您知道在哪里查找，并且 string.CountOccurrences 不会分散在整个代码库中。

【讨论】：

我发现 wiki 也“太多”了。特别是太多，无法保持最新。

【解决方案4】：

我再补充几个

雇用合适的人 - 如果您想创造一个伟大的动态，这是必不可少的（不喜欢社交的人需要更多的努力）
事前和事后。我们为此使用 wiki，为您的每个项目创建一个页面，将其拆分为重复性事物（商品和坏事）的部分。在每个里程碑结束时，让团队开会进行事后分析。在项目结束时（或经过一段时间的修复），让项目协调员将其编译成易于后代阅读的内容（并将其放在您的 wiki 上）
每日站立是必须的！你已经说过了，但我觉得它很有帮助！
如果您在公司中有多个团队，请组织会议讨论他们最伟大的成就之一。如果可能定期，甚至跨部门，您会惊讶于艺术家如何对程序员的工作感兴趣。
午餐是分享的好时机，我们公司有总裁早餐，项目领导午餐，项目结束晚餐。我喜欢它们，混合搭配以获得更好的效果。
与整个公司的非现场会议很棒，我们每年至少举行一次（早上我们介绍未来的活动，下午是了解项目的活动）
Wiki 很棒，但请注意随着时间的推移可能会变得虚假的信息（这是任何书面信息中反复出现的问题）

【讨论】：

【解决方案5】：

我想到的还有一些事情：

模式和实践会议 - 不必每周都举行，但应该有一些时间专门用于团队可以讨论各种悬而未决的问题并就可能让很多人头疼的事情达成共识。
文化因素 - 工作场所是否提供足够的社交活动以帮助团队凝聚或可以进行一些团队建设练习，例如障碍课程或一起烹饪，有助于建立一些动态。开发人员之间是否有谦逊的态度，以便没有可能成为问题的大自负。这里的另一个因素是考虑你会如何回答这个问题：你会去当地的酒吧和你的队友一起喝一杯吗？如果是，那么你在这里有一些好处，如果不是，那么这里可能需要做一些调查。
回顾性跟进 - 如何考虑和实施回顾期间提出的想法？一般如何处理会议？
团队内的演示 - 如果某个故事已经完成并涉及一些大代码点，那么也许应该对此进行一些演示，以便团队查看已完成的工作并允许其他人看到已完成的工作知识确实得到了传播。这与我的第一个观点相吻合，即有助于进一步沟通。

【讨论】：

回顾 - 这就是重点:) 我们需要知道我们的更改是否提供了预期的结果。

【解决方案6】：

我非常支持结对工作。这是传递知识和保持沟通渠道畅通的好方法。也可以尝试为每个项目混合配对。

【讨论】：

【解决方案7】：

我尝试了很多方法，并且非常喜欢结对合作完成项目，以及与团队进行定期讨论或会议。

不过，我还发现，我能做的最好的事情就是培养开发人员之间不断沟通的文化。我尝试让我的所有开发人员在工作时相互交流 - 甚至不必等到每周或每月的会议。

对我来说，这有点棘手，因为我的大多数开发人员都不在同一个位置，所以我们设置了一个 XMPP 聊天室，并且我们所有人在处理项目时始终处于登录状态。一些开发者（包括我自己）也会在我们的下班时间登录。

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

不过，这样做的部分原因是我尽量不将交流限制在手头的工作或任何特定项目上。我的感觉是人们会谈论其他与工作无关的事情，无论我是否鼓励这样做。不过，我宁愿在官方频道上谈论“饮水机”，而不是在外面。

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

我的经验是，因中断而损失的时间远少于因拥有一个总是渴望帮助解决手头问题的团队而节省的时间。

【讨论】：

【解决方案8】：

如果您的团队足够小，充分使用 SVN 提交 cmets，并利用它们生成 RSS 提要的工具（例如 Trac）可能是促进沟通的一种简单有效的方式。

要使其工作有几个要求，这些要求很容易达到： - 经常提交（这本身很好，因为它允许每个人从每个程序员的本地更改中受益，并及早发现问题）； - 使用详细的 cmets（这很好，因为它可以更轻松地跟踪更改的内容，以防万一发生故障）； - 确保每个人都实际阅读（更好的是，通过 RSS 阅读器保持发布）这些提要。

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

另一个有用的工具是要求每个开发人员，比如说，每周一次，针对他/她真正熟悉的主题，为其他编码人员写一个大约 10 个要点的建议列表。

【讨论】：

Bullet point 的列表非常适合团队/部门内部博客。
我在考虑团队的 wiki，在“编程指南”部分，但这基本上是一样的 :)

【解决方案9】：

时间。

官方

走出尘土飞扬的办公室，让你头脑清醒，真正花时间去听讲座或培训，这一切都有助于传播知识。

预算也很容易：N 个开发人员参加 T 小时会议。

非官方

“在职”培训...您特定工作所需的内容只能由了解该工作的人教授。

在当前的气候下，在当前的压力下（必须现在），没有人需要时间来完全解释某件事。只有当人们放松时，他们才准备好进行信息共享。当人们有足够的时间时，他们就会放松。

除此之外，您需要在真正开始考虑之前遇到一些特定的链接器错误。没有时间去思考、提问、阅读，你将无法获得知识。您不能将其推迟到正式的链接器培训。

预算更难：开发人员 Mary 用一个半小时向开发人员 Sophie 询问了动态链接。第二天，她带着一些问题回去了。经验丰富的开发者会花更多时间进行分发，而年轻的开发者则需要更多时间学习。

【讨论】：

【解决方案10】：

没有围墙 - 让您的所有开发人员都在一个没有围墙的大房间里 - 每个人都可以看到并互相交谈。
共同目标 - 确保您的团队充分了解目标，包括自我提升的目标
奖励 - 奖励 - 即使只是交流 - 强化你想要完成的事情

社会化和共同目标总是鼓励信息交流。

【讨论】：