[Specification by Example][ch2 key process patterns]-[读书笔记]

Specification by Example 是由一组过程模式组成的，这组过程模式能够应对软件产品中的变化，以便有效的研发出来正确的产品。 主要过程和关系如下图所示：

Just in time: 

Successful teams don’t implement the entrie sequence at one time or for all the specifications, as shown in figure 2.1 – especially not before development starts. Instead, teams derive the scope from goals once a team is ready for more work, for example, at the beginning of a project phase or a milestone.  They proceed with specifications only when the team is ready to start implementing an item, sucha as at the start of the relevant iteration. Don’t mistake the sequence in figure2.1 for big waterfall specifications.

这句话挺有意思的，作者说并不是在开发开始前完成所有的阶段，只有在开始实现某个条目的时候才开始处理Spec, 迭代？而且作者说不能把这个当作瀑布式的Spec。

Deriving Scope  From goals

---

Implementation scope offers a solution to a business problem or a means to reach a business goal.  很多团队期望客户或者用户能够在软件开发前给出业务范围，当用户明确出来他们想要的内容后，研发团队实现它。这也是通常假定会让客户满意的方面，事实上，这正是构建正确的产品的争论的开始。【This is supposedl what will make the customers happy.  in fact ,  this is when issues with building the right product begin】.

依靠客户给出用户故事、用例或者其他相关信息的列表，研发团队是在让客户提供解决方案，但是用户不是软件设计者。假如用户定义了范围，项目不会从研发团队的知识中受益。最终的结果是研发出来的产品是用户被问的而不是他们确实想要的。[this results in software that does what the customer asked but not what they really wanted].

和盲目的接受软件需求作为对未知问题的解决方案不同，成功的团队从目标中得出范围。[Instead of blindly accepting software requirements as a solution to an unkonwn problem, successful teams derive sope from goals].他们从客户的商业目标出发，然后他们协作来定义能够达成目标的范围。研发团队和用户一起来定义解决方案，用户讲述需要的特性以及希望达到的价值，这些帮助每个人理解什么是需要的，研发团队可以提出来便宜的、快速的和易于实现和维护的软件产品。

Specifying collaboratively

---

假如开发人员和测试人员在设计Spec的阶段没有参与，那么这些Spec还需要单独的向研发团队交底。实际上，这也是很多误解产生的根源：细节在沟通传递的过程中丢失。 随后，用户需要在产品发布后验证产品，如果验证失败，研发团队需要回来修改。这些都是不必要的重复工作。

和依靠一个人单独的得到Spec不同，成功的研发团队依靠和用户协作来明确解决方案。[Instead fo relying on a single person to get the specifications right in isolation, successful delivery teams collaborate with the business users to specify the solution]. 来自不同背景的人具有不同思想的人使用他们的经验和技术来解决问题。技术专家知道如何更好的利用技术框架，知道如何利用新技术，测试人员知道在哪里发现潜在的争议，团队应该如何工作来阻止这些争论的出现。在设计Spec的时候所有的这些信息都需要捕获。

协作编写Spec 能够使我们利用整个团队的知识和经验。[Specifying collaboratively enables us to harness the knowledge and experience of the whole team]。这也创建了对功能规范的共同所有权，是每个人都能够更积极的参与到研发过程中。[it also creates a collective ownership of specifications, making everyone more engaged in the delivery process].

Illustrating using examples

---

自然语言是存在歧义和依赖上下文的，采用自然语言编写的需求不能为开发或者测试提供无歧义的上下文。当一些问题具有明显的领域特色和行话的时候，这种问题更加突出。理解上的细微的差别会慢慢的累计发生作用，最终导致返工。

