此前，Scott Ambler发布了一篇文章，其中谈到如何利用加速度衡量敏捷团队的工作效率，
用美元衡量敏捷的工作效率
。最近，他又发布了一个帖子，回答了一些关于敏捷工作效率和加速度最常被问到的问题，专门谈到了如何衡量正在加速的团队所能节省下来的资金数目。Ambler的观点认为：
如果你能够很方便地衡量工作效率，那就能很快找出：在你的工作所在情形中，哪些是有效的，哪些不能发挥作用，并做出响应调整。他首先谈到：大多数敏捷团队都用速度衡量团队的表现，然后就会提出（并回答）下面的问题：
用速度衡量工作效率可能么？……
你没有办法比较两个团队的速度，因为他们使用不同的度量单位。团队A和团队B都使用点数衡量，可是都是彼此自己的点数，所以无法直接比较。
实际上他提出了另外的解决方案：
比较速度，实际上不妨比较一下两个团队的加速度。……
随着时间推移，团队A的速度在不断增长，与此同时，团队B的速度似乎在走下坡路。一切条件都是对等的，因此，你可以假定团队A的工作效率在提升，而团队B的工作效率在下降。当然，仅靠数字表象去管理并不明智，我会对各自的工作状况做假设，而是去跟两个团队的成员谈话。这样一来，我可能发现：团队A已经采纳了以质量为导向的实践，比如持续集成和静态代码分析，而团队B没有。也就是说我应该帮助团队B采纳这些实践，并希望可以提升他们的工作效率。
为了计算团队的加速度，Ambler建议使用下面的公式：
（迭代速度X1 - 迭代速度x2）/迭代速度x2 = 团队加速度其中迭代x1在时间上要早于迭代x2，
管理资料
《用美元衡量敏捷的工作效率》(https://www.unjs.com)。在这个例子中，Ambler使用了两个团队，一个团队加速度为正，一个团队的加速度为负。……团队A从迭代1到迭代6的加速度是（20-17）/17=0.176，而团队B的加速度是（45-51）/51=-0.118Ambler指出了这种方法的的一些优势和劣势：
优势：
易于计算。
成本低廉。
不易于敷衍了事。
很容易自动化。
为更有效的管理提供了机会。
要是调整团队大小，也很容易操作。
易于从金钱的角度衡量该方法。
劣势：
对于衡量工作效率来说，并不直接。
必须要测量感兴趣的指标。
管理可能很灵活。
现有的度量的方式可能被人质疑。
用词听起来过于科学化。
在他的FAQ中，他深入说明了如何通过金钱计算加速度：
……假定你的加速度是0.007（0.7%），团队中有五个人，每年每个人承担的成本为15万美元，迭代的时间长度为2周。 ……所以，每个迭代每个人负担的成本是150,000/26=5770美元。这个团队每个迭代的工作效率提升就是5770*5*0.007=202美元。如果加速度保持在0.7%，一年下来整体的工作效率提升就是（1.007）^26（假定团队每年工作52周）,也就是1.198或19.8%。这会节省148,500美元。数字26是一年中的迭代数目（52周/2周）。
你愿意使用这种方法来计算团队的加速度么？
查看英文原文：Measure Agile Productivity in $
本文出自：http://www.infoq.com/cn/news/2009/01/Measure-Agile-Productivity