前言
本文将探讨一个所有软件开发者都头疼的问题，那就是项目计划和其中涉及到的估算。任何一个项目都离不开项目计划，但绝大多数项目计划都不怎么靠谱。以前已经有一篇文章讲了计划会议的实践，这里是传送门。但项目计划并不是简单的计划会议，而是一整套的活动才能确定的。接下来就结合经典的敏捷开发方法论以及我们团队的实践来看看在敏捷开发里项目计划和估算的实践方式是否能够给你带来一点启示。
内容
敏捷计划的特点
首先敏捷开发中的计划也不是很靠谱的，但相对于传统的计划，良好的敏捷团队给出的计划和估算能够在团队变化不大的条件下做到短期内靠谱。你要是让敏捷团队提供一个超过一年的靠谱开发计划估计是难为他们了。
其次他们给出的估算只适用于他们这个团队，而且都是相对值，对于人天的估算并不是很理想。
最后一般来说敏捷开发的计划都是会滚动动态调整的，不是静态不变的。
Sprint-0计划
有不少介绍敏捷方法的书一上来就会说要进行迭代开发，大家真正着手这么干的时候往往会懵逼不知道该如何开始，其实一般敏捷团队在新项目开始的时候都会有一个Sprint-0的周期，这个周期主要是准备环境，资源以及进行需求调研等等，这些事往往都比较虚，但都是极为重要的，如果做不好就会一团糟。下面我们就逐步介绍跟计划有关的部分。
注意：计划相关的活动应该全部的团队成员都参加，无论是测试，开发，项目负责人，UI等等，如果团队太大的话应该各个方面派出代表，但这往往意味着你需要进行团队的拆分。
场景构建
第一步是场景构建，场景这个词出现的频率是越来越高，而且正在从互联网行业向传统行业转移，以前一听到场景这个词就觉得一定是个高手，但现在用户都能说先讨论场景，可见其普及程度和重要性。
构建场景属于需求分析中的关键一步，而需求分析应该是贯穿整个敏捷开发流程的，之所以要在Sprint-0进行场景构建就是因为场景是展示需求的舞台，使后期的讨论能够具象化，让参与者能够更快的达成一致。
场景构建可以采用模拟法，通过白板或画纸来快速的勾勒出简化的有高度代表性的业务情景。一般可以通过模拟整个产品或系统的使用过程来逐步进行演示，然后将大家关注的一小段作为一个场景进行切分，确定系统或产品的典型场景即可，有点像拍电影的感觉。
什么时候构建完了呢，就是找一个没有参加讨论的人，来给他演示确定经典场景，他一次就明白过程，而且对于场景有画面感就基本算是完成了。
这一阶段的成果最好通过照片或画纸记录下来，后面将经常用到。
用户故事梳理
第二步就是梳理用户故事了，用户故事的形式大家都知道：作为XXX，我希望能做到XXX，以便我XXX。
针对刚刚的每一个场景分别进行用户故事梳理，就直接把照片或画纸贴到白板上，对着场景即可。大家通过头脑风暴的形式提出这个场景的用户故事，用户故事就写成卡片的形式直接贴到场景上，直到确认用户故事完全的覆盖了场景。
别忘了最后保留场景外的用户故事，来确保没有遗漏。
这个阶段你应该收获一堆卡片，并且是对着不同的场景的。
用户故事估算
接下来该是开发团队的重头戏了。
开发团队（实际上是所有参与开发的团队，包括但不限于测试，UI等等）需要逐一对着用户故事进行估算，来确定完成用户故事所需要的时间。一般采用故事点来衡量。注意故事点是一个相对的大小单位，并不一定代表着一个固定的人天数。
采用的具体方法可以考虑使用敏捷扑克法，这将是个漫长的过程，准备好足够的零食和水。仅仅一个规模不大的项目估算用户故事就能消耗3~4个小时。具体的敏捷扑克法我就不在这里说明了，百度一下大概情况应该能了解。
这个阶段最后你应该能得到一堆估算完的用户故事，我们习惯于把估算值写到故事右下角。
故事地图来确定发布计划
一般来说估算完了的总和是很吓人的，可能好几百了故事点，根据之前的经验也许一个故事点需要大概5人天，这可能需要好几年的时候才能全部完成。这时候项目负责人该变为主角了，将这些卡片分别排在对应的场景下，项目负责人根据优先级对用户故事进行排序。
成果如下图所示
然后再根据估算的周期进行划分，不断的权衡周期和内容，最终确定如下图所示的内容。
这里的发布1，2，3就可以算是大体靠谱的里程碑了，如果更科学一点的应该让团队进行三个迭代周期的开发，再来正式确定发布日期。
总结
良好的Spint-0是一个项目成功的基石，是不是已经厌倦了拍脑袋的日子了呢？敏捷模式将是一个不错的选择。