回复 5# uuforce
2.
对于一个正在处于维护阶段的应用系统，在这阶段如何提高新开发与修正BUG的质量？谢谢。不管处于哪个阶段的应用程序，都面临这个问题。以下就如何提高新开发与bug修正的质量，说说我的一些看法。 1.
一切问题的根源在需求和需求分析 2.
无法有效提高修复至少说明了两个问题，一是不善于总结，二是人的能力问题 3.
糟糕的配置管理 4.
跟踪滞后 看法是其次的，也未必全面，不过有些做法倒是可以借鉴，如下： 1.
需求分析要给力啊。开发的基础是设计，设计的基础则在需求分析。需求做不好，质量也好不到哪里去，来回修改不说，bug的界定都会有问题； 2.
新功能开发前，最好可以提供一个可供用户确认的UI原型 3.
新功能开发过程中，一定要对现有需求和设计进行评审。哪怕是小范围的，局部的； 4.
新功能开发过程中，需要进行定期的代码抽查；运维项目的代码抽查是很重要的 5.
每次发现bug都应该分析bug产生的原因和引入阶段，这是基本点。而且要周期性操作并实施总结，并给出技术意见来规避类似bug的产生。常规的做法是列出一份常见bug清单及规避方法指南； 6.
加强开发人员和测试人员的技术规范培训，单单有总结还是不够的，经常性的总结和技术规范培训应该是长效机制，这两点实行后可以在较短时间内得到较为明显的改善；实际上还有一种方法可以更快见到效果——直接将这两项内容的执行并入到绩效考核并直接与薪酬或奖金挂钩。 7.
加强内部配置项的管理，增强流程执行力度。有些问题的产生并不一定是开发之罪，而是来自于流程混乱和上下衔接的错漏。比如：代码签入签出的相互覆盖等等。始终记得，软件——特别是大型软件的开发是一项团队工作，个人能力的强弱可以影响一部分，但是决定因素在整个团队的整体素质（有兴趣可以读下短板理论） 8.
任何一个发现的bug都是有有效期的，特别是在项目中，由于受限于开发时间，版本的更迭速度非常快，两三天一个版本的情况时有出现。如果bug经常性拖延修改，不仅会阻碍开发进度，更会留下地雷和深水炸弹。所以，对于已经发现的问题应该立即确认并安排修改，在时间上保障。这点可以参考下微软的做法——必须优先考虑的是bug的修改而不是新功能开发（这点在产品的研发上尤其重要）。 9.
Bug的修改过程首先是代码修改过程，其次是个代码修改成果的确认过程。开发人员直接修改代码后，本地不编译调试进行单元测试的习惯非常恶劣，这也是bug修复质量不高的主要原因之一。建议还是应该从开发那边入手，提高其自觉性。可以参考的做法 扩展阅读： http://pm.manaren.com/zlgl/201103/5317_1.html | 
/1 
关于我们
发表于 2011-4-22 13:34:53
发表于 2011-4-22 14:22:33
