进入公司差不多有3年的样子了，大大小小的项目参与了不少，一路走来有不少的感想，总的感觉很累。无论是大的项目还是小的项目，总觉得效率很低，耗时很长，我不停的思考，究竟一个团队的产品开发和维护应该具备什么样子才能高效而快速的向前推进。
这段时间，“敏捷开发”变的很时髦，似乎不“敏捷开发”就落伍了，那么到底什么是“敏捷开发”呢？简而言之，敏捷是一种新的软件开发的思想，通过迭代、结对编程、测试驱动等实践逐步完善对软件的开发，最终形成稳定的系统。与传统的软件开发相比，敏捷强调人与人之间的沟通，而不是通过文档。
我觉得一般的网络公司的项目一般不是很大，项目开发有几个要数：
- 项目成员的主动性
- 项目成员的沟通
- 完善的设计文档
- 规范的流程
- 系统的自动测试
一、项目成员的主动性
大部分的项目都是比较小的（一些稍微大点的项目经过功能分割，实际上也比较小），考验的项目成员的能力。所以在项目安排上要有所区分，让合适的成员担任合适的岗位。在每个项目成员的所属的职责范围内，需要项目成员本身主动积极的去处理和探索所碰到的问题，要积极的承担项目中的相关责任。在实际的项目开发中，项目成员或许由于技能变的熟练或者其他等原因可能会比较消极的对待或者推诿责任。个人觉得需要采用各种方式来激励项目成员。
二、项目成员的沟通
毋庸置疑，项目沟通在项目开发中占着非常重要的地位。对于一个产品的迭代开发，一个项目组由开发工程师、产品设计师、测试工程师等相关人员的参与，如果不及时沟通，会导致需求和交付的产品不一致，会导致开发、PD、测试相互理解的不一致。在开发过程中，需要项目成员及时汇报自己的进度和下一步的工作，以便PM及时调整计划或者资源。一般沟通为一天一次比较好，比如我们现在是每天早上有个晨会，大家汇报自己的进度和碰到的问题，汇报明天的计划，如果测试有接入的话，测试会总结一下测试的情况和进度，这样如果有问题，大家在会议上立刻进行处理。一般晨会不易太长，5分钟左右。
三、完善的设计文档
很多项目有个很明显的后遗症：就是资料不全。后续接手的和维护产品的都不知道如何下手，这样也给人员的轮岗带来麻烦，故项目开发完毕以后需要有一份完善的文档，这个文档从产品设计到开发结束都需要不断的调整，需要整理到相应的文档库中。
四、规范的流程
一个产品从需求、设计、开发、测试、上线需要遵循一定的流程，比如要有DB表结构变更规范、代码开发规范、代码提交Review规范、测试规范、上线的流程等等。有了这些规范还需要严格的执行，否则是一张白纸，很容易出问题。目前流程是系统化和人工化各有一半，但个人觉得适当的偏向系统化一点更能保证系统的质量，毕竟单纯的靠人来监督还是有疏漏的。
五、测试驱动
系统开发过程中，很多人都很相信自己的代码，以为写完了就好了，就提交到测试环境让测试去测试。其实这个是非常不负责任的行为，一份提交给测试工程师是需要经过自己严格测试以后，否则到测试工程师发现问题以后，然后再反馈调整，无疑代价扩大，同时牺牲了开发和测试的宝贵时间。所以一份提交的代码需要经过几个环节：1.开发个人的单元测试。2、系统的自动化测试。3、经过前面两个环节的过滤以后，才提交到测试环境。
当然在实际的项目过程中，还有其他因素（比如环境，E网打进产品和5-6其他产品有关联关系），那么就需要确保这些因素稳定在一个允许的范围内。另外，我觉得需要有一些奖罚机制，比如BUG数量、规范的执行情况等，当然奖罚并不是目的，目的是警戒一下没有遵守规范和规定的结果。
好了，罗哩罗嗦这么多，上面只是我这段时间来参与项目和带项目的一些感想。还需要以后不停的总结和改进。