德国大保险公司（化名）的巨型LeSS转型尝试（下）
PBR结果分享会议的问题
初始PBR工作坊结束后，墙上可视化了排序的条目（便利贴）列表。在分享会中APO解释了列表，目的是让产品负责人团队、PM＆BA＆CO团队，测试经理，测试工具负责人，开发经理、发布经理及首席架构师获得共同理解38。
目标是获得以下方面的透明度：
哪些具有较高确定性的条目可以交付
哪些条目可能会产生
哪些条目明确不在范围内
请注意，在LeSS中通常不存在这样的“分享”事件，因为在初始PBR之后与之共享信息的人员应该已经积极地参与了初始PBR。必须进行单独共享的事实表明，没有进行有效的自上而下的变更去消除传统的团队和角色。
另一方面，LeSSHuge描述了产品负责人团队（POT）在Sprint计划之前进行同步的可能性，我认为这种同步在这里发生了很多，因此这很有用，但也包含了传统团队的无用的活动。
这次共享会议确实在POT内部，部门内部以及PM＆BA＆CO之间建立了信任和信心。此外，还播种了以定期进行重新规划和重新排序的种子。进步！
新组织结构的问题
拉曼组织行为定律
组织会含蓄的优化会以避免改变中层经理、一线经理及“专家”的职位和权力结构的现状。
作为（1）的推论，任何变更倡议都将简化为重新定义新术语，以与现状保持基本相同。
作为（1）的推论，任何变革倡议都会被嘲笑为“纯粹的”，“理论的”，“革命的”，“宗教的”和“需要针对当地情况的务实的个性化”，这偏离了解决弱点和经理、专家的地位的现状。
作为（1）的推论，如果在变更之后某些经理和专家仍然被取代，他们将成为变革的“教练或培训者”，并常常加强了（2）和（3）。
在这种情况下，所有这些定律都必须遵守。以下段落更深入的描述了组织结构及各个小组和职能的功能失调。
产品管理、业务分析及协调（PM&BA&CO）
PM＆BA＆CO确实是Alpha公司的一个单独部门，这一事实使他们很难参与到LeSS实施中。在自上而下和自下而上的支持的变革中，两个部门PM＆BA＆CO和Terra将合并为一个部门。
因此，这种功能失调设置的存在，造成了尤其是在早期对于如何完成事情理解的不一致性，例如：
他们不断提供较大的需求定义。
发布内容的预期承诺（请参阅合同游戏）
通过指导，教育和举办共同的工作坊，随着时间的推移合作得到改善。但是由于缺少高层管理人员的支持，从长远来看，其他做法（例如预算，激励机制，目标设定）可能会比这些改进更有价值。
开发主管与产品负责人
LeSS的基本规则是只有一个产品负责人。考虑了几个选项来回答这个问题，谁将承担这位产品负责人的职责。很明显，她不能来自现有的PM＆BA＆CO39部门，因为他们仅涉及B2B2C产品，而完全不涉及B2B产品。
开始巨型LeSS实施时，很明显项目经理既是真正的产品负责人40，同时又是“开发负责人”，即领导整个组织（一个人担任两个不同的角色）。
产品负责人团队
产品负责人团队（POT）由PO和三个APO组成。
POT经常开会，以重新规划PB的短期和长期优先级。很难掌握产品负责人的职责，因此产品负责人团队建立15分钟的每日站会时间，以便能够根据需要与PO同步日常问题。
后来，POT意识到需要定期重新确定PB的优先级。这是与PM＆BA＆CO的代表一起完成的。参与者花了好几轮的时间才能够集中讨论短期（1-2个Sprint）和中期条目（接下来的2-3个月）。
对话没有继续进行合同游戏，而是逐渐朝着更具协作性的方向发展，并专注于信息交换和寻找方法，以使下一次发布尽可能有价值。
特性团队
LeSS的规则还定义了每个团队都是自组织，跨职能，在同一地点且长期存在的。
在命令和控制环境中工作了多年之后，特性团队开始学习自组织。开发人员迅速重新调整自己，以便特性团队的所有成员坐在一起。“合同承保”RA有5个团队，其中4个与APO在同一地点，而另一个团队在印度。
在自设计团队工作坊之后，所有特性团队都是跨职能和跨组件的，能够完成以客户为中心的特性，即结果而不是输出。
从某种意义上说团队是稳定的，因为团队成员没有被抽调到其他小组中。由于大多数团队成员来自合作伙伴，因此每1.5至3年会进行一次成员交换。
许多团队成员（和经理）是合作伙伴（或分包商），有时甚至是竞争对手。这个事实大大限制了团队的自组织能力。
成员经常在这里进行改变的事实是另一个功能失调，这阻止了组织和团队的整体学习。个人确实学习了，然后就带着所有的知识去了另一家公司。
Scrum Master
尤其是Scrum Master都没有大规模Scrum和LeSS的经验。所有人都对如何支持1-2个团队的Scrum转型有很好的想法，但没有足够的知识和理解来支持更大规模的实施。他们在指导PO、管理层和组织方面，或者换句话说，“为人们创造成功的环境”方面，都没有Scrum Master角色的丰富经验。41
不幸的是，关于Scrum Master的LeSS规则仅得到了部分实现。
最大的差距是缺乏对LeSS的知识，以及他们无法专注于组织、开发实践和整个组织的系统。随着LeSS Huge的实施，所有Scrum Master都致力于担任这一角色，并在一个RA中为1-2个团队提供服务。
在我辅导的时间里，Scrum Master 开始学习LeSS规则、原理、指南和实验。特别是，他们学会了支持LeSS事件，APO和整个组织作为一个复杂的系统。Scrum Master尚未将重点放在开发实践上。
Scrum Masters在所有RA中形成了一个社区，这对他们的技能，思维方式以及他们可以互相支持的地方有很大帮助42。此外，他们还学会了引导大型团体活动43。
一名Scrum Masters具有SAFe背景，他拒绝了我们计划的所有结构的改变。项目经理已经清楚了这种情况需要解决。因此，这个Scrum Master的合同（他和其他人一样都是外包人员）提前终止了。
未完成部门
通常未完成的部门是功能失调的。首先应避免使用未完成部门，随着时间的流逝且团队越来越多地完成“未完成的工作”，这肯定会消除它们。
在Terra部门中，“未完成的部门”包括：
系统测试和验收测试
测试工具
系统测试和验收测试
新功能的系统测试由团队完成，但是系统级的回归测试主要由印度44的“测试工厂”进行，而测试工厂是由测试经理“监督”的。大多数测试是手动执行的。
这种功能失调会导致较长的反馈周期、交接、用工具进行沟通、我们与他们、学习不足、责任从行动中分离出来，以及对产品增量准备交付的方式的不清楚。
此外，“测试工厂”来自战略合作伙伴，该合作伙伴与另一合作伙伴互换，后者承诺在自动化回归测试中也将提供更快的速度。这个改变延迟了大多数所需实验的开始。简而言之，这是非常麻烦与混乱的，对于LeSS实施而言这并不是最佳选择，但这是朝着可能改善情况的第一步。
总的来说，目标是从长远来看使回归测试和系统测试自动化，并完全消除该功能或至少显著降低其功能。但是，我认为这个目标实际上与合作伙伴的目标和利益相抵触，因为通过提供手动进行测试的“主体”可以使合作伙伴获得很好的收益。从整体上看这是另一个功能失调，从而被管理层忽略了。
测试工具
测试工具团队负责构建和开发验收测试框架的一部分，维护服务器并运行测试框架，在计划发布产品时执行验收测试。测试工具团队与特性团队一起参加冲刺事件。
这种功能失调的设置禁止（或至少阻碍了）团队学习有关验收测试驱动开发和所需工具的知识。此外，这种情况造成了交接、更长的反馈周期、依赖性以及协调的需要。
该团队的存在是由于历史原因，即测试工具始终由X部门来完成。此外，该工具的体系结构是X部门的主管建立的，据我所知，没有足够的文档证明团队可以自行继续开发工具。管理层允许这种情况，我认为延迟开发的风险被认为是这种设置的影响。据我所知，这个小组没有任何消除它的计划。
客户文档
随着巨型LeSS的实施，本地45CuDo团队被解散并整合到团队中。
支持功能
支持功能包括：生产管理，发布管理，架构师和资源经理。
通常，支持功能是LeSS实施中的功能失调。首先应该避免，并且随着时间的流逝一定会消除支持功能，因为这些浪费的工作要么被消除，团队进行有用的工作，而且在团队中建立这些能力。
通常，这些职能阻碍了团队进行自组织，进行交接并延迟信息的流动。
生产管理
生产管理包括两个团队：缺陷管理和配置管理。
缺陷管理
B2B2C产品具有大量累积的缺陷。原因是Terra部门的结构，印度有“测试工厂”的事实以及测试工厂与开发团队之间的沟通是通过缺陷工具完成的事实。因此，当印度的测试人员发现系统测试或回归测试中的缺陷时，他们在系统中开一个ticket，他们将工作视为“完成”。然后，开发团队来找出解决方法。
Terra部门有自己的团队来协调来自测试工厂、最终客户、生产系统和产品其他用户的缺陷。该团队提供了一级支持，并为团队之间的一级支持之外的问题提供了协调。
协调效果不佳，因为这试图通过像“APO的影子”一样向特性团队注入工作。与APO和团队沟通不畅是一个持续的摩擦点。
当该团队的一个关键人员离开公司时，我们讨论了将缺陷管理的职责移交给团队的可能。但是，这些想法被生产主管否决了，不幸的是这些想法永远消失了。几个月后，生产主管离开了部门。
最大的功能失调首先是问题的根本原因，即系统测试和验收测试小组的存在，以及通过工具进行的沟通，以及试图从侧面将工作注入团队（译者注：工作不是由APO或者PO确认的）。
配置团队
配置团队负责构建系统，并将最终软件投入生产46。他们还负责部分运营，因此需要与测试工具团队和特性团队密切合作。我不了解有关合作和分工的详细信息。无论如何，这增加了工作的复杂性，并增加了特性团队的工作量。
这个团队的存在造成了交接，限制了团队学习构建系统他们所需的真正的知识，创建了较长的反馈周期，并将责任转移到了团队外部，从而使预测变得更加不可预测。这个责任应该在团队中。
版本管理
版本管理团队的作用是帮助PO，APO，非常规团队47，并维护Jira中麻烦的PB的团队，他们负责检查数据一致性和支持团队，APO向Jira中输入数据，创建和维护电子表格和Jira之间的链接，向高层管理人员报告，帮助APO创建燃尽图以及PB排序所需的其他信息。
就LeSS实施而言，此团队的工作显然是浪费的，并且存在该功能的最大原因是因为使用了Jira（当然，没有人会计算出增加的价值或增加的成本）。使用更合适的PB工具，此功能可以很快消除。
实际上，由于随着LeSS Huge的实施开始，对“发布管理”的需求（即协调）大大降低，因此该功能的规模减小了，团队的负责人离开了并且没有换人。
资源经理
资源经理负责支持项目经理，以创建和维护该部门工作人员的概况，建立能力矩阵，确定战略性的未来需求和潜在的问题领域。
原来的生产线管理结构被彻底淘汰，项目经理没有自由的认知能力来处理生产线人员的所有方面（例如在LeSS框架中，开发负责人将担任这一职位），并且作为快速解决方案，引入了资源经理。
架构师
在实际LeSS实施的过程中，架构师加入到团队中，没有形成自己独立的部门。
由4名架构师48组成的职能部门，帮助APO拆分较高层级的需求（分到不同的RA），从而拿走了本该属于团队的职责。这种功能失调的设置会导致例如前期设计决策，从而给团队带来不必要的约束和负担，并且可能导致实施中的解决方案不理想。交接、延误和等待只是一些典型类型的浪费。
另外，我想强调的是，这样一个（架构师）团队的存在支持了X理论模型，在该模型中，“一些人思考，其他人只能动手”，即架构师思考，团队“只能动手执行”，这是许多组织中的主要问题。
然而，架构师在团队49中的行为大多像导师，参加了梳理工作坊50，并主持了架构师社区51。这些团队已经具有足够的基础架构能力，他们可以自己梳理大多数的需求。然而在实施之初，团队常常需要架构师的支持。
据我了解，架构师团队存在的原因如下：
项目经理认为，将架构师整合到团队中的风险太大
该产品是较大系统52的一部分，该系统具有与其他系统的关键接口，并且项目经理不想更改此设置中的任何内容以向外部过渡
架构师认为他们不需要改变
我的工作结束时，首席架构师来到我身边，询问开始第一步的时候，是否将架构师团队解散并加入需求领域的团队会更有意义呢。所以隧道里有了灯光（译者注：意味着LeSS实施引发了新思考，后续有新的可能）。
运营任务的问题
Terra部门还负责运行软件，并承担各种运营任务。这些任务主要包括，回答客户如何使用该软件的问题，前期分析由PM＆BA＆CO提出的相关问题、监视数据（和正常运行时间）以及支持向Alpha公司其他部门提供产品相关的报告（不是状态）。
分析工作坊的目的是确定并细化那些运营任务，使其透明化，并识别是否还有其他方法来处理（例如，将一些澄清工作移入梳理工作坊，就像通过消除多余流程的“少即是多”原则）。
当时基本上确定了两个选项：
A. 开发该软件的团队也负责运营问题。 B. 一个专门的团队负责运营任务
LeSS建议的另一种解决方案是轮换角色，这就是说其中一个团队（在LeSS Huge中，每个RA可能需要一个轮换团队）是“快速响应团队”，因此，剩下的队伍减少了。例如，每1-2个Sprint轮换一次该角色。
那些任务每个本身并不大，而是有大量的小任务[^53]。将它们单独放入PB会使PB模糊并数量大增。解决此问题的另一种方法是（事后检查）检查这些任务将花费多少时间，然后PO和团队将保留一定比例的时间用于这些活动（请参阅指南：处理特殊条目）。
解决方案（A）在LeSS实施之前52和实施中就已到位。这造成团队的工作范围出现一些令人不愉快且令人不安的变化，并影响了Sprint的预测。
该解决方案的优点如下：
团队可以感受到他们的产品实际运行的现实情况
减少交接和排队的数量
为团队提供了机会，学习和改善当前客户面对的挑战
使问题透明化，以便团队可以解决这些问题
注1：如果这些任务是浪费的和不必要的，则解决方案（A）可能与“少即是多”原则相矛盾，因为这增加了复杂性，支持现有过程而不是问我们为什么需要这样做。但是，将这些特殊的工作条目交给专家团队会使协作更加复杂。因此，当时的解决方案（A）显得更有意义。
注2：事后看来，达到Sprint预测非常重要，即“需要可预测性”。这支持“合同游戏”53的概念。这个概念在最初（仿造）Scrum的实施之初肯定存在，但是在我担任教练的过程中减弱了。
Terra部门在自我设计团队工作坊期间尝试建立解决方案（B）但失败了，因此解决方案（A）得以继续。
冲刺事件的问题
巨型LeSS的一项规则是，每个需求领域只有一个产品级别的Sprint，而不是不同的Sprint。Sprint结束时有一个集成的完整的产品。LeSS规则还暗示着一个产品级别的Sprint，而不是每个团队有一个不同的Sprint。每个团队同时开始和结束Sprint。每个Sprint产生一个集成的完整的产品。
整个部门遵循相同的两周节奏54。
在进行Sprint计划的第一部分之前，POT举行了一次简短会议以分享他们的情况并讨论协调一致的机会55。
在每个RA中，Sprint计划分为第一部分和第二部分56。通常，每个团队都会派两名代表参加到Sprint计划的第一部分，并从PB中选择几个条目。
通常情况下，每个条目都经过较好的梳理，在这次活动中没有任何惊喜。团队代表回到他们的团队进行Sprint计划的第二部分57。作为Sprint计划第二部分结果的PBI是对APO做出了预测。
在sprint计划会期间有可能的共同工作时，团队自己进行协调。
APO开始在卡上写好PBI，以加快Sprint计划。这种方法演进并包括了一个跟踪系统，因此APO直到数据录入Jira工具才知道哪个团队选择了哪个条目。
然后将物理板安装好，这提供该RA中正在进行和即将进行的工作的可视化。APO进行了两次“记账工作”，将主要内容保留在物理板上，然后数据输入到Jira中。
每个RA的所有团队一起进行Sprint评审58。每次Sprint之后，都会与PM＆BA＆CO和其他干系人组织一次产品演示。
在团队层面59举行Sprint回顾会。较小的改进通常是立即完成的，而无需等待回顾会。每个RA都有一个总体回顾会60，而该部门每月有一次全部门的回顾会，跨所有的RA包含所有职能都会参加的回顾会61。几个月后，每个RA都建立了整体回顾会。
在部门范围的回顾中，与管理层、POT、Scrum Master、团队代表以及其他职能部门的参与者一起识别障碍和改进的主题。有些障碍已转发给AGC进行处理，其他障碍可由参与者解决。通常，在许多方面都进行了改进，例如每日站会（跨团队学习），PO与APO的合作，如何处理缺陷，以及建立了多个社区。
PBR会议通常是多团队梳理62，PM＆BA＆CO63常常需要参加。对于涵盖多个RA的需求，需要组织多个RA一起参加梳理会。
仅在极少数情况下，才会按照LeSS规则邀请最终客户，即在团队、客户、用户和干系人之间尽可能多地进行澄清。
跨团队协调是通过团队非正式地请求其他团队支持64或通过常见的Scrum of Scrums会话来进行的。集中的会议似乎是使问题引起团队注意的快速方法。
此外，APO与架构师每天同步，和其他人（例如教练、部门主管）进行讨论，以解决有关公共产品的问题。
Sprint待办列表清单
每个团队都有自己的Sprint待办事项列表65。至少每个团队有一个物理板，团队还可以在Jira中使用。板子就在团队附近。
完成的定义
在最初（仿造）Scrum实施期间，团队与APO就所需功能的代表的共同的完成定义（DoD）66达成了一致。这是在两个共同的工作坊上完成的67。只要我在场，共同的完成的定义便保持不变。不过部门意识到，增强DoD是一种改进68的可能。有些团队确实增强了其团队级别的DoD69。
在LeSS实施开始的时候，客户文档已集成到团队中，团队的DoD已经包含了这项工作。
单元测试和系统测试被认为是至关重要的，因为当前的设置产生了较长的反馈周期，并且通过Jira进行了尴尬的通信。在创建环境方面正在进行重大变化，因此可以改进测试领域的DoD。
工程实践
所有团队都集成到一个产品中。最初采用“Scrum”时，该部门已经有一个自动构建系统。单元测试覆盖率很低，并且在系统测试阶段发现了许多缺陷。系统测试和回归测试通常是手动完成的。随着越来越多的测试自动化，随着时间的推移情况得到改善。
这是该部门通过增加单元测试覆盖以及显著增加自动化测试量来改善总体测试状况的主要工作之一。我提供了指导，以在所有团队（和所有团队成员）中传播测试驱动开发（TDD）和验收测试驱动开发（ATDD）70的能力。部门采取了具体步骤（我没有完全详细了解）以将缺少的能力带入团队。
但是，特别是对于使用“旧”语言进行编程的开发人员来说，这是一个真正的挑战，我在（辅导）的期间团队并没有掌握。
结对编程和编程(mob programming)被推广为一种获得学习能力的方法。举行共同编码活动以总体上提高编码质量。
需求处理
LeSS的实施使需求梳理的方式从根本上发生了改变，从组件视图到以客户为中心的71拆分。
如果没有以这种方式划分需求的技能，就不可能在基于RA的结构中独立工作。
APO，架构师，Scrum Master以及当然还有团队成员都需要接受培训，这是一条陡峭的学习曲线，存在许多障碍。能够通过了解产品的性质和需求领域来留在客户问题空间中是至关重要的，并且对如何制定和拆分需求的理解对于初始PBR工作坊的成功也是至关重要的。
在新客户（例如保时捷）想要提供车辆保险的情况下，所有三个需求领域都涉及到。通常，承保是开始工作的第一个领域，其他RA在逻辑上是建立在此之上的。
在PB工具中（记住Jira！）需求总是有父级，该工具对于获得关于产品整体功能就绪性的某种信息是必不可少的。
有时PB（电子表格中的第1级）中还包含中等粒度的条目，这是由于拆分较大的条目而产生的，例如，当您创建新客户（例如“保时捷”）时，您不需要一开始就完成承保的所有细节。
签订合同一年后可能才需要某些功能。然后，通过拆分父级的需求，将这些特性拆分并在PB中排序，然后再进行基于单元的拆分。
这时，拆分主要遵循树状拆分，而不是推荐的细胞状分裂[^75]，这是因为开始使用这种方法（对于Terra部门而言）已经是激进的新思维方式。这是一种在LeSS实施开始阶段足够好的方法，且相关人员可以一起合作。
此外，在极少数情况下，较小的PBI确实会出现在电子表格PB中，从而提供了像单元格一样的拆分。这些条目为PM＆BA＆CO部门提供了证明，“敏捷”似乎在创造适应性方面发挥了作用。这创造了积极的势头，并在部门之间建立了信任。
管理文化的问题
最初“Scrum”实施之前
对于开发人员，产品负责人，架构师和管理人员而言，典型方案如下：一个人在以下方面最多有三个上级：职业，职能和项目。大多数人来自外包公司，只有一小部分直接由Alpha公司雇用。来自Alpha的员工很少属于Terra，而是按（长期）“借用”的基础分配给Terra。
这是我所见证的责任的描述：
职业：这位上级负责薪水、休假的正式签核以及长期发展。
职能：此人负责功能能力的所有问题，例如业务分析、编程语言、领域和测试
项目：此人向人们提供了应执行的实际任务。
有时，一个人同时担任职能经理和项目经理。
最初“Scrum”实施
功能和项目维度已删除。取而代之的是，这些任务的一部分是通过自组织的团队和“假PO”来完成的，“PO”主要是技术输出负责人（现在仍然是某类子项目经理）。职业维度仍然存在。
巨型LeSS实施
情况发生了巨大变化。由于巨型LeSS的结构，APO通过减少他们在团队工作中的参与而从其早期的虚假“分析师”和“指导者”PO角色成长而来。这些团队提高了自组织的程度。对于大多数人来说，职业上司仍然没有受到影响。来自战略合作伙伴的所有人员在其母公司中均有职业上司。
很明显，在这种情况下，“文化遵循结构”这一说法得到了确认。新文化显然是值得注意的。
几个Sprint之后
重组后的两个月，由于几个人离开了部门，三个RA中的两个RA需要再次进行重组。这是通过以自我设计团队工作坊的形式自愿提供的，工作坊的主持人（Scrum Master）和受影响的APO对此问题进行了解释。在短短的两轮中就解决了问题，并成立了新的特性团队。继续进展！
LeSS实施的第一阶段以6.6版本上线结束。这次活动仍然具有与旧风格类似的风格，即星期六人们在办公室发布，管理层提供食物并查看该软件顺利投入生产的旧风格。
然而，在编写第一版本报告“发布活动日”之后的一个星期，没有出现预期的缺陷风暴。可以提高质量吗？进展！
辅导方法
可能需要注意的是，该部门尚未决定正式转向巨型LeSS。然而，该部门从仿造Scrum的实施中学到了经验，并开始在很大程度上遵循LeSS框架和结构，基本上没有做出有意识的选择。但是，持续改进和学习还有很长的路要走。
“有人可能会受到伤害” 75：经过总共6个月的训练，我的教练期突然结束了。显然，我的方法又太过急，或者部门还没有做好真正改变的准备，而我的看法也太不舒服了。有几个初级教练在我之后来了（又走了）。为了持续改进，需要更合适的高级教练。
结语
在2017年12月，我与项目经理以及部门其他成员进行了讨论。项目经理说…
“尽管对新功能的吞吐量还不满意，但他承认其产品质量已得到显著地改善，并且对于连续三个版本来说，以前预期的新版本出现的常见缺陷风暴并没有发生。该部门搬到了另一栋大楼，那里的房间不像以前那样支持团队合作。该公司在2017年夏季也面临了一些裁员，更多的开发工作转移到了印度。保留了RA的基本结构，但是失去了一些重点。工程实践、特别是测试（代码覆盖率和回归测试的自动化）得到了改善。”
在这段时间之后，我基本上与团队失去了联系。因此，从长远来看，LeSS Huge的实施是失败还是成功的任何陈述都是推测。
从最初的“Scrum”实施到巨型LeSS的实施，这非常令人着迷。突然，“事情”开始发生并对人们有意义。人们更快乐，他们喜欢承担挑战和承担责任。结果产生并且质量提高。见证工作场所的这种转变是一次压倒性的积极经历。进展！
致谢
我要感谢Ran Nyman，他提出了将此案例用作案例研究的想法，感谢他对本案例的支持和最初的评论。我还要感谢ME允许发布此案例。此外，我还要感谢Ran Nyman，Elad Sofer，Bas Vodde和Craig Larman的宝贵意见和评论。
注释：
PM＆BA＆CO，测试经理，测试工具负责人，生产经理，发布经理和首席架构师形成了功能失调的设置，在“新组织结构的问题”一章中进行了更多讨论。 ↩︎
据我所知，后来两个部门都考虑APO是来自PM&BA&CO部门的。 ↩︎
根据LeSS指南“五种关系”，PO工作得非常有效，并与APO进行密切合作。 ↩︎
参考书籍Large-Scale Scrum More with LeSS（英文版）第135页 ↩︎
参见指南：社区工作 ↩︎
参见指南：大型团队的引导 ↩︎
参见实验：避免…开发与测试分开；避免…测试部门。 ↩︎
本地CuDo团队由位于爱尔兰的的按需支持的团队三名专家组成。 ↩︎
我没有参与这个团队的辅导，因此对此的了解非常有限。 ↩︎
参见指南：“产品负责人助手” ↩︎
另请参阅需求处理一章；Terra的高级管理人员不敢放手架构师团队。请参阅“避免…独立的架构师团队” ↩︎
避免…宇航员架构师（PPT架构师） ↩︎
尝试…专家参与设计工作坊而不是事后批准审核 ↩︎
尝试…设计、架构师实践社区，团队成员就开始学习更多相关知识 ↩︎
“构建软件并运行软件”的概念. ↩︎
避免…产品管理与研发部门就“发布合同”（范围和日期）进行谈判、 ↩︎
周四是Sprint计划会，周三是Sprint评审、回顾和产品负责人团队会议。Sprint Planning on Thursday, Sprint Review & Retro, POT meeting on Wednesday. ↩︎
请参阅LeSS规则（产品负责人和领域产品负责人频繁同步。在进行Sprint计划之前，他们确保团队工作在最有价值的条目。在Sprint评审之后，他们进一步启用产品级别的实施。）和指南 ：产品负责人团队会议。 ↩︎
请参阅LeSS规则（Sprint计划由两部分组成：Sprint计划第一部分所有团队都参加，而Sprint计划第二部分通常是每个团队单独进行的。在共同空间中进行多团队的Sprint计划第二部分以紧密合作相关的条目。） ↩︎
请参阅LeSS规则（“Sprint计划第二部分”是由团队决定他们将如何处理所选条目的方法。通常涉及设计和创建团队的“Sprint待办事项列表”）。 ↩︎
请参阅LeSS规则（只有一个产品的Sprint评审；所有团队共同一起的。确保合适的干系人加入并贡献了有效的检视与调整所需的信息）。See LeSS rule (There is one product Sprint Review; it is common for all teams. Ensure that suitable stakeholders join to contribute the informa- tion needed for effective inspection and adaptation). ↩︎
参见LeSS规则（每个团队有自己的Sprint回顾会） See LeSS rule (Each Team has its own Sprint Retrospective). ↩︎
参见LeSS规则（在团队回顾之后举行总体回顾，以讨论跨团队或系统范围的问题并创建改进的实验。产品负责人、Scrum Master、团队代表和经理（如果有）参加）。 ↩︎
参见LeSS指南: 多领域的评审会与回顾会。 ↩︎
参见LeSS规则（PBR中每个团队梳理他们将来可能要做的条目。进行多团队或总体PBR可以增进共同理解，并探索协作的可能性，这发生在密切相关的条目或者需要更广泛的投入和学习中。） ↩︎
谨记，“中间人分析师”的那些人，这种设置是功能失调的。 ↩︎
参见LeSS规则（跨团队协调由团队决定。相对于集中式协调，LeSS更偏好分布式的和非正式的协调。通过代码沟通、跨团队会议、组成导师、旅行者、侦察员以及开放空间来强调只交谈和非正式的网络。） ↩︎
参见LeSS规则（每个团队有自己的Sprint待办事项列表）。 ↩︎
参见LeSS规则（有一个整体产品的完成的定义，所有团队是一样的） ↩︎
参见避免…质量团队定义的完成的定义 ↩︎
参见LeSS指南：扩展产品定义 ↩︎
参见LeSS规则： 每个团队可以通过扩展通用的DoD有自己更严格的完成的定义。 ↩︎
参见实验：尝试…验收测试驱动开发。 ↩︎
参见实验：尝试…编写客户为中心的需求。 ↩︎
我完全是外部的。参见实验：尝试…外部敏捷教练。 ↩︎
我将内部用引号括起来，是因为该人确实来自合作伙伴组织，并且被录用只在这里工作。 ↩︎
参见尝试…内部教练和外部教练；尽管该主题在TDD章节中，但我认为它总体上也适用于教练。 ↩︎
Leading Teams: Setting the Stage for Great Performances by J. Richard Hackman. ↩︎
原文链接：https://less.works/zh-CN/case-studies/german-big-insurance
- 点赞
- 收藏
- 关注作者
评论（0）