随着我所在的团队努力正式化并建立更多的开发实践，我发现通信似乎在以下几点失败：
在关于项目的非正式对话期间，大脑火花时刻成为新的特征/要求。这些“附加物”似乎在裂缝中失败，或者细节在经过一段时间后变得模糊。
在没有明确授权目标或任务的会议中，参与会议的成员对实际讨论的内容有不同的说明。
作为一个团队，我们不断受到挑战（现在我们实际上更愿意编写它们）以生成质量规格和技术文档，详细说明项目中需要具备哪些功能。
我的问题是： 解决这些沟通瓶颈和效率低下的一些建议和方法是什么？没有程序员喜欢编写文档，但希望我们可以集中理解并在项目的生命周期中使信息更加可见和可用...
谢谢你的帮助！
坚持议程。保持目标。当事情开始偏离正轨时，要么安排另一次会议，要么在会议结束后将其发送给电子邮件。
用行动项目结束每次会议 - 一份关于谁将做什么以及何时做出预期的书面清单。是的，这意味着有人需要在会议期间写/输入某些内容。
如果文档变得重要且需要，那么我强烈建议您提出简单的标准然后坚持下去。
维基。维基。维基。所有对团队有用的“部落知识”信息都需要进入维基。如何设置开发环境，常用调试技巧等
记录所有内容，而不是电子邮件！
使用具有历史的东西。我一直试图使用Google Wave跟踪项目的“开发”（改变需求，解释等）。维基也会起作用，但编辑的障碍更大，可能会由更少的人更新。篝火也是一种很好的方法。
新方法（Campfire / Wave）基本上是记录的聊天记录，您可以随时保持打开状态。 Campfire无法“推动”重要决策，我认为他们会在一般对话中迷失方向 - 但是通过Google Wave和Wiki，您可以不断删除不相关或旧的信息。 Wikis将为您提供更多重新格式化新功能的能力。
实际上Wave / Wiki的组合可能是最好的。只需将wave用于日常IM类型的谈话，并将重要的线程/决策拉到Wiki上。
XP（敏捷）中的一些实践也有帮助。如果你全力以赴xp（不仅仅是召集你的每日会议“Scrums”），你会发现一些重要的帮助，例如跟踪不断更新的卡片要求或让现场客户回答重要问题。 XP / Agile的整个想法是基于需求变化和需要跟踪这些变化以及它们影响发布计划的事实。
在结束会议之前，领导会议的人应说明行动事项，当然还有谁将执行这些事项，并获得指定人员或人员的同意。应该指派某人创建会议记录并发布。您可以尝试轮流记笔记，以便每个人都有时必须这样做。你可以尝试一个scrum master（如果你正在做scrum）。
尝试使用wiki作为笔记。会议记录应包括行动项目。所有操作项都应具有与之关联的日期。
如果你不能让任何人认识到你正在做的事情的记录很重要，那么你的开发人员就会遇到严重的问题。当然，您可以拍摄白板及其笔记的图片，但这对阅读和维护问题没有帮助。
许多程序员（包括我自己）都喜欢编写文档。
我发现在Wiki或post-it板上记录决定的原因很重要。没有它，在可以实现两个选项的关键项目上，您将看到一个开发人员逆转另一个开发人员的一些代码。两者都可能有正当理由，但这清楚地表明缺乏沟通。
为了避免这样的问题，会议的关键决策需要重复，甚至一个月之后。
为什么不在维基上保留这些会议的记录，以便其他人可以看到它，人们可以修改它以澄清含糊之处，然后你会提醒所达成的协议。
然后，您可以使用这些功能，并将它们放入您的错误跟踪软件中，这样您就不会忘记有等待实现的功能。
至于＃1：一个新的创意后板怎么样？创建在工作环境中高度可见的区域。正如讨论的想法一样，在粘性上贴上提醒说明并放在板上。将电路板分为几类（即UI，性能改进等）。负责任的成员可以负责将这些转录为完整的wiki，当细节需要添加或者想法足够好以至于它应该花费在设计上的一些真正的努力。
至于＃2：如果您的团队难以保持目标，那么mtg组织者必须花时间准备议程并裁定对话保持主题并坚持会议按时结束。离开会议，知道谁必须做什么。
至于＃3：有人必须负责，找到您希望看到的各种文档和规范的示例，并安排一些时间与团队进行审核和讨论。
我认为维基或内部博客可以很好地为所有团队成员记录有用的程序。
但另一个有趣的观点是程序员之间的沟通，当一些程序员有一个实现怀疑。例如：程序员不知道如何实现某些功能。因此，它可以在“短消息应用程序”中发布您的疑问，例如推特（但有超过140个字符）。然后，一些知道如何解决她怀疑的开发人员可以发布解决方案。将存储所有消息，直到找到解决方案。因此，该团队的所有其他成员将来都会考虑使用此解决方案。
我认为这个架构很好，因为有时开发人员不喜欢“浪费大量时间”在博客上写一篇文章或在wiki上写一些东西。
我用 大本营 管理我的项目。会议成为有趣的头脑风暴会议，然后在网站上委托工作。