Scrumban [R]Evolution
您目前处于:技术领导力  2017-03-30

如何定义Scrumban,它的起源?

Scrumban既是一种理念体系,又是一种管理框架。虽然Scrumban大多起源于Scrum和Kanban方法,但是它并不是这两种框架的混合。

Scrum是敏捷软件开发方法中的一种,它是迭代式的,有一些事先约定的规范。开发团队在规定的时间段内完成事先计划好的一定量的工作,我们把它称为一个冲刺。冲刺结束后,产品经理和团队一些评审所完成的工作。然后他们会一起分析回顾这个冲刺过程,并找出哪些方面可以在下次改进。

作为一个敏捷框架,Scrum旨在帮助人们在做出承诺和可靠地履行承诺时充满自信。有时间限制的Sprint机制和团队评估技术都支持这些成果,但是往往不能在企业环境中很好地扩展(因为相互依赖项不能很快消除,并且很难以有意义的方式来综合主观评估技术)。

Scrumban是如何支持实施敏捷的?

Scrumban是一种拉动式的系统,开发团队不用像原来那样在计划会议上把要完成的工作评审出来,并承诺在冲刺中完成,而是根据用户故事的价值不断地梳理Backlog。Scrum中的会议还是继续召开的,但是节奏更倾向于内容驱动。Scrumban的真正核心点在于WIP的使用,即同时进行的工作要有合理的限制。

Work-in-progress限制,而不是冲刺。在Scrum中,进行中的工作量是由冲刺承诺的总量决定的。但是在Scrumban中,我们并没有给出特定的时间承诺,团队在任务板的相应列上以预设的WIP值来限制自己。目标就是要让卡片在任务板上自左向右不停地流动。如果过多的任务同时进行,就意味着团队不会高质量地完成它们。所以说,应该给每一列都设定一个不允许超越的最大数值。如果某一列的数值超过了WIP限定,所有的团队成员(无论什么角色)都向转到这一列一起把问题解决掉。

采用了Scrumban方法后,我们在团队能力和产品需求之间做出平衡,这样每个人都不会感觉到负担过重,超出承载范围。从设计之初,我们就追求产出而不是漂亮的数据。它可以把更多实际工作时间还给团队,避免不必要的会议。更重要的是,由于它限制同时进行中的工作,所以可以保证团队从一开始就高质量地完成任务。Scrumban使得团队不再工作在过载的压力下,提高了效率,保证了较高的客户满意度。

Scrum建议固定sprint时间,而Kanban则重视连续流。在Scrumban里是如何对待时间盒和交付流的?

在许多环境中使用固定时间方法(time-boxed approach)必须解决几个独特的难题。有时,一个团队承担的工作性质导致不能简单地将其切割,使其满足给定的时间盒的限制。这时你就会看到团队会人为地将工作切割成不合适的组块,仅仅是为了使切割后的工作块适合方法论,而不是按照业务需求交付价值。有时,在一个同步的节奏上将验收工作与交付工作紧密结合是没有意义的。例如,如果你在一个快速变化的市场中运行,即使是两周一次的交付和反馈节奏对真正的敏捷而言也是嫌长的。

Scrumban同时支持时间盒和持续流。


看板的五个核心实践

核心实践1:可视化工作(价值)流

看板开发方法把可视化工作流作为基础实践,先让价值和价值流动具体可见,然后才是管理和优化。

图中的每个卡片代表一个价值项,如:功能需求、缺陷、技术概念验证等。它们所在的列,表示其所处的阶段。

价值流动可能会被阻碍。比如,编码因对第三方接口错误而无法进展;测试因没有设备而停滞。

核心实践2:显式化流程规则

显式化流程规则,是指明确定义和沟通团队所遵循的流程规则。价值项的“流转规则”是看板开发方法中最典型流程规则,它定义了一个价值项从一个阶段进入下一阶段所必须达到的标准。

核心实践3:限制在制品数量

限制在制品数量是看板开发方法的核心机制。在制品数目小于这个数字时,才可以从前一阶段拉入新的工作。图中,分析阶段的在制品限制数目是3,而实际在制品数目是2,可以拉入新的工作。测试阶段的在制品数是3,达到了上限,就不允许拉入新工作。

核心实践4:度量和管理流动

累积流图( cumulative flow diagram -  CFD )

最初,Scrum开始使用燃尽图来展现完成剩余待办工作所需的小时数(或故事点数)。之后燃烧图也开始被使用。这些图将团队每天完成的功能数量绘制了出来。

这些信息连同速率数据可用于展现某个Sprint/迭代的完成度。

然而,仅考虑到已经完成的的工作还不够。

里特定律(Little’s law)告诉我们交付时间(Delivery time)依赖于在制品数量(Work In Progress, WIP)。WIP是指所有已经初始但还未完成的工作,例如:所有在分析(Analysis)与完成(Done)之间的工作。

如果WIP增加了,你的交付日期就会有风险。

根据约束理论( Theory of Constraints , ToC),每个系统有且只有1个约束(瓶颈)。如何才能识别出工作流程中的瓶颈?根据瓶颈法则( Law of the bottleneck ),你会在吞吐量最低的位置找到瓶颈。

回到我们软件开发的流程上,我们可以将其中每个不同环节(分析、实现、测试、部署、完成)的工作项数量用不同颜色的带状区域可视化出来。

现在观察一下,是否有一个区域的在变窄,同时在流程中相对于这个环节之前的环节正在变宽。

如果你看到了这种情况,就可以用上面提到步骤来解决瓶颈。

要留意的是,当我们看到了一个瓶颈, 我们会本能的认为,我们需要更多资源。但是,这通常是代价最大的方法 ,并且通常不是最好的解决方法 。

在制品数目和周期时间

周流量图


核心实践5:协同改进(Improve Collaboratively)

David J. Anderson这样定义看板开发方法:看板定义了我增量、渐进地改变技术开发和组织运营的方法。它的核心机制是限制在制品数量的拉动系统,通过它暴露系统运作(或流程)的问题,并激发协作以改进系统。


Reference:

http://itindex.net/detail/46781-解析-产品-开发

http://www.infoq.com/cn/articles/book-review-scrumban-revolution

http://www.tuicool.com/articles/YFFr2mA


转载请并标注: “本文转载自 linkedkeeper.com ”  ©著作权归作者所有