鼓励团队沟通的最佳方式是什么？

我在一个中等规模的团队（20个+开发人员），我相信团队成员之间沟通的工作也没有那么好，因为它可以。鼓励团队沟通的最佳方式是什么？

最喜欢的球队，我想，我们有我们建立和维护多个系统。我们还在我们的工作中使用了数十种不同的工具，例如Visual Studio 2008，Subversion，Resharper，Tibco，TeamCity等。

我们还开发使用“敏捷”方法......我将它放在引号中更像是“急于得到这个功能以尽快......我们将不得不为你的规格在大约一个星期......刚开始工作，但现在可以肯定的单元测试它，有它的代码被人审查。”因为这个原因，我们的系统设计不好，因此很难维护....所以我们最终得到了一小部分人，他们非常熟悉他们所创建的系统。

此外，由于IT行业普遍的步伐，我们经常需要使用新技术和工具的最新版本中，我们开发英寸

我的观点是不要去抱怨，说“哦，荣辱与共是我的事情是困难的......“而是我担心的是，除非我们的团队开始更好地沟通，否则我们会一直停留在这种情况下。

让我试着来解释沟通好一点我的意思....

最近我们刚刚从VS2005升级到VS2008 ...这是我的眼睛真棒，因为我喜欢与最新的技术工作。而且我们也从CruiseControl.Net移动到了TeamCity ......这一切都很好。

......但是......我们从来没有真正接受VS2008或C＃3.0的新特性的培训......甚至没有关于TeamCity的备忘录......作为IT人员，我们似乎期望适应并随时随地学习。

现在很明显，我可以通过阅读博客和以下有关我使用的工具......这是我做的最新消息发现信息了自己....但是不断学习的做法是不是真的每个人都在练团队，所以你最终与人们使用新功能，但没有真正了解他们...

此外，我们的团队最近被指示开始进行代码审查...但没有任何指导，什么是真正意义..现在它只是将你的代码给予某人......任何人...在团队中，并让他们看看你的代码......无论是两秒钟还是两个小时，它在整个团队中都不是很好建立或统一。 ...如果他们甚至被在全部完成......

这同样适用于写单元测试真的......我们一直鼓励他们写的...但它没有真正传达团队广泛什么是最好的方式给他们写的是...所以一些开发商试图将它们写，发现它很困难，并且要么写出糟糕的单元测试，要么放弃并决定单元测试是一个糟糕的主意......

我想出来帮助改善这种情况的想法是组织一系列会议，一个开发者论坛...在这些会议中，一个团队成员将提出一个不同的主题，剩下的时间专门讨论开发人员。

一个星期的话题可能是C＃和新的功能，它周围的推荐的最佳做法....和下一个可能是有关代码的评价和寻找什么......而未来可能是一个介绍到一个不起眼的遗留系统.....开发人员可以利用讨论来分享他们的经验和问题。最终的目标是在开发人员中有一个可以自由分享想法和信息的地方。

我得到了我的经理和我的几位同行开发人员的支持，以便让事情顺利......但是我被告知这样的想法已经被尝试过并且最终消失了。

我希望这个想法能够成功，而不是我自己推动所有事情的唯一方法，只有当我最终从这家公司走向成功时，它才会死去。

那我怎么能鼓励我的团队更好地沟通？我对开发者论坛的想法听起来像一个好主意吗？我能做些什么来防止它消失？

有什么更好的，我可以做，而不是我没有考虑？

不仅仅是开始一系列会议......我如何鼓励和影响我的团队开始以团队的形式表现？我非常喜欢我的工作，并且相信我正在与一群优秀的开发人员一起工作......但我也非常想为这个团队增加价值，我认为这个领域目前有点欠缺。我如何有效地做到这一点？

来源

2009-01-21 mezoid

喜欢你的球队缺少一个技术领导这听起来我。

此人将从管理层获得指导，并将其转化为其他团队可以使用的实际步骤。

例如：

你提到你使用大量的产品在你的团队，并没有说明或培训被给予球队有时更新这些。
技术负责人将记录产品以及如何使用它们，理想情况下在wiki上，这样其他人可以贡献自己的力量，并有新产品的使用经验，所以他们可以在需要时帮助任何人。
技术主管也会提供关于如何使用新产品的指导，无论是电子邮件，文档，wiki文章等。
这个人会产生如何做代码审查，与管理层会面后，资深开发等
对于任何新的进展，或主要功能要求的技术负责人将与设计它参与指导，从而进行同行评审，知识将在团队中传播。

