此文写于2013年7月10日，转自我的开源中国https://my.oschina.net/vell/blog/143770.
以下社区项目总结：
且听我从立项到开发再到测试并上线这个顺序来一一道来，其中包含了项目组内同学的在总结会上提出观点.
一、立项(包含需求阶段)
1.没有明确的产品经理
在社区项目立项之初，由运营的同学出了份需求文档，明确了几个重要的功能模块，但没有将文档出的比较细，需求文档没有产品负责人来更新，由此导致开发和测试的同学对于需求理解很模糊，开发的功能中有很多细节没有关注到，这又使得开发人员按自己的思路对开发的功能进行主观的判断，做出了一些非常棒的细节性功能，但是这样的细节性功能有一部分可能违背了产品经理的观点，结果就导致了一些需求的小变动，开发人员不断进行返工，当然由于测试也是在开发过程中介入的，由此又导致测试同学也出现了类似问题，即不断的对这些小改动进行验证，不明确的需求细节的条件下，也产生了很多主观上的测试行为，这样就导致大家经常做了无用功，思路根本无法统一，也就是俗话说“费力不讨好”。
当然上述问题的产生在互联网项目开发过程中不可避免，而需求的变动是有成本的，这个成本可以归结为两类，一是时间、二是人力，即便是再好的敏捷开发团队，也无法保证需求的变更不会对质量和进度产生影响，这种变更必然是需要一个角色来承担责任和义务，那就是产品经理，而项目经理为了保证进度很可能不会对这种变更进行让步，这样便了产品质量和周期的矛盾，而要保全这两者，必然就会让整个产品研发团队做出付出额外的精力，而产品细节的确定也让团队付出了很多沟通的成本。
对于互联网的产品研发过程中，产品经理的角色是至关重要的，如果要做一款成功的产品，必须要有一个能握产品方向，关注和完善细节功能，对产品需求、运营计划做日常管理的产品经理来完成这些工作,这样才会更进一步增强产品互动性和用户满意度。
2.协作、沟通不到位
开发过程中前后端的同学没有良好的配合，主要表现在要在需求明确的情况下接口参数、数据格式前后端没有即时沟通统一意见，联调的时才发现问题，这样也程序的修改成本变大，还有后台系统之间涉及到的数据库表字段和注释的修改、系统接口页面的修改时，都要通知到相关人，并且得到他的答复后才能执行修改操作。
另外，使用svn时，代码提交前，没有认真测试，导致其他人服务器启动时报错，所以在更新了别人代码或提交自己的代码时一定保证代码能在本地正常跑起来，抽一部分时间出来自测，会省去很多处理代码冲突的问题的时间。
3.不重视规范
如果我们的编码规范、开发流程能认真的按要求执行，有很多沟通、测试的问题都能很好避免，例如业务代码、数据库字段注释可以让开发、测试人员都能第一时间了解细节到代码和字段的含义，有效的开展开发和测试。代码整理提测之前，如果都能把自己模块的单元测试跑通，把握好每个模块和功能之间的耦合，通过自测保证修改后的代码对整体的功能影响降到最低，这样既节约了测试人员的时间，也减少了开发返工的次数。
4.程序未充分设计
这一点提出来，也是为以后更快、更好的开发项目做准备，我们在开发设计阶段，要充分考虑功能模块组件化思想，不同的模块可以复用，功能代码通过组件的形式进行扩展。
组件化编程的关键目的是为了将程序模块化，使各个模块之间可以单独开发，单独测试。
基于组件化开发带来的优势，首先原有到系统级的粗粒度控制细化到了到组件级别的细粒度控制，一个复杂系统的构建就是组件最终进行集成后的一个结果。每个组件都自己独立的版本，组件可以独立编译，独立打包和部署。其次产品组件化后可以真正实现完整意义上的按组件进行产品配置和公用，用户可以选择购买哪些组件，组件之间可以灵活的进行组装。另外包括我们说的配置管理，开发，测试，打包，发布完全控制到组件层面，带来额外其它很多好处，如我们常说的如果一个组件进行小版本升级，如果提供给外部的接口没有任何变动，其它组件完全可以不用做任何测试等。
基于组件化的思想开发的同时，我们在代码的构建可以使用Maven或 Gradle这样的构建工具，加快项目的测试、部署周期。
