引子

精益思维是一种行之有效的系统，可以扩展到大型开发，丰田和其他公司已经证明了这一点。尽管最常用于产品，但它也用于服务领域-在Toyota内部以及医疗保健等领域。

我们用来传达关键思维错误和机会的隐喻（来自精益倡导者Don Reinertsen）是接力赛的一项运动。

考虑一场接力赛。赛车手们站着等待着同事的接力棒。财务部门的会计师对这种可怕的未充分利用的“浪费”感到震惊，可能会强制执行“ 95％的资源利用”的政策目标，以确保所有赛车手都忙碌而“富有成效”。他建议，也许跑步者可以同时进行三场比赛以提高“资源利用率”，或者他们可以在等待接力棒的同时上山。

有趣的…但是这种思想是许多传统的管理和产品开发过程的基础。相反，这是精益思维的中心思想：

注意接力棒，而不是跑步者。

您的组织是否根据人们的忙碌程度或花多少时间观察跑步者来衡量“生产力”或“效率”？还是以向真正的客户快速交付价值从而衡量“警棍”的方式衡量“生产力”？您的工作中的废物价值比是多少？价值流的障碍是什么？人们如何受到激励以不断努力改善价值流？精益思想解决了这些问题。

精益思维：大局

背景

精益（或精益思维）是丰田工程师在麻省理工学院完成研究生工作时使用的英文名称，该系统现在称为Toyota Way。丰田是一家强大而富有韧性的公司，随着时间的推移，它似乎会不断进步。例如，2014年《福布斯》将丰田公司列为全球最大和最有价值的汽车公司。至尊丰田公司专门用一章将其可持续发展的业绩与同行业中的其他公司进行比较。

丰田汽车远非完美之选，在精益思想中找不到其他系统可以借鉴的独特东西。我们不建议丰田或精益思维是唯一可以学习或简单模仿的模型。但是，它是一个长期完善的有效系统，来自一个相对健壮和可持续的公司。

精益的支柱不是工具和减少浪费

关于精益有一些常见的误解。本节从清除这些内容开始。精益思想和丰田的本质和力量是什么？

当我第一次开始学习丰田生产系统时，我被[一体式流程，看板和其他精益工具]的强大功能所迷住。但是一直以来，丰田公司经验丰富的领导者一直告诉我，这些工具和技术并不是关键。TPS背后的强大力量是公司对不断投资于员工并促进持续改进文化的管理承诺。经过将近20年的学习…..这终于沉没了。（强调添加）[Liker04]

丰田汽车专家若松和近藤简洁地说：

[Toyota系统]的本质在于，每位员工都有机会以自己的工作方式发现问题，解决问题并进行改进。

管理工具不是精益的支柱

上面的引用强调了一个关键点，因为多年来有一些表面上的“精益”推动者将精益思想减少到机械化，肤浅的管理工具（如看板和队列管理）的水平。这些派生的描述忽略了丰田专家的核心信息，他们强调成功的精益思想的实质是“先造人，然后造产品”，以及通过不断改进来“挑战现状”的文化。

将精益思想减少到看板，队列管理和其他工具上，就像将工作民主制减少为投票一样。投票是好的，但民主却更加微妙和困难。考虑一下几年前我们在日本访问丰田时拍摄的照片中显示的丰田内部座右铭。它抓住了精益的核心，总结了对教育人们成为熟练的系统思想家的关注：

将精益思维简化为工具的做法是，公司不得不多次陷入陷阱，而之前，这些公司只是肤浅而未成功地尝试采用他们认为精益的东西。

……直到美国汽车制造商用尽其他所有理由来解释丰田的成功（日元被低估，温顺的劳动力，日本文化，卓越的自动化）之后，他们才最终承认丰田的真正优势在于其驾驭“智慧”的能力。普通员工。[Hamel06]

因此，丰田人认为精益六西格玛代表六西格玛工具，但不代表真正的精益思想。前丰田工厂和人事经理解释道：

精益六个西格玛是工具和培训的汇编，专注于隔离项目以降低单位成本……丰田的方法[…]更为广泛和深入。起点是“丰田之道”尊重人并持续改进的理念。原则是培养不断改进流程的高素质人才。责任不在于黑带专家，而是负责运营的领导阶层，他们是老师和教练。[LH08]

减少浪费不是精益的支柱

《精益思维》一书理所当然地受欢迎，并向更广泛的读者介绍了一些丰田的想法。我们建议使用它，同时观察到它代表了丰田系统的简明视图。精益思想极大地借鉴了1980年代和1990年代初专注于丰田生产系统的研究，并在丰田自己的《丰田之路2001》之前发表，从内部人士的角度总结了更广泛原则的优先级。精益思想的副标题是“ 消除 浪费 并在您的组织中创造财富”，因此毫不奇怪，仅阅读一本书的人常常将精益总结为“消除浪费”。

尽管有用，但减少浪费并不是精益的支柱。它仅在Toyota Way 2001的深处提到了几个级别。另外，在“ 精益思维”中，诸如Go See（在丰田汽车中突出显示）之类的杰出精益原则以一种有趣但仅是传闻或次要的方式进行了处理，从而有可能错过丰田中某些精益原则的相对重要性。学习精益思维，学习更多推荐读物。

精益的两大支柱

什么是精益的支柱？丰田总裁加里·康维斯（Gary Convis）：

丰田之路可以通过支持它的两个支柱进行简要总结：持续改进和尊重人。持续改进（通常称为kaizen）定义了丰田开展业务的基本方法。挑战一切。比个人做出的实际改进更重要的是，持续改进的真正价值在于创造一种持续学习的氛围以及一个不仅接受而且实际上接受变化的环境。这样的环境只有在尊重人的地方才能创造-因此，丰田之路的第二大支柱。（添加了重点）

丰田首席执行官渡边胜昭（Katsuaki Watanabe）说：

丰田之路有两个主要支柱：持续改进和尊重人。尊重是与人合作的必要条件。“人员”是指员工，供应合作伙伴和客户。…我们并不意味着最终客户；在装配线上，下一个工作站的人也是您的客户。这导致团队合作。如果您采用了这一原则，那么您还将继续分析自己所做的事情，以查看自己做得是否完美，从而不会给客户带来麻烦。这将提高您发现问题的能力，并且如果您仔细观察事物，将会导致持续改善。丰田之道的根源在于对现状不满意；您必须不断问：“我们为什么要这样做？” （添加了重点）

尊重人并不断改进，“挑战一切”，树立“拥抱变化”的心态。这些精益的支柱将在本章后面进行扩展。如果精益采用计划忽略了它们的重要性（我们将其称为“ 货物崇拜”精益采用），那么对于精益实现可持续成功的基本理解和条件将缺失。

为什么要“精益”？精益与丰田之道

丰田系统的英文术语“精益”是为了将批量生产与丰田的非大众生产（精益生产）形成对比。这意味着批量的急剧减少，不再在规模经济上竞争，而是在适应能力，避免库存和以很小的单位工作的能力上竞争— LeSS中也存在这些主题。

《改变世界的机器》的两位作者继续写着《精益思维》，这是一个受欢迎的导言，总结了五个原理。

在3M应用精益思维的Mary Poppendieck 在精益软件开发的出色著作中，Tom Poppendieck提高了人们对精益与敏捷软件开发方法的对应性和互补性的认识。Scrum的共同创造者Jeff Sutherland和Ken Schwaber研究了Toyota和精益思维。

精益系统的相对广泛的描述是Toyota Way，Toyota产品开发系统，Toy of Toyota，Extreme Toyota和精益产品和流程开发。所有这些都是基于对丰田的长期研究。除了其内部的Toyota Way 2001外，Toyota还使用Toyota Way文本进行教育。对精益的介绍与这些描述相似。

精益总结：精益思想屋

精益思想屋在“房子”图中总结了现代丰田之路，因为丰田系统的早期版本首先是在丰田内部通过类似的房子图总结的。这所房子还定义了本导论的主要部分，例如14条原则。本简介的其余部分按照以下顺序遵循图的主要元素：

1. 精益的目标
2. 精益的基础​​：精益思考的经理-老师
3. 尊重人
4. 持续改进
5. 14条原则
6. 精益产品开发

精益的目标

广义上讲，丰田公司精益思想的全球或系统目标是以可持续的速度尽可能快地从“概念转变为现金”或“定单转变为现金”，以便快速地将有价值的东西（交付给客户和社会）。所有过程的周期时间越来越短，同时仍然达到了最高的质量和士气水平。丰田致力于减少周期时间，但绝不通过偷工减料，降低质量或以不可持续或不安全的步伐进行；相反，通过不断的持续改进，这需要一种对人们有意义的尊重的公司文化，在这种文化中，人们认为他们有挑战和改变现状的人身安全感。

丰田生产系统（TPS）的创建者大野耐一（Taiichi Ohno）的话表达了这一目标：

我们正在做的只是看时间线，从客户下达订单到我们收取现金的那一刻。我们正在通过减少非增值浪费来缩短时间表。

