引子

精益思维是一种行之有效的系统，可以扩展到大型开发，丰田和其他公司已经证明了这一点。尽管最常用于产品，但它也用于服务领域-在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

1. 背景

这个报告描述的是发生在2015-2016年期间华为杭州的两个产品开发部门的经历。我的工作是作为一个咨询师帮助他们的大规模敏捷导入。公司规模巨大，在产品开发上就有几万人。他们组织成业务线和开发部门，每个通常都有几百到几千人。之前也尝试过敏捷导入，只是多少有些偏差，比如他们实现的“迭代”事实上更象小瀑布，经常把测试和缺陷遗留到下个迭代；而“持续集成”更多只是每日构建和测试自动化，而非开发人员真正持续地集成他们的代码。

在2015年中期当我受雇作为外部咨询师来帮助他们的大规模敏捷导入时，我的内部联系人陈光镜脑海里有一些候选的开发部门，但是并没有任何一个已经决定采用LeSS或者类似LeSS的方式。因此，我们做了一系列LeSS培训来提升大家的认识并对LeSS意味着什么建立合适的理解，更多细节在稍后描述。

大家从培训中意识到LeSS带来的变化要比他们预想的更大，这并不让人吃惊。事实上，在最初的工作坊后没有一个部门立刻表达想尝试的意愿。这是问题吗？根本不是！我们更感兴趣的是少数部门能够基于正确的理解和刻意的选择迈出真正有效变革的步伐，而不是大量部门玩着“变革游戏”。事实上，我们最不想要的是又一次假的变革，因为那样并不会带来任何有意义的好处。很多部门从未迈出下一步。

然而，还是有两个部门决定向前推进，他们成了这份报告中的两个案例。

1.1 为什么组织先行？

很不幸，在项目上试点Scrum的做法很普遍，因为一个项目团队天生是跨职能和端到端的。为什么这样的做法经常会注定失败？项目组织中遍布的是传统的矩阵结构，项目团队并不是一个真正的团队，而只是一组人，他们各自关注自己的诸如前端开发和测试之类的专业领域。尽管在“项目管理理论”上，即使没有进行有意义的组织结构变革，也是可能让“项目团队”里的每个人都对齐共同目标并承担共享责任的，但是这种对齐至少是脆弱的，就我的经验而言，很少能真正实现。

为什么会这样？

• 项目团队成员的部分分配导致了多任务。这不仅降低了个体效率，而且带来了下一个问题。。。
• 项目团队成员不交叉学习其它专业，因为他们被充分使用以获得“局部的高效”。这减少了学习，从而降低了作为一个团队的适应能力，这在下一个问题中就有所反映。。。
• 项目团队成员没有蜂聚来把条目完成。“团队”只是名义上的，他们其实只是一组个体而已，并不能一起工作来达到共同目标。这带来了下一个问题。。。
• 项目团队成员不能形成自管理团队。因为在实践中他们没法“同时同地”地工作于共同目标，需要其他人管理他们来达到目标，这便是传统项目经理的角色。而项目经理的存在又加重了团队自管理的缺失。

考虑到团队会面临其它诸如协作能力不足和工程能力弱之类的挑战，由组织结构引起的缺乏动力会让成功变得更遥不可及。在我的经验中，很多团队在一段时间后都步履蹒跚。一些组织通过改变组织结构得以继续向前，而另一些则回退到过去。

这一问题在Richard Hackman的工作中有很好的表达。图1来自他的经典书籍《Leading Teams》，其中展示的团队绩效、团队设计和辅导之间的关系极具洞察。团队设计和辅导都对团队绩效有影响，但相比之下团队设计起到更大的作用。

在Scrum中，ScrumMaster（SM）负责提供有效的辅导。但在我的经验中，大多数组织里最初的SM们还只是刚开始学习如何辅导，而许多暴露出来的障碍的根源都会和组织结构有关。由此带来的辅导复杂度对他们来说有些过于强大。除此之外，当开始导入时，辅导这一概念对我的客户而言是陌生的，他们很难想象一个没有指定管理者的自组织团队。如果我们在现有的结构（没有组织重新设计）下试点Scrum，让经验欠缺的SM去尝试辅导团队通往自组织，成功的几率将会很低。

因此，我们采用了不同的方式：1）首先专注建立合适的结构；2）然后再增加辅导的能力。

另一个首先专注于组织结构的原因是因为这个特定的咨询任务 – 我被期望能帮助到他们获得在大规模敏捷导入中应用LeSS的经验和好处。深入的组织重新设计是成功导入LeSS的必要条件。事实上，因为其重要性，它被突显作为一条导入相关的LeSS规则：“对产品组从一开始就建立完整的LeSS结构，这对LeSS导入至关重要”。

