最近敏捷小伙伴们在讨论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在动荡之中自然会形成”。短的时间盒也是更调整和响应变化带来更大的余地。
参考阅读
●认知科学)有一个核心信条：只在单一的层级上进行研究，不可能彻底地理解精神和脑。认知科学是一个跨学科领域，包含了来自各领域的贡献，包括心理学、神经科学、语言学、精神哲学、计算机科学、人类学、社会学和生物学。
●管理3.0
●复杂理论
●系统思考
●“Waterfall, Lean/Kanban, and Scrum”, Ken Schwaber, 2010（本资讯于2017-09-07首次发布）
