敏捷开发为何总在ToB项目中铩羽而归呢？[通俗易懂]

我在10年ToB的行业产品研发和项目实施的工作中，不止一次听到关于“敏捷开发模式不适合大型ToB项目研发”的观点，坚持该观点的往往也都是资深项目经理和研发Leader。

这就很奇怪了，一方面最近这10年是敏捷开发在国内IT产品研发中用的最多和普及率最高的项目（产品）开发模式，特别是在互联网行业里混得风生水起，一个产品经理如果不懂Scrum或XP，都不好意思自称是产品经理。

另一方面大型企业的行业产品研发不断尝试敏捷的过程管理（例如：生产制造业的ERP，服务业的CRM，BILLING等系统），但最终收到的效果和传统瀑布模式比并没有显著提高，客户体验不好，项目周期延迟，开发bug多，需求变更适应性差，研发成本高昂等老大难问题依然存在。

敏捷开发的普及在当下仍处于冰火两重天的状态，在互联网中小型项目中玩得风风火火，在大型ToB项目中却又铩羽而归，受到业内人士质疑。

但不可否认的是无论ToC还是ToB的产品研发过程对需求变更适应性的要求只会越来越敏捷，不会再回到过去传统瀑布模式的研发体系中，至少这是业界的共识，只是用敏捷方法论还是混合方法论才是争议比较大的方面。本文将从项目（产品）目标，团队构成和研发过程三个方面分析这种情况出现的原因，并希望从业者一起为敏捷开发在ToB项目中的推广普及献计献策。

产品目标

一. 从项目（产品）实现目标来看敏捷开发的必要条件

敏捷开发成功的首要条件是项目（产品）目标的一致性认知，只有企业，团队和个人的目标在高度一致的情况，才能很好的利用敏捷开发带来的快速，灵活，低成本的优势。

这和互联网公司扁平化的管理模式的道理一样。ToB和ToC的项目（产品）最大的区别是这个目标还要加上同客户的目标一致性问题，在To C的项目（产品）中，研发团队对客户的使用目标是通过分析和预期得到的，客户很少实际参与决策（当然为提高客户体验，很多产品研发引入自愿者用户参与产品设计，但更多的是提供用户体验的反馈，而不是决策）；但在ToB的项目（产品）研发过程中，客户却是最重要的决策者之一（很多时候就是客户决策）。

出现这种情况，是因为大部分ToB的项目（产品）都是合同驱动的，先签合同，后开展产品研发或者项目实施，所以客户在将得到一个什么样的产品的问题上占有决策的主导地位。这时研发企业或者团队想要开展敏捷开发模式，如果不把客户的目标和研发团队定义的MVP产品目标以及后续迭代计划相整合，那敏捷开发是很难推进展开的。

1. 企业客户的软件目标是什么？

一般来讲，在ToB的大型企业级软件交付市场中，企业客户对于即将交互的软件总是希望能最大可能的解决目前企业的全部问题；能一次性割接和替换掉现有的老系统

这种最大化价值产品期待和敏捷开发的最简化价值产品（MVP）的理念是恰好是相反的，可以想象如果企业客户希望的第一个上线运行版本，是一套功能完整和彻底改进的产品，而你的开发模式又采用敏捷开发模式，这样的项目从一开始就注定是一个失败产品（至少从期望上看）。

2. 改造企业客户的产品预期

敏捷开发产品理念和企业客户的产品预期由于综上所述原因，存在天然矛盾，这就为软件提供商和企业客户提出了一道选择题：

1）如果企业需求变更小，项目预期周期短（恰恰是因为项目周期短，需求变更的可能性才小），请还是使用瀑布模式或者螺旋模式。

2）如果企业需求本身不稳定，项目预期又是一个长周期，那请使用敏捷方法。在当今激烈的市场竞争过程，如果项目周期是以年为单位开展实施的，恰恰需要用敏捷方法，因为需求从项目开始到结束必然会发生变化，如果还采用瀑布模式，得到的产品一定不是最后客户想要的产品。

而我们要在企业客户的产品研发中采用敏捷开发方法，首要条件是要说服企业客户转变产品预期，把产品目标从一次性的整体性解决方案改为小步快步的分流程分业务的迭代改进。

这是相当不容易的，在ToB的软件交付过程中，客户是合约权责的行权方，客户有理由要求得到与合同额价值相匹配的产品，所以除了从敏捷开发理念上去说服客户以外（靠理念说服效果最差），最重要的是要切入企业客户业务运营架构，从企业SOP（Standard Operating Procedure）中去建立企业核心core流程（服务或生产），区分核心业务流程优先级，为企业客户提供一套可行的产品迭代业务框架。 关于企业核心SOP Core流程可以参看：《初建电商优先关注的7个流程(一)》。

