第一年工作小结

       虽然是去年7月份才工作的，但事实上，我确是从去年3月中旬就已经在实验室开始工作了。（因为毕业后留实验室的原因，我虽然还没有正式毕业，但其实已经是开始工作了）。
       从时间上来讲，主要分为两个阶段。

        半正式工作期间：
    
         2006.4－－2006.7   BUG系统需求获取。 需要开发平台的一个新增功能: BUG管理功能模块。我是任务负责人，带领2个从云南大学来的实习生做这个Project。由于项目需求主要来源于平台用户的反馈和平台自身功能完善的需要，而没有人对需求有清楚的描述，甚至做成什么样也没有人有定论。因此，在前一个月，团队主要进行系统调研和需求确定这件事情。我们先后调研了 BUGZIALLA, Mantis, BugFree, JIRA等系统，在调研这些系统的基础上，我们对平台新增BUG功能模块进行了原型设计，用于和涉众进行讨论，以进一步确定需求。
        在第一次讨论会上，我们的原型作为大家讨论的基础。根据这个原型，销售负责人，测试负责人以及开发负责人都提出了很多需求以及他们设想当中的系统应该是什么样的。老板也参与了该需求讨论会，并最终确定了产品开发的方向：要把功能都融合到平台中去，而不要单独做为一个组件，便于推广平台……
        第一次讨论会之后，我们半个月之后又拿出了新的原型系统，再第二次讨论定需求，由于老板没有参加，很多需求细节有很多争议，不确定。之后，我们又半个月继续补充并整理需求，第三次讨论需求，这个时候，虽然对需求还有一些争议的地方，但是大局以定。一个星期之后，我们进行了第四次需求讨论，在该讨论会上，基本对需求打成了一致意见。
        之后，我们小Team就开始制定原型系统，编写用例归约文档，交测试组进行评审，以方便他们编写测试用例。前前后后确定需求花了大概3个月的时间。

    正式工作期间：

       2006.7－－2006.9   BUG系统开发。经过前期的需求获取之后，本以为可以轻松搞定这件事情。但云南大学的两位实习生要回去了，无奈又招了两个低年级学生加入到开发中。前面半个月主要负责培训需求、项目规范、项目架构、开发工具和语言培训。之后他们又放了半个月的高温假，我放了一周。正式开发就从我高温假回来之后开始。我负责设计模块架构以及业务层，领域层以及DAO层的开发，他们负责页面表示层的开发。到9月中旬，系统开发完毕。算了下，其实真正开发系统不过用了一个半月的时间。

       2006.9－－2006.10  BUG系统的组内测试。10月休假之前，我们已经完成了开发并开始了系统的组内测试。通过两个星期的测试，期间使用的就是自己开发的BUG管理系统，我们自己总共在系统中提交了60个BUG，并全部解决了。

       2006.10－－2006.11  BUG系统的集成测试。这段期间，将BUG系统和平台做集成。由于平台底层DAO已经做了大量重构，BUG系统是否能够正常运行是个很大的问题。且我个人认为DAO重构的质量难于保证。基于两点，第一：DAO重构有很多是由学生来完成。第二：DAO重构没有写单元测试。并且这种重构属于个人行为，难于获得 IDE的支持。在实际集成测试期间，确实有很多以前没有出现的问题出现了，同时，BUG系统和平台集成还需要考虑风格，权限，处理方式，以及易用性上的一系列问题。通过这次集成测试，系统功能基本稳定。

      2006.11－－2007.1  平台V2.9.4版本发布测试。主要测试的是：BUG系统以及其它新增功能，还有整个系统的测试。每到这个时候，测试总是能提出一些小需求。确实是测试组呀，厉害。这轮测试，不仅测试了历史项目，还测试了和以前版本的兼容性，还解决了很多小需求，小问题。总共解决130个BUG。配合平台V2.9.4版本发布成功。前段期间交给两位学生做的代码经受不了测试组严格甚至可以说是苛刻的测试，这段期间，我只好承担了修改BUG的主要责任。加班很多。

       2006.11－－2006.12  度量功能模块需求获取以及设计。度量按说是实验室的强项，王老板和她的博士生基本上是国内研究度量的个中翘楚。需求基本上是度量小组来定的，我们负责设计实现。但即便是这样，也发生了严重的需求变更，这是我们史料不及的，需求变更的影响之大，使得我们最初的设计基本上是需要重新做。以前根本么有用户自定义度量，也没有度量的多层次原因分析，用户的使用方式也完全变化了，引出了另外一个需求：项目数据基线。
       当时，度量功能模块也主要是由我来负责。经过这次需求变更之后，项目的实现难度明显增加。我和项目的两位项目经理进行分工，btw，我不是项目经理。我负责度量底层数据结构，存储和数据传输以及客户端数据访问。另外两个项目经理，一个负责基本度量、派生度量的定义以及度量脚本的编写，另外一个负责度量报告和PCB报告的生成和保存。
     
       2007.1－－2007.2.12  度量功能设计和开发。平台V3.0版本需要在07年4月末给用户，已经用用户签好合同了。但这个3.0中的主要功能：度量还没有开发，整个项目组压力很大，我们又开始了漫长的加班阶段，基本上每天都到晚上11点。截至2月12日，我负责的项目数据基线导入和存储，实体数据定义，实体数据库的生成和存储，实体数据库的传输，客户端数据访问功能开发完成。由于再晚就买不到去厦门的机票了，我提前4天回去度假。此时，度量功能的基础部分已经搭建起来了。感觉收获很大。

    2007.2.12--2007.3.4  休假当中，前前后后算起来有三周的时间，我一直待在厦门这个如花似锦的城市，好舒服。只是时间有点长了，我宁愿用时间来换钱，哈哈:)

      2007.3.4－－至今  平台V3.0版本发布测试。主要测试的是：度量。4号回北京，8号来到无锡进行封闭开发，一直到现在。
    每周工作六天，每天的工作时间安排是：工作时间：上午8:30-11:00,下午 1:00-5:30，晚上7:00-9:00，必须保证每天9小时的工作时间（如果白天因个人原因工作量不足，请延长工作时间）。
    测试组和项目组都来了，此次测试，测试组使用我们开发的BUG管理系统来进行测试管理。在实际使用过程中，他们又提出了很多有关BUG管理的新需求以及使用建议。因此，前三周主要就是处理新增需求以及修改部分度量的代码，以满足变化。到目前为止，BUG管理系统应该是比较贴近用户的需求了:)。我负责的度量部分主要是底层，页面上的东西少，因此BUG少。
       
        回想起来，时间过得实在是太快，一年时间转眼就过去了，主要就是做BUG和度量两件事情。我个人觉得自己在这一年期间是很努力工作的，应该是对得起当时自己留在实验室的承诺的。我也有所收获，不光在个人技术和能力上有所长进，同时也增加了一些项目管理的经验，但更重要的是我开始明白了做人的重要性。我开始意思到不管你从事什么样的工作，这个和人交往的能力，做人很重要。
        “说你行，你就行，不行也行。说你不行，你就不行，行也不行。”以前对这句话没有太多领悟，但这句话确实是很经典。我本来就是实验室培养的学生，毕业后又留在实验室工作，处理好各种人际关系应该对我来讲，并非难事。但是实际上，如果自己不去用心经营，这人际关系也不会好。
        再说，我个人性格上有缺陷：我一直就是属于那种比较自信的人，觉得自己比其它人出色。自己在工作中对自己严格要求，对其他人也是要求苛刻。如果别人没有做到合乎要求，那么我肯定是不高兴，难免会得罪人。再加上，我一直对测试组的工作有看法，觉得他们的进度和测试水平有问题，在改BUG的过程中会和测试人员的看法有所不同，产生不一致的理解，会带来争论，这也难免会得罪人。曾经就有测试经理在开会时向王老板反应我负责的BUG系统遗留的BUG多，闹得开发经理跑到我这里来质问:(，但实际情况呢，毋庸我来多讲。
       是我的问题，我一定改得了。以后不管是在工作还是生活当中，都要注意这个方面。搞好关系，不要把属于自己的机会白白扔掉。做事情的时候，要讲究方式和方法，才能团结一切可以团结的力量，来做好项目，做好产品。