“ 我们是银行的软件开发部门。尽管公司这几年自顶向下力推敏捷开发，但是实现端到端全面敏捷的项目还是凤毛麟角。虽然不少业务人员开始接受敏捷的理念，但是在具体项目实施上，还是更接受传统的瀑布项目计划与承诺。我相信我们的情况具有广泛的代表性。对此，与其抱怨业务‘不解风情’，不如深入理解业务部门的需要，找出更适合业务特点的方法。”
预计阅读时间：8分钟
01
—
To C产品与业务项目的区别
我们看到各种敏捷教科书里很多端到端的敏捷案例都是像互联网产品这样的面向消费者（To C）的产品的，其需求和用户都是不确定的，产品经理能决定这个产品是怎样的。这类产品的具体的用户和需求，是一个需要不断探索和验证的过程。整个过程最关键的是试错——更快地开始行动并通过真实的市场反应获取反馈。因此也不适合和不可能预先做长期的计划。
但是作为银行的软件开发部门，我们面对的情况则完全不一样，业务作为甲方是需要确定性的。针对一个需求，尽管可能还非常概要，我们需要明确回答要多长时间和多少预算才可以完成，而敏捷开发，确实无法在一开始回答这个问题。虽然有敏捷计划方法（故事点和测速），但通常需要几个迭代的过程。因此有业务人员会说“敏捷就是不做计划的借口”（尽管采用瀑布计划，也不见得真的可以准确地回答这些问题）。不管准确与否，业务需要一个承诺，因为他们需要以此给客户一个承诺。
02
—
为什么业务不能接受MVP
我们知道，最有效的降低项目交付风险的方法就是定义最小可用产品（Minimal Viable Product，MVP），然后快速交付出来给用户体验，以收集反馈，持续改进产品和进行产品的长期演进。这一点对于To C的产品尤为重要。
大家可以回忆一下2011年腾讯刚推出微信时，它有多简单，但正是这一简单的版本（MVP），由于已经实现了最核心的语言聊天功能，大大拉近了人与人的距离，迅速得到了市场的认可，经过多年的演进，今天已经成为移动端最重要的平台级产品。但是当初谁也无法预测这样一款产品到底市场会否接受，主要受众会是谁，有没有竞争对手在开发同样的产品。以最小成本和最快速度向市场推出成品（MVP），在这个阶段，是个验证想法（idea）的过程，如果市场反应并没有预期的好，要么及时通过收集到的真实的产品反馈进行调整，要么放弃掉这个产品止损。唯快不破，快速试错，是像互联网产品这样的To C产品的生存法则。最近，腾讯又发布一款新产品——腾讯文档（在线跨平台协同文档编辑工具），目前的版本也是极度简单，就是一个活生生的MVP的例子。
对于我们的业务部门来说，大多数情况下，我们并不是推出一个市场上没有的新产品，而往往是市场的追随者。比如我们要做的基金外包业务，市场上已经有多个竞争对手在做了，如果竞争对手在提供10项服务，而我们只提供3项（MVP），客户根本不会选择我们。当我们的业务去询问客户需要我们提供哪些服务时，会被反问我们能提供哪些服务。我们不能从客户那里得到准确的需求，但是我们必须推出比竞争对手更丰富和更好的服务。简单地说，只包含最核心服务的MVP对于业务来说是卖不出去的。
03
—
瀑布与敏捷的和平共处
2017年，面对小米的困境，雷军曾说过守正比出奇更重要：“遇到问题的时候，大家希望用奇招来逆转，这是错的。遇到困难一定是某个基本功出了问题，守正比出奇更重要。” 通过守正，小米实现了销售上的逆转。
业务需要知道的交付时间和成本问题，尽管一开始确实很难回答，我们是无法回避。我们依然需要拿出传统项目管理的基本功——工作分解结构（WBS）、任务间的依赖关系、每项任务的大概估算以及找出关键路径这样的瀑布计划方法。我们知道，对项目的理解是越到后期越明晰的，整个软件开发和交付过程也充满了不确定性，对计划进行持续和及时的调整和修正非常重要。Microsoft Project在这方面是很好的工具。
即使在整体上很多项目不得不以瀑布计划的方式进行，但并不妨碍我们在具体实施过程中适用性地采纳敏捷实践。
笔者最近的项目是帮助业务部门在国内开展基金外包服务，核心系统都是采购的，我们的工作主要还是在银行内部搭建符合集团灾备要求的服务器架构、配置环境、安装应用、安全测试、满足上线要求的各种非功能性要求等。整体上来说，是一个非常瀑布的过程。为了满足业务规划，我们也必须回答是否能在目标日期前完成。
通过对项目上线所需要的所有要件进行尽职调查，得到了整体的瀑布项目计划，对目标日期能否上线做到了心里有数。同时，我们采纳了以下的敏捷实践：
与业务部门采用了像JIRA这样的敏捷工具记录和跟踪所有的任务和变更，并通过JIRA进度板和每日站会进行持续讨论和跟踪。
由于核心系统是采购的，大部分的开发工作由供应商来完成，我们通过Scrum让供应商的开发人员在每个Sprint聚焦在有限的最重要的交付上，从而让他们有更明确的短期目标和更快的交付速度，并实现持续交付。
为了实现更多的增值服务以满足客户期待，项目所采购的系统比较多，每个系统的应用架构又不一样，运行的操作系统和数据库也有差异，需要对每个系统进行单独的服务器架构设计，导致服务器数量非常多。同时，业务部门需要核心系统尽快上线以申请牌照。我们对整体计划进行了拆分，先交付牌照申请所需要的核心系统，这样业务部门的牌照申请可以和后续的增值服务系统的交付同时进行，使整体交付更加敏捷和弹性。
通过部署流水线和自动化回归测试实现各环境的持续部署。
因此，在这类主要以业务项目为主的交付过程中，敏捷与瀑布并不是一个非黑即白的关系，很多时候需要打组合拳，和平共处，目标都是尽力和尽快地满足业务的目标。
我的其他文章：
关于作者
早期敏捷践行者
起步于极限编程
熟悉极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发
关注公众号
