[Specification by Example][ch5 Deriving scope from goals]-[读书笔记]-[1]

前言：

---

作者这里采用F-16战机的研发来举例子。F-16最初的客户要求是将速度达到Mach 2-2.5,  其设计者Hillaker为美军方为什么这个需求比较重要，军方的回复是为了能够从战场逃生。最终F-16战机的速度没有超过Mach 2,  但是在协助飞行员从战场逃生方面具有很大的灵活性。F-16也开发了除提升速度外的其他特性，这些特性为达到目标提供了额外的设计方法，而且生产成本更低。

F-16成功的原因是因为提供了比客户要求的更好和成本更低的设计方案，最初的需求，包括将速度提升到Mach2.5，形成了对问题的唯一解决方案，这些问题是由于沟通不到位导致的。设计者没有简单的实现用户的需求，而是更深入的理解问题，一旦对问题有了清晰的了解和界定后，就能够界定最终目标，从而从目标得出设计方案，而不是简单的根据用户简单的粗糙的功能需求得出设计方案。这是成功产品设计的关键所在，软件开发也是如此。

大多数商业用户倾向于将需求表达为设计方案，很少讨论最重要达到的目标，也很少了解需要提供解决方案的问题本质，很多团队都是在这种概念误解的风险下盲目的接受客户提议的解决方案，并且努力实现它。成功的团队不这样做。

像F-16的设计者一样，成功的团队更深入的理解问题的本质，通过协作来得出解决方案。他们也在项目范围方面这样做，项目范围暗示了一个解决方案。和消极的将范围定义的活动交给某个人相比，成功的团队积极的同客户协作来决定好的范围是什么，最终他们的目标能够达到。这也是从范围中得出目标的本质。[like the F-16 designers, successful teams push back for more information about the real problem and the collaborate to design the solution. They do this even for scope. Scope implies a soulution.  Instead of passing the responsibility for defining scope onto someone else, successful teams are proactive and collaborate to determine good scope with the business users, so that their goals are met. this is the essence of deriving scope from goals.]

通过和客户协作的方式从目标得出范围无疑是本书中最有争议的部分。在过去的五年里，软件行业中价值传递的巨浪使大家意识到通过协作的方式从目标得出范围的重要性。而另外一方面，大多数团队并不认为他们对项目的范围有什么控制，而是期望客户或者用户给出完整的定义。最终出于以下三点，作者将这一部分纳入过来：

• 定义软件范围在构建正确的软件中发挥着重要的作用。假如范围错误了，最终得到的是无用的内容。
• 定义软件范围将来会成为最重要的软件开发主题之一。我希望现在就提出来。
• 在以价值交付为观念主题的软件开发过程中，定义范围非常和谐的融入了设计过程。

Building the right scope

---

用例、用户故事或者后备条目提供了一个项目范围的广泛定义。很多团队认为这些内容都是用户或者产品所有或客户应给出的。要求用户提供范围如同依赖于没有任何软件设计经验的人给我们一个高级别的设计方案。得出解决方案是最具有挑战性的活动之一而且也是最重要的步骤。布鲁克斯在人月神话中提到“The hardest single part of building a software system is deciding precisely what to build”, 爱因斯坦也提到”the formulation of a problem is often more essential than its solution.”

当前，用户故事是敏捷和小团队用来定义范围的最常采用的方法。用户故事在软件项目中发现商业价值方面做的非常精彩，不再要求用户在某个开发平台和CRUD事务操作界面进行选择，用户故事使的我们可以和用户讨论她们理解的内容并且排定优先级。很重要的一点是每个用户故事都要有一个清晰的关联的商业价值。（it’s important to note that each story should hava a clearly associated business value)，用户从这些故事中选择价值（而这经常是冰山的一角）。但是当我们知道什么样的用户故事是最终需要发布的时候，我们可以深入调查并且提供可供选择的解决方案。 Christian Hassa of TechTalk 解释说：

人们告诉你什么他们认为他们需要的，通过问他们为什么，你能够识别气候隐含的目标。许多组织不能够明确的识别他们的商业目标，但是一旦你得出来目标，你应该再次逆向的从识别的目标中得到范围，这可能会丢弃最初假定的范围。

这也是我称之为”challenging requirements in Bridging the communication Gap”的实践的本质。虽然我仍然认为质疑需求是重要的实践，但是这种那个行为是倒置的。尽管这样肯定比不做要强很多，目前有很多在获取商业目标方面具有前瞻性的技术和实践。为了避免错误的用户故事，我们可以和我们的商业用户一起协作来完成正确的用户故事。但是关键的不是从用户故事出发而是根据商业目标和客户协作得出来范围。【The key idea is to start not with user stories but with business goals and  derive scope from there collaboratively】。