LeSS是什么？
Scrum是一个基于经验过程控制的开发框架，由跨职能开发团队以迭代增量的方式开发产品。在《Scrum指南》中，强调的是一个团队如何工作，而不是多团队如何共同工作。这自然也引发了对大规模Scrum如何运作的思考。
LeSS（Large-Scale Scrum）是将Scrum应用在共同开发一个产品的多团队中的框架。
LeSS并不是新的或改进版的Scrum，也不是在每个团队运行Scrum的基础上再叠加一些东西。相反，它是对于如何尽可能地在大规模背景下应用Scrum的原则、目标、元素和简洁性的探索。与Scrum和其他真正的敏捷框架一样，LeSS也是一种“勉强够用的方法论”，基于以下的特点：
1）适用于多团队：由3-9名学习型成员组成的跨职能、跨组件、全栈的特性团队，包揽从用户体验到代码到视频，独立生产已完成的可发布产品。
2）共同工作：这些团队在一起共同工作，因为他们有着共同的目标，需要在迭代结束时共同交付可发布的产品。每个团队都关心这一目标，因为他们是对整体负责的特性团队，而不是只对产品的一部分负责。
3）在一个产品上：什么产品？一个以客户为中心，客户真正使用的端到端的完整解决方案，而不是一个组件，一个平台，一个层或库。
LeSS的起源
LeSS 起源于 2005 年 Bas Vodde 和 Craig Larman 之间的合作。
2002 年，当Craig Larman撰写《敏捷与迭代开发》一书时，许多人认为敏捷开发只适用于小型团队。然而，Craig Larman和 Bas Vodde都对将 Scrum 应用于大型、分布式和离岸开发感兴趣，并且也收到了越来越多相关的需求。因此，自 2005 年起，他们开始与客户共同合作规模化Scrum。
他们试图找出如何让 Scrum 的精髓在多团队（大型）产品开发中发挥作用，以适应大规模产品开发。由于这在当时还是未知数，Craig 和 Bas 与产品团队合作，根据以下原则调整了组织改进循环：
1）Go See（去现场看）：与亲身参与产品开发和使用的人员一起工作，因为他们会发现开发和使用中的真正问题。
2）系统思考：根据“Go See”过程中的观察，尝试了解开发系统及其影响和相互联系。只有深入了解现有系统及其问题和潜力，才能更好的做出改进。
3）实验：从基于 Go See 和系统思考不断发展的系统心智模型中，我们可以尝试改进哪些事情，并进一步了解它？
通过这一组织改进循环，Bas 和Craig 在大型产品开发中指导了数百次实验。经过十年的实验，他们总结出了最基本的经验，并创建了一个勉强够用的，促进适应性实验的结构 —— LeSS 规则。
如今，两个 LeSS 框架（小型 LeSS 和大型 LeSS）已被全球不同领域的大型集团所采用：
电信设备–爱立信和诺基亚网络公司
投资和零售银行–瑞银集团
交易系统–ION Trading
营销平台和品牌分析–Vendasta
视频会议–思科
在线游戏（博彩）–bwin.party
离岸外包 – Valtech India
就规模而言，采用LeSS的典型团队规模是怎样的？可能是一两个地点，5个团队。他们曾参与这种规模的几百人团队的应用，也曾参与过超过一千人、非常多开发站点、数千万行 C++ 代码以及定制硬件的 大型LeSS 案例。
LeSS学习资源
为了帮助大家学习LeSS，Craig Larman和 Bas Vodde在2008年和2010年出版了两本关于使用LeSS框架进行规模化敏捷开发的书籍。
《规模化精益与敏捷开发：大规模 Scrum 的思维和组织工具》—— 解释了思维、领导力和组织设计方面的变化。
《规模化精益与敏捷开发实践：使用大规模 Scrum 进行大型、多站点和离岸产品开发》—— 根据我们与客户合作的经验，分享了数百个 LeSS 的具体实验，包括产品管理、架构、规划、多站点、离岸、合同等方面的实验。
这本书：《大规模Scrum：More with LeSS》是LeSS系列的第三本书，是前传和入门书。本书综合、阐明并强调了最重要的内容。
除了这些书籍外，可以参考Less.works，获得在线学习资源（包括书籍章节、文章和视频）。
实验、指南、规则和原则
LeSS框架包含以下这些内容：
规则：一些帮助入门和构成基础的规则；它们定义了LeSS框架的关键要素，这些要素需要到位，以支持经验主义过程控制和对产品的整体关注。
指南：一套适度的指南，帮助有效地采用规则和实验子集；基于多年的 LeSS 经验，值得一试。指南包含一些提示。通常很有帮助，并且是需要持续改进的领域；例如“三个采用原则”。
实验：许多实验都非常情景化，也可能根本不值得尝试；例如，尝试……团队翻译。
原则：从 LeSS 应用经验中提炼出的一套核心原则，为规则、指南和实验提供依据；例如，关注整个产品。
LeSS 指南和实验是可选的。指南可能会有所帮助，建议尝试。但要绕过或放弃那些限制进一步改进或不适合的指南。
/ignore-error/1″ width=”604.733″ height=”615.95″ style=” margin-left: 0px; margin-top: 0px; width: 604.733px; height: 615.95px;”>
LeSS原则
LeSS 规则定义了 LeSS 框架。但这些规则非常简单，不包含如何在您的特定环境中应用 LeSS的说明。LeSS原则为做出这些决策提供了基础。
大规模 Scrum 就是 Scrum — 它并不是改进版的新 Scrum。相反，LeSS 是要弄清楚如何在大规模环境中尽可能简单地应用 Scrum 的原则、规则、元素和目的。
透明 — 基于有形的“已完成”产品，短周期，协同工作，共同定义，消除工作场所的恐惧。
简洁 — 我们不要更多的角色，因为角色越多，团队成员的责任就越小。我们不要更多的工件，因为工件越多，团队与客户之间的距离就越远。我们不要更多的流程，因为这会减少学习机会和团队对流程的自主权。相反，我们希望通过减少角色来提高团队的责任心，我们希望通过减少工件来打造更多以客户为中心构建有价值产品的团队，我们希望减少流程来提高团队对流程的所有权并关注更有意义的工作。我们希望用简洁得到更多。
关注整个产品 — 一个产品Backlog，一个产品负责人，同一个可交付产品，同一个迭代 — 不论是3个还是33个团队。客户需要的是有价值的功能，是整体的产品，而不是独立的技术组件。
以客户为中心 — 专注于了解并解决客户的实际问题。识别付费客户眼中的价值和浪费，从他们的角度减少等待时间。增加并加强与真实客户的反馈回路。每个人都了解自己今天的工作如何直接关联并帮助到付费客户。
不断改进，追求完美 — 这是一个完美的目标：无时无刻都在生产即不花钱，又无缺陷，客户满意，改善环境，让生活更美好的产品。为了实现这一目标，我们要无何止地进行谦卑而彻底的改进实验。
精益思维 — 创建一个以“管理者为师”为基础的组织，管理者应用并传授精益思维，进行管理改进，提倡“停下来修复”，实践“去现场看（Go See）”。再加上以为为本和不断挑战现状的改进心态这两大支柱。所有这些都是为了实现完美的目标。
系统思考 — 洞察、理解和优化整个系统（而非局部），利用系统建模探索系统动态。避免只关注个人和团队的效率或生产率的局部优化。客户关心的是从概念到现金的整体周期。
经验主义过程控制 — 不断检视和调整产品、流程、行为、组织设计和实践，以适应形势的发展。要做到这一点，而不是遵循一套规定的所谓最佳实践，因为这些最佳实践忽视了具体情况，造成了仪式化的追随，阻碍了学习和变革，压制了人们的参与感和主人翁意识。
排队论 — 了解研发领域中队列系统的行为方式，并将这些洞察应用于队列规模、在制品限制、多任务处理、工作包和可变性的管理。
两个框架：LeSS 和 大型LeSS（LeSS Huge）
大规模Scrum有两个框架
LeSS：2-8个团队
LeSS Huge：8个以上团队
LeSS这个词有双重含义，既指一般意义上的LeSS（大规模Scrum），也指LeSS中更小的框架。
神奇的数字8
实际上，8并不是一个神奇的数字，如果你们能够在超过 8 个团队的情况下成功应用较小的 LeSS 框架，那就太好了！但我们目前还没有看到成功案例。这只是我们观察经验中的一个上限。在某些情况下，例如多地点，缺乏经验的纯外语团队合作的复杂项目中，这个上限可能小于8。
无论如何，在某些情况下，(1) 单个产品负责人无法再掌握整个产品的全局；(2) 产品负责人无法平衡外部和内部的关注点；(3) 产品 Backlog 太大，一个人很难处理。
当团队达到这个临界点时，可能是时候从较小的 LeSS 框架更改为大型 LeSS 框架了。另一方面，我们建议在变得更大之前首先尝试变得更好、更小、更简单。
当团队达到这个临界点时，也许就该从较小的 LeSS 框架转向 LeSS Huge 了。另一方面，我们建议在变得更大之前，首先尝试变得更好、更小、更简单。
框架共同点
LeSS 和 LeSS Huge 框架具有共同的要素：
- 一个产品负责人和一个产品 Backlog
- 所有团队有一个共同的 Sprint
- 一个可交付的产品增量
LeSS框架概要
小型LeSS框架针对的是（有且仅有）一个产品负责人管理产品，Sprint节奏相同的团队共同在这个产品Backlog上工作，对整个产品进行优化。
LeSS框架的元素与单团队Scrum大致相同：
角色 — 一位产品负责人、2到8个团队、一个Scrum Master负责1到3个团队。最重要的是，这些团队都是特性团队–真正的跨职能、跨组件的全栈团队，他们在共享代码环境中工作，各司其职，共同完成项目。
工件 — 一个潜在的可交付产品增量、一个 Product Backlog，以及每个团队单独的 Sprint Backlog。
事件 — 整个产品共享一个共同的Sprint；它包括所有团队，产出一个共同的潜在可交付产品增量。
规则和指南 — 勉强够用的规模化框架中的规则，用于经验流程控制和聚焦整体产品。指南可能会有所帮助。
LeSS Huge框架
需求领域（Requirement Areas）
在 LeSS Huge 框架中，当超过八个团队时，就会围绕客户关注的主要领域（称为需求领域）对团队进行划分。这体现了以客户为中心的 LeSS 原则。
规模 — 需求领域比较大，通常包含4-8个团队，而不是一两个。
动态 — 需求领域是动态的，随着时间的推移，需求领域的重要性会发生变化，然后随着团队的加入或离开（如加入或离开另一个现有的区域）而扩大或缩小。
示例 — 例如，在证券产品（股票交易）中，这些可能是客户感兴趣的一些主要领域— 需求领域：
交易处理（从定价到捕获再到结算）
资产服务（例如处理股票分割、股息）
新市场准入（例如尼日利亚）
从概念上说，在产品Backlog中，添加了一个需求领域属性，并且每个待办项都被归入一个且仅一个领域。
共同Sprint — 每个需求领域都按自己的Sprint工作，到未来某一天再延迟集成？当然不。
在 LeSS Huge 中，在一个共同的 Sprint 中持续集成。
只有一个产品级的 Sprint，而不是每个需求领域都有不同的 Sprint。它以一个集成的整体产品为终点，所有需求领域的所有团队都在努力对整个产品进行持续集成。
领域产品负责人（Area Product Owners）
LeSS Huge 引入了一个新角色。每个需求领域都有一个领域产品负责人，专门负责该领域并关注其领域产品Backlog。
大型产品团队通常会有几个支持性的产品经理，专门负责不同的客户领域，其中一些可能会担任区域产品负责人。有时，产品负责人同时还兼任一个领域产品负责人；这在规模较小的 LeSS Huge团队中更常见。
领域特性团队（Area Feature Teams）
领域特性团队在一个需求领域内共同工作，由一位领域产品负责人管理领域产品Backlog。从团队的角度看，在领域内工作，和在小型LeSS框架内工作类似，他们与领域产品负责人互动，就像在团队里和产品负责人互动一样。
关于规模的关键点：许多特性团队共同在一个需求领域中工作。
一个需求领域通常有4到8个团队。
这意味着需求领域很大。
每个需求领域都作为一个（小型）LeSS团队，各个LeSS团队都在一个共同的Sprint中并行工作，有时我们会将LeSS Huge中的Sprint总结为LeSS堆栈。
参考资料
