德国大保险公司（化名）的巨型LeSS转型尝试（上）

介绍

本案例研究描述了一个部门从最初采用Scrum到LeSS Huge的转变。迈向LeSS Huge的那些步骤包括但不限于：

• 部门的重新设计

• 建立需求领域

• 引入LeSS事件

• 引入描述需求的新方法

• 重组产品待办事项列表

本案例研究首先简要介绍了背景，试用阶段（2016年夏季-2016年12月，当时我不在场）以及最初采用Scrum的过程（2016年12月至2017年3月），在此期间我曾经指导了该部门。

LeSS的大规模采用始于2017年4月，并进行了更深入的描述。我一直在全职工作，直到2017年6月。此外，我还吸收了开发主管和其他成员在2018年夏季之前的反馈。

目的

本案例研究的目的是对部门中试图实施 LeSS Huge 有一个批判的视角。尽管已经取得了很多积极的成果，但案例研究还是有目的地强调了问题，并讨论了原因和结果，因为与“平滑”转型相比，这通常会使人们对组织变革的动力有更多的了解。因此，请勿将此描述视为“最佳实践”;）

背景

大多数人都有某种形式的保险。为了更好地理解这个案例的背景，我将以奥托（Otto虚拟人名）为例说明一些相关方面。奥托拥有几项保险，例如人寿保险、家庭保险和旅行保险（保险供应商Sampo提供的）。奥托想购买一辆新车，然后去他选择的汽车经销商处。他买到了梦寐以求的汽车。另外，作为销售套餐的一部分，经销商提供了各种汽车保险。这就是本案例研究中称为B2B2C（车辆保险）产品的内容。奥托购买了责任险，并高兴地回家了。他希望一目了然地查看所有保险，为此，他登录了提供此视图的保险公司网站。提供查看的数据来自于“公共数据库 common database”（本案例中我起的名字）。

Terra部门隶属于一家超大型的德国保险公司Alpha1。Terra负责产品的开发及其运营。他们在其职责范围内创建了两种类型的产品，如下所示分别为“B2B2C”和“B2B”的车辆保险。

B2B2C产品是德国的车辆保险，而B2B产品是代理商的国际保险服务。B2B2C产品是基于现有车辆保险产品的变种，此外，B2B2C产品使用了一个公共数据库（包含企业和消费者的数据）。

现有的（此处称为“ B2C”）车辆保险产品开发以及公共数据库不在本案例研究范围之内。

Terra在德国和印度的两个办公地点约有250人。在这250人中大约有150人做产品开发，其他人则是支持功能和“测试工厂”。

另一个部门包括产品管理、业务分析和协调人员（我称其为PM＆BA＆CO）。除了市场分析、定价、定义营销活动之外，业务分析部门还负责一些高层次的需求工作，然后将其移交给“协调”部门。

据我了解，该协调部门负责按优先级排序需求，并以发布的形式构建“可销售的特性集”。这些高层次的需求移交给Terra。此外，该部门还负责“接受”Terra提供的功能、特性和修改。这些活动集中于B2B2C产品。

PM＆BA＆CO部门是在LeSS实施的直接范围之外。但是，如稍后的案例研究中所述，这些部门之间的工作方式也发生了一些变化。

该公司有很多层级，PM&BA&CO和Terra之间的共同管理层已经在几个层级之上了（译者注：即PM&BA&CO和Terra都汇报给同一个更高的管理层）。坦率地说，高层管理人员并不关心Terra的组织方式，因此Terra内部的管理人员很少得到高层管理人员的支持。

Terra自己对B2B产品的客户需求进行分析并确定优先级。该部门的目的是开发这两种产品。

试行阶段

该部门对两个独立的子产品进行了单团队Scrum和工程实践的试验。这些团队由一个PO，一个Scrum Master和一个开发团队组成，每个团队对Scrum进行了大约6个月的试用，并取得了积极的成果。积极的反馈以及其他因素（例如，需要更高的灵活性、对变化的响应能力、业务价值的增加、降低部署的风险、提高产品质量）引领整个部门的敏捷之旅开始了。

