本文写于2005年12月，由于某些原因未能公开，现在一晃过去2年又多，早已是物是人非，回头看看这篇文章，当时的情景还是历历在目，让人感概良多，用一句时髦话总结：“很傻很天真”。不敢独藏，与各位同行分享。

本文可以任意转载或分发,但请注明作者和出处。

--------------------------------------------------------- 正文----------------------------------------------------------------------------

   该项目是X财政局的预算管理系统，与7月1日上线的国库集中支付系统在同一个平台上。国库集中支付和预算管理是财政的核心业务，幸好，偶们今年都一并做了。

   5月份中标，到9月初历时4个多月，但项目真正启动是在7月4日，当时部门的高层判断失误，错误的以为这个项目可以延期到10月中，结果大家都在拖，同时由于国库系统没有做好，问题不断，也影响了预算系统项目的启动。一直到6月底，财局的局长一个电话打到大boss那里，要求跟他谈谈。那天下午的会议开了 1个多小时，最后的定论是预算系统项目不能延期，一期（单位版）必须在8月15日前上线，二期（财局版）必须在9月5日前上线，当时离deadline满打满算只剩下两个月时间了。两个月，做一个从来没有做过的业务系统，没有人熟悉业务，使用并不十分完善、前台开发效率很低的j2ee平台，可能完成吗？我没有信心，客户也没有信心。“你们能在8月底完成吗？我们的兄弟评估过，你们很大可能不能完成。”客户不止一次在偶面前说这句话，我当时只能苦笑，因为我也不知道能不能完成。
   面临的困难很多，如何能够在两个月时间内完成这么一个项目？我们还是一步一步的来看看把。

   项目组在项目启动之日（2005年7月4日）成立，当时的项目组的组成有PM、QC、 TM和QA各1名，高级程序员（其中一名从公司其他部门借调过来，时间到8月底）2名，中级程序员3名，初级程序员2名，还有一个mm（需求人员/集成测试人员/文档编写人员）。幸好，项目组中有多名团队成员参与过第一个项目（国库集中支付）的开发，积累了不少的经验。

   项目采用跌代的开发方式，其中一期beta版本在7月底发布（以提交给客户做评审为标志），release版本在8月15日发布；二期beta版本在8月 15日发布（同样，以提交给客户做评审为标志），release版本在9月5日发布。从最后的结果来看，当时错误的估算了二期的beta发布时间，直到8 月22日（其实这个时间发布beta版本客户也应该是接受的）才发布，延期一周。

   为了规避需求风险和技术风险，7月4日－7月8日，需求开发人员天天缠着客户（mm就有这样的好处了，换成个大男人天天缠人就不太好了）确认需求，同时组织技术评审，定好大体的开发和技术框架。

    由于不熟悉业务，只得采用驻客户现场开发的方式，但有些团队成员（1高级程序员，2中级程序员）有其他任务在身，不能在客户现场开发。迫不得已，安排他们在广州开发一期，项目组主力驻客户现场开发二期，分为两条开发主线并行开发。当时错误的估算了一期的工作量和高估了广州开发人员的能力，在Week1结束后（7月15日）发现广州开发小组只是做了几个还没有完善的jsp页面，其他什么都没有，进度已经严重滞后。当时分析的原因有那么几点：

i.    广州那边的开发人员没有参与第一个项目的开发，技术积累不够，业务知识积累不够。

ii.    由于需求是在客户现场捕获的，通过msn等交流工具存在很多的沟通问题。

iii.    开发人员的能力确实不够，短时间要求他们的生产效率大幅提高不太现实。

