LeSS 介绍

LeSS 介绍. Cary Bao • 2019年11月13日pm12:41 • 敏捷与精益 • 阅读2553. LeSS是Scrum应用于多个团队共同开发一个产品。

构造[设计]的方法有两种：. TobeAgile首页百科敏捷与精益 LeSS介绍 CaryBao • 2019年11月13日pm12:41 • 敏捷与精益• 阅读2576 LeSS是Scrum应用于多个团队共同开发一个产品。

构造[设计]的方法有两种：一种方式是使其变得如此简单，以至于显然没有缺陷，另一种方法是使它变得如此复杂，以至于没有明显的缺陷。

C.A.R.Hoare 单一团队Scrum Scrum是一个经验过程控制开发框架，跨职能的自我管理团队以迭代的增量方式开发产品。

每个带有时间限制的Sprint 都会交付潜在可交付的产品增量。

单个产品负责人负责最大化产品价值，对产品待办事项中的项目进行优先级排序，并基于不断的反馈和学习来自适应地确定每个Sprint的目标。

一个小团队负责实现Sprint目标；没有限制的单一专业角色。

ScrumMaster教授团队为何用Scrum以及如何从中获取价值，指导产品负责人，团队和组织应用它，并充当镜像。

Scrum中没有项目经理或团队负责人。

经验性的过程控制需要透明性，这种透明性来自于短周期开发和可交付产品增量的审查。

它强调对产品及其创建方式的不断学习，检查和调整。

这些是基于以下的理解，在开发中，对于详细而公式化的流程配方而言，事情太复杂，太动态了，从而阻碍了提问，参与和改进。

在《Scrum指南》和《ScrumPrimer》中，强调的是一个团队。

重点不是很多团队一起工作。

这自然导致人们考虑大规模 Scrum。

LeSS LeSS是Scrum应用于许多团队共同开发一个产品。

LeSS是Scrum-Large-ScaleScrum（LeSS）并不是新的和改进的Scrum。

而且这不是底层每个团队的Scrum和在上层运行的一些东西。

而是要弄清楚如何尽可能简单地在大规模环境中应用Scrum的原理，目的，元素以及保质保量。

像Scrum和其他真正敏捷的框架一样，LeSS是具有高影响力的“刚好够用的方法论”。

ScaledScrum不是一个仅在团队级别Scrum的特殊扩展框架。

真正的ScaledScrum是Scrum的扩展。

…应用到许多团队 -跨职能，跨组件，全栈的功能团队，由3–9名学习型人员组成，从UX到代码到视频，这些都可以完成，并创建完成的任务和可交付的产品。

…一起工作 -团队之所以一起工作是因为他们有一个共同的目标，即在共同的Sprint结束时交付一个共同的可交付产品，并且每个团队都在乎这一点，因为他们是负责整个而非部分的功能团队。

…关于一个产品 –什么产品？实际客户使用的广泛，完整的端到端以客户为中心的解决方案。

它不是组件，平台，功能层或库。

背景 在2002年，当Caige撰写Agile&IterativeDevelopment时，很多人认为敏捷开发仅使用于小型团队。

但是当我们两（CaigeandBas)都对将Scrum应用于大型，多站点和离岸开发感兴趣并提出了越来越多的要求。

因此，自2005年以来，我们一直与客户合作以扩展Scrum。

如今，两个LeSS框架（SmallerLeSS和LeSSHuge）已在全球不同领域的大集团中采用： 电信设备—爱立信和诺基亚网络投资和零售银行—UBS瑞银交易系统—IONTrading营销平台和品牌分析—Vendasta视频会议—思科在线游戏（投注）—bwin.party离岸外包—Valtech印度 从大的角度来看，典型的LeSS 应用案例是什么？可能有五个团队分布在一到两个地点。

我们参与了规模达数百人的应用，以及涉及多达一千多人的LeSSHuge案例，涉及许多的开发中心，数以千万计的C++代码以及自定义硬件。

实验，指南，规则，原则 LeSS的前两本书强调：产品开发中没有最佳实践之类的东西。

在特定的情况下，只有适当的做法。

做法视情况而定；轻描淡写地声称他们是“最好的”，从而使他们脱离了动机和背景。

它们成为仪式。

推行所谓的最佳实践会扼杀学习，质疑，参与和持续改进的文化。

