今天，我阅读了《实例化需求》的10-12章。
第10章主要讲了在开发项目的时候，我们需要频繁验证来提高软件的稳定性。在系统对自动化测试支持得不够好的时候，我们需要找出最烦人的问题并将其解决掉，然后不停的重复。解决掉其他的烦人的问题，最终的系统将会变得非常稳定。在遗留系统中引入自动化测试时，用持续集成测试历史来找到不稳定的测试。只要可执行需求说明在持续构建系统中运行，我们就可以从测试的运行历史中看到哪些测试最不稳定。然后需要搭建专用的持续验证环境。如果你的应用程序需要部署，并且要运行功能测试，那么保证可重现性的第一步就是确保专用的部署环境。然后就是使用全自动部署，这样可以确保所有的开发人员拥有和测试环境一样的系统部署。在有外部参考数据源时，可以为外部系统创建较简单的测试替代品。在有外部系统参与其中时，要选择性地隔离外部系统。在大型、多级组织中。可以尝试多级验证。
读完第10章，我知道了我们在开发项目的时候，需要频繁地验证可执行需求说明，以确保它们的可靠性。再具体的环境下。使用具体的方法。
第11章主要讲了实现活文档系统的做法。首先先讲了我们不要创建冗长拖沓的需求说明。因为需求说明越长越难以理解。不要使用许多小的需求说明来描述单个功能因为大量类似的代码可能会混淆视听。然后我们需要从更高的抽象层次仔细去查看需求说明所描述的内容。然后讲述了活文档在开发过程中的作用，也提出了对活文档的要求。前后结构和语言必须保持一致。活文档必须组织得井井有条，便于访问。最后我们需要按照活文档上面所描述的进行测试。
读完第11章，我知道了为了尽可能发挥活文档的优势，应该保持其一致性。并确保单个可执行需求易于理解。
第12章主要讲了 uswith的成功经验，首先它们开始改变流程，从2007年的瀑布开发流程到08年的Scrum到最后引入需求说明工作坊，新的组织结果让他们更频繁地发布软件。第二步优化流程，它们创建了一个环境，只用于持续验证。解决了稳定问题。第三步，它们每一步的流程都由团队讨论，然后确定优先级。最后他们的软件质量大幅提高了，转化率也增长了。
读完第12章，我知道了uSwith成功的原因是因为他们专注于提高质量，而不是尝试实施任何特定的流程。为了提高质量而寻求改变。