敏捷开发用短短十年时间发展为当今最为广泛使用的开发方法，其原因在于它简单且有效地提高了开发团队的生产率。敏捷方法指导团队将产品需求置于Product Backlog中管理，并按照优先级对每个产品需求进行必要的排列；通过计划会(Planning Meeting)、Daily Standard Up Meeting(每日立会)、Project Review Meeting(评审会)等，从Product Backlog中挑选最重要的Willing List（意向表），分配到团队的每个Sprint 研发过程中。高效、灵活的保证了可执行产品的交付，并让用户更早提出修改意见。

  但是敏捷方法的普遍使用中，又发现了单纯敏捷方法的局限性：

•         缺少对多团队参与的大型项目的指导框架；
•         缺少开发和QA测试的整合模型；
•         无法支持需求驱动下完整的可追溯性；
•         整个团队完全致力于项目的开发是基本前提，一旦开发团队的方向出现变化，会导致项目的崩溃，因为需求总在变化；
•         一旦使用敏捷方法失败，不但时间会被浪费，团队人员也会出现松动。当相关人员离职后，整个过程的经验积累也无法得以保存。

        因此敏捷的自身发展又反过来推动了敏捷方法和其他开发方法的相互整合。当今超过75%的企业敏捷项目，采用了多个方法相融合和杂化的敏捷过程。

例如版本V1.0 采用单一敏捷方法（Scrum）；V2.0采用传统方法（瀑布）；V3.0采用敏捷和传统方法相结合。

      理想的敏捷开发方法的基本理念：软件是构想、功能设计和技术设计相结合的产物，只要设计完善，任何好的开发团队都能实现它。

      以Scrum为代表的单纯敏捷方法论指导将产品需求置于产品待办目录（Product Backlog）中管理，并按照优先级对每个产品需求进行必要的排列。但实践调查发现更多大型项目的成功，依赖于通过需求工作流、需求分析和需求可追溯性，来系统化管理需求，从而在需求层面上对项目做整体规划和控制，高效、灵活地向客户交付可执行产品，并保证交付结果的正确性。

同时以Scrum为代表的单纯敏捷方法缺乏质量控制的考虑，我们来思考以下观点是否正确？

•        尽可能多的测试以保证每个Sprint交付的可执行软件完全没有缺陷；
•        好的Sprint 开发过程应当保证产品完全没有缺陷；
•       缺陷在Sprint 开发过程中应当被发现；
•       缺陷应当在当前Sprint中全部被修复。

因此传统的敏捷开发需要结合与需求管理和质量控制的考虑，SpecDD的建立，解决了Scrum在需求层面上，以及团队合作上的缺陷、质量保证等问题。

 什么是SpecDD？

      SpecDD是一种管理软件研发过程的混合型敏捷方法，它基于同时支持敏捷和非敏捷研发过程而设计，使得开发团队能用相同的办法来管理敏捷和非敏捷项目。SpecDD框架中包含了产品负责人、项目经理、测试主管、开发团队和测试团队五个角色。在SpecDD 模型中，一个项目的研发过程通过三个空间来进行表达，即，需求空间、研发空间和QA测试空间，三个空间是相互完全整合的。

       在SpecDD模型中，开发工作被分解到开发空间、里程碑和各个冲刺迭代中，同时Product backlog和需求管理是相互整合的。此外，SpecDD提供了明确的指导方针，以及如何实践的做法，实现QA测试用例在开发迭代周期内被定义；借助这样的模型，使得QA团队既能够独立工作，同时又能与回归测试相整合。SpecDD解答了在现实项目中，如何有效地实现敏捷开发与需求和质量的整合。

 SpecDD 过程模型
 
SpecDD追溯性模型