阿里巴巴从Scrum到互联网精益敏捷之路

老牌互联网企业阿里，骨子里一直有着脚踏实地、自力更生的基因。阿里的敏捷落地没有自上而下的大规模转型，更多的是在业务压力驱动下自发地采用了若干敏捷实践。

对于此时的互联网企业而言，敏捷已经成为必要的研发方法。

01

阿里最初引入 Scrum 的情景

“首先应该解决领导的问题，解决方式就是拍晕他。拍的方式，一言难尽啊。至于接下来，说实话，我觉得推 Scrum 这种方式还是很容易推的，不过是一种管理理念。比当年推 CMMI 那种东西好多了。”

“其实我们一开始并没有把 Scrum 这个说法拿出来。就是首先和业务一起商量什么时候上线，商量的结果是每个月定期上线。然后为了管理，我们开始开晨会。

然后为了改进，我们开始开项目总结会，把 Product review 和 Team retrospective 放在一起，既有产品经理介绍现状，也有大家讨论成绩，不足和挑战。

后来总结会上觉得质量不好，我们加入了单元测试和代码 Review 机制。至于计划会议，一开始我们就采用的 Scrum 的方法。

项目小，MS Project 太难调。我们就更换了 Scrum 的 Excel 计划表，后来又换了 XPlanner。”

“就这样走了几个月后，我们把大家叫到一起，开了一个 Agile 方法分享会。把大家之前实践总结一下，然后告诉大家，我们的做法就叫做 Scrum ，而且它是很有名的哦。然后再把 XP、Agile 和 Scrum 都给大家系统讲一遍。于是大家如梦初醒，原来我们是在走 Scrum 啊～～～～！！！”

“同时这个项目组的成绩也得到了高层认可，高层也认为效率提高了。于是让这个团队给周围的团队做分享。并挑几个团队开始试行。因为我们团队成员可能会有轮岗和互调，一个团队使用 Project，一个团队使用 XPlanner，有时员工也难以上手。为了部门管理统一，方法统一，工具统一，最后高层下令全部实施 Scrum。”

——李宇谈阿里最初引入 Scrum 的情景

02

脚踏实地的阿里敏捷

2005 年 8 月，雅虎以 10 亿美元投资和雅虎中国全部资产为代价，换取阿里巴巴 40% 的股份。这笔交易不仅解决了阿里的燃眉之急，而且让阿里获得了雅虎中国一批优秀的工程师。其中雅虎中国广告团队整体切换成阿里广告团队，并于 2007 年成立阿里妈妈。

阿里的敏捷之旅，就发端于这支团队。据当时在阿里妈妈负责过程改进的李宇回忆，这支团队最初是在 2006 年 3 月开始试用 Scrum，并结合了极限编程的一些实践，经过近两年的试点、推广和改进，到 2008 年已经在全部门采用。

阿里妈妈开始使用敏捷方法的出发点非常简单：业务希望每个月能定期上线，技术团队就对应地制定了每月一个项目的排期。因为是互联网线上服务，没有版本的概念，对技术来说就是在这一个月以内完成某一批需求，这一个月以内的工作叫一个项目。

以 2006 年的行业背景和技术环境而论，每月一次上线生产系统，是相当短的发布周期（作为对比，Martin Fowler 在 2006 年中国软件产业发展高峰论坛上发表演讲时，台下绝大部分听众无法理解“为期 8 个月的项目在两个月时已经上线开始收钱”的概念）。

为了管理这种快节奏的项目，团队引入了每日站会、计划会议、回顾会议、单元测试等实践，项目管理工具也由微软的 Project 更换为适合 Scrum 和极限编程的 XPlanner。

经过几个月的实施之后，团队领导者才告知团队成员，这段时间采用的方法是以 Scrum 为主的敏捷方法。

这种先实践、后理论的敏捷推行方式，与阿里一贯重实干、讲实效的企业文化是一致的。作为早期的敏捷导入者，李宇认为在阿里推 Scrum 是很容易的，因为需求模糊、沟通成本高、发布周期长、质量不佳等问题是业务与技术团队的共识，只要是能解决这些问题的办法，团队都有意愿尝试。

另一方面，阿里较强的技术能力，使得自动化测试、持续集成等技术要求较高的实践能够比较容易地落地。

阿里的即时通信软件“来往”团队的敏捷导入之路就是这样一个典型的例子。这支团队是 2014 年从公司各个部门紧急抽调大量人手快速组建的，在不到两个月的时间里组建了上百人的团队，人员的快速膨胀带来了秩序的缺失，大家各自有想做的方向，无法形成合力，处于一种生机勃勃而又混乱的状态。

