有个总结

所有的博文基本都是技术性的，今天来个特别的，标题借用一下“有家客栈”

新近参与了一个项目，客户是一家跨过公司，全球500强，系统功能块不多，但是业务逻辑比较复杂。

我在其中的角色主要是报表的开发，原因是之前用Reporting Service 2000开发过数量不少的报表的经历，事实上现在使用Reporting Service 2005开发，不少新东西还是需要了解的。另一项职责就是顺便帮忙其他团队成员熟悉使用公司的新开发框架。而我来公司也不到一年，从进门到现在，也没做过多少常规的开发，所以对公司的新老框架其实了解不多，所以主要还是靠着对技术的掌握发挥了一些作用。

客户还是很急的，开发一个月左右的时间就要求前期功能上线试用，我加入的时候，项目经理和其他成员刚刚了解完需求，原始需求资料基本是英文写的，幸亏之前也做过外包的项目，了解国外公司的一些惯用手法，所以需求的了解没有想象的那么困难。

开始开发了，项目经理和另外一个成员都是新来公司不久，素质都还不错，但是显然LINQ、公司框架的学习成本还是产生了一些阻碍，项目开始时进展缓慢，幸亏没有使用SVN来做源代码管理，否则学习成本增大，风险就更大了，我是从其他部门借调来的，所以沟通不足也是一个负面的因素。

20个左右的报表，原定2天1个的速度，现在几天就开发完了，前期由于对需求不熟，慢了一些，后期可以借用前期的中间成果，所以速度上也加快了。但是不幸的事还是发生了，由于项目组需求理解的问题，报表的数据逻辑发生了变化，幸亏做的时候有一些封装，所以修改的工作量减少了很多。不过修改还是引起了不少的问题，加上之前没有和用户充分沟通报表的每个细节，而开发时缺少数据，又没有充分验证，所以测试过程中，bug还是不少。 

 目前，我已基本退出该项目组，总体感觉，项目状况虽然可以，但是不足的地方还是很多，关键的几条体会总结如下：

1、需求一定要和最终用户确认过，最好用原型沟通过，否则后期修改影响会很大

2、需求规格说明要尽可能详细，列表要说明每一列的来源、格式

3、编码完的一定要进行验证，能够单元测试就单元测试，再熟练、再自信的程序员也是一样

4、使用新技术和新框架，要考虑项目成员的学习成本，注意控制风险

5、条件允许，尽量使用更好的源码管理系统，提高生产率

6、沟通至上，一定要尽快打破沟通的障碍

7、建立统一的成品质量标准， 并事先公开给项目成员