logo标签列表

团队内部的信息/知识流动

project-managementagilepair-programming
7
我希望避免开发人员不共享常识（解决问题的解决方案、技巧、常见错误、实现特定目标的快捷方式、配置问题、部分需求等）的情况。我指的是这种缺乏沟通是偶然的（由误解或不当管理造成的结果）- 我不考虑开发人员故意保留知识的情况。
我相信以下技术非常有用，可以改善开发团队内的信息流：
XP配对编程-由于配对之间的知识交流（以及定期的配对混合）。
站立会议-由于有机会告诉其他人你正在从事什么工作以及遇到了什么问题。
领先开发人员为团队/部门准备的培训/演示/辅导。
“Web 2.0工具” -公司/部门的技术博客，团队负责人专用的Twitter账户，维基百科等等。
还有其他想法吗？您在公司使用哪些技术（或曾经使用过）？您将如何鼓励开发人员彼此分享知识？
我投票关闭此问题，因为 - 这只是离题了，主题是如何管理团队，而不是如何编写代码。 - Yishai Galatzer
10个回答
11

信任。

你可以“显得愚蠢”，但如果你不知道或不完全理解我的话，请询问。请告诉我如果我错了（因为我也一样愚蠢，可能没有意识到自己的错误）。

这可能听起来有点傻，但它是真的。请“告诉我”为什么你要给答案投反对票。你似乎拥有我没有的知识。 - xtofl
+1 - 我同意，人们需要随时随地感到自在地提出任何问题。 - Reed Copsey
我投了一票 :) 不是我 :) - Henryk Konsek
6

我曾经在一家公司工作，每个星期五我们都有开发者午餐会，管理层提供食物，而开发者则需要分享他们的知识；介绍最近学到的工具或技术，或者演示他们正在进行的项目等。

这并不限于团队目前正在使用的技术，开发者被鼓励学习新技术，并向团队演示。我现在的工作也有月度IT小组会议，有时来自不同团队的开发者会展示他们正在开发的项目。

这是一个非常棒的主意，虽然给开发者买午餐会给公司带来一些费用，但我敢打赌，在此期间创造的价值远远超过了这个成本。如果有更多的公司能意识到这一点就好了！ - SqlRyan
顺便提一下，买午餐的公司是一家资金紧张的初创公司，最终倒闭了 :) - WebMatrix
我喜欢那个想法。特别是来自其他团队的项目演示 :) - Henryk Konsek
2

  1. 一种类似于Twitter的内部工具。也许是一个维基，如果你能让它工作的话，我个人觉得有点过于复杂。但是Twitter不同，可以在上面发布“刚刚添加了一个扩展方法来转义行过滤器中的like子句”之类的内容。

  2. 有些人可能会觉得它有点过于繁琐，但这是公共的实用程序位置，所以你知道在哪里查找string.CountOccurrences而不需要在整个代码库中搜索。

我认为维基百科也“太多了”。特别是要保持它的最新状态，需要投入太多的时间。 - Henryk Konsek
2

我再补充几点

  • 雇佣合适的人才 - 如果你想创造良好的团队动态，这是必不可少的（独来独往的人需要更多的努力）
  • 前视和后视。我们使用维基进行项目管理，在维基上为每个项目创建一个页面，并将其分成重复出现的部分（包括好的和坏的）。在每个里程碑的结尾，让团队开会进行后视。在项目结束时（或者在固定的时间后），让项目协调员整理出易于阅读的东西以供后人查看（并将其放在维基上）
  • 日常例会是必要的！你已经说过了，但我发现它非常有帮助！
  • 如果公司有多个团队，请组织关于他们最大成就的会议。如果可能的话，定期举行跨部门的会议，你会惊讶地发现艺术家对程序员的工作也很感兴趣。
  • 午餐时间是分享的好时机，在我们公司，我们有总裁早餐、项目主管午餐、项目结束之后的晚餐。我都很喜欢，可以混合搭配以获得更好的效果。
  • 全公司外出会议很棒，我们每年至少举行一次（早上展示未来计划，下午是了解项目的活动）
  • 维基很棒，但要注意一些可能会随时间变得不准确的信息（这是任何书面资料的一个经常出现的问题）
2

