SpecDD：混合的敏捷开发方法模型概述
敏捷已成为当今使用最广泛的开发方法。值得一提的是，敏捷方法的流行性并不是因为它取代了其他开发方法，相反是与这些开发方法进行了更好地融合。现实中众多敏捷项目的成功，也印证了敏捷将走向混合化的未来。
SpecDD是由周铁人博士创立的一种以需求为核心的混合敏捷开发方法。它基于同时支持敏捷开发和非敏捷开发流程而设计。
SpecDD过程模型
在SpecDD过程中，开发过程由一组连续的迭代组成，这些迭代过程通常也被称为Sprint。一个迭代周期通常持续2-4周，但也可以根据实际情况或长或短。在迭代内，团队对规划的新开发工作做出承诺，并完成开发实现及测试，同时将这些过程记录在案。
通过在SpecDD项目过程中，为每个开发Sprint周期引入敏捷QA测试，同时与独立的QA团队相整合并完成回归测试，来实现高质量的项目交付。具体来说，在开发Sprint内，流动的QA和敏捷团队共同合作，并确保每个开发任务完成的时候都是经过质量验证的。而回归测试团队负责为多个完成的Sprints建立产品集成测试（这些Sprints常常是由多个团队分别完成的），来实现期望的质量标准。伴随开发Sprints的进展需要，建立并执行QA测试计划和测试周期。
如上图所示，一个SpecDD项目从需求管理开始，需求驱动并建立产品Backlog和Sprint backlog等开发工作。基于这些相同的需求，生成相应的QA测试用例。定义好的测试用例存放在测试用例库中，并作为需求的质量标准。然后回归测试团队创建测试计划，并执行多次测试周期。
量化需求，以驱动开发
SpecDD使用Epic和Spec来管理需求。Epic表示一个大概的想法，一般来说往往过于笼统，范围也比较大，因此需要进一步分解为Spec。Spec表示一个新功能或者功能改进，可能需要进一步分解为一个或多个开发任务进行实现。一个Spec，不需要在充分理解需求，或者需求被完整文档化的情况下，才开始实现。随着Spec的开发实现，可执行的软件本身将帮助团队更好地理解原始需求。并常常会为需求添加新的和改进后的文档及附件，包括新的业务逻辑模型、更新后的用户图形界面、以及新的技术设计文档等。
当Spec被分配到产品Backlog时，Story将被创建，用来作为对Spec实现分配的承诺。实际项目中，单个Spec的实现，可能需要生成多个Story，经过多次实现分配才最终完成。
下面的图说明了Spec、Story和任务之间的关系。Spec被分配到开发空间中，生成一个或多个Story。每个Story可以进一步分解为一个或多个开发任务。每个开发任务可能含有一个或多个QA测试子任务。
在SpecDD模型中，需求“驱动”并不意味着需求在驱动开发和质量实践前，需要被完整的定义。Spec 是以客户价值角度，表达的某个产品功能，可能并不包含最初需求的细节。需求Spec的实现过程，与需求Spec的重定义过程，常常并行发生。SpecDD提倡团队使用需求作为交流的标准，并使用文档记录改进后的需求理解，以保存团队在需求决策过程中所做的“智慧”。
SpecDD开发迭代
Sprint工作量来源于产品负责人选定的一组候选功能和缺陷列表。功能以Story的形式分配到Sprint，每个Story包含一些细分的开发任务。缺陷通常以独立存在的开发任务（不与Story相关联）分配到Sprint。
随着任务负责人对各自工作进展的推动，一个个开发任务从初始状态，经过中间状态，并且最终到达完成状态。使用一个简单的敏捷工作流，常常能够帮助团队管理任务的生命周期。SpecDD框架下的任务工作流，往往包含以下几个状态：待分配，处理中，QAFloater验证和完成任务。随着任务负责人每天的进展，剩余工作时间理想情况下，将从最初的估计值不断减少直至为零。伴随开发团队自我管理，自我驱动地完成所有承诺的开发任务，生成的燃尽图报表（例如下图）最佳地展现了团队Sprint工作量的进展。
SpecDD Sprint质量模型
SpecDD框架中，Sprint工作量由一组待实现的Story，开发任务和缺陷组成。在Sprint开始的时候，为开发人员估计每个工作项的工作量，可以使用剩余时间或点数。这里有一个问题：是否需要创建与开发任务同级别的QA测试任务，并作为工作量的一部分？
一个常用的，但不合理的做法是为所有的开发任务创建同级别的QA测试任务，使用同样的办法，为QA测试任务也设定具体的剩余时间，从而驱动QA测试任务的进展。对于一个开发任务，估计剩余时间是可能的，并且能很好地激励任务负责人，在估计的时间内努力完成工作。
然而对于QA测试工作来说，在Sprint开始的时候，将所有可能需要的各种测试任务创建完毕，并且估计剩余时间，实际上是不可能的。更为重要的是，对QA测试总时间的估计，阻碍了建设一个自我驱动的团队。不包含QA测试时间，对于Sprint的总剩余时间，团队总是可以自我驱动的，并将它作为要达成的动态目标。而包含QA测试时间，它只会损害一个自我驱动的开发团队，在他们估计的时间内，努力完成所有开发工作的积极性。
在SpecDD模型中，通过为开发任务建立子任务来表示QA测试工作。对于功能性开发任务，可以基于开发任务所对应的父级需求，生成相应地测试标准。随着需求被充分理解并文档化，团队可以为需求Spec和Story创建测试用例，来准确表达质量标准。对于缺陷修复任务，测试子任务可能并不会与测试用例相关联，因为缺陷描述本身往往就保留了QA测试的标准。下图说明了基于QA测试子任务的SpecDD Sprint质量模型。
SpecDD Sprint质量模型创造了一种“平衡”的质量控制概念。可执行软件的创造人员，自我驱动并努力将Story和开发任务转化为可执行的软件。QA Floater是可执行软件的保护者，他们为开发任务创建QA测试子任务，以确保开发任务完成之前进行充分的测试。可执行软件的创造者想要燃尽图走的更快，总是主动积极并达成剩余时间估计目标。而保护者则是减缓剩余时间的进展，有时，他们甚至因为发现新的缺陷，而增加了开发任务的剩余时间。SpecDD Sprint质量模型为这两个关注面创造了一种动态的平衡，优化了开发产生力和质量保障。
对于每个SpecDD的敏捷开发团队，推荐1-2名测试人员加入开发团队，加入的测试成员称为QA floater。QA floater主导测试，并促进最佳测试实践，同时帮助每个敏捷团队成员成为更好的测试人员。建立并完善测试用例，是敏捷Sprint测试实践中的主要产物，以确保高质量的Sprint。测试用例将被保存于测试用例库中，完整的测试用例库未来会进一步指导测试团队的全面回归测试。
SpecDD回归测试模型
在QA floater和测试子任务模型下，一个理想的SpecDD Sprint将能够交付一个没有缺陷的可执行软件。但现实中往往是，在多个Sprint迭代后，相互集成的产品，势必会有一些缺陷。没有一个稳固的回归测试实践，多团队参与的大型项目，无疑将缺乏质量控制和可扩展性。
SpecDD使用测试用例，并与运行时的环境变量相结合，正规化表达并量化产品的质量。QA测试计划为产品的发布指定了测试标准。为了更加灵活高效地执行测试计划，常常使用测试周期来表示较小的测试迭代，一个测试周期可用于覆盖QA测试计划可能产生的所有任务的一个子集。
一个测试周期包含一组测试任务，测试任务是基于测试用例与运行环境变量排列组合下产生的具体实例。可以手动或使用自动化测试工具，来执行这些测试任务。下图反映了开发迭代周期与QA 测试周期的关系。
正如您所看到的，QA测试周期的规划和执行，不一定同步于开发迭代周期。当您想将新发现的缺陷分配到当前进展中的Sprint时，敏捷开发方法会要求测试团队只能将缺陷提交到产品Backlog中。QA回归测试团队负责提交缺陷，但是他们并没有权利决定何时修复这些缺陷。拥有一个独立的测试团队，更早地发现缺陷，并在产品Backlog中对缺陷进行优先级排序，实际上有助于创造一个更加灵活的敏捷过程。
结论
敏捷技术，正成为一个个构建基石，嵌入到其他开发方法。有了这样的信念，SpecDD为团队提供了指引，将敏捷技术与团队现有实践进行最佳的融合。
对于使用瀑布模型的团队，SpecDD帮助他们扩展了需求管理，并支持产品Backlog。随着产品Backlog的优先级排序，团队可以开始尝试较短的迭代开发，同时通过燃尽图和每日敏捷练习，创造自我驱动的团队。伴随需求驱动的开发和质量的实践，他们很快就会看到生产率的提高。
对于已经实践敏捷开发的团队，SpecDD有助于全面整合需求管理与产品Backlog，实现需求完整可追溯。通过引入敏捷Sprint QA测试，并建立一个独立的QA团队来执行回归测试，使得多团队参与的敏捷项目变得更具有扩展性。