该部门建立了一个“敏捷指导联盟”（Agile Guiding Coalition AGC）2，其目的是通过例如定义方向，决定使用哪些框架，帮助团队及消除障碍来指导和支持该部门。AGC由Terra的高级管理团队，敏捷教练，架构师，Scrum Master和产品负责人组成。

最初的“Scrum”实施

组织

最初该部门分为以下职能部门：

• 设计

• 编码

• 测试

每个团队都有一个团队负责人（TL3）和一个业务负责人（BL）。最上面是项目经理（PM）。此外，还有一些支持功能，例如架构，版本管理，缺陷管理，运营和其他一些团队。

在最初采用Scrum的开始，我们移除了职能部门并建立了新的结构。

该结构由管理层设计的、十四个分布的Scrum团队（跨职能，但仅限于一个组件）。每个团队都有专门的产品负责人（PO）并且部门有一个整体的首席产品负责人（CPO）4。未改变其他部门（产品，架构等）的结构。

该结构的设计无需任何LeSS专家指导。这项变革是自上而下的一次性5引入的，没有人心甘情愿，也没有得到Terra6部门的高级管理层自上而下的支持。

我开始辅导时，新组建的组件团队是第一次见面。在启动会议上，项目经理解释了变革的原因并传达了方向。

在这个阶段AGC决定：

• 新组建的团队在新架构中工作的日期

• 2周的Sprint节奏

• 具有基本的Scrum仪式和（每个Sprint）（产品待办列表）梳理工作坊（PBR）的框架

• 产品级的Sprint评审，其中志愿团队向其他团队、高级管理层、产品管理人员介绍功能

• 单独的系统测试功能

• Scrum of Scrums

• 产品负责人创建：

• 隐含的团队列表的集合，合并到一个“产品待办列表”（PB）中

团队创建：

• 所有团队共同的完成的定义（DoD）

• 多个社区7 如Java社区

• Scrum Masters创建：

• Scrum Master 社区8

接下来发生了什么…

在最初采用假 Scrum 时，已经对即将发布的版本（6.5）的需求进行了分析和“设计”。遵循旧的工作方式，在Jira中记录了开发和测试的“剩余”工作。这些工作条目没有有意义的估算，这使得发布计划和进度跟踪实际上变得不可能。即明显缺乏透明度。即使工作条目与用户故事9背后的原始想法相距甚远，这些工作条目还是被称为“用户故事”（开发人员和客户之间的直接对话）。

为了弥补损失，发布管理功能创建了进行跟踪和预测的“热图”，所谓的“ PO”（实际上只是业务分析师）可以帮助了解情况。早期更新是每周发布，随着发布日期的临近（“热量增加”），发布经理每天都会进行更新。

由于团队只是组件团队，而不是Scrum中可以端到端完成所有事情的真正的开发团队，因此团队之间的依赖性非常惊人。10

由于未解决的开发缺陷在组件团队之间频繁发生，因此工作经常完全停止。很难找到可以修复该缺陷的团队，因此修复需要很长时间。

现有的构建系统确实提供了延迟的反馈，并且集成是繁琐的。回归测试是手动完成的，仅在发布结束之前才可以进行系统测试。

为了快速解决缺陷处理的问题，AGC召开了一次集中的协调会议，即“ Scrum of Scrums（SoS）”，这很有帮助。

注意：SoS会议并没有解决缺陷推脱的根本原因问题，即组件团队结构，它只是对此做出了反应。

如实验“尝试……Scrum of Scrums”中所述，该会议在短期内有助于处理缺陷。SoS使用一个物理板从所有团队中选择条目，并查看发生了什么。这是针对团队的团队的一次会议11。每个团队确实派出了一个不是Scrum Master 12的代表。每个Sprint或每两个Sprint 13团队代表轮换一次。

