软件过程中的反模式

最近看了<软件调试修改之道>,看到最后一章<反模式>,觉得虽然有些地方太理想化了,但还是很有借鉴作用的,因此决定记录下来,期间根据自己的体验做了一些修改.

1 混乱的缺陷优先级

既然我们优先解决最高优先级的,那么就有可能出现测试人员为了优先解决自己的缺陷而故意夸大优先级的情况

1.1 解决方案

• 定期对缺陷进行审查,确保缺陷的优先级确实能够反映出它们真正的优先级,并以此作为对测试人员的信用评价

• 写的越详细的描述,优先完成.(问题描述作为测试人员的成本,我们认为,越舍得花费成本的,其需求越高)

2 人员更替

经常由于预算或其他项目需求等原因而发生项目团队人员的更替. 然而人员更替往往存在交接双方旋接不上的问题.

而且若被交接人被迫要去修复交接人产生的缺陷时,也容易对士气产生影响

2.1 解决方案

• 任何人在仔细地完成当前工作之前,不允许任何人进入下一个任务.

• 采取自负自责的原则,谁造成了缺陷就由谁来修复它,即使他可能已经被分配到新的项目中了.

• 做好文档的工作.

3 将软件过程分成开发和维护两个阶段,由不同的团队维护

这容易造成以下缺陷: