“让我们推动大铁球”
老王是一个典型的H人－充满激情和执行力极强，他忧虑地跟我说：“这个项目就像一个大铁球，人人都知道很重，但是光滑的表面让所有人不知如何使劲”。我的回复是：“你需要一个敏捷里的项目启动”。
这样的项目都有一个类似的特征：一个被拍脑袋的，谁也不知道能不能完成的结束日期；一堆还未明确的需求；一群缺乏计划的开发人员；和一个必须看到团队至少应该干点什么的项目经理。以往的项目开始也许是当项目不得不开始的时候，大家停止争吵说：好吧，一起开始。可能事情不如我相信的那样悲观，但是在上线前几天没人知道团队到底能做到什么程度，应该是确定的。
于是，敏捷项目启动的关键在于确定项目范围，围绕在这个周围的是：故事拆分、优先级、工作量、和迭代计划。
故事拆分
首先，让我们一起拆分故事。需求在初期一定是不明确的，为了把需求不明确造成的返工浪费减到最小，我们把一个大需求根据业务场景拆分成若干用户故事，也许只是一个标题而已。标题的格式最好采用“XXX可以XXX”这样业务语言的格式，例如“营业员可以查看客户订购的服务列表”，而不是“客户订购关系列表”这样功能语言的格式。业务语言而不是功能语言可以制造一种业务价值导向的开发氛围，努力杜绝做“不增加价值”的事情。此外，还有很多必要的技术任务被识别出来。这样我们就得到一个包含各种用户故事和技术任务的列表。
值得提出的一点，容易产生混淆的是“分拆用户故事”和“分拆技术功能点”的区别。传统思维中，需求被拆分成许多独立功能点，每个功能点可能在多个业务场景下被用到，我们认为把这样重复使用的功能点或模块单独进行开发，可以减少工作量，考虑也更加周全（单个功能在多个业务场景下可能有不同），是一种非常高效，且理所当然的工作模式。这样做的结果是，到项目开始后的很长时间，都不能完成一个较为完整的业务场景（每个场景可能都开始，但都是零散的功能点）。这里便是规模生产和精益单件流生产模式的本质不同，关于此点我将另在文章中解释，此处不赘述。
排优先级
当我们有足够的故事卡片被拆分出来，为了让核心团队对整个项目交付计划有个初步的感觉，我们把卡片平铺在一张大桌子上，分成三个区域“基础”、“提升”和“特殊”。每个区域的分别含义是：
- 基础：核心的技术任务和最基本业务流程框架中的用户故事，拿开户业务为例，“可以开户”就是一个基础用户故事；
- 提升：在基础的用户故事上进行提升的特性，例如“在开户时可以看到可用号码列表”就是一个提升型用户故事——开户是基础特性，可用手机号码的选择可以先采用手工输入方式；
- 特殊：一些非必要的，满足客户更细化的要求，例如“在开户时可以看到带8的可选号码列表”就是一个特殊型用户故事——这样的需求相对独立，不影响业务主场景的实现；
从软件开发层次上考虑这三个等级便是：Usable(可用的)、Useful(好用的)和Engaged(信赖的)。
我们需要做的事情是把拆分好的卡片放进相应的区间里，目的是在后阶段实践中，我们尽量把时间花在第一个区间“基础”的卡片上，对于后两个区间的卡片，尽量不要陷入到细节的争论中去。
估计工作量
往往出现的情况是我们忽视真正需要进行代码开发的人对工作量的估计——某个拥有权威和经验的系统专家给出一个让开发团队敢怒不敢言的工作量，经常让开发进度陷入不可控的艰难境地。工作量的估计是为了设置一个合适的迭代工作量目标，不要过大，也不要过小。注意我们只能知道昨天的天气，迭代能完成的量不是恒定，在迭代正式开始后，需要根据上一迭代的情况进行调整。
估算工作量的方法是召集5到7个开发人员