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

18-08-19 banq
              

在我知道DDD之前,对于如何给类命名,我曾经提到过以下的想法。

如果我们用客户习惯使用的词语来命名类呢?这难道不让我们更容易向客户解释我们为他们实际建造了什么吗?

当然,实际中有可能是完全错误的,但我想说我们与客户使用这种方式进行对话是有原因的:不断涌现的新需求。

这不是一个bug,它是一个特性

问题是,我们的大多数项目都是基于固定的价格(和固定的功能)。在收集了所有的需求之后,就会以一种对我们来说有意义的方式构建了这个东西,实现一些不言而喻的业务规则。

但是,在最初的发布之后,我们会从客户那里得到不断增加新特性的请求。有时,我们不得不告诉我们的客户:这在技术上是不可能的(banq注:客户希望手机里的应用背景随着手机外护套颜色变化而变化,有的产品经理不会告诉客户这是不可能的,而是让程序员实现,程序员能不爆发吗?)。或者我们会直接了当告诉他们,他们认为是错误的地方其实是我们设计它的方式是错误的。

抵抗变化

这就是命名问题的重要性体现,我们试图解释产品的实际工作原理,但我们使用的是我们自己编的术语去给类命名,这就会使得客户很难理解,也很难实现新的功能,因为我们必须将客户所说的一切都翻译成我们自己的技术语言。基本上,该产品已变得无法应对变化的需求了。

这是非常遗憾的,然后开发者开始抱怨:要是客户他们早点想到就好了!这种抱怨其实没有任何意义!这完全是对客户的不尊重,但表达一个善良愿望:我们觉得很难达到客户预期,但是我们真的很想这样做。

拥抱变化

我还要进一步指出,我们让客户失望了,他们认为他们想要X,我们建造了X,他们发现他们实际上需要Y,但到那时已经太晚了,X只能是他们能够得到的全部。

“敏捷宣言”提到:

响应计划的改变

这一点很重要,因为客户对他们所需要的产品的理解是随着时间的推移而演变的,每当客户因为这种演变而改变主意,我们就应该庆祝!这是一个接近理想解决方案的机会!我们需要拥抱改变。

那么,当你不知道变化会是什么样子的时候,你该如何规划它们呢?以下是一些你可以做的事情。

1. 对齐

你知不知道最初对技术债务的描述是这样的:

如果不能使程序与领域的思考方式相一致,就会失败。

就我个人而言,我曾经讨厌像“看齐”和“协同”这样的管理词汇,但不管你讨厌与否它就在那里,它是存在的。如果你有同样的感觉,那么更换另一种思维方式就是消除摩擦。

我们可以在启动编程之前花时间理解领域,从而将这种摩擦(或阻力)降到最低,结果发现我们在某些事情上是错误的,我们可以按照我们新的理解方式重构代码。

这会有用吗?我们必须承认,无论客户要求什么,在他们的领域都是有意义的。如果代码也是按照该领域构造的,那么他们的要求在代码中也就有意义了。如果你的订单包含产品,当客户要求添加一个产品条目时,您会感到畏缩,但是如果你的订单中已经包含订单条目集合LineItems,你就会说:“当然可以。”(因为你已经按照理解了领域本身逻辑,好像能提前预知客户变化的需求一样)

2.经常付交

另一种应对客户变化的需求方法是让它尽快发生。发生得越早,重构的代码就越少。

由AndyHunt和DaveThomas设计的实用程序员描述了一种叫做Tracer子弹的技术。诀窍是在短周期内发布,并根据已经完成的事情收集反馈。这也意味着你必须以一种让你的客户能够理解的方式来组织工作。是的,这意味着你不能从后端开始,然后再构建前端。

这也是为什么敏捷宣言说:

频繁地交付工作软件,从几周到几个月,优先考虑更短的时间尺度。

3.开发人员本能

最后,作为一名开发人员,您有一些需要解决的问题。

我喜欢举的例子是一位同事,他非常沮丧,为什么? 因为客户希望他在他构建的动态菜单中增加一个额外的级别,而他们之前明确告诉他菜单只需要两个级别。太天真了,永远不要相信客户的话,只能相信你的领域分析。

所以我的建议是:

当顾客告诉你他们只需要两级菜单时,千万不要相信他们。

我想给你更多的通用性建议,这是一个平衡。如果你把客户说的每句话都实现得面面俱到,你就会遇到麻烦,但如果你从来不认真对待你的客户,你最终可能会把所有的东西都设计得过于复杂。

关键是,当我们已经建立了大量的软件,随着时间推移会看到需求的变化,我们需要跟随它变化的本能。

原文:

https://medium.com/@scato.eggen/changing-requirements-744274e6b90e

[该贴被banq于2018-08-19 19:07修改过]

              

1