软件度量一直是软件开发中最容易引起争议、也最难能说服团队的一项吃力又很不讨好的工作。

  • 定个测试覆盖率的指标;每个团队的测试覆盖率都是 90% 以上,但在这 90% 以上的测试覆盖率,所形成的测试防护网里,却往往连个 “有效” 测试线上运维的测试用例都没有。
  • 定个单位代码行的缺陷率的指标;团队就总是只纠结着那个 “分母”;到底应该是百行还是千行。
  • 定个告警为零的指标;团队就总是在熬夜清告警,却又总是忘了应该要思考下,清完了一个告警,所会真正带来的商业价值为何?更忘了市场所要求的响应速度与自己的身体健康状况。
  • 定个用户满意度的指标;团队又总是只为了获得高的用户满意度,而忘了市场所需要的创新与创新所需要的试错。

我不是说软件度量这件事情有问题、不对。

而是软件度量这件事情,是很容易就被 个人的利益个人的主观意识,甚至是 个人的自尊心所给扭曲、所给区解的。

所以,我们也许该换个角度看看 “软件度量” 与 “软件质量” 之间的关系。

  • 首先,也许我们就该认为软件度量与软件质量之间是 没有任何 直接的关系的;也就是说,没有任何的软件度量能 “完全、直接、正确” 的界定软件质量的好、坏、优、劣。
  • 当软件度量与软件质量之间没有任何直接的关系时,那软件度量要拿来做什么?软件质量又要从何而来
  • 软件度量应该是要用来做 “决策”的。
  • 软件质量的界定;好、坏、优、劣;应该是来自于 “决策”,而不是直接的来自于软件度量。

也就是说,当团队知道如何的针对自身产品、团队的问题,而能制定出所需的软件度量时,并能从软件度量中做出适当的决策,自然而然就能把握有限的开发人力与时间,却能产出符合用户预期与市场竞争力的产品。更重要的是,能保证团队成员的身体健康状况的良好。

所以,我们不应该将软件度量与软件质量直接的就藕合在一起;而是要将软件度量与软件质量之间,以 决策将两者给完全的隔离

因为,只有这样,才会使得软件度量成为软件开发上的一个相当有用的 “决策工具”。当软件度量成为一个有用的决策工具时,软件度量才不会因为前述的人类行为上的偏差,而被扭曲、而被曲解。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据