京东购买链接：https://item.jd.com/10205955087769.html
6.5 度量与丈量
在撰写本书时，我们始终在两种极度之间寻求均衡：一边是盲目乐观地以为简朴的数字足以量化统统；另一边则是对软件度量尺度抱有显着的反感态度，以为它们无法精确反映软件开辟的复杂性。而正如常理所示，大概中庸之道才是最佳选择。
在我们的讨论中，度量指标是一个带有标签的数值。单独的数字“3”并无太多寄义，但假如说有 3 位步伐员正在开辟某个功能，这就构成了一个度量指标。我们在一样平常互换中常常使用度量指标，比方，“我们筹划周五下战书 3 点发布，另有 5 天时间”，这里就提到了两个差别的度量指标。根据《牛津英语辞书》的界说，我们所使用的度量指标就是一套丈量体系。我们无时无刻不在举行各种丈量，因此，我们不应拒绝度量指标这一概念。
然而，“度量”这个词另有一层更玄妙的寄义，就好像“假如你不能将其（转换成数字）权衡，你就无法管理它。”我们并不完全认同这一点。我们熟悉的大多数人都是通过照镜子决定是否剃头，少数人大概会在日历上安排时间，但我们还没听说过有人会用尺子量头发的长度来决定是否该剃头。在软件范畴，将事物简化为数字确实有其上风。你可以权衡事物，设定目标，然后定期回顾更新。假如统统按筹划举行，那就很好，你可以自我庆贺并享受一些休闲韶光。假如环境不妙，那么就督促你的团队成员加速工作。假如环境严肃，那就须要他们给出表明并定期更新希望。
仪表板（Dashboards）作为一种工具，资助人们纵然在不相识过程细节的环境下，也能概览并把握全局。但假如度量失衡，就无法到达应有的效果。
度量失衡
最简朴的度量方案就是统计 bug 数目。当发现大量 bug 时，测试职员和测试分析师会受到夸奖；相反，当 bug 数目较少时，则体现开辟职员编写了质量较高的代码，因而也会受到夸奖。项目司理则渴望看到 bug 数目为零或在一个较低水平，以便他们可以或许做生产物发布的决定。
不幸的是，最简朴的方法并不总是最好的，由于它不可制止地会导致失衡的活动。
每次见到这种度量体系（包罗在咨询项目中），我们都会发现它会导致测试职员对每个拼写错误，以致是每个有争议的拼写错误都提交一个 bug。与此同时，开辟职员则会耗费精神去争论此 bug“不是 bug”或“不是我的责任”。管理层大概会施加压力以低沉 bug 数目，于是人们不再将 bug 录入体系。转而使用便利贴转达，大概在长途工作时，通过谈天工具转达信息。
对量化的渴望偶然会偶然中将有用的信息清除在体系之外。
这种过分量化的题目不但发生在测试环节，还存在于交付流程的各个环节中，好比团队的速率、网站用户数目、每周完成的功能数目等。Matthew 曾经与一家公司互助时发现，该公司天天都统计自动化查抄的运行次数。纵然步伐员在不绝添加自动化查抄脚本，司理还是会每个月调解一次测试运行的隔断，确保天天统计的实行次数是增长的。
Matthew 的研究生导师罗杰 · 弗格森（Roger Ferguson）博士曾说过：“有数字总比没有数字好”，一个数字至少给人一个出发点。话虽云云，但让我们思量如许一个场景：昨天体系中有 5 个拼写错误的 bug，而本日登录功能完全瓦解了，根本没有人可以使用测试环境。我们能由于 bug 数目从 5 个淘汰到 1 个就说质量有所提拔吗？固然不能，这个想法谬妄至极。但是，对于那些阔别现实过程、只盯着仪表板的人来说，外貌上看起来好像就是如许的环境。
我们的导师 Cem Kaner 博士，将这个题目称为建构效度（Construct Validity），这是一个在科学范畴有特定寄义的术语。也就是说，简朴地盘算几件事并不公道。比方，我们可以在桌子上数现金（纸币）的张数，但假如每张纸币的面额差别，单纯的数目并不能告诉我们太多信息。假如我们根据纸币的数目来夸奖团队，他们大概会把大额纸币换成小额，营造出生产服从进步的假象。我们在之前的自动化查抄数目的例子中就看到了这一环境。Kaner 博士在 SoftwareEngineering Metrics: What Do They Measure and How Do We Know（链接 6-1）一文中大概对此做了形貌—读完这篇文章后，人们很容易感到沮丧以致克制。在其职业生存后期，Kaner 博士将软件比作股市投资，对于上市公司有一系列的度量指标，但全部指标都存在题目。这些指标反映了公司在某些方面的真实环境，若投资者可以或许综合思量一系列相互制衡的指标并明确它们，将会对公司有一个更全面、更深刻的熟悉。
筛选数据是相识事变希望的一种方式，另一种则是深入到场工作流程。打个比方：老师不须要通太过数来相识门生的环境—老师自己就清晰门生的状态。之以是产生分数，是为了出现给家长、校方和招生办等。这是为了让外界人士能便捷地相识和比力。度量尺度同样起到了如许的作用。随着抽象层级的提拔，从单日细节到团队每两周总结，再到多个团队的每三个月报告，信息在逐级转达中渐渐流失。我们的挑衅在于，以最紧凑的方式提供最不易被误解的信息，最大限度地生存关键内容。
我们要区分查询指标（inquiry metrics）和控制指标（control metrics）。在缺陷巨细和影响相似的环境下，你可以进入需求管理体系并陈诉团队本周发现的20 个 bug。上周也是 20 个，而且修复了 15 个—看起来 bug 数目仍在增长。你以致可以回溯几个月的数据，把这些数字填入电子表格制成图表。然而，当你每周更新图表，并基于它来决定提拔和涨薪时，就已经从查询指标转移到了控制指标。有了控制指标，人们就有了改变活动的动机。这时，我们开始看到关于作甚bug、作甚功能哀求、严肃水平怎样界定的争论。人们大概开始自己发现并修复bug，而不颠末正式渠道陈诉。大概会有人争辩说，标志为 WILL_NOT_FIX（不会修复）的 bug 也应该算作已修复，假如计入它们，图表上的数字就会降落。效果，质量也逐步下滑。
Jerry Nadelman对于bug数目的见解
我们发现 bug 数目会出现周期性变革。当开辟一个新功能时，bug 数目会很高。但随着时间推移，颠末几天 / 几周，随着功能渐渐完成，发现的 bug 数目会渐渐淘汰。假如度量指标很告急，我们就必须查察汗青趋势。对我们来说，新功能开辟最初几周的 bug 数目应该与之前功能开辟最初几周的 bug 数目举行对比，后期的 bug 数目也应是云云对比。假如不如许做，你将看到一个连续的上下颠簸，那么这个度量指标就会失去意义。我们还需将 bug 数目与故事点估值举行对照。更高的故事点数意味着更大的复杂度，预计也会有更多的 bug 出现。对于一个规模较大的故事来说，发现20 个 bug 大概并不算是大题目，但如果一个估计值点数低、理应在一天内完成的小故事中发现了 20 个 bug，那就是一个巨大的告诫信号。
本章的目标是促使你停下来思考一下，什么样的度量筹划才气引导你走向精确的方向。我们完全支持查询指标，但不要止步于此—要验证它们。比方，在列出已往两周内发现的全部 bug 后，获取这些 bug 清单。弄清晰是否告急的 bug得到了修复，还是仅仅修复了容易办理的题目。假如告急的 bug 得到了修复但bug 总数仍在上升，我们怎样表明这对质量的影响？
本章更多的是引导思考而非展示实例。在第 9 章中，我们将讨论可以或许经得起查验的测试度量指标实例。
对度量指标的一个常见渴望用途是推测将来，偶然也被称为推测，这值得一提。
免责声明：如果侵犯了您的权益，请联系站长及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金. |
发表于 