因此，精益的重点是指挥棒，而不是奔跑者-消除瓶颈，以更快地为客户提供价值，而不是通过尝试最大限度地利用工人或机器来进行本地优化。这也是Scrum的重点-在每个短时间的迭代中提供有价值的功能。

丰田汽车（及其雷克萨斯和Scion品牌）不仅制造汽车，而且还成功有效地开发新产品-精益原则适用于产品开发。丰田如何在产品开发和生产这两个主要过程中实现“全球目标”？

• 发展 – 通过产生更多有用的知识并有效地使用和记住它，超越竞争。
• 生产 – 通过专注于短周期，小批量和排队，停止寻找并解决问题的根本原因，不懈地清除所有浪费（等待，交接等），从而改善了竞争。

此介绍稍后将返回学习和改进。当然，这些方法不是互相排斥的。丰田发展提高了生产能力。

精益的基础​​：精益思考的经理即老师

在日本首次访问丰田汽车时，我们采访了人们，以了解有关其管理文化和教育体系的更多信息。我们了解到的一件事是，大多数新员工在开始其他工作之前首先要接受几个月的教育。在此期间，他们学习精益思维的基础，学习了解“浪费”（我们将返回的主题），并在Toyota的许多领域进行实际操作。这样，新的丰田人…

• 学会“看整体”（系统思考）
• 学习了解精益思维在不同领域的应用
• 学习改善的心态（持续改进）
• 欣赏丰田的一项名为Go See和gemba的核心原则

去看意味着人们，尤其是管理人员，预计将，而不是坐在“去用自己的眼睛看到”办公桌后或相信真理只能从报告或数字来学习。这与了解 gemba 的重要性有关–进入价值型工作人员实际所在的一线价值工作场所。

我们还了解到，潜在的执行经理通过多年动手的精益思维实践并在与他人的指导下不断努力。丰田章男（Eiji Toyoda）出任总裁时，对管理团队说：“我希望您积极地训练自己的员工如何思考自己” [Hino06]。请注意，这不是简单的一条消息让别人觉得自己。相反，管理文化是管理者充当 思维技能的老师 。丰田公司的经理受过精益思维，持续改进，根本原因分析，可变性统计和系统思维方面的教育，并在这些思维工具中指导其他人。

由此，我们尤其感到赞赏的是，要成功采用精益管理，任何有意义的持续成功都需要具备管理素质-领导团队不能“倾听”精益支持。丰田（Toyota）是少数几个表现出这些品质的公司之一。总结一下：

• 长期哲学-公司中的许多人都通过经理老师的课程和辅导来学习精益思维。
• 长期哲学-几乎包括管理层在内的所有管理人员必须对精益原则有扎实的理解，已经实践了多年，并向他人传授。
• 长期的哲学—经理老师培养了系统思维和过程改进型解决问题的思维能力，并将其教给他人。这种文化充满了思想和行为，“让我们停下来，了解问题的根本原因。”

经理即老师 -丰田内部的座右铭是“ 好思想，好产品”。他们如何实现构成成功基础的“良好思维”？这是通过指导文化来实现的。经理应该是其工作领域的实际掌握者（俗话说，“我的经理可以比我更好地完成我的工作”），应该理解精益思想，并应该花时间教别人。我们在日本的一次采访中了解到，丰田公司的人力资源政策包括对经理花在教学上的时间的分析。简而言之，在精益思维，“制止和固定权利”以及改善心态的原则下，经理不再只是监管，而更多是老师。这样，丰田DNA得以传播。

丰田北美公司总裁Atsushi Niimi说，向外国经理传授丰田方式的最大挑战是：“他们想成为经理，而不是老师。”

人们越了解精益，就越会意识到该基金会是经理和老师，他们生活和教书并具有长期动手经验。基础不是工具或减少浪费。

任何希望在精益开发方面取得成功的公司执行团队都需要注意这一基本课程，即他们不能“呼吁”他们的支持以“精益”。

支柱一：尊重人

支柱二：持续改进

14条原则

引用丰田董事长赵富士夫的话：

许多优秀的美国公司都尊重个人，并实践改善和其他[Toyota]工具。但是重要的是将所有要素整合为一个系统。必须每天以非常一致的方式进行练习。

数十年来的直接观察和与丰田人的访谈产生的《丰田之道》（Toyota Way）书中描述的14条原则涵盖了更广泛的系统的一部分。

精益产品开发

丰田人很好地执行了两个关键流程：（1）产品开发和（2）生产。密歇根大学的研究人员对丰田和北美公司的产品开发有效性进行了为期三年的研究[LM06]。结果呢？…

例如，丰田工程师的平均模具设计完成时间为五个月，竞赛为十二个月。所有这些，由于其开发实践的有效性，在保持全球任何主要汽车公司最低的研发与销售比率的同时。

他们是如何做到的呢？精益产品开发的重点是什么？

超越比赛

例如，当丰田开发混合动力普锐斯时，它们创造了什么？

• 汽车的设计（以及嵌入式软件的实现）；在开发中，他们拥有知识价值流，可以创造有利可图的生产价值流
• 关于客户，替代品，实验的知识或信息
  
  

精益产品开发（LPD）专注于创造比竞争产品更多的 有用 知识和学习。而且，利用这些知识，不要忘记所学到的东西，而浪费工作的成果。

并非所有的新知识或新信息都有价值。理想的做法是创建对经济有用的新信息[Reinertsen97]。这具有挑战性，因为这是一个发现过程，您赢了一些，输了一些。基于信息理论的简单见解，一种通用的精益策略是增加所 创建信息的价值并降低创建知识的成本。

高价值信息 -精益和敏捷开发中的几个想法会有所帮助。例如：

• 专注于不确定的事物 —在Scrum中，一项优先排序准则是选择尽早实施和测试不清楚或有风险的事物。反馈的价值之所以很高，恰恰是因为结果的可预测性较差-可预测的事情对我们没有太多帮助。
• 专注于早期测试和反馈 -信息具有延迟的实际成本，这就是为什么在漫长的顺序周期结束时仅进行一次测试（由于误导性的本地优化（认为它会降低测试成本）所致）的原因之一不熟练 经过18个月的开发，在压力性能测试中发现关键的架构决策存在缺陷，这可能是非常昂贵的。在精益（和Scrum）中，具有早期反馈回路的短周期至关重要。通过在包括测试在内的短周期内及早实施难以预测的事情，可以降低延迟成本。

低成本信息 – 减少批次大小和周期时间的间接好处探讨了采用精益和敏捷原则最终如何减少了流程的间接成本。实际上，可以通过降低变更成本（与敏捷性竞争）来广泛地将这些方法视为成功的方法。这包括降低学习成本。例如：

• 专注于大规模测试自动化 -了解缺陷和行为。设置成本非常重要（如果您当前正在进行手动测试），但是重新执行成本几乎为零。
• 专注于持续集成 —了解缺陷和缺乏同步。通过频繁地进行小批量集成，团队可以减少由于集成大量代码而产生的非线性工作量所带来的平均开销成本。
• 着重于专家的指导和知识的传播，以减少重新发现的成本。

精益产品开发实践

节奏

在生产和开发中，以规律的节奏或节奏工作是精益原则[Ward14]。心跳稳定。在精益生产中，这称为节拍时间。在开发中，它称为节奏。在定期的时间范围内进行（和举行可预测的会议）的Scrum实践说明了节奏。在精益产品开发中，Cadence是一个强大的原则，因此将对该主题进行更详细的研究……

关于节奏，有些基本的东西是非常人性化的：人们欣赏或想要生活和工作中的节奏，并欣赏或想要这些节奏中的仪式 [Kerth01]。我们大多数人的工作节奏为七天。有星期二上午的每周例会。等等。简单地说，工作节奏可以提高可预测性，计划和协调性。在更深层次上，它反映了我们生活的节奏。

在采用LeSS的大型团队中（以前这些团队几乎没有或没有整个系统的节奏，并且工作时间很长，他们很无聊），通常听到人们说：“一个普通的短Sprint是我们采用的最有益的方法。” 这反映了人们对节奏的欣赏程度。

假设一个小组不在某个时间范围内工作，但是他们有可能可以在一天中的任何时候交付一个正在运行的经过测试的系统（这是一个很好的地方）。假设他们想召开协调计划会议（因为涉及多个团队）并且他们想举行总体回顾。他们的两个选择是（1）随时间推移半随机地保存这些事件，或（2）定期保存它们。这种精益原则表明了后者的选择。

节奏和时间盒

改进节奏的一种流行方法是时间盒（在Large Scale Scrum中使用），它是固定的（通常是较短的）开发工作周期，例如两周的时间框。团队应在固定期限结束时交付或展示某些东西，即小型且做得很好的事情，而不是大型且部分完成的事情。持续时间可能不会更改，但是工作范围可能会有所变化，以适应时间表。

时间盒并不是解决所有知识工作问题的灵丹妙药，但它具有以下优点：

