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

Understand the “Why” and “who”

---

用户故事通常具有三个部分：“As  a  XX  I want  XXX in order to  XXX”.  也就是理解为什么有些事情是需要的谁需要的对于评估一个提出来的建议是非常重要的。【understanding why something is needed and who needs it is crucial to evaluating a suggested solution】.

同样的问题可以用于确定项目的范围上。在较高的层次上问这些问题能够将项目拉向不同的方向。

作者举了一个比较极端的例子：

在利比亚有个交通符合信息管理的系统，最初的时候是采用Access来管理和维护的，随着业务的拓展，该公司在不同的国家里都有了数据收集的工作，这些系统都采用Access程序，这些Access数据库是偶尔需要合并的。然后，用户的想法是开发一个以数据库为中心的在线的Web 应用程序来管理这些内容。初步的预算是10万欧元。

在项目开始之前，用户说”我们需要一采用中心数据库的Web应用程序”，此时，问用户为什么需要这个，以及谁会采用这个系统，用户说需要一个单一的数据源在上面工作以便能够节省合并时间，而目前只有十个Access数据库，另外Merge操作大概一年一两次。最终系统采用了Crtrix的远程服务器方案。

在项目范围的级别很容易得出来解决方案，在没有进入可能的用户故事和用例并且讨论具体的任务的Spec的时候，某些人建议的Web 应用程序是一种解决方案，但是不能沿着它往下走。这样充分说明了在项目开始之前了解谁需要以及为什么能够得出更好的解决方案。

Understand where the value is coming from

---

除了能够帮我们得出比较好的设计方案，理解价值所在能够帮我们确定优先级别。 Rob Rark的团队通过在更高级别的特性上识别优先级的做法，帮助他们有效的过滤出低等级的用户故事，节省了大量的时间。 Part说：

我们关注等级高，通过商业价值了解对于特性来说什么是核心内容的部分。 我们将特性分解为不同的尽可能小的用户故事。其中的一个示例是： 为14个周将证据以PDF的形式发布。从商业角度我最想了解的是“这究竟价值多少，其后价值多少美元”。在那种情况下，一个高级人员告诉我们“恩，大约50%的来电都是为了这些内容，这些来电的50%是为了保险卡片的证据，那么大约25%的来电是处理那些内容的”。他们知道他们有多少来电需要处理，并且通过生成PDF而不是复制粘贴的方式能够节约多少资源，那么他们能够将一些数字放到这部分内容上，那确实比较酷。

将讨论放到项目范围和优先级的角度的讨论能够比在用户故事级别更加有效率。【Raising  the discussion to the level of the goals allows teams to deal with scope and priorities more effciently than just doing so at the story level】。

在这个领域的另外一个例子，这能够帮助评估时间。Rob Park的团队发现讨论目标能够减少他们在为每个用户故事评估资源上的浪费。

我们确实不想再评估用户故事的资源上烦恼。加入你开始评估用户故事，以Fibonacci 数字为例，你很快意识到任何高于或者等于8的数字都是在一个迭代中太大而难以发布，那么我们将其切成1， 2，3 ，5. 在下一个阶段你发现5比较大， 那么所有的事情都是1， 2 ，3 ， 他们都是类似的。我们可以将用户故事分解为那种大小，而不是先去做评估，然后再实际上需要发布的时候来具体评估。

以个人经验来说，预测一件事情将要花费多少钱是非常难的，而且预测要花费多长时间来实现它也是容易出现错误的，但是假如你的领域允许你在特性前标识个数字，这会帮助用户参与。要求他们在特性甚至商业目标行排定等级比要求他们在下一阶段的用户故事和任务排定登记要好很多。【Asking them to prioritize features or even business goals works better than asking theme to prioritize low-level stories or tasks.】

Understand what outputs the busines users expect

---

当目标很难说清楚的时候，一个有效的方法是了解期望的系统输出: 调查为什么客户需要并且软件如何提供给他们。一旦你能够搞定这些期望的输出结果，你能够集中你的工作在满足来自于客户的需求上。通过分析为什么这些输出是必须的能够得出来项目的目标：

与其尽量和商业用户在明确怎么将内容加入系统，我们应该从输出的示例开始。这能够帮助用户参与讨论并且能够让客户了解他们会得到什么样的系统。【Instead of trying to collaborate with business users on specifying how to put things into the system, we should start with examples of outputs. This helps engage business users in the discussion and gives them a clear picture of what they’ll get out of the system.】

Wes Williams在一个由于构建用户界面的拖延而导致返工的项目上工作：

验收测试是针对领域模型编写的，是在我们的用户能够看到GUI之前。UI部分大概拖延了四个月。当用户看到UI的时候，他们发现和他们当初设想的完全不一样。当我们开始为UI编写测试用例的时候，比领域模型花费了更多的资源。当领域代码需要发生变化的时候，客户假定那一部分已经完成了。他们之前在那一部分进行过测试，运行，通过，所以他们假定已经完成了。

系统的期望结果能够帮助我们发现目标并且决定需要构造什么内容来支撑他们。 Adam Gears在敏捷项目之前就将注意力集中在构造正确的内容上。

我们采用了之前称之为报表优先的方法，但是是在用户故事的级别，而且我们的经验主要集中在EPR的实现阶段。 不是敏捷项目。这种方法帮助了我们很多，因为在报表上不存在的一个数据元素能够导致返工。通过先考虑输出我们能够避免返工。

从系统输出得出项目的范围是来自BDD社区的想法。由于这个想法能够解决常见问题已经引起很多关注了。在我之前的一些项目中，我们集中在处理流程和将数据加入系统。我们将处理的结果比如说报表放到了后续阶段。这种方法的问题是商业用户只有在这些结果能够出来的时候才能参与进来，而这经常导致返工。根据输出来进行工作能够确保商业用户一直提供反馈。