概要：
对于纯敏捷，例如Scrum，它的工作流与混合型的敏捷（比如SpecDD）总是会有一些区别，在本博客中，我
会用现实工作中的例子来解释这些区别。在Scrum中，工作流经常是非常简单的，一个任务可能仅仅包括了
几个状态，开始，进行中，工作完成，关闭。但是在SpecDD中，工作流经常没那么简单，因为质量控制和需求管理也是工作流的一部分。
一个典型的SCRUM工作流
下面的图展示了一个典型的Scrum工作流程，您可以看到，当一个任务在产品Backlog中，这种任务一般状态
叫做待开始状态，当它被分配到一个Sprint中，并且经过Sprint计划会议，这个任务一般就会下一个状态叫
做进行中。然后开发人员会开始这些任务，当完成时，这个任务状态就会被更改到已完成。而在此过程中，
QA测试这个环节通常是只是作为这个任务的子任务来完成。
所以，为了精确地估计一个开发Sprint的工作量，所有的开发任务与测试任务都会被创建，然后通过剩余时
间来预估工作流，但是会带来一个结果，QA测试的工作量很难去估计出来。
一个简单的Scrum工作流程有一下好处：
-
它很简单。Scrum团队每个成员在Sprint计划会议后会给每个任务给出一个预估的剩余时间，然后接下来每天，每个成员会工作在这些任务上，并且及时更新剩余时间。一个好的团队可以渐进式地完成他们的工作量，然后也会有一个好看的燃尽图来展现工作进度。
-
它鼓励建立一个自我驱动的团队。当测试任务也预估完以后，测试工程师需要依靠开发人员的“准时”才能确保他们可以预期完成任务。然后即使开发已经完成了他们的开发工作，测试工作还要依靠开发的质量才能保证能够准时完成测试工作。然后，这样的流程已经被证明是可以工作的，当然它是建立在一个高度自我驱动来完成任务并且兼顾质量的团队基础上的。
简单工作流程的缺点也是明显的：
-
QA测试工作量很难被正确预估，即使是很有经验的团队。开发人员可以估计完成一个开发工作需要花多少时间，但是测试工作没法这么估计。一个简单的工作流也没有鼓励测试人员去
充分测试以保证质量。 -
燃尽图不应该包括剩余测试时间，燃尽图应该只包括开发的时间。
一个典型的SpecDD工作流
下图展现了一个典型的SpecDD工作流程，你会看到，状态被分成了三个组：对于开发工作包括了待分配，进行中与工作结束；这里面也把测试过程包含了进来，有测试中与测试复查；它同样也把需求过程包含了进来。
QA测试过程主要用于：
-
测试复查：用于那些开发与QA Floater无法重现的Bug
-
测试中：用于那些开发人员或者QA Floater都没法去确认任务。这个状态主要是用于敏捷团队从其它传统测试团队获取帮助。当QA Floater没法完全确认一个Bug是否被修复，那么原始的提交者或者有相应测试环境的测试人员就会被要求来帮助确认Bug的修复。
SpecDD的优点：
-
它有一个更强大的测试保证机制。它能使敏捷团队在充分保证质量的同时又不会丢掉驱动任务完成的灵活性。
-
它使得燃尽图主要是基于开发工作的剩余时间来计算。测试任务更多是作为开发工作的子任务存在的。测试任务不仅可以由QA Floater在任何时候添加，而且还可以从其它非敏捷团队中“借”测试人员来完成。
-
当一个需求不是很明确，产品负责人必须介入进来协调需求定义或者界面设计的时候，这个过程就可以作为正式工作流的一部分。
SpecDD的相对难点：
-
它不是很简单
-
它可能需要很多时间让团队来学习这个可以与测试/需求集成的敏捷流程。对于那些可能参与过简单敏捷方式的团队来说，或许没法很快接受这个相对复杂的敏捷流程
对于纯敏捷，例如Scrum，它的工作流与混合型的敏捷（比如SpecDD）总是会有一些区别，在本博客中，我 会用现实工作中的例子来解释这些区别。在Scrum中，工作流经常是非常简单的，一个任务可能仅仅包括了 几个状态，开始，进行中，工作完成，关闭。但是在SpecDD中，工作流经常没那么简单，因为质量控制和需求管理也是工作流的一部分。
一个典型的SCRUM工作流
下面的图展示了一个典型的Scrum工作流程，您可以看到，当一个任务在产品Backlog中，这种任务一般状态 叫做待开始状态，当它被分配到一个Sprint中，并且经过Sprint计划会议，这个任务一般就会下一个状态叫 做进行中。然后开发人员会开始这些任务，当完成时，这个任务状态就会被更改到已完成。而在此过程中， QA测试这个环节通常是只是作为这个任务的子任务来完成。
所以，为了精确地估计一个开发Sprint的工作量，所有的开发任务与测试任务都会被创建，然后通过剩余时 间来预估工作流，但是会带来一个结果，QA测试的工作量很难去估计出来。 一个简单的Scrum工作流程有一下好处： 它很简单。Scrum团队每个成员在Sprint计划会议后会给每个任务给出一个预估的剩余时间，然后接下来每天，每个成员会工作在这些任务上，并且及时更新剩余时间。一个好的团队可以渐进式地完成他们的工作量，然后也会有一个好看的燃尽图来展现工作进度。 它鼓励建立一个自我驱动的团队。当测试任务也预估完以后，测试工程师需要依靠开发人员的“准时”才能确保他们可以预期完成任务。然后即使开发已经完成了他们的开发工作，测试工作还要依靠开发的质量才能保证能够准时完成测试工作。然后，这样的流程已经被证明是可以工作的，当然它是建立在一个高度自我驱动来完成任务并且兼顾质量的团队基础上的。 简单工作流程的缺点也是明显的： QA测试工作量很难被正确预估，即使是很有经验的团队。开发人员可以估计完成一个开发工作需要花多少时间，但是测试工作没法这么估计。一个简单的工作流也没有鼓励测试人员去
充分测试以保证质量。 燃尽图不应该包括剩余测试时间，燃尽图应该只包括开发的时间。 一个典型的SpecDD工作流
下图展现了一个典型的SpecDD工作流程，你会看到，状态被分成了三个组：对于开发工作包括了待分配，进行中与工作结束；这里面也把测试过程包含了进来，有测试中与测试复查；它同样也把需求过程包含了进来。
QA测试过程主要用于： 测试复查：用于那些开发与QA Floater无法重现的Bug 测试中：用于那些开发人员或者QA Floater都没法去确认任务。这个状态主要是用于敏捷团队从其它传统测试团队获取帮助。当QA Floater没法完全确认一个Bug是否被修复，那么原始的提交者或者有相应测试环境的测试人员就会被要求来帮助确认Bug的修复。
SpecDD的优点： 它有一个更强大的测试保证机制。它能使敏捷团队在充分保证质量的同时又不会丢掉驱动任务完成的灵活性。 它使得燃尽图主要是基于开发工作的剩余时间来计算。测试任务更多是作为开发工作的子任务存在的。测试任务不仅可以由QA Floater在任何时候添加，而且还可以从其它非敏捷团队中“借”测试人员来完成。 当一个需求不是很明确，产品负责人必须介入进来协调需求定义或者界面设计的时候，这个过程就可以作为正式工作流的一部分。 SpecDD的相对难点： 它不是很简单 它可能需要很多时间让团队来学习这个可以与测试/需求集成的敏捷流程。对于那些可能参与过简单敏捷方式的团队来说，或许没法很快接受这个相对复杂的敏捷流程