大多数组织试图避免组织结构变革，因为他们觉得这有些冒险。当它同时涉及成百上千人时，风险是客观存在的。但是到目前LeSS导入已经积累了很多经验，我们现在对这些风险具备很好的理解。基于此，成功导入LeSS的另一条原则是“狭窄但深入胜于宽泛但表面”。这意味着在“较小的”大规模场景，也就是50人左右或更少，我们从一开始就建立完整的LeSS结构。相反，在很大的大规模场景，也就是LeSS巨型的范畴，导入过程中的结构变革则采用演进增量的方式。

1.2 组织的约束

导入LeSS最初的关键决策之一是定义什么是我们的产品。在华为，几乎所有的产品开发都被分散到多个部门进行，而且那些部门都是组织实体，如图2所示。

有各种产品开发部门存在。“产品”的开发部门负责面向终端客户的真正产品，但它通常依赖于诸如平台或网管之类的其它部门。平台被进一步拆分成应用平台和基础平台，而对应的部门也做同样的拆分。复杂产品构建在应用平台和基础平台之上；而简单产品则只是构建在基础平台上。

举个例子，基站是面向电信运营商（比如中国移动）的一个真正的产品，它就构建在平台之上，并依赖于网管。这样一来至少涉及三个产品开发部门来交付完整的解决方案：基站（“产品”开发部门），平台（至少一个“平台”开发部门）和网管（另一个“产品”开发部门）。这只是一个简化视角，真实的情况是通常会涉及多个平台。

作为一条LeSS规则，“产品的定义应该是在实际的前提下尽量广并且以终端用户/客户为导向”。从把产品定义扩展得尽可能广来说，它应该包含整个栈。然而，因为和我们工作的是部门的管理层，他们只能在自己的范围内做结构变革，我们初始的产品定义也就受限于部门的范围。这与LeSS指南“定义你的产品”中的建议一致，一个常见的把产品定义缩小的约束力来自于现有的结构。如图3所示，“产品”开发部门的可能演进路径是扩大到至少包含“应用平台”开发部门；而“基础平台”开发部门可能演进成真正的通用平台产品，但是我们必须理解这意味着进入一个完全不同的市场，与完全不同的客户打交道。

我们工作的两个产品开发部门代表了两种不同类型：一个是基础平台，而另一个是产品。尽管这里的产品确实使用了这里的基础平台（是它使用的若干个平台之一），但是它基本就是拿现成的基础平台来用，而非要求平台做很多改动以支持产品。因此，虽然理想的产品定义扩展可以包含这两个“产品”，我们还是把它们作为独立的案例来对待。它们也代表了不同的规模，一个大约40人，而另一个大约120人，正好分别提供了LeSS和LeSS巨型的情况。我们在2015年晚些时候开始了LeSS的案例（基础平台部门），然后在2016年开始了LeSS巨型的案例（产品部门）。有一段时间我同时跟这两个部门工作。

2. 在“平台”开发部门的LeSS导入

在这个案例中的部门开发一个被多个上层商业产品所共享的平台，在辅导的时候是大约40人的规模。有必要重复之前的一个要点，在一个理想的更广的产品定义里，这个平台部门不应该是一个单独的“产品”，而只是更大产品的一部分。但是，组织结构边界使得一上来就定义更广的产品并不现实。这种可能的艺术也在LeSS对产品定义的规则中得到了体现：“产品的定义应该是在实际的前提下尽量广并且以终端用户/客户为导向。随着时间的推移，产品的定义可能会扩大。我们倾向于更广的定义”。

该平台提供了诸如操作系统扩展、通信、补丁之类的功能。它们处于下层，因此对其它开发部门很少有依赖，而是其它部门依赖于它们。对它们的需求并不是直接的客户需求，而只是由上层应用（另一个平台或者一个真正的产品）定义的解决方案的一部分。

2.1 建立认识

最初的一次LeSS工作坊发生在2015年8月。它是一个两天的工作坊，专注于理解一份产品待办列表和特性团队背后的组织设计原则。我们邀请了来自一些开发部门的关键管理者和有影响力的领导；其中有一半是来自这个平台部门。简而言之，我们以LeSS指南“启动”中的第零步“培训所有人”开始。然而，决定做组织结构变革已是2015年晚些时候了，大致是在工作坊过后的3-4个月。这也是LeSS导入中常见的做法：缓慢决策，在实际变革之前仔细学习和讨论。期间我们有过几次和管理团队的深入讨论。考虑到组织变革的风险和它涉及很多人员变更，这是寻常的节奏。

在变革开始之前很久它就已经开始了。

2.2 一个产品负责人和一份产品待办列表

工作重新设计的一个关键方面是创建一份且仅一份由多个特性团队共享的产品待办列表。这反映了LeSS规则：“对整个可以交付的产品有一个产品负责人和一份产品待办列表”。主要的改变总结于图4。

收集所有的工作放入一份优先级排序的待办列表是工作重新设计的关键。我们去除了项目群，从项目群模式转换为产品模式。这与LeSS指南“产品胜于项目或项目群”是一致的。

