关闭。这个问题是opinion-based .它目前不接受答案。
想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.
3年前关闭。
Improve this question
我在一个中等规模的团队(20 多名开发人员)中工作，我认为团队成员之间的沟通没有达到应有的水平。
我想，像大多数团队一样，我们有几个系统需要构建和维护。我们还在工作中使用了数十种不同的工具，例如 Visual Studio 2008、Subversion、Resharper、Tibco、TeamCity 等。
我们还使用“敏捷”方法进行开发……我把它放在引号中，因为它看起来更像是“急于尽快获得此功能……我们将在大约一周内为您提供规范……只需现在就开始研究它，但一定要对其进行单元测试，并让某人对其代码进行审查”。
正因为如此，我们的系统设计很差，因此变得难以维护......所以我们最终只有少数人作为“大师”，他们非常熟悉他们创建的系统。
此外，由于 IT 行业的总体步伐，我们经常需要使用新技术和我们开发的工具的最新版本。
我的观点不是提示并说“哦，不幸的是我的事情很困难”......我担心的是，除非我们的团队开始更好地沟通，否则我们将停留在这种常规上。
让我试着通过更好地沟通来解释我的意思......
最近我们刚刚从 VS2005 升级到 VS2008...这在我看来很棒，因为我喜欢使用最新的技术。我们也从 CruiseControl.Net 迁移到 TeamCity ......这一切都很好。
...但是....我们从未真正接受过任何关于 VS2008 或 C# 3.0 新功能的培训......甚至没有关于 TeamCity 的备忘录......作为 IT 人员，我们似乎被期望适应和学习我们走。
现在显然我可以通过阅读博客和关注有关我使用的工具的最新消息来找到这些信息......我确实这样做了......但是团队中的每个人都没有真正实践过持续学习的实践，所以你最终导致人们在没有真正理解它们的情况下使用新功能......
此外，我们的团队最近被指示开始进行代码审查......但没有任何关于这真正意味着什么的指导......目前它只是意味着将你的代码交给某人......任何人......团队中让他们看看你的代码......无论是两秒钟还是两个小时，它在整个团队中都没有很好地建立或统一......如果他们甚至正在完成......
编写单元测试也是如此……我们一直被鼓励去编写它们……但它并没有真正在团队范围内沟通过编写它们的最佳方式是什么……所以一些开发人员尝试编写它们，找到这很困难，要么编写糟糕的单元测试，要么放弃并决定单元测试是一个坏主意......
我提出的帮助改善这种情况的想法是组织一系列 session 作为开发者论坛......在这些 session 中，团队成员将提出一个不同的主题，其余时间用于讨论开发商。
一周的主题可能是 C# 的一项高级新功能以及围绕它推荐的最佳实践......下一个可能是关于代码审查和寻找什么......而下一个可能是对一个晦涩的遗产的介绍系统......然后开发人员可以使用讨论来分享他们的经验和问题。最终的目标是拥有一个可以在开发人员之间自由共享想法和信息的地方。
我已经从我的经理和我的几个开发人员同事那里得到了一些支持……但是我被告知这样的想法以前已经尝试过，最终消失了。
我希望这个想法能够成功，而不是我一个人插入，直到我最终离开这家公司时才让它消失。
那么我怎样才能鼓励我的团队更好地沟通呢？我关于开发者论坛的想法听起来是个好主意吗？我能做些什么来防止它消失？
有什么我可以做而我没有考虑的更好的事情吗？
不仅仅是开始一系列 session ....我如何鼓励和影响我的团队开始作为一个团队执行？我真的很喜欢我的工作，并且相信我正在与一群优秀的开发人员一起工作……但我也真的很想在我认为目前有点缺乏的领域为团队增加值(value)。我如何有效地做到这一点？
最佳答案
团队精神是很难强制的。大多数让人们更好地合作的尝试适得其反。它需要被培育和成长。
与其召开一系列 session ，不如每月一次左右的团队午餐(在公司)。一些非正式的东西，不会影响任何工作时间。没有什么正式的，而是人们相互交谈和“联系”的机会。如果人们有能力，晚上喝几杯酒或玩一局牌会有所帮助。重要的是它是自愿的和非正规的。
结对编程可以帮助传递知识，帮助人们相互认识和理解，所以可能值得思考。
然而，贵公司的管理风格似乎与事情背道而驰。
"Rush to get this feature in asap...we'll have the spec for you in about a week...just start working on it now but be sure to unit test it and have it code reviewed by someone".
这让事情变得悬而未决。有人读过开发团队应该做的事情，但不愿意花时间(也就是金钱)正确地做事情。这将使开发人员被剥夺权利和动力，从而损害团队。
关于agile - 鼓励团队交流的最佳方式是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/465104/