周四、周五、周六三天LeSS的学习，提前请好假，做好充足的准备，开始LeSS学习之旅。三天的学习收获颇多。虽然提前买了Large Scale Scrum的书但是但是理解并不深刻，经过三天的学习，对书中的很多内容有了更加深刻的理解，非常感谢吕毅老师把LeSS课程的内容一点一点的分析讲解。
LeSS概述
首先什么是LeSS？
LeSS是应用于共同开发同一产品的多团队的Scrum。
什么意思呢？简言之LeSS也是Scrum，大规模Scrum并不是全新的或者改进后的Scrum。也不是每个团队在基层使用的Scrum。它是如何在大规模环境下尽可能简单的应用Scrum的原则、目的、要素及所表现出来的灵活性。
LeSS应用于多团队--跨职能，跨组件、全特性团队，由3-9人注重学习的人员组成，完成产品开发的所有工作，比如从需求梳理、需求澄清、UI设计、代码编写、测试等所有的工作，完成当前迭代的所有特性（需求），最后交付出可工作的软件（也就是产品发布后，业务方可以使用的软件）。
LeSS在于协同工作--团队之所以协同工作，是因为有一个共同的产品目标，也就是在一个共同的sprint阶段结束时，共同实现一个可交付产品的部分功能。
LeSS用于开发一个产品--什么样的产品呢？一个清晰完整的、端到端的、以客户（用户）为中心的、有真正客户（用户）使用的解决方案。
LeSS框架的概述
LeSS有两个框架：LeSS Framework和LeSS Huge Framework。
LeSS：2-8个团队（每个团队3-9人）
LeSS Huge：8个以上的团队
小型LeSS概述
小型LeSS框架适用于一个产品负责人，该产品负责人负责该产品，并且在共同的Sprint中管理团队的一个Product Backlog（产品待办事项列表），为整体产品的交付不断优化，LeSS框架中的元素与单团队Scrum大致相同：
角色--1个产品负责人，2-8个团队，每1-3个团队1个Scrum Master。关键特点是这些特点都是特性团队（端到端的团队）--真正的跨功能和跨组件的全面型团队，他们在代码共享的环境中协同工作，每个团队都竭尽所能的完整Sprint Backlog中的需求。
工件--每个团队都有一个潜在的可交付产品增量、一个产品待办事项列表和一个单独的Sprint待办事项列表。
事件--整个产品一个共同的Sprint，共同的Sprint针对所有团队，并以完成潜在可交付产品增量结束。
规则和指南--基于经验性过程控制和整体产品聚焦原则的简单扩展框架所支持的规则。
巨型LeSS概述
不论是1000人的产品开发团队，还是只有100人的产品开发团队，由于大量需求的复杂性以及人员的复杂性，分而治之是不可避免的。传统的大规模团队一般会按照如下方式划分：
单一只能组（产品组、测试组、Java组、前端组、UI组等）
体系结构层面的组件组（UI层组、服务器端组、数据访问组件组等）
这种组织架构的划分，使开发变得缓慢而不灵活，看似划分合理，但是极其浪费（比如由于跨团队以来接口，需要长时间的等待、比如跨团队沟通交流、比如在开发的需求很多，都不能交付等），这样会导致需求不能及时交付，长时间延迟需求的ROI，复杂的组织架构设计，通常更多的间接增加管理费用，以及弱反馈和弱学习。这种组织设计，从长远来看，是向内围绕单一技能、体系结构和管理模式设计的，而不是向外围绕客户价值设计的。短期内效果很好，效率还不错，但是把时间轴拉长，对于整个团队是不利的，只发展员工的单一技能，如果需要特殊技能的时候，不得不招具备特殊技能的人才，设置新的岗位，增加组织的复杂度。
但是，在巨型LeSS框架中，当团队超越大约8个团队时，组织划分需要围绕客户关注的主要领域（需求领域）来进行。这反应了LeSS以客户为中心的原则。
规模--需求领域很大，参与的团队通常4-8个，而不只是1-2个。
动态性--需求领域是动态的。随着时间的推移，一个领域的重要性会发生变化，然后随着团队加入或者离开一个需求领域，该领域会增加或者缩小。
共同的Sprint--是否每个需求领域都在各自的Sprint中单独工作，并且延迟到很晚才做集成呢？不是的。巨型LeSS要求在共同的Sprint中持续集成。只存在一个产品级的Sprint，而不是每个需求领域存在不同的Sprint。每个Sprint结束时，都会形成一个集成的整体产品，并且来自所有需求领域的所有团队都在努力的执行整个产品的持续集成。
在巨型LeSS中引入了一个新的角色。每个需求领域都有一个领域产品负责人（这是LeSS在角色上不一样的地方），专门负责该领域的产品待办事项列表的工作。
领域特性团队
领域特性团队在一个需求领域（资产服务）内工作，一个领域产品负责人专注于一个领域的产品待办事项列表中的需求。从团队的角度来看，在一个领域中工作就像在一个小型LeSS框架中工作一样，他们与领域产品负责人积极互动，完成特性（需求或者用户故事）的开发，直到交付。
LeSS原则
#原则1：大规模Scrum也是Scrum
前面说到过，大规模Scrum也是Scrum，它不是新的被改进的Scrum。确切的说，LeSS研究的是如何在大规模环境中尽可能简单的应用Scrum原则、规则、要素和目的。
#原则2：透明度
基于有形的“完成”条目、短周期、协同工作、共同定义，以及对工作场所恐惧的消除。
#原则3：以少为多
LeSS追求简洁，也就是不想要更多的角色，因为更多的角色会导致团队的责任感变弱。不想要更多的工件，因为更多的工件会导致团队和客户之间的距离更远。不想要更多的流程，因为更多的流程会导致团队学习更少，团队对流程的所有权更弱。相反，LeSS希望拥有更少的角色和更负责任的团队，希望拥有更多以客户为中心的团队以便用更少的工件构建更有用的产品，希望拥有更少的既定流程让团队拥有更多的流程的所有权和更有意义的工作。所以，LeSS想要的是以少为多。
#原则4：整体产品聚焦
一个产品待办事项列表、一个产品负责人、一个可交付的产品、一个Sprint--无论是3个团队还是33个团队，客户希望在有内聚力的产品中提供有价值的功能，而不是分离的部件中提供技术性的组件。
#原则5：以客户为中心
专注于了解客户真正的问题并解决这些问题。识别客户严重的价值观。从客户的角度减少等待时间。增加并加强与实际客户的反馈回路。每个人都需要知道他们今天的工作如何与客户直接相关，如何让客户受益。
#原则6：持续改进以求完美
完美的目标是：始终以几乎无成本、无缺陷的方式创建和交付产品，让客户感到满意，让环境得到改善，让生活更美好。为实现这一目标，团队需要不断的做谦逊和激进的改进试验。
#原则7：精益思想
创建一个组织体系，其基础是认可管理者作为导师来应用和教授精益思想，设法改进、促进“停止与修复”实践，并认可“现场观察”（Go See）观念，加入尊重他人和不断挑战现状的改进心态这两大支柱，所有观念和行动都应朝着完美目标前进。
#原则8：系统思维
观察、理解和优化整个系统（而不是局部），并使用系统建模来探索系统的动态。避免将重点放在个人和单个团队的效率或生产力上。客户关心的是整体的从概念到盈利的周期时间和流程，而不是单个步骤，而且局部优化某一个部分几乎总是会对整体优化产生负面影响。
比如通过系统循环图可以推导出增加团队的适应性，可以降低Product Backlog的数量。系统思考给我最大的启发就是从全局思考问题，而不是做局部优化。做局部优化，短期来看确实是一个不错的决定，但是从长期来看未必是一个好的决策。系统思考是一个非常好的将问题可视化出来的一个工具。
#原则9：经验性过程控制
持续检验并调整产品、过程、行为、组织设计和实践，使其以适合当时环境的方式发展。这样做是需要的，而不是遵循一套所谓的最佳实践，因为这样的实践忽视了具体环境，使后续活动变成了某种仪式，阻碍了学习和变革，压制了人们的参与感和主人翁感。
#原则10：排队论
了解排队系统在研发领域的行为，并将这些洞察应用于管理队列大小、队列数上限、多任务处理，以及可变因素等。
总结
3天整个LeSS课程上下来，发现里面很多内容设计的都非常好，每个指南、规则都值得深入学习。课上完了，但是LeSS的内容还远远没有结束。接下来就是思考和复盘LeSS的其他内容了，今天时间有限只复盘这么多。对LeSS感兴趣的同学，可以查看LeSS官网（https://less.works/）
番外篇
首先感谢吕毅老师，温和而又不失热情的把LeSS课讲的那么生动容易理解，真的收货非常多。其次是被吕毅老师强大的逻辑推理能力折服。然后一起学习的小伙伴各个都很厉害，都是来自各个行业（IBM、SAP、字节跳动、平安等）的大佬，那么优秀的人还那么努力，真的也被他们的学习精神所吸引。还有一点就是上课的时候感觉到他们的英语每个人都超级一流棒。只有与高手过招，才知道自己与别人的差距。接下来，继续好好努力，与大佬之间的距离尽量缩小，也希望自己以后可以成为别人口中的故事。