我们遵循了LeSS规则“对整个可以交付的产品有一个产品负责人和一份产品待办列表”，设置了一个且仅一个产品负责人。之前组织里有多个项目群经理会给团队指令，可以想象得到，这些指令之间常导致优先级冲突。当我们去除了项目群时，我们也去除了项目群经理的角色。其中一个前项目群经理因为有着扎实的业务理解和与真正产品部门良好的工作关系，所以就成为了产品负责人。

为了在实践中让一个产品负责人能工作顺畅，比如不会工作量过载，有必要让产品负责人更多关注优先级排序，而让团队做更多需求澄清，团队尽可能直接地与客户工作。这样的做法符合LeSS指南“优先级排序胜于需求澄清”。我们在后续章节2.6 迭代实践中对此将有更多描述。

2.3 初始的完成定义

跟工作重新设计相关的另一个重要方面是约定完成定义。我们拿他们原有的迭代交付标准作为起点，与版本发布标准加以比较，澄清其中不清楚的问题。最初的完成定义是由产品负责人、领域专家和管理者一起起草的，然后在第一个迭代开始前经过了新组建团队的评审。这一步骤和LeSS指南“创建初始的完成定义”一致。初始版本的完成定义并不完美，因为它并没有以可交付的产品作为迭代结束。在（不完美的）“完成”产品增量和最终真正可交付的产品增量之间有大约两周的延迟。完成之外（也就是正式识别为暂时不包含在初始的完成定义之内）的工作主要有两类。

一类是完全由“平台”开发部门自己掌控的内部工作，其中最重要的是全量回归和安全检查。全量回归仍然部分依赖于手工测试；而现有安全检查流程带来的工作量很大。基于现状考虑在初始的完成定义中包含它们并不经济。

另一类是和应用层的集成工作，它需要和其它开发部门一起完成，因此也就不是自己能完全掌控的了。按传统的做法其它部门不会使用还在开发中的功能，他们依然抱有集成可以轻松完成的幻想，因此觉得没必要提前来做。

我们把这些完成之外的工作放入暂时还需要的发布迭代中来做。发布迭代的做法在LeSS指南“创建初始的完成定义”中的第三步“探索如何处理完成之外的工作”有提到，关键点是特性团队而非其它单独的团队来做完成之外的工作，以避免交接浪费。

后来我们在减少这两类完成之外的工作上都取得了实在的进展，这一点遵循了LeSS指南“演进完成定义”。

具体怎么做的呢？我们通过自动化和流程优化把内部工作移到迭代里做，也就是把它们包含到完成定义中。同时我们通过改善和上层应用的协同把部分需求的集成工作也移到迭代里做。

2.4 自设计团队

在导入LeSS之前，该平台有4个组件团队各自负责不同的组件，和1个测试团队。我们通过自设计团队工作坊将他们重组成6个特性团队，自设计团队的做法反映了LeSS指南“三个导入原则”中的另一个：“使用志愿的方式”。我们的目标是将单一职能组件团队的组织结构改成跨职能特性团队的组织结构。这符合与团队结构相关的LeSS规则 – “每个团队是：1）自管理的、2）跨职能的、3）同在一地的、4）长期的”和“多数团队都是以客户为中心的特性团队”，以及LeSS指南“构建基于团队的组织”和“LeSS组织结构”。

管理层和我制定了一些新团队的约束，最初的列表如下：

• 团队规模5到6人
• 团队跨职能
• 团队跨组件、特性导向，能够完成平台范围内的“端到端特性”
• 团队知识面广，从而具备适应性（灵活性），能够从一份共享的产品待办列表里挑选任一条目

针对最后一点，我们对每个团队发展成什么都能做但是什么都不够深入的可能性有所顾虑。尽管每个团队能做任一条目提供了最大的灵活性，它也给短期交付带来了最大的挑战。不幸的是总有更快交付的压力，由此导致拓展学习的间隙不够。为此我们应用了LeSS指南“偏好在客户领域的专业化”，是怎么做的呢？
该平台有4个相对明显的领域（比如操作系统扩展、补丁），重组后会有6个团队。我们试着兼顾广度和效率，通过两条约束条件：1）每个团队至少能做两个领域的工作；2）每个领域的工作至少有三个团队能做。这样一来，每个团队还能有一定程度的专业化，它对效率有利；同时也能做到整个组织仍以来自产品负责人输入的优先级顺序工作，而不用因为受限于能力不得不去调整优先级。

在决定了约束条件后，我们继续设计了工作坊的日程。我们参考了这篇文章中的一些做法，制定的大致日程如下：

1. 开场（开发部门领导强调了自设计团队工作坊背后的动机）
2. 自荐成为组长（参见后续章节2.4 对比SM和组长）
3. 自组织团队第一轮（依据管理层设定的初始约束条件）
4. 自组织团队第二轮（加上参加人员提议的额外约束条件）
5. 自组织团队第三轮（修复“缺陷” – 未满足的约束条件）
6. 创建团队简历并介绍给整个部门
7. 收场（参加人员志愿分享感受和意见）

