Overview of "Hybrid Agile Development"
Agile development has become the most popular development method today. Many development teams are gradually moving towards agile development methods, one of the important reasons is that it can rapidly improve the work efficiency of the team, and another reason is that agile methods are considered to be an advanced and popular "smart" development method. If the agile model is not adopted, the development team will always be in an inefficient work situation, and will constantly question the management of the company: why not adopt the most advanced development methods? In the long run , it will eventually lead to even worse consequences: a large loss of excellent developers.
However, when you start to practice agile development, you also face another risk, that is, the value of project management, requirements management and quality management is often overlooked in the agile development process. For example, pure agile development tends to emphasize and focus on the task level. The workload of the project, and the lack of attention to the requirements analysis, overall design and planning, which will lead to the failure of the project.
In actual agile development practices, more than 70% of agile teams have adopted an agile process that combines agile development methods with traditional development methods. In other words, agile development is being strongly required to be used in conjunction with project management, requirements management, and quality management, and in agile processes, effective project governance and control are critical. However, in fact, there is no method in the industry that will teach you how to achieve this integration.
Hybrid development method based on agile: SpecDD ( Specification Driven Development ) came into being, SpecDD is an extensible agile development model, which helps development teams realize the integration of requirements and quality in agile development, and realize agile processes and projects The integration and balance of management help enterprises achieve more success in managing large-scale projects and multi-team collaborative projects.
Organizing and promoting a balance between agile development and project management has obvious benefits but also challenges. Agile advocates individuals and interactions over processes and tools, and seems to eliminate the need for micro-management and project planning management; because its primary purpose is to successfully deliver a product / project to the customer that meets the requirements. In fact, agile development does not exclude project management, but hopes to use appropriate project management and requirements planning to create a better environment for development teams, so that teams can more effectively engage in agile processes.
Agile development is willing to accept changes in requirements, and advocates actively responding to changes rather than sticking to conventions. Many agile teams mistakenly believe that requirements management is unnecessary, and as a result, their agile processes fail to achieve sustainable success. Agile processes rely on a prioritized Product Backlog to properly plan each development iteration cycle. Such a product backlog actually performs proper management of requirements. The requirements management of large-scale projects will be more complex, and the realization of multi-level requirements planning and management is the basis for ensuring the success of large-scale agile projects with multi-team collaboration.
Perhaps the easiest mistake for a company that is just starting out with agile development is adding all the test teams to the agile team. Testers were assigned to each agile team, and as a result, the test department was left vacant, and test managers and test leaders began reporting directly to the agile project leader. In fact, the development team never has full control over the quality of the product. Therefore, the proper integration of the testing process in agile practices enables the effective deployment of agile development in large-scale projects.
SpecDD : Hybrid agile development with full integration of project management, requirements management and quality management
SpecDD is a scalable agile development methodology. It allows teams to use Agile without losing the best-practice principles of traditional development methods. It helps businesses be more successful in managing large-scale projects and multi-team collaborative projects by balancing the following practices.
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和需求管理相整合的敏捷过程，组织推动了均衡和可扩展的敏捷开发方法论。