• 时间盒可强制执行节奏。
• 开发工作通常是模糊的无边界（或弱约束）工作。当团队知道时间表于3月15日结束时，它将限制模糊工作并增加焦点。因此，定时装箱可限制范围蠕变，限制镀金并增加关注度。
• 时间装箱减少了分析瘫痪。
• 假设您正在上大学，并且在星期一有作业。您什么时候开始？对于许多人来说，答案是“接近星期一”。这就是所谓的学生综合症 [Goldratt97]，而计时则是一种平衡。
• 如果团队必须在两周之内完成出色的工作，那么当前工作方式中的浪费和无效就变得十分痛苦。时间装箱创建了一个不断改进的变革力量。这是减少批次大小和周期时间的间接好处中涵盖的“湖石”改善效果。
• 时间装箱简化了计划。
• 人类可能对时间变化比对范围变化更敏感，人们对“太晚了”的记忆要比“比我想要的少”。时间盒避免了信心侵蚀时，开发产品的人说，再次出现这种情况对企业的利益相关者，“……也许在一个多星期就全部完成。”

重用信息或知识

怎么样？

• 精益的文化辅导大师工程师和管理者，教师再利用的信息。
• 从侧面传播知识的实践社区（CoP）。CoP是LeSS的组织元素。
• 现代的以Web为中心的工具，例如Wiki。
• 在硬件和软件中学习和交流设计模式。这些利用了现有设计见解的利用。

Obeya：具有可视管理功能的专用房间

精益产品开发鼓励团队空间（或“大房间”，对于团队来说足够大）而没有内部隔板或墙壁，跨职能团队在此工作并见面，而企业家的总工程师坐在那里。墙壁上覆盖着大型的项目和工程信息物理显示器，以支持可视化管理。与在单独的办公室或小隔间中工作的人们形成对比的是，团队间中存在沟通障碍，例如团队成员之间的分隔。Obeya是不一样的大型开放式空间结构。这意味着有是一个专门的房间一个跨职能的团队，其壁用于可视化管理。

这张照片是对传统固定墙的一种变化，是滚动的白板。

具有业务控制权的企业家总工程师

在许多（也许是大多数）产品组织中，产品管理小组负责业务目标和功能选择，成员不是具有最新且深刻的技术深度的总工程师。丰田的做法有所不同。他们的产品开发由一位具有“卓越的技术卓越性”的伟大首席工程师领导，他也对新产品的商业成功负有责任。在丰田公司，产品和工程部门的领导者由一位企业家总工程师组成，他了解市场，产品管理，利润和工程技术。

基于集合的并行工程

您看到了如下发展吗？…选择一种解决方案或设计或为其原型（一种用户界面，一种体系结构，…）

基于集合的并发工程也称为基于集合的设计，这是不同的。例如，不是由一个工程师或一个团队来创建一种冷却系统设计，而是由不同的团队在丰田公司并行探索几种替代方案，其他组件也可以进行探索。探索和组合这些替代方案，并逐步循环过滤，从最初的大量替代方案，然后是较小的替代方案，收敛到解决方案，依此类推。他们通过增加选择和组合来超越竞争。

在软件方面，朝这个方向迈出的一步是为非平凡的设计元素探索至少两个替代方案。例如，我们与一个团队合作，该团队必须为称为JDF的打印协议构建处理程序。我们不是将所有人围成一堵白板墙，而是作为一个团队进行一种设计，而是分成两组，在团队室两端的两个巨型白板（敏捷建模）中工作。每隔45分钟左右，我们就会互相拜访对方的墙体设计，并进行“展示和讲述”，从而相互收集想法。快要结束时，我们聚在一起，研究了这两个设计思想（涵盖大白板），并确定了这两个更吸引人。然后，团队从墙上绘制的设计思路中汲取了灵感，实施了该方案。

基于集合的设计精神，即使不像丰田公司那么详尽，也可以应用于许多设计问题。您可以并行创建原型：

• 两个或三个用户界面替代
• 性能关键组件的两个替代方案，…

精益生产课程可以帮助开发吗？

新产品开发（NPD）或研发（R＆D）并不是可预测的重复生产（制造），并且假设它们相似是造成1900年代初期制造业在研发中滥用“规模经济”管理实践的原因之一；例如，顺序开发和需求的大批量转移。

但是，精益生产中应用的一些原理和思想（包括短周期，小批量，停产，修复，视觉管理和排队理论）已成功应用于精益开发。为什么？现代精益生产是不同的，小批量，排队和循环时间部分反映了排队论的见解（在其他见解来源中），这是为网络中可变行为而创建的一种学科，它比传统制造业更像发展。

在某些产品组织中，具有讽刺意味的是，制造工程师已经进行了革新，采用了精益生产，从“规模经济”转向小批量生产而没有浪费的灵活性和灵活性。但是，这些教训（非常适合NPD）仍未被研发管理部门使用，他们继续采用较早的规模经济制造管理中的实践。

话虽这么说，但请注意：NPD不是制造业，这两个领域之间的类比是脆弱的。与生产不同，NPD（并且必须）充满发现，变更和不确定性。在新产品开发中，某些可变性既正常又理想；否则，不会做任何新的事情。因此，精益思维自然包括独特的发展实践。

结论

在研究精益思维时，很容易看出它是一个与敏捷原则相交的广泛系统，涵盖企业的所有组和功能，包括产品开发，销售，生产，服务和人力资源。精益思想适用于大规模产品开发-实际上，它适用于企业。

精益思想是远远不止的工具，如看板，可视化管理或队列管理，或者仅仅是消除浪费。在丰田公司可以看到，这是一个建立在精益思想的经理-老师基础上的企业系统，它具有尊重人和持续改进的支柱。它的成功引入将需要数年，并且需要广泛的教育和指导。要重新引用丰田公司董事长赵富士雄：

许多优秀的美国公司尊重个人，并实行改善和其他[精益]工具。但是重要的是将所有要素整合为一个系统。必须每天以非常一致的方式进行练习。

推荐读物

• 杰弗里·里克尔（Jeffrey Liker）博士的《丰田之路》（Toyota Way）是一位研究人员的详尽而有说服力的总结，该研究人员花了数十年研究丰田及其原理和实践。
• 日野聪教授在丰田汽车内部的研究。日野花了很多年从事产品开发工作，随后又从事了学术工作。日野“花了20多年的时间研究本书的主题。” 这是一本数据驱动的书，着眼于原始精益思维管理系统的发展和原理。
• Osono，Shimizu和Takeuchi撰写的Extreme Toyota是经过6年的研究和220次访谈而对Toyota Way的价值观，矛盾和文化进行的深入研究。它包括对丰田强劲业务业绩的深入分析。竹内弘孝（Hirotaka Takeuchi）还是1986年著名的《哈佛商业评论》文章“新产品开发新游戏”的合著者，该文章介绍了Scrum的关键思想。
• 艾伦·沃德（Allen Ward）的精益产品和流程开发以及利克尔（Liker）和摩根（Morgan）的丰田产品开发系统对于从精益角度洞悉开发很有用。
• 丰田文化，由Liker和Michael Hoseus撰写。Hoseus曾在丰田公司担任工厂经理和人事经理，使内部人士对这本精益企业的工作原理有深入的了解。
• 博士精益思维。沃马克和琼斯（Womack and Jones）是对一些精益原则的有趣且写得很好的总结，这些精湛的原则是由精通本学科的作者撰写的。正如本章前面所警告的那样，它提出了一种轶事和简明的观点，可能给临时读者带来错误的印象，即精益的关键在于减少浪费，而不是理解精益思想并帮助建立尊重基础的经理教师文化。为人们服务，并通过Go See和其他行为进行持续改进。
• 改变世界的机器：沃马克，琼斯和鲁斯的精益生产故事基于麻省理工学院对精益和丰田系统进行的五年研究。
• 大野泰一的工作场所管理是丰田生产系统的创造者撰写的一本简短的书。它已经绝版，但Jon Miller最近对其进行了重新翻译，现在可以使用。该书没有太多讨论TPS，但包含一系列简短的章节，很好地展示了大野大一对管理和精益系统的看法。
• Mary和Tom Poppendieck的著作《精益软件开发》和《实现精益软件开发》是写得很好的书，它们在精益思维，系统思维和敏捷开发之间建立了重要的联系。

转载自： https://less.works/less/principles/lean-thinking.html

Nexus 指南的目的

Nexus 是开发和维护规模化产品和软件开发的框架。它使用 Scrum 作为其构造基石。本指南包含 Nexus 的定义，其中包括 Nexus 的角色、事件、工件以及将它们组织在一起的规则。Ken Schwaber 和 Scrum.org 开发了 Nexus，Nexus 指南也由他们撰写和提供。

Nexus 的定义

Nexus（名词 ）：人或事物之间的关系或连接。

Nexus 是一个框架，由角色、事件、工件和将它们组织在一起的规则组成，它把大约 3 至 9 个 Scrum 团队共同工作于同一份产品待办列表以构建满足目标的集成增量的这些工作结合和编排在一起。