而MVP产品范围的定义一定要满足企业客户的Core业务流程中的Core业务。软件提供商在提供第一个MVP版本的功能框架中要选择实现完整的一个Core业务流程或者流程中完整的一个Core业务。例如：Request-to-answer （客户请求到响应）中的某产品咨询流程。

软件提供商为企业客户提供一套具备产品迭代优先级的企业Core业务流程框架（注意是框架不是具体需求）和第一个MVP版本功能范围，是建立和企业客户之间的信任，从而说服企业客户采用敏捷方法验收的必要条件。

3. 改造研发企业的内部KPI

要在ToB项目中成功实践敏捷开发，研发企业内部的KPI考核体系也需要随之调整。在传统ToB项目中，研发企业内部往往通过合同签约，客户阶段性验收和项目回款等考核体系来评价研发团队或项目实施团队，评估反馈者是客户（企业客户）。

这种评估和管理手段在敏捷开发中是无效的，敏捷的迭代单元是一个Core流程或者Core业务，同时敏捷的评估反馈者是最终用户的产品实际体验（是软件的最终使用者）。

有效的考核体系应该建立在有最终用户参与的产品反馈体系中，我们知道很多主流B2C的网站和APP在设计之初就把流量反馈和用户使用反馈等作为上线后的运营重点，这些产品用户一线的使用反馈才是在敏捷开发中，帮助修正需求和开发偏差重要考核依据。

4. 提供多系统并行的运维保障

如果在ToB项目中采用敏捷开发，以提供MVP产品的作为上线标准，那就会出现在未来的一段时间内新老系统同时并行运行的问题。上面讲过，在ToB的MVP产品定义，是实现一个完整的Core业务流程或者流程中Core业务，而这样就会出现企业其余业务流程或业务还需要在原有老系统中完成，这种多系统并行的运营模式，是企业客户不愿意看到的，这会带来运维成本高，运维难度大的问题。

要解决该问题软件提供商就必须提供一套在敏捷开发模式下支撑多系统并行需要的运维保障框架，包括：数据同步，业务接口调用，流程串接等。只有认识到多系统并行也是敏捷开发所带来的必然结果，并且用完整的运维保障去克服新老系统的衔接和过渡问题，才能使企业客户打消疑虑，愿意采用对MVP产品逐步迭代方式完成软件交付。

二. 从敏捷团队构成看敏捷开发的必要条件

相信很多在ToB项目中尝试过敏捷开发的朋友都有这样的经历，往往我们要实践敏捷方法，首先实践的是敏捷的迭代计划，规则和流程这些制度化的指标，例如：每个迭代Sprint控制在1-4周，每日站立会议，迭代中是否允许需求变更，是否遵守优先级等方面。

但我们常常忽略人的因素，从敏捷开发的观点看是：交付产品的关键因素是人，而非过程，所以我们对过程的精益求精，往往是以忽略“敏捷人”本身素质为代价的。

在传统ToB开发模式中，每个开发阶段都有相对应的组织或部门分工协作，细分每个步骤，从需求分析，架构设计，研发，测试，项目实施，项目管理都是由林林总总的部门和组织构成，而这些部门之间的沟通由接口人和接口文档构成，各自只负责自己的专业和领域，所以当需求发生变更的时候从上至下的变更成本高，大家都抵触。

而在敏捷的开发模式中，团队构建以MVP产品完整的端到端业务线为组织单元，不再以职能划分，不同的研发角色按完整业务流程混合搭配，组成特战混合团队，保证研发目标是最终用户的认可，为此不惜重构代码。

而每个参与团队的人员综合素质需要更加全面，产品经理要理解系统，研发要懂得设计，测试要熟悉客户，而全部成员都要懂得产品的概念模型。

这种特战混合团队的开发模式从当前的军队改革进程中可以窥见一斑，目前我国军队正在从传统按装备分类（类似我们的研发职能部门）的师级单位向混合旅单位转型，按照不同的作战方向（类似我们的业务线）为每个混合旅配置不同的装甲部队，火炮，陆航甚至战术弹道导弹等，以适应不同情况下（类似我们的产品需求）的作战需求。

所以以MVP为目标的敏捷开发，除了必要的一些规则和方法以外，最重要的是要从参与人的敏捷素质上要求，并建立敏捷的开发团队。

XP

三. 从开发过程管理看敏捷开发的必要条件

接着我们谈谈从开发过程的细节处，看敏捷方法在ToB中容易忽略的问题，为了描述方便我简单从：需求，计划，测试和重构四个方面入手谈敏捷，因为是敏捷，所以这四个方面并没有传统的顺序，而是相互融合的过程。