每一轮结束都有6个涌现出来的团队设置。第二轮开始时让参加人员提议额外的约束条件以帮助更好地组建团队。当他们看到第一轮中出来的一个具体的团队设置时，提议额外的条件要容易很多。比如，他们注意到有些涌现的团队全由资深人员组成，而另一些则全是初级人员。当这点被提出时，有一个简短的自由讨论，然后检查共识，有共识的条件就被加进列表。第三轮开始时则让所有人员给第二轮涌现的团队设置报“缺陷”。“缺陷”可以是1）某个团队缺乏测试技能，2）某个领域的工作只有两个团队能做，等等。然后他们自组织来修复那些未满足的条件。

整个工作坊花了两个半小时，6个稳定团队就此产生，还有因此充满的能量。前后状态的对比总结于图5。

2.5 对比SM和组长

对华为来说，导入LeSS – 更准确说是Scrum – 的一个挑战是引入SM角色。SM是教练，而教练角色在传统组织里几乎是不存在的。同时组长角色却很普遍，传统组织会让他们对团队绩效负责，其实这里的团队只是一个群组而已。这与Scrum和LeSS里的团队问责模型大相径庭。

当意识到在这点上没法达成共识时，我们决定保留组长角色，而把问责定义得相对模糊 – 由组长和团队共同承担。这样的安排并不理想，但却是我们的起点。随后我们给组长做了辅导自组织团队的培训，并通过引导站会和迭代回顾来具体示范。在那以后，有些组长拉我帮助他们进一步提升辅导能力。有些组长发展成更接近SM和教练的角色，而另一些组长则基本延续了他们指挥控制的传统方式。

2.6 迭代实践

在合适的组织结构（除了还保留的组长角色）到位后，我们就能相对直截了当地实施LeSS迭代实践了。

2.6.1 产品待办列表梳理

因为我们整个平台所有6个团队只有一个产品负责人和一份产品待办列表，我们从整体产品待办列表梳理开始。它不仅开始澄清工作，还协调团队间如何做后续的梳理。这跟LeSS指南“整体产品待办列表梳理”的做法是一致的。产品负责人和团队代表一起决定哪些团队会梳理哪些条目。对有些条目我们直接决定由哪个团队来做；而另一些则不定，因此让多个候选团队一起来梳理，直到迭代计划时再决定最终由哪个团队来做。即使团队是跨职能特性团队，具体的知识却不会均匀地分布在每个团队，因此不同团队的成员还是会按需被拉入帮助梳理特定条目。

2.6.2 迭代计划

迭代计划的两个部分都在一个大的共同空间里联合举行，如图6所示。参加人员包括产品负责人、所有团队成员、一些使用平台的开发人员，以及一些“技术支持”人员。因为多数条目的计划和澄清都能受益于多团队和多干系人的输入，所有人在一起确实帮助很大。在这个案例中有一个经验教训是我们并没有在迭代计划之前做足够的多团队产品待办列表梳理（我们多数时候做的是单团队产品待办列表梳理），这导致了在迭代计划时仍需要比正常更多的干系人参与和更多的澄清和协调讨论。比如说，有一次我们发现不同团队从两个（真正的）产品部门收到两个单独的条目，但它们背后其实是同一个需求。如果我们做更多的多团队产品待办列表梳理的话，就能更早地发现这样的问题。好在让多个干系人参加迭代计划还是能让我们看到它并加以解决。

迭代计划一的目的是理解要做什么。通常先由产品负责人大致讲解一下产品待办列表和接下来迭代的候选条目。团队一起决定那些条目分别由哪些团队来做。为了降低风险，产品负责人确保高优先级的条目被分布到多个团队。LeSS指南“迭代计划一”中就有“散布高优先级条目”的建议。对一些条目我们已经在产品待办列表梳理时确定了团队，而对有些条目由哪个团队做则在计划时决定。在选择完后，团队并行地澄清一些没有在梳理时考虑到的需求细节，并与会使用这些功能的开发人员直接讨论验收标准。当发现条目范围不清晰时，产品负责人就会被拉入到讨论中来。

注意我们的需求澄清是从产品待办列表梳理开始的，并在迭代计划一中继续。这实际上是混合了两个LeSS指南 – “多团队产品待办列表梳理”和“迭代计划一” – 中的活动。

迭代计划二的目的是理解要怎么做。我们的做法是所有团队在同一个大空间里继续进行迭代计划二，也就是以所有团队替代了LeSS指南“多团队迭代计划”中的部分团队。为什么所有团队在一起做迭代计划二呢？因为这能增加团队识别出协调机会的概率。经常会听到有团队只是喊一声“我们下个迭代要对组件X做大改动，有团队需要一起讨论基本设计吗？”，然后就有其它团队响应。

在迭代计划一或者二中，可能有些团队发现他们其实做不完那么多条目，而另一些团队则发现他们能做更多。当所有团队都在时，很容易由他们和产品负责人一起通过自组织来调整。

在开始迭代时我们的计划效率低，但是我们坚持对计划限制时间，这意味着前几个迭代的计划产出并不够好。最初我们只能识别出一些验收标准，并只能创建巨大且模糊的任务。当我们的计划能力提升后，在同样的时间内，我们能够草拟出验收测试，并通过对设计和协作的更多思考来创建更小更清晰的任务。

