近一段时间在关注一种新的敏捷模式，当然这里说新，是由于目前很少看到有项目在应用，其实这种模式很早已经诞生了。一个偶尔的机会，在苦寻敏捷测试的过程中，无意中看一本书，关于如何提高敏捷过程中需求、开发和验收的测试效率，让我很是感兴趣，这本书名《实例化需求：团队如何交付正确的软件》。可能是由于翻译的原因，读起来给我的帮助并不是那么大，但至少先让初步了解他的思想，我想这是大的帮助了，因为我确实接受了他。

　　关于如何处理需求说明与测试，不同的组织使用不同的名称，或者说是不同的定义，但他们都有一套共同的核心原则与思想，而且当你接受他了之后，我们便可以认为他们本质上是一致的。通常有如下定义：

　　● 敏捷验收测试

　　● 验收测试驱动开发

　　● 实例驱动开发

　　● User Story测试

　　● BDD行为驱动开发

　　● 实例化需求说明（Specification by Example）

　　对于以上的概念，我想大家都不陌生，但可能都是一个概念，因为没有实践。当具体去实践，其实发现跟我们平时的流程相对也很容易理解，只是方式不一样，或者执行流程不一样，当然这里要说的是不同，那是方法。方法都是总结出来，多实践之后，提炼出来的是适合我们的方法。如同我们在实施了一段时间之后，突然有有人问我什么是BDD（行为驱动开发），我发现我很疑惑，我不理解。但细想，我现在做的流程不是BDD吗，而我现在做的流程准确来说被定义为实例化需求，但这个概念似乎不能把开发和测试给拉进来，而用BDD来定义，似乎一瞬间把需求、设计、开发和测试拉绑定在了一起。

　　何为BDD？其实是通过真实用户的行为来定义我们需要开发出什么样的产品来，个人理解。但再结合实例化需求，会发现，我们是把用户的行为通过一个实例化的过程描述出来，然后整理成设计、开发和测试都能看懂的，当然重要的是用户也能看懂，而且用户看完之后认可，这是我想要的，这是BDD，也是实例化需求过程。

　　它既不是传统的需求文档，也不是设计文档，更不是测试用例文档，但适用于从需求、设计、开发和测试的每一个阶段，而且都是从用户的角度为出发点的。那我认为那是我们想要的过程模式。

　　以下为实例化需求说明的主要过程模式：

　　当我们获取一个业务目标时，将按照上述流程图来生产实例化需求过程

　　● 从目标中获取范围

　　通过用户提供的需求描述，我们将这些描述转变成另一种用户能够理解且真实用户实际地行为方式，这里要引入User Story用户故事的概念。然后以客户的业务目标为起始，然后通过协作界定可以实现目标的范围。这里关键的是与用户更密切地沟通，通过不断细化，确认这才是用户想要的功能。

　　● 从协作中制定需求说明

　　之所以要提出协作制定需求说明，目的是让需求、设计、开发以及测试都参与进来，发挥整个Team的知识和经验，力求让项目的干系人都更多的参与到交付过程中。

　　● 举例说明

　　举例说明其实是项目需求交流过程中不可或缺的，团队中不同职能人都有，而且每个人的业务背景不同，通过举例说明的方式可以让目标更一致。

　　● 提炼需求说明

　　协作过程中的开发讨论可以建立大家对相关领域的共识，但终得到的实例往往包含很多不必要的细节。而关键实例必须是精简的。提炼需求说明的过程，其实伴随着实例化需求的产生，且这些提炼好的实例可以当作交付的验收条件。

　　● 频繁验证

　　频繁验证的依据是提炼需求产生的实例化需求，它是所有过程实施中都必须要反复进行的工作。需求通过频繁验证与用户进行频繁确认；设计通过实例化需求来频繁验证设计是否满足用户的需求；开发通过实例化需求频繁验证代码中业务逻辑；测试通过实例化需求来频繁验证交付的功能，并作为后验收测试的依据。

　　● 演化出一个文档系统

　　通过以上的这些流程，后演化出一个文档系统。之所以称为文档系统，主要是体现它的可靠性、权威性。所有设计、开发、变更以及测试过程都以此为出发点来考虑，并及时更新，长久维护。

　　实例化需求过程的核心是与用户站在一起，从沟通开始，不断举例、细化、精简到统一确认。