Nexus 的背景

软件交付是复杂的，可工作软件的集成有许多工件和活动必须协调，以构建“完成”的成果。这项工作需要被组织、安排顺序、消除依赖，并依阶段产出成果。

许多开发人员已经在使用 Scrum 框架，作为一个团队一起协同工作，致力于开发和交付可工作软件的增量。然而，如果不止一个 Scrum 团队工作在同一份产品待办列表和共同代码基的同一产品上，则经 常会遇到困难。如果这些开发人员分别处在不同地点的团队，他们所做的工作相互影响，他们如何沟 通?如果他们在不同的团队中工作，他们如何集成和测试增量?这些挑战出现在两个 Scrum 团队将他 们各自工作集成为一个单一增量时，在三个或更多团队协作时，将会显著地变得更为困难。

在每个 Sprint 中协作构建(至少一次)一个完整和“完成”增量时，团队之间的工作会产生许多依赖。 这些依赖涉及:

1. 需求：需求范围可能重叠，并且它们实现方式也可能会相互影响。当排序产品待办列表和 选择需求时，应该考虑到这些重叠与影响。
2. 领域知识：团队成员拥有不同的商业和计算机系统的知识。他们的知识应该分布在各个 Scrum 团队中，以确保团队具备他们工作所需的知识，以便在 Sprint 期间将 Scrum 团队之 间的干扰降到最小。
3. 软件和测试工件：需求最终会以软件来实现。

在某种程度上，将需求、团队成员的知识、软件工件映射至同样的 Scrum 团队，可以降低团队之间的依赖。

当使用 Scrum 进行规模化软件交付时，需求、领域知识和软件工件等依赖关系应该驱动软件开发团队 的组成。这样的团队组成能够将生产力最优化。

Nexus 框架

Nexus 是一个过程框架，用于多个 Scrum 团队一起工作创建集成增量。Nexus 与 Scrum 是一致的，对于 使用过 Scrum 的人来说，对于它的部分内容是非常熟悉的。不同之处在于，Nexus 更加关注的是多个 Scrum 团队之间的依赖关系和互动，确保在每个 Sprint 都能至少交付一个“完成”的集成增量。

如图所示，Nexus 包含：

• 角色：新角色—— Nexus 集成团队(Nexus Integration Team)，它的存在是为了协调、教 练(coach)和督导 Nexus 的应用和 Scrum 的运作，以便得到最佳成果(outcomes)。 Nexus 集成团队由产品负责人(Product Owner)、Scrum Master 和 Nexus 集成团队成员组 成。
• 工件(Artifacts):所有 Scrum 团队使用同一份产品待办列表。产品待办列表项经过精炼 并准备就绪后，Sprint 中团队执行工作的指标变得透明化。新工件—— Nexus Sprint 待办列表( Nexus Sprint Backlog)，它的存在是为了提高整个 Sprint 的透明度。所有 Scrum 团队 各自维护他们自己的 Sprint 待办列表。
• 事件：Nexus 事件新增、扩充、或取代常规 Scrum 事件(例如 Sprint 评审)来增强它们。 经过修改后，它们不仅服务于 Nexus 内的所有 Scrum 团队的整体投入，而且还服务于每一 个个体团队(individual team)。

Nexus 过程流

Nexus 由共同致力于至少在每个 Sprint 结束时交付潜在可发布集成增量的多个跨职能(cross-functional) Scrum 团队组成。基于依赖关系，各团队自组织(self-organize)和选择最为合适的团队成员来做特定 工作。

• 精炼产品待办列表(Refine the Product Backlog): 产品待办列表需要分解，以便识别和 解除依赖或使其最小化。产品待办列表项精炼为功能薄片(thinly sliced pieces of functionality)，并且应该识别出可能完成这项工作的团队。
• Nexus Sprint 规划 (Nexus Sprint Planning):来自每个 Scrum 团队的合适代表进行讨论和 评审精炼过的产品待办列表。他们为每个团队选择产品待办列表项。之后，每个 Scrum 团 队规划各自的 Sprint，酌情与其他团队进行互动。其成果是与 Nexus Sprint 目标(Nexus Sprint Goal)对齐的 Sprint 目标集(a set of Sprint Goals)，每个 Scrum 团队的 Sprint 待办列 表和一份惟一 Nexus Sprint 待办列表。Nexus Sprint 待办列表使得每个 Scrum 团队所选的产 品待办列表和任何依赖关系透明化。
• 开发工作:所有团队频繁地将他们的工作集成到共同的环境，并测试，以保证集成是完成的。
• Nexus 每日 Scrum(Nexus Daily Scrum):来自每个开发团队的合适代表每日讨论确定是否 存在集成问题。如果存在集成问题，那么将这一信息透明化传回每个 Scrum 每日例会。之 后，Scrum 团队使用他们自己的 Scrum 每日例会创建当天计划，确保在 Nexus Scrum 每日 例会中提出的集成问题得到处理。
• Nexus Sprint 评审(Nexus Sprint Review):Nexus Sprint 评审在 Sprint 结束时举行，旨在提 供关于 Nexus 在 Sprint 期间构建的集成增量的反馈。所有 Scrum 团队与利益相关者一起评 审集成增量。产品待办列表可能会被调整。
• Nexus Sprint 回顾(Nexus Sprint Retrospective): 来自每个 Scrum 团队的合适代表进行讨 论以识别出共同面临的挑战。接着，每个 Scrum 团队各自举行 Sprint 回顾。然后，来自各 个团队的合适代表再次讨论，任何必要的行动都基于共同的挑战，提供自下而上的智慧。

Nexus

Nexus 的角色、事件和工件继承了相应的 Scrum 角色、事件和工件的目的和意图属性，正如 Scrum 指南所述。

Nexus 角色

一个 Nexus 由一个 Nexus 集成团队和大约 3 至 9 个 Scrum 团队组成。

Nexus 集成团队

Nexus 集成团队的职责是确保在每个 Sprint 至少产生一个“完成”集成增量(整合工作由 Nexus 完成)。 Scrum 团队负责交付一个潜在可发布产品的“完成”增量，正如 Scrum 规定。 Scrum 团队成员的所有 角色在 Scrum 指南中规定。

Nexus 集成团队是 Scrum 团队，它的组成是：

• 产品负责人
• Scrum Master
• 一个或多个 Nexus 集成团队成员

集成团队成员通常也是 Nexus 中的 Scrum 团队的成员。如果是在这种情形下，他们必须以 Nexus 集成 团队的工作优先。Nexus 集成团队的成员身份优先于个体 Scrum 团队的成员身份。这样的优先顺序有 助于确保影响多个团队的问题的工作处于优先位置。

随着时间的推移，Nexus 集成团队的组成可能会发生改变，以反映 Nexus 当前的需要。Nexus 集成团队 的常规活动可能包括教练、咨询和突出对依赖关系和跨团队问题的认知。它也可能会做产品待办列表上的工作。

Scrum 团队解决在 Nexus 中的集成问题。 Nexus 集成团队为 Nexus 提供了一个集成聚焦点。集成包括 解决任何可能阻碍 Nexus 持续交付集成增量能力的跨团队技术或非技术的约束。他们应该利用 Nexus 中各团队自下而上的智慧去解决问题。

Nexus 集成团队中的产品负责人

一个 Nexus 只有一份产品待办列表，正如 Scrum 框架所描述， 一份产品待办列表对应有一个可以最终 确定其内容的一个产品负责人。产品负责人负责产品价值最大化，由 Nexus 中的 Scrum 团队来执行和 集成工作。产品负责人属于 Nexus 集成团队。

产品负责人负责管理产品待办列表以便 Nexus 构建的集成增量产生最大化的价值。如何做到这一点， 可能会因不同组织、不同 Nexus、不同 Scrum 团队和不同的人而有很大的差异。

Nexus 集成团队中 Scrum Master

Nexus 集成团队的 Scrum Master 对确保 Nexus 框架被理解和遵照执行负有全责。Scrum Master 也可以是这个 Nexus 的一个或多个 Scrum 团队中的 Scrum Master。

Nexus 集成团队成员

Nexus 集成团队由熟练使用工具、各种实践和系统工程通用领域的专业人士组成。Nexus 集成团队成员 确保 Nexus 中的 Scrum 团队理解与实现用于检测依赖关系所需的实践和工具，并频繁地将所有工件集 成以满足“完成”定义。Nexus 集成团队成员负责教练和指导 Nexus 中的 Scrum 团队获取、执行和学 习这些实践和工具。

另外，Nexus 集成团队成员也教练 Scrum 团队符合组织的开发、基础设施或架构标准，以确保开发出 高质量的集成增量。

如果满足了他们的主要职责，那么 Nexus 集成团队成员也可以作为开发团队成员在一个或多个 Scrum 团队中承担工作。

Nexus 事件

Nexus 事件持续时间以 Scrum 指南中的相应事件的长度作为指导。除了对应的 Scrum 事件，Nexus 事件也是有时间盒(time-box)限定的事件。

