前言

业务敏捷可以定义为一个组织重塑自我并快速适应环境变化的能力。克劳斯.利奥波德在他的书《Rethinking Agile》中提出，人们需要优化交付客户价值的流来实现业务敏捷。通过优化流，你迟早会注意到需要组织结构做什么样的调整来加以支持。

首先，关键是理解敏捷的真正含义，就像敏捷宣言中构想的那样，它并不是组织交付客户价值的速度，而是组织以低成本快速响应变更的适应性。（参阅《Scaling Lean & Agile Development》中 Be Agile一章）。利奥波德对于组织变革还有这样一个观点：在持续地关注系统优化目标时，人们会注意到那些阻碍改进的因素。然而通过系统思考，长时间在实地的观察和实践，对现存系统动态的反思，人们也可以预见到那些阻碍快速适应能力的相对明显的现存组织障碍。在这个故事中，一个组织学习并最终看到影响大规模适应性的组织障碍，它经历了漫长而痛苦的过程。更糟糕的是，很多管理层试图保持传统管理现状而仅仅将事物标记为"敏捷"，而不是去预见 - 或者愿意去预见 - 相对明显的障碍并在一开始就进行必要的变革。简而言之，这个过程恰恰反证了LeSS中的关键导入原则（"对于产品团队，要在一开始就建立LeSS的组织架构，这对导入LeSS非常关键"）以及由此带来的后果。

所以，接下来的案例说明了，如果组织没有在一开始进行合适的组织设计，会发生什么情况。从开始的传统组织架构和管理方式入手，可能混有一点伪Scrum元素，LeSS要求的组织设计也许会浮现。但这将会是一个更长、更危险的旅程，因为它可能不会带来导入LeSS所预想的好处。为什么？因为一旦没有立即采用新的组织架构，那股保持组织现状的强大力量极有可能会获胜（参阅拉曼组织行为定律）。

本案例的关键"反事实"洞察：如果你想开始业务敏捷的旅程，期望减少过程中的许多痛苦，并快速获得LeSS所预期带来的适应性上的提升，一定要在导入LeSS的开始阶段就建立合适的组织结构，就象LeSS规则所倡导的那样。

开始之前的评注

LeSS就是（多团队的）Scrum，Scrum就是单一团队的LeSS。（参阅原则：大规模Scrum也是Scrum）。为了让本案例中的描述更加准确，我还是会澄清哪些是Scrum指南中的规则，哪些是LeSS指导方略中的规则。在参与这个案例的过程中，我受到less.works网站的积极影响，参加了Bas Vodde和Craig Larman的LeSS实践者课程，并花费了大量时间阅读最初出版的两本LeSS书籍。可惜的是那时第三本书还没有出版。在这个案例中，我阐述了我们尝试过的LeSS实验，并且也会关联我们遵循的LeSS原则、规则和指南，尽管那时并不知晓。

简介

下面的案例涵盖了我从2015年2月到2016年9月在一家公司Sys的IT组织做外部教练的时光。Sys是一家来自德国的从事软件行业的跨国公司。因为我已签署保密协议，所以不能在此公布公司的真名和其他相关的公司信息。时间回到2014年底，Sys着手用一个平台来变革公司软件销售方式，取代现有各种外部合作伙伴平台。这个平台的诞生标志着Sys迈入电子商务新途径的里程碑，不仅重新思考了如何直接地向客户销售软件，还重新定义了卖什么（例如，除软件以外的数据）和怎么收费。

图1: Tanja Wehr绘图 - www.sketchnotelovers.de

2011年，我曾在负责所有内外部平台的Sys IT部门工作过，这些平台跟Sys商店很像，那时我们整个部门开始将瀑布模式替换成Scrum。在用（单团队）Scrum的方式搭建了两个平台之后，我离开了这家公司，去支援其他客户的敏捷之旅；在2015年的早期，我又重新加入Sys来支持这次重要的旅程。

变革之前

系统架构

图2: 系统架构

变革之前的组织结构

图3: 变革之前的团队结构

图4: 变革之前的组织架构

痛苦的最后期限和变革的必要

当我在2015年2月底加入时，平台基本上已经可以使用，只差正式宣布。各团队还在冲刺最终官方发布日期：2015年5月5日。到时候公司会在美国举行有史以来最大的会议，首席数字官会当场向公众演示这个平台。所有正在研发的功能都是官方需要发布的功能，所以，项目办公室制定了一个看起来能在5月2号发布所有功能的严格的项目计划。该计划包含了研发阶段、系统集成阶段，用户验收测试以及回归测试，就像我们通常说的瀑布模式。

在三月的最后两周和整个四月项目进入一个动荡期。时间表正渐渐延期。当并行工作在不同功能的团队将他们的代码合并到主代码仓库后，很多之前已经测试通过的功能不再能使用或者表现异常。不停修复这些问题又带来新的问题，并且还经常突然接到必须立刻实现的新需求。在此之上，之前从未考虑过的安全问题和负载测试现在也必须解决。管理层变得十分焦虑，每个人不得不工作更长的时间来尽量满足计划。在四月的最后两周，还建立了一个"作战室"，所有的经理、团队负责人和架构师都在这个房间从早到晚不停的清理障碍以保证发布的所有准备工作都做好。最后，开完数不清的升级会议和成百上千小时的加班之后，团队终于能够在大会的第一天发布平台的新版本。

经过了如此痛苦的发布，对管理层来说，毫无疑问现有的研发方式已经不能支撑公司的雄伟目标，那就是销售指数级增长，能快速尝试新的商业模式和推出完全不同的产品。Scrum作为一个敏捷研发框架，专注于首先交付最高业务价值，持续关注透明性、检视和调整，这些都建立在基于经验过程控制的理论之上，它成了一个自然而然的选择。然而要导入Scrum或者LeSS都被认为极其困难，不仅仅是因为组织层级设置和对分散在不同地方的各种技术专家的依赖，还受到巨大营销渠道的影响，即每年有两次不可更改的作为大里程碑的重要峰会。

引入变革

