YMU2.0开发总结

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>