《实例化需求-团队如何交付正确的软件》全书18章，210页，共30.7万字。本书共分为三个部分：开始、关键过程模式和案例研究。本次阅读第一部分开始，从第一章到第四章，大概65页。
实例化需求说明是一组过程模式，它帮助团队构建正确的软件产品。
1、实例化需求优点
* 更有效地实施变更。【活文档（living documentation）后续需重点关注】
* 更高的产品质量。
* 更少的返工。
* 同一项目不同角色的活动协调得更好。
画重点：
1）正确地构建产品和构建正确的产品是两回事。二者兼顾才能取得成功。
2）实例化需求说明能够在适当的时间提供恰好够用的文档，帮助使用短迭代或基于流的开发过程构建正确的产品。
3）实例化需求说明有助于提高软件产品的质量，显著减少返工，并使得团队更好地在分析、开发和测试活动中进行协作。
4）从长远来看，实例化需求说明有助于团队创建一个活文档系统，它是一种具有相关性的、可靠的功能描述，会随着程序代码的变更自动更新。
5）实例化需求说明的实践配合短迭代（Scrum、极限编程）或基于流的开发方法（看板）一起使用，效果最好。
2、关键过程模式
实例化需求说明是一组过程模式，它可以协助软件产品的变更，确保正确的产品能够有效地交付。
划重点：
- 实例化需求说明的主要过程模式是从目标中获取范围、协作制定需求说明、举例说明、提炼需求说明、自动化验证时不修改需求说明、频繁验证以及演进出活文档系统。
- 对于实例化需求说明而言，功能需求、需求说明和验收测试都是一回事。
- 其结果是一个活文档系统，它解释系统可以做什么，并且与编程语言代码一样确切和可靠，但更容易理解。
- 不同背景的团队使用不同的实践来实施过程模式。
3、活 文 档
实例化需求说明的过程和工件有两种流行的模型：以验收测试为中心的模型和以系统行为规范为主导的模型:
- 以验收测试为中心的模型（通常称为验收测试驱动开发，ATDD或者A-TDD）侧重于自动化测试，并把它作为实例化需求说明过程的一部分。优点：开发目标更加明确，并且可以防止功能退化。
- 以系统行为规范为主导的模型（通常称为行为驱动开发或者BDD）侧重于制定系统行为的场景。它的主要工作是通过协作和需求澄清，在项目干系人和交付团队之间建立起共识。该模型认为，通过自动化测试预防功能退化也很重要。
作者认为：尽管回归测试的确很重要，但我并不认为这种长期好处是它产生的。 首先，实例化需求说明并不是唯一可以防止功能退化的方法。 其次，Capers Jones在EstimatingSoftware Costs一书中指出，通过回归测试移除缺陷的平均效率仅有23%。这无法证明成功的团队在实现实例化需求说明上作出长期投资是正确的。
从代码中挖掘系统功能的过程叫做“系统考古学”。【我们也是考古系的！o(*￣︶￣*)o】
改动过时的内容不是主要的成本所在，花时间去找出需要改动的地方通常才是成本较高的地方。
划重点：
- 实例化需求说明允许你渐进性地建立起一个良好的文档系统。
- 活文档是交付过程的重要工件，与代码一样重要。
- 侧重于建立业务流程文档系统可以帮助你避免长期维护需求说明和测试造成的大部分常见问题。
4、开始改变
20世纪80年代晚期，Gerald Weinberg和Donald Gause在《探索需求》一书中谈到了软件需求的沟通问题。作者认为实例化需求说明既是需求说明又是测试的两重性。
实例化需求对敏捷来说主要解决的常见问题是返工、沟通不畅导致的重复工作、为了理解系统而回头阅读代码所浪费的时间，以及手工重复执行相同测试所消耗的时间。
我们将探讨如何着手改变过程和团队文化，以便你去实施实例化需求说明。
4.1 如何开始改变过程
1、把实施实例化需求说明当作更广阔的过程变更的一部分（适用于：新项目）
实施Scrum、XP或任何其他敏捷过程终归是一种休克疗法，因此如果有可能的话，可以把实施实例化需求说明也纳入其中
2、专注于提高质量
先找出提高软件质量的最大阻碍，然后解决这个问题
3、从功能测试自动化开始（适用于：应用到现有项目）
如果你还没有实行功能测试自动化，请记住这是一个容易实现的目标，一个开始实施实例化需求说明的简单方式。
想要使用自动化测试完全覆盖遗留系统是徒劳的。为了从最早实施的功能测试自动化中获得最大收益，请专注于将系统中存在风险的那部分先自动化掉，这些地方的问题会花费很多财力。
4、引入一个可执行需求说明的工具（适用于：测试人员负责测试自动化时）
使用支持可执行需求说明的自动化工具后，开发人员会更多地参与到测试自动化中，同时商业用户也能够对测试有更深入的了解。
5、使用测试驱动开发作为踏脚石（适用于：开发人员对TDD有较深认识的时候）
引入实例化需求说明的另一个常见策略，就是从（单元）测试驱动开发上入手，特别是在开发新项目的时候。可执行的需求说明就是针对业务功能的测试。
4.2 如何开始改变团队文化
1、避免使用“敏捷”术语（适用于：在一个抵制变化的环境中工作时）
无需使用技术术语就能实施实例化需求说明，这是完全可能的。如果工作环境抵制变革，那么开始变革时就一定要避免使用术语。
2、确保你得到管理层的支持
没有管理层的认可和支持，过程变更成功的几率很小。
3、把实例化需求说明当作是比执行验收测试更好的方式来推销
我认为，大部分团队是能够以避免把验收测试拖到最后为理由证明实施实例化需求说明的花费是值得的。改变过程，让团队能更快地完成目标，会带来可衡量的经济利益，这样也就可以证明在过程变革中的投资是值得的了。
4、不要让测试自动化成为最终的目标
团队只关注测试自动化时，就不会更好地协作
5、不要太关注工具
实例化需求说明并不以程序员为中心，而程序员独自使用一个工具不会取得很好的效果。
6、在迁移过程中，遗留脚本也要有人维护（适用于：在遗留系统中引入功能测试自动化时）
通过委派一个专门的人员来更新遗留事项，团队就可以更快地朝着迁移到新过程的目标前进。
7、跟踪哪些人在运行（以及没有运行）测试自动检查程序（适用于：开发人员都不愿意参与时）
通过监视测试是否执行，来让程序员执行自动检查程序。
4.3 团队如何在流程和迭代中集成协作
过程变更没有通用的解决方案，每个团队都需要决定如何最好地扩展他们交付软件的方式。
-通过快速周转来提供快速反馈和重点；高效地完成软件的一小块，而不是试图一次性处理一大块。
-强调有效、高效的沟通，而不是冗长、乏味的文档。
-建立共享所有权，这样在需求说明变成代码或测试的过程中，开发人员与测试人员不会互不通气。
-整合跨职能团队，为了制定正确的系统需求，测试人员、分析师和开发人员一起进行工作，而非各自为战。
4.4 处理签收和可追溯性
实例化需求说明提供了有关需求的工件：活文档。活文档可用于追溯，这使得敏捷过程可以应用于受管制的行业。
1、在版本控制系统中保存可执行需求说明
我访问过的一些人说，把可执行需求说明和产品代码放在同一个版本控制系统中，是成功实施过程的最重要的做法之一。
2、通过导出的活文档来签收（适用于：逐个迭代签收）
如果需要在实现功能前签收需求说明，并且可以在每个迭代里都这么做，那么你可以根据下一个迭代所计划的可执行需求文档创建一个Word或PDF文档，然后在上面签收。
3、签收的是范围，而非需求说明(适用于：签收较长的里程碑)
如果你要签收的内容比一个迭代所能交付的要大，那就试着对范围而非对具体的需求说明进行签收。比方说，签收用户故事或用例。
4、在“精简的用例”上签收
对“更轻量的用例”做签收，而无需实例。
5、引入用例实现（适用于：签收时需要所有的细节时）
在方法论雷达监控之下，添加诸如用例实现的细节是在正规过程中引入实例化需求说明的一个不错的想法。当商业合同需要对需求进行签收但还允许之后对细节进行变更时，这种做法同样有助于实现实例化需求说明的概念。
4.5警告信号
1、注意频繁改动的测试
同跟踪测试用例失败来统计代码修改来判断测试用例的良莠。
2、当心回退
跟踪回退也是一个很好的方法，可以为引入实例化需求说明提供业务上的支持。它可以帮助团队查明由需求模糊以及需求说明里的功能分歧造成的浪费。
3、注意组织级的失调
事先分析过头、分析不会马上被实现的东西，或者需要分析细节时却滞后了，这些都是过程出现问题的警告信号。
4、当心“以防万一”的代码
实例化需求说明可以显著减少这种问题（开发人员的以防万一的过度设计），因为它会帮助我们建立共识，让我们知道要交付什么。
5、注意霰弹式修改
这个信号同样适用于活文档：如果对生产代码做了某个改动后，发现还需要修改很多可执行需求说明，那说明你有地方做得不对。组织好你的活文档，这样对代码进行一个小改动时，只需要对测试做一个较小的更改即可。这是降低自动化长期维护成本的一个关键步骤。
小结
本书的第一部分开始主要从整体介绍实例化需求的有点；关键过程模式；介绍活文档；以及如何开始改变。很适合想主动实践的组织。本书结合实际的团队项目实例来介绍各种组织实践的情况，具有很好借鉴作用。可以说：我们遇到的问题，书里都有答案。
