13.5项目计划
我们的项目是日期驱动的，10月1日是我们项目的正式运行日期，现在是4月中旬，我们只有5个多月的时间，如何规划我们项目的进度呢？
可以从项目发布的日期倒推上来，大家在白板上画来画去，最后得出了这样一幅图（如图13-2所示）。
图13-2项目计划
小飞：我们可以把8月和9月上旬都做成开发里程碑，然后把9月中下旬作为稳定和发布阶段，这样是否可以写更多的功能？
阿超：这是非常理想的情况，但是根据目前的技术水平和管理水平，我们不能做到这一点。而且目前我们没有设立任何缓冲区。在项目的进行中，我们还有可能要做设计变更（DCR，Design Change Request），这些都需要时间。
大牛：为什么叫第0里程碑？
大栓：因为程序员从0开始计数。
阿超：对，更重要的是在这个里程碑中我们要确定整个系统的框架，别的里程碑（或者叫迭代）都可以看做是在第0里程碑基础上的增量开发。
大牛：有道理，咱们集市里摆摊的都很重视早上开市的第一笔买卖，这就相当于第0里程碑。第一笔买卖没成，一天的生意都受影响。
大栓：那应该叫第0笔买卖。
13.5.1检查点（CheckPoint）
现代软件开发的流程并不是软件团队在绝大部分时间里保持绝密状态，然后某一天突然对领导和同事宣布——某某软件成功了！把所有人都吓了一跳。
我们要在软件开发的过程中，经常发布软件，发布并不是指发布给最终用户，而是在一个阶段结束时，让用户 / 领导 / 同事看看进展，或者是让我们内部使用。
Stone项目中有下面几个发布点、检查点：
（1）6月底，内部发布。对团队内部发布，主要目的是验证发布流程，保证以后发布能自动进行。项目的大部分功能还没有完成。
（2）7月底，CTP（CommunityTechnical Preview，社区预览版本）发布。对于特定用户的一些基本功能已经完成，发布的主要目的是听取一些用户对系统的意见。
（3）8月底，Beta版本发布。这时候绝大部分功能都已经完成，可以公开向外界宣布，允许不同背景的用户登录并收集反馈。
（4）9月底，正式发布。正式把系统移交给运营单位（目前假设移山公司继续运营这一网站）。
由上可见，在项目进展的各个阶段，我们需要不同类型的发布，检查进度，收集反馈，最终保证产品能顺利完成。
13.5.2 如何决定各种功能的优先级
大牛：Stone项目有这么多功能，每个功能还有子功能。每天每人还有新的想法，我们的电子邮件里有不少讨论。到底哪个功能更重要？如何决定？我们以前的项目是开发人员想到什么功能，就做什么功能，随意挥洒，也没有考虑功能的完整性，相互依赖关系和重要性。现在我们怎么办？
阿超：这样是比较乱，我们以前开会讨论，达到共识了么？
二柱：当然开过会，不过会上我说这个功能“相当”重要，别人说那个功能“很”重要，另一个人说还有一个功能“特别”重要。还有人说，虽然重要，但是很难做；为啥不先做一些容易的功能呢？也有人说有些事情什么时候做都可以……最后谁也说服不了谁。
阿超：可以把不同任务的技术难度、重要性、紧迫度，以及其他参数列出来，用数字来表示不同等级，然后把各个因子的乘积加以比较。
我们可以考虑功能的“价值”、“技术可行性”和“紧迫性”，然后给它们定下级别及数值。可以用不连续的数来表示价值的差别，例如1，5，9。
九条：1，5，9听起来不美，不如1，4，7。
阿超：也可以，这个表就叫1-4-7表好了，如表13-2所示。
表13-2 1-4-7表
|
价值 |
技术可行性 |
紧迫性 |
|
|
1 |
可有可无 |
听说过，没见过（比如微软最近宣布的WPF/E技术） |
也许用户会感兴趣 |
|
4 |
有点意思 |
见过，试验过 |
有些用户会喜欢 |
|
7 |
很重要 |
大路货，很多人都能做 |
用户哭着喊着要 |
对于诸多的想法，如果用1-4-7表来处理，结果就比较一目了然了，表13-3是一个例子：
表13-3 1-4-7表的实例
|
价值 |
技术可行性 |
紧迫性 |
乘积 |
|
|
想法1 |
1 |
7 |
1 |
7 |
|
想法2 |
4 |
4 |
1 |
16 |
|
想法3 |
7 |
7 |
7 |
343 |
|
想法4 |
7 |
1 |
1 |
7 |
|
想法5 |
1 |
4 |
7 |
28 |
|
想法6 |
7 |
4 |
4 |
112 |
|
想法7 |
1 |
4 |
7 |
28 |
|
想法7 |
4 |
4 |
4 |
64 |
从上表可以看出，对用户有价值，技术上不难做的，用户迫切需要的功能会从众多候选想法中脱颖而出。
大牛和芸芸就组织了一次功能“海选”，大家畅所欲言，最后所有人都投了票，除了果冻。
果冻：我不高兴，我觉得不能用数学来搞这些东西，我觉得给一个“4”，或者“7”没有意义。我不参与。
芸芸：那咋办？我只能等果冻回心转意？
斯坦：果冻不高兴，也许是因为他中意的功能得的分数不高吧。呵呵，民主听起来是个好东西，但是真正实行，那感觉就不一样了。
阿超：评比和投票的目的是为了交流意见，不是为了谁打败谁。这个选举没有失败者。我们要想办法理解果冻的担心，但是同时项目必须往前推动，不能停下来。
13.5.3更详细的项目计划
在开了几次头碰头会议之后，头儿们终于拿出了项目各个阶段的比较详细的计划。
1．第0里程碑计划阶段
这一里程碑的主要目的是完成基本建设，进行核心部分的设计。其中，数据库的schema设计包括：商品数据、商家数据、用户数据、交易数据，以及用户反馈信息数据（对产品的评价）和用户售后服务数据（退货，投诉）（如图13-3所示）。
图13-3第0里程碑
在这一里程碑中，这个里程碑为期1个月。结束条件是什么呢？是——
（1）团队项目服务器正常运转，100%的员工能正常工作。
（2）各项设计通过复审。
（3）总的测试计划和本阶段的测试计划通过复审。
（4）系统的典型用户通过初始复审。
2．第1里程碑（开发阶段）
这一里程碑的主要目的是完成基本功能，达到内部发布Alpha的要求（如图13-4所示）。
时间为一个月，结束条件是：
（1）商家能够注册，登录。
（2）商家能够上传产品信息。
（3）商家能够修改商品信息。
（4）用户能够注册，登录。
（5）用户可以浏览商品主页。
图13-4第1里程碑交付件计划
3．第2里程碑（开发阶段）
项目第2里程碑——进一步完善功能（分类、搜索、购物车、购物交易、用户论坛、评估、售后服务、可扩展性），达到社区预览发布的标准（如图13-5所示）。
图13-5第2里程碑交付件计划
4．第3里程碑（开发阶段）
在这一里程碑中，我们要实现剩余的主要功能：用户论坛、评估、售后服务，开始效能测试以保证系统的可扩展性。在前几个阶段一直在进行的UI设计应该基本定型。给网站的所有功能提供统一的界面。
这个阶段我们要进行CTP发布，并收集反馈。
大牛：为什么第3里程碑没有更详细的数据？
阿超：因为我们看不清未来，目前只能这样了，写太详细了，有时候还不如不太详细。因为过早的详细计划会给人一个印象，认为事情都搞定了，其实不然。
阿亨：但是我们需要详细的数据来帮助测试团队进行计划。
大拴：我想起一个相声，说是两个视力不好的人争论庙里新挂上的匾额的字写得如何如何，连匾额的颜色和落款都描述了一番。两人正争执不下时，一个和尚路过，说那匾额还没有挂上去呢！
阿超：阿亨，别往心里去。不过大拴说的有道理，我们有时花时间争论某些功能的细节，但是这个功能是否要实现还是一个很大的未知数。
阿杰：有了阿超这句话，看来我可以少写不少文档了。
5．第4里程碑（稳定阶段）
在这一里程碑中，我们要分析用户的反馈，慎重考虑增加或者删除功能，进行设计变更（DCR），完善效能和压力测试。在里程碑的最后，发布Beta版本，收集用户反馈。这时我们可以对用户界面进行最后的修改，之后，这个时候的网站就很接近最后发布的网站了。
6．第5里程碑（发布阶段）
修改缺陷，最后验证所有功能，准备发布工作，10月1日正式发布。
同时，计划下一个版本的工作。
二柱：阿超，我们真的会有下一个版本？
阿超：凡事预则立，不预则废。我们不是要成为王屋河流域有影响的网站么？当然要经过好几个版本的努力。
鄂公网安备 42010302001612号