精炼（需求梳理和排期）活动

规模化的产品待办列表精炼(refinement)服务于双重目的。它预估哪个团队将交付哪些产品待办列表项，并且识别跨团队之间的依赖关系。透明化让团队可以监控依赖关系并使其最小化。

以 Nexus 的规模来看，会有许多不同层级的精炼。只有在产品待办列表项足够独立时，它们才能被选择，并在 Nexus 中的 Scrum 团队之间没有过度冲突的情况下工作。

精炼的数量、频度、持续时间和出席者取决于产品待办列表的固有依赖关系和不确定性。产品待办列表通过不同层级的分解，使得其从非常大和模糊的需求分解为能够被一个 Scrum 团队在一个 Sprint 之内可以交付的可操作的工作。

在整个 Sprint 中，精炼是必要和适当的。产品待办列表精炼将在各个 Scrum 团队中继续精炼，以便在 Nexus Sprint 规划事件中，产品待办列表项已经为被选择准备就绪。

Nexus Sprint 规划

Nexus Sprint 规划的目的是协调 Nexus 中所有 Scrum 团队在这个 Sprint 中的活动。产品负责人提供领域知识、选择指南和优先级决策。在 Nexus Sprint 规划之前，产品待办列表应该被充分精炼，识别出依赖关系，解除或最小化。

在 Nexus Sprint 规划之初，来自各个 Scrum 团队的合适代表验证和调整在精炼事件中构建的工作排序。 所有 Scrum 团队成员应该参与其中，以便最小化沟通问题。

在 Nexus Sprint 规划期间，产品负责人讨论制定 Nexus Sprint 目标。Nexus Sprint 目标描述在整个 Sprint 期间由 Scrum 团队想要满足的目的。一旦 Nexus 整体工作被理解，每个 Scrum 团队将执行他们自己特定的 Sprint 规划。Scrum 团队间应该持续共享最新发现的依赖关系。当每一个 Scrum 团队完成他们各自的 Sprint 规划事件时，Nexus Sprint 规划也随之完成。

在 Nexus Sprint 规划期间，新的依赖关系可能会涌现。它们应该被透明化和最小化。跨团队的工作序列也可能需要调整。一个充分精炼产品待办列表将最大限度地减少在 Nexus Sprint 规划时新依赖关系的涌现。所有在这个 Sprint 被选择的产品待办列表项和它们之间的依赖关系要在 Nexus Sprint 待办列表中变得透明。

Nexus Sprint 目标

Nexus Sprint 目标是 Sprint 的目标集。它是所有在 Nexus 内 Scrum 团队的所有工作和 Sprint 目标的总和。 在 Nexus Sprint 评审时，Nexus 应该表明他们开发的“完成”功能达成了 Nexus 目标，以便获得利益相关者的反馈。

Nexus 每日 Scrum 站会

Nexus 每日 Scrum 是一个事件，来自个体 Scrum 团队中的合适代表，检视集成增量的当前状态，识别集成问题或者新发现跨团队依赖关系或跨团队影响。

在 Nexus 每日 Scrum 期间，参与者应该聚焦于每个团队受集成增量的影响，并讨论:

• 前一天的工作是否成功集成？假如没有，那么为什么没有？
• 有什么新的依赖关系或影响已经被识别？
• 在 Nexus 中有什么新的信息需要跨团队共享？

开发团队使用 Nexus 每日 Scrum 检视 Nexus Sprint 目标进展状况。至少每次 Nexus 每日 Scrum 时， Nexus Sprint 待办列表应该被调整，以反映当前对 Nexus 内 Scrum 团队工作的理解。

在 Nexus 每日 Scrum 中识别的工作，将带回给个体 Scrum 团队，作为规划他们自己内部的每日 Scrum 事件。

Nexus Sprint 评审会

Nexus Sprint 评审在 Sprint 结束时举行，旨在提供对于 Nexus 在整个 Sprint 中构建的集成增量的一个反馈，并在需要时调整产品待办列表。

Nexus Sprint 评审替代个体 Scrum 团队 Sprint 评审，因为聚焦于取得利益相关者对整个集成增量的反馈。 在细节上展现所有完成的工作是不太可能的。最大化获得利益相关者反馈的技巧可能是必要的。Nexus Sprint 评审的结果是经过修订的产品待办列表。

Nexus Sprint 回顾会

Nexus Sprint 回顾是一个 Nexus 自我检视和适应(inspect & adapt)的正式机会，并为下一个 Sprint 制定改进计划以确保持续改进。Nexus Sprint 回顾是在 Nexus Sprint 评审之后与下一个 Nexus Sprint 规划之前之间进行的。

它包含三个部分:

1. 第一部分是让来自 Nexus 中各个 Scrum 团队的合适代表进行讨论和识别会造成影响超过一个团队的问题。目的是使问题透明化，共享于所有 Scrum 团队。
2. 第二部分是如同 Scrum 框架所描述，每个 Scrum 团队举行他们各自的 Sprint 回顾。他们可以使用 Nexus 第一部分回顾产生的问题作为他们讨论内容的输入。在个体 Scrum 团队回顾中应该形成行动处理这些问题。
3. 最后，第三部分是一个机会，从来自各个 Scrum 团队的合适代表再次进行讨论，商定如何可视化和跟踪这些识别出来的行动项。这意味着允许 Nexus 作为一个整体进行调整。

因为它们都是常见的规模化功能障碍，每次回顾应该处理以下主题：

• 是否留下任何未完成的工作？Nexus 是否产生技术债务？
• 是否所有工件，特别是代码，都能频繁（如，每天）成功集成？
• 软件是否成功地构建、测试和部署，频度足以防止未解决依赖关系压倒性的累积？

对于上述的问题，如有必要，讨论以下问题：

• 为什么会发生？
• 技术债务如何消除？
• 如何防止问题再次发生？

Nexus 工件

如 Scrum 指南所描述，工件代表工作成果或价值，提供透明化，为检视和适应(inspection & adaptation)提供机会。

产品待办列表

整个 Nexus 和它的所有 Scrum 团队只有惟一一份产品待办列表。产品负责人对这份产品待办列表负责， 包括它的内容、可用性和有序性。

在规模化的情境下，产品待办列表必须在依赖被检测和最小化的层级水平上进行理解。为了支持解决方案，产品待办列表经常被分解为被称之为“薄切片”功能的粒度。在 Nexus Sprint 规划会议上，当 产品待办列表项可被选择以便 Scrum 团队完成，并且没有跨团队依赖性或已降低到最低时，产品待办列表项被视为“准备就绪”。

Nexus Sprint 待办列表

Nexus Sprint 待办列表由源自各个个体 Scrum 团队的 Sprint 待办列表的所有产品待办列表项组成。 它用于突出 Sprint 期间的依赖关系和工作流。它至少每天更新，通常作为 Nexus 每日 Scrum 的一部分。

集成增量

集成增量代表由 Nexus 完成的所有已集成工作的总和。集成增量必须可以使用和潜在可发布，也就是意味着它必须满足“完成”定义。在 Nexus Sprint 评审时，检视集成增量。

工件的透明化

就像它的基石—— Scrum 一样，Nexus 是基于透明化的。在 Nexus 中，Nexus 集成团队与 Scrum 团队协同工作，确保所有工件提供足够透明度给团队，集成增量的集成状态被广泛地理解。

基于 Nexus 工件状态所做决策，其效果与工件透明化水平一致。不完整或部分信息将导致不正确或有缺陷的决策。这些决策的影响能够在 Nexus 规模上放大。软件开发必须在技术债务对 Nexus 而言变得不可接受之前检测并解决依赖关系。缺乏完整的透明度将使它不可能有效指导 Nexus，使其最小化风险和最大化价值。

“完成”的定义（DoD）

Nexus 集成团队负责“完成”的定义（Definition of Done），应用于每个 Sprint 的集成增量开发之中。Nexus 的所有 Scrum 团 队坚守“完成”的定义。只有当产品负责人认为增量可用并且满足潜在可发布时，增量才被认为“完成”。

个体 Scrum 团队可以选择更为严格的“完成”定义，应用于他们自己的团队中。但不能使用严格程度 逊于增量约定的标准。

结束语

Nexus 是免费的，由本指南提供。与 Scrum 框架一样，Nexus 的角色、工件、事件和规则是不可变的。虽然仅仅实施部分的 Nexus 是可能 的，但其结果就不是 Nexus 了。

致谢

Nexus 和 Scaled Professional Scrum 由 Ken Schwaber、 David Dame、 Richard Hundhausen、 Patricia Kong、 Rob Maher、 Steve Porter、 Christina Schwaber 和 Gunther Verheyen 共同合作开发。

翻译

修订者：Jacky Shen (CST, CTC，优普丰认证敏捷教练)