2.6.3 利用站会来辅导组长

组长对站会有着各式各样的理解，有些把站会误解为状态汇报会，站会是个通过示范进行辅导的好场合。每次我去都会观察他们的站会，并试着问有效力的问题，比如“我们这个迭代的目标是什么？”、“对我们达成目标最重要的风险有哪些？”、“什么让我们慢下来？”、“哪些是我们达成目标最重要的任务？”、“我们该如何调整？”，等等。通过问问题让团队自己思考并讨论决定如何推进这样的方式帮组长打开了如何带队的视野。他们中有些对辅导的方式很感兴趣，并开始学习问有效力的问题；而我则专注于给那些想成长为教练型组长的人更多帮助。

2.6.4 跨团队协调

他们整个部门都在同一层楼办公，这以非常简单的方式有力地帮助到了跨团队协调。

在迭代运作过程中从来没有涌现出对Scrum of Scrums会议的需要，这也和LeSS指南“可能不用Scrum of Scrums”相吻合。在产品待办列表梳理和全员都参加的多团队迭代计划二之后，团队通常对在迭代中需要与哪些团队保持紧密沟通心中有数。他们建立了各种渠道来分布式地协调，这也符合LeSS关于协调的规则，“偏好分布式的和非正式的协调，胜过集中式的协调”。具体怎么做呢？一个例子就只是让一个成员去观察另一个团队的站会，也就是LeSS指南“侦查员”的做法。

引入组件评审员主要是为了降低特性团队对组件知识欠缺所带来的质量风险，但是他们也有助于发现跨团队的协调需要。

测试社区是LeSS指南“社区”的一个实例。它不仅支持学习和提升测试技能，也同样有助于发现跨团队的协调需要。

这里的多渠道和着重识别协调需要正是LeSS看待协调话题的两个要点。

2.6.5 从质量控制到内建质量

在LeSS导入之前，这个部门传统的质量实践是“在创建后检查出缺陷”，而非“在创建时内建质量”。他们的质量实践包括设计文档评审和代码评审，都是在创建之后发生的。不幸的是，他们还没有掌握LeSS指南“多团队设计工作坊”和XP中结对编程这样的实践，而用这些“内建质量”实践替代事后“检查出缺陷”的活动将会更有效。因此，即使导入LeSS之后，他们还是继续了之前的评审活动，这些活动由少量指定的评审员来执行。

LeSS导入至少让这些实践带来的问题变得明显，因为它们延缓了开发和阻碍了持续地集成工作。

他们为此做了两个调整。第一个是增加了评审的频率，并提倡小批量频繁提交。第二个是增加了指定评审员的数目，以达到至少每个团队一个。

这些评审员同时在帮助团队增加对组件的知识，以避免在评审中出现大量的意见。随着时间的推移，在团队内的指定评审员被授权可以决定对某项工作的评审是否必须。

2.6.6 迭代评审。。。从“消费者”那里获取反馈

开始时我们想过邀请一些作为“消费者”的开发人员和干系人参加迭代评审，但是发现他们并不感兴趣。主要的原因还是在于这个平台并不是真正端到端的产品，而只是一个技术平台。迭代评审本义是要看并使用有意义的功能，而平台的功能最终都呈现为给上层应用的API和服务，这些并不适合在迭代评审中被“使用”。

因此，通常在迭代评审中就能获取的有价值的反馈在这种情况下只有当作为“消费者”的开发人员集成并使用了迭代产出的平台增量时才能获得。

我们都认同最有价值的反馈来自于对平台的集成使用，所以把焦点转向在迭代中，而非在迭代评审时，学习来自“消费者”的反馈。最终，我们扩展了完成定义来反映这一点，就是和上层应用的集成也要在迭代内完成。这提醒我们在决定条目优先级时问一下，“什么时候上层应用会消费这个条目？”。事实上，之前发生过在条目被交付后才发现已经不需要它们的情况。

当在迭代中对条目的使用就已经发生时，作为“消费者”的开发人员和团队直接交流，任何问题都能马上显露。到迭代评审时，我们只是分享期间的学习和反馈，讨论它们的影响并相应更新产品待办列表。

因为平台本质上是真正产品中的一个大组件，我们没法在迭代评审中根据完成条目和未来条目的真正客户价值来做检查并适应。真正的检查并适应发生在产品层面，而平台的工作则是集成进了真正的产品条目中。因此很不幸，我们的迭代评审更多的是在关注如何调整产品待办列表以满足各个产品的版本发布日期。

2.6.7 回顾和持续改进

针对持续改进，我们既做迭代回顾也做整体回顾。这里我把已经提到的一些过程改进例子总结如下：

• 从强制的评审流程演进为志愿的评审流程
• 把和应用的集成移到迭代内做
• 测试自动化以降低全量回归的成本
• 流程优化以降低安全检查的成本