一方面，SoS并未解决该问题的根本原因，其中包括

• 相互依赖的组件团队的组织结构。

• 缺陷管理团队的存在。14

• 缺乏合适的信息系统。

如果组织希望创建一个更好的环境，从而消除那些阻碍因素，建议避免SoS 15这样的集中会议。

由于缺乏稳定的产品维护，特性开发是通过“冻结”期16的代码冻结而结束，该时间段与新版本发布之前的用户验收测试时间段并行。

每个团队根据团队自己的待办列表工作17。所有这些列表都作为所谓的“产品待办事项列表”存储在一个工具工件中，但就工作和团队而言，该部门实际上并没有一个共同的待办事项列表。那是一种幻想。相反，他们将许多与不同团队相关的“隐性待办事项”存储在一个工具中。

由于是组件团队，所以存在大量的交接、隐藏的待办事项、大量的协调开销以及其他原因，直到开发的中间时间点，人们才意识到并非所有内容都可以及时交付。

因此，为了应对这种延迟，项目经理最终对以客户为中心的高层次需求列表进行了排序。此操作创建了一个公共PB（在一个简单的电子表格中），并将重点放在了部门上。现在，其他所谓的“PO”分析师和他们的团队也牺牲了“他们自己”（不是很关键）的工作，并帮助其他团队满足关键的需求。

在此版本的结束时，仅交付了非常基本和关键的功能。

总体而言，当使用缺陷数量作为代理度量标准时，该版本的技术债越来越多。

此外，即使有些组件团队尚未完成关键内容的实施，他们也已经开始考虑下一个版本。这偶尔引起了激烈的讨论。

此时很明显，我们将重新设计Terra部门的组织结构，从最初的产品待办事项列表梳理（PBR）开始，但是这些团队的Scrum Master进一步推动了组件的方案。

经验

在与项目经理进行反思AGC的当前状况时，这种组织结构是不可持续的，这很明显。实际上，许多人意识并了解到协调工作是巨大的，由于隐含式的列表的使用，工作分散了，因此大家希望拥有更多独立工作团队的结构。

此外显而易见的是，需求是以不同的方式描述的，PB需要不同的结构，及不同的工作模式来维护PB。

巨型LeSS实施

问题与背景

我相信，随着最初采用的虚假Scrum和“幼稚的规模化” Scrum的方式，项目经理对于缺乏透明度和需要跨团队协调感到非常沮丧。我认为，采用LeSS Huge的诱因是**“对未知的恐惧小于对已知的恐惧”**。

结果，并非如此决定实施巨型LeSS，因此忽略了关键的LeSS实施原则，且在LeSS指南入门中的第一步执行时花了太少的精力。

因此，我提出了在某些约束条件下我认为最有意义的措施。从这个意义上讲，部门迈出了更具适应性的第一步。

LeSS实施原则

LeSS实施有三个原则18，这对于组织的LeSS实施非常关键：

• 深而窄 高于 宽而浅

• 自上而下和自下而上

• 采用志愿服务

深而窄 高于 宽而浅

基本思想是将变革限制在一个需求领域内（Requirement Area RA19）或一次约50人，学习和试验一段时间，然后在进行下一个需求领域。

这还没完成。在最初使用（仿造）Scrum时，该部门的所有开发都发生了巨大变化。这一团糟，我认为该部门处于混乱状态，需要迅速采取行动。此外，由于有第二种产品（B2B），因此受到“巨型LeSS实施”影响的人数并不多。从这个角度来看这仍然是一个（产品）边界的案例，不应将其视为典型的LeSS的实施。

自上而下和自下而上

