啥？这也叫敏捷？

敏捷是不是就是实践Scrum或极限编程方法、落地自动化测试、自动化部署和提高发布频率呢？都不是！

01

—

很多人在公司落地敏捷，会遇到一个困境。为什么敏捷教课书里写得头头是道，但在实际落地时却处处碰壁？

我总结，这里有一个重要因素是，敏捷教科书里讲的案例大多是To C（To Consumer，面向消费者）的，而我们很多人在自己公司面对的是To B（To Business，面向商业用户）的场景。

敏捷思想的提出是在2000年左右。那是国外互联网兴起的年代。而互联网是To C的。因此，敏捷教课书中的案例大多也是To C的产品开发过程。

大部分的敏捷教科书都教导我们，MVP（最小可用产品）一定要足够小，目标是尽快推出一个只具有最核心功能和卖点的产品，快速上市，从市场和用户那里获取反馈，也就是真实的日活和月活数据、用户行为数据，并根据这些反馈不断调整和优化产品，实现产品的持续迭代、优化和升级。

我们所有人都一起见证了微信从一个相对简单的语言聊天工具，迭代成今天成为半个操作系统的平台产品的过程。这就是To C的玩法。

在非互联网的世界，绝大多数情况下我们面对的都是To B的场景，包括为业务部门开发和维护系统。以笔者所在的金融行业为例，公司推出一项新业务，往往都不是什么创新产品，大多数情况下，都是市面上已经有的产品或服务，这些新业务要在一片红海中挖掘机会。

这就导致了这些业务的产品和服务范围，必然是你有的我也要有，你没有的我就要有，要在同行已有功能和服务的基础上，推出更多的增值服务，才能形成差异化竞争。

这导致的后果是，针对这些新业务的所谓“最小可用产品”，也就是MVP，也会非常的大而全。这就导致大部分这类项目，一启动就要做几个月甚至一、两年。

这也是大多数传统行业的常态。

因此，我们不能直接套用敏捷教科书的方法和案例，必须在充分理解其价值观和原则的基础上，面对的实际场景因地制宜。

真假敏捷？

在To B场景下，需求大而全带来的直接问题就是开发过程复杂，周期长，首次交付上线动辄需要一、两年的时间。这也导致很多这类项目虽然运用了Scrum，但却是假敏捷。

大多数这类项目不得不采用Water-Scrum-Fall的模式，需求、设计、集成测试和发布是瀑布过程，只有开发阶段拆成了很多所谓的Sprint，其实这个过程中每个Sprint都只是输出不能上线的半成品，大家感觉自己“敏捷”了，玩得很High，但是从结果上来说，和原来的瀑布模式并没有本质上的区别，所谓的敏捷，其实只是穿了个马甲的瀑布。

而是否每个迭代都有可上线的产品，是评判真假敏捷的唯一标准。当然，前面提到过，针对我们经常面对的To B项目或产品，要在几个星期、几个月之内就上线新产品，是不现实的。所以我给DevOps一个更简单的公式是DevOps = MVP + 持续交付。

实际案例

我来以一个曾经做过的项目，作为具体例子来展开这个问题。

当时业务方找到我们，要求我们在半年内从无到有，搭建一个新的业务系统，上线开门迎客。

说句心里话，半年内上线一套新系统，对于我们来说肯定说是Mission Impossible。

虽然我们是采购第三方成熟的系统，这套系统应对国内的监管要求和一般的客户需求都没有问题，但我们作为全球金融企业，有大量的内部合规要求，包括很多的非功能性需求，比如容灾设计、安全、权限等，都要满足，需要第三方厂商进行大量的整改。

要满足上线要求，我们IT这边也有基础设施架构设计、系统架构评审、采购服务器、配置服务器、安装部署、配置环境、系统交付等，配合各种严苛的上线评审、测试和流程。简单来说，这个项目的首次上线，根据我们过往的经验，没有一年的时间，肯定是拿不下来的。

虽然难度大，但是有困难就得想办法解决。既然时间和目标不能改，我们就看看范围和细节能不能调整？

例如，业务方希望能够尽快拿到牌照，以获取资质招揽客户，想以最快速度提交牌照申报材料。而其中一份资料就是我们的系统和监管机构进行联测的测试报告。业务方要求我们在3个月内完成联测，从监管机构那里取得报告。

把一个起码要一年时间才能完成的事情压缩到3个月内，这当然是不可能的。后来，我们和这个机构进行交流，发现这个联测可以从我们的测试环境发起，而且第三方厂商系统的原始功能就能完成这个联测。而在3个月内在我们的测试环境部署这套系统的原生版本完全可行。

我们就围绕着这个阶段性目标行进，并按时满足了业务提交申报材料的要求。这样下来，我们就可以一边等待监管机构冗长的审批过程，一边继续实施这个项目。

接下来的目标是要使系统尽快在生产环境上线，让业务方有信心随时开展业务。但项目开始的时候，业务方的功能性需求、集团内部的合规需求和IT的非功能性需求加起来就有超过60个需求，需要第三方厂商进行大量的整改，随着项目的推进，新的需求也在不断地涌现。

我们与业务方明确了这个阶段的目标就是要使系统满足能上线的要求，应该优先整改最核心的IT非功能性需求，其它的需求，可以在上线后通过持续交付的方式逐步满足。业务方答应了我们这个方案。

于是我们形成这样一个“以阶段性业务目标为维度”的持续上线过程，分别包括了联测、核心系统以及三个不同的增值业务。这也是我们前面提到的公式“DevOps = MVP + 持续交付”的具体体现。我们前后用了7个月的时间从无到有实现了系统上线，也就是完成了MVP，随后一旦有某个需求完成了，便可以随时部署上线，实现持续交付。

这里的核心重点就是每个迭代都必须有明确的阶段性业务目标，并围绕着这个目标确定这个迭代的范围和具体交付。套用到Scrum里面，就是每个Sprint都要有目标。

总结

从我最后的案例，大家也可以看出，我并没有直接套用任何敏捷教科书的具体方法和工具。我不断强调，要围绕着业务目标和阶段性目标，抓核心需求。以不断满足阶段性目标来持续上线，增量发布。

实践和工具没有放之四海而皆准的标准，只有价值观和原则是普世的。

在笔者所在的公司，经过过去多年全集团的敏捷与DevOps转型，我觉得我们最大的收获并不是多少团队在实践Scrum或极限编程、自动化测试代码覆盖率提高了多少、发布频率提高了多少等，而是敏捷与DevOps的思想深入人心，DevOps & Agile ，简称DnA成了每个人的DNA，我们做事情的思维方式改变了，我们接到一个新的需求，首先思考的是如何更早、更快地开始和交付，先完成再完美，更重视迭代式演进，这种思想不光运用在软件开发，也可以运用到了其它任何类型的项目和任务。