J.P.摩根如何运用LeSS框架实施大规模敏捷

J.P.摩根如何运用LeSS框架实施大规模敏捷2016-03-10 infoq Craig Larman and Mat顶尖金融服务企业中的大型组织是如何采用大规模Scrum框架（LeSS）的？

背景

J.P.摩根的全球核心处理技术集团由Simon Cooper领导，是一个遍布全球的3000多人的组织。2013年集团决定要改变为（真正的）Scrum，并采用Large-Scale Scrum（LeSS）框架，这意味着在组织设计要做出相应改变。

之前他们曾零散地采用了"Scrum-But"及各种敏捷工程技术，主要是在开发团队中，但现有的权力和组织结构并无显著改变，与业务的交互也是一样——仍然是“合同谈判”而非“客户协作”。仍然存在负责交付“合同”的研发项目经理、团队主管、单一职能的专家角色，以及单独的组件团队和职能团队（比如测试团队）。

年初Craig与Simon Cooper及其直接下属的经理做了一次有力的对话，随后他们就决定将组织设计转变为基于LeSS的Scrum框架。

这次领导力对话认清了组织中目前“合同游戏”的动态，它阻碍了组织提高敏捷性和改善以客户为中心的特性交付。

这次领导力对话也针对真正的特性团队进行了探讨——跨组件和跨职能团队，它可以端到端地交付客户特性，不存在移交、依赖或延迟。这需要消除组织内的藩篱，比如职能部门和组件团队，以及相应的经理角色。

管理者们乐于接受这些想法，因为他们认为有可能提高敏捷性，简化计划和协调工作，更多关注价值，减少交付的问题。现在他们意识到要想转变为Scrum框架，就需要调整组织结构及相应的学习，而不是之前想的那样“Scrum只是团队实践”。

核心证券处理集团内的变化

在通往Scrum的路上，他们决定让Mike Goldverg麾下的证券组织首先进行重组。这意味着证券团队不得不第一个吃螃蟹来考虑影响深远的组织变化。集团决定了以下的优先级：

理清部门所支持的产品间的联系，识别出产品负责人，并授权他在每个迭代（Sprint）中决定发布日期、内容和优先级。

建立特性团队，关闭按职能划分的部门。

消除一线经理角色。

改变剩余经理的心态和行为，由命令与控制向教练与指导转变。

识别和培养熟练的程序员作为老师，直接与团队一起工作来辅导极限编程（XP）技术，比如TDD。

由自组织的特性团队（feature team）自己来做重要的决定，比如选举Scrum Master。

传统组件团队和相应的计划

证券集团之前是按照架构组件的传统方式来组织的，每个组件有一名经理即负责人。组件负责人习惯于与多个业务单元一起做决定，主要是作为年度计划周期的一部分。由于以客户为中心的特性通常跨多个组件，那么为了交付端到端的以客户为中心的特性，多个组件负责人需要共同商定时间表和优先级。自顶向下的协调做计划（出现在各种事件中，但实际经常难以意识到）通常很耗时，涉及多轮谈话和谈判，因为不同的业务单元（和特性）会由于组件团队的可用性和优先级以及“他们的”小算盘而竞争。