同样由于采用纯粹的自下而上，这并未遵循LeSS的原则。这是整个Terra部门，但是PM＆BA＆CO部门的存在证明了，此变革没有自上而下的支持。实际上，高层管理人员已经做出了几项决定，在此之后的几个月中，我已经离开了组织，这表明他们缺乏对这种变革的支持（请参阅结论部分）。

采用志愿服务

在“Scrum”实施之初，很少使用志愿服务。到开始采用LeSS Huge时，部门越来越多地采用志愿服务的概念，尤其是在团队自设计工作坊中。该工作坊为高级管理层建立了继续和促进志愿服务所需的信心。

LeSS指南：入门

本指南中的第0步是对所有人进行教育，这几乎被忽略了。激励项目经理按要求投入足够的培训是非常困难的20。

……然后我们就开始……

通过最初（假）Scrum的学习，AGC决定做出一些根本性的改变。作为教练，我从AGC那里获得了很高的支持，创建了一个产品待办列表（PB），并且需要进行的澄清和结构的改变被视为实现这一目标的“必要且痛苦的操作”。因此，AGC对部门所需的结构变更的阻力很小。

（LeSS的）实施开始于一个初始的产品待办列表梳理工作坊（PBR）21。

该决定引发了一些关键问题需要事先进行澄清，例如：

• 产品是什么？

• 组织结构是什么？

• 高层次的客户需求的最初优先级是什么？

注意：高层次客户需求的初始列表由PM＆BA＆CO排序的，我们避免创建特性优先级类别。这些需求很大，有些需求可能会在多个版本中实现。除了PM＆BA＆CO，还有架构师22和团队，每位都提出了他们的需求清单，来作为此次工作坊的输入。

自我设计团队工作坊的准备，产品及其领域的定义以及最初的产品待办事项列表梳理工作坊大约花了三周时间。一个内部热心的专职教练为高级管理层，部门成员和其他必要的人员之间的大多数讨论提供了引导。

该部门的各个成员都非常怀疑能否在几天内完成此更改。因此，我想强调一下，实际事件彼此之间迅速发生，而在这之间没有间歇：

• 周一下午：自我设计团队工作坊

• 周二和周三上午：新架构中的初始产品待办事项梳理工作坊

• 周三下午：与新的APO进行PBR结果分享会议

• 周四：按照常规的Sprint节奏进行新架构中的Sprint计划1和Sprint计划2。

产品定义与需求领域方面的问题

产品定义工作坊发现该部门实际有两个（以客户为中心）产品：

• B2B2C产品是仅为德国市场的车辆提供保险

• B2B产品是面向代理商的国际车辆保险服务

B2B2C产品占据了部门的主要工作量和重点，而B2B产品处于起步阶段，在国际市场上具有增长的潜力。

从B2B产品开始，成立了一个特性团队，拥有一个真正负责人和一个Scrum Master。新成立的开发团队位于印度同地协作，而PO则位于德国。因此，B2B产品通常被排除在以下讨论之外。

注意：所有产品均基于相同的代码库，并且从概念上讲，它们基于相同的车辆保险产品23。换句话说，B2B2C产品和B2B产品都可以视为该基础产品的变体，该基础产品是在不同部门开发的。但是，由于组织边界限制了产品定义，因此定义了这两个产品。

B2B2C产品由10个团队组成24，“保险公司业务模型”25大致分为三个需求领域RA：

• 合同承保（5个团队）

• 合同修改（3个团队）

• 索赔（2个团队）

对所选设置的反思

为了优化适应性并在全球范围内更可能发挥最大价值，LeSS Huge框架规则之一是每个需求领域的团队数量都在 “4-8” 之间，因此这就减少了与团队数量相关的产品待办事项列表的份数。Terra部门的结构违反了此规则，因为有两个需求领域少于4个团队（一个需求领域有3个团队，另外一个需求领域有2个团队）。

