vlambda博客
学习文章列表

此前，InfoQ 曾发表了谷歌前工程总监 David Jeske 在 Quora 上对敏捷开发的一些言论，他认为：敏捷开发的一些思路并不适合谷歌的革命性工程项目，比如短迭代、低文档等，并在文章中给出了他的理由和改进想法，这篇文章迅速引起了国内开发者的激烈讨论，知乎上相关话题《为何谷歌之类大厂程序员认为敏捷开发是瞎扯淡？》被浏览了 58 万余次，百余位用户发表了自己的看法，部分有代表性的高赞回答对“中国的敏捷开发水平和文化不甚友好”，比如：

延展阅读：

程墨 Morgan 提到：“既然产品设计者都讲不清楚具体需求，而且需求还总变，那就用敏捷方法哄你开心好了，这就是“敏捷”一下子流行起来的原因...... 以我个人的体会，可以搞敏捷，但是很容易陷入“伪敏捷”的陷阱......”

熊节表示：“他们（谷歌）说，他们（谷歌）发现敏捷有很多问题，我觉得，说的很有道理。一个方法用了十年，肯定会发现很多问题，肯定是要不断演进完善的...... 但是国内企业的配置管理水平、自动化测试水平和代码质量，根本啥方法都没有好吗...... 很多人有一种莫名其妙的脑回路，谷歌说敏捷是瞎扯淡所以我也说敏捷是瞎扯淡。Linus 从来不写单元测试所以我也从来不写单元测试。这个，人啊，贵在有自知之明。”

知乎网友七月在线：因为客户和 PM 都没法一次性完美描述出他们的整体真实需求，经常是每次提出部分有代表性的需求。既然如此，那我们何不每次就做好一部分？就比如下图，先做个前半身就去上线，后半身等下个阶段在做……

所以，为什么大部分的声音不看好敏捷开发的实践？这一方法论在企业推进落地的过程中是不是出现了一些阻碍？如何正确理解这一方法？如何解决这些阻碍？敏捷开发适用于什么类型的项目和场景？本文，InfoQ 采访并咨询了多位敏捷开发行业的技术专家，一起探讨敏捷开发在国内的落地情况。

纵观所有评论，大部分不看好敏捷开发的开发者提出了几点原因：一是项目缺乏整体设计，客户和产品经理的需求不固定且变更频率较高；二是会议流于形式，没有讨论出结果反而浪费了很多时间；三是盲目追求速度，一再压缩开发和测试的时间；四是企业的基础工作还未做好，比如没有成熟的自动化测试手段，盲目搞敏捷开发，往往会变成“伪敏捷”。

如上种种让很多敏捷开发流于形式，这本身也来源于实施者对敏捷开发的误解。Dell EMC 敏捷与精益创业咨询师袁店明在接受 InfoQ 采访时表示：不论国内还是国外，都有很多开发者对敏捷开发存在误解，就好像每个人心中都有一个哈姆雷特一样，不同的开发者对敏捷开发也有着自己的理解，以谷歌的前工程总监 David Jeske 为例，他对此的理解更侧重于短迭代和低文档，基于此做出的判断难免不全面。

袁店明补充道，敏捷开发的 4 条核心价值观和背后的 12 条原则是从无数实践和方法中抽象出来的理论，因为单一的开发方法都有其优点和缺点。

2001 初，17 位代表各种轻量级软件开发过程流派的领军人物聚集在一起，讨论当时正在实践的各种方法哪种方法是最好的。然而，这些人并没有达成一致，由于都是面向对象的高手，所以就讨论并抽象出所有这些方法背后的原则和价值观，这就是后来的敏捷宣言。

考虑到这样的诞生过程，当开发者将敏捷开发的理论运用到实践中时，一定是在遵循原则的情况下结合自身情况适当调整，比如迭代周期并不是必须一周，而可以在一到四周之间浮动；低文档并不代表不需要文档，只是“可工作的软件胜于面面俱到的文档”等。

简单来说，敏捷开发只是一个指导思想和原则，并没有给出具体的实践步骤。在实际的工作中，如果企业只是一再对外强调敏捷开发，这没有意义，更多的是说清楚为了达到组织目标的过程中遇到了什么问题，在敏捷原则和核心价值观的指引下，哪些实践和方法可以帮助达到组织的目标，或者解决这些问题从而达到组织目标。然而，如果本身对敏捷开发就存在误解，这很容易导致错误的实践方式。

