2018年8月我有幸参加了Bas Vodde上海的三天CLP课程，无论从教学内容还是授课技巧都受益良多。最近我申请到LeSS Friendly Scrum Trainer的资格，申请过程中，我的CSM课件需要Bas的评审。2018年11月Bas给了对我的CSM课件的反馈，毫不夸张地说Bas 几乎是Scan我课件的每一个单词和句子，他严谨的治学态度让我自愧不如。直到最近我才着手更新课件，与Bas的沟通过程中，学到了不少东西，也澄清不少概念。总结一下，分享出来。注意到文章标题，本文不是试图诠释LeSS。
（1）PSPI (Potential Shippable Product Increment) 是LeSS的概念。第一次听说PSPI是在吕毅老师的CSM课上。后来Bas的CLP课上，用PSPI引出了理想的DoD (完成的定义)和Sprint的DoD，我们通常指的DoD是Sprint的DoD，反映了团队对Sprint产品增量“完成”的共同理解和当前的交付能力，Bas 的课上巧妙地图示这两个DoD的区别，让团队看到了gap即未完成的工作，帮助给出团队扩展DoD的方向。结课后，我在CSM/CSPO课上讲授DoD时也采用这种方法，Bas还诙谐地介绍了组织中Undone Department的概念， 尽管这个名称让人听起来不舒服。如果我们对照Scrum指南，她定义了符合Scrum团队当前“完成”的定义（DoD）的潜在可交付功能增量，这个定义作为规范、标准或者指引标准来保证当前产品增量的质量，也同时被用来指导开发团队在Sprint计划会议时能选择多少产品待办列表项。但Scrum中没有明确理想的DoD的定义，更多强调当前Scrum团队对产品增量完成的理解和透明性。
下面这个公式也帮助我们理解完成的定义。
Potentially Shippable = Definition of Done + Undone Work；（弱完成的定义）
如果 Potentially Shippable = Definition of Done （完美的完成定义）
Work in Sprint = Product Backlog Items × Definition of Done
（2）PBR (Product Backlog Refinement（老的说法是grooming)，产品待办列表梳理在LeSS中明确定义是一个持续的活动，包括四种类型的PBR：初始PBR， 总体PBR， 多团队PBR，单团队PBR。但在Scrum中没有明确定义PBR是一个event，Scrum框架中的3355中的5个主要事件，把Sprint本身作为五个事件之一，其它4个有Sprint计划会议、每日Scrum站会、Sprint评审会议和Sprint回顾会议构成。Scrum 定义Sprint本身作为一个事件以外，还是其他所有事件（包括开发工作）的容器。
我更倾向于把Sprint作为一个容器(container), 主要包括四个事件和一个活动。这个活动就是PBR。Scrum中在描述product backlog的章节中提及了PBR的活动, 没有把它单拿出来讨论，实践中容易忽视PBR的重要性，甚至有些团队把PBR和Sprint计划会议混为一起。在我的CSM课上会把PBR单独拎出来，花大量时间讲解PBR。
其实Scrum 中PBR的设计，是把敏捷12条原则中第4条的着实落地了，即“项目过程中，业务人员与开发人员必须在一起工作”， 这样慢慢会演进成大家一起做事的文化或组织的DNA。PBR的工作包括，澄清需求定义验收标准，团队估算PBI大小，拆分PBI，也有可能重新排优先级，识别风险和依赖。
另外一个误区是DoR (definition of ready)的概念，首先声明DoR不是Scrum的内容， 尽管Scrum 提到我们通过PBR的活动把这些能够在Sprint中“完成”的列表条目项称为“准备就绪的”（Ready）条目，但没有明确非要用DoR的字眼。我们用DoR的实践， 但要小心，不要把DoR 理解成这是PO的工作，否则又会变成一个合同游戏(contract game)，那样的话与需求规格说明书没有什么两样。PBR是PO，客户，干系人，团队一起协作对话的持续活动。不是PO一个人的准备和单向沟通。这也是为什么有些讲师提及DoR跟提及Sprint 0一样，非常谨慎。
（3）特性团队（feature team）是LeSS中的概念。Scrum我们讲的是跨职能(cross functional)或多功能团队， 没有提及特性团队。特性团队强调交付客户为中心的端到端的产品功能。 特性团队不仅是跨职能而且是跨组件，自管理的团队。LeSS 中对特性团队和组件团队做了详细的比较，特别在依赖关系方面。 见下图。LeSS要求团队的主体是客户导向的特性团队，LeSS也给出了特性团队采用的路线图。
那么Scrum中的团队是不是特性团队？吕毅老师有文章专门阐述，见文末的参考资料。
LeSS中，对特性的定义取决于产品的定义。产品界定了特性，并且特性在产品中是端到端。
如果组件定义为产品，则组件上的需求将成为特性。
如果平台定义为产品，则平台上的需求将成为特性。
如果“产品”定义为产品，则对“产品”的需求将成为特性。
如果解决方案定义为产品，则对解决方案的需求将成为特性
（4）Scrum团队（Scrum team） vs 团队（team） vs 开发团队（development team） 的混淆
Scrum有三个角色， 即SM, PO 和开发团队。最容易混淆的是开发团队，这里的“开发”经常误解为软件的开发工程师，讲师每次花时间解释“开发团队”的真正意思是“开发”的通称或 泛指， 包括交付PSPI的所具备的相关技能的成员， 比如代码开发，设计，测试，UI, 文档，集成部署等 。LeSS中用 团队（team）一词取代了Scrum中的开发团队以避免混淆。而且LeSS 没有沿用Scrum 团队的提法。Scrum中有Scrum团队的提法，Scrum团队=SM+PO+开发团队。Scrum中开发团队是自组织(self-organized)和跨职能的团队。LeSS 中的团队说法是自管理（self-managed特性团队。酝酿中的2020年新版的Scrum指南还在征集反馈，特别是开发团队的提法会有变更，避免使用“开发”一词， 因为Scrum已经扩展到非软件开发和IT领域。比如：硬件，嵌入式软件、交互功能的网络、自动驾驶汽车、学校、政府、市场、生产运营等。
由于Scrum和LeSS两个框架对Scrum team及team的定义不同，也给我们带来一些困扰，比如回顾会PO参加不参加。Scrum明确回顾会要求Scrum team 都要参加， Sprint回顾会议是Scrum团队检视自身并创建下一个Sprint改进计划的机会。LeSS 中首先是各个团队的Sprint回顾会， 这个回顾会对PO是可选的，然后有一个全体（overall）回顾会， 参加人员有PO， SM、 团队代表、管理层。全体回顾会来处理系统性问题，改进和完善系统。
（5） Scrum 本身混淆的几个地方
我们在Scrum的旅程中会总结出一些好的实践，但这些是涌现出来的实践（不应称为最佳实践），或者我们叫Scrum的模式(pattern)语言, 比如相对估算，用户故事和用户故事点（user story point）; Sprint和发布燃尽图，包括速率的概念等等。 还有一个常见的例子，我们提到Sprint backlog，会马上想到任务（Task），Scrum 没有明确说Sprint backlog 非得是任务级，Scrum提到SBL是团队规划的work，那么work可能是任务，也可能是颗粒度较小的PBI，Scrum没有要求非得拆成任务级别，只不过大多Scrum团队初期会拆解任务。所以我们有必要把规则（rule）, 原则（principle）, 指南和实践（ guide and practice） 分开。 再重复一下，燃尽图，用户故事，相对估算不属于Scrum的内容。
社区中我们也会听到这样的讨论：Scrum 和LeSS欠缺，比如没有给出发布计划和版本管理的具体操作。每个企业和产品都不一样，我们可以共创用户故事地图的方式把发布计划和迭代的开发计划打通，或者PO组织和更新发布计划会议，PBR也是间接的更新发布计划；Sprint评审会结束后也给了PO依据实际真实的数据及时调整发布计划。SAFe的PI (program increment) planning, 包括4个Sprint+ 1 个Innovation Sprint, 实际上还是瀑布式集中化的一次计划会议。当然我们不能否认PI的做法比传统的发布计划思维前进了一大步。
敏捷的思维是发布计划是持续动态的过程，敏捷通过尽早和持续的发布交付价值给客户，我们没有必要去定义一种特定格式和仪式去做发布计划管理，One solution can NOT fit all。
（6） Scrum 和LeSS 共同遵循的原则,Scrum 是当下流行的敏捷方法，是针对复杂性工作团队交付价值的一个框架。那么Scrum 为什么会流行？有人说是CSM的认证模式， XP的出现其实也不晚，DSDM 也有过认证课程。Scrum 在抽象的原则和具体的实践之间找到了一种理想的平衡，所以Scrum 先天是不完整的，是有“缺陷”的，是有意为之的。Scrum不是构建产品的一种过程或技术，而是一个框架。框架的定义是勉强够用（barely sufficient）刚刚好（good enough）， Scrum可以比喻为Game rules， 比如（chess game），体育竞技比赛的游戏规则通常是不变的。
在Scrum指南中并未显式提出多团队Scrum的应用。在真实的工作场景中，我们面临的通常是多个团队共同交付一个产品。多团队增加了工作的复杂性：Product backlog的构建和优先级排序，架构设计，工作的依赖，多团队协作沟通，迭代对齐和集成等等。
在基于一个Scrum的框架下，如何减低复杂度及沟通成本，必要的Scrum会议如何组织，最终交付一个多团队协作的有价值的产品。LeSS （Large Scale Scrum）与Scrum 类似，也力图在抽象原则和具体的实践之间寻求平衡，LeSS 也有不完整的一面，但这是有意为之的。Scrum和LeSS在许多方面没有提供明确的答案，这样对那些期待公式化的答案或寻求看似确定安全又严谨的方法论的人们是一个不小的打击。确定的解决方案会给人们一种舒适的幻觉，人们可以掌控一切。但这种试图定义不确定的过程要付出高昂的代价，为什么呢？
我们生活的时代变了，泰勒科学管理的方法已过时，VUCA 时代面临不确定性和复杂性，构建人类命运共同体应对全球挑战，比如最近的全球疫情。我们必须运用系统思考，必须在透明机制的前提下，用试验性的过程控制来检视和调整我们的方法和行为。
—— Jim Wang
写于2020年3月12日疫情期间
参考资料：
（1） https://blog.odd-e.com/yilv/2017/01/is-team-in-scrum-feature-team.html
（2） Scrum guide at http://shinescrum.com/scrum
（3）https://blog.odd-e.com/yilv/2017/03/seeing-the-system-dynamic-sprint-vs-pi.html
（4）Large-Scale Scrum: More with LeSS, Craig Larman, Bas Vodde
（5） https://less.works/resources/learning-resources/indexeSS