人们为什么要挑战最好？ 因此，早期的LeSS书籍分享了我们和我们的客户尝试过的实验，并且我们鼓励并鼓励了这种思维方式。

但是随着时间的流逝，我们发现只有实验的思维方式存在两个问题： 新手小组做出不利于自己的非熟练决策，无目的应用LeSS，存在明显的问题；例如，小组创建了需求区域，每个区域有一个团队。

新手小组问：“我们从哪里开始？最重要的是什么？”可以理解，他们看不到关键的基础知识。

在此基础上的反馈，我们做了反思，并回到了Shu-Ha-Ri的学习模式：Shu -遵循规则学习基础知识。

Ha -打破规则和发现内容。

Ri-掌握并找到属于自己的方式。

在Shu级LeSS的采用中，对于勉强足以启动经验过程控制和整个产品重点的框架，有一些规则。

这些规则定义了两个LeSS框架。

总结并基于这些观点，LeSS包括： 规则 – 入门和构成基础的一些规则。

它们定义了LeSS框架的关键要素，这些要素应当支持经验过程控制和整个产品重点。

例如，对每个Sprint进行一次总体回顾。

指南 -一组适度的指南，可有效采用规则并进行部分实验；根据LeSS的多年经验值得尝试。

指南包含提示。

通常是有帮助的，是需要不断改进的领域；例如三个采纳原则。

实验-许多实验都是视场景而论甚至可能都不值得尝试；原则（从本质上讲，是一组原则），这些原则是从应用LeSS的经验中提取的，这些原则为规则，指南和实验提供了指导；例如，关注整个产品。

LeSS指南和实验是可选的。

指南可能会有所帮助，建议尝试。

但是绕过或放弃那些限制进一步改进或根本不适合的方法。

LeSS完整的示意图： LeSS原则 LeSS的规则定义了LeSS的框架。

但是规则是极简的，并不能回答如何在你特定的环境中应用LeSS。

LeSS的原则提供了做出这些决定的依据。

Large-ScaleScrum还是Scrum-它不是新的和改进的Scrum。

相反，LeSS旨在尽可能简单地弄清楚如何在大规模环境中应用Scrum的原理，规则，元素和目的。

透明度-基于切实可行的项目，短周期，需要共同努力，共同的定义以及消除工作场所的恐惧感。

Morewithless —我们不想要更多的角色，因为更多的角色导致对团队的责任减少。

我们不希望有更多工件，因为更多工件会导致团队与客户之间的距离更大。

我们不希望有更多的流程，因为这会导致较少的学习和团队对流程的所有权。

取而代之的是，我们希望拥有更少的角色，从而拥有更多负责任的团队；我们希望拥有更多以客户为中心的团队，通过减少工件，来构建有用的产品；我们希望拥有更多的团队对流程的拥有权，并通过定义更少的流程来进行更有意义的工作。

我们需要通过减少来获取更多。

关注整个产品 -一个产品待办事项列表，一个产品负责人，一个可交付产品，一个Sprint（无论3个或33个团队）。

客户需要紧密结合的产品中有价值的功能，而不是单独模块中的技术组件。

以客户为中心—重点学习并解决客户的实际问题。

识别付费客户眼中的价值和浪费。

从他们的角度减少等待时间。

增加并加强与真实客户的反馈循环。

每个人都知道他们今天的工作与客户的关系以及如何给客户带来价值。

持续改进追求完美，这是一个完美的目标：自始至终，尽可能低成本的，无缺陷的方式创造和交付产品，让客户感到满意，改善环境并改善生活。

为实现该目标不断保持谦逊和尝试根本的改进。

精益思维–建立一个组织系统，其基础是视经理为教师，他们应用和教授精益思想，设法改进，StopandFix，并实践GoSee。

增添尊重人和持续挑战现状改进思想这两个支柱。

所有人都朝着完美的目标迈进。

系统思考 -查看，理解和优化整个系统（而非部分），并使用系统建模来探索系统动态。

避免关注个人和单一团队效率或者产出的局部优化。

客户关心从概念到现金的整个周期和流程，而不是单个步骤，并且本地优化几乎总是对整体进行局部优化。

经验过程控制-不断检查和调整产品，过程，行为，组织设计和实践，以适应当下情况的方式进行演进。

