SpecDD：整合项目管理、需求管理与质量管理的混合型敏捷

“混合型敏捷开发”综述

敏捷开发，现今已发展成为最流行的开发方法。众多开发团队正逐步走向敏捷开发方法，其中很重要的一个原因是因为它能迅速提高团队的工作效率，另外一个原因是敏捷方法被认为是一种先进流行的“智能”开发方法。如果不采用敏捷模式，常会导致开发团队由于一直处在缺乏效率的工作境地，而不断产生对公司管理的质疑：为什么不采用最先进的开发方法？ 长此以往, 最终将造成更为不良的后果：大量流失优秀的开发人员。

不过，当您开始实践敏捷开发的时候，您同样要面临另外一种风险，即敏捷开发过程常常会忽视项目管理，需求管理和质量管理的价值，比如单纯的敏捷开发往往更强调和关注任务层面的工作量，而对需求分析、整体设计和计划不够重视，而这将kenen导致项目失败。

在实际敏捷开发实践中，超过70%的敏捷团队采用了敏捷开发方法与传统开发方法相融合的敏捷过程。换句话说，敏捷开发正被强烈的要求与项目管理、需求管理以及质量管理整合在一起使用，且在敏捷过程中，有效的项目监管和控制是至关重要的。然而事实上，此前业界并没有任何一种方法会教您如何去实现这种整合。

基于敏捷的混合型开发方法：SpecDD（Specification Driven Development）应运而生，SpecDD是一种可扩展的敏捷开发模式，它帮助开发团队在敏捷开发中实现需求与质量的整合，并实现敏捷过程与项目管理的融合与均衡，助力企业在管理大型项目和多团队协作项目中获得更多成功。

组织并推动敏捷开发与项目管理之间的均衡，带来的好处显而易见，同时也带来挑战。敏捷倡导个体和交互胜过过程和工具，看起来似乎不再需要微观管理和对项目的规划管理；因为其首要目的就是向客户成功交付一个满足要求的产品/ 项目。实际上敏捷开发并不是排斥项目管理，而是希望采用适当的项目管理和需求规划，为开发团队创造一个更好的环境，从而让团队能更有效地投入到敏捷过程中。

敏捷开发乐于接受需求变更，提倡积极响应变更而不默守陈规。许多敏捷团队错误地认为需求管理是不必要的，结果导致他们的敏捷过程无法实现可持续的成功。敏捷过程依赖于一个按优先级进行排序的产品Backlog来正确规划每个开发迭代周期。这样的产品Backlog实际上履行了对需求的适当管理。大型项目的需求管理会更加复杂，实现多层次的需求规划与管理是确保多团队协作大型敏捷项目成功的基础。

对一个刚开始实践敏捷开发的公司来说，也许最容易犯的错误就是把所有测试团队都加入到敏捷团队中。测试成员被分配到每一个敏捷团队，结果导致测试部门被空置，测试经理和测试主管开始直接向敏捷项目负责人汇报工作。事实上，开发团队从来无法完全掌控产品的质量。 因此，在敏捷实践中正确的整合测试过程，才能实现在大型项目中有效地部署敏捷开发。

SpecDD：项目管理、需求管理与质量管理全面整合的混合型敏捷开发

SpecDD是一种可扩展的敏捷开发方法。它让团队在使用敏捷的过程中又不失传统开发方法的最佳实践原则。它通过均衡以下实践，帮助企业在管理大型项目和多团队协作项目中获得更多成功。

l  项目管理主要包括：针对项目的生命周期管理，项目成功的准则，执行层的任务跟踪，以及质量管理。

l  需求管理并不苛求百分百的理解和无一遗漏的文档。但是需求必须被正确的表达和量化，从而使得敏捷开发团队能够正确设定产品Backlog的优先级，并成功管理开发迭代周期。

l  质量管理源于正规化表达和量化产品质量。测试团队应当推荐一到两名测试人员加入敏捷开发团队，加入的测试人员主导测试工作，并保持相对独立的工作，同时又与敏捷开发团队共同合作以保证质量。测试团队和测试部门应始终存在，并负责产品的整体质量管理。

l  完整的可追溯性从需求管理开始。在敏捷开发中，产品Backlog不断被消耗和燃尽。生成的燃尽图，常常被用于估计剩余的工作量和跟踪以下工作的完成度，包括需求的完善过程，开发迭代的任务分配过程，以及测试标准和测试计划的执行过程。

l  以Scrum为代表的单纯敏捷方法缺乏对多团队协作大型开发项目的有效管理模型。纯敏捷只针对单一敏捷团队的开发过程。SpecDD的出发点就是融合项目管理、需求建模和质量管理；使得多个敏捷团队能够相互整合工作，从而取得项目的成功。

 

量化需求，以驱动开发

     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团队来执行回归测试，使得多团队参与的敏捷项目变得更具有扩展性。

 

SpecDD创始人简介

      周铁人，毕业于美国Kansas 州立大学，获计算机科学专业硕士学位和人工智能专业博士学位；在攻读博士学位期间，他致力于实验室自动化、概念建模、机器人技术和人工智能的研究。如今，作为"以知识为核心"的应用生命周期管理（ALM）领域内的专家，周铁人博士提倡以知识为核心的软件过程改进，并针对当今的分布式开发团队和服务支持团队的特点和需求，设计开发TechExcel ALM 解决方案，帮助企业全面管理软件生命周期内的各个流程，从概念形成、设计规划、到开发实施和产品交付。周博士曾参与过全球最大的开发团队的培训及实践工作，其独创的SpecDD混合的敏捷开发方法论，已成功指导和应用于EA、SONY、RIM、联邦快递等国际知名企业，优化了QA和需求管理相整合的敏捷过程，组织推动了均衡和可扩展的敏捷开发方法论。