作为一个偏好大规模Scrum的经验丰富的敏捷和Scrum教练，我被要求建议"研发部门"应该如何改变工作方式以应对当前的挑战。 我的挑战因此是（1）让所有人都意识到为了应对挑战不只是研发部门而是整个组织要改变；（2）帮助参与者通过理解为什么来拥有变革背后的想法，而不只是跟随我的想法遵循我的建议而已。 在一次上层管理者（包含Sys首席数字官）的会议中，我展示了从和业务和研发代表的对话中收集到的关于挑战的总结。它包括：

• 业务挑战（摘录）

  • 单个特性和产品能力的优先级不明确
  • 明确标注已完成的工作在后期出现问题

• 技术挑战（摘录）

  • 可用性和基础设施问题（性能，端口关闭等）妨碍了日常运行
  • 整个部署流程耗时太长。常常缺少某些部分（模版，后处理等）
  • "架构师"们忙于做构建流程、合并代码、以及基础设施的建立/配置这样的手动任务
  • 使用各种分支而不是基于主干的开发，导致代码合并的工作量巨大；并且质量很低，有许多缺陷/问题
  • 测试数据的的创建是一个非常耗时的过程并深受知识缺口的影响

在准备这个会议的过程中，我还收集了管理层的整体改革目标。基于与管理团队成员一对一谈话和访问，我总结了如下几点：

• 通过清除浪费来优化系统以更快地向客户交付价值
• 给组织赋能以使其更加理解客户并更快响应新的需求，还能从已发布的不足中学习和调整
• 改进交付代码质量并减少缺陷/问题的数量
• 关注整体产品，对以客户为中心的需求优先顺序可视化
• 增加各团队正在进行的工作的可见性

第二个目标跟LeSS中的整体系统优化目标是一致的，即学习并交付给付费客户最大"价值"所需的最高适应性。其他目标可以通过对LeSS原则的特别关注而实现（例如：第一个可以用排队论和精益思想）。所以我非常高兴地看到研发团队和管理层都喜欢应用Scrum，把它作为一个软件研发框架并紧贴敏捷价值观和敏捷原则。我个人觉得，为了成功，我们不仅要激励那些有着清晰目标的个人，还需要得到组织高层的支持来移除障碍并赋能变革。这已在LeSS指南三个导入原则（自上而下&自下而上）中体现。

然而，我也注意到这里并没有对Scrum的理解形成共识，需要一个工作坊来培训所有人并对组织变革达成一致。这也体现在LeSS指南：开始中。

我在管理层会议中的总结报告中提出，在开始变革之前需要一些前提条件：

• 业务和研发需要对工作模式达成一致，才能帮助达成上述目标
• 我们需要（1）自组织的（2）跨职能的（3）同在一地的（4）长期的 团队 （见LeSS结构规则）
• 团队需要Scrum培训，创建工作约定并对于完成的定义达成一致
• 建立产品待办列表，包含技术项和业务项

管理层一致同意上述几点，给了一个月的时间来准备过渡到新的工作方式。

开始

下面几段描述了我们当时对组织变革还认知有限的情况下所做的几个启动步骤。我会将它们关联到LeSS的指南和规则 - 我们遵循了哪些；更重要的是强调了那些我们本应做得不一样的部分。

首先，我们组织了一个两天的工作坊，参与者来自研发部和业务部。这个工作坊由我本人负责，并带了一个助教，主要是做Scrum培训。这个做法与LeSS的导入指南一致：LeSS指南：开始 0，培训每个人。

在工作坊结束时，参与者理解到Scrum不是一项实践或者一个定义好的方法，而是想be agile而非"do agile"所需要的组织设计变革。这个工作坊还在研发和业务之间建立了强有力的纽带。

回顾中得出的关键教训是下一次这样的工作坊要包含所有的高层管理干系人（而不只是几个）。通过让高级管理人员思考LeSS组织设计的含义，例如团队结构、层级结构、所在地策略、角色、流程和政策，不仅可以获得对更改组织结构和政策的支持，还可以从一开始就建立正确的结构，这能省去很多麻烦 -- 正如我们经历的那些。

第二个关键教训是持续关注如何让参与者探索、理解Scrum和LeSS的意图、想法和组织设计变革的含义 ，而不是仅仅关注教授Scrum或LeSS的知识。为了更聚焦在原因上，在LeSS原则（例如：系统思考、精益思想）的支持下，让参与者从中导出他们自己的工作模式。这样做使得他们参与更加深入，因为我们更少关注拷贝"最佳实践"或者一个方法理论，而是理解系统优化目标、现有系统动态是如何符合（或不符合）该目标的，以及系统可以通过怎样的改变来更加符合目标。

定义"产品"

就像指南:开始 1. 定义"产品" 中说的，产品的定义是"你做出的最重要的决定之一"，因为它决定了导入的范围、产品待办列表的内容，以及谁是最合适的产品负责人。在我们的案例中，产品的定义受到产品愿景和已有的组织结构的约束。想了解更多关于约束产品定义的因素，可参见LeSS指南：你的产品是什么？

产品的愿景是"创建一个简单连贯的数字体验用于寻找、尝试、购买和消费Sys软件以及其合作伙伴的解决方案"，并"简化客户的数字购买过程和体验，准确地提供他们想要的东西，在他们想要的时间和地点"。目标是通过这个由当时的CDO（首席数字官）带领的Sys数字部门负责的电子商务产品来实现。电子商务站点用来提供来自Sys不同部门和其他公司的产品。在理想状态下，产品的定义会随着时间扩展（见LeSS规则：产品的定义应该依照实际情况，尽可能广泛，并以最终用户/客户为中心。随着时间的推移，产品的定义可能增加。 更广泛的定义是首选）。然而从开始的角度来说，有限的产品范围给了我们更清晰的产品定义。

一个非常棘手的已有约束是Sys的IT部门没有任何研发工程师有SAP Hybris Commerce Suite的经验。于是他们聘请了一家专长于此的公司，为他们提供了散布在欧洲各个地方的工程师。然而，就像我们将看到的那样，这极大地影响了团队的建立。

建立团队

第三步，我们关注在建立团队和首次组织变革。

