敏捷管理之对比Scrum和看板方法

系统范围

在讨论 Scrum和看板方法之前,我觉得有必要澄清系统范围。在 Scrum里,系统范围由“产品的定义”和“完成的定义”决定;而在看板方法里,看板系统的边界定义了系统范围。

Scrum的运作是围绕产品的,每个迭代开始时,从产品待办列表挑选进入下一个迭代的故事,迭代结束将故事做到完成。故事的范围是由产品的定义决定的,故事在产品范围内是端到端的。“完成的定义”体现了故事可交付的程度,也就定义了价值流的终点。

看板系统的边界定义了价值流的范围,由此决定故事的范围。故事将要流过整个看板系统,其终点状态完成的定义也就相当于 Scrum中“完成的定义“。

需要指出的是, Scrum的系统范围定义通常是基于组织结构的,它涉及产品的定义和团队的组建,产品待办列表要与团队相对应,因此系统边界相对严格;而看板的系统范围定义只基于在统一的看板系统做可视化和管理流动,因此系统边界相对宽松。这也跟两者不同的变革导入思路有关。

两者都有一个思想,即尽可能地扩展系统范围,以利于管理整体的价值流动和实现。只是体现出来的不同:对 Scrum而言，是产品定义的扩展和完成定义的扩展;对看板方法而言,是看板系统边界的扩展。

在我看来,无论 Scrum还是看板方法。都希望帮助到价值交付和持续改进,但各自采取不同的方式。最显著的差别在于、 Scrum采用选代而看板方法采用流。

价值交付

Serun和看板方法都致力于最大化价值交付,无论是采用选代还是流,关键都在于减少在制品。在制品由进行中故事的个数和故事的大小决定。

当采用选代时,限制故事的个数是间接的,选代长度间接限制了故事的个数。当采用流时限制故事的个数却是直接的。

故事的大小是另一个影响在制品多少的因素。迭代会推动故事的拆分,因为在选代结束时要求能够将故事完成。然而,把故事拆得过小会使拆分变得不自然(也就是为了拆而拆)。反而降低了那些拆出来的故事的价值。故事不能无限拆分改事在有价值的前提下能拆多小通常有其自然的限制。采用达代,有可能会人为破坏故事的自然大小和完整性,而采用流则更遵从故事本来的颗粒度。

持续改进

Scrum和看板方法都致力于持续改进,无论是采用选代还是流,关键都在于创造合适的挑战来驱动改进。当改进目标达成后,。改进就会陷入停滞,而持续改进却需要永不停歇。

Scrum和看板方法都是通过提升目标来再次创造合适的挑战以使改进继续,但是提升目标的方式却不同。

Scrum里最重要的改进目标是在选代结束做到完成。这里有两个变量,选代长度和完成的定义。通过改进做到选代结束完成后,我们会看完成的定义是否可以扩展。扩展后完成的定义产生了新的挑战。从而提供了继续改进的动力。当完成的定义已经达到可以交付时,我们会看是否可以缩短迭代长度,进而又能驱动进一步的改进。

看板方法的改进目标一方面来自于直接的在制品减少。通过在制品限制的降低,系统更多问题被暴露出来,从而驱动改进。另一个重要的因素是围绕前置时间的改进,前置时间的缩短对价值交付和提升灵活性都有帮助,因此是一个很好的改进目标。

变革导入

最后想说的是关于 Scrum和看板方法的变革思路。我理解的根本在于改善(小变化)和改革(大变化)的平衡。如果引入过大变化,由此产生的挑战过大,结果往往会适得其反。如果过于保守而引入过小变化,会使变化过于缓慢,甚至逐步丧失了改革的能力。

Scrum的有效运作需要组织设计,在我看来,它的第一步是改革,然后由每个迭代回顾驱动持续改进。看板方法尊重现有的组织结构,从现状出发,因此它的第一步更接近改善,

然后也是持续改进。对两者而言,持续改进理论上引发改善或者改革都有可能,实际中发生更多的是改善。

当变革涉及系统范围的扩展时, Scrum要求组织结构要发生改变,而看板方法要求的最小改变只是放在统一的看板上进行可视化管理,因此更能反映“可能的艺术”。然而,当现有的组织结构制约了协作模式并最终影响到价值流动时,组织结构仍然需要有所突破。

敏捷管理系列内容：点击查看列表