规模化敏捷死亡之路

本文写于2016年《规模化敏捷案例分析》第一辑。

在大型企业中被强调很多次的词语之一就是“规模化”，但通过过去两年的经验，所经历的规模化敏捷方法都证明 无法被规模化。本次在德国与Martin Fowler、Neal Ford、Mike Mason等在技术雷达11月份的讨论会上，专门讨论了SAFe，各路专家的观点让人很有启发，决定结合近些年亲身经历的案例，探索一下大型企业组织敏捷转型的规模化之路。

案例一 国外大型软件厂商S公司 SAFe敏捷转型

项目背景

S公司是一家大型国际化的存储与安全公司。在美国总部发起的SAFe转型时，该企业中国公司正面临双重困境：云计算公司在市场上的挑战和中国政策的变化。其中包括，企业开始广泛地接纳云计算战略，不再亲睐自建数据中心及维护机房，S公司曾经领先市场的产品面临市场需求萎缩；中国政策在政府安全领域的国产化战 略，也全面挤压了外企产品的主要销售市场。

中国区的转型由一家美国的SAFe公司主导，据S公司的员工说，当时是集中数百人召开跨国会议，讲敏捷、讲产品Release、讲产品Backlog，最后丢给团队一个Release Planning要求按计划交付，同时也丢给我们一个SAFe框架最底层，即团队级别的Scrum & Sprint的咨询任务。

调研阶段产出物过程

调研阶段一般控制在一周内，产出可给客户中高层演示的报告。报告大纳应包括：问题和现状、改进目标和改进计划，有经验的咨询师最好还能给出一些业界方法实践的参考和改进的差距分析(GAP)。以S公司为例，当 时的输出为：

敏捷改进目标和计划 

1. 问题和现状

目前三个团队在交付计划的制定上，前期学习型任务占比重较多，交付反馈周期过长。 具体表现在：

• A Server团队：学习型任务和项目开发有一些区别，部分在 Spike 期间成功的技术拿到真实任务中又会遇到一些障碍；

• A Client团队：需要两个迭代才能确定技术框架，在这两个迭代中，缺乏敏捷 所定义的可到用户手中的交付物；

• C团队：学习任务占据了四个迭代，与 SM 沟通发现团队的目标定位在人员技能培养上，交付目标不够清晰。

• 在迭代开发中，敏捷倡导尽可能快地获得用户反馈，从用户视角来看，目前S公司团队的迭代计划缺乏明确的交付物，也缺乏交付的节奏感，还谈不上持续交付。

2. 改进目标

建立持续交付的基础：每个迭代需要有清楚的交付物，缩短用户和测试的等待周期。 对每个Feature进行增量开发，缩短用户反馈周期和改进周期。

3. 改进计划

对每个迭代交付物进行定义,定义需满足以下标准：

• 可交由集成测试团队测试

• 可向用户(PO)获得反馈

• 根据增量原则，形成合适的 User Story 分解方法，对可以增量开发的 Stories 制定后续的交付计划。

• 建立稳定的Scrum团队和PO沟通反馈会议，对每次的反馈在Jira中进行跟踪，将改进可视化出来。

为S公司定制的 User Story 分解方法及排出迭代计划的过程是，拿实际的产品故事卡进行分解，提取方法，再让S公司的开发人员基于方法进行分解，反复几次总结出最合适的方案，如下：

并给出了合理的迭代交付模型：

思考与分析：不同的客户和产品，咨询师如何形成标准化方法和差异化输出? 

咨询的棘手问题

进入S公司项目时，在敏捷这个领域我已经有超过6年的背景，和业界也有不少的交流及碰撞。在成功把一个开发小组推向了迭代交付之后，另一个小组C却非常棘手：他们是做偏向操作系统的配置界面，可视化展示存储容量、阵列组装等情况，而这次产品新版本是更换操作系统，旧的上万个单元测试全部不可用，维护涉及系统环 境变量、命令操作的查找改写，非常困难，而且每轮测试又需要在操作系统上安装其它团队交付的产品，问题很难定位，也很难推动跨团队协作，尤其是在美国的团队。

这种怨气很巧妙地通过内部八卦表现出来了，相比咨询的专业化，在组织里能够敏锐地嗅出不同寻常的气味更是一种强大的洞察力。

通过和这个团队对我的内部拥护者喝咖啡，我了解到这个组并不是看起来军心焕散所以能力很差，而是聚集了很多技术高手，在上两轮美国咨询公司主导的SAFe大减员下，从各个其它团队剩下的幸存者，拼凑而成一个组。由于看不到发展，又担心新来的咨询也有裁员的目的，所以士气低落。组里有一名技术大拿，在这个产品很多关键问题与定位解决，包括外部操作系统团队的底层问题，都是由这位技术大拿单枪匹马解决，但从来默默无闻，外部看来可有可无，很多人都为他抱不平，认为他的级别和受到的重视不成正比。 

