敏捷Scrum中蕴含第一性原理来降维打击

最近敏捷小伙伴们在讨论Scrum与Kanban的区别,还有一些伙伴趁着清明节使劲地挖坟考古。我也来谈谈看法。本文无意考古和展开某种方法论,而是试图以“第一性原理”来探讨事情的本质。

第一性原理

A first principle is a basic, foundational proposition or assumption that cannot be deduced from any other proposition or assumption.

这是来自于量子力学计算的一种说法,意思是从头算,只采用最基本的事实,然后根据事实推论。

早在古希腊哲学家亚里士多德的书中,第一原理是这样表述的:在每一系统的探索中,存在第一原理,是一个最基本的命题或假设,不能被省略或删除,也不能被违反。参考

著名创新企业家马斯克眼中的第一原理是这样的:我们运用「第一原理思维」而不是「比较思维」去思考问题是非常重要的。我们在生活中总是倾向于比较——别人已经做过了或者正在做这件事情,我们就也去做。这样的结果是只能产生细小的迭代发展。参考

总之,「第一原理」的思考方式是用物理学的角度看待世界的方法,也就是说一层层剥开事物的表象,看到里面的本质,然后再从本质一层层往上走。

产品研发是一个复杂系统,其特征是整体大于部分之和。那么针对产品研发的第一性是什么?答案是,在反馈循环(loop)进化和学习

几千年前的《道德经》曰:“反者道之动,弱者道之用。天下万物生于有,有生于无。” 意思是世事无常,万物都在不断的循环之中变化。后有达尔文的进化论,今有互联网精益创业试错手段,无不体现了敏捷思维就是在不确定和复杂环境中,建立低成本地响应变化的能力,让价值能顺畅地流动,保持轻松和优雅,这种灵活性称为敏捷性(agility)。参考

复杂域下的决策和领导力

敏捷人士应该对Cynefin领导力框架Stacy Matrix矩阵不陌生,是把事物分为四个领域:

3 复杂 2 繁杂
4 混乱 1 简单

复杂情况下,因果关系是互为循环关系和互相交叉的,表现出巨大的不确定性和复杂度。美国军方称之为VUCA时代,投入重金研究在不同场景下如何进行决策。在产品研发和软件工业中,一直都出于复杂领域中,传统的过程改进和科学管理理论完全不适用,于是引入复杂科学及衍生的管理3.0来解释如何进行管理。

在90年发展起来的敏捷思维和方法论中,Scrum是发展比较好的一支,其独特的三大角色设定,特别是跨职能团队的设定,非常好地贯彻了“用复杂应对复杂”这个原则,发挥团队的自主性和积极性,而不是用僵化的流程来管控。正如人脑现在已经无法理解基于人工智能的AlphaGo如何打败了全人类的围棋高手一样。

另外,Scrum(借鉴了XP方法),还提倡对三个方面进行 拆分(breakdown):

  1. 时间,把长达几个月的项目周期拆分为短的时间盒(timebox)。这是治疗拖延症,强调节奏感,强迫各方融合协作的灵丹妙药;
  2. 内容,把大块的需求分拆为小的用户故事,(在软件中还包括把软件模块进行解耦和抽象)。《道德经》曰”图难为其易,图大为其细”;
  3. 团队,把大型组织分拆为跨职能的小团队(亚马逊创始人贝索斯说的”Two pizza team”也是这个意思)

通过这种拆分,其实就是在将事物从复杂领域拉向简单领域,让人脑能够理解和处理。我称之为“降维打击”,即缩小范围,减少变量,分而治之。把事物从cynefin框架的complex域降到simple域。这是scrum的核心武器,我讲Scrum培训时都会提到这件事情。

Scrum与Kanban之争

其实Scrum与Kanban是POV(视角)不同,非要比较的话,Scrum的视角是从responsiveness,更多是破解复杂性,而kanban视角是从flow,更多是整流顺畅性。所以这两种方法的视角和想要达到的状态不同,但互有支持和重叠,本质最终都指向第一性原理。

两者都借鉴了精益思想,其目标包括低成本、短迭代地快速交付和响应,以最大化客户价值。显著减少任务批量规模,去除瓶颈以加快交付客户价值产出的速度。不再进行规模经济竞争,而是在适应能力、避免库存和小单位工作方面的竞争。可视化、timebox都应该为这个目标而服务。

改进是精益的核心之一,至于怎么改进,精益思想给了一些手段,比如”go see”与可视化管理等,然而相对于Scrum方法,精益与看板对循环(loop)这件事提的都不多。至于价值流建模,Kanban对研发过程是一种落地手段,但是还有很多是Kanban难以进行建模的,比如持续交付流水线、TDD和重构过程、模块化设计等。

Kanban的理论基础很多来自于Don的那本书,其出发点是flow,通过可视化来推动这个变化。Kanban更多是一种可视化的协作模型。它对现有过程进行建模,看板试图通过可视化手段以及WIP限制(因),达到“流动”和“拉动”这种状态(果)。但并未对具体实践给出太多的指导和设定,比如没有固定时间盒,没有要求团队要重组,也没有要求需求拆分。当然你也采可以用迭代,称之为Kanban Cadence。如果是不严格的时间盒,更像FDD/XP;如果应用固定时间盒,那么也就更偏向Scrum的玩法。(kanban创始人其实也试图在融入更多循环的概念)

Scrum更多是一种产品与组织的学习和改进模型,绝不是项目管理方法。也借鉴了精益思想、PDCA戴明环、时间盒/GTD等。

时间盒是Scrum除了三大角色设定(包括跨职能团队)、拆分之外的另一大特点,强调节奏感,这是软件交付的核心,等大家节奏感有了,自然流式交付。时间盒也有助于人们的共识对齐。任何产品和组织协作,最难的一步就是alignment,这是所有方法都梦寐以求的。借用你王大爷的话:”Scrum给了我们不需要理解就能得到一些“东西”的框架,通过给你一次又一次失败的机会来调整自己,alignment在动荡之中自然会形成”。短的时间盒也是更调整和响应变化带来更大的余地。

参考阅读