译者：周建成 (Agile Coach), 本中文指南（2018年1月版）从 ken Schwaber 的英文原版翻译而来，https://scrumorg-website-prod.s3.amazonaws.com/drupal/2018-01/2018-Nexus-Guide-Chinese-Simplified.pdf

]]> https://www.uperform.cn/less-agile-less-huge-large-scale-scrum-framework/ Thu, 15 Sep 2016 02:18:56 +0000 http://www.uperform.cn/?p=959 […]]]> LeSS规则是LeSS框架的定义，分为LeSS和巨型LeSS两种规模。这些是我们认为导入LeSS必须做到的事情。

LeSS Framework Rules

The LeSS framework applies to products with 2-“8” teams.

LeSS Structure

• Structure the organization using real teams as the basic organizational building block.
• Each team is (1) self-managing, (2) cross-functional, (3) co-located, and (4) long-lived.
• The majority of the teams are customer-focused feature teams.
• Scrum Masters are responsible for a well-working LeSS adoption. Their focus is towards the Teams, Product Owner, organization, and development practices. A Scrum Master does not focus on just one team but on the overall organizational system.
• A Scrum Master is a dedicated full-time role.
• One Scrum Master can serve 1-3 teams.
• In LeSS, managers are optional, but if managers do exist their role is likely to change. Their focus shifts from managing the day-to-day product work to improving the value-delivering capability of the product development system.
• Managers’ role is to improve the product development system by practicing Go See, encouraging Stop & Fix, and “experiments over conformance”.
• For the product group, establish the complete LeSS structure “at the start”; this is vital for a LeSS adoption.
• For the larger organization beyond the product group, adopt LeSS evolutionarily using Go and See to create an organization where experimentation and improvement is the norm.

LeSS Product

• There is one Product Owner and one Product Backlog for the complete shippable product.
• The Product Owner shouldn’t work alone on Product Backlog refinement; he is supported by the multiple Teams working directly with customers/users and other stakeholders.
• All prioritization goes through the Product Owner, but clarification is as much as possible directly between the Teams and customer/users and other stakeholders.
• The definition of product should be as broad and end-user/customer centric as is practical. Over time, the definition of product might expand. Broader definitions are preferred.
• One Definition of Done for the whole product common for all teams.
• Each team can have their own stronger Definition of Done by expanding the common one.
• The perfection goal is to improve the Definition of Done so that it results in a shippable product each Sprint (or even more frequently).

LeSS Sprint

• There is one product-level Sprint, not a different Sprint for each Team. Each Team starts and ends the Sprint at the same time. Each Sprint results in an integrated whole product.
• Sprint Planning consists of two parts: Sprint Planning One is common for all teams while Sprint Planning Two is usually done separately for each team. Do multi-team Sprint Planning Two in a shared space for closely related items.
• Sprint Planning One is attended by the Product Owner and Teams or Team representatives. They together tentatively select the items that each team will work on that Sprint. The Teams identify opportunities to work together and final questions are clarified.
• Each Team has their own Sprint Backlog.
• Sprint Planning Two is for Teams to decide how they will do the selected items. This usually involves design and the creation of their Sprint Backlogs.
• Each Team has their own Daily Scrum.
• Cross-team coordination is decided by the teams. Prefer decentralized and informal coordination over centralized coordination. Emphasize Just Talk and informal networks via communicate in code, cross-team meetings, component mentors, travelers, scouts, and open spaces.
• Product Backlog Refinement (PBR) is done per team for the items they are likely going to do in the future. Do multi-team and/or overall PBR to increase shared understanding and exploiting coordination opportunities when having closely related items or a need for broader input/learning
• There is one product Sprint Review; it is common for all teams. Ensure that suitable stakeholders join to contribute the information needed for effective inspection and adaptation.
• Each Team has their own Sprint Retrospective.
• An Overall Retrospective is held after the Team Retrospectives to discuss cross-team and system-wide issues, and create improvement experiments. This is attended by Product Owner, Scrum Masters, Team representatives, and managers (if any).

LeSS Huge Framework Rules

LeSS Huge applies to products with “8+” teams. Avoid applying LeSS Huge for smaller product groups as it will result in more overhead and local optimizations.

All LeSS rules apply to LeSS Huge, unless otherwise stated. Each Requirement Area acts like the basic LeSS framework.

LeSS Huge Structure

• Customer requirements that are strongly related from a customer perspective are grouped in Requirement Areas.
• Each Team specializes in one Requirement Area. Teams stay in one area for a long time. When there is more value in other areas, teams might change Requirement Area
• Each Requirement Area has one Area Product Owner.
• Each Requirement Area has between “4-8” teams. Avoid violating this range.
• LeSS Huge adoptions, including the structural changes, are done with an evolutionary incremental approach.
• Remember each day: LeSS Huge adoptions take months or years, infinite patience, and sense of humor.

LeSS Huge Product

• Each Requirement Area has one Area Product Owner.
• One (overall) Product Owner is responsible for product-wide prioritization and deciding which teams work in which Area. He works closely with Area Product Owners.
• Area Product Owners act as Product Owners towards their teams.
• There is one Product Backlog; every item in it belongs to exactly one Requirement Area.
• There is one Area Product Backlog per Requirement Area. This backlog is conceptually a more granular view onto the one Product Backlog.

LeSS Huge Sprint

• There is one product-level Sprint, not a different Sprint for each Requirement Area. It ends in one integrated whole product.
• The Product Owner and Area Product Owners synchronize frequently. Before Sprint Planning they ensure the Teams work on the most valuable items. After the Sprint Review, they further enable product-level adaptations.

版权所有© 2006-2018 Jeff Sutherland 及 Scrum Inc.

Scrum@Scale是Scrum Inc.的注册商标。本指南基于署名-相同方式共享许可协议4.0发布。(CC BY-SA 4.0)

简体中文版原创翻译团队：申健 Jacky Shen (CST, CTC, Agile Coach); 王洪亮 Stephen Wang (CSP, Agile Coach); 李国彪 Bill Li (CST, Agile Coach);

简体中文版官方授权译文链接：http://www.uperform.cn/scrum-at-scale-guide-chinese/，欢迎转载，请保留所有版权信息并遵循共享许可协议进行演绎。

Scrum@Scale指南之目的

最初在Scrum指南中描述的Scrum，是单个团队进行开发、交付和持续发展复杂产品的框架。自诞生以来，它已经扩展到需要多个团队合作来创建产品、处理过程、服务和系统。创建Scrum@Scale是为了有效地整合这种新型的团队生态系统，从而优化组织的整体策略。为了实现这个目标，它利用一个自由扩展的架构建立起一个“最小可行的官僚机构”，自然地将单个Scrum团队的功能扩展到整个组织中。

本指南包括构成Scrum@Scale框架的组件定义，包括扩展的角色、扩展的事件、企业级工件，以及将它们组织在一起的各种规则。

Jeff Sutherland博士基于Scrum、复杂自适应系统理论、博弈论、面向对象技术等背后的基础原则开发了Scrum@Scale。本指南采纳了许多有经验的Scrum实践者的输入，基于他们的现场工作成果。本指南之目标是读者能够自行实施Scrum@Scale。

为什么要Scrum@Scale?

Scrum是为单个团队而设计，使其能够在可持续的速率下发挥最佳生产力。在该领域中，人们发现随着组织内的Scrum团队数量增长，最佳输出（可工作的产品）及那些团队的速率会开始下降（比如由于跨团队依赖和重复劳动等问题）。很明显，为了获得线性的可扩展性，人们需要一个有效整合那些团队的框架。设计Scrum@Scale是为了利用自由扩展的架构达成这个目标。

通过使用无标度架构，组织的增长并不受限于以一组武断规则所决定的特定方式；相反，它可以有机地基于自己的独特需求而增长，并维持可持续的变革速度，从而可以被组织的成员们接受。

Scrum@Scale是为组织的整体扩展而设计：所有部门、产品和服务。它可以被运用到不同领域，包括工商业、政府或学术界中的各类组织。

Scrum@Scale的定义

Scrum（名词）：Scrum是一个框架，在此框架中，人们可以解决复杂自适应问题，同时高效并创造性地交付最大价值的产品。

Scrum指南是最小功能的集合，它通过彻底的透明性促进检视和适应性，从而驱动创新、绩效和团队幸福感。

Scrum@Scale（名词）：Scrum@Scale是一个框架，在此框架中，一致采用Scrum指南进行运作的Scrum团队网络可以解决复杂自适应问题，同时高效并创造性地交付最大价值的产品。

注意： 这些“产品”可以是硬件、软件、复杂的集成系统、处理过程、服务等，取决于Scrum团队所处的领域。

Scrum@Scale是: * 轻量的 – 最小可行的官僚机构 * 易于理解的 – 仅仅包含Scrum团队们 * 难以精通的 – 需要实施一个全新的运作模型

Scrum@Scale是一个对Scrum进行扩展的框架。通过使用Scrum来扩展Scrum，它彻底简化了规模扩展。它仅仅包含一些Scrum团队，这些团队通过Scrum of Scrums和MetaScrums进行整合。

