项目概况

　　这个项目的策划是在11月开始的，是对现有的一个Web应用程序进行改造。客户写了一份简单的需求说明，希望能在12/25圣诞节之前投入使用。根据这份需求说明，我们整理出了一份功能列表，然后估算每个功能的代码规模，发现规模大大超出期限，于是跟客户交涉，删减了一些功能，并将发布日期定为1/26。最后结果为服务器端3KL，客户端3KL，按照1KL/人月的保守估计，需要6个人月，投入两个人，正好能在1月底完工。于是项目就开始了。

　　为检查项目进行状况，客户希望在12/25之前发布beta测试版。因此主要功能必须在短短的两个月之内完成。为了赶工期，我们省略了概要设计和大部分的详细设计，直接进入编码阶段。一部分用户需求还未确定，只好先进行确定部分的编码工作，将那些迟迟没有定论的需求放在beta版发布之后。

　　我负责客户端的开发，很不幸的是负责服务器端开发的同事在11月上旬一直在忙于另一个项目，而到了11月中旬又因病离职，导致11月份服务器端几乎没有任何进展。好在服务器端开发难度不大，项目组在12月份调入另一名强人来接班。在我俩的努力下终于在12/24如期发布了beta版。、

　　12月 2 2

　　1月 2 5

　　2月 0 8.5

　　总计 6 17

　　实际的工时约为预计的3倍。

　　分析原因

　　为什么这个项目会失败?我认为原因在以下几个方面。

　　1. 忽视项目风险。这个项目的风险有以下几条

　　风险 影响(人月) 发生的可能性 实际影响(人月)

　　未确定的需求 1 100% 1

　　原有框架的缺陷造成的实现困难 0.5 20% 0.1

　　开发环境不完善 0.2 50% 0.1

　　新的bug管理系统造成的学习困难 0.2 50% 0.1

　　发布后的bug 1 50% 0.5

　　总计 1.7

　　总计是1.8人月，也就是说项目应当在计划的6人月上再加上1.8人月，实际的估算值应为7.8人月。但在估算时并没有考虑到这些风险(或者说，虽然考虑到了但却没有认识到它的严重性)，导致1月底计划结束时风险暴露，不得不增加人力来修补问题。

　　2. 对风险未采取相应对策。实际上，上述风险中甚至存在发生概率为100%的风险，但由于开发者过于自信(所谓的“自我膨胀”)，以致并未采取相关措施。甚至在12月底，某些问题已浮出水面时依然未进行控制。

　　当初如果能采取一些对策，或许就不会这么糟糕。

　　风险 对策

　　未确定的需求 严格控制流程，在详细设计未完成之前禁止编码

　　原有框架的缺陷造成的实现困难 及早联系框架开发者调整

　　开发环境不完善 尽早使用较为完善的开发环境

　　发布后的bug 发布β版

　　3. 人月神话。《人月神话》这本经典著作中提到，增加开发者并不能加快开发进程。请注意2月份比1月份多出来的那3.5人月。从事后结果来看，这3.5人月并未发现一个有效的bug。这是因为，这3.5人月是从其他项目组临时借调过来的人员，完全不熟悉项目，加上不完善的测试用例，导致他们无法正确理解测试用例的意图。

　　通常编码过程中的人月效应都能引起大家的重视，但实际上测试阶段也存在人月效应，它的影响并不比编码时小多少。

　　并不是说不能加人，加人时也要加有经验的开发者(比如1月份比12月份多的那3个人月)。

　　4. 盲目编程，跳过概要设计和详细设计，直接进行编码。我们都知道，随着项目的进行，修改一个bug所花费的时间会呈指数增加。也就是说，一个本应在详细设计阶段发现的bug，推迟到单元测试阶段修改，所花时间将是详细设计阶段修改的几十倍;如果推迟到正式部署之后再修改，所花费时间将是详细设计阶段修改的上万倍。

　　因此，跳过概要设计和详细设计，相当于增加了修改bug的时间，扩大了项目风险。

　　结论

　　软件项目开发中的几个重点——质量管理、进度管理、风险管理，通常大家都会注意到前两者，而风险管理则鲜有人知，为什么?因为风险是有概率的，不像质量和进度那么实在，而这种不确定性使得它很容易因为开发者的自负和自我膨胀心理而被忽略。

　　因此无论项目有多么紧急，请务必脚踏实地地分析项目风险，不要抱有侥幸心理。

　　到这里似乎一切顺利，但接下来的一个月中，未确定的需求和不断发现的bug成了灾难。项目从原定的1/25推迟到2/8，再推迟到2/16。而这时开发团队也由原来的两个人增加到五个人，增加的三个人专职测试。最后终于发布了，结果发布当天就因为一个小bug导致数十个用户数据被误删。于是暂停服务继续修改，改为封闭式开发，并且继续增加测试队伍到10个人，这样整个团队就有12个人在工作。

　　这样的状况一直持续到二月底，项目总算正常发布了。

　　计算一下结果

　　下面是每个月的开发者数目。

　　计划 实际

　　11月 2 1.5