合同修改RA和索赔RA中的那些团队完全不了解承保RA中的条目。如果产品负责人想要调整，以便更多的团队专注于承保、修改和索赔RA团队无法做到的事情（如果不先了解它们），他们将无法适应并且将被困在原始RA中的、从全局角度来看可能较低了需求条目的价值。项目经理已理解该问题，但出于以下所述的原因，决定从此结构开始。

原因之一是该选择支持了分为三个区域的现有PM＆BA＆CO部门结构，并且此更改确保了在外部接口方面的更平稳过渡。这使APO可以在其区域内自主工作。换句话说，由很大一部分于产品组仍以传统方式进行结构化（因为这只是部分的LeSS实施），因此考虑到政治力量，选择较小的RA是折衷方案，以帮助与传统组织保持一致。

另一方面，项目经理认为，将来还有理由将这两个领域合并起来（从APO的角度来看），开始他相信，如果APO可以在其新角色上更加坚定，一个人就可以处理这两个领域，其次，一个APO表示了继续前进的长期愿望，因此无需再次填补这一职位，而是将未来的两个领域结合起来。

另一个问题：放开每个团队一个PO的原则是APO候选人的又一大步。因此，寻找APO的讨论耗时好几周26。最终，产品负责人找到了三个合适的APO，他们感觉比较舒服（对于认知负荷、愿意尝试和学习新结构的方面）对于拥有一个领域并在每个领域和多个团队工作。

自设计团队工作坊的问题

这是Alpha公司历史上的首次允许团队自组织，Terra部门挑战现状并获得了成功。这项活动给部门中的许多人带来了动力，几个月后效果仍然很明显。

Terra的所有开发人员包括印度的开发人员都参加了此活动。印度的开发者同时在本地也进行了自组织。

根据先前解释的前提条件或约束条件，项目经理支持开发团队以自组织的方式进行重新组织。

工作坊的准备

为了准备自设计团队工作坊，一小组代表和教练（不仅是经理）创建了提供客户价值所需的所有技能的清单（请参阅下一段），并准备了一组边界条件，这些条件将帮助实现工作坊的目标。

边界

图示的团队布局模板用于提供边界，以支持组建以客户为中心的特性团队

除了团队布局模板之外，我们还提供了以下边界：

• 团队必须在同一地点

• 团队必须是跨职能的（即业务，技术，测试）

• 团队必须是跨组件的（技能，例如门户，富客户端，文档或Orga工作流）

• 团队人数为5人到9人

• 团队中有敏捷爱好者和敏捷怀疑论者

注意：在理想情况下，团队成员将能够独自完成准备工作，他们将设定自己的边界，自己的计划，并且不需要预定义的团队布局模板。

但是，考虑到当时所有的限制因素和团队的不成熟，教练们建议提供这样的界限。这些边界和工作坊的准备必须获得AGC的批准。

工作坊的执行

工作坊的日程安排如下：

每个人都有一个预先打印的名牌（名字，颜色表示的核心技能 - 业务、技术、测试）和不同颜色代表能力的级别。主持人确保缺席的同事由队友代表。然后要求人员将其名牌固定在团队布局模板上，以说明新团队的设置。

回顾回合中，每个人都可以审查和挑战其他团队的设置。

工作坊结束时几乎实现了所有目标。尤其值得注意的是，所有团队实际上都是跨职能、跨组件的且位于同一地点27。与以前的组织设计相比有很大的不同！

德国团队的自我设计的同时，印度的开发人员也成立了特性团队。组建了一个团队来创建（很小的）B2B产品，另一个团队加入了新成立的“承保”RA。

这里观察到几个主要问题。

• 理念是将运营工作分成一个独立的团队（在RA之外），该团队不用遵循Scrum周期（例如，每月关闭财务系统、回答客户和用户问题的这些任务）。但是，在工作坊召开时没有发现团队负责人，而项目经理正担任这一职务。由于团队负责人是故意不出席自我设计工作坊的，因此该团队的人员配备未达到可以运作的水平。结果，人们决定将运营的任务保留在开发团队中（就像以前一样）28。

