2009年软件部开发部工作重点

1.      代码检查

这可能是目前最急迫的工作！因为从最近Stockholm项目的检查工作（包括翻译和功能两方面）中，还真发现2005年开发ODMS（也是当年APJ最大的一个项目）存在不少编码问题，比如说Hardcode、对象未释放等老问题，说明我们对编码标准的执行还很不够。其实，5月份还委托TownGas项目组对JPSS和BMIS也进行了一次Code Review，也发现在代码组织、层次关系、数据库操作方面存在一些问题，所以安排一次公司级的大检查是完全必要的！

已经决定， 9月下旬将对全公司刚刚完成的项目（如MFC Phase I、IRMIS、SIF、SIM Phase I等）以及正在进行的项目（如CAS、MFC Phase II、SIM Phase II等）进行互查，之前要求各个项目组在9月中旬开展自查。为方便自查与互查工作，9月上旬将讨论并确定代码检查的准则和清单。

2.      Common Library的建设

如果说代码检查是当务之急，那么Common Library的建设则更加具有战略意义。凡是从事过开发工作的人都不否认Common Library的建设对一家软件公司发展的重要性。APJ的Common Library的建设，从2003年开始也历经了几年时间，但始终没有达到大家的期望。今年我们应该横下一条心把这件大事情做成！

为此我们还改变了之前“开发→培训”的模式，为“设计→讨论+培训→开发”的模式。这样一方面使设计尽可能满足众多项目要求，而且集众家所长；另一方面通过设计讨论的过程对每位参与人员（项目负责人必须参加）进行了非常深入培训，可以在实践中更好执行标准。

但在实际执行当中还是有新问题出现，就是参与人太多、且各有各的想法，拖慢了Common Library建设进度。所以还恳请大家献计献策、推进Common Library建设。

3.      项目估计、工作量、效率

一般情况下，我们所作的项目估计与客户期望的进度是存在差距的。之前的做法大多是“质量屈服于进度”，想尽办法也只是为了满足客户的进度要求。但实际上，这已经埋下了后患。为了解决这个问题，争取合理的项目时间是必要的！

但如何才能说服客户制定更加合理的开发计划呢？我想事实胜于雄辩，我们应该基于已有的项目经验向客户提供更多的数据，比如人工生产率（代码产出率）、功能点的复杂度（低、中、高）以及预估的代码行数（不同的复杂度代码行数不同，但相同复杂度的功能点代码行数在一定范围内浮动，根据生产率可以预估工作时间）。这样客户不接受也不行。

其实这样做还有一个好处，就是让每位同事的工作也透明起来，一个人做了多少功能点、复杂程度如何、代码量多少，方便对个人工作能力评价。

但说实话，如何确定功能点和复杂度，目前我们还没成体系，需要一定的时间去研究、探讨，也希望大家积极献计献策。