Scrum@Scale本身基于组件的性质允许组织定制他们的转型策略和实现方式。它使得他们获得一种能力，可以将转型的努力聚焦在他们认为最有价值或最需要改变的领域内，然后再向其他方面取得进展。

在Scrum中，要注意区分对“What”与“How”的问责。在Scrum@Scale中也是一样，那么就要明确地理解权限和职责，从而消除浪费性的组织冲突，令团队更容易达致最佳生产力。

为了区分这两个权限，Scrum@Scale包含两个循环：Scrum Master循环（“How”）和产品负责人循环（“What”），彼此具有两个相互接触点。总之，这些循环造就了一个强大的框架，整合多个团队朝着同一个方向而努力。

Scrum@Scale框架的组件

价值观驱动的文化

除了区分对“What”与“How”的问责，Scrum@Scale还进一步在实证背景下创造价值驱动的文化，旨在建立健康的组织。Scrum的价值观包括：开放、勇气、专注、尊重和承诺。这些价值观驱动着实验性决策，而其取决于透明、检视和调整这三大支柱。

开放支持着所有工作和过程的透明性，没有这种透明度，就无法诚实地检视并试图更好地调整它们。勇气指的是大胆跳跃，这是以创新方式更快地交付价值所需要的。

专注和承诺是我们处理工作职责的方式，把交付客户价值作为最高优先级。最后，所有这一切都必须发生在一个尊重每个人的工作环境中，否则不可能创造任何东西。

Scrum@Scale支持仆人式领导风格和基于意图的领导力模型，以帮助组织蓬勃发展，¹培养一个以可持续速率进行工作的积极环境，致力于将面向客户价值放在努力的第一位。

开始使用Scrum@Scale

在实施大型团队网络时，针对少量团队开发出一个可扩展的参考模型是至关重要的。当部署多个团队时，Scrum实施中的任何缺陷都会被放大。

因此，第一个挑战就是建立少量良好实施Scrum的团队。这组团队克服了那些阻碍敏捷性的组织问题，并为Scrum创建一个在组织中众所周知可运行的参考模型，将其用作整个组织范围内扩展Scrum的模式。

随着团队参考模型的加速，延迟交付、产生浪费或妨碍业务敏捷性的障碍及瓶颈会变得明显。消除这些问题的最有效方法是在整个组织中传播Scrum，以便优化整个价值流。

Scrum@Scale通过使组织浸泡在Scrum中，并有机地分配速度和质量，从而实现了生产力的线性扩展，与组织的特定策略、产品和服务保持一致。

Scrum Master循环

团队级过程

在Scrum指南中明确阐述了团队级过程。它由三个工件、五个事件和三个角色组成。团队级过程旨在：

• 最大限度地使完成和通过质量验证的工作流动起来。
• 每个Sprint都提高一点点速率。
• 以一种可持续和丰富的方式运作。

整合如何做事(“How”) – Scrum of Scrums

需要协作的多个团队组成一个“Scrum of Scrums”（SoS） 。SoS是“团队之团队”²，每天举行一个规模化每日例会（SDS）事件，每个团队派代表参加（通常是团队的Scrum Master，尽管任何人都可以参加，也可以派多个人参加）。SDS的存在是为了协调团队并移除障碍以交付价值。

SDS事件反映了每日Scrum例会，优化了团队网络的协作和绩效。另外，SDS：

• 少于15分钟的时间盒。
• 每个团队必须派代表参加。
• 是一个团队代表们解决3个简单问题的论坛：
  • 我的团队有什么障碍阻止了他们完成他们的Sprint目标（或影响即将发布的版本）？
  • 我的团队是否在做任何事情阻止了其他团队完成他们的Sprint目标（或影响他们即将发布的版本）？
  • 我们发现了团队之间的任何新的依赖关系吗，或者找到了解决现有依赖关系的方法吗？

这一组Scrum Master们本身就是一个Scrum团队，负责在每个Sprint末尾从所有参与团队那里完全地集成出一个潜在可交付的产品增量。SoS团队需要实时地应对所有参与团队所提出的障碍。

SoS充当一个发布团队，必须能够直接地向客户交付价值。为了能有效地做到这一点，它需要与Scrum指南保持一致；也就是说，要有自己的角色，工件和事件。这包括一个待办清单梳理事件，他们在其中决定哪些障碍已经“准备好”被移除，最佳移除障碍的方式是怎样的，团队如何才能知道它是“完成”的。要特别关注SoS回顾事件，团队代表们在其中分享各自团队中的任何成功的学习收获或流程改进，以便在SoS中的各个团队能够将这些实践标准化下来。

为了在每个Sprint结束时交付一个完全集成的潜在可交付产品，它需要具备所需的所有技能。它具有产品负责人代表来解决优先级问题。它可能需要经验丰富的架构师，QA负责人和其他操作技能组。当启动Scrum@Scale时，团队们可能还不具备能够支持持续部署的基础架构。这会迫使SoS建立一个“集成团队”或“发布团队”，以完成克服工程缺陷所需的额外工作。SoS被鼓励去激进地解决集成和部署的障碍，因为它创造了一个超高生产力的环境，例如，亚马逊有3300个Scrum团队，平均每秒部署超过一次³。

Scrum of Scrums Master (SoSM)

SoSM负责联合团队的发布，并且必须：

• 使组织可以看到障碍待办清单。
• 移除团队自己无法解决的障碍。
• 对障碍进行排序，特别要关注跨团队依赖和产品待办清单的分配。
• 提升Scrum of Scrums的效果。
• 与产品负责人们密切合作，每个Sprint部署至少一个潜在可交付的产品增量。
• 利用产品负责人的发布计划来整合多团队的部署工作。

扩展SoS

根据组织或实施的规模，可能需要多个SoS来交付非常复杂的产品。在那些情况下，可以从多个Scrum的Scrum中创建一个Scrum of Scrum of Scrums（SoSoS)。 SoSoS是Scrum团队的一个有机模式，可以无限扩展。每个SoSoS都应该有SoSoSM角色们，以及每个工件和事件的扩展版本。

扩展SoS减少了组织内部的沟通路径数量，因此复杂性被封装了起来。SoSoS与SoS的接口、SoS与单个Scrum团队的接口，两者都采用了相同的方式，从而实现线性可扩展性。

示例图：

注意： 尽管Scrum指南将最优团队规模定义为3到9人，但哈佛大学的研究认为最优团队规模为4.6人。⁴ 针对高绩效Scrum团队的研究一再表明4或5人在一起工作是最优人数。对于SoS中的团队数量，这种模式带来的线性可扩展性是至关重要的。因此，在上图和下图中，选择了五边形来表示一个5人团队。这些图仅仅是示例，您的组织图表可能会有很大差异。

高管行动小组

针对整个敏捷组织的Scrum of Scrums被称为高管行动小组（EAT）。EAT是SoS不能移除的那些障碍的终点站。所以，它必须由在政治和财务上得到充分授权的人们组成，去移除那些障碍。EAT的职能是协调多个SoS（或者SoSoS）。和任何Scrum团队一样，它也需要具备一个PO和SM。EAT最好也像Scrum团队一样可以每天见面。每个Sprint他们必须至少见一次面，并且具备一个透明的待办清单。

例图展示了1个EAT，正在协调分布在5个群组中的25个团队

EAT的待办清单及责任

Scrum是一个区别于传统项目管理的敏捷操作系统。整个SM组织汇报给EAT，后者负责在组织内建立、维护和提升其打造的敏捷操作系统。EAT的角色是创建组织转型待办清单（一份经过排序的列表，包含待完成的敏捷举措）并确保落地执行。例如，如果在一个旧组织中存在一个传统的产品开发生命周期，那么一个新的敏捷产品开发生命周期需要被创建、实现和支持。通常它会比旧方法的更好地支持质量和合规事项，但是需要采纳一套不同的规则和指南来实施。另外，组织发展和治理的很多方面也需要调优。

EAT对于整个组织的Scrum质量负责。它的职责包括但不仅于：

• 为参考模型创建敏捷操作系统，以扩展到整个组织，包括提升敏捷性的企业运营规则，过程和指南。
• 度量和改进组织内的Scrum质量
• 构建组织内业务敏捷的能力
• 创建一个针对Scrum专业人士的持续学习中心
• 支持去探索新型工作方法

最后，EAT必须比照SoS，聚集PO群体来建立和支持相应的的产品负责人组织，从而扩展PO职能。这些PO和关键干系人的团队被称为MetaScrum。

Scrum Master组织的输出/效果

SM组织（SoS、SoSoS和EAT）作为一个整体来完成Scrum Master循环的组件：持续改进和移除障碍，跨团队协调，和部署

持续改进和移除障碍的目标是：

• 识别障碍并转化为机遇。
• 维护一个安全的和结构化的环境以排序和移除障碍，并验证和落实改进。
• 确保组织内的可见性以促成变革。

跨团队协调的目标是：

• 协调多个关联团队间的相似流程。
• 管理跨团队依赖以确保它们不会变成障碍。
• 使团队规范和指南的保持对齐，以确保持续的输出。

