总结

一、    负责项目工作总结

08年5月，我加入了公司被分配到DPOS系统工作。在项目初期，负责对JasperReport报表组件的研究使用，以及编写组件的使用文档，为组员在项目中应用JasperReport报表组件做技术准备。另外，研究Hibernate、Dwr Ajax技术应用，为项目组员准备使用文档。

项目开发过程中，主要负责盘点单、盘点录入单、盘点方案、调拨单等模块编码工作；以及在杨建香同事离职后，积极配置项目组长安排调配，接手供应商和进货订货模块工作，保证项目地顺利进展。

该项目首先引入EXT，给项目中的模块实现带来一定的挑战；密密麻麻的js代码、频繁的细节问题增加了项目的难度，同事间的通力合作成就了项目的顺利完成。

项目中的工作角色及内容

1.         作为DPOS系统开发组员，负责盘点（盘点单、盘点录入单、盘点方案）、调拨模块的编码工作；以及同事离职，接手供应商、进货订货模块的工作。

2.         作为JasperReport报表组件带头实践者，为组员提供组件应用培训，指导及解答应用过程中的问题。另外，为项目收集Hibernate应用经验，以6个实例工程帮助组员理解Hibernate的配置和应用，并为组员开发过程中的问题提供指导和帮助；同时，为实现页面无刷新重载，研究应用Dwr Ajax技术，并以一个实例工程配以文档阐述Dwr的配置、关联、使用，为组员应用该技术提供技术支持。

3.         为项目开发共享函数及js文件，提供简单参数传递实现项目中各个模块都需要应用的处理过程，为项目争取到时间。

4.         在完成自己工作，帮助同事的模块实现。

 

 

遇到的问题及得到的帮助

这个项目成功完成，离不开江涛的大力帮助，在项目前期技术准备及开发过程遇到的难题，给我很多指导意见；悉心的引导、耐心的讲解，让我在进公司之后能够很快的适应到这个开发环境，为之后项目工作的开展提供基础，在此谢谢他！同

 

时还要谢谢吴敏志，在需求到实现的过程给我很大的帮助，让我的实现变得有价值，能够按着顾客的需要来进行。还有谢谢梁瑞能负责任的领导，不断细化到对项目的模块的进展情况的关心，鞭笞着对项目模块的不断完善，像一个心脏，泵动整个思维的血液，让我的模块能不断完善、优化。

二、    项目经验和教训

²        对需求的看法：在项目编码之前，应该调查程序员对负责模块的理解情况，安排一定次数的单独沟通机会，了解程序员对模块的理解是否是需求想要表达的。传话筒传过多人，意思和味道可能都变了。另一方面，也可以及时纠正程序员对模块理解的偏差。

²        对设计的看法：当前的这种设计方式很不错， 但当设计完成传递到编码，在接口调用及系统整体框架保持不变外，检验编码实现是否考虑了全部支线事件流就很难监控；以及让重构优化代码变得困难，更为严重的当修改了一个BUG，引起一堆BUG，使得后期对代码的维护变得绑手绑脚。

我觉得可以采用测试驱动设计（TDD）方式，在设计的过程中，建立测试类包含测试所有的事件流（主、支线事件流）。这样设计人员更容易检验编码是否按着设计意愿来实现，以及编码人员更有把握地重构代码，甚至增加新功能也不怕影响已经测试通过的代码。

²        对编码的看法: 在编码之前应该对自己负责的业务模块所表示的概念，以及该业务块与其他业务快之间的联系有个清晰的认识。试想想问问自己这些问题：我们的业务块是什么？我们正在实现着什么？我们应该是什么？当思维有了冲突，那么需求就能为此解答，而尽可能避免我们偏离需求。

²        对技术的看法： 我觉得项目中技术的共享力度不够，当某一位同事遇到个技术难题，而其他同事都很忙，也不清楚其他同事能否帮助解决该难题，尽使自己咬尽指甲，抓破头皮。等到项目例会再来反应该问题，应该又一周了。

每天早上，应该准备10分钟探讨组员前一天的难题，每个成员各抒己见为该难题提提看法。不仅可以对问题透彻的了解，而且能应用各个组员的长处。

对测试的看法：说实在测试是本项目中做得最好的一个环节，对系统测试覆盖面广，对BUG定位准确，甚至在业务BUG问题上，能指出到某个数据表特

 

²        定字段，为开发人员缩小修改范围，节约修改时间。加油，好的系统离不开你们的汗水。

²        对UI设计的看法：本系统的UI界面做不错，特别是POS端的操作界面，页面布置、功能分工明确，操作过程不论你当前处于何处也不会“迷路”。 通过一个“工具”按钮就简单地将各个功能块联系起来。

²        对项目内协作的看法：项目中各位成员各施其职，项目顺利完成。

²        对与其它部门或组协作的看法

²        自己的收获：理解需求是多么需要，当一切都已实现完了，需求说这不是我想要的，那份提薪吊胆很不好受。 所以在编码之前要弄明白需求的意思，搞清楚设计的思路。

 

三、    项目管理优缺点和改进建议

u       项目进度控制作为项目管理一个重要环节，然而却很难被控制，原因是无法准确估算模块工作量，我们经常用一个模块、一个类、一个方法来概括工作量；一个模块到底多少工作量？一个方法又是怎么才算实现完成？主线功能都完成，然而留下一堆的BUG，修改老BUG又带来新的BUG，一个方法究竟是多少工作量？

采用测试驱动设计方式（TDD），在设计的过程中，建立测试类包含测试所有的事件流（主、支线事件流）及可能发生的业务异常。根据测试流的数量、及实现难度估算模块的工作量；在实现过程中，编码人员对实现的测试流统计，了解当前模块的进度情况。

             

u       “现在遇到什么困难，需要什么资源可以更好地协助你解决当前问题？还需要多长时间才能解决当前问题？”然而，总不能得到确定的答案！这些问题可能已经困扰了好几天了，而且也不确定解决方法，只在周例会才被谈到。或许不用等到周例会，就暴露出这些问题，或许可以听到其他组员的解决方案。

 

 

 我觉得应该可以有一个：每日10分钟的小会。在早晨，所有开发人员都站到一台有最新系统版本的电 脑前，然后探讨前一天开发中遇到的问题，或者做了什么共享方法类。这时候所有组员可以各抒己见，围绕问题展开探讨或者介绍共享方法类的使用。项目组根据其贡献情况给予考评、记录绩效。