Scrum与SpecDD的工作流区别

作者:TechExcel公司CEO兼首席软件架构师 周铁人 博士   

 概要：

对于纯敏捷，例如Scrum，它的工作流与混合型的敏捷（比如SpecDD）总是会有一些区别，在本博客中，我会用现实工作中的例子来解释这些区别。在Scrum中，工作流经常是非常简单的，一个任务可能仅仅包括了几个状态，开始，进行中，工作完成，关闭。但是在SpecDD中，工作流经常没那么简单，因为质量控制和需求管理也是工作流的一部分。

一个典型的SCRUM工作流

下面的图展示了一个典型的Scrum工作流程，您可以看到，当任务在产品Backlog时，这种任务一般处于待开始状态，当它被分配到某个Sprint中，并且经过Sprint计划会议，任务一般就会进入到下一个叫进行中的状态。然后开发人员会开始处理这些任务，当完成时，任务状态就会被更改到已完成。而在此过程中，QA测试通常也用任务来表示，并且也作为 Story 的子任务。

 

所以，为了精确估计一个开发Sprint的工作量，所有的开发任务与测试任务都会被创建，并为它们估计剩余工作时间。但是会带来一个问题，QA测试的工作量往往很难被估计。

一个简单的Scrum工作流程有以下好处：

• 它很简单。Scrum团队每个成员在Sprint计划会后，会给每个任务给出一个预估的剩余时间，然后接下来每天，每个成员会工作在这些任务上，并且及时更新剩余时间。一个好的团队可以渐进式地完成他们的工作量，也会有一个好看的燃尽图来展现工作进度。
• 它鼓励建立一个自我驱动的团队。当测试任务剩余时间也被估计后，测试工程师需要依靠开发人员的“准时”才能确保他们能在预期内完成任务。并且，即使开发完成了开发工作，测试人员还要依赖开发的质量才能准时完成测试工作。然而，这样的流程已经被证明是可以工作的，当然它是建立在一个高度自我驱动，且能够同时兼顾质量完成任务的团队基础上的。

简单工作流程的缺点也是明显的：

• QA测试工作量很难被正确预估，即便是很有经验的团队。开发人员可以估计完成一个开发工作还需要花多少时间，但是测试工作没法这么估计。一个简单的工作流无法鼓励测试人员去充分测试以保证质量。
• 燃尽图不应该包括剩余的测试时间，燃尽图应该只包括开发的时间。

一个典型的SpecDD工作流

下图展现了一个典型的SpecDD工作流程，正如你看到的，状态被分成了三个组：开发过程包括了待分配，进行中与工作结束；这里面也把测试过程包含了进来，有测试中与测试复查；它同样也把需求过程包含了进来。

QA测试过程主要用于：

• 测试复查：用于那些开发与QA Floater无法重现的Bug
• 测试中：用于那些开发人员或者QA Floater都没法去验证的开发任务。这个状态主要用于敏捷团队从其它测试团队获取帮助。例如，当QA Floater无法完全验证一个Bug是否被正确修复，那么Bug提交者或者有相应测试环境的测试人员就可能会被邀请来帮助验证修复工作。

SpecDD的优点：

• 它有一个更强大的测试保证机制。它能使敏捷团队在充分保证质量的同时，又不会失去自我驱动完成任务的灵活性。
• 燃尽图主要是基于开发实现工作的剩余时间来生成的。测试任务更多是作为开发任务的子任务存在的。任何时候，测试任务不仅可以由QA Floater生成并完成，而且还可以从其它非敏捷团队中“借调”测试人员来完成。
• 当需求不够明确时，当产品负责人需要协调需求定义或者界面设计时，这些过程都可以作为工作流的一部分来正规化管理。

SpecDD的相对难点：

• 它不是很简单
• 它可能需要更多时间让团队来学习与测试和需求相互整合的敏捷过程。对于那些正在使用简单敏捷方法的团队来说，或许没法很快接受这个相对复杂的敏捷流程