做到这一点，而不是遵循一套规定的所谓最佳做法，而这些最佳做法常常会忽略当下环境，产生仪式性的追随者，阻碍学习和变革并压制人们的参与和主人翁意识。

排队论 -了解研发领域中队列系统如何运行，并将这些见解应用于管理队列大小，在制品限制，多任务处理，工作包和变化。

两个框架：LeSS和LeSSHuge Large-ScaleScrum有两个框架： LeSS。

2-8个团队LeSSHuge。

8个以上团队 LeSS一词有多个含义，它既表示通常意义下的Large-ScaleScrum，又指smallerLeSS框架（2-8个团队）。

神奇的数字8 实际上，8并不是一个神奇的数字，如果你的团队成功的将SmallerLeSS框架应用到8个团队以上，那就太好了。

但是我们还没有看到…。

这只是一个上限的经验观察。

并且在一些案例中，例如不同复杂的目标，没有经验的多语种跨地域团队，很可能少于8个团队。

无论如何，在某些时候，（1）单个产品负责人不能再掌握整个产品的概述；（2）产品负责人无法平衡外部和内部关注点；（3）产品待办事项列表是如此之大，以至于一个人很难与之共事。

当小组达到临界点时，可能是时候从SmallerLeSS框架更改为LeSSHuge。

另一方面，我们建议先尝试变得更好，更小和更简单，然后再变得更大。

框架通则 LeSS和LeSSHuge框架具有共同的要素： 一位产品负责人和一位产品待办列表在所有团队中有一个共同的Sprint一个潜在可交付的产品增量 内容引用自LeSS官方网站，https://less.works，请前往官网了解更多。

发布者：CaryBao，转转请注明出处：https://tobeagile.cn/2019/11/13/less-%e4%bb%8b%e7%bb%8d/ LeSS敏捷框架 赞(1) CaryBao创始团队 00 生成海报 国际Scrum联盟CSM认证培训|线上|5月4/5/9 上一篇 2019年11月12日am11:24 ScrumMaster，兼职还是全职？ 下一篇 2019年11月20日am9:55 相关推荐 文章 我的LeSS视角 01.6K21 吕毅 2019年10月30日 文章 规模化敏捷的思考|原创：JimWang老师 02.3K10 ShineScrum捷行 2020年3月12日 文章 消除依赖，而不是管理它们 11.7K20 LucyLiu 2019年10月28日 发表评论请登录后评论...登录后才能评论提交 CaryBao创始团队 包尔瑾,TOBEAGILE创始人,企业敏捷教练,看板方法认证培训师和咨询师AKT|AKC,看板方法专业教练KCP,CSP,LeSSPractitioner 46 文章 4 评论 3 粉丝 关注私信 最近文章 KanbanUniversityKMP认证培训|线上|2022/04/9-10&2022/06/04-05 KANBANATNET-A-PORTER–重新获得对流的控制 KanbanUniversityTKP认证培训|线上|2022/01/15 KANBANATVISOTECK–寻找价值的本质 渐进式的研发管理改进之路 最热百科 KanbanUniversity 2020年1月7日 LeSS介绍 2019年11月13日 AgileAlliance敏捷联盟 2019年11月8日 ScrumAlliance及其认证体系 2019年11月7日 关于SCRUM 2019年10月25日 最热文章 2018全球敏捷文章精选 2020年5月20日 ProductOwner工具箱 2020年4月24日 ScrumMaster工具箱 2020年6月3日 敏捷中常用的心理学效应和定律 2020年1月2日 ScrumMaster，兼职还是全职？ 2019年11月20日 标签A-CSM认证(5) CAL认证(5) CLP认证(7) CSM认证(8) CSM认证在线直播(5) CSM认证培训(17) CSM认证培训课程(5) CSP-SM(8) CSPO认证培训(7) LeSS认证(7) SCRUM(8) ScrumMaster认证(20) ScrumMaster认证线上课程(5) Scrum敏捷培训(25) Scrum认证课程(25) 产品愿景(13) 产品经理(12) 产品负责人培训课程(12) 产品负责人认证(8) 大规模Scrum框架(7) 待办列表(10) 敏捷开发(6) 敏捷教练(8) 敏捷教练认证(9) 敏捷认证培训(24) 敏捷领导力认证(6) 梳理需求(9) 规模化敏捷(8) 需求优先级排序(9) 高阶ScrumMaster认证(8)