书中指出，实例化需求仅仅只是防止退化的有效条件。从保证软件质量角度，实例化需求所做的长期投资并不是非常划算。
以文档为中心的模型所具有的好处： 交付团队应该把测试文档看做是一个单独工件，与交付的系统等同重要。把文档当成关键性交付物是以文档为中心的模型最核心的部分。 增强技术结构或者澄清测试意图不再是技术负债！ 把验收测试的工作交给初级开发人员和测试人员是有问题的！
实例化需求说明的两种模型 BDD，ATDD及其应用场景。 实例化需求说明的创建是循序渐进的。 活文档是交付过程中的重要工件，与代码一样重要。 侧重于建立业务流程文档系统可以帮助你避免长期维护需求说明和测试脚本造成的大部分常见问题。
改变过程，改变团队文化过程的改变可以从以下几点做起：如果已经在进行一个过程变更，那么就通过它实现实例化需求说明的主要思想。将实例化需求说明的思想当做改善产品品质的灵感。为那些没有自动化功能测试的团队，实施功能测试的自动化。对那些自动化测试与开发环节脱离的团队，引入自动化的可执行需求说明。对那些时间测试驱动开发的团队，使用TDD作为下一步的踏脚石。
团队文化的改变从以下几点做起：避免使用“敏捷”术语。从帮助团队提高质量和开发效率的一点一滴做起，每一步都起到实效。获取管理层支持。因为需要显著改变工作方式，不可避免会遇到阻力。把实例化需求当做是比执行验收测试更好的方式来推销。
传统意义上，构建正确的产品需要庞大的功能需求说明、文档以及漫长的测试阶段。如今，软件每周都要有交付，这一套已经行不通了。我们寻求的方案要能带来如下好处。
避免过度说明需求从而产生浪费，避免花时间在开发前会发生改变的细节上。有一种可靠的文档，可以解释系统的行为，据此我们能容易修改系统行为。
可以有效地检查系统行为与需求说明的描述是否一致。以最少的维护成本维持文档的相关性与可靠性。
适合短迭代和基于流的过程，这样能为即将开展的工作提供即时足够的信息。
互联网时代，交付速度是当今软件开发的主题。十年前，项目通常要持续好几年，并且项目阶段是以月来衡量的。如今，多数团队的项目周期是按月来衡量的，而项目阶段则减少到几周甚至几天。任何需要长远规划的东西都将被抛弃，比如大量的前期软件设计和详细
的需求分析。超过项目阶段平均周期的任务将不复存在。变化频率如此之高，文档很快就会过时。不断更新详细需求说明和测试计划需要投入大量精力，相当浪费。那些以往在日常工作中依赖于此的人们，如业务分析师或者测试人员，在这个每周迭代的新
环境中经常会无所适从。开发人员原本以为不会受到纸质文档缺失的影响，现在却要把时间浪费在不必要的返工与功能维护上。他们不是花时间去制订宏伟的计划，而是要浪费数周的时间去修正有问题的产品。
标签：需求,测试,十二月,笔记,说明,实例,文档,阅读,团队 From： https://www.cnblogs.com/-GYP/p/17927008.html