从第一个迭代开始我们就引入了团队层面的回顾。传统的做法是组长会思考改进想法，然后让团队去实施。当过去组长询问团队想法时通常是一片沉默，这样的经历让组长不知如何让团队成员参与到持续改进中。我给所有的团队引导了至少一次回顾，示范了通过有效引导是能够产生不同效果的。比如，我们一起构造时间线来看到整个团队对过去迭代的视角；我们通过1-2-4-所有人的结构来共同产生行动想法。有些组长对引导的带队方式产生了兴趣，而我就会跟他们工作以帮助提升他们的引导能力。

我们也实施了LeSS规则“整体回顾”。我们在第一个LeSS迭代之前举行了一次全员参加的特殊整体回顾，它是就过去2-3个月开发上个版本的经历所做的反思。对于每个迭代的整体回顾，开始时只有组长、产品负责人和部门管理者参加。我们讨论了是否让团队代表参与进来，但是决定作为第一步先不让他们参与了。为什么呢？因为不幸的是让实际做事的团队成员参与到“组织改进分析”中这样的做法还是太过“激进”，所以我们决定在转变过程中采取小步走，先从组长开始，之后才把其它团队成员集成进来。

在持续改进中的一个焦点是缩短从不完美的完成增量到完美完成的可交付增量之间的时间。这是我们好几个迭代整体回顾的主题。通过系统性地移除障碍和扩展完成定义，参照LeSS指南“演进完成定义”的做法，我们在6个月期间将这个时间从大约两周缩短到三天。

整体上来看，在周期时间和效率上我们有了显著改进；而在质量上，就外部缺陷而言，在LeSS导入之前已经处在较低水平，之后则保持了低水平。

2.7 剩余的主要弱点和待改进方面

在我离开时，这是一些主要的仍待改进方面：

• LeSS导入的整个范围仍然只是局限在平台内，而跨越从上层应用到底层平台的更广的产品定义是继续演进的目标。
• 完成定义依旧不完美，还需要三天时间来处理完成之外的工作才能真正达到潜在可交付。
• 特性团队的专业化程度对完全按产品负责人的优先级工作仍有一定约束，有需要进一步拓展学习。
• 把问责从组长身上移除，然后完全给到团队。当然那样也就意味着移除组长角色。
• 更多的多团队产品待办列表梳理以增加学习广度，从而带来更强的团队适应能力。
• 加强结对或群体编程和持续地集成来提高“内建质量”。
• 在整体回顾中有团队成员的持续参与。

3. 在“产品”开发部门的LeSS巨型导入

我们接下来（更简短地）讨论的第二个案例是个LeSS巨型导入，它发生在另一个产品开发部门。如前所述，虽然这个产品确实用到了上个案例中的平台，它们的LeSS导入是各自独立进行的。

这个案例中的部门开发一个网络安全产品，由大约120人组成。这个组织的规模超过了较小的LeSS框架（适用于50人左右），因此用到了LeSS巨型框架。该部门有三组人，一组在北京，做web接口；另两组在杭州，做网络设备上的工作。有很多特性仍然会跨越前端的web接口和设备上的“后端”组件。

3.1 需求领域

在LeSS巨型中的关键决策是需求领域的建立。按照LeSS指南“需求领域”的做法，它既是工作的组合也是人员的组合。

一个较小LeSS框架的导入应该是“一步到位”的，但是LeSS巨型的导入是不同的。因为由此暴露的复杂度和弱点会是巨大的，所以我们需要考虑两个LeSS巨型导入的关键指南：“演进增量地导入”和“一次一个需求领域”。

这意味着在LeSS巨型导入的早期会是有些组处在特性团队的新模式，而有些组则处在组件团队的旧模式。举例来说，理想情况下我们应该解散北京的web接口组，因为它只是一个大的前端组件组（由此带来延期、交接和其它浪费）。但是考虑到这是一个在异地的组件组，而我们刚迈出LeSS导入的第一步，我们决定暂时保留那个组的传统工作方式。一开始就试着解决它实在过于困难。

所以我们决定先从杭州开始建立两个需求领域，而北京则暂时仍以一个传统的组件组工作。两个需求领域分别是“协同运营”和“系统支撑”。

为什么从一地开始？虽然LeSS导入可以是也通常是多地的，我们觉得在第一步不要引入太多的问题以确保有可见的成功非常重要。一下子引入两地或者多地增加了组织被太多问题淹没的风险，而初期赢得对LeSS导入本身的支持依然至关重要。

因此我们应用了巨型指南“演进增量地导入”，但是并没有应用另一条指南“一次一个需求领域”。为什么呢？在杭州“只有”80人，因此只会有两个需求领域，而且结构上需要调整的并不大，基于此我们觉得相对有信心在两个需求领域同时导入。

