去年5月份，公司项目较少，我就组织了一个用于公司内部办公管理的项目（以下称OA)。第一个目的是为了让公司里面一些技术较差的人员得到真正编程的锻炼；第二个目的是为了使用空闲的人员为公司开发一个产品，在内部推行科学管理，以后也可以考虑销售。
结果一直到今年4月份，这个项目才算上线，开发进度一拖再拖，代码质量很差。回过头来考虑原因，有以下几个：
1）程序员技术能力弱
2）对JSF技术不熟悉
3）JSF框架有Bug，并且可用tag较少，不足以应付项目，还需要额外开发自定义tag
4）人员变动频繁
5）按照<<Software Engineering>>最新版的建议和日立公司开发流程结合指定的开发流程不合理
a)设计阶段连web界面的每个控件(tag)的表现形式都描述的清清楚楚，花费了大量的人力
b)开发流程如下
use-case设计－》画面设计－》系统建模－》数据库设计－》编码－》代码评审－》
单体测试式样书编写－》单体测试
集合测试式样书编写－》集合测试
这个开发流程看上去很完美，其实由于国内项目进度要求都很高，其实不能支付这样高昂的开发成本，并且如果项目管理不当，很多文档写了，却没有人遵守。
6）管理人员对代码审查把关较弱
7）缺乏一个合格的项目经理，我因为兼顾公司很多事情，项目经理只是挂名而已，唯一把好关的就是数据库设计是自己亲自做的
8）对OA的复杂业务（特别是考勤业务）缺乏经验，设计人员也是边设计边改。
以上说的是问题，下面也说说说收获：
1）程序员得到了实战的机会，原来我公司的能力弱的程序员一直没有机会编程，只是做一些测试工作，这次让不少程序员得到了较大提高
2）对JSF基础知识的掌握，通过实战和编写文档等方式教育，培养了一个了解JSF技术的团队
3）OA是公司内部第一个多人开发的大型Web系统，从这个过程中发现国内项目普遍不能承受<<Software Engineering>>和日本开发流程中的“完美”过程管理，因此对后来的OA开发流程进行了简化：
use-case设计(包含Review)->美工画面设计
->数据库设计
->程序员编写基础画面->整合美工的画面->编码->代码评审（特别加强）->程序员交叉测试（按照use-case要求）
4)代码评审的工作如何更加有效呢
要求程序员先编写调用代码（有点类似测试驱动开发的方法，这个时候很多类和方法其实不存在，所以编译不会通过），技术管理人员评审调用代码，没有问题后程序员再逐一实现各个类和方法，最后技术管理人员再作一次代码评审。为了保证质量，降低成本，代码评审工作是重中之重。
5）使用了NetBeans6.5+UBuntu8.10的开发环境，一个获得了较好的开发速度(Linux性能好），而且避免了windows的盗版问题，Eclipse配置比较麻烦，NetBeans更好上手。
6）找到了ICEFaces Framework进行后续开发，ICEFaces能够提供web 2.0的一切特性，并且只要编写纯Java代码，降低了程序员的负担，JSF所有的基础知识都能够使用。
因此，我认为现在OA的Alpha3开发出来的产品一定比之前的更快、更好，而且功能强大。不过还要继续实践下去。
后续1(2009－7－19)：