我在10年ToB的行业产品研发和项目实施的工作中，不止一次听到关于“敏捷开发模式不适合大型ToB项目研发”的观点，坚持该观点的往往也都是资深项目经理和研发Leader。
这就很奇怪了，一方面最近这10年是敏捷开发在国内IT产品研发中用的最多和普及率最高的项目（产品）开发模式，特别是在互联网行业里混得风生水起，一个产品经理如果不懂Scrum或XP，都不好意思自称是产品经理。
另一方面大型企业的行业产品研发不断尝试敏捷的过程管理（例如：生产制造业的ERP，服务业的CRM，BILLING等系统），但最终收到的效果和传统瀑布模式比并没有显著提高，客户体验不好，项目周期延迟，开发bug多，需求变更适应性差，研发成本高昂等老大难问题依然存在。
敏捷开发的普及在当下仍处于冰火两重天的状态，在互联网中小型项目中玩得风风火火，在大型ToB项目中却又铩羽而归，受到业内人士质疑。
但不可否认的是无论ToC还是ToB的产品研发过程对需求变更适应性的要求只会越来越敏捷，不会再回到过去传统瀑布模式的研发体系中，至少这是业界的共识，只是用敏捷方法论还是混合方法论才是争议比较大的方面。本文将从项目（产品）目标，团队构成和研发过程三个方面分析这种情况出现的原因，并希望从业者一起为敏捷开发在ToB项目中的推广普及献计献策。
产品目标
一.从项目（产品）实现目标来看敏捷开发的必要条件
敏捷开发成功的首要条件是项目（产品）目标的一致性认知，只有企业，团队和个人的目标在高度一致的情况，才能很好的利用敏捷开发带来的快速，灵活，低成本的优势。
这和互联网公司扁平化的管理模式的道理一样。ToB和ToC的项目（产品）最大的区别是这个目标还要加上同客户的目标一致性问题，在ToC的项目（产品）中，研发团队对客户的使用目标是通过分析和预期得到的，客户很少实际参与决策（当然为提高客户体验，很多产品研发引入自愿者用户参与产品设计，但更多的是提供用户体验的反馈，而不是决策）；但在ToB的项目（产品）研发过程中，客户却是最重要的决策者之一（很多时候就是客户决策）。
出现这种情况，是因为大部分ToB的项目（产品）都是合同驱动的，先签合同，后开展产品研发或者项目实施，所以客户在将得到一个什么样的产品的问题上占有决策的主导地位。这时研发企业或者团队想要开展敏捷开发模式，如果不把客户的目标和研发团队定义的MVP产品目标以及后续迭代计划相整合，那敏捷开发是很难推进展开的。
1.企业客户的软件目标是什么？
一般来讲，在ToB的大型企业级软件交付市场中，企业客户对于即将交互的软件总是希望能最大可能的解决目前企业的全部问题；能一次性割接和替换掉现有的老系统
这种最大化价值产品期待和敏捷开发的最简化价值产品（MVP）的理念是恰好是相反的，可以想象如果企业客户希望的第一个上线运行版本，是一套功能完整和彻底改进的产品，而你的开发模式又采用敏捷开发模式，这样的项目从一开始就注定是一个失败产品（至少从期望上看）。
2.改造企业客户的产品预期
敏捷开发产品理念和企业客户的产品预期由于综上所述原因，存在天然矛盾，这就为软件提供商和企业客户提出了一道选择题：
1）如果企业需求变更小，项目预期周期短（恰恰是因为项目周期短，需求变更的可能性才小），请还是使用瀑布模式或者螺旋模式。
2）如果企业需求本身不稳定，项目预期又是一个长周期，那请使用敏捷方法。在当今激烈的市场竞争过程，如果项目周期是以年为单位开展实施的，恰恰需要用敏捷方法，因为需求从项目开始到结束必然会发生变化，如果还采用瀑布模式，得到的产品一定不是最后客户想要的产品。
而我们要在企业客户的产品研发中采用敏捷开发方法，首要条件是要说服企业客户转变产品预期，把产品目标从一次性的整体性解决方案改为小步快步的分流程分业务的迭代改进。
这是相当不容易的，在ToB的软件交付过程中，客户是合约权责的行权方，客户有理由要求得到与合同额价值相匹配的产品，所以除了从敏捷开发理念上去说服客户以外（靠理念说服效果最差），最重要的是要切入企业客户业务运营架构，从企业SOP（StandardOperatingProcedure）中去建立企业核心core流程（服务或生产），区分核心业务流程优先级，为企业客户提供一套可行的产品迭代业务框架。关于企业核心SOPCore流程可以参看：《初建电商优先