所有这一切的关键是让每个人的工作更轻松，更高效。这个人可能很清楚，因为他们会成为最受尊敬的成员，每个人在撞墙时都会去。该人需要一段时间来执行此角色。

不幸的是，如果那不是你，那么你说服人们改变工作方式可能不会有太多的运气。

此外，每月一次非正式午餐，足球或任何团队成员可非正式结合的帮助非常大。

来源

2009-01-21 13:30:07 Bravax

团队精神很难强制。大多数尝试让人们一起工作的后果更好。它需要培育和成长。

而不是一系列会议，团队午餐（在公司）每个月一次左右。非正式的东西不会影响没有工作时间。没有什么正式的，但是有机会让人们彼此交谈并“联系”。如果人们有能力，晚上喝几杯或一纸牌可以提供帮助。重要的是它是自愿的和非正式的。

结对编程可以帮助传递知识，并帮助人们相互了解和理解，因此可能值得思考。

然而，贵公司的管理风格似乎与事物相反。

“尽快获得此功能......我们将在一周内为您提供规范......现在就开始研究它，但一定要进行单元测试并对代码进行审查由某人“。

这让事情变得非常糟糕。有人已经读过关于开发团队应该做的事情，但不愿意花时间（又名钱）来妥善处理事情。这会让开发人员失去权利和动机，这会伤害一个团队。

来源

2009-01-21 12:50:06

它很难给出一个明确的答案..除了尝试出头，希望他们中的一些坚持

避免知识当地岛屿 - PairProgramming可能会奏效。如果A在X拥有一些专业知识或钟表时间的区域注册任务，他可以让X与他配对。执行任务的过程在X的头上扩散，是一个实时代码审查，并有助于提高平均团队技能/专业知识/代码熟悉度。它还鼓励人们互相交谈，而不是对号入座了..

技术演进动态步伐 - 生命...需要事实去适应它。使用开发者论坛，午餐盒论坛，布朗包会议，维基，图书俱乐部，在线论坛等可以工作。取决于你的团队中的人选择他们的首选摄取方式。研究反馈......如果团队认为他们从开发者论坛中受益，他们将会维持。如果它消失了，想想为什么它不坚持..尝试别的经验教训..

松弛 - 一个经常错过的方面。确保人们有时间帮助某人......在截止日期之后不会跑步。

营造一种环境，鼓励和帮助人们说出......帮助别人......然后让他们凝聚在一起。祝你好运。

来源

2009-01-21 12:53:34 Gishu

也许你的关注不是关于沟通，更多关于你队友的动机。在编程等知识领域，动机必须来自实践者。没有这一点，很难走得太远。如果是这样的话，你需要转移到另一个地方。

来源

2009-01-21 12:59:53

首先是通过将团队移动到相同的位置来分解所有实体墙，优先考虑让每个人都坐在同一个房间里。

二，开始使用发布计划会议。也就是说，您的团队与客户协调一致，估计每个需要为即将发布的版本开发的故事。我将改善团队成员之间的沟通，因为他们一起讨论技术问题和解决问题。他们正在估算，如果做得正确的话，会导致就估算和设计方法达成共识。通过迭代计划会议来跟踪每次迭代踢出发布计划（一周迭代最好）。这是团队将每个故事分解成多个计划在本次迭代中实施的小任务的地方。

三，开始使用配对编程。不要强迫它，但强烈鼓励它。此外，确保配对只能在一天左右配对。即旋转对。这建立了集体代码所有权和团队精神，因为它是“我们的代码”而不是“他的代码”。

哦，最后：学会总是谈论“我们”和“团队”。切勿点手指。

来源

2009-01-21 13:17:29

你如何鼓励你的同事进行更好的沟通？以身作则。

在我的公司，我们经常使用术语'驱动某些东西'。有人需要推动一个项目，需要推动测试等。这意味着承担起这项任务的责任并积极应对。不要只指望你的同事分享信息，告诉他们该做什么以及如何去做。

当你发现一些关于VS2008的新的细节时，与他们分享。但要专业。不要只是告诉两位你今天晚些时候喝咖啡的人，准备一份描述你的发现的小型演示文稿或文字文件，并将其传达给所有团队成员。我绝对宁愿给一个简短的演示文稿，而不是给他们发一封电子邮件，但这可能是不可能的。

您可以将其应用于定期的信息交流会议，但我认为在日常工作中保持同样的态度至关重要。不要只是做到这一点，活下去。

（噢，我的，我听起来像那些愚蠢overpayed动机的教练之一！好吧，也许他们是对的，值得所有的钱;-)

来源

2009-01-21 13:20:21 Treb