• 对于任何愿意举办这样工作坊的人来说，重要的是要了解还有另一个挑战几乎导致工作坊失败。很少有人能按照指南来创建团队。人们被困在自己的观点和立场上，这导致了死循环。即使经过几轮让人们试图自己解决冲突的努力后，也没有解决方案。在Scrum中转型自组织团队的敏捷性原则时，这是很常见的事情，人们没有如何独自解决矛盾情况的教育或经验，教练和Scrum Master也都没有想到。在之前的传统管理模式中，由不同的管理者来做这样的决定，使得普通的人感觉没有权力或能力来做自己的决定，并在冲突中工作。只有通过APO和教练的密切合作，才能最终找到解决方案。

产品待办列表的问题

本节包含两个主要部分：产品待办列表及其工具。

产品待办列表

在LeSS Huge中，只有一个产品待办事项列表，其中每个条目都恰好属于一个需求领域（RA）。因此，每个需求领域只有一个领域待办事项列表。29

由于存在三个RA，因此PB包括这三个需求领域Backlog，每个Backlog由一个需求领域产品负责人 Area Product Owner（APO）负责。

对于Terra部门来说，创建一个以客户为中心的PB是一个巨大的挑战，而该PB注重结果而不是产出。

即将发布的版本和下一个新版本的主要重点是为新车制造商（我们称为保时捷）提供保险解决方案。这项巨大的需求被立即分解为三个RA，而承保则需要先进行，而修改和索赔均在此基础上进行。30

此外，与“保时捷”讨论的是，整个解决方案将有两个主要步骤。第一步将集中在两个系统（保时捷和保险公司）的复杂技术集成上，只完成最小集合的特性。这些不会进行商业的发布。第二步将包括商业发布所需的所有特性。很快就可以看出，将迈出第三步，因为商业发布并不需要某些特性和功能，然而稍后必须包含这些特性。31

这就形成了以下的框架，代表了PB中的高层次的需求：

每个较高层级的条目（如6.5）都非常大，为了达到每个团队每个Sprint可以完成四个条目的要求，有必要引入一个中间级别。

重要的是要注意，例如“保时捷：集成”主要是一个粗粒度巨大的类别或是“一桶”条目，而不是一组固定的要求，即这不是需要全部完成的 “大批量”。相反，如果各方在分拆过程中意识到现在不需要某些功能，会在后面将其转移到了以后的版本（桶）中，例如保时捷：发布。32

因此，PBI被分为三个级别（有关内容的详细说明，请参见需求处理部分）。

• 第1级：大的、粗粒度的需求或需求桶（想法：通常可以在版本内完成，如果开始需要多个版本，则有人创建需求桶）

• 第2级：中等要求（想法：可以在版本内完成）

• 第3级：小的（细粒度）要求（想法：可以在Sprint中完成）

产品待办列表工具

LeSS指南中对于大型产品待办事项的工具是“仅使用电子表格spreadsheet和Wiki即可。”因此，没有“跟踪工具”（例如Jira）或所谓的“敏捷管理工具”（例如Rally）。为什么？

• 这些工具包含并推广报告功能，从而加强了传统的管理报告和控制的行为。

• 这些工具支持并加强了传统的大批量到小批量工作分解结构和流程，其中一个独立的业务小组来决定（大尺寸和大批量）的主要条目，然后将其推给开发团队，以较小的规模进行工作。分批这只是传统管理而非精益管理，通常使用新的术语，例如“史诗”和“故事”。

• 当没有任何有意义的改变时，工具只是传达了改进或敏捷转型的表面。“敏捷行话”工具与成为敏捷没有关系。

• 他们经常给团队强加不灵活的术语和工作流，从而剥夺了流程所有权并限制了改进。

• 这些工具可以使工作复杂化而不是简化。

