Scrum与产品创新
VUCA时代的产品
产品（Product）是用来满足人们需求和欲望的物体或无形的载体(服务)。虚拟产品和服务将会越来越多占据人们的时间。然而产品研发中，需求文档永远没法完全被理解，实际用户在看到实物之后可能都不知道自己要什么，充满交互的系统（软件系统，以及近在眼前的AI人工智能、VR虚拟现实）永远无法被精确定义和测试。产品及产品研发从来都是创新，没有哪个产品会和昨天完全一样，那样的话只要复制就行了。既然难以复制，所以如果太过关注于效率，就很难有好的效果。在充满变化和不确定性的情况下，产品研发工作会迅速地进入Cynefin框架中的复杂和混沌领域并不断进化。
VUCA和互联网时代，问题、方案、人员、环境很多都越来越难以琢磨，昨天的成功不可重复，甚至昨天的经验可能是明天的阻碍。所谓不确定性，其实是没有加上时间维度。学会做时间的朋友，从不确定中找到确定性，一切就容易多了。在物理学中，单独测量一个光子的偏振方向，每次得到的结果都是随机的，但是结合时间维度长期来看，测量结果是有规律的、符合概率的，于是人类就可以“控制”量子了，从不确定中获取确定的收益了。大家也可以看看《反脆弱》这本书，期权投资获利也都是这个道理。
“尊重人”与“持续改进”
30年前，流水线制造是工业社会主流，成本效率优先。两位学者Takeuchi和Nonaka于1986年在“哈佛商业评论”发表论文《新的新产品开发游戏》（用了game一词，现在的Scrum实践也称为Game Rule，这不是巧合)。开篇提到“在当今快节奏，激烈竞争的商业新产品开发世界中，速度和灵活性至关重要。 公司越来越意识到，开发新产品用旧式、顺序的(比如Waterfall/PMP/CMMI或任何预先计划的方法论)方法根本无法完成工作。需要一种整体类似英式橄榄球(Rugby)打法，球队作为一个整体，不断传球的方式。”
作者在研究了包括富士施乐，佳能，本田，NEC，爱普生，IBM，兄弟，3M，施乐和惠普（注意，所研究项目是产品整体研发，研究对象都是当时的高科技产品：复印机、相机、个人电脑等，而不单纯是软件开发和交付）在内等多家美国日本的产品创新研发企业后，研究者提出了六点特征，组合起来可以提高产品研发速度与灵活性，提高企业竞争力：
内在不稳定性（目标导向，团队高度自主。这就是不确定性管理思维，也即[《管理3.0》中讲的“用复杂应对复杂”）
自组织项目团队（强调打造团队，发挥“人”的作用，鼓励自我超越和”Kaizen"，异花传粉式的人员发展）
重叠的研发阶段（相对于管理密集型的传统“顺序”式阶段而言，类似今天Scrum中的迭代概念。每个迭代都打破职能分工，以产出可用的成果，加速反馈。这种节奏感好比推动团队的脉搏，加强了共同责任与合作，激发参与和承诺，锐化了解决问题的重点，鼓励主动采取，发展多元化技能，提高对市场条件的敏感性。）
多层次学习和跨职能学习（个人不断的读书、观察学习，今天有种说法叫”全栈“工程师。组织和团队的学习，比如现场客户调研，比如有限时间内的探索等，鼓励在自己专业之外发展多技能。）
微妙的控制（不是高高在上的管控和精英主义，而是通过同侪压力和爱进行“控制”，以及自我控制，进而打造自组织团队。这就是为什么Scrum比起其他敏捷方法，更加感性，也是Scrum与教练技术紧密结合，在组织规模化转型发挥巨大能量的原因。CSM中文认证课程的同学，应该还记得乔布斯深谙如何去创造一个“容器”带领大家发挥智慧之道。）
组织的学习转移（不断调整组织结构，将有限的优秀人才转移到更关键的项目上，同时将学习到的知识和教训分享和传播出去，但是要小心过度的制度固化）
这些对组织的管理层提出了更高要求，高管必须首先认识到产品研发工作不会以线性和静态的方式进行。它涉及到迭代和动态的试错过程。为了管理这样的过程，公司必须保持高度适应性的风格。1986年已经窥见了“不确定管理”的雏形，并完全地在强调打造团队，而当今互联网时代更是势在必行。如果管理者没有首先转变确定性管理思维，是无法运用任何方法的达致业务成功的。
这篇论文没有提到丰田，而与此同时的丰田早已走上了精益生产的道路，顺风顺水。在2001年的《丰田之道》中，“尊重人”与“持续改进”是精益价值观的核心。 这与哈佛商评论文的观点有着异曲同工之妙。
美国人从丰田的精益制造中提炼和学习精益思想，想弄明白日本汽车是如何大规模占领美国本土的。可惜日文“Kaizen”这个词被翻译成“Continuous Improvement”，中文进一步翻译为“持续改善/尽善尽美”。字面上看，只要有一点点进步也算是进步嘛，然而，日文原意可不是这么松松垮垮的被动改进之意，而是“激进地挑战一切”之意。
Scrum与精益的渊源
TL;NR
Scrum并非直接延续自精益。Scrum是继承于CAS(复杂自适应系统)，而精益有助于向管理者解释为什么Scrum可以奏效。
Scrum的创始人之一Ken Schwaber受哈佛商评论文影响，从1990年代开始实践新方法，在1993年拯救了一个濒临失败的项目。
Ken在1994年建立的“控制混乱”网站中，就指出不确定性管理的必要性，他认为自己与另一位创始人Jeff Sutherland对Scrum的研究总结背后蕴含着第一性原理：“复杂性过程需要试验性的过程控制”。在那个年代，研发型的组织一定都是走在创新之路上的，现在很多研发组织实际走向了富士康模式，但是却无法管理好。这背后的原因是技术与管理的进步使一些东西变得确定了，然后却有更多新的不确定因素涌现出来，“控制混乱”前路漫漫。
1995年，Jeff Sutherland应邀将哈佛商评的文章转发给正在创立极限编程的Kent Beck。Jeff曾是越战中美军的战斗飞行员，对变化无常的战场复杂形势有着切身的体会，要想生存就必须要建立响应变化的能力，没人能够走直线的。
除了那篇论文，他们还借鉴了精益思想、时间盒概念、SmallTalk社区的面向对象设计思想等理论基础，并于1995年正式在OOPSLA发布了Scrum研发过程论文，期间也受到Mike Beedle的帮助，正式提出了Scrum研发框架。
根据Jeff的说法，Scrum在创立之初就受到高德拉特的约束理论和精益思想的影响，关注于"muri, mura, muda"。
Muri - 避免给予人员和组织不必要的压力，现在也称为“可持续发展”。
Mura - 消除跳变和不一致，进行整流，有助于达到超生产力(hyperproductive)。最初几个Sprint主要是消除流动中的干扰，从而是后续的Sprint更加顺畅。
Muda - 激进地消除活动中的7大浪费，持续改善。
直到2001年，在美国Snowbird和大家一起形成敏捷宣言，连同《Agile Software Development with Scrum》一书(中译本《Scrum敏捷项目管理》) 和现代IDE的出现，Scrum逐渐流传开来。
后来Ken又注意到Scrum更多是一种管理实践，而对于软件开发而言，Scrum落地需要更好的技术能力实践，于是借鉴XP极限编程提出了Scrum Developer训练内容。
Scrum框架的意图
为什么要采用Scrum？因为商业组织往往面临这些痛点：
产品做出来没人用，忙的像狗却没有成就感
计划赶不上变化，需求变更太快太多，无法聚焦完成一件事
业务与研发总是在扯皮，用户总是在投诉
时间紧任务重，每件事情都是高优先级，总是中救火之中，做不完又焦虑
所有压力和风险都在后期集中爆发，越忙越添乱
技术和架构更不上时代，知识缺口越来越大，逐渐与社会主流脱节
好的习惯和流程坚持不下来，形同虚设
招不到优秀人才来帮忙，牛人还中不断流失，团队一盘撒沙
个人工作与生活失衡，从加班到辞职
Scrum框架的定义
Scrum基于试验性过程控制理论(Empirical Process)，或称之为经验主义，是自然科学研究方法的基础。经验主义主张知识源自实际经验，以及观察当前已知情况下做出决定所获得。（注意区别于教条主义，以及完全基于过去经验进行判断的固定思维，或者忽视理论指导的局部经验主义）。“透明、检视和适应”是试验性过程控制的三大支柱，支撑起每一个试验性过程控制的实施。Scrum采用一种迭代、增量式的方法来优化对未来的预测和管理风险，建立组织响应变化的敏捷能力，从而达致更好的效果。Scrum借鉴了精益思想、时间盒、模块化设计等，并完整地体现了敏捷宣言和敏捷原则。
Scrum是一种通过“检视-调整”来开发和维护复杂产品的框架，是遵循敏捷宣言和原则的一种流派，整合了3个角色、3个资产、5个事件、5个价值观，简称“3355”。在这个框架中，整个开发过程由若干个短的迭代周期组成，称为Sprint。每个Sprint的建议长度是1到4周。使用产品Backlog来管理产品的需求，它是一个按照价值排序的需求列表。每个迭代中，Scrum团队从产品Backlog中挑选最高优先级的需求进行工作。挑选出的需求在Sprint计划活动上经过讨论、分析和估算得到相应的迭代目标和交付计划，我们称它为Sprint Backlog。迭代中每天会有一个站立式的Daily Scrum。在每个迭代结束时，Scrum团队将邀请业务和利益干系人评审潜在可交付的产品增量。 随后，团队进行回顾，不断改进工作方式。Scrum不仅适用于软件开发项目，也可用于任何复杂的或是创新性的项目和探索，以及组织变革设计。
什么是迭代（Iteration）
Iteration英文原意是重复地做同一件事。而Scrum中的Sprint（直译为短跑、冲刺）概念，是借鉴了XP极限编程中迭代产出增量的含义，要求每个时间盒周期内都要有可用的成果出来，并不是狭义地重复任务的意思，而是重复地在固定时间盒内进行PDCA改进循环的意思。既然是产品创新和研发，所做的任务一定没有相同的，但是重复地践行Scrum各种活动仪式，反复进行改进，从这个意义上，的确是在Iteration。Sprint要求每个周期的时长是固定的，不会轻易变动，并且希望团队在和PO确定完短期目标后全力以赴。就像短跑运动员在进行冲刺，因为百米冲刺时你不会总抬头看成绩的。
Scrum中的精益思想
精益思想，有个很形象的比喻：“关注接力棒，而不是运动员”。意思就是要关注价值的尽快流动，而资源利用率是次要的。这就引出精益的五大原则：
价值
价值流
流动
拉动
尽善尽美
下面从这几个方面分别阐述精益思想在Scrum框架中的体现。
价值
“尊重人”的对象，除了员工、伙伴，还有客户，不给客户添麻烦，最大化客户价值，就是对客户的尊重。
产品研发最大的浪费是什么？是做出来的东西没有客户愿意用！方向错了，再努力也没用，“火车跑得快，全凭车头带”。
Scrum的目的是“通过迭代和增量，最短时间内交付最大价值”，而精益就在于“精”和“益”，即以最小的成本获得最大的收益，并坚持持续改善。两者说法不完全相同，但最终指向同一个第一性原理：什么都想要的贪念会分散宝贵的精力。作为客户代表的Product Owner是一个获得授权的火车头式的角色，带领着大家聚焦方向和投入产出决策，牵引着交付和改进，至关重要。让所有都朝向一个目标努力并不容易，引导(Faclitation)技术能够有效地提到大家协作的效率。
精益是从系统全局管理的视角思考的，然而丰田固有的“尊重人”这一点，在后来的各种精益流派实践中，体现的都不多，更多是从上帝视角将组织当做一个机器来改进。Scrum区别于其他流派，就在于一开始就要解决WHO的问题。没有角色定义，就像是一群喝醉的猴子在玩拼字游戏。清晰的角色职责可以避免“龙多了不下雨”的情况。敏捷宣言第一句就是强调“个体与互动”，没有任何一个其他的敏捷流派像Scrum这样，将对人的尊重培养和对团队的打造放在首位。“自组织、跨职能”的提法让很多组织感到头痛，因为这与传统精英主义下，“命令与控制”、“岗位分立”的管理手段截然不同。
在每个Sprint Planning时大家一起选择本迭代最想要完成的需求条目（PBI），这些条目已经被PO按照价值排序，团队在最短时间内（一个迭代的时长）交付最高的价值。
Sprint Planning时PO还要与团队一起定义本迭代的Sprint Goal，显然那会是整体业务价值的一小部分，这个小目标可以使大家更加聚焦。价值并不等于功能范围，关注迭代目标而给需求功能范围留有弹性的余地，有助于在一个迭代内进行调整，更好的朝向目标前进。
不是只有功能性需求才有价值。迭代目标也可以是探索和学习，特别是在前几个迭代充满市场风险、技术风险的时候，试错的经验同样是宝贵的价值。必要不增值的基础设施搭建和工具改造，也能够间接地、长期地为客户带来价值，它们也可以进入Product Backlog。
认领后的PBI要进一步梳理和分拆。在拆分的时候，一定要按纵向拆分原则。即使再小的需求，也能够做到完成对利益干系人可见。好比吃蛋糕，虽然结构上是横向一层一层的，但吃的时候永远是竖着切，哪怕再薄的一片，也会包含水果、奶油、巧克力、蛋糕坯等。如果横向拆分，比如只完成了前端开发的任务，这种都称为半成品，对客户没有价值。
价值流
价值流必须在某个层面是闭环，才能最终给客户带来价值。差一点都不能让客户满意。比如今年在云南某县，某部门制作了精美的意见箱，但是挂的太高了，群众无法投递，也就达不成制作意见箱的初衷，导致价值流中断在“最后一公里”。这在Scrum中叫"Not Done"，在精益中叫WIP(在制品）浪费。
团队在Sprint Planning上针对Sprint目标及所选择的PBI，集体讨论出如何完成他们的计划，这些统称为Sprint Backlog。任务墙、燃尽图都是展示Sprint进展的可视化方式，也可以将任务墙扩展成可视化看板。可视化管理有助于让大家对价值流形成共识，关注进展，识别潜在的障碍和瓶颈，从而及时参与改进。这些都是属于团队自管理的工具，应该由团队自己搭建、使用和改进，并开放给所有人。
由于产品研发的价值流不像生产制造那样是线性系统（流水线），而是非线性价值增值曲线，所以Scrum采用非线性的DoD（完成的定义）来展示出所有必要的工序，以此来驱动质量内建而避免半成品。在实践中，Sprint更多是时间盒概念，时间一到迭代就结束，所以Sprint没有成不成功一说，真正要关注的是每个PBI是否完全满足了DoD，形成了完整的价值流。这样还不够，每个Sprint Review是一次向真正客户和利益干系人展示和获取反馈的机会，配合技术实践比如CI或DevOps做到每个Sprint都能上线就更好了，实现更大范围的价值流闭环，为下一个Sprint的做出调整。
不光一线团队，跨部门的管理团队也可以成为自组织和跨职能团队，来改进整个公司的业务，打通业务-财务-人力-研发-维护-运营全流程，这时CEO/COO就是PO。（甚至党政一把手也是PO呢）因此，项目群或产品集层面，管理团队也可以用可视化的方式来展示公司运营的价值流。甚至借助故事地图、影响地图来识别市场-业务-研发-运维-运营整个价值流的，成为跨多个Scrum团队的规模化敏捷。
流动
“最短时间交付最大价值”，即尽快地让一个可用成果真正地完成，中途的障碍越少越好。
朝令夕改的模糊决策、研发内容的复杂性、高资源利用率、僵化的组织结构与流程、人员能力不足，都是提高流动效率的障碍。
实施Scrum首先要求重新定义角色。要有明确的PO来确定优先级，帮助大家对齐和聚焦短期目标。组建跨职能团队，消除协作壁垒。甚至鼓励一专多能，可以进一步，减少等待和协调工作。全新的ScrumMaster角色，辅导大家进一步理解Scrum框架，避免因为概念不清而走弯路。三个角色都为加速流动而努力。
每个Sprint Planning时候拆分PBI，尽量拆小、拆独立，破解复杂性，破解依赖性，朝着“单件流”方向改进。降低可变性是有帮助的，但不可能每个需求都拆成一样大小，在这个过程中，计划扑克™和相对估算有助于团队尽快达成共识。有的Scrum团队还引入Product Backlog Refinement实践，在每个迭代为下一个迭代提前进行需求梳理，避免在迭代开始后再花费时间进行需求讨论，从而进一步提升下个迭代的流畅程度。这些梳理活动是一种“整流”活动，大家可以想象北京南站进站口迂回的围栏，虽然增加乘客进站的步行距离，但每个乘客进站的时间反而是缩短了。如果大家都抢着进入一个狭窄的入口，反而谁都走不快。
[图片上传失败...(image-6d11f8-1521990276132)]
Sprint中承诺的PBI不变也有助于流动速度，这也是一种强行压制可变性的手段。想象在拥堵的地方不断有人插队，最后就是导致整个系统都变得缓慢。对于变化非常剧烈的情况处理，请见后续章节。
管理者容易想到的是管理实践，往往忽视了“用技术手段解决管理问题”。根据排队论，系统资源的高利用率反而有害于工作项流动速度，这是反直觉的。在产品研发中，管理层和PO要尊重团队的集体估算结果，量力而为，避免过大的团队压力，比如长期加班导致质量下降和返工，从而提升流动速度，符合俗话说“欲速则不达”。
Scrum强调打造团队，包括人员能力提升。不同程序员的生产力能相差10几倍以上，如果程序员掌握极限编程中的Clean Code、Refactoring、TDD，并善于利用版本控制工具和持续集成工具进行主干开发的话，可以有效减少返工和缺陷，并提高代码的可读性和可维护性，使得系统在项目后期也能易于变更，保持工作项流动速度在一个平稳的高水平上。在精益生产中，有"自働化"的实践，授权给一线员工发现缺陷有权及时停止生产，也称为质量内建。在敏捷中，借鉴为持续集成中的"Stop & Fix"实践，促使团队及时修复缺陷。
此外，给员工配更快的电脑，去掉上网查资料的限制，也是提高组织的灵活性和顺畅度的重要手段，而且简单可行。
以上这些都是组织领导力和管理层要关注的，各级管理者在扮演ScrumMaster角色。Scrum实践中，敏捷教练会帮助建立Impediment Backlog或者Improvment Kata，将障碍也可视化出来，发挥群众的力量，使更多人参与到改进中来。
拉动
精益生产中，拉动的表现为JIT（即时生产）实践，根据客户订单情况，下游工序有需要，上游工序才会开工，实现“零库存”。
产品待办项清单（Product Backlog）是一个已排序的需求清单，PO通常是根据客户价值以及投入产出比进行排序。
精益的拉动原则是基于WIP上限的，完成一个如果有空余产能，就再拉入下一个。Scrum中有2层拉动实践，其一是每个迭代开始时团队基于速率来从Product Backlog中拉入一些工作项到Sprint Backlog中；其二是团队成员基于自己手头的情况。Scrum没有在Doing/WIP这一列中继续细分，而是把权力交给团队自己决定。要不要分出更多工序阶段，抑或设置每道工序的WIP上限，都是团队自组织和因地制宜的结果。
团队成员每天从Sprint Backlog拉入新的工作任务，并蜂拥而上（swarming）以尽快完成一个工作项，再认领下一个，只有这样才能真正地降低平均周期时间。完成的标志是满足DoD，而不是Sprint时间盒结束。
然而，在一个3-9人的团队中，2-3个PBI同时在并发进行是很现实的。拉动是基于WIP上限的，但并不意味着团队的迭代周期(前面说了，Sprint是时间概念)可以无限缩短。在Don的《Flow》一书，对于批量大小的选择，实际上需要在交易成本和持有成本中间取一个平衡，并不是批量为一（单件流）才是最好的。采用1-2周的迭代长度的Scrum，其实是从经济角度最优的设计。另外，如果这个工作任务非常巨大，比如“我想做个APP”这个工作项是不能直接开工的。真正精益和敏捷的做法是要进行拆分，将任务拆散拆小，确保PO和团队都知道预期产出是什么，即以终为始，再分配到短的迭代周期中去完成。
[图片上传失败...(image-b0a52c-1521990276132)]
尽善尽美
Scrum中有3个PDCA戴明环，通过不断检视-调整来消除影响流动的阻碍，这三个反馈环是Daily Scrum, Sprint Review, Sprint Retrospective。
精益制造的“尽善尽美”有3个含义：
用户满意 - 改进价值。
无差错生产且满足需求 - 改进产品。
企业自身的持续改进 - 改进工作方式。相信任何事物现状都是假设，都可以去挑战和主动提高，永远可以做得更好！
Daily Scrum
在Sprint中，ScrumMaster每天辅导团队开展Daily Scrum并回答三个问题。特别是每个人要讲三个问题：
“昨天我完成了什么？”
“今天我打算完成什么？”
“今天我遇到了什么障碍？”
随时进行检视-调整。这是每24小时发生一次的自组织活动，识别阻碍工作项流动的障碍，尽快解决。也是促进团队协作沟通的一次机会。
Sprint Review
向客户展示进展情况，会给研发人员一种成就感。用产品Demo来确保真实的进度，即Backlog的进展不是用文档而是实际成果来衡量，正是精益中关注价值和流动的体现。同时尽早地接受真实的用户反馈以改进产品。
难道产品增量(Increment)必须在迭代结束才能给利益干系人演？红宝书《Scrum Guide》上只是说这个活动上PO要解释那些PBI被接受了，哪些没有。如果PO和利益干系人有可能尽早地验收甚至上线，为什么不呢？没有人拦着啊。如果PBI都已经提前验收了，这时Sprint Review可以更多成为一个充满仪式感的活动。善始善终，团队文化扑面而来，提到团队凝聚力。
《你无趣是因为少了一些仪式感》中引用《小王子》中的一段故事，是这么说的：
小王子在驯养狐狸后的第二天又去看望它。
“你每天最好在相同的时间来，”狐狸说，“比如说，你下午四点钟来，那么从三点钟起，我就开始感到幸福。时间越临近，我就越感到幸福。到了四点钟的时候，我就会坐立不安；我就会发现幸福的代价。但是，如果你随便什么时候来，我就不知道在什么时候该准备好我的心情……应当有一定的仪式。”
“仪式是什么？”小王子问道。
“这也是经常被遗忘的事情。”狐狸说，“它就是使某一天与其他日子不同，使某一时刻与其他时刻不同。”
仪式感对于生活的意义就在于，用庄重认真的态度去对待生活里看似无趣的事情，不管别人如何，一本正经认认真真地把事情做好，才能真真正正发现生活的乐趣。
在《奇特的一生》中“柳比歇夫的时间事件记录法”也值得借鉴。Sprint Review最终统计在各工作项上花了多少时间，作为反馈，团队可以改进今后做Sprint Planning的能力，尽量更加准确地预测。
Sprint Retrospective
刚才提到的Sprint Review更多是在改善价值和改善产品本身，而Sprint Retrospective则是在改进工作方式，更新团队约定，使得团队在下个迭代能更有效的协作，提高工作项流动速度。这个活动是"Kaizen"精神的最深入体现。
[图片上传失败...(image-2f75ed-1521990276132)]
所谓磨刀不误砍柴工，但很多团队忽视这个活动，或者开成了汇报会甚至批斗会，结果是虽然每个迭代都有产出，但是一直在低绩效水平上徘徊。有效的Retrospective需要优秀的ScrumMaster，利用软技能引导和教练团队，本文不做详细展开。
Scrum超越了精益思想
Scrum体现了精益思想，同时还吸收了其他思想，并没有将精益生产的看板直接照搬到产品研发中，而是采取了更加务实和开放的态度。Scrum中更多关注“人”，也是为什么相比精益顾问，Scrum教练和管理者越来越多对教练技术感兴趣，更少地制定规范流程，尝试从内部驱动力和打造团队来促进企业转型。
Sprint固定时长的时间盒
笔者年轻时曾组过多年乐队登台演(Si)出(Hou)。一般摇滚乐队最少3-5人，包括主唱、和声、节奏吉他、主音吉他、贝斯、鼓手、键盘等。乐手往往需要兼职，比如主唱兼节奏吉他，贝斯手或键盘手兼和声等，乐队人员更迭也是常有的事情。大家靠什么配合才能完成一首歌的演出？答案是“节奏”，例如歌曲是4/4拍每分钟120拍，发出不同音符的乐器必须在同一个节拍速度上，通过节奏感大家才能形成默契，不必费心考虑什么时候开始和结束，降低认知负担。乐曲的音符时时在变，不变的就是节拍速度，每个小节都是一个固定时间盒作为和弦走势变化的基础。以演奏《梦缠绕的时候》为例，当大家在主歌之后如约停止演奏，然后心中默数12345678之后，所有乐器又同时开始巨大的轰鸣进入副歌，那种团队配合协作产生的巨大成就感、荣誉感、幸福感是难以为外人所道的。（题外话：沉浸在音乐中是一种很好的静心方式。这几年作为专职培训讲师，登台演讲不怯场，也和那些年的演出经验密不可分。）
正如著名小提琴家耶胡迪·梅纽因(Yehudi Menuhin)一次写道的那样:"音乐是乱中求序的，因为节奏在各行其是中加进了步调一致;旋律使相互脱节的东西前后贯穿;而和弦则从本不相同的东西中找出匹配。"
固定长度时间盒背后有很多科学理论，在各种时间管理方法中都有提到，包括《Get Things Done》和《番茄工作法》。Scrum通过固定时长时间盒作为迭代的基本单位，Sprint也称为Scrum的心跳。团队就像一个人，脉搏太快太慢都不好，时快时慢更不行。这样设计的用意：
其一，降低所有人对活动仪式的记忆负担，什么时候计划、什么时候演示都不用每次商量了，到点来就行。
其二，清晰的节奏感确保大家的参与和目标一致。
其三，时间是对大家都公平的，固定时长，多个迭代的单位时间团队绩效才能进行对比。每个迭代完成的故事点称为速率，可作为生产力度量进行检视-调整。下个Sprint周期计划时看看历史速率，就可以知道团队能承受多少工作，不要多也不要少，有助于提高今后做计划的能力。
其四，避免像流水线一样一个劲儿地压榨团队承担更多工作，团队的单位工作容量总是有一个相对稳定的数值，速率也就是团队的每个迭代的WIP上限。定期停下来，抬头望望天，缓口气。改进措施没有立竿见影的，需要时间的检验，也要考虑交易成本，所以固定长度的时间盒更多是为改进而服务的，而不是束缚工作项的牢笼。
常见的Sprint周期一般选择1-2周，理论上并没有最小的Sprint长度限制。一天的Sprint长度是我在产品开发中看到过的最小长度。在培训时有时可以用0.5天作为Sprint的长度。然后，一个Sprint可以称为Sprint的关键是它必须包含4个活动。
有人说“有了单件流就不需要迭代了“，这是一种误解。单件流在生产上是指通过标准化，使每个工序耗时趋于一致，使得批量大小可以降低到1。这对智力型工作的管理有指导作用，但是，智力型研发工作的内容和颗粒度都不相同，即使通过拆分，颗粒度（工作量）仍然会有几倍差距。而且前面说过，WIP为1从经济角度上并非最优选择。Scrum站在时间的维度上，基于每个迭代中团队的速率（工作容量）大致稳定的前提，每个Sprint承诺的工作总和可以看做是一个"单件"，来达到某种意义上的管理标准化。
线性看板与非线性DoD
传统瀑布式过程以工序作为项目的不同阶段，比如"分析-设计-开发-测试"。弊端已经说过了，产品本身、研发的过程、团队协作，这几方面都不是线性系统，而是复杂自适应系统（CAS)。其特点是，系统是一个非线性网状结构，存在大量循环往复的路径，从来没有过任何一个项目不是在那几个阶段之间反复震荡的。用线性方式为线性系统建模是存在缺陷的，虽然意图是好的，试图简化系统模型。
看板方法仍然在用二维线性方式建模，卡片在看板泳道的一个阶段流入下一个阶段，这对制造业流水线没问题，但是对复杂的产品研发有时候会存在矛盾，很多工序内容在看板上体现不出来，而且人员共享关系也很难体现，毕竟是二维的形式。比如，Code Review与功能测试孰先孰后不一定，不同的软件看板专家对“任务卡片能否倒流到上一阶段”这个问题存在不同答案。另外，看板上一般都会分为”开发、测试“列，虽然这是从工序来划分的而不是职能划分的，但某种程度上仍然默许了“小瀑布”的存在，不像Scrum一开始就鼓励职能融合。
继承于复杂自适应系统的Scrum是怎么做的？Scrum也可以用任务板（Task Board）来可视化工作进展，但只要开始做的工作都是进入"Doing/WIP"列。团队对任何任务和需求定义了一个通用的“完成的定义(DoD)”，形式上这是一个公开的检查清单(Checklist)，包含了所有要做的工序事项，例如设计、开发、代码评审、代码提交、单元测试、验收测试、性能测试、打包、写文档等等，这些工序并不一定是串行的，而是循环往复进行的。所以Scrum将复杂问题交给团队去找答案，让团队自己决定如何协作将所有工序做完。对于单个需求来说，不关心执行的顺序，只有DoD清单上所有事项都打勾了才叫完成。对处于"Doing/WIP"列中的卡片上打点挑勾，反而是个更好方案来体现价值流。
Sprint的内容原则上不允许变更
虽说变化是唯一不变的，但不可能一切东西都在变，变与不变是辩证统一的。比如说你研发过程的需求、设计、技术、人员等全方面100%的要素都在变化，这不可能，而且也承受不了。更务实的情况是，变化的部分占一定的百分比，可能是10%可能是30%，我们需要稳定固化不变的部分。Scrum是目前已知的方法里面对变与不变区分比较好的。比如时间对大家都公平，那就固定时间，并以灵活的策略调整能力去应对变化，从而可以设计出健壮同时灵活应变的系统。
因为固有的复杂性和不确定性，所以工作项具有涌现性，也就是说Sprint内可能会出现新的SBI，在Sprint期间SBI是可以变化的，但团队已经承诺的PBI不能变化。在Sprint中的"No Change”是指承诺到PBI条目而言的。
Sprint过程中PO想要变更已经承诺的PBI，是突发情况还是一而再再而三？戴明说过，要区分特殊情况和一般情况。如果是前者可以应急处理，如果是后者，需要从工作方式和流程上找原因。
Scrum框架原则上不允许迭代内变更，某些没有经历过Scrum的Kanban拥护者会片面地曲解这样不够灵活。相反，Scrum鼓励价值有节奏地流动。现实中大家已经受够了产品需求朝令夕改然后第二天又改回去的现象，因为看似紧急的需求变更（除非是影响运营生产缺陷）往往都是没想清楚的拍脑袋，业务规划就没有一些前瞻性吗？需求变更连一个迭代都等不及吗？需求池里排队等几天，反而可能是一个冷静思考的机会。而且，Scrum所说的不能变更，指的是迭代目标及所承诺的那几个最高优先级的PBI顺序不能变更，实现细节留有弹性。因为这些目标已经是Team与PO之间花时间澄清估算后的相互承诺，需要认真和专注地对待，这样在每个迭代之后，人们也会更有认同感，成就感，信任感，提振士气。
话说回来，如果真的是因为业务竞争太激烈或者线上紧急缺陷，除了可以缩短迭代周期，一般也是采用置换原则，即迭代中最低优先级的PBI要换出来，然后才能插入一个更高优先级的新PBI，也符合精益中限制在制品的拉动原则。最不济了，PO有权决定提前终止当前迭代，重新与Team进行计划。
“随时随地能将需求放入团队中”是一个非常理想化的状态，考虑经济性其实并非最优状态。而且必须是在资源利用率比较低的情况下才有可能，想象一下，如果队列中已经有很多在等待翻牌子的需求了，再来一个需求通常还是要等待一个迭代以上才能轮得到，那么也就无所谓当前迭代允不允许变更了。
Scrum是“完美”的最小核心
完美是形容词或者动词吗？不，完美是个动词，毫无瑕疵的状态其实永远不可能达到，只有不断地逼近那个状态，这也就是“Kaizen”持续改进和学习的状态，对人对组织对产品都是一样的，活到老，学到老。
这不代表我们可以降低目标。有人觉得Scrum像禅宗一样难实施，不像净土宗们念个阿弥陀佛就能修成正果，就想裁剪一些东西吧，降低一些要求吧。要知道，如果目标定在100%，实际中能做到70%已经了不起了(所谓Scrum-But现象)；如果目标就定低在70%，实际也就只能做到30%了，因为改进的动力太弱了。随意地动剪刀，没有坚持的底线，最后很可能剪的啥都不剩，组织还是安于现状，继续在贴着“敏捷”标签的温水瀑布中舒服地煮着。
Scrum框架的3355元素及其规则是最小核心，在多年的实践提炼中，已经去掉了那些可选的元素。各种敏捷流派各有千秋，但如果一起都差不多，一起都随缘，那么又如何区分宗教、迷信和邪教呢？因此凡事都需要有个最小定义，即区别于其他流派独有的规则和实践，大家可以在其之上进行扩展变化，但是核心是不变的。变与不变是辩证统一的，随机应变不等于乱变。正如“守破离”中的“守”阶段，正是要坚持扎马步练基本功，才能有机会学习心法和招式。上来就学花拳绣腿，挑肥拣瘦，终将一事无成。
要旗帜鲜明地反对对Scrum框架进行任何裁剪，要坚定不移地实施3355，即使做的不够到位，只要不断提高就是好的。3355就像整形的牙套，一开始戴着虽然不舒服，但只有坚持佩戴，时间长了才能矫正和形成良好的习惯，工作生活吃饭才能更顺畅。