之前提过，最初我们的特定组件团队（比如SAP CRM后端或SAP Hybris Commerce)与单一职能团队（比如架构团队或测试团队）之间是割裂的。在培训时期，我们强调如果想要改进我们的能力来交付以客户为中心的最重要特性的话，就需要建立跨职能、跨组件、稳定并长期存在的特性团队。这反映了第二条LeSS组织结构规则，其背后的原因在LeSS指南：理解特性团队中作为总结出现，其细节可参考第一部出版的LeSS书籍《Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum》。第二部LeSS书籍中的两个实验也表明了这一点：避免单一职能团队和避免组件团队。

新建的团队用特性团队来组织，包含了拥有不同技能的各类专家。最终我们建立了四个团队，每个团队里包含三到四个SAP Hybris研发，一个SAP后端研发，一个UI专家，两个测试专家，以及一个专长持续发布的架构师。我们解散了专业测试组和架构组（把他们融入特性团队），并建立了社区，在那里专家们可以定期交流并对齐工作方式。在"社区"部分我会就此详细说明。尽管很不幸合同需要我们依然有带着专家头衔（比如"解决方案架构师"或是"测试专家"）的人，但是我们从一开始就明确团队成员们"愿意把头衔放在门外"，学习必要的技能并帮助他人以便能够在每个Sprint结束时创造一个已集成的产品增量。

开始时每个团队配备一个专门的Scrum Master，因为绝大部分Scrum Master和团队都没有LeSS的经验。为了以身作则，我在其中一个团队里担任Scrum Master。通过我的培训和辅导，一个前项目经理逐渐可以满足Scrum Master的要求并在三个月后替代了我的位置。

在第一年，一个Scrum Master只能支持一个团队，后来有些Scrum Master可以同时支持两个团队。他们的关注点从帮助团队改进工作方式转移到揭露阻碍团队提升绩效的组织功能障碍上。这反映在LeSS指南：Scrum Master关注点中。

图五：Scrum Master关注点随时间变化

系统运作

Sys的IT部门曾经经历过许多项目的实施，系统在几个月到数年内被构建，但到某个时间点，预算就不再增长而只通过配备离岸团队对系统持续运作和维护投资。在过去，这种方式会在"实施预算"快耗尽前引入一个"交接"阶段。这里也包含了对离岸团队的知识传递。这个"交接"阶段总是十分痛苦，关注点常常只在为维护团队创建"刚刚好"的文档，而这样会导致系统恶化，因为维护团队对每个功能最初背后的原因没有足够的理解，而提供的资金也只能增加一些小的功能而不足以改进整个系统。

我们在"培训工作坊"期间设法解决这个问题，保证有部分"维护预算"来将离岸研发人员一开始就整合到特性团队中。他们刚开始对SAP Hybris Commerce系统或SAP后端系统一无所知，但通过结对和mob编程，他们逐渐能从"仅仅修复问题"到实现系统新增功能。这对系统的代码质量产生了巨大的影响，因为（离岸）团队成员特别关注技术债和必要的文档随系统而增长的事实，而他们将是"实施预算"耗尽后的持续负责人，所以常常是他们来提醒其他团队成员关于系统质量的问题。

开始时未解决的组织挑战

在团队最初建立之后，仍有两个挑战未得到解决：分散的团队和与业务人员的集成。虽然这在前期带来了更大的问题， 它们在后来还是被解决了。

第一个挑战是我们团队太分散。之前说过，内部研发部门没有人懂SAP Hybris，所以必须依赖外面的公司提供懂SAP Hybris的工程师。而这个公司的工程师散布在欧洲各个地方，大部分人在家办公。在那时，让所有团队成员搬到一个地方长时间工作是不可能的事情，也没有资金，所以我们建议先做两周的启动活动, 然后每六个月安排一次现场活动。让所有人在一起办公的效果太明显啦，以至于大家很快都意识到这种差别。而对团队结构的调整也极大地改善了团队的绩效。不到一年后，团队就又重新组织，以使大部分成员在一个地方工作。

新的组织结构已经变成了图六这样。

图六：改变前后的团队结构

第二大挑战是与业务人员的集成。之前说过，组织里除了真正做市场调研或伙伴关系管理的产品经理们，还有很多在真正的研发人员和真正的业务人员之间的中间人。这些中间人忙于传统瀑布中定义的任务，比如识别下一步做什么、描绘系统蓝图，或做终端测试。同时，研发部门已经习惯了与他们自己的（伪）产品负责人以Scrum的方式工作，这个产品负责人实际上只是一个中间人项目经理。在过去，这个人作为一个团队与业务的接口而存在。在研发这边还常常有一个带伪中间人"产品负责人"身份的业务分析师，负责编写需求和为研发部门澄清需求，以及一个带伪"产品负责人"身份的项目经理充当业务人员和研发之间的唯一桥梁。当我们在"培训工作坊"中讨论这件事情时，大家都清楚这里有管理层的限制和缺乏管理层的支持来从一开始就直接改变组织结构。但是就象在接下来的"唯一的产品负责人"章节所述，这个情况导致了非常多的组织功能障碍。大约八个月之后，我们改变了组织结构，只有一个产品负责人负责整个产品，其他产品经理则对其支持。

启动

"培训工作坊"结束两周后，研发和业务的代表们一起组织了一个大型工作坊，让所有团队成员都来参加这个最初的启动活动。两周内，所有的团队成员都有机会相互认识，相互讨论、反思并就他们共同希望的工作方式达成共识。

这个大型工作坊还涵盖了两天的Scrum培训（所有人都参加），创建了最初的完成的定义（DoD)，建立了团队和整体工作公约，最重要的是帮助团队凝聚在一起。

对于我作为一个教练和其中一个团队的Scrum Master来说，有一个很重要的事情是让团队尽快从"形成"阶段过渡到"规范"阶段和"高效"阶段。当然在两周内是不能达成的，但是理解了团队发展动态，让我们知道在这两周内我们最主要的关注点应该放在建立一个共同目标和建立团队成员之间的信任上。因此我们做了非常多的团建活动，取得了巨大的成功。

完成的定义