• 他们通常需要进行大量的自定义、集成和持续更新的任务，从而导致创建另一个开销很大的浪费角色，例如“Jira秘书”或一个假的“Scrum Master”或“产品负责人”。

Terra部门未遵循该指南，而是决定

• 第1级条目使用电子表格（spreadsheet）

• 第2级第3级条目使用Jira

该电子表格还用于与PM＆BA＆CO部门的沟通（还用于重新计划和报告），因为他们仍在使用传统的模型。随着时间的流逝，Terra与PM＆BA＆CO部门之间的合作得到了改善，从而使这种想法成为现实，对话也发生了转变，以统一的看法并理解“大局”。

最大的问题之一是PM＆BA＆CO的一位高级经理并不了解（需求）桶的概念（以及工作方式）。这也导致了频繁的争论和无用的讨论，即使会议室中的所有各方都同意并知道这些条目的情况。

另一个自我产生的问题是电子表格和Jira保持同步，并使Jira中的数据可维护和保持一致性。这需要大量的手工工作，并且从根本上证明了整个发布管理支持功能的存在性（请参阅发布管理一章）。

使用Jira的原因是模糊的，我只能猜测。首先，一个原因是，Jira已经从传统的管理方法中就位了，它已用于缺陷管理以及其他各种事情。其次，Jira允许传统管理思想33驱动的“控制”类型，这意味着项目经理可能没有足够信任人们，并希望拥有控制权的选择。

由于Jira是不可协商的（对于检视与适应而言更是如此），因此教练的目标是最大程度地减少该工具造成的损害。结果，产品负责人团队、教练和支持人员参与了一个新的Jira项目的引入，在昂贵的Jira工具专家的广泛帮助下，包含新结构的该项目的工作流程大大简化了。

Jira列表（不能称为真正的LeSS产品待办事项列表）仅包含中小规模的PBI、估算值、上层条目信息、设计信息的链接和注释等。

Jira为每个RA创建的发布烧起图仅提供了一般性的报告。

此外，发布管理功能从工具收集数据而不是从APO收集数据存在风险。最初，这会引起了一些额外的摩擦，尤其是当发布管理充当APO状态报告的“控制者”时。但是，经过几次Sprint，风险得以消除，并且发布管理功能就放弃了这种“控制”的活动。

尽管项目经理坚持使用Jira，但Jira显然是虚假的PB工具，也是功能不足的“PB”工具。如果部门只是从电子表格开始，就可以避免大量的工作。

除此之外，Jira在产品待办事项列表细化（PBR）和Sprint计划期间毫无用处。至少一个APO打印出相关的条目或将其写在固定在板上的卡片（请参阅Sprint规划一章）。

初始产品待办事项列表梳理的问题

初始PB的创建对于部门来说是一个巨大的挑战，因为每个人都需要学习如何以新的方式拆分需求34。令人怀疑的是，初始PBR工作坊能否在很少或没有前期设计的情况下产生任何有意义的东西。

PM＆BA＆CO的架构师和代表参加了此次工作坊，以支持团队进行细化、定义验收标准并立即澄清问题。教练和大多数Scrum Master共同协助了这次活动。

在理想的情况下，客户、用户和团队一起澄清PBI。在此初始PBR中，客户、用户不存在，而是由PM＆BA＆CO35的成员代表。这些是站在团队与实际客户、用户之间的“中间人分析师”。

但是与早期版本相比，人们传递规范，且每个人与之交谈的普通会议都是朝着更好的方向迈出的第一步。

但是，这种设置的功能失调是交接传递的浪费（和信息的丢失相关），增加了库存，并加剧了功能失调的角色和部门的存在。

在初始PBR中，团队主要与RA中的其他团队一起对条目进行了细化。1天半后，在墙上用活动挂图和便利贴创建了初始PB。有些条目具有接受标准。有足够的（几乎都是端到端的）PBI可以为每个团队至少填满一个Sprint。进度很棒！

