某日关于项目delay的总结

存在问题：
1：开发环境与测试环境差异过大，很多问题无法直接开发环境验证。

2：开发过程不可控，需求的变更有点频繁（微博需求单号DBANKDEV-3216，从2月15日提出至3月31日仍不间断更新），并且需求的变更没有很好的管理起来，导致需求的遗漏和追踪困难。

3：开发并行的任务过多，并且没有注意优先级别，很多人都是来回几个工程来回切换，或者是一个人负责好几个模块。站长需求，统计需求，微薄需求的公示的转测时间相冲突。

4：版本管理不严格，版本发布目标不明确，现网积累的部分问题都归纳于此版本解决(共享问题)，并且没做好现网版本的归档。

 

5：涉及接口的改动过多，并且从策划到开发到测试的响应效率不高，改动成本过高。

6：测试没有全面完整的测试用例覆盖，并且bug单的优先级别没有被很好的管理，开发与测试由于是两个不同的公司负责，协调和管理上存在一定难度。

7：连续加班，团队气势低落，影响团队稳定。

以下是各项的改进措施及建议
1：降低开发环境与测试环境的差异化，目前，微薄的开发已经基本和测试环境一致（后期才改进统一的)，但还有一些比如获取文件目录，树信息，发邮件无法和测试环境统一起来。

2：敏捷不代表忽视项目管理的重要性，需求的变更直接关系到成本的大小和过程的可控，需要有项目经理参与到变更的流程和管理中来。

 

3：资源有限的情况下，并行的任务不宜过多，否则影响质量不说，进度也不好控制。建议增加人员，目前由于资源有限，很多开发人员都需要横向的负责多个模块，或者整个工程或者多个工程，并且负责模块不固定，这样会导致模块问题模糊，难于确责和追责，引起所谓的＂责任心＂问题。

4：版本的管理不严格，规划不明确，现网版本改动的问题没有归档到现网版本中，而是直接在主线的开发版本进行，这样会产生难于预料的问题，建议版本之间要归档，对现网的改动需要马上更新的需要在现网版本中进行，而不是在当前版本中进行，两个版本需要并行开发或者是说分步发布，建议建立版本分支，然后各版本特性通过svn合并到主线版本中。

5：外部接口，尤其是php的接口，需要做单元测试，建议提高接口的设计抽象程度，毕竟接口的改动不宜频繁。建议难沟通的，需要马上响应的都要到位沟通

6：我不太清楚现在测试是什么驱动去覆盖功能点的，建议以用例的形式去做，不光开发的需要重视用例驱动的概念，测试和项目经理也需要有这样的概念，至少现在给我感觉不强，开发首先不重视用例驱动覆盖，所以会导致开发功能的盲点，项目管理不以用例去驱动，必然会导致需求管理质量管理，进度管理的盲点，测试不以用例去驱动，会导致测试的盲点，这就是为什么就快发布到镜像的时候，才发觉游客用户在微薄处理的情况和需求有一定出入。ps.策划也应该重视用例。

7：测试和开发工作不好协调，在发布到测试环境中，工作都是以测试的驱动去进行，测试的有问题单，开发才好修改，在进度紧迫的时候，测试需要额外的投入资源去做这快，而不是等开发解决问题单，然后测试再验证问题，主次颠倒，这样重大问题的发现往往到后面才发现到。建议可以安排XX的合作方的测试与XX的一起，这样协调门槛低一些。

8：加班难免，团队愿意连续加班至少说明责任心没问题，方式上或许有点问题，长期下来对团队的建设也是不健康的，之前做的绩效考核制度需要把质量的指标和具体的绩效考核联系起来，并且真正有效执行，以奖励为主罚为辅，客观的说合作方的开发属于指哪打哪型，在开发过程中，很少主导权，如果不分析真正原因，不客观的分析，处罚是达不到目的，且会有反效果的。

 

9 ：其他，开发人员往往发现问题，有重构的心但没重构的时间和资源，建议有腾出或者挤出时间资源来做重构。