我认为还有一些其他的事情需要考虑：

  • 模式和实践会议 - 这些不必每周都进行，但应该有一些时间用于讨论各种未解决的问题，并就可能会给很多人带来麻烦的事情达成共识。

  • 文化因素 - 工作场所是否提供足够的社交活动以帮助团队形成默契，或者一些团队建设练习，例如障碍赛或一起做饭，是否有助于建立某些动态。开发人员是否谦虚，以便没有大的自负成为一个问题。另一个因素是要考虑如何回答这个问题：你会去当地的酒吧和你的队友喝一杯吗？如果是，那么你在这里有一些好的观点，而如果不是，那么可能需要进行一些调查。

  • 回顾后续 - 如何考虑并实施回顾中提出的想法？通常如何处理会议？

  • 团队内演示 - 如果完成了某些故事并涉及到一些重要的代码点，那么可能应该为团队进行一些小型演示，以便团队了解已完成的工作，并让其他人了解已完成的工作，以便知识得到传播。这可以与我的第一点相结合，从而进一步促进沟通。

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

我非常支持成对工作。这是传递知识和保持沟通畅通的好方法。尝试为每个项目改变成对的组合。

1

我尝试了许多方法，而且我非常喜欢在项目中与人合作，并定期与团队进行讨论或会议。

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

对我来说，这有点棘手，因为我的大多数开发人员不在同一地点，所以我们设置了一个单一的XMPP聊天室，当我们在项目上工作时，我们所有人都始终登录。其中一些开发人员（包括我自己）也会在下班后登录。

我在办公室里也是这样做的 - 我们往往是一群相当安静的人，但我非常乐意让人们随时打断彼此提问，或者抓起椅子坐下来集思广益。

然而，这种方法之所以奏效，部分原因是我尽量不限制沟通范围仅限于手头的工作或任何特定项目。我的感觉是，无论我是否培养这种文化，人们都会谈论其他与工作无关的事情。然而，我宁愿在正式的渠道中进行“水龙头”谈话，也不愿意在外面进行。

这使得每个人都更容易提出“显而易见”的问题，让大家感到更加自在。此外，人们会不断地提问，因为他们就在那里，并且习惯与所有人交谈。如果需要，很容易忽略，但也更容易随意提出一个普遍的问题，看看是否有人有想法，而不感觉像个麻烦。

我的经验是，由于拥有一个总是渴望帮助解决手头问题的团队，因此由于中断而失去的时间要比节省的时间少得多。

1
如果你的团队规模足够小，使用充分的SVN提交注释，并利用生成RSS订阅源的工具（例如Trac）可以是一种简单高效的促进沟通的方式。
要使此方法有效，需要满足以下几个要求，这些要求相当容易实现： - 频繁提交代码（这本身就很好，因为它使每个程序员的本地更改对所有人都有益，并且能够及早发现问题）； - 使用详细的注释（这也很好，因为在出现问题时更容易追踪到更改的内容）； - 确保每个人都真正阅读（最好通过RSS阅读器保持关注）这些订阅源。
当然，无法“回复”此类注释，但如果有人确实需要回复，通常邮件就足够了，这是该人与提交者之间的私下交流。
另一个有用的工具是要求每个开发人员每周写一份大约10个项目的建议清单，针对自己非常熟悉的主题，供其他开发人员参考。
项目团队/部门内部博客的一个好候选项是项目点列表。 - Henryk Konsek
我在考虑团队的维基百科，在“编程指南”部分，但实际上这基本上是一样的 :) - Varkhan
1

时间。

官方

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

而且预算也很容易：N个开发者参加T个小时的会议。

非官方

“在职”培训...你需要为你特定的工作学到的东西，只有那些懂得这份工作的人才能教给你。

在当前的环境下，在当前的压力下（必须现在就发布），没有人有时间充分解释某些事情。只有当人们放松了，他们才准备分享信息。当人们有足够的时间时，他们会放松。

除此之外，你需要遇到一些具体的链接错误，才会真正开始思考它。没有时间去思考、问问题和阅读，你将无法获得知识。你不能把它推迟到官方的链接器培训中。

要更难预算：开发人员Mary和Sophie谈了一个半小时关于动态链接的问题。第二天，她回来提出了一些问题。经验丰富的开发人员将花更多时间分发，而年轻人则需要更多时间学习。

-1
  • 没有隔墙 - 让所有开发人员在一个大的、无隔墙的房间里工作，这样每个人都可以看到和交谈。
  • 共同目标 - 确保您的团队对目标有一个良好的理解，包括自我提高的目标。
  • 奖励 - 奖励 - 即使只是沟通 - 也会强化您想要实现的目标。

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

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接