对于敏捷开发团队来说，深入设计讨论工作，是否可以替代设计规范的创建？

应用设计讨论可以替代设计规范文档，如果敏捷开发团队的沟通质量高的话，那么在交付高质量的代码上也将更加高效。

因为敏捷设计是持续的，从字面上讲，设计讨论敏捷开发团队日常工作中最重要的讨论。开发人员和架构师需要从设计中思考设计网格和其它的不同，然后达成一致。没必要举行正式的会议，虽然设计讨论可以 是任何形式的，如会议或只是一个带有白板的非正式讨论。无论何时团队达到的设计讨论点或敏捷开发团队成员提出了一个关于当前设计的问题，都有组织设计讨论。

设计讨论发生在所有业务代码编写之前。通过测试它来测试原型代码和证明设计的合理性。使用测试驱动开发的TDD原则来确定设计的健壮性。编写代码之前排除掉所有的担忧和问题。

设计发生于项目的前几天或第一周。第一周结束后，测试团队开始了解代码，使他们的测试更加有效，因为他们能够更好的测试失败点。应用质量得到提升。

设计讨论发生的越早，开发人员就越容易达成一致，编写的代码也越一致。这样，牛仔代码或被禁止的代码就越少，这也提升的应用的质量。在规范文档编写、单方、讨论和丢弃之前，敏捷开发团队要把这一切都完成。

确保质量的关键是沟通和持续设计。在设计会议中尽可能让客户和产品经理参加，这非常重要。如果不这样做，产品经理必须阅读、审查并理解了设计理念，并证实这一设计满足了最终业务目标的需求。

对于我的钱来说，无论从短期来看还是从长远来看，设计讨论都是有价值的；且更有用，当向客户交付正确的代码和高质量的应用时。