在初始PBR的结尾，团队使用“魔术估算” 36方法以及相对的故事点37来估算条目。

后续内容见：德国大保险公司（化名）的巨型LeSS转型尝试（下）

注释：

1. 由于保密协议（NDA）我不能提到真实的公司名。 ↩︎

2. AGC主要遵循试验“尝试…障碍服务而不是变更管理”。 AGC确实做了一些关键的决定，例如 启动“初始PBR”，实际上这触发了巨型LeSS的实施 ↩︎

3. 实际上是一个子项目经理。 ↩︎

4. 实验协调员请尝试或参见以下内容，以避免出现问题。 ↩︎

5. 不要遵循试验“尝试…逐步从组件团队过渡到特性团队。” ↩︎

6. 避免尝试…自上而下管理层支持的转型 ↩︎

7. 尝试… 社区。 ↩︎

8. 尝试… ScrumMaster社区 ↩︎

9. 这种方法更像是“做敏捷”，当然应该避免。 ↩︎

10. 我在这里指出，在一些高级经理的脑海中的有个“假Scrum”的图像，他们希望SM担任经理协调员。由于指导，我们避免了这种情况（避免… Scrum Master协调员）。 ↩︎

11. 避免…Scrum of Scrums成为管理层的状态会议 ↩︎

12. 避免…Scrum of Scrums成为Scrum Master会议 ↩︎

13. 尝试…轮换Scrum of Scrums代表，避免… 频繁轮换代表。 ↩︎

14. 缺陷管理团队将在“组织”一章中进行介绍。 ↩︎

15. 指南：也许不要做Scrum of Scrums。 ↩︎

16. 应避免这种情况（请参阅避免…需要“冻结”）； 但是，由于系统测试滞后，因此打开了一个时间窗，在该时间窗内修改缺陷具有最高优先级。 ↩︎

17. 避免…虚假的团队级别“产品待办列表” ↩︎

18. 参见指南：三个实施原则。 ↩︎

19. 参见产品定义与需求领域方面的问题。 ↩︎

20. 我猜这是因为深深植根于使用外部合作伙伴而不是自己的人的想法。外部人员需要具备所需的全部能力，因此无需培训。 ↩︎

21. 参见指南：初始产品待办列表梳理。 ↩︎

22. 注意：从这个点开始，架构师就看到了基础架构变更的需求，而这些变更在各个团队之间并没有被团队所看到。 ↩︎

23. 参见背景章节的图 ↩︎

24. 注意：B2B2C产品团队的确切数量仅在重新设计工作坊之后才知道，这影响了Terra的所有开发团队 ↩︎

25. 来源: https://en.wikipedia.org/wiki/Insurance#Insurers%27_business_model ↩︎

26. 不幸的是，APO候选人没有参加任何CLP课程，所以我需要讲授LeSS Huge框架的基础知识。 ↩︎

27. 参见稍后文档中的特性团队章节 ↩︎

28. 后面运营任务的段落发生了深入的讨论。 ↩︎

29. 在这个案例中，领域待办事项列表为产品待办事项列表提供了一个过滤视图。 ↩︎

30. 首先，必须先有一份保险合同，然后才能对其进行更改或报告一起交通事故并希望换回一些钱。 ↩︎

31. 保险专家指导这些是什么，而我不知道。 ↩︎

32. 这遵循了把几个较小的工件“概括”为一个较大的工件的方法。 ↩︎

33. 注意：Sprint待办事项列表都在墙上而不是Jira中。 ↩︎

34. 参见稍后的需求处理部分 ↩︎

35. PM&BA&CO不是真正的干系人。LeSS的规则是澄清尽可能在团队和客户、用户及干系人之间完成。 ↩︎

36. 来源 https://campey.blogspot.com/2010/09/magic-estimation.html ↩︎

37. 参见指南“规模化估算”和实验“尝试…用故事点估算” ↩︎