在这两周"启动"会议中，所有人都来到了现场，来建立一个适用于所有团队的初始"完成的定义"，如LeSS指南：创建完成的定义描述的那样。在这个工作坊，我们与所有成员一起探索为了交付产品（潜在可交付产品增量）我们需要做什么，并将所有团队那时已能在日常Sprint中做的活动和产品发布所必需的其它活动区分开来。这也是我们第一次深入讨论不同类型的测试和文档，并设法让大家对于工作方式达成一致的理解。

图7: 潜在可交付物和完成的定义最初版

图7中划线的条目是大家一致同意放进初始"完成的定义"中的条目。其他都算作"完成之外的工作"，即不在"完成的定义"中但也是交付产品需要满足的条件。开始时这个"完成之外的工作"非常多，而我们最终目的是让所有在"完成之外的工作"中的条目最终都包含在"完成的定义"中。在随后的"发布Sprint"章节我会解释我们是怎样处理这些"完成之外的工作"的。随着时间的推移，我们通过整体回顾会议渐渐扩展了这个初始"完成的定义"。

唯一的产品待办列表

对我们而言，重点之一是从一开始就有唯一的产品待办列表。这也符合LeSS规则：一个整体交付的产品只有唯一的产品待办列表。

业务方原有的组织结构和不同产品经理的职责分配给我们的开始带来了不少挑战。不同的产品经理负责在电子商务网站上发布不同的Sys产品，这导致了优先级的冲突。在过去，每个团队有一份他们自称的"产品待办列表"，由一个横在真实的业务人员和团队之间的带伪"产品负责人"身份的项目经理来对团队待办列表上的条目进行排序。这导致了局部优化，因为每个团队的"产品负责人"只关注交付产品的某个部分，而缺乏整体视野。结果就是每个"产品负责人"都在争取交付更多的功能，而期望"其他团队"来改进整个产品和发布的流程。当然，这并没有发生。

我们的目标是让真正全局重要的（已经确认包含在里程碑中的）条目包含技术条目可见。我们尝试了用户故事地图。想法是在地图上标注所有的重要条目并重新组织它们以使得我们能够把所有重要条目放在一起来讨论和排序。通常情况下，在产品待办列表梳理结束几天之后，在Sprint计划会议开始的几天之前，基本上是每两周，产品经理团队（包含伪PO们）会花大约两个小时来展示和讨论各个梳理结果，并就要带到下次Sprint计划上的产品范围达成一致。这样做的优点是为业务方下次里程碑上需要实现的条目创造了可见性，包含了团队在梳理中对条目所做的估算，以及有多大可能在一个Sprint里能实现这些条目。这样做的挑战在于，它引起了许多激烈的讨论，因为每个产品经理都有一些"个人目标"要实现，因此几乎不可能达成共识。这导致了一段时间之后在谁负责排序这个问题上的改变。

唯一的产品负责人

之前说过，开始的时候我们在研发方有一个带着伪"产品负责人"身份的业务分析师，在真正业务人员与团队研发人员之间有一个带着伪"产品负责人"身份的项目经理，我来讲讲这件事的背景。在2011年早期开始把（单团队）Scrum作为研发框架导入组织的时候，由于不够理解Scrum和真正的Scrum Master或产品负责人是什么样的，来自Sys IT部门的项目经理们被要求选择是否想把自己变成所谓的"Scrum Master"和所谓的"产品负责人"来满足新的工作模式，这当然没有真正改变什么（见拉曼组织行为定律 #1和#2）。一部分前项目经理选择成为"Scrum Master"，另一部分选择成为"产品负责人"。这给大多数前项目经理形成了巨大的挑战。困难的部分并不在于学习新的未知技能（比如个人或团队辅导），而是与软件研发团队工作时放弃原先的信仰和行为模式（比如在自组织不发生的情况下如何做）。这导致事实上在我们团队里只有一个前项目经理后来保持作为Scrum Master（并且这个人向公仆式领导者的转变非常快）。因为只有头衔变更而组织结构和政策都没有相应变化，并没有真正的产品负责人成为"产品负责人"，而只是重新把项目经理标记为伪"产品负责人"。

这种每个团队带有两个伪"产品负责人"的非常规设置，是基于没有理解导入Scrum的意图，在开始的时候感觉还不错，因为研发团队有了"业务现在已经靠近研发"的错觉，并产生有了研发团队获得客户期望的"高效渠道"的假象。然而这导致了两个主要问题：一是让团队"产品负责人"们负责团队的"产品待办列表"会导致局部优化，如上所述；二是团队的"产品负责人"们（业务分析师）逐渐成为团队理解需求的中介和瓶颈。让伪产品负责人编写产品需求说明书，然后递交给团队来"实现"，这样的做法产生了大量的浪费，比如交接问题、延迟、过度处理、在制品和缺陷。

整个产品只有唯一的产品待办列表，并按时（每个Sprint）讨论，我们确保了团队"产品负责人"/项目经理们可以改变一些条目的优先顺序，但还有其他人可以管理团队正在研发的所有条目的优先顺序。有时候，团队"产品负责人"们所定义的优先顺序并没什么意义，因为团队最终会工作在其它相对于整体产品更关键的条目上。终于到了某个时刻，其他项目管理部门的人在优先顺序上花费的时间越来越少，只有唯一的一个非常靠近CDO的人来负责对所有团队的所有条目排序。

第二个问题的处理（团队产品负责人是信息瓶颈）更加困难，主要是因为公司本身的约束。事实上，团队成员对和客户澄清需求感到不舒服，或是缺乏这方面的技巧，或是相信由一个人来做需求澄清同时其他人专注在研发上会更加（局部）"高效"，亦或是伪产品负责人团队（项目经理们和业务分析师们）有着不一样的身份和薪水 -- 所有这些都让它成为一个巨大的挑战。

技术卓越

技术卓越是一个对我们的LeSS导入非常重要的部分。在"引入变革"中说到，我们成功的标志是在多大程度上能减少缺陷的数量以及我们可以以多快的速度发布新的功能，以此来交付客户价值或者至少学习并理解客户和变化方向。引入并持续改进以下敏捷工程实践使我们在这两个目标上都取得了巨大的进步。

迈向持续集成和交付的婴儿步