iv.    迫于时间的压力，没有做技术框架的Demo和完善的架构文档以及技术说明，直接导致了代码的不规范和实现方式的不统一，直接影响了一期的开发效率和进度的滞后，因为一期的开发人员大多是新手，希望他们几天时间了解struts、dao等等确实是勉为其难。
   一开始就延期了，怎么办？最直接有效的方法，加资源，冒着二期可能延期的风险，抽调了一名中级程序员小C到广州开发一期。结果week 2结束后（7月22日），一期的开发只完成了不到50％，这时候离发布一期beta版本只剩下5个工作日的时间。当时的直觉：一期如果还在广州开发就必然会完蛋的，当机立断，决定广州的开发截至到26日，同时26日开始广州那边抽调一名初级程序员并和原来抽调过去的小C在客户现场开发一期，同时以外包的形式把一大部分的内容给WBB开发。这回把宝压在了XXX上面，幸好，偶没有看错人，WBB没有让我们失望，经过一个星期的努力和周末的加班，一期beta 版本在8月1日如期发布，先在客户的技术部门内部做了一次评审，并在8月4日给客户的业务科室做了一次演示，谢天谢地，演示过程没有出错。真的已经很稳定不会出错了吗？当然不是，在3日晚上内部测试的时候就预先把那些功能可用，那些不能用，那些按钮可以点，那些不能点搞得清清楚楚，以确保演示的“万无一失”。

   演示Pass后，经过QA的测试，在8月15日发布了一期的release版本1.0。当时还很乐观的认为一期不会有什么问题，但后来几天发生的事情，让我自己都觉得这个版本实在太烂了，出现了很多很多不该出现的缺陷。因为什么？没有代码复审，在上线前如果我花1-2个小时的时间，认真看看代码的话，起码可以保证不会出现一些很严重的问题，也不会弄得客户的电话变成热线，一刻都没有停过。比如，一个非常严重的缺陷，单位A和单位B同时做业务C，单位B的用户后登陆，单位A保存数据后，这些数据都变成B单位的数据。Why？客户带我们去客户的客户那里看现象的时候，我也不相信，怎么会有这样的情况发生？重新看代码，发现了某些可疑的代码可能会导致这样的问题，修改后重新发布。当时有一个很可疑的变量，我感觉是有问题的，但一时忽略，没有细看，这是基于：开发人员不会犯这么低级的错误的。结果到了第二天，还是有这样的问题，这回用了不到一分钟的时间就发现struts的action类中居然出现了静态变量，这个变量用来保存单位编号，也就意味着某个时刻只会有一个单位存在，其他单位做的数据全部都是这个单位的数据。我Kao，这个错误也太低级了，实在无话可说。

   另外还有其他一些小问题，页面问题，操作不方便问题，那段时间客户的电话没有停过，而且往往是一个电话过后，客户就在我身边跟我说这个有问题，那个有问题，接着又匆匆跑回去接电话，然后又匆匆的跑过来跟我说这个那个，那1-2天真不是人过的日子，连喝水的时间都没有，幸好，客户关系做得还算可以，压力都顶住了。然后，电话慢慢，慢慢的少了，一个星期后，每天只有零星几个电话，多数是操作问题。

   总的来说，一期是硬上的，没有经过QA的严格测试，没有客户的试运行，没有SA的代码复审等等，质量可想而知了。不过我们都挺过去了：一切终须过去，只要奋起面对。

   相比较而言，二期的质量就好多了，毕竟是项目组的主力完成。二期的开发是跟一期同时进行，在客户现场，这样做的目的是把客户的资源也纳入到项目组中，客户的信息部门有一个既熟悉业务也熟悉技术的人配合我们。一个很不爽的地方，由于客户地方不够，我们只能跟客户同一个办公室，什么事情都暴露在客户的眼皮底下，cvs等等重要的资源也是跟客户共享，这个非常的不好。当别人对你知根知底的时候，想跟别人讨价还价就很难了。另外，不得不说一下的，财神爷又不是没钱，却在硬件方面小气得很，Web Server用的还是1个CPU，1G内存的机器，而且数据库还是Sybase 11.9.2这样的古董。先不说这些废话了，看看二期的管理把。

   首先，最重要的先把范围定好，跟客户确认在2005年9月5日上线包括的内容，这方面经验不足，其实有很多可以在9月底上线的内容都提到9月5号，但客户一口咬定非得在9月5日上线，现在想想，实在不知道客户方出于一种什么考虑。其次，定好范围后，拆分模块根据团队成员的特点分配工作，比如新加进来的开发人员就分配一些不需要熟悉业务的工作，参与过上个项目开发的就分配一些熟悉业务的任务等等。其实加快任务的执行最有效的方法就是拆分为并行的多个任务，而且这些任务相互之间的关联越少越好，这个跟Oracle并行执行的原理是一样的。

二期开发一周（7月16日）后，发现项目组的前台开发效率很低，项目比预期延期了20%。效率为何低下，当时分析的原因有：

i.    项目组成立没多久，团队之间的磨合不够，基本同一班开发人马，加入的人员又是新人，要想在短时间内，提高开发效率是比较困难的

ii.    开发人员的能力不够

