“ScrumBan”是一种周期发布过程，融合了Scrum（周期发布）和Kanban（流水线发布），是经典Scrum过程的改良成果。这种模式更适合分布式团队，更贴近实际生产流程，后续也有非常高的可拓展性。
Scrum
理想情况下，Scrum过程累积流图应该是这样的：
我们会筛选部分任务进入迭代清单，完成任务后，任务的点数被持续燃尽，直至迭代完成并发布。
但实际情况下的迭代过程，往往会在迭代开始时加任务，迭代临近结束时砍任务，导致在发布前夕遭遇大量瓶颈。
Kanban
在看板过程中，我们会筛选出“在制品清单”，每完成清单中的一个任务，就会新增一个新任务进入在制品序列。这一过程持续进行，直至特定的发布节点。
值得注意的是，由于精益思想提倡避免任务闲置、消除浪费，所以在Kanban过程中，在制品往往不以工作量或点数为度量单位。Kanban只限制任务个数，保证每个任务都“在制”，一个任务无论工作量是1天还是9天，都需要赋予同等的关注度。相比之下，Scrum团队则认为一个耗费9天的任务，约等于9个耗费1天的任务，并以此类推。Kanban的在制品限制，简单高效的保证了流水线上的每个任务都尽可能快速的完成，不需要预估，也提供了一种更自然的工作方式来处理单个迭代内无法完成的任务。
ScrumBan
在一个理想化的ScrumBan过程中，我们采用经典的Kanban方法来启动一个迭代。而在临近迭代尾声、准备发布时，则会采取一些措施，如图所示：
筛选过滤：排除在此次发布计划内无需完成的任务，并转移至下一发布计划中，这是任何一种定期发布过程都不可或缺的关键环节。在上图中，我们以一次性筛选的形式标识出了这个筛选过滤过程，而在实际情况中，一旦我们发现有任何无法及时完成的任务，都应该果断考虑及时过滤、筛选和取舍。
需求冻结：禁止再向现有的生产列表中新增任务，这样才得以正常燃尽列表中仍未完成的任务及问题（或如图所示，燃起已完成任务），保证稳定发布。
稳定期：以稳定发布为目标，完成或移除任务，并持续修复问题的过程。此时累积流图会在迭代尾声开始逐渐收敛，但需要特别注意一个原则：在这个发布计划彻底完成之前，不建议开发转移到新的开发任务上。这个原则同时也会带来一些潜在的心理压力，来推进发布计划更快更好的完成。
稳定期常常占据了整个发布周期的1/3左右，这种情况下如果要顺利完成一个发布计划，比较建议的做法是：当发布周期进行到2/3的节点前后，就开始采取相对激进的筛选过滤和需求冻结措施。当然，如果能做到尽可能地缩短稳定期，就可以考虑采用纯Kanban的方式了。
但如果你正在采用Scrum迭代的方式，那么建议你从下个迭代开始尝试ScrumBan吧！你将会get：
- 再也不用做估算和迭代计划啦！特别是在管理一个或多个分布式团队（比如下面会提到的Constant Contact项目团队）时，团队对于迭代计划很难达成一致意见，问题多多。去除了估算和迭代计划的环节后，大家就可以更专心地做设计和写代码啦！
- 可以随时修复bug了！要知道在理想化Scrum模型中，如果bug修复任务插入到独立的开发任务队列，通常会被视为极大的干扰。
下图是Constant Contact的Gil Irrizarry团队实际的累积流图，可以对比上文提到的理想化ScrumBan模型，找找存在哪些异同：
长按二维码关注