从每个团队在不同的分支上工作几周甚至几个月才向主干合并代码，到持续集成，在我们这个案例中，经历了漫长的过程，其中有很多教练课程、对话/会议和讨论。当然，最初的工作方式毫无疑问带来了太多的问题，比如破坏系统、引入已经修复过的缺陷、在与新功能无关的系统维护与稳定等事情上耗费太多时间。见避免...大批量的改动。因此在研发这边对远离大发布有很高的接受度。不幸的是，没有人知道怎样才能做到。在案例中对我们有所帮助的是联系了其他IT部门的人，他们之前在Sys创建了一个内部云系统来自动化所有Sys IT系统的部署，因此对持续集成和持续发布有丰富的经验。

每个团队都加入了一位构建专家，他主要关注在两件事情上：（和他的同行一起）构建持续发布的流水线；教导其他团队成员如何自动化每次系统变更，并让所有东西都放入版本控制系统（我们用Github)。但是持续集成不只是让所有东西都版本控制和自动构建，持续集成是一个开发实践。见避免...认为持续集成只是一个工具。它需要团队的承诺和纪律：将小的增量变更频繁地合并到主线；并一致认为修复导致应用程序崩溃的变更是最高优先级的任务。因此作为教练，我们关注在引入并维系这样的思维方式，并不断寻找改善下面事物的机会：

• 减少主线代码提交时间间隔
• 增加自动化测试套件的全面性
• 减少在服务器上构建所需的时间
• 减少每个研发人员在开发环境里执行测试所需的时间

研发人员已经习惯通过分支来处理组件团队的复杂性和串行开发，他们无法想象与其他缺乏经验的同事一起工作在主线上，所以把分支立刻清除被认为是不现实的。我们的做法是挑战分支的持续时间。团队从此开始只工作在两类分支上：长期存在的发布分支和"短暂"存在的特性分支。在减少特性分支的持续时间上我们花了不少功夫，使之从长过一个Sprint的周期（如果该特性不包含在产品增量中）减少到几个小时。有两件事起了极大的作用：一件是持续讨论分支的缺点并展示替代方案比如隐藏新功能或增量做改变；另一件是让分支"活着的时间"透明化。研发人员引入了一个代码审查流程，每当有新的小特性增量在特性分支上做了开发，为了合并这个分支到主线并删除这个分支，另外一个研发人员必须审核分支上的代码变更和执行代码合并。通常情况下，研发人员在开始新特性增量开发时要通过主要交流工具（Slack）与其他团队成员一起讨论这一步，并在变更实现、研发环境测试完成后请求代码审查。尽管从精益研发的观念看这是一个大的缺点，因为它增加了延迟成本并引入工作交接，然而这种方式至少是沿着改进的方向在走，增加了分支持续时间的透明性，也加强了团队中互帮互助的氛围。

在我离开的时候，分支的平均持续时间已经只有一天（有很多分支只有几个小时），虽然不是最优，但相对于以前的工作方式已经是巨大的进步了。

自动化测试

如果没有自动化测试，一次成功的构建仅仅表示应用可以被编译和组装。开发一个详尽的自动化测试套件包括单元测试和验收测试对于快速反馈至关重要，这也是持续集成的核心成果。见尝试...单元测试，尝试...验收测试驱动开发。

团队里有一个对测试即有知识又有热情的成员对我们帮助极大，因为她懂得敏捷软件研发中的测试是指测试在实质上的独立性而并非与开发分离。获得这种测试实质上的独立性是在开发之前就定义好测试，最好是通过跨职能团队（产品负责人或其代表，以及任何其他了解需求的潜在干系人）在工作坊中来讨论和澄清测试需求。见尝试...需求工作坊。在"LeSS事件"产品待办列表梳理中我会介绍我们的产品需求工作坊的流程。

开始阶段，我们让懂编码的测试专家创建自动测试套件来将手动测试脚本自动化，比如，使用Selenium将UI测试自动化。一段时间后，大家意识到这不是一个好主意，虽然在每次构建之后都有一些反馈，但是反馈太慢而测试极其脆弱，需要很多的维护工作。见避免...在UI上做测试。测试常常有因为有些UI或功能改变而产生的问题，团队成员需要不停地检查系统新的行为是否符合期望。这还不是最大的问题。这里我们最大的教训是团队里的一组人负责测试自动化同时另一组人负责实现新功能是灾难的根源 -- 这导致额外的复杂性、交接工作的浪费，以及知识分散。见避免...单独的自动化测试团队。我们引入结对工作来解决单一技能团队成员间的分离，使得之前懂测试的成员逐渐扩展了他们的编码知识，而懂编码的成员开始编写自动化测试案例。这不但使我们的测试转向更少的UI测试而更多的API测试，还提高了代码覆盖率。

另一个重要因素是为了减少最初的痛点 -- 大量的缺陷 -- 除了测试自动化外还引入了"停止并立即修复"的规则。见尝试...所有测试通过-停止并立即修复。把我们的构建流水线和我们的消息传递工具（Slack）连接起来，这样每当有分支合并到主线，构建就会启动并在构建结束时，一个测试通知会被发送到"通用"Slack频道。如果自动化测试套件里有测试失败，这个失败的测试信息会与触发构建的分支合并信息一同发布出去。面对这样的信息立刻有自愿者行动起来修复问题很快变成了团队文化的一部分，大部分时候会由感觉是自己的提交导致了测试失败的那个人来承担解决。

另外一个团队采纳的的行为是在修复问题之前为每一个新发现的缺陷写一个新的验收测试。这样，我们的自动化测试套件越来越大，我们对每次产品增量带来的构建都是可发布的信心也越来越强。一年后我们测试套件中的测试达到了1000多个，发布前的回归测试时间也从几周减少到了几个小时。

在修复缺陷或实现新功能之前编写（或更新）验收测试带来的另一个积极影响是，我们把Wiki或Jira中经常过时且零散的文档替换成了活文档，就象实例化需求（Specification by Example）中描述的那样。验收测试变成了可执行的需求规格说明书，也是永远更新的活文档，与代码在同一个仓库中保存和更新。

社区

