软件开发团队的质量管理的几点想法
近在学习PSP，其核心思想是：记录自己的工作数据，通过数据找出有问题的地方予以改进，通过数据预测自己将来执行某项任务时所需要的时间。 如果衡量开发人员的工作需要真实地记录他们工作的执行情况的话，那么开发人员似乎没有很大的动力做这件事，因为： 他们似乎需要花费大量的时间执行一些和任务本身没有关系的事情。 由于PSP也需要开发人员记录自己代码的缺陷，因此开发人员可能宁可不记录，来让自己显得“不那么笨”。 所以，我必须找到一种激励方法，让他们愿意如实地记录自己代码中注入的缺陷。我们可能不能采用“发现缺陷则惩罚”的方法，因为代码中总是有缺陷的。我们或许可以采取一定的奖励措施，这种奖励措施由“短期的、相对容易实现的目标”和“长期的、不容易实现的目标”组成。前者的目的是引导开发人员经常性地关注自己的代码质量，努力降低缺陷率。由于是短期的且相对容易实现的，则相应的奖励也比较小。而如果在一个较长的时间内开发人员能够始终保持低缺陷率，则第二种奖励便可自动达到。 例如，“短期的、相对容易实现的目标”可以是在一个迭代中“每千行代码包含的缺陷数量低于10个”；“长期的、不容易实现的目标”可以是在连续的12个迭代中至多只有2个迭代的缺陷率没有达到“每千行代码包含的缺陷数量低于10个”。 我们不应该采取“发现缺陷则奖励”的措施，因为这会激励测试人员去汇报一大堆无关紧要的缺陷。对于测试人员，可以采用“产品发布后，在一定时间内客户没有报出一定数量的缺陷，则奖励测试人员。” 无论是对于开发人员还是测试人员，这种奖励好是针对团队整体的，或者至少是团队层面和个人层面都有的，而不要仅仅在个人层面。这样做的期望是让每个人都为团队整体的绩效负责，同时在某些人可能明显拖整体后腿的前提下，让一些一直努力的人可以得到奖励。 要让开发人员明白，他们的职责是两点： 按时开发出符合质量要求的产品。 为公司省钱。事实上，这第二点要求是第一点要求的连带产品：只要“按时”和“符合质量”，为公司省下了钱。 终的目标：让团队在保证工作质量的前提下，过上朝九晚五的生活。注意反之是不成立的。
