如何评估代码质量：反馈回路、文化、代码质量、技术债务、部署管道

质量实践评估模型（QPAM）可将团队的表现行为划分为四个维度：起步、统一、实践、创新。该模型分析了社会与技术质量相关问题，如反馈回路、文化、代码质量、技术债务、部署管道等。

在2022年敏捷测试日中，Janet Gregory 谈起过使用 QPAM 模型进行质量评估。

质量实践评估模型有十个质量方面，具体可参见用质量实践评估模型协助团队交付一文中的描述。

在每个质量方面中，团队所表现出的行为都可被归为四个维度：起步、统一、实践和创新。但 Gregory 同样也提到，团队的所有质量方面不一定都归属于同一维度。处于起步维度的团队很少会有质量方面的实践，且经常缺乏结构性。Gregory 解释道：

部署低质量代码到生产环境中会导致累积的缺陷不断增加。团队成员或许进度各异，有些所面临的环境相比别人会更加混乱，但几乎所有人都希望能有所改进。

在统一的维度中，组织中或多或少都应用了一些敏捷方法，形成了功能性各异的交付团队：

团队会遵照一定形式，比如每日站会、实时更新的产品 Backlog、块状时间迭代工作。团队会将工作划分，并在迭代结束之前完成计划工作量，会学会与跨职能团队协作。

在实践维度，团队成员感觉良好，他们能自然地应用所学的实践，并持续为客户提供价值。

团队拥有快速且有效的反馈回路以应对突发情况。当前的工作重点是防治代码缺陷，故而很少有缺陷存在。在先前维度所发现的缺陷会立即得到修复，或将修复在下一次迭代中列为优先事项。在周期早期就引入测试行为，让产品在初期就能拥有质量实践，并借由客户反馈改良产品。

创新的团队拥有更高的绩效，在更短的周期内不断提供客户和商业价值。

团队了解市场并在已知方面拥有对高质量的定义。他们会在适合的区间试水，调整前进方向。不断地自学和自律让团队努力学习并进步。因为心理上很高的安全性，失败会被看作是学习的机会。在以客户价值为基础的前提上，功能的开发重点在深思熟虑后放在了流程上。团队通过生产使用中的持续反馈，了解并监控变化的影响。质量在维度的最初就已经内在存在了。

困难在于整合从不同来源中收集的所有信息，并找出其中差异。Gregory 解释道：

我常用一张电子表格记录不同的质量方面及相关的做法。这样我能跟轻松地对比维度之间的调查发现。

模型的好坏取决于使用者，Gregory 也提到建导是一种技能。团队在自我评估时，自我打分常常会高于外界分数，但 Gregory 认为，这对团队而言不一定是个糟糕的尝试。

Gregory 与 Selena Delesie 在二人合著的《用 QPAM 评估敏捷质量实践》一书中对质量实践评估模型有所描述，此书被列在了 Gregory 的出版作品页面之中。

InfoQ 就评估质量问题采访了Janet Gregory。

InfoQ：你对评估建导者有什么建议吗？

Janet Gregory：获取信息的方式有很多，我应用尽用：将过程回顾、访谈，旁听会议或研讨会相结合，还有研究用户故事和测试等方面。在我们的书中，我们列出了建导者可以采用的开放式问题。一名建导者需要通过仔细地倾听和观察，才能提取出信息。通常来说，非言语的表达与说出的话同样重要。我们正在写一本续作，以建导者指南的形式，为评估提供帮助。出版时间未定，不过很可能会在 2023 年上半年面世。

InfoQ：要如何体现评估的结果呢？

Gregory：根据背景不同，建导者的分享内容也会有所不同，但重要的是信息的匿名性。如果你是一名内部建导者，你可以收集所有的观察结果，分享发现，方便团队找到需要改进的方向。如果你和我一样是名外部建导者，那么你也可以分享观察结果，并提出自己的意见和建议。

原文链接：

How to Assess Software Quality

相关阅读：

POC、Scrum 和低质量软件的解决方案

开发高质量的软件要付出什么样的代价？