和等待功能规范在实现阶段中能够第一次就表述清楚不同，成功的团队使用示例来阐述功能规范。【Instead of waitting for specifications to be expressed precisely for the first time in a programming language during implemention, sucessful teams illustrate specifications using examples】。这些团队和用户一起识别能够阐述期望功能的关键示例。【key examples that descibe the expected functionlity】。在这个过程中开发和测试人员经常提出来一些额外的示例用来阐述边缘用例或者系统需要特别注意的领域。这些消除了期望功能和实际功能之间的差距和不一致的情况，确保了团队的每个成员对需要研发什么有个共同的理解【ensures that everyone involved has a shared understanding of what  needs to be deliverd】, 避免了由于沟通中的错误理解和翻译导致的返工。

假如系统（研发完毕的产品）能够在所有的关键示例下都能够成功的工作，那么它满足了每个人都赞同的功能规范。关键示例有效的定义了软件需要实现哪些功能，可以用于在软件开发过程中，也可以用于评估开发过程是否完毕。

假如关键示例很容易理解和沟通，那么他们可以有效的被用作无歧义的和详细的需求。【If the key examples are easy to understand and communicate, they can be effectively used as unambiguous and detailed requirements】.

Refining the specification

---

协作的、公开的讨论能够建立对业务领域的共同理解，但是讨论产生的示例经常过于详细。 比如说： 用户考虑用户操作界面，提供了当点击理解和填充字段之后应该做什么的示例，这样的繁杂的描述限制了系统。详细描述事情应该如何做而不是做什么是必需的是浪费资源的。额外的细节使得示例比较难于理解和沟通。

关键示例必须简洁、实用。通过重新定义Spec，成功的团队移除了额外的信息，为开发和测试阶段创建了具体的精确的上下文。他们采用适度的细节重新了要实现和验证的目标，识别了哪些是软件应该去做的，而不是如何做的。 [Key examples must be consice to be useful. by refining the specification, successful team remove extraneous information and create a concreate and precise context for development and testing. They define the target with the right amount of detail to implement and verify it. They identify what the software is supposed to do , not how it does it ].

重新定义的示例可以被用作交付的接受标准，知道所有的示例都验证通过后开发才算完毕。在提供额外的信息确保关键示例容易理解后，团队创建具有示例的功能规范，是可以作为工作依据的功能规范，可以接受的测试，未来功能回归的测试。

Automating validation without changing specifications

---

一旦对Spec达成了一致并且明确了下来，那么Spec就成为了团队的一个指南。而这个Spec是需要反复的验证的，在很短的周期里需要保证很快的反馈和验证，需要一个有效的自动化的维护工具。这个问题是Spec如同作者在前面提到的，并不是一次性的完成，而是过程中需要不断的补充和完善，因此是一个持续的验证和具体化的过程，另外，如果考虑单元测试或者功能测试的话，会很容易陷入UI的细节中，这里作者推荐了FitNesse和Concordion两个工具。个人觉得Concordion的功能说明能够说明作者的意图。如下所示：

Validating frequently

---

为了有效的发布软件和支持软件开发，我们需要知道要做什么和为什么做，所有的这些都需要通过代码来实现，大多数编写过的代码在产品发布之前的时候都会处于过时的状态，程序员是知识的了解这和信息的瓶颈。

可执行的Spec能够很容易被系统验证，假如经常的进行Spec验证，我们就能够保证可执行的Spec和我的代码是一致的。由于可执行的Spec 是易于理解的，团队很容易和用户讨论变化，决定如何处理问题。他们会保持可执行的Spec和系统的一致性。

Evolving a documentation system

---

成功的团队不会满足于可验证可执行的Spec，他们会确保Spec是有效的组织的，易于查找的和可访问的，并且保持一致的。随着项目的推进，团队对于业务的理解也在发生变化，市场机会也在发生变化，团队会同时更新Spec以反映这些变化，构造一个有生命力的文档系统。

感受：这一部分作者主要在阐述Spec by Example能够带来的利益，这里关于Spec比较重要的是，个人感觉如下：

• 更新的文档。
• 唯一的来源。
• 可执行的文档。

另外，作者认为Spec并不是在开发之前就能够一次完成的，是随着项目的推进不断的改进的，所以这里对Spec的要求如上可以理解。