在此之前我们先得了解一下目前最为流行的两种敏捷方法：Scrum和XP(Extreme Programming)从差别，具体细节差别大家可以参看：《Differences Between Scrum and Extreme Programming》这篇文章，从总体上来讲Scrum是一套敏捷框架，它并没有具体的操作方法，所以对成员的敏捷素质要求比较高，比较敏捷经验丰富，能力比较综合或者是小型的研发团队。

而XP则对团队组成（包括客户），办公区域大小，环境（开发空间），需求的结构，交付周期，测试方法，编程方法（结对编程），计划，持续集成，重构都有具体的实践方法，所以对于喜欢用制度和规定来实践敏捷的企业，比较适合，更适合中大型研发团队。所以后面主要参考XP，作为ToB项目敏捷研发方法对比。

1. 需求

在传统ToB的软件交付过程中，同客户沟通，收集，分析，整理需求的工作都是由BA（或者叫需求分析师）这个角色完成，其他角色只是被动等待BA的输出文档，如：RFP（Request for Proposals）和RFS（Function Requirements Specification）,RFP文档负责与客户沟通，RFS文档负责与研发团队沟通。这样分工清晰的界面，在敏捷过程中却很容易严重限制需求响应的灵活性。

敏捷（XP）的需求，首先要求的是框架性需求，而不是一次性搞清楚所有问题；从客户需求到研发需求尽量采用一套文档，而不是多套文档间转换（需求失真往往是通过文档转换产生的）；大量采用概念模型方式验证和说明业务含义，减少纯文字描述性需求（大量文字描述会影响需求变更的代价）；而由于客户本身就是敏捷团队的成员，客户需求直接对接研发单位，传统BA向产品经理转型。

需求的分析重点也发生了变化，需求不再是大而全的收集和分析，而是根据企业的运营核心实体，核心运营流程，以MVP定义产品目标为方向的重点分析核心流程和核心业务。重点保障核心流程和核心业务实现完整的端到端贯通。

需求是敏捷开发的素材，这种素材不需要立刻填充完整，而是需要先有需求骨架（需求骨架用于制定迭代计划），然后需求内容和细节是要在开发中和用户不断碰撞的过程中逐渐丰满的。所以敏捷的需求分析过程是持续性的，迭代的，由粗到细的。

2. 计划

在传统ToB项目中计划的安排基本是以项目里程碑的框架形成的，如：需求， 开发，测试，上线，初验，终验等，而系统上线，这样一个关键里程碑的时间设定，往往是商务谈判的结果，并不是对需求实际分析和实践后的结果，而剩下的细分计划就是以上线时间点的基准倒推形成，当然最后结果就是80%的大型项目上线都要延迟（在我经历过的大型项目中好像就没有准时交付的），这种延迟更多的是软件提供商和企业客户之间的商业博弈的结果和技术性无关。

企业客户和软件提供商在对待项目计划的制定上，总是处于对立面，这是因为企业客户并没有把软件交付过程看成是一种相互协作的过程，而是一种商品交易过程。所以花了大钱肯定就要提出更快更多的要求。

如果要采用敏捷开发模式，在计划的制定上就要从整个系统这个很难技术化评估的单元（如：CRM系统），转移到具体实例化的某个流程和业务（如：完整的快消品订购过程），因为流程，业务和具体的功能是双方可以开展技术化辩论和评估的依据。

敏捷开发的计划安排，总是从某个完整的具体流程和业务入手，通过团队成员共同制定的。一开始的任务执行偏差是允许的，项目可以通过某个完整的一个Sprint的完成，实现对团队效率，能力和任务难易程度的评估，从而以此为基准制定其他计划。

所以敏捷的计划是在实践中开展修正的，一切以先做起来为目标，不会因为项目经理和企业客户还在对整体系统的上线时间点上争吵不休，而停滞不前。敏捷的计划是战术计划，更具备可执行性。

3. 测试

在敏捷的测试过程中强调测试用例的前置，这和传统ToB项目中在功能开发完成后，再编写测试用例的过程截然不同。测试用例前置到需求分析阶段同步开展，以测试驱动开发是敏捷方法的典型特征。

在敏捷的测试中我们简单分为单元测试（白盒测试）和验收测试（黑盒测试），在这两类测试用例前置到开发前编写，通过测试用例设计，我们会收到意想不到的效果。

1）单元测试（白盒测试）

在需求分析阶段就要求开发人员编写代码级的单元测试用例，这样可以让开发人员积极参与需求讨论和分析，深刻理解需求本质，由于为了保障用例编译通过，还需要开发人员依据功能要求预先编写功能接口，从而保障单元测试完整性。

用代码方式实现一套单元测试用例和功能接口以及相应的代码注释，你会收到第一个敏捷衍生品API文档（代码），在敏捷开发中提倡以代码（接口）和模型方式作为输出文档，尽量减少文字的运用，能用代码直接描述功能的就不用文字，最敏捷的描述功能的方法就是接口类，最敏捷的描述数据的方法就是数据模型。