对LeSS中的重要话题特别有热情的那些人会对导入带来巨大的影响。Natascha是我们最资深的测试人员，她是实例化需求（Specification by Example）的铁粉，把让团队的关注点从测试执行转向测试确认和测试设计作为她的使命。最重要的是，她拒绝成为所谓的测试主管因为她觉得成为测试瓶颈并没有什么意义。因此，她尽全力地去传播她的知识并培养团队对高效测试的理解。为了更有效地做到这点，她召开例会讨论测试话题，参会的是主要关注于质量保证和探索测试的团队成员（其他人也欢迎参加）。这些会议的成果主要是形成的共识，比如，怎样用Gherkin语言创建规格说明书，或怎样将规格说明书聚焦在测什么而不是怎么测。这些后来会被放在Wiki上与其他团队成员分享。她做的另外一件很棒的事情是向社区成员分发测试相关的书籍。越来越多的人对这个测试的"新方式"充满热情，并将这种热情注入到团队。这些实践也可见LeSS指南：社区工作。

除了测试社区，我们还有Scrum Master社区和架构社区。

Scrum Master社区是让Scrum Master们对齐和互相学习的好机会，也供大家分享和缓解他们在LeSS导入中遇到的挫折。跟其它两个社区一样，这里有一个单独的Slack频道，也是一个特别小的组，仅有三个Scrum Master和一个教练，后来增加到五个Scrum Master。人少让我们捆绑得更加紧密，本身也成为一个小团队。在所有团队站会之后，我们每天都有短暂的同步，但这不是Scrum of Scrum。我们不讨论团队的进度而是讨论在站会中发现的新障碍，对齐下个LeSS事件并讨论谁来作引导。大部分时间我们分享各自的观察并扩展我们的学习。我们互相交换Scrum的文章并组织会议讨论它们。特别是在开始时期，我会常常与新的Scrum Master们结对工作，先由我做会议引导再与他们讨论，然后让他们来引导会议并随后反思一些观察到的情况。甚至在Scrum Master们变得经验更丰富以后，我们还坚持了结对教练，与团队成员做定期教练对话。这是一个Scrum Master们发起的实验，目的是在团队成员和Scrum Master之间建立信任关系，使Scrum Master更加了解团队中的每个人，帮助他们应对新的工作方式。考虑到团队的分散性，这样每两个Sprint一次、每次一小时的对话无论是对团队成员还是对Scrum Master来说都非常有价值。

最后成立的是架构社区。

设计/架构社区是LeSS强烈推荐的社区，所以非常奇怪这个社区在半年多以后才成立。考虑到组织那时对架构的理解，我能够预见到人们开始时看不到建立这个社区的必要性。

作为一个习惯了瀑布工作和用离岸/近岸的"便宜"研发来维护现有系统的部门来说，他们的理解是，软件是可以被资深架构师"架构"好然后被"普通"程序员按照架构实现的。在我们团队里发生的关键意识转变是理解"敏捷架构源于敏捷地架构行为 -- 有实战经验的程序员架构师，卓越的代码文化，重视结对编程，培育高质量的代码/设计，敏捷建模设计工作坊，测试驱动开发和重构，以及其他代码实战行为"。见LeSS实验：尝试...思考'培养'胜于'架构' - 创造一个活着的、不断成长的设计。

这是一个非常漫长的过程，从与负责系统维护（组织中完全不一样的部门）的经理们开展许多讨论开始。通过将资深架构师把设计交给研发做实现（见LeSS实验：避免...设计交接给'码农'）的系统动态可视化，我们说服他们将近岸研发人员整合到团队中来。这些人开始时做缺陷修复工作，然后就被加入到所有的团队会议中，参与结对编程课程并随着代码审查流程的建立。他们被鼓励负责任何类型的实现，无论是新功能还是已有功能。从清晰地定义谁负责什么到整个团队集体负责产品的设计和质量，确实是一个巨大的转变。除了按需安排的日常结对编程和上面提到的代码审查流程之外，另一个帮助每个研发更好理解系统架构的关键因素是在每个Sprint计划会议中做试探设计工作坊。我会在下面"LeSS Sprint 计划会议"章节详细描述我们是怎么做的。

一旦理解到真实的软件架构会随着每次编程而演化，突然间就需要建立一个不一样的架构完整性方法，来取代以前那种每次实现之前创建好设计文档的方式。每个团队中最资深的研发人员想要经常聚在一起，分享在设计工作坊中所做的试探设计和使用的架构模式（见LeSS实验：尝试...架构和设计模式）。随着时间的推移，一些额外的会议涌现出来，它们不是LeSS事件但可以看作是架构社区会议。一个"架构对齐"会议在每次产品待办列表梳理之后的几天被安排举行，使得资深研发工程师可以一起探索和讨论新需求对大规模架构的影响。这对下个Sprint的计划非常有帮助。还有一个我们称之为"解决方案设计对齐"的会议在Sprint计划会议之后的几天举行，主要是用来对齐在Sprint计划会议2中单个团队试探设计的结果。我相信如果我们都在同地办公并在需要时采用联合设计工作坊（见Less实验：尝试...讨论更广泛的设计问题做联合设计工作坊），这些会议是完全不必要的。然而，因为离散的团队（甚至是多个离散团队）让开展有效的会议变得困难，这些作为额外的会议也可以说是非常有价值的。

LeSS中的社区并不只是作为学习和知识传播的支持系统而存在，它们也提供了一个理想的组织决策环境。在这里管理者们并没有妨碍决策的敏捷性（成为瓶颈），决定是由领域专家（无论他们来自于哪个团队）做出的。LeSS建议社区在他们如何工作和做决定方面达成共识（见LeSS指南：社区）。在我们这三个社区里，我也非常惊讶地看到他们在没有正式的决策协议的情况下做得如此成功。我相信，这与以下事实有关，即团队成员通过早期参加社区活动建立了非常深层次的相互信任和尊重。在这样的环境中，社区基于每个人同意来做决定就变得容易。（同意意味着没有人会反对这个想法，而共识是指每个人都支持同样的想法。即使在这样的环境中，那也不太可能发生）。

LeSS 事件

图8: LeSS 框架

我们的LeSS Sprint 仪式

