敏捷开发到底能为我们的产品研发节约多少成本？

作为一个软件项目产品经理，最终的目标是是否能如期保质保量地交付，并且更重要的一点，你需要向你的老板说明，你采用不同的开发方式到底能为他们节省多少钱。任何公司的老板都看重这一点。我自己也一直对敏捷和传统开发在不断地进行对比，可慢慢发现，如果工作中真的摒弃传统开发方法，完全按敏捷的步子来，那么很难计算出我们的成本。

为什么？最容易看出的地方就是对传统开发来说，抵制的是产品设计的变更，因为行业业务逻辑相对稳固，最终的主线需求是不变的，所以无论设计还是开发，这部分变更的成本都容易控制和核算。但对于敏捷开发来说，比如互联网行业经常用迭代式开发和增量式交付，来不断地更改产品设计，更改交付的模块，那这部分因为变更导致的成本是没办法衡量的，或者更严谨地说，这部分变更的成本，谁来买单呢？是自己还是客户？

也许有人会说敏捷中也有项目工作量呀！比如我们把用户故事拆分成任务，再用扑克估算法估算出较为准确的工作量。没错，但这并不是只有敏捷中才有的方法和手段，在传统的软件开发中，做规模较大的项目时，我们也会将功能模块拆分到可估算的颗粒度，比如一个工作时长为6～8小时的活动，用WBS分解和类比法来做工作量的预估，而敏捷中的用度量数据调优，在传统软件中我们也会用资产沉淀的数据，来做挣值分析和项目预算，任何项目都不抗拒历史数据的积累，这不是任何开发方式/方法的特点，而是人类在项目经验中不断的积累，对任何项目都适用。更重要的一点，并不是能预估工作量、能计算实际工作量就能得出成本，因为你必须还能得到损失的成本。

在一次敏捷会议中，其中QA阶段有个人提问：“敏捷如何来帮助我们控制成本呢？”有个很明确的回答：“并不是所有项目都适合用敏捷，要看你最后想达到的目标是什么，如果目标是看到某个产品在互联网用户中的增长率、产品反馈速度，那么敏捷可以帮你实现，但如果是成本，敏捷无法帮你控制成本，它无法来准确地估算。”

所以如果我们的项目是以交付为导向，是以成本、合同为验收目标，而不是用户数量，那么敏捷中适合我们的就是那些频繁的沟通和站立式会议，以及显而易见具有灵活性鲜明的状态板，因为这些优势和开发模型无关，就像饭前洗手一样，在任何时候都适用。