你收到的第二个衍生品是代码解耦，通过单元测试用例来驱动后续的功能开发，可以让开发人员在投入具体编码前，站在客户端的角度整体性的去思考功能调用间的关系，而不是一头扎进具体的某个功能实例中思考另一个功能调用。这样好处是让你最终可以收获一套相对解耦的功能实现，解耦对于敏捷开发是至关重要的，直接影响到你的代码是否可以适应需求变更和重构。

2）验收测试（黑盒测试）

如果说在需求分析阶段，编写单元测试用例是从微观上实现代码接口的定义和限制，那编写验收测试用例就是从外观上实现功能的定义和限制。一般验收测试用例由QA和客户一同编写，首先确定验收测试用例模板（可以参考5W1H），通过测试变量的可调整，最终生成测试用例的脚本实例。

测试用例模板可以用作产品功能定义，在传统ToB项目的FRS中描述的大多数是静态功能（如：账户增加，绑定，删除等），文档中无时间，地点，环境等，所以开发人员如果直接依据FRS文档开发出的产品，很多都无法获得客户认可，是一套死系统。而如果采用测试用例模板获得是一套场景化的功能动态描述，更具适用性和友好性。另外生成的测试用例的脚本实例（带上具体变量枚举参数）则自然成为后续自动化测试的素材。

在传统ToB项目中往往通过细化分工完成协作，BA负责需求分析，Developer和QA依据BA输出的FRS编写单元测试和验收测试用例，所以FRS文档就成了上下游的衔接关键点，当我们把一切后续研发产生的代价和成本都押在一份没有沟通和反馈的文档上的时候，大家可以预知后面的产品会长成什么样。

4. 重构

我不止一次问过在ToB的项目中的资深工程师，我们的项目有开展过重构吗? 他们的回答是：“有重构，每年我们的版本都在升级，从1.0到2.0”，确实记得我参与过的一个项目从1.0一直升级到9.0，最后不得不换个系统名称。但系统升级显然不是系统重构，系统升级是功能升级，而系统重构是代码重构，代码重构并不一定会有功能升级，这有本质区别。

在我经历过的ToB的项目中没有一个是主动开展过代码重构过程的，原因大致有三方面：

1）系统所有权问题，一旦ToB的项目上线，系统所有权就是企业客户的，后续软件提供商就是再想优化和重构以前的代码，如果企业客户不愿意承担重构带来的系统风险，那也很难开展。

2）重构代码无利可图，对于软件提供商和企业客户来讲，重构都不能直接产生经济效应，企业客户需要的是功能，欢迎功能升级，拒绝无功能升级的重构；软件提供商需要的是合同，新功能带来新合同，拒绝无收益的成本投入。

3）怕重构，软件提供商往往已经达到谈重构色变的地步，记得有一次产品研讨会上我向企业领导提出了重构的想法，这位领导立刻打段我的话，说：“我们投入这么大的研发成本，就是希望不要再重复修改我们产品”。我想他一定觉得自己的产品是一架设计优美，做工精良的钟表。

重构是实现敏捷的必然之路，如果没有重构，我们怎么优化和适应对需求的理解呢？敏捷开发强调对需求的理解是从点到线再到面的过程也是和产品由局部到完整的迭代过程同步的，任何只想使用敏捷方法的形式（如：迭代周期，站立式晨会，任务跟踪等），而忽略敏捷方法的本质：鼓励重构，的系统建设想法都是错误的，这样做你并不能得到一个敏捷的系统。

总结

从业务发展趋势来说，未来ToB系统的需求只会越来越不稳定，没有哪个企业客户能保证年初的想法和市场需求到年底不会变化，这种需求变化频率从原来的年度提高到季度和月，这种现象也是不可逆转的，我们只能去适应和解决它。

而敏捷方法给我们指出了一条快速适应需求的路，敏捷可以给我们的系统带来更多的灵活性，但它并不能直接帮助软件提供商提高合同额，提高研发效率，对，你没有看错，敏捷并不是提高效率的手段，有时反而因为迭代开发还会延长产品交付周期，但敏捷带来了更好的产品需求适应性，选择敏捷模式同学们一定要记住。

因为篇幅和主题的限制其实关于敏捷的开展是否最终能成功还有一个关键因素，本文并没有涉及，这就是：敏捷设计，由于话题太大，需要另设立主题聊，所以我打算后续通过领域驱动设计（DDD: Domain-Driven Design）中聊聊敏捷的设计话题。

我们很多把敏捷形式开展的很好的团队，常常忽略了敏捷设计的重要性，就如同两条腿走路，断其一只都寸步难行，如果没有敏捷化的代码和模块设计，再好的敏捷想法也不能通过系统本身实现。

本文由 @乌士儿 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自PEXELS，基于CC0协议