另一个有趣的决策是我们是否将需求领域和正式的直线组织结构绑定。我们决定将正式组织结构和需求领域分离，也是遵循了LeSS指南“LeSS巨型组织”里的建议 – “避免将需求领域等同于组织结构，因为这会导致需求领域难以改变”。为什么有这样的建议？我们在这个案例中就直接看到了那样做的问题。该产品的每个市场版本大约6个月，从这个版本到下个版本，优先级的重点会从一个需求领域转向另一个需求领域。我们希望有一些团队能在不同的版本周期移到不同的需求领域工作。如果这样的调整需要改动“汇报线”，考虑组织政治的因素，进行如此频繁的“汇报线”变更将会非常痛苦。结构具有粘性！为了能够适应两个需求领域之间优先级的波动，我们计划在每个需求领域都能有一个团队可以按需工作到任一领域。

3.2 产品负责人团队

我们按部就班设置了一个产品负责人和两个领域产品负责人，还有三个项目群经理角色也被保留下来，但只作为和公司其它部分的接口。他们一起组成了整个产品的产品负责人团队。

产品负责人是那个组织里最资深的人之一，他有能力与多方干系人工作并做出艰难的优先级决策。然而，我们没能在组织里找到同样经验水平的人来做领域产品负责人，这清楚地反映了该部门在产品管理上的弱点。领域产品负责人最终需要直接与干系人工作并能自己做决策，产品负责人以此为愿景扮演了领域产品负责人导师的角色，不只是帮助他们完成工作，还帮助他们成长。这跟LeSS指南“LeSS巨型产品负责人”里描述的他有培养和支持领域产品负责人的职责是一致的。

3.3 在需求领域中的扩展组件团队

因为北京的web接口组仍然保留作为一个组件组，我们没法一步到位完全实现特性团队。在这种情况下，LeSS指南“特性团队导入地图”提供了一个演进路径。我们是以扩展组件团队开始的，这意味着每个团队能在一定范围跨组件开发，因而减少了浪费增加了适应性，但是仍然没有达到完美愿景中能够全栈工作的真正特性团队的状态。

作为LeSS巨型导入的第一步，这些扩展组件团队是基于命令行接口对网络设备做自动化和手工探索测试的，而web接口组则做完整的端到端集成测试。

为了实现扩展组件团队，一个变动是我们把测试组分散到各个团队，以使每个团队都包含稳定的测试人员。

为了实现每个领域共享一份领域产品待办列表，我们需要创建有能力做领域内任何条目的团队。在变革之前，每个团队都工作于单一的专业子领域，本质上在每个子领域都有一份隐性的待办列表。如何创建领域内的全面团队呢？我们并没有进行团队重新设计，而是让已经存在的团队扩展他们的工作范围到更多组件，过程中他们得到之前相关专业人员的学习和反馈支持。这样的方式可行是因为子领域之间的技能差异并不大。

按照特性团队导入地图中的增量方式，LeSS巨型导入的未来步骤会是杭州的团队要学习web接口开发工作，从而变成全栈特性团队，当然也承担完整的端到端测试。

3.4 依赖

在LeSS巨型里多数的迭代活动通常是按需求领域进行的。这里是个真正的产品，而非平台，因此带来了更多的依赖复杂度。该产品依赖网管和若干平台，而它们都是由其它部门开发的。考虑到组织边界，把团队扩展到跨不同开发部门并不现实，所以我们不得不借助其它方式管理依赖。SAFe在公司的很多部门都有采用，所以我们对此的策略简而言之就是在部门之间做SAFe的“项目群增量”同步来管理依赖，而在部门内则转向特性团队来消除依赖。当我们能把工作同步到同一迭代时，集成就可以在迭代内持续地进行。然而，跨部门不同步的问题还是时常发生，这是因为在更大结构上有着根本性限制 – 其它部门本质上是在给我们的产品开发组件。

在未来有机会扩展到更广的产品定义时，它应该包含网管部门和“平台”部门的工作范围。那样我们就能扩展成真正从前端到后端的特性团队，从而消除那些依赖。

4. 我们学习到的

我们的经历对Richard Hackman的发现 – 合适的团队设计比有效的辅导更能影响团队绩效 – 有很强的共鸣。LeSS对组织设计的强调也反映了这一点。传统的方式是在现有结构里试点，而结构先行的方式会是一个更好的替代方案。

如果我们能约定一个针对有效辅导的愿景将会是更好的情况。因为在组织层面缺乏这样的约定，是否转向辅导方式的选择留给了组长个人，这限制了我们作为整个组织在自组织团队上能走多远。

在战术层面，我们主要的学习收获总结如下：

• 用渐进的方式来扩展领域专业能力以获得更多灵活性。
• 从传统组长到SM/教练的转型路径。
• 通过跨团队的联合Scrum活动来促进自组织。
• 让所有团队深入参与需求澄清和反馈，以使一个且仅一个产品负责人能够对应多个团队。

从某种意义上，这个经验报告并不是一个完整的故事。它没有讲我们参与之前发生的事。在组织里工作的人需要理解LeSS导入带来的变化是很大的，因此得准备发挥可能的艺术，并抱有耐心一直坚持到组织能够重新被设计。

5. 致谢