SoS的目标是像个发布团队一样工作，因此产品部署也是其分内事，而决定发布内容则是PO的分内事。因此，部署的目标是：

• 持续流动式地向客户交付有价值的完成产品。
• 将不同团队的工作集成到一个无缝的产品。
• 确保用户体验的高质量。

产品负责人循环

整合做什么事(“What”) – MetaScrum

如果一组产品负责人有必要整合一个唯一的待办清单，以供Scrum of Scrums来工作，那么他们自己就形成一个团队称为MetaScrum。每个SoS都有一个对应的MetaScrum。MetaScrum沿着同一路径来对齐多个团队的优先级，这样他们就可以整合多个待办清单，并和干系人保持一致以得到他们对待办清单的支持。MetaScrum举行一种规模化的待办清单梳理活动。

• 每个产品负责人（或其代理）都必须参加
• 这个事件是领导者、干系人或其他客户表达各自倾向的论坛

这个事件按需发生，每个Sprint至少发生一次，以确保一个“就绪”的待办清单。MetaScrum的主要职能是：

• 创建产品的主要愿景并且使之对整个组织可见。
• 和干系人保持一致以确保他们支持产品待办清单的实现。
• 创建唯一的排序的待办清单；确保规避了重复工作。
• 针对SoS内所有团队创建统一的“完成的定义”。
• 消除由SoS提出的依赖。
• 生成一份整合的发布计划。
• 监控能够洞察产品的度量，并基于其进行决策。

类似于SoS，多个MetaScrum本身也作为Scrum团队来运作。所以，需要某人来扮演SM来保持团队的正常沟通。他们还需要唯一的人来负责协调，使得MetaScrum覆盖的所有团队创建出唯一的产品待办清单。这个人被指定为产品总负责人。

产品总负责人(CPO)

通过MetaScrum，产品总负责人与各个团队的产品负责人来协调优先级。他们以干系人以及顾客需求来对齐待办事项的优先级。类似于SoSM，可以是某个团队的PO来扮演这个角色，或者是某个人全职担任这个角色。他们的主要职责和普通PO是一样的，但是在扩展的时候：

• 建立整个产品的战略愿景
• 创建唯一的、排序的待办清单，包含将要被所有团队交付的价值。
• 这些事项对于一个团队的PO来说可以是更大规模的故事。
• 与相应的SoSM紧密工作在一起，以便有效地部署MetaScrum团队创建的发布计划。
• 监控客户对产品的反馈并相应地调整待办清单。

扩展MetaScrum

如同SoS可以增长到SoSoS，MetaScrum也可以用同样的机制进行扩展。没有专门的术语对应这些扩展单元，他们的CPO们也没有专门的扩展头衔。我们鼓励每个组织发展自己的方式。下图中，我们选择了再增加一个“总”以突出那些PO。

一些例图：

注意： 如上所述，这些多边形代表着理想规模的Scrum团队和MetaScrum。这些图仅仅作为例子，你的组织图可能会显著不同。

高管MetaScrum（EMS）

MetaScrum使得PO及其对应的SoS能够以一种网状设计进行无限地扩展。整个敏捷组织的MetaScrum是高管MetaScrum。EMS拥有组织的愿景并设立整个公司的战略优先级，使各个团队围绕共同目标来对齐。

例图展示了1个EMS，正在协调分为5个组的25个团队：

产品负责人组织的输出/效果

PO组织(各种MetaScrum，CPO和高管MetaScrum)作为整体来工作以满足产品负责人循环的组件：战略愿景、待办清单优先级排序、待办清单分解和梳理，以及发布计划

设置战略愿景的目标是：

• 透过一个共享的路径清晰地对齐整个组织。
• 清晰而有力地表述组织为什么存在。
• 描述组织会做什么从而调度其关键资产以支持其使命。
• 持续更新以响应快速变化的市场情况。

待办清单优先级排序的目标是：

• 针对待交付的产品、功能和服务，识别出一个清晰的排序。
• 待办清单的排序反映了价值创造、风险缓解和内部依赖。
• 在分解和梳理待办清单之前，先在整个敏捷组织内对高层举措进行排序。

待办清单分解和梳理的目标是：

• 把复杂项目和产品分解为独立的可工作元素，每个元素都可以被一个团队在一个Sprint中完成。
• 捕获和提炼涌现的需求和客户反馈。
• 确保所有的待办事项条目是真的“准备就绪”以便被各个团队拉取。

发布计划的目标是：

• 预报关键特性和能力的交付
• 向干系人沟通交付预期
• 按需更新优先级排序

连接SM与PO循环

理解反馈

反馈组件是PO和SM循环所交叉的第二个点。产品反馈通过调整产品待办清单来驱动持续改进，发布反馈通过调整部署机制来驱动持续改进。获取和分析反馈的目标是：

• 验证我们的假设。
• 理解顾客如何使用产品和与产品互动。
• 捕获新特性和新功能的创意。
• 定义针对已有功能的改进。
• 朝着产品/项目完成的方向更新进度，以更好地规划发布计划并与干系人对齐。
• 识别出部署方法和机制的改进项。

度量与透明性

彻底的透明性是Scrum最佳状态运作的本质，但是只在能够拥抱Scrum价值观的组织中可行。它使组织能够诚实地评估进度并检视和调整其产品及过程。这是Scrum指南中记载的Scrum的实证主义本性的基石。

SM和PO循环各自需要的度量会分别由SM和PO组织来决策。对于两个特定组织以及那些组织中的特定功能来说，度量也可能是唯一的。Scrum@Scale并不要求任何特定的度量集，但是它推荐了最低配置，即组织应该度量如下方面:

• 生产力 —— 例如，每个Sprint交付的可工作产品的总量变化
• 价值交付 —— 例如，单位团队工作量能够带来的业务价值
• 质量 —— 例如，缺陷率或者服务宕机时间
• 可持续性 —— 例如，团队满意度

设置这些度量指标以及透明性是为了：

• 提供适当的上下文给所有的决策者——包括团队成员在内——以做出优秀的决策。
• 尽量缩短反馈周期以避免矫枉过正。
• 最小化地要求团队、干系人和领导者进行额外投入。

关于组织设计的一些说明

Scrum@Scale自由扩展的本性，允许将组织设计为一个个组件，就像框架本身一样。它允许重新平衡和重构团队，从而响应市场。随着组织的增长，分布式团队带来的益处可能也很重要。一些组织在无法获取人才的时候则通过外包开发来扩展和签约。Scrum@Scale展示了如何扩展这种情况，同时避免过长的延迟时间、妥协的沟通以及低劣的质量，使得组织在规模上和地理分布上兼具线性扩展性。⁵

在这个组织图中，知识和基础设施团队表示一些虚拟的专业团队，这些专家的数量太少，难以保证在每个团队中都配备。他们作为一个组与多个Scrum团队进行整合，遵照服务水平协议，每个专业方面请求都流经同一个PO，他将那些请求转换为透明的已排序的待办清单。值得注意的是，这些团队并不是坐在一起的一群各自为政的个体(这是为什么他们被标记为中空多边形)；这些团队成员都坐在实际的Scrum团队当中，但是他们组成这个虚拟Scrum是为了传播待办清单和过程改进。

客户关系，法务/合规、人力运营也包含在这里，因为他们是组织中必要的部分，他们将独立于Scrum团队而存在，其他人将依赖于他们。

关于EAT和EMS的最后一点：在这个图中，由于有2个成员同时存在于这两个团队中，所以两者看起来是重叠了。在非常小的组织或者实施中，EAT和EMS可以由同一批人组成。

结束语

Scrum@Scale是为了扩展生产力而设计的，使得整个组织在一个显著改善的工作环境中能够高质量地做到事半功倍。在大型组织中适当的应用本框架可以削减产品和服务的成本，并且提升质量和创新。

Scrum@Scale是为了让Scrum浸透组织而设计的。所有团队，包括了领导层、人力资源、法务、咨询和培训，以及产品和服务团队，他们在精简和提升组织的时候都采用同一种Scrum风格。

良好实施的Scrum可以运作起整个组织。

致谢

我们感谢IDX创建了Scrum of Scrums，它允许Scrum扩展到上百个团队，⁶感谢PatientKeeper创建了MetaScrum，⁷它使得创新产品能快速部署，感谢OpenView Venture Partners将Scrum扩展到整个组织。⁸ 我们珍视来自英特尔的二万五千多人实施Scrum的输入，教会了我们——“没有事物能扩展”——除了一个自由扩展的架构，还要感谢具有最大的Scrum团队的SAP产品组织，教会了我们让2000多个Scrum团队一起工作的必要因素就是让管理层参与到MetaScrum中。

敏捷教练和培训师们与Jeff Sutherland一起工作，在亚马逊、GE、3M、丰田、Spotify和很多其他公司实施了这些概念，这对于在更广范围的不同领域的公司中验证这些概念是非常有帮助的。

最后，Avi Schneier和Alex Sutherland制定和编辑本文的工作是价值无量的。