为了让大家更清楚的理解问题，先从一个具体的事例开始。两个月前，我听说以前辅导过的一个团队在那一段时间总是周末加班，想到一定是有交付压力，另外我也想看一下如何能够帮到团队，所以就和该团队的PO和ScrumMaster坐在了一起。为了近期的业务目标，团队正在忙于一个合同变更审批的功能，其实做的事情就是在客户要求合同变更的时候，实现自动的审批流程，让相关人等能够看到变更的内容以及能够自动上线。涉及的修改还是比较多，而且由于有业务目标的压力，团队“必须”要全部完成。

问题搞明白后，接下来看看团队的实现方案，大吃一惊，尽管已经做过MVP了，团队还是决定要一个工作流引擎，而且要实现一个类似于版本管理系统的内容比较系统（工程师总是喜欢引擎、框架、系统）。设想一下，工作流引擎光测试用例就会有很多种，如果像Git那样的版本管理实现和测试起来也不会特别快。但是这么多功能对于我们的业务来说需要么？团队是否有可能在几个sprint（每个sprint一个星期）内完成所有功能么？我们设想的这个方案能够解决业务目标的所有问题么？怎样能让我们的PO、客户以及团队感知到我们正在逐步解决问题而不是一口吃一个胖子？

有了大的业务目标，因此必须要把这个大的目标切分成几天可以完成的小目标就变得十分必要。下面是我们花了几分钟大体列出来的几天可以实现的目标。

1. 合同变更直接上线（无任何审批流程；显示所有最新内容）
2. 合同修改后只有一个审批节点，变更自动上线
3. 只针对一个字段（比如合同延期）显示变更信息 （其实从业务角度来讲，90%的合同变更只涉及三五个字段）
4. 实现两个审批节点、无分支的变更自动上线 （审批节点太多以及分支太多本身可能说明公司的业务流程出现了问题，太过于官僚）
5. 针对第二个字段显示变更信息
6. 如果实在有必要，根据一个字段（比如只针对于合同延期），实现工作流审批分支跳转 （当然也有可能不需要事先工作流分支）

另外还有一个例子，另外一个功能，是把很多数据从数据仓库中读出，然后显示成表格，最后在显示成线图。工作量大约是四个星期。而且里面有一些技术难点，比如实现数据推送、大量数据的持久化以及复杂的图表。整个一个需求的工作量是四个星期，肯定很水，如何能让进度变得可见，而不是一个黑洞。最终大的业务目标被切分成如下的小目标。

1. 用表格方式展示一个字段（比如是访问数），数据是hard code的 -> 主要目的是证明能够用表格方式显示数据
2. 能把Hard code点评数，按照点的方式，暂时不用曲线的方式去展示1天的数据 -> 主要是证明能够把数据展示成图
3. 能把Hard code点评数，按照点的方式，暂时不用曲线的方式去展示2天到7天的数据 -> 主要是证明能够把展示多个点，但是不要求连成线
4. 能从数据库中读取点评数，并展示成表格和图表 -> 这时候数据已经不是Hard code的，而是动态的了
5. 能从数据仓库中读取这个字段的内容，导入到数据库，并展示成表格和图表 -> 打穿了从数据仓库到图标的通路，系统基本框架已经成型
6. 能把点图变成线图
7. 把一个字段扩充成两个字段，能够展示表格
8. 把一个字段扩充成两个字段，能够根据表格展示点图
9. 两个字段用不同颜色展示线图
10. 把7天扩充到30天，根据时间段不同显示不同的数据
11. 数据持久化技术方案确定
12. 大数据量推送、同步方案确定

说到这里，大家可能想到了，这个blog其实是关于需求切分的。我想强调的是，所谓需求切分其实更重要的是业务目标的切分。目标切分是敏捷团队和个人所必须具有的核心技能之一。几个月前我在微博上分享过，我们四个pair在5个小时内有过130次提交代码，很多人不理解，觉得是不是修改一个字母就提交了。其实背后隐含了绝大多数程序员缺乏切分目标、切分需求的能力。如何把一个比较大的目标变成一系列SMART(Specific, Measurable, Achievable, Relevant, Time)的小目标，从而从一开始就知道我们在哪里、我们的方向是哪里、我们的速度如何。。。对于业务成功十分关键。推荐一篇XP创始人Kent Beck的文章Optional Scope Contract。

更深一步，有可能我们一开始的方向是错的，我们解决的是错误的问题，我们也就没有必要把问题完全解决，关键是做完一部分，扔到客户那里，然后跟着客户的反馈走。

突然想到敏捷宣言第四条其实很有道理：“响应变化 高于 遵循计划”。