http://www.cnblogs.com/guilin_gavin/
持续了1年之久的一个项目，终于顺利结项了，大家的心情都很激动，有必要开一个总结会，谈谈我们在这一年中的得失，说说我们项目中的那点事儿， 下面作为一次会议总结，主要从优点、不足和建议三方面来划分大家的各种想法，作为自己的一个记录，在此和大家分享：
<!--[endif]-->
|
发挥比较好的地方 |
|
1. 项目二期的进度合理，无加班现象。 2. 项目中规范统一的div和css的使用提高了开发效率。 3. 中美双方团队之间每天的IM会议和Email沟通的效果很好。 4. 团队内开发和测试人员的工作分工明确、任务量分配合理。 5. 项目团队对任务工作量的的前期评估准确率较高，保证了项目Schedule始终处于可控状态。 6. 项目组内服务器由专业人员负责，为项目的开发和测试提供了很多便利。 7. 团队成员在对项目需求的理解、讨论和反馈等环节表现得很高效。 8. 在面对前期众多不定因素和资源不足的前提下，团队成员共同努力，使项目慢慢步入正轨，直到最终完成。 9. 团队成员的位置集中，保证了高效的团队沟通质量。 10. 团队成员在填写Bug Tracker时，对于注释的填写很认真，信息量也很全面，节省了大量的时间。 11. 美国团队在项目前期的工作很全面，在项目进度和需求管理方面都很高效，保证了项目的质量。 12. 美国团队给予了全方位的支持，不仅提供了高质量的需求文档，还保证了每次沟通的及时有效。 13. 测试人员提交bug的有效性很高，并能及时地review出现的问题。 14. 测试组对系统的问题控制很好，能始终保持高质量的测试标准，并积极配合开发人员解决问题。 15. 开发团队和测试团队间的协作顺畅，团队氛围良好，而且大家的工作热情也很高涨。 16. 开发团队在攻克关键技术难点时，表现得十分高效。 17. Leader对项目的进度和节奏控制好，保证了项目的顺利进行。
|
|
有待完善之处 |
|
1. 项目版本数量较多，缺少严格的控制机制。 2. 团队成员间对需求的评估和讨论的机会太少。 3. 项目安全性问题没有得到应有的重视，导致后期页面权限问题变成一个很棘手的问题。 4. 项目中有待抽象的功能模块较多，缺少时间进行进一步的优化整理。 5. 开发团队成员间彼此Review代码的机会太少。且需求更新过于频繁，直接导致普遍出现对前期需求理解不完全的情况。 6. 在回归测试过程中，暴露了很多因前期的需求理解不够全面和测试质量把关较松造成的问题。 7. 测试团队有必要加强Test Case的质量，尽量照顾到全部的功能点。Test Case review会议没有落实到实处，且没有根据需求的更新情况及时更新test case，最后，没有及时提交测试后的test case结果。 8. 二期的测试工作量较大，主要因为增加了Test Case的工作环节，还有处理第一期遗留的大量需求变更。 9. Bug Tracker的优先级别设置不够严格，截图的大小控制较差，bug的处理方式选项不够全面，且出现重复bug的几率较高。 |
|
好的建议和想法 |
|
1． 在中美团队协作过程中，建议尽量多主动反馈一些问题和意见。 2． 在处理CSS样式等可能涉及项目整体的问题时，建议谨慎处理，以保证整体功能的可用性。 3． 建议因地制宜地改进Test Case的编写方法，以便更加高效地发挥其作用。 4． 建议加强对项目Schedule的重视程度，尽可能地争取合理的工作时间，以减少项目风险。 5． 如果条件允许，可考虑通过参数对象的方式来连接BLL和DAL层。 6． 建议能适量增加团队成员间的沟通活动。 7． 建议适当增加阶段性的开发和测试总结交流会。 8． 建议增加阶段性的项目子功能模块演示，以增加团队成员对需求的整体理解程度。 9． 建议进一步优化团队成员资源的调配利用。 10. 建议增加团队内部的技术培训活动。 11. 建议尽量保证项目中代码风格的一致性。 12. 建议团队成员应加强自己对项目的全局意识，以便能多发现一些隐性问题。 13. 建议努力提高个人代码质量，寻找性能及时间的平衡。 14. 通过Email沟通的问题，建议尽快予以反馈处理。 15. 存在一部分测试内容没有完全按照需求文档执行的情况，建议在test case方面多做一些工作，同时，团队Leader有必要加强对质量的监督。 16. 无论开发团队还是测试团队，都建议加强对需求的整体理解程度，且尽量增加开会讨论的机会。 17. 需求更新途径较多，导致一些需求的变更没有得到严格的跟踪，建议通过Email或Excel来进行跟踪。 |
珍惜每一次自己付出的机会，并及时总结自己的心路历程，是一个受用终身的好习惯~