7

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

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

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

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

4

10 回答 10

11

相信。

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

于 2009-03-26T21:00:21.880 回答
6

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

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

于 2009-03-26T21:03:12.203 回答
2

  1. 一个内部 twitter-esque 实用程序。如果你可以让它工作，也许是一个 wiki，我个人觉得它有点太多了。但推特不同。“只是添加了一个扩展方法来逃避 rowfilter 中的 like 子句”和类似的东西。

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

于 2009-03-26T21:16:30.673 回答
2

我再补充几个

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

我想到的还有几件事：

  • 模式和实践会议——不一定每周都举行，但应该有一些时间专门用于团队可以讨论各种悬而未决的问题，并对可能让很多人头疼的事情达成共识。

  • 文化因素——工作场所是否提供足够的社交活动来帮助团队凝聚，或者一些团队建设练习，例如障碍训练或一起做饭，是否有助于建立一些动力。开发人员之间是否有谦逊的态度，这样就不会有可能成为问题的自负。这里的另一个因素是考虑你会如何回答这个问题：你会去当地的酒吧和你的队友一起喝一杯吗？如果是，那么您在这里有一些好处，如果不是，那么可能需要在这里进行一些调查。

  • 回顾性跟进 - 在回顾性过程中如何考虑和实施想法？一般如何处理会议？

  • 团队内的演示 - 如果某个故事已经完成并涉及一些大代码点，那么也许应该对此进行一些演示，以便团队查看已完成的工作并允许其他人查看已完成的工作，以便传播知识大约。这可以与我的第一点相吻合，因为它有助于进一步沟通。

于 2009-03-26T23:29:17.547 回答
1

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

于 2009-03-26T21:00:39.587 回答
1

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

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

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

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

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

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

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

于 2009-03-26T21:15:58.193 回答
1

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

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

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

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

于 2009-03-26T21:17:38.500 回答
1

时间。

官方的

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

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

非官方

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

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

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

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

于 2009-03-27T09:24:51.280 回答
-1
  • 没有墙壁 - 让您的所有开发人员都在一个没有墙壁的大房间里 - 每个人都可以看到并互相交谈。
  • 共同目标 - 确保您的团队对目标有很好的理解，包括自我提升的目标
  • 奖励 - 奖励 - 即使只是沟通 - 加强你想要完成的事情

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

于 2009-03-27T18:29:09.957 回答