思考与分析：这是一个什么样的问题？面临这类问题，咨询师如何处理?

问题的识别和SAFe的缺陷

和软件领域有分析建模方法和设计模式一样，思考和解决问题也有很多方法和模型，这是咨询师需要重点学习和积累的部分。对小组C的问题，可以结合TOC来分析和解决。

TOC（Theory of constraints），中文译为“瓶颈理论”，也被称为制约理论或约束理论，由以色列物理学家高德拉特(Eliyahu M. Goldratt)博士创立，与精益生产、六西格玛并称为全球三大管理理论；其核心观点为立足于企业系统，通过聚焦于瓶颈的改善，达到系统各环节同步、整体改善的目标。

上面提到，小组C的关键问题和整个产品操作系统级的问题，都严重依赖于某个具体的人来解决，这就满足了 TOC 理论的适用范围：关键约束。而SAFe框架并没有提供关键资源和约束瓶颈的解决方案，跨团队如何协同、沟通，至少在 S公司当时的转型框架中，没有看到明显的解决办法。 在S公司这个案例中，我们可以识别出规模化的第一个问题：规模化组织的关键资源如何共享和去约束。 除了基于方法和模型思考之外，基于经验和历史回溯也是一种办法。对于这个问题，敏捷本身其实是给出了答案，这也是“规模化”和“敏捷”的根本冲突之一。在敏捷软件开发的早期，率先被提出的问题就是团队成员能力上的参差不齐，当时的大部分方案，都是企业内水平最高的人员去组成敏捷团队，实行敏捷开发。后来才有了一些口号，指出“敏捷团队人人都应该可替代”，并且有了一些实践和方法将团队内成员的能力水平平均化。 我们可以识别出规模化的第二个问题：如何将在团队中就稀有的能力扩大化到整个组织。 

这其实是传统企业组织结构的悖论，对大型企业来说，经营方向的多样性和产品技术深度都不是从事软件交付类或互联网企业能够比拟的。在S公司我曾经被客户质问：“是否懂我们的企业？是否懂我们的产品？互联网那 一套怎么可能在S公司这样的产品上玩得转？”对这些问题，我当然有自己的答案，比如说，敏捷需要把产品做小，快速迭代式开发的选择正是因为来自互联网产品的同类市场竞争压力......等等。但我们的工作局限于客户顶层的转型方案约束，我们可以看到，两个问题都是SAFe框架的缺陷。

Kanban, Scrum

Kanban和Scrum分别从持续流动与迭代冲刺两种模式给出了基层小团队的轻量级管理框架。但他们都不是组织运作与管理的模式。所以Craig Larman在实施了数家大规模敏捷，包括大组织、复杂项目、离岸交付之后，总结出了大规模敏捷转型的精华：别搞规模化敏捷。

On to our key recommendation: After working for some years in the domains of large, multisite, and offshore development, we have distilled our experience and advice down to the following: Don't do it.

There are better ways to build large systems than with many  developers in many places. Rather, build a small group of great developers and other talents that can work together in teams, pay them well, and keep them together in on place with product management or whoever acts as the voice of the customer.

简单的框架很难水平扩展成为复杂的组织协同与决策模型。有兴趣的不妨研究一下组织管理思想的三大流派：

• 科学管理

• 社会系统

• 经理人角色
  

咨询师的立场

经历了这么多的咨询项目，个人的总结是，无论项目成功还是失败，一个有“咨询师立场”的人最后都是成功的。 这个立场可以称之为一种“观察者立场”，即保持局外人旁观者身份。因为咨询最重要的就是方法和经验的积累， 每一个案例都能成为独特的“启示”。

这个案例的最后，是我们成功拿下了第二期合同，但我们的客户大势已去，再难重回曾经的地位了。所以在当时，我是强烈反对再做类似于 S公司这样的客户及项目，因为这类项目会损害我们的市场口碑。但在S公司这样的项目上，我们可以认清一些产业事实，积累起一些行业经验，当然也包括个人经验，这就是项目失败但无损咨询师的成功。

本文来自微信公众号“敏捷加速器”（ID：Agile-Booster），作者 陈加兴，资深敏捷精益专家，场量科技创始人。拥有超过十五年行业经验，帮助华为、招行等数家顶级企业优化IT效能，是LEAP产品创新方法的提出者。

管理圈经授权转载，如需转载请联系原作者。