我们从一开始就建立了所有的LeSS事件，但是如你所见，因为我们的团队是分散的，这使我们在实现这些事件本应具备的关键透明性和检视上变得极其困难。

我们所有团队都从两周的Sprint开始：所有团队同时开始和结束一个Sprint（见LeSS规则：同产品级的Sprint）。

LeSS Sprint计划会议

跟其他LeSS事件一样，Sprint计划会议因为有远程参与者而非常具有挑战性。开始，所有的团队成员都参与Sprint计划会议1，时间不超过30分钟。然而，随着团队数量的增加，后来只派团队代表参加。见LeSS指南：Sprint计划会议1。我之前在"唯一的产品待办列表"章节说过，在Sprint计划会议之前我们一直有一个"业务对齐"会议。在那里，业务代表、"业务PO们"和其他干系人一起讨论和对齐产品待办列表梳理的结果。最后，（后来的）产品负责人决定所有条目的优先顺序并在Sprint计划会议1中由他或其代表向大家展示这个列表。通常情况下，这进行得非常迅速，因为团队会自愿拿走他们梳理过的条目；但在有些情况下，当那些条目并不在前列，如果其他团队没有产能，团队也会挑一些不熟悉的条目。这时，团队代表会寻求在Sprint计划会议2中以及接下来的整个Sprint中跨组合作的机会。他们会召开一个多团队的Sprint计划会议2，这样所有相关团队就可以有共享的设计会议并协调共享的工作。

因为有分散的团队，Sprint计划会议2不得不通过电话会议来完成，使其更加困难。在团队重组之后，这个情况得到了极大的改善：大部分成员坐在一个房间，在一块白板面前，仅仅少数几个成员远程加入。这些团队在不同的时期尝试了许多不同方式，比如怎样改进Sprint计划会议2。最终，我观察到每个团队都有自己喜欢的方式来进行这个会议。有些团队喜欢把自己分成2到3人的小组，让这些小组来把每个PBI拆分成任务；然后他们再聚一起展示所有的任务，让整个团队来重新估算并评估所有的条目加在一起是否能放在一个Sprint中完成。另外一些团队倾向于把每个PBI逐个查看并确认需要完成这些PBI的所有的任务，也用小时数作估算，用这样的方式直到他们都"满了"。虽然每个团队开会的方式不一样 -- 这也是LeSS鼓励的做法 ，因为团队应该拥有自己的流程而不是租用别人的流程 -- 所有团队都关注在对约定的Sprint待办列表达成共识上。无论使用哪种方式，作为Scrum Master和教练的我们都意识到，团队对他们的"预测"充满信心并为某些不可预见的工作保留一些缓冲是多么重要。我们注意到当团队挑选比最初预测的更少的工作时有一种强大的积极影响，导致团队士气和绩效的提升。

产品待办列表梳理（PBR）

我确信在整个导入过程中，产品待办列表梳理是LeSS事件里改变最多的。一开始，我们（错误地）计划了每两周一次2小时的会议，只有团队成员和"业务PO"参加。业务分析师（也称为IT"产品负责人"）与"业务PO"一起提前准备所有的产品待办列表条目。所有的条目在PBR中展示，团队主要关注在问需要澄清的问题和估算条目的大小上。

所有团队都有在每个Sprint后剩余一些未完成条目的情况，这在团队回顾会议上经常被讨论，其中一个根因是跟使用的梳理方式有关。我们根据咨询教练的建议为PBI引入了一个固定结构：一个用户故事和史诗（Epic）模板包含了业务价值、用户成功场景、假设、验收测试和开放问题。就绪的定义（Definition of Ready / DoR）也被引入来保证未就绪的条目不会在Sprint计划会中展示。除此之外，业务分析师同意采用遵循Gherkin语法（Given...When...Then）的例子来写下验收测试。仍然，这并没有为当前的情形带来多大的改善。许多PBI或用户故事在Sprint结束时并没有完成，是因为一开始他们都没有被完全理解。我们还有很多"回旋镖"（一类在发布之后两个月内又回炉重做的PBI）。随着时间的推移，人们开始意识到，无论在一开始采用了多么好的模板，最能帮助获得真正理解的是在把事情写下来过程中的讨论和反思。不止这个，我们还注意到，我们作为一个团队可以设计出比业务分析师和业务人员独自在一边做出的更好的解决方案；一个让每个人都能理解真正问题并合作解决的机会。鉴于此，在产品待办列表梳理上，我们慢慢地从讨论技术性能规格说明和估算工作，过渡到讨论业务尝试达到的目标或解决的问题，一起定义在一个Sprint里能够实现的目标范围或是帮助我们迈向目标的范围并决定潜在的解决方案。业务分析师仍然负责整个PBR的运行，但后来，我们给团队成员更多的机会来合作定义范围和设计解决方案，而不只是对提前确定的关键实例提出问题。一种有效的方式是在业务分析师展示完一个清晰的实例（"快乐路径"）之后分组讨论，让团队成员们分组寻找边界并尝试提出更多的其他实例。理想情况下，每组都在同一个地点，但有些时候我们通过视频电话会议一起用在线工具（比如wiki网页）解决。之后，我们会评审这些不同的实例，并约定随后会被一起自动化的关键实例。

通过这种转换和不同的方法，我们也认识到业务分析师和"业务PO"并不能对所有讨论出来的问题都有答案，所以我们开始邀请业务方面的专家参与进来。

重要的是要记得整个带有这些伪"PO"们的模式都是错误的，它既是强加于我们的，也是反映了我们对Scrum和LeSS的许多误解。

LeSS Sprint 评审

遵照LeSS的建议，我们建立了一个所有团队参加的产品Sprint评审。由于组织中分散团队和多地点的约束，我们只能通过视频会议来进行这个事件，以便来自不同地方的所有团队成员和业务代表们都可以参加。作为教练和Scrum Master，我们很高兴为所有团队提供了一个共同的Sprint评审，以至于所有参与者都能聚焦于整个产品。通过持续集成实践，团队在Sprint中就让他们的干系人评审已完成的条目以尽快得到反馈。因此大部分PBI都在Sprint中已经被产品负责人和业务代表们评审过了。在Sprint评审中，我们更关注于产品全貌，讨论我们实现了哪些又错过了哪些。不幸的是，由于上面提到的组织约束，我们的Sprint评审缺乏动手检视的特征。

