开发一款高质量的软件产品属于软件工程范畴。变幻莫测的用户需求和苛刻的项目计划表很容易导致预算超支或者交付延迟。所以，项目做得越大，其功能也越复杂。正因为存在这么多因素的影响，项目质量很容易失去把控。
没有哪个工程可以离开精确的计量，而量化必须要借助一些度量方法才能实现。
因此，开发者需要一些软件度量方法来实现产品透明而又高质量的交付。因为当你在衡量你所说的话时，你需要用数字来体现你的失败或成功。你需要有一个计算公式来显示你在哪里薄弱，在哪里做得好。用Bob Parsons的话来说，“量化和监督能够促使进步”。
那么，现在问题来了，应该选用哪些软件度量方法呢？
一种选择是使用一套预先制定好的度量方法。另一种选择是首先定义好产品需求，并与相关人员进行讨论，然后再确定所需的度量方法。
说得浅显易懂一些，打个比方，你在为某个冒险运动打包装备，你会带着降落伞去划皮划艇吗？
肯定不会。
相反，你会首先决定是参加哪种冒险运动，做一些调查，并根据需要打包你的冒险装备。所以，如果你要去玩滑翔伞，带好头盔和束带吧。
你应该把船桨留在家里等着下次玩的时候再用。
因此，在产品开发周期中，不同的迭代周期要使用合适的度量方法，这一点很重要。作为一家曾开发了令人心动的产品的软件开发公司，Quovantis公司遵循的软件度量方法包括以下这些。
1. 团队速度点
简单来说，团队速度衡量的是你的团队在某个迭代周期内向着目标前进的平均速度。一个典型的迭代周期大概为2-4周，团队速度点的计算被证明是评估团队效率最有效的度量方法。
如果要计算你的团队的速度，你应该汇总当前迭代周期内已经完成的故事点（Story Points）。为确定团队的速度，建议取三个迭代周期的平均值。
为什么要用这个度量方法呢？因为它是行业标准，它决定了软件功能开发行进的步调。简单来说，它时刻跟踪着Scrum团队的速度。这个度量方法有助于判断团队是否可以承担更多的工作，或者团队已经超负荷，需要减轻工作量。
2. 迭代周期燃尽图
迭代周期燃尽图是项目健康度可视化的最有效的跟踪度量方法。它有助于查看有多少工作尚未开始，团队是否需要加快或放慢速度。你还可以预测迭代周期的预期完成日期。一旦项目进展偏移预期的燃尽目标，Scrum教练就会收到一面小红旗，以促使他采取适当的行动。
例如，如果燃尽曲线在迭代周期中始终位于预测曲线之上，这是对现有观察视角的一个补充。在这个时候，团队应先完成“团队目标”，然后再从功能特性清单中领取新的任务。
为什么要用这个度量方法呢？ 因为燃尽图显示了迭代周期的工作进度。它显示了团队每天完成的工作总和是否能让迭代周期顺利地完成。
3. 发布燃起图
产品负责人（Product owner，简称PO）首先需要与其他相关人员进行讨论以评估应该向市场上推出哪些功能特性。发布燃起图能够帮助产品负责人根据工作进展情况确定要推出的产品功能特性的优先级。
如果发布日期是固定的，但是项目一开始时又额外增加了新功能，那么为了保证实际发布时间不变，就得砍掉低优先级的功能，或者试着采取合适的手段来提高工作效率，在这种情况下，这种度量方法就显得非常重要了。
发布燃起图显示了每个迭代周期是否正在向着项目逐步完成的方向发展。此外，发布燃起图还提供了预计完成项目的日期。
4. 预估成本和实际成本
通常，项目开始时的预估成本会与项目结束后的实际成本之间存在差距。这个度量方法能衡量哪些偏差可能导致成本上的差异。
虽然项目成本一般都会比预期的高，但这一指标可以帮助你了解成本超支的可能原因，无论是设计错误还是产品开发范围发生变化。
为什么要用这个度量方法呢？因为它帮助我们了解我们预估成本是多少，实际产生的成本是多少，这有助于我们修正原来的计划。
5. 每个迭代周期的主要bug的数量
这个数量体现了产品的整体质量。在你正在进行的敏捷项目中，在任何时候提前关注项目中存在的未解决的主要缺陷的数量变得越来越重要。
怎样才能让缺陷数量保持在可接受的范围之内呢？减少上报的缺陷数量。
那怎样才能减少缺陷数量呢？不要上报啊！
当然，这只是个玩笑。
更好的解决方法是：在规划迭代周期时，高瞻远瞩一些，在确定迭代周期功能特性列表前先明确可接受的标准。
修复重要缺陷的优先级要高于实现一个新的功能。因为在你解决完问题之前，你是不能选择去实现新功能的。
同时，在产品发布后要密切关注上报的bug的数量。如果你没有积极主动地重构并改进代码质量，这个度量的结果可能会不太好看。这能帮助你在测试过程中找到出现差距的主要原因，让你及时采取改进措施。
为什么要用这个度量方法呢？ 如果从整体来看，随着时间的推移，这个比率可以说明产品质量是否得到了改善。我会说，这比选择一个新的故事点（Story Points）更重要。