iii.    对于现场开发的开发环境，不利于团队建设和人员沟通，由于和客户混在同一个工作场所，人员的士气会受到影响、交流的机会大大减少

   当时在进度报告中对这些情况作了详细的说明，要求增加1名熟练的前台开发人员开发新的业务模块以及熟悉Sybase的后台开发人员2名开发查询统计部分〔如果目前资源不足以完成任务的情况，PM就应该跟高层要求资源了，不然PM没有跟高层说明情况而导致项目延期的话，老板会很生气，后果会很严重，责任会很大〕。报告是发过去了，不过高层那边好像稳如泰山，不见一点动静。当时感觉是部门没有资源可用了，项目已经存在延期的风险，起码beta版本的发布会受到很大影响。幸好，在第二周，新加入的高级程序员小W的开发效率提高了很多，这是一个很利好的消息。在第二周结束后，小W开始了新业务模块的开发，但查询统计还是没有人开始做，需求开发、代码开发等等，还是原样。

   这样的开发一直到了7月底，这时候由于一期要上线，中间抽调了不少资源在一期上，在8月初的第一个星期，感觉特别的乱，一期开发和二期开发扯在一起，那段时间基本上没有计划的，内容实在是太多，人员安排不过来〔不要跟我说加人，这时候加人只会更乱〕。幸好，也只是一周的时间，慢慢的，从混沌又恢复到正常，这是在一期上线后，也就是在8月8后。

   这时候，又加入一名新人小Y，据称熟悉Sql server，熟悉存储过程，加入项目组开发查询统计。不过一天过后我就觉得，如果单靠这个人的话，查询统计两个月都做不完，技术不太熟练之余，业务上的理解有不少问题。负责开发需求的人在跟我提意见，说小Y应该这样开发，不应该那样开发，偶只是听，没有做其他实质性的工作，因为我知道单凭他是不可能完成任务的，反正都要延期，不如先集中精力把其他有望如期交付的任务上面。这种情况也如实往部门高层反映，并抄送了一份给大Boss。不知道是客户给boss施加了压力还是什么其他原因，大boss派了一个玩了八、九年的sybase人CF过来，当然效率不是小Y可比拟的。客户曾经说过，查询统计不能在9个工作日内完成，但CF做到了，而且是在周末没有加班的情况下做到的。
    终于，到了8月15日，还有30%的工作量还没有完成。硬着头皮跟客户解释，结果没说几句客户就开始埋怨为何不早响警报，为何不找他要资源，为何不要求他们的支持，说了一堆。然后说到一期上面，外面一百多个单位，出现那么多问题，真给你们玩s。说得我没话可反驳，尤其是一期的质量确实不好，当时就抱定：没关系，说就说把，反正偶脸皮厚。

   为了讨好客户降低压力同时也为了规避变更风险，在没有把握的情况下在8月19日发布了二期的beta版本，并给信息部门做了一次演示。变更不多，就是本身的bug实在是太多，bug系统里面的集成测试计划和系统测试计划里面都有2个页面的bug，总共有100多个，经分析后，中优先级以上的有60多个，这些bug要在9月5日前全部完成，而且保证不能出现新的bug。当时都有点蒙了，这么多？在8月19日开始一直到9月2日，除了两个人还在开发查询统计外，其余资源全部投入改bug，这时候中级程序员和高级程序员的分野就在这里了。高级程序员做出来的东西bug不多，修改起来也很快，而中级的呢？一堆错误不止修改bug还改出不少bug。当然，这个跟人的素质是有关系的。很不幸，项目组有这样的人存在，而且在负责关键任务〔为什么？没有资源〕。终于，一天，偶实在是无法忍受“修改10个bug，5个复审不通过，又引起5个bug”这样的情况，让另外的高级程序员大H全面接手这部分工作，效果马上就出来了，bug是越来越少。

    最后，上线时间定下来了，无论如何，9月5日上线。那就意味着，9月3日（周六）就必然要加班了，实在还有很多的bug需要修改。为了减轻点压力，9月2日集体去看电影靓Tom的新片《世界之战》。9月3日奋战了一天，直到晚上9:30才从X地回广州，在东圃的农家庄吃饭，东西还不错，就是吃得太晚了，到家已经是凌晨了，感觉，真累。

   9月5日，一个值得回忆的日子，在没有延期的情况下，系统如期上线。辛苦了整整两个月，总算有所回报。

[ 本帖最后由 pharos 于 2008-4-14 23:52 编辑 ]

嘿嘿 老大的兄弟拿来看看

总结才有提高，分享才有价值。支持

分享总是好的

项目，还没摸着方向

不错！！！

QUOTE:

---

原帖由 pharos 于 2008-4-14 23:57 发表
总结才有提高，分享才有价值。支持

---

  也别太沉迷了哦 哈哈

拜读小栋哥的文章

看起來真累呀。說實話沒有這么累過。

QUOTE:

---

原帖由 Tomac 于 2008-5-30 11:05 发表
看起來真累呀。說實話沒有這么累過。

---

是累s。