在LeSS中，如同在Scrum中，Sprint评审是关于动手检视产品，并在团队、产品负责人和干系人之间进行深度会谈，以共同了解产品、利润驱动因素、战略客户、业务风险、新的问题和机会，等等。在我离开时的一个改进重点是找到方法允许干系人、产品负责人和团队成员们在多站点环境中对工作的软件进行交互并检视新产品，比如用多站点评审集市的形式并允许对检视中的发现和下个Sprint的方向进行讨论。

LeSS 回顾

另一个有影响力的改进机会是使用整体回顾，就象在第三本LeSS出版书中描述的那样：见LeSS指南：改进系统。很长一段时间里，我们在每个Sprint结束就只有一个团队回顾，因为没人认为额外的会议有任何价值。但是随后人们认识到只有让每个团队的每个人都参与，才能解决系统性问题。改进代码质量或更多业务方参与这样的事情，如果所有工作在上面的团队都共同努力，影响会完全不一样。起先，Scrum Master在团队回顾之后有一个同步会议来对齐不同团队承诺的改进措施，但后来他们认识到他们不一定能说服他们的团队成员来执行这些其他团队决定的措施，为此他们挣扎了很久。最后，我们引入了"整体回顾"，来自所有团队的成员都会参加，有时候（不幸的是这并不是一直）管理者也会加入。很多重要的改进在"整体回顾"上被讨论和解决，比如在产品待办列表梳理中引入实例化需求的改进。缺乏架构完整性的问题也在整体回顾中被解决，设计/架构社区从"解决方案设计对齐"和"架构对齐"中被创建出来，以支持得到联合的设计对齐。为了解决系统级的问题，就需要和管理层一起审视整个系统，讨论系统动态和心智模式，这个步骤我们已经开始，但在整体回顾中仍然没有成为标准。

发布Sprint

因为我们没有单独的"完成之外的部门"，所有不在完成的定义（DoD）之内的工作需要在发布之前被研发团队做掉。开始时，我们每两个月一次发布，所以每四个Sprint就有一个发布Sprint，这个Sprint里几乎所有的工作都是与完成之外的工作相关。这也符合LeSS实验：尝试...在Scrum团队中包含一个发布Sprint。当然我们的目标是减少完成之外的工作并改进DoD，以至于不再需要一个发布Sprint。在我离开时，完成之外的工作已经减少到只需一个团队在发布Sprint中去做，每次发布都由一个新的团队来负责，而其他团队大部分都工作在移除技术债上面。

结论

这个故事展示了应用LeSS原则、规则、指南和实验来在Sys IT部门改进和形成一个更有适应性的组织，使Sys商店得以成功实现，即使有一些组织约束阻止了我们用推荐的方式导入LeSS。就如同开篇里提到的，这并非关于怎样正确导入LeSS。通过（1）当许多团队创建一个产品时引入LeSS规则来去除反适应的元素和（2）通过移除组织结构和政策逐渐改变组织，我们在适应性方面取得了重大改进。持续对系统动态的反思和管理者支持为能持续改进做必要的组织改变，支持和指导了我们通往低切换成本适应的系统优化目标。

应用LeSS框架规则，比如实现唯一的产品待办列表、唯一的产品负责人和全体团队共享Sprint计划会议，有助于保持对产品整体的关注，并在支持自组织和内在激励的同时对团队正在进行的工作提供了可见性。有五个分散团队、许多干系人在不同的地方，这种情况的共同评审非常具有挑战性。即使缺乏真正的Sprint评审应有的深度会谈和对齐，这仍然有助于聚焦在产品整体上。整体回顾使得我们解决更大的组织变革问题，这在团队层面不会得到多少关注。除LeSS事件以外，许多LeSS推荐的指南和实验的采用对软件开发工作也产生了巨大的积极影响。

在我看来，建立比如"停止并立刻修复"之类的规则，并成为我们的文化，对我们能够在短时间内交付缺陷更少更好的产品有极好的影响。我确信，这是基于建立了技术卓越（就像测试自动化、持续集成等等），否则，是不可能以简单、快速、灵活的方式改变产品并快速获得反馈的。没有这些，"停止并立刻修复"是不可能的。

在我就职期间，有三个关键的组织方面使文化发生了转变：移除组织壁垒和层级，去除团队内部角色（所有团队成员在一起工作，每个Sprint结束时创造一个已集成的产品增量）和抛弃了所有为"特殊人群"召开的特别会议，让每个人更紧密也更贴近每个迭代交付高质量产品的目标。移除政策和会议，聚焦在整体产品和整个系统是让我们能够改变文化的主要因素。见LeSS指南：文化跟随着组织结构。我觉得另外两个有利因素是社区和教练（对话）。

回想起来我最大的收获是关于导入LeSS的方式。我们逐步导入LeSS组织架构的方式是由于受到我们组织约束的限制而被迫为之，很幸运我们能够实现上面所述的改进，并没有制造出更多的问题。在大多数情况下，以错误的组织结构开始增强了案例中提到的拉曼组织行为法则描述的动态。通过（1）一开始就教育每个人了解背后原因，（2）如预期从一开始就将组织设计落实到位，和（3）得到那些深入理解LeSS的组织含义、不遵循拉曼组织行为法则的高层管理团队的大力配合、达成共识并获得支持，我们本可以更快取得更多进展，让每个参与其中的人更容易些。

致谢

我想要表达我对Mark Bregenzer最诚挚的感谢。他是德国第一位LeSS培训师，从我见到他第一天起他就是我的导师，他不仅帮我构造和设计了这个案例，还在我作为大规模Scrum实践者、教练和培训师的成长路上产生巨大的影响。我还要感谢Craig和Bas在我写这个案例过程中给我的有价值的反馈和支持。最后一点也很重要，感谢在这个转型的旅程中参与和陪伴我的每个人，特别是我夫人，Oksana。如果没有你们所有人，我什么也写不了。