关闭

YMU2.0开发总结

300人阅读 评论(0) 收藏 举报

YMU2.0上线了

经过9月紧张的战斗,Mars版本终于在10.1假期前上线。YMU2.0,即Mars版本从6月下旬开始,原定8.31上线,整整被推迟了30天。由于进度延迟问题,9月份公司强制加班,工作日每天晚上加到9点以后,同时周六再加班一天。

 

本篇文章简要介绍Mars版本开发情况及一些经验教训。

开发目标

Mars版本主要有以下三大类目标:

 

UI改版

  • 增强功能操作界面的易用性;
  • Official website也需要全面重新规划风格,并充实内容。

 

一般功能改进

  • Report管理:进一步精化报表;采用velocity技术来实现报表模板;报表内容与用户时区关联;
  • Alert管理:告警粒度从service细化到monitoring source;进一步规范化alert rule
  • 进一步规范化各对象(customer, user, YMU-NODE, service)的状态及其转换;
  • YMU-NODE的安全性增强。

 

系统架构升级

在不远的将来,customer数量、及并发访问会大幅增长,Public Beta版本的架构肯定不能满足要求,在Mars版本做了以下改进以达到初步的功能分布,并增加扩展性:

  • 前台程序原来全部在Web server中实现,无法实现分布处理,因此Mars版本剥离一些功能出来,形成独立的程序,从而实现功能上的分布;
  • 负载均衡:实现web server的负载均衡方案,以适应customer数量增长的需要;
  • 可靠性:初步实现数据库mysql的可靠性方案,以应付可能的数据丢失问题。

项目组结构

项目组结构大致如下:

  • 项目管理:1个,兼产品管理;
  • 系统分析:1个,那就是本人;
  • 前台组:1team leader,前期3个开发人员,其中一个新来的,而且WEB开发不是很熟;9月初开除了一个低效率的开发人员,随后加入一个新人;实际上做最多工作的是两个老程序员,9月份新加入人员做的工作很少,还占用了指导人员(team leader)大量的指导时间,真是得不偿失;
  • 后台组:开始有两个开发人员,其中一个老的,一个新加入的;由于工作安排问题,新加入的只是在练手,对Mars版本根本没有帮助,9月初因为效率问题不予转正;
  • QA组:一度达到4个人,其中一个team leader,到9月份时只剩下两个。

进度延迟原因

分析一下延迟的原因,主要有以下几点:

 

前期规划时间不够Mars版本的前期规划(需求、技术验证)只是进行了大概12周的时间,很多功能需求都是比较粗的、未经过全面讨论,也未与程序人员进行充分沟通。这样造成两方面的问题:一是工作量无法精确评估;二是后面开发过程中有较多的修改、细化和返工。如使用google map来展示监测源及结果就是在开发过程中增加的特性要求;另UI改版成Yahoo Mail Beta的风格也是开发进行后才确定的,工作量还不小呢。

 

Project plan不够充分:进度规划时,时间点及功能知识只是根据市场策略来定,而未考虑具体的工作量及人力资源情况;同时开发人员做计划时,总是存在乐观估计个倾向,未能充分考虑任务的复杂性和工作量。因此,从某种角度看,该计划从一开始就不是很实际的计划,多次delay也就在所难免了。

 

人力资源问题:人力配备上,从数量上看,应该算不错的了,但有些人员的素质还有待于提高。其实,从公司成立以来,人力资源一直是个问题,没有能补充进充足的、合适的programmer。另外,在前面项目前期,大家都有些松懈,没有更早紧起来,浪费了不少时间。如果大家都能像9月份这样的工作干劲,可能就需要这么多的delay,或有更多的测试时间,从而有更高质量的版本。

 

新技术原因 为分布式、性能、容量等考虑,技术架构做了较大的升级。主要是public beta版本着重于功能,未充分考虑适于分布式,大规模系统和HA的架构,因此造成Mars版本较大的架构升级。目前也只是做到前台功能的分布,已经独立出NSS, RGS, ADCS, AGMS, CMSIFS等可分布部署的SERVER,后面还有很多架构方面的工作需要做。这些升级采用了Socket通信, Multi-Thread等在以前版本中未使用过的技术,这明显增加了coding, testingintegration的时间。

 

版本规划问题Mars版本的目标还是比较宏大的,前期规划需要3月完成,并规划了几个可发布的子版本。实际工作过程中,由于工作安排问题及UI风格调整等原因造成子版本是不可发布的,只能总体发布的局面,这样总体进度就比较难把握了。

 

现在总结一下,其实还是可以分割成多个可发布的、粒度更小、更易控制的子版本的,如可先完成UI改版,给用户更好的体验;其他功能及架构改进则可根据优先级安排到不同的子版本中。

 

这是个重要的教训,我由此体会到了迭代开发的重要性。以后规划版本时,可以半月为基准,最多不超过1个月。

 

关键点控制问题:在Mars版本开发过程中,主要抓了前台Server的设计及code review,取得了一定的效果;但对关键点控制还是做得不好,还有很多漏掉的。

Instant check功能,是老功能,就没有特别关注,9.28部署上去时,发现了很长时间不能显示检查结果的问题。经检查,发现代码中存在很多问题,经改进,效率提高了很多。实际上对用户来说,这是个很重要的功能,因此需要把它列入关键功能,做重点检查、Review和测试。

 

还有登录功能也存在较大问题。现在输入密码后,要很长时间才能进入操作界面,这对用户体验绝对是灾难性的。而且该问题是我们的customer发现并提出来的!

 

功能复杂度增加原因:每个user增加了time zone,并需要体现在报表、alert和客户通知邮件等,这给RGS, AGMSCMS等的设计和开发增加了不少复杂度。

总结

Mars版本延迟发布的教训是深刻的,需要我们在以后的版本开发中加以避免,为用户提供更快、更好的服务。在互联网时代,你不需要完美,但你一定要快,一定要根据用户需求、竞争对手情况快速进化,如果慢,那你就死定了!

 

互联网法则“快鱼吃慢鱼”是一条你必须遵守的法则!

 

  <script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script>
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:16190次
    • 积分:386
    • 等级:
    • 排名:千里之外
    • 原创:17篇
    • 转载:4篇
    • 译文:4篇
    • 评论:0条
    网站监测