主导引入敏捷的是该团队的技术负责人梅坚。团队的初衷是希望建立一定的流程，既要有清晰的产品规划、形成合力，又能快速产出基础的 MVP 版本、并快速迭代演进产品。

在梅坚和过程改进工程师林岳令、许珊珊等人的努力下，团队建立起了以 Scrum 为基础的迭代节奏：每个月对外发布一个新版本，每个星期发布一个阿里集团内部测试版。

发布周期的缩短给测试人员带来了很大的压力：以手工的方式每月一次全量回归测试已经相当困难，每周一次全量回归更是不可能的任务。

于是来往团队顺理成章地采用了自动化测试的实践，从而降低手工回归测试量。一方面，开发人员要为自己的代码编写单元测试，核心代码的单元测试覆盖率能达到 80% 以上；另一方面，测试人员也编写了大量系统级和接口级的自动化测试用例。

自动化测试在很多组织的敏捷导入中是一个难题：开发人员认为测试是测试人员的责任，不愿编写自动化测试；测试人员又不具备编写自动化测试所需的编程能力。

然而在来往团队中，快速验证产品、占领市场的压力驱使开发与测试打破壁垒，同时阿里长期的技术储备又大大降低了自动化测试的难度。

尤其在测试人员的能力方面，阿里有大量测试人员具备编写自动化测试用例的能力，这对于团队缩短发布周期起到了至关重要的作用。

2014 年下半，在来往产品的基础上，又孵化出了专门用于移动办公的即时通信产品“钉钉”。这支新成立的产品团队复制了来往团队的大部分敏捷管理与技术实践，并且以全功能子团队的形式改组了其内部结构。

钉钉团队最初组建时，内部子团队按照功能划分，有 iOS、安卓、服务端开发、测试、产品经理、设计师等团队划分。产品负责人陈航希望团队成员长期稳定专注某一块业务，提高端到端的业务响应力，因此将团队垂直切分为 4 组：语音通话、DING、基础 IM 功能、PC 版钉钉。

每个产品组都拥有完整的产品、设计、前后端开发、测试能力，对业务结果负责。为了协调各组的进度，在其上又增加了一层定期的组间会议。

可以看到，尽管没有明确地用 Scrum 的“特性团队”、“Scrum of Scrums” 等理论作为指导，但在业务压力、尤其是交付周期的压力驱动下，钉钉团队自主地发展出了同样的实践。

阿里的团队普遍承担很大的业务压力，对市场的快速响应能力是各个团队普遍的诉求。团队负责人对于特定的方法往往没有偏好，更注重最终达成的业务效果。

因此阿里的过程改进专家在建立了基础的需求管理、项目管理、配置管理、质量保障机制后，不约而同地把眼光投向了精益（Lean）。

（更多内容故事，请阅读图书《敏捷中国史》）

敏捷是一种重视质量、追求快速反馈的软件开发方法。它对行业的影响远不止几个编程实践，说它影响了 Java 技术栈的变迁，说它引领了 DevOps 和持续交付的潮流，甚至，说它在中国 IT 发展史上是浓墨重彩的一笔，都不为过。

然而，敏捷在技术人士中具有很大的争议，有人将敏捷奉为圭臬，有人对敏捷嗤之以鼻。

大家对敏捷的态度为何有天壤之别？如今很多人所认识的敏捷跟 Martin Fowler、Kent Beck 等先驱主张的敏捷有何不同？70 后与 80 后老程序员当年是如何突破自身技术成长困境，将敏捷引入中国的？

敏捷是如何从一个名不见经传的小流派，到如今，从自由职业者，到创业小团队，再到大型公司，无不接纳并大力应用它的？IT 领域最有影响力的巨头阿里、腾讯、华为的技术成长是如何深度融入敏捷方法的？

作为中国敏捷十余年发展历程的亲历者与推动者，资深老程序员熊节从整个中国 IT 发展进程审视敏捷，通过本课程带你一起重新经历一代程序员的青葱热血岁月，与你一起梳理中国软件工程领域 20 年发展的关键脉络。

不止于敏捷，你会切实感受到整个中国 IT 行业、乃至中国经济的发展。

作者简介

作者 | 熊节，优普丰资深敏捷教练，曾任 ThoughtWorks 总监咨询师、 CSDN 技术主编。 IT 行业打拼 18 年，在金融、零售、政府、电信、制造业、全球医疗等行业的信息化建设方面有着丰富经验。翻译了《重构》《软件工艺》《实现模式》等行业重要著作，是中国 IT 浪潮中敏捷发展的领航者之一。熊节拥有利物浦大学 MBA 学位。

插图 | 虎头锤，旅居墨尔本的老程序员，北邮博士、北大硕士，15 年编程经验。目前从事支付系统相关业务，曾转战区块链、通信行业。敏捷倡导者、手绘爱好者。