我想特别感谢我在华为的联系人陈光镜。我们在整个过程中都紧密工作，对如何帮助这两个部门推进有过很多深入的讨论，也分享了很多洞察。

这个经验报告最初的版本是在敏捷2017大会上发表的，我想感谢Chris Edwards对此的无私帮助。在随后将它变成一个LeSS案例的过程中，Jurgen De Smet作为我申请LeSS培训师的导师给予我了很多有用的反馈。最后，我想感谢Craig Larman帮助我再次改进它，最终成为了它现在的样子。

作者：吕毅，中国首位CST，LeSS认证导师
原文链接：https://less.works/zh-CN/case-studies/huawei

这个例子来自德国纽伦堡的某个硬件产品团队，他们在5年前开始导入LeSS（大规模敏捷）。

产品领域是电信硬件和软件，其中关键是cross connect board(某种PCB电路板)，包含电源、FPGA–现场可编程门阵列(其中一些最终融入到ASIC–专用集成电路中)、设备驱动等。

一个架构要点是，容错是非常重要的；一块PCB电路板经常具备另一块“B计划即故障切换(failover)板子（想象该cross connect board”方案具有A板和B板），即使在单块板子上也会有容错处理（例如:从外接电源切换到电池）

作为一个例子，一个特性团队应该包含具备不同技能的人，如电路板设计、热能分析和调整（降温和耗散设计）、电源、FPGA（Verilog编程语言）、Linux设备驱动（C和C++语言)、其他（此外，有个人现在能用FPGA的Verilog语言做TDD，采用了一个有趣和有用的工具叫SVUnit。如果想学习更多硬件研发和增量分拆的话，我推荐大家接受FPGA Verilog TDD辅导）

将巨型增量分解为更小（但仍然巨大）增量的一个明显方式是：

• 只有一块板子
• 不集成A板和B板
• 不支持故障切换
• A板和B板集成并带有故障切换。 *

对于单块板子，它包含供电，并支持主（电源）备（电池）切换。注意团队可以创建一个增量，只有一个主电源的单块板子（相对于支持切换到备用电池来说）…没有其他东西了。于是第一个具体的增量是这样的：

• 带有主电源（外部供电）的单个板子（不含其他芯片/功能）
• 带有第二电源（电池供电）的单个板子（不含其他芯片/功能）
• 带有主备电源（以及主备切换）的单个板子

接下来，现在是DC直流电（而非AC交流电），而板子需要AC/DC转换器。这也需要2个（为了容错切换）。于是：

• 带有主备电源的单个板子，以及主AC/DC转换器
• 带有主备电源的单个板子，以及第二AC/DC转换器
• 带有主备电源的单个板子，以及主备AC/DC转换器（以及主备切换）

板子要能够通过探针和查询来提供信息。于是：

• 带有主备电源的单个板子，以及主备AC/DC转换器，能够启动并提供”空“的服务水平信息
• 带有主备电源的单个板子，以及主备AC/DC转换器，能够启动并提供简单的服务水平信息
• 带有主备电源的单个板子，以及主备AC/DC转换器，能够启动并提供丰富的服务水平信息

板子能够提供配置/控制。于是：

• 带有主备电源的单个板子，以及主备AC/DC转换器，能够启动并提供丰富的服务水平信息，并且可以处理“复位”操作
• 带有主备电源的单个板子，以及主备AC/* DC转换器，能够启动并提供丰富的服务水平信息，并且可以处理“复位”和“进入省电模式”等操作

或许这足以感受一下如何分拆硬件增量？

毫不惊讶，采用FPGA进行增量开发，那么板子的服务就容易进行纵向拆分（一早就有的软件功能分拆）。如果大家想要最终走上ASIC的路上，那么我们可能先仅仅从FPGA开始，最终再转变到ASIC。

=== 注意硬件组件团队的局部优化认知偏见 ===

顺便提醒我的是：据我所知，对于形式上的硬件研发敏捷或Scrum，常见的入门建议是采用预定义的接口来定义单独的硬件组件，然后据此建立单独的组件团队。这与纯软件的组件团队没有区别，且在硬件研发造成和软件研发一样的系统动态，局部优化，缺乏敏捷性，没有工作在最高价值上，造成浪费。

反之，跨硬件组件的特性团队。硬件组件的边界，有时候的确是难以用一个真正的特性团队联系到一起，这是因为”硬知识“的限制（比如我们辅导过的施乐，(1)光学引擎，与(2)送纸机械，会用到(1)大部分光学知识，(2)机械工程知识，于是难以融为一个团队）。但是通常来说，在LeSS中我们建议去尝试更多的跨硬件组件的特性团队（比如：在一个团队中，包含具备不同技能的人，如机械工程、热能分析、FPGA、电源等）。我们承认有时是太难以至于无法融合，但值得尝试，而不是将硬件组件研发落入局部优化偏见的限制思维中。

本文由@申导 翻译自Craig Larman(CST/LeSS创始人)在SA TCC board中回答的一个问题。优普丰敏捷学院原创内容，未经授权，不得转载。

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.