在过往实践中，国内外也有很多企业在敏捷开发上做出了很好的示范，比如华为、诺基亚（包括前阿尔卡特朗讯）等通信企业，甚至一些传统的大型企业。但是，正如熊节所言，国内大部分企业在这方面踩过很多坑。袁店明表示，如果一家企业连基础设施都没有建好，怎么做到迭代式开发呢？

与瀑布式开发相比，迭代式开发的周期更短，原来可能是一年一个瀑布，一年才做一次完整的回归测试，虽然整个过程的代码也是不断提交的，但如果换成是迭代式开发，即便一个月一次迭代，一年也需要进行 12 次迭代，回归测试的量就是原来的 12 倍，如果还是单纯依靠开发者本能，不采用自动化测试的方法，遇到问题很难定位，这时的迭代式开发往往只是概念引入，技术上没有跟进。

此外，很多开发者对敏捷开发的“短迭代和低文档”有误解，袁店明在采访中表示，短迭代并不意味着每个周期结束必须将产品交付给用户。当然，如果有能力交付用户体验肯定很好，如果没有，开发团队交出一个潜在可用的产品即可，至少需要通过评审才能判断需求是否合理，逻辑是否正确，从而判断是否需要进行调整。这也是迭代式开发的优势之一，可以提前判断产品设计的合理性。

至于文档，敏捷开发虽然倡导可运行的软件胜过面面俱到的文档，但并不等于没有文档。袁店明在采访中表示，文档的作用可以分为两类：一类是记录和传承；另一类是沟通。记录主要用于保留架构设计和所有产品需求，这部分内容不仅重要，还需要尽可能做到透明化，实时反映需求的变化，需求的描述也应该更加具体和详细；至于沟通，小范围沟通的场景下，面对面沟通显然比文档更加高效。

技术的诞生一定是为了解决问题，不论公司是采用瀑布式开发、迭代式开发还是两者兼而有之，只要能够解决实际问题，都是可行的解决方案，尤其是在没有完全理解敏捷开发的概念时，袁店明不建议盲目上手实践。

可能很多人会有疑问：敏捷开发是不是有具体的适用场景？在 David Jeske 的回答中，他就曾指出这一方法不适合谷歌的革命性工程项目。袁店明则认为，不同规模的项目确实需要分开看待，但并不是说就一定不适合，针对大型组织，现在已经有了很多大型开发框架，比如：

• LeSS：大规模 Scrum，以 Scrum 为基础。LeSS 分两个模式，LeSS 模式宣称适合 8 人团队、最多 8 个团队共 64 个人的情况，LeSS HUGE 模式则号称可适应数千人规模的产品研发；在敏捷方法方面，LeSS 以 Scrum 为核心，工程实践维度，有实践指导材料；

• SAFe：大规模敏捷框架，完整的 SAFe 框架可以分为四个层级，团队级适合 5~9 人团队、项目群级适合 5~12 个团队（约 50~125 人）、大型解决方案级适合数百人规模、组合级适合 500~1000 人规模；敏捷方法论方面，介绍了 Scrum、XP、Kanban 方法，主张团队自主选择，工程实践方面有所提及，但没有特别详细的介绍；

企业要结合自身的组织架构、人员水平和业务现状进行选择。以组织架构为例，创业阶段企业的业务单一、所以组织结构通常是扁平化的，成长阶段企业会快速构建起层级组织结构以适应不断增长的企业规模，成熟阶段的企业往往采取矩阵式组织结构以支撑企业多元化的业务。

如果企业在实施敏捷开发后，依旧维持需求和产品团队、开发团队、测试团队，各个团队各自为政，老死不相往来的方式，敏捷开发肯定要失败。在敏捷开发中，往往一个 Team 就是一个特性团队，一个可以交付产品的特性团队，一个端到端的团队。如果是一个很大的产品，则可以按照子系统划分团队。由多种技能人员组成的特性团队是非常重要的，对小公司来说， 建立特性团队相对容易， 但对大公司来说，这简直就是一场革命，肯定要触动不少人的利益，有既得利益者的阻挠， 这是非常难的。

所以，很多公司虽然了解敏捷开发的好处，在小范围内做了试点并收获了正向反馈， 但现阶段还不适合， 最后往往不了了之。

无论国内还是国外，大公司还是小企业，敏捷开发都已经有了无数的成功案例。这些年，软件工程中一些好的实践，比如持续集成、测试驱动开发、结对编程、看板等都来自于敏捷开发。可以肯定的是，敏捷开发是一种非常好的软件开发模式，但当一件事情从开始就理解错了，那以后的路只会越走越偏。企业决定实践敏捷开发前，请先检查组织内部是否已经做好准备，相关人员是否对此有正确的理解，全靠开发者本能的狂奔，肯定不会走太远。