SpecDD是一个以需求为核心的混合敏捷开发方法。它旨在提供一个简单的框架，在一系列原则指导下能同时管理敏捷项目和传统项目。
SpecDD中的用户需求，通过需求Epic，MSWordEpic，Spec，以及文档附件进行表达。Spec是对需求条目的规范化表达，并用于量化需求。和Scrum一样，在SpecDD中，一个开发项目的研发过程由一组连续的迭代组成，每个迭代完成一系列承诺的工作项，并交付可执行软件。
不同于单纯的敏捷，SpecDD整合了需求和QA测试过程模型。需求被用来生成产品backlog和开发sprint工作量。QA测试用例可以在开发迭代开始前，过程中，或之后被创建。为了使QA测试实践变得可扩展，建议有一个独立的QA团队与敏捷团队一起合作，以便在开发sprint过程中以及全面回归测试期间进行测试。
什么是SpecDD？
SpecDD为敏捷团队提供了一个实践框架，并将敏捷功能与传统项目管理的最佳实践相融合作为实践指引。
需求通过工件的形式表达在产品backlog上。产品backlog中的条目被消耗并转化生成为可执行的软件，而需求则被完整地保留下来。
需求与QA测试用例相关联，在开发sprint开始前，过程中或之后，创造并完善测试用例。
在SpecDD中，每个开发sprint都含有两个交付件：改进后的可执行软件，和改进后的需求表达。
SpecDD拥抱变更，但是需求和与之相关的变更都应该被记录在案，以保留业务逻辑或创意在创造和完善过程中产生的智慧。
SpecDD提供了一个可扩展的质量模型，同时确保了单个开发sprint的质量和整合后产品的整体质量。
SpecDD的优势
SpecDD通过提高团队的工作效率和创新能力，来实现可扩展的，可重复的成功。
在需求层面标准化团队沟通，将能够提高团队的产品创新能力。
需求和产品backlog的整合，为多团队和大型敏捷项目提供了一个清晰的，可扩展的模型。
独立的QA回归测试团队和引入的QA-floater模式，让全面质量管理更具可扩展性。
它使企业能够在产品需求和商务策略层面上，对敏捷或非敏捷项目进行规划。
量化需求，以驱动开发
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工作量的进展。
SpecDDSprint质量模型
SpecDD框架中，Sprint工作量由一组待实现的Story，开发任务和缺陷组成。在Sprint开始的时候，为开发人员估计每个工作项的工作量，可以使用剩余时间或点数。这里有一个问题：是否需要创建与开发任务同级别的QA测试任务，并作为工作量的一部分？
一个常用的，但不合理的做法是为所有的开发任务创建同级别的QA测试任务，使用同样的办法，为QA测试任务也设定具体的剩余时间，从而驱动QA测试任务的进展。对于一个开发任务，估计剩余时间是可能的，并且能很好地激励任务负责人，在估计的时间内努力完成工作。
然而对于QA测试工作来说，在Sprint开始的时候，将所有可能需要的各种测试任务创建完毕，并且估计剩余时间，实际上是不可能的。更为重要的是，对QA测试总时间的估计，阻碍了建设一个自我驱动的团队。不包含QA测试时间，对于Sprint的总剩余时间，团队总是可以自我驱动的，并将它作为要达成的动态目标。而包含QA测试时间，它只会损害一个自我驱动的开发团队，在他们估计的时间内，努力完成所有开发工作的积极性。
在SpecDD模型中，通过为开发任务建立子任务来表示QA测试工作。对于功能性开发任务，可以基于开发任务所对应的父级需求，生成相应地测试标准。随着需求被充分理解并文档化，团队可以为需求Spec和Story创建测试用例，来准确表达质量标准。对于缺陷修复任务，测试子任务可能并不会与测试用例相关联，因为缺陷描述本身往往就保留了QA测试的标准。下图说明了基于QA测试子任务的SpecDDSprint质量模型。
SpecDDSprint质量模型创造了一种“平衡”的质量控制概念。可执行软件的创造人员，自我驱动并努力将Story和开发任务转化为可执行的软件。QAFloater是可执行软件的保护者，他们为开发任务创建QA测试子任务，以确保开发任务完成之前进行充分的测试。可执行软件的创造者想要燃尽图走的更快，总是主动积极并达成剩余时间估计目标。而保护者则是减缓剩余时间的进展，有时，他们甚至因为发现新的缺陷，而增加了开发任务的剩余时间。SpecDDSprint质量模型为这两个关注面创造了一种动态的平衡，优化了开发产生力和质量保障。
对于每个SpecDD的敏捷开发团队，推荐1-2名测试人员加入开发团队，加入的测试成员称为QAfloater。QAfloater主导测试，并促进最佳测试实践，同时帮助每个敏捷团队成员成为更好的测试人员。建立并完善测试用例，是敏捷Sprint测试实践中的主要产物，以确保高质量的Sprint。测试用例将被保存于测试用例库中，完整的测试用例库未来会进一步指导测试团队的全面回归测试。
SpecDD回归测试模型
在QAfloater和测试子任务模型下，一个理想的SpecDDSprint将能够交付一个没有缺陷的可执行软件。但现实中往往是，在多个Sprint迭代后，相互集成的产品，势必会有一些缺陷。没有一个稳固的回归测试实践，多团队参与的大型项目，无疑将缺乏质量控制和可扩展性。
SpecDD使用测试用例，并与运行时的环境变量相结合，正规化表达并量化产品的质量。QA测试计划为产品的发布指定了测试标准。为了更加灵活高效地执行测试计划，常常使用测试周期来表示较小的测试迭代，一个测试周期可用于覆盖QA测试计划可能产生的所有任务的一个子集。
一个测试周期包含一组测试任务，测试任务是基于测试用例与运行环境变量排列组合下产生的具体实例。可以手动或使用自动化测试工具，来执行这些测试任务。下图反映了开发迭代周期与QA测试周期的关系。
正如您所看到的，QA测试周期的规划和执行，不一定同步于开发迭代周期。当您想将新发现的缺陷分配到当前进展中的Sprint时，敏捷开发方法会要求测试团队只能将缺陷提交到产品Backlog中。QA回归测试团队负责提交缺陷，但是他们并没有权利决定何时修复这些缺陷。拥有一个独立的测试团队，更早地发现缺陷，并在产品Backlog中对缺陷进行优先级排序，实际上有助于创造一个更加灵活的敏捷过程。
结论
敏捷技术，正成为一个个构建基石，嵌入到其他开发方法。有了这样的信念，SpecDD为团队提供了指引，将敏捷技术与团队现有实践进行最佳的融合。
对于使用瀑布模型的团队，SpecDD帮助他们扩展了需求管理，并支持产品Backlog。随着产品Backlog的优先级排序，团队可以开始尝试较短的迭代开发，同时通过燃尽图和每日敏捷练习，创造自我驱动的团队。伴随需求驱动的开发和质量的实践，他们很快就会看到生产率的提高。
对于已经实践敏捷开发的团队，SpecDD有助于全面整合需求管理与产品Backlog，实现需求完整可追溯。通过引入敏捷SprintQA测试，并建立一个独立的QA团队来执行回归测试，使得多团队参与的敏捷项目变得更具有扩展性。
作者简介
周铁人，毕业于美国Kansas州立大学，获计算机科学专业硕士学位和人工智能专业博士学位；在攻读博士学位期间，他致力于实验室自动化、概念建模、机器人技术和人工智能的研究。如今，作为"以知识为核心"的应用生命周期管理（ALM）领域内的专家，周铁人博士提倡以知识为核心的软件过程改进，并针对当今的分布式开发团队和服务支持团队的特点和需求，设计开发TechExcelALM解决方案，帮助企业全面管理软件生命周期内的各个流程，从概念形成、设计规划、到开发实施和产品交付。周博士曾参与过全球最大的开发团队的培训及实践工作，其独创的SpecDD混合的敏捷开发方法论，已成功指导和应用于EA、SONY、RIM、联邦快递等国际知名企业，优化了QA和需求管理相整合的敏捷过程，组织推动了均衡和可扩展的敏捷开发方法论。
