YMU2.0上线了
经过9月紧张的战斗,Mars版本终于在10.1假期前上线。YMU2.0,即Mars版本从6月下旬开始,原定8.31上线,整整被推迟了30天。由于进度延迟问题,9月份公司强制加班,工作日每天晚上加到9点以后,同时周六再加班一天。
<o:p> </o:p>
本篇文章简要介绍Mars版本开发情况及一些经验教训。
开发目标
Mars版本主要有以下三大类目标:
<o:p> </o:p>
UI改版
- 增强功能操作界面的易用性;
- Official website也需要全面重新规划风格,并充实内容。
<o:p> </o:p>
一般功能改进
- Report管理:进一步精化报表;采用velocity技术来实现报表模板;报表内容与用户时区关联;
- Alert管理:告警粒度从service细化到monitoring source;进一步规范化alert rule;
- 进一步规范化各对象(如customer, user, YMU-NODE, service)的状态及其转换;
- YMU-NODE的安全性增强。
<o:p> </o:p>
系统架构升级
在不远的将来,customer数量、及并发访问会大幅增长,Public Beta版本的架构肯定不能满足要求,在Mars版本做了以下改进以达到初步的功能分布,并增加扩展性:
- 前台程序原来全部在Web server中实现,无法实现分布处理,因此Mars版本剥离一些功能出来,形成独立的程序,从而实现功能上的分布;
- 负载均衡:实现web server的负载均衡方案,以适应customer数量增长的需要;
- 可靠性:初步实现数据库mysql的可靠性方案,以应付可能的数据丢失问题。
项目组结构
项目组结构大致如下:
- 项目管理:1个,兼产品管理;
- 系统分析:1个,那就是本人;
- 前台组:1个team leader,前期3个开发人员,其中一个新来的,而且WEB开发不是很熟;9月初开除了一个低效率的开发人员,随后加入一个新人;实际上做最多工作的是两个老程序员,9月份新加入人员做的工作很少,还占用了指导人员(team leader)大量的指导时间,真是得不偿失;
- 后台组:开始有两个开发人员,其中一个老的,一个新加入的;由于工作安排问题,新加入的只是在练手,对Mars版本根本没有帮助,9月初因为效率问题不予转正;
- QA组:一度达到4个人,其中一个team leader,到9月份时只剩下两个。
进度延迟原因
分析一下延迟的原因,主要有以下几点:
<o:p> </o:p>
前期规划时间不够:Mars版本的前期规划(需求、技术验证)只是进行了大概1~2周的时间,很多功能需求都是比较粗的、未经过全面讨论,也未与程序人员进行充分沟通。这样造成两方面的问题:一是工作量无法精确评估;二是后面开发过程中有较多的修改、细化和返工。如使用google map来展示监测源及结果就是在开发过程中增加的特性要求;另UI改版成Yahoo Mail Beta的风格也是开发进行后才确定的,工作量还不小呢。<o:p></o:p>
<o:p> </o:p>
Project plan不够充分:进度规划时,时间点及功能知识只是根据市场策略来定,而未考虑具体的工作量及人力资源情况;同时开发人员做计划时,总是存在乐观估计个倾向,未能充分考虑任务的复杂性和工作量。因此,从某种角度看,该计划从一开始就不是很实际的计划,多次delay也就在所难免了。
<o:p> </o:p>
人力资源问题:人力配备上,从数量上看,应该算不错的了,但有些人员的素质还有待于提高。其实,从公司成立以来,人力资源一直是个问题,没有能补充进充足的、合适的programmer。另外,在前面项目前期,大家都有些松懈,没有更早紧起来,浪费了不少时间。如果大家都能像9月份这样的工作干劲,可能就需要这么多的delay,或有更多的测试时间,从而有更高质量的版本。
<o:p> </o:p>
新技术原因: 为分布式、性能、容量等考虑,技术架构做了较大的升级。主要是public beta版本着重于功能,未充分考虑适于分布式,大规模系统和HA的架构,因此造成Mars版本较大的架构升级。目前也只是做到前台功能的分布,已经独立出NSS, RGS, ADCS, AGMS, CMS和IFS等可分布部署的SERVER,后面还有很多架构方面的工作需要做。这些升级采用了Socket通信, Multi-Thread等在以前版本中未使用过的技术,这明显增加了coding, testing和integration的时间。
<o:p> </o:p>
版本规划问题:Mars版本的目标还是比较宏大的,前期规划需要3月完成,并规划了几个可发布的子版本。实际工作过程中,由于工作安排问题及UI风格调整等原因造成子版本是不可发布的,只能总体发布的局面,这样总体进度就比较难把握了。
<o:p> </o:p>
现在总结一下,其实还是可以分割成多个可发布的、粒度更小、更易控制的子版本的,如可先完成UI改版,给用户更好的体验;其他功能及架构改进则可根据优先级安排到不同的子版本中。
<o:p> </o:p>
这是个重要的教训,我由此体会到了迭代开发的重要性。以后规划版本时,可以半月为基准,最多不超过1个月。
<o:p> </o:p>
关键点控制问题:在Mars版本开发过程中,主要抓了前台Server的设计及code review,取得了一定的效果;但对关键点控制还是做得不好,还有很多漏掉的。
如Instant check功能,是老功能,就没有特别关注,9.28部署上去时,发现了很长时间不能显示检查结果的问题。经检查,发现代码中存在很多问题,经改进,效率提高了很多。实际上对用户来说,这是个很重要的功能,因此需要把它列入关键功能,做重点检查、Review和测试。
<o:p> </o:p>
还有登录功能也存在较大问题。现在输入密码后,要很长时间才能进入操作界面,这对用户体验绝对是灾难性的。而且该问题是我们的customer发现并提出来的!
<o:p> </o:p>
功能复杂度增加原因:每个user增加了time zone,并需要体现在报表、alert和客户通知邮件等,这给RGS, AGMS和CMS等的设计和开发增加了不少复杂度。
总结
Mars版本延迟发布的教训是深刻的,需要我们在以后的版本开发中加以避免,为用户提供更快、更好的服务。在互联网时代,你不需要完美,但你一定要快,一定要根据用户需求、竞争对手情况快速进化,如果慢,那你就死定了!
<o:p> </o:p>
互联网法则“快鱼吃慢鱼”是一条你必须遵守的法则!
<o:p> </o:p>