腾讯和银联都在用的开发工具，究竟有何魔力？

来源：CODING

最近，在美版知乎 Quara 上有一个问题火了。

Why do some developers at strong companies like Google consider Agile development to be nonsense?

为何谷歌之类大厂程序员认为敏捷开发是毫无意义的？

在这个问题下面，Rocket 程序员Jasmine Adamson 表达了敏捷开发原则是废话的观点：

// 没有人愿意接受改变需求。这就是第二个敏捷原则，普遍被厌恶的一个。

// 部分公司在这方面做的很好，但是大多数团队无法很好的掌控敏捷时间的尺度。交付时间表通常是基于大的更新，而大更新不属于敏捷。

// 这意味着每个人每周都要花 30 个小时在开发上，还需要花 10 个小时管理自己和工作负载、与他人沟通等等。

…

在他的回答中，他认为敏捷开发的思想很好，却是不可操作的，没有人会真的用这种方法来进行开发。

然而没过不久，前 Google 工程师总监 David Jeske 就站出来提出了不同的意见，他认为：

// 敏捷对许多人来说意味着许多事情。我认为简单的高级敏捷宣言与谷歌工程师对软件开发的思考方式非常接近，但这一切都是在综合文档记录工作软件辅助的情况下实现的。

其实，不只是 Google，同样证明了敏捷开发在特定工具辅助下可行性的还有另外一家中国公司——腾讯 Tencent 。

故事得从 2006 年说起。

当时的腾讯，规模已经开始膨胀。开发模式急需规范和标准化，到底走 IPD（集成产品开发） 还是 Agile（敏捷开发） 的路线，公司管理层也拿不定主意。

直到研发管理部门与 ThoughtWorks 公司接触。

ThoughtWorks 公司是一家创办于 1993 年的全球性软件及咨询公司，它的首席科学家 Martin Fowler 是当今世界软件开发领域最具影响力的五位大师的其中一位，与此同时他还是敏捷软件开发方法的早期开拓者和敏捷宣言的创始人之一。

正是这次接触，让腾讯公司最终敲定引入敏捷产品开发模式。

在往后的十余年里，这个涉及范畴包括敏捷项目管理和敏捷软件开发的开发体系支撑了 QQ、微信、王者荣耀等众多核心业务的技术开发。

而与 Google 工程师总监 David Jeske 不谋而合的一点是，腾讯也认为敏捷开发需要与相应的工具软件配合才能发挥最大的功效。

于是在 2018 年，腾讯投资一亿元入股云端敏捷开发平台 CODING ，用来进一步完善其敏捷开发工具体系。

现在，这款云端敏捷开发平台面向公众免费开放。

扫码即可注册 不限成员，免费使用
1.什么是敏捷开发？

---

传统的开发模式，都是严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。 通常需要等到前一步完成之后再进行下一步，而且一旦前一步确认完成了，便只允许少量修改，不允许多改更不许大改。 就像你在餐厅一次性点了 18 个菜，菜做出来了就不允许加工了，更别说回炉，而且这 18 个菜不是一个一个上桌的，而是一次性端上桌。 这种采用严格预见性方法进行开发的模式就是传统的瀑布开发。 相信你也看到了，使用这种传统开发模式会严重降低开发自由度，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。 然而客户的需求是不确定的，也是随时间变化的，这样的开发模式越来越不适应互联网时代的开发需求，甚至有论文统计他是造成 70% 软件开发失败的原因。 正如你可能吃完十道菜之后，觉得吃饱了，后面八道菜不要了，但是这样的需求在之前的点餐模式当中不可能会得到满足，而这会导致你的体验极差。 于是新的点餐模式被发明出来了：一道菜一道菜的上，您先尝尝合不合口味，再决定之后的菜上不上、多久上、上多少。 这种随需求变化立马做出开发结构变化的开发模式就是敏捷开发。 敏捷开发的提出来源于 2001 年 2 月，包含 Martin Fowler， Jim Highsmith 在内的 17 名业内著名的软件开发专家齐聚美国犹他州雪鸟滑雪圣地，举行的一次敏捷方法发起者和实践者的聚会。 在这次会议上面，他们正式提出了 Agile(敏捷开发) 这个概念，并共同签署了《敏捷宣言》。 敏捷宣言强调的敏捷软件开发的四个核心价值是：

• 个体和互动高于流程和工具
• 工作的软件高于详尽的文档
• 客户合作高于合同谈判
• 响应变化高于遵循计划

以此宣言为核心的敏捷开发是一种以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。 在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。 换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 使用这种方法之后，开发的灵活性得到了极大的提升，然而另一个问题又跟着出现了—— 过度零散的代码以及频繁增减的需求让项目管理变得极其复杂，而不断地变化也让人力安排以及协同合作变得困难重重。 一桌点 18 个菜，中途频繁增添菜品可能容易处理，但是十桌，一百桌呢？ 大量的简单问题会汇聚成一个复杂问题，而这恰恰就是很多人认为敏捷开发无意义的根源所在。 然而事实上，在像 Google、腾讯 一样的大厂中，一种新的技术工具早就被开发出来并成功解决了这个问题。 2. CODING 就是这样的一款软件

---

人脑要花大量的时间将复杂的问题逐渐拆解成简单的问题并解决，但计算机不一样。
CODING 的产品设计理念就是使用技术手段，将复杂的问题隐于后台，通过系统完整的功能模块帮助企业完成从需求管理到开发测试到集成上线全流程动态化管理，从而帮助企业在需求不明确，市场变化快的情况下提升开发自由度，为逐步明确需求、及时响应变化创造可能。 最终，将 开发各个角色的工作内容和进度汇总于个人工作台，进而从根本上解决项目大量细分后的代码零散问题以及需求快速变化下的资源配置问题。
为了完成上面这些步骤，CODING 的产品经理，通过严密的论证及测试，最终将功能划分为： 敏捷开发管理 以及 DevOps 自动化 。 其中，敏捷开发管理是平台设计的核心内容。

CODING 为了更好的将敏捷理念与工具进行结合，让每个不熟悉敏捷开发的个人或者团队，也能利用这种方法来提升开发效率以及代码质量，甚至还跟国内做敏捷认证培训的机构优普丰有深度的合作，邀请国内的几位敏捷大师来做顾问，共研产品。

其次，通过 DevOps 模式进一步提升团队开发效率，减少每一处不必要的时间 支出。 所谓 DevOps 是 Development 和 Operations 的一个组合词，是过程、方法与系统的统称。这种方法被很多大公司用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。 它是一种重视“ 软件开发人员（Dev）”和“ IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。 透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 DevOps 的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。 截至今年八月，已经有包括中国银联、富士康、复旦大学在内的数十家知名校企与 CODING 达成长期合作。 现在，为了顺应平台核心理念，为广大企业提升开发效率，节约开发成本，CODING 平台面向公众免费开放，也可点击 阅读原文 免费使用。

扫码即可注册 不限成员，免费使用