敏捷模式随着移动互联网的发展变得越来越普遍与流行，那么对B端产品来说，是否可以运用敏捷开发模式呢？如果可以的话，又有哪些注意要点呢？

在中国移动互联网流行之前的2011年以前，B端软件的研发大多还是传统的瀑布式研发的方式，后面随着移动互联网的发展，To C端软件普遍使用敏捷模式来做。

但是目前仍然还有很多人采用瀑布式方式来进行B端软件的开发，不看好敏捷模式进行B端产品的开发，那么重流程，业务高耦合度的B端软件是否适合敏捷的开发模式？

今天我们探讨一下什么样的B端软件适合敏捷开发，以及B端软件进行敏捷开发的一些要点，在此之前我们看一下敏捷的定义以及价值观：

01 敏捷的定义

敏捷是一种管理项目的方式。它将大型项目分解为可管理的小块，称为迭代（sprint）。在每次迭代结束时，都会产生一些有价值的功能，每次迭代期间的产出物都应该能够发布出去，用来获取市场用户的反馈。

02 敏捷价值观

正如“敏捷宣言”所宣称的，敏捷价值观如下：

交流比流程以及工具更加重要

运行的软件胜于完整的文档

与客户合作而非谈判

响应计划变更

敏捷意识到软件项目本质上是不可预测的。在任何项目过程中，市场，团队，战略都可能会发生变化，在产品推向市场之后，变化也是随时发生的，敏捷拥抱了这种不可预测性。通过将项目分解成小块，可以轻松地在项目中对功能进行优先级划分，进行添加删除，在传统的瀑布项目中，这是不可能的，敏捷模式大大增加了项目成功的可能性，也降低了市场试验成本。

03 敏捷开发适合B端产品吗？

了解了敏捷的定义以及价值观，我们实际上知道了敏捷开发的本质是什么，是拥抱变化，拥抱不可预测性，更好的应对产品的不可预测性。

一般来说B端产品在确定产品定位要做什么之后，相对来说公司需要管理的业务是比较固定的，HR,CRM,ERP等企业信息管理软件都有相对固定的业务以及流程，不像C端产品那样每个功能的推出，市场的反馈有很大的未知性。

所以从这种角度来说，C端产品天然就是更加适合敏捷开发的；B端软件，如果可预测性越大，那么实际上对于敏捷开发的需求强烈程度越小，基于这个概念你可以去判断你的产品对于敏捷开发的需求程度。

B端项目又分为那种单个客户定制化的项目或者适合大量客户的产品，对于一个面向广大市场的通用产品来说，产品时间跨度大，市场客户情况复杂，竞争对手多，这样的情况基本来说都是敏捷模式是更适合的一种情况；对于一些定制化的B端项目，如果项目周期跨度很长，为了减少不确定性，也是建议采用敏捷的方式来进行迭代；如果一些周期短的定制化项目，可以基于情况考虑瀑布式的开发方式。

04 敏捷模式开发的一些要点

很多B端产品公司想去实施敏捷模式，但是很难真正落地，或者最后搞的四不像，笔者将B端软件敏捷实施中的一些要点概括如下，希望对大家有一些帮助：

1. 如果要实施敏捷模式，公司首先需要在理念上面统一起来

首先我们要知道敏捷模式的实施不只是产研部门的事情，敏捷模式是全公司的事情，公司这边产研和业务，销售部门建立密切合作而非对立的价值观和文化。公司内部各部门通力协作，以客户为中心，形成产品快速迭代，快速推向市场，快速收集市场客户反馈，快速基于反馈来进行调整的闭环。

2. 实施敏捷模式，需要首先从组织架构出发

敏捷模式的建立先从组织架构的调整开始，产研需要建立一个支持敏捷模式的组织架构，每个敏捷团队人数在7-15人，不要超过15人，以7-9人为佳，里面包含PO，Scrum master，设计人员，开发人员，测试人员的角色。

如果项目比较复杂的时候，可以分割成为多个敏捷小组，在敏捷小组之上设置总PO，负责多个敏捷之间需求的协同（这个总PO一般就是产品负责人）。

敏捷小组应该尽量负责相对独立的功能模块，降低敏捷小组之间的耦合性，可以将和其他小组高耦合度的共通功能模块单独分成一个敏捷小组。

在产研部门之外，每个相关的业务部门，包括市场，运营，销售部门都要有项目的相应的Stakeholder, Stakeholder和PO 团队在需求业务，需求优先级，产品评审，产品发布方面密切合作，贯穿整个产品过程，共同协作为产品负责。

3. 几个角色的注意事项