如何应对不断变化的需求?

在我知道DDD之前，对于如何给类命名，我曾经提到过以下的想法。 如果我们用客户习惯使用的词语来命名类呢？这难道不让我们更容易向客户解释我们为他们实际建造了什么吗？ 当然，实际中有可能是完全错误的，但我想说我们与客户使用这种方式进行对话是有原因的：不断涌现的新需求。 这不是一个bug，它是一个特性 问题是，我们的大多数项目都是基于固定的价格(和固定的功能)。在收集了所有的需求之后，就会以一种对我们来说有意义的方式构建了这个东西，实现一些不言而喻的业务规则。 但是，在最初的发布之后，我们会从客户那里得到不断增加新特性的请求。有时，我们不得不告诉我们的客户：这在技术上是不可能的（banq注:客户希望手机里的应用背景随着手机外护套颜色变化而变化，有的产品经理不会告诉客户这是不可能的，而是让程序员实现，程序员能不爆发吗？）。或者我们会直接了当告诉他们，他们认为是错误的地方其实是我们设计它的方式是错误的。 抵抗变化 这就是命名问题的重要性体现，我们试图解释产品的实际工作原理，但我们使用的是我们自己编的术语去给类命名，这就会使得客户很难理解，也很难实现新的功能，因为我们必须将客户所说的一切都翻译成我们自己的技术语言。基本上，该产品已变得无法应对变化的需求了。 这是非常遗憾的，然后开发者开始抱怨:要是客户他们早点想到就好了！这种抱怨其实没有任何意义！这完全是对客户的不尊重，但表达一个善良愿望：我们觉得很难达到客户预期，但是我们真的很想这样做。 拥抱变化 我还要进一步指出，我们让客户失望了，他们认为他们想要X，我们建造了X，他们发现他们实际上需要Y，但到那时已经太晚了，X只能是他们能够得到的全部。 “敏捷宣言”提到： 响应计划的改变 这一点很重要，因为客户对他们所需要的产品的理解是随着时间的推移而演变的，每当客户因为这种演变而改变主意，我们就应该庆祝！这是一个接近理想解决方案的机会！我们需要拥抱改变。 那么，当你不知道变化会是什么样子的时候，你该如何规划它们呢？以下是一些你可以做的事情。 1. 对齐 你知不知道最初对技术债务的描述是这样的： 如果不能使程序与领域的思考方式相一致，就会失败。 就我个人而言，我曾经讨厌像“看齐”和“协同”这样的管理词汇，但不管你讨厌与否它就在那里，它是存在的。如果你有同样的感觉，那么更换另一种思维方式就是消除摩擦。 我们可以在启动编程之前花时间理解领域，从而将这种摩擦(或阻力)降到最低，结果发现我们在某些事情上是错误的，我们可以按照我们新的理解方式重构代码。 这会有用吗？我们必须承认，无论客户要求什么，在他们的领域都是有意义的。如果代码也是按照该领域构造的，那么他们的要求在代码中也就有意义了。如果你的订单包含产品，当客户要求添加一个产品条目时，您会感到畏缩，但是如果你的订单中已经包含订单条目集合LineItems，你就会说：“当然可以。”(因为你已经按照理解了领域本身逻辑，好像能提前预知客户变化的需求一样) 2.经常付交 另一种应对客户变化的需求方法是让它尽快发生。发生得越早，重构的代码就越少。 由AndyHunt和DaveThomas设计的实用程序员描述了一种叫做Tracer子弹的技术。诀窍是在短周期内发布，并根据已经完成的事情收集反馈。这也意味着你必须以一种让你的客户能够理解的方式来组织工作。是的，这意味着你不能从后端开始，然后再构建前端。 这也是为什么敏捷宣言说： 频繁地交付工作软件，从几周到几个月，优先考虑更短的时间尺度。 3.开发人员本能 最后，作为一名开发人员，您有一些需要解决的问题。 我喜欢举的例子是一位同事，他非常沮丧，为什么? 因为客户希望他在他构建的动态菜单中增加一个额外的级别，而他们之前明确告诉他菜单只需要两个级别。太天真了，永远不要相信客户的话，只能相信你的领域分析。 所以我的建议是： 当顾客告诉你他们只需要两级菜单时，千万不要相信他们。 我想给你更多的通用性建议，这是一个平衡。如果你把客户说的每句话都实现得面面俱到，你就会遇到麻烦，但如果你从来不认真对待你的客户，你最终可能会把所有的东西都设计得过于复杂。 关键是，当我们已经建立了大量的软件，随着时间推移会看到需求的变化，我们需要跟随它变化的本能。