此前， Scott Ambler 发布了一篇文章，其中谈到如何利用加速度衡量敏捷团队的工作效率。最近，他又发布了一个帖子，回答了一些关于敏捷工作效率和加速度最常被问到的问题，专门谈到了如何衡量正在加速的团队所能节省下来的资金数目。
Ambler 的观点认为：
如果你能够很方便地衡量工作效率，那就能很快找出：在你的工作所在情形中，哪些是有效的，哪些不能发挥作用，并做出响应调整。
他首先谈到：大多数敏捷团队都用速度衡量团队的表现，然后就会提出（并回答）下面的问题：
用速度衡量工作效率可能么？
……
你没有办法比较两个团队的速度，因为他们使用不同的度量单位。团队 A 和团队 B 都使用点数衡量，可是都是彼此自己的点数，所以无法直接比较。
实际上他提出了另外的解决方案：
比较速度，实际上不妨比较一下两个团队的加速度。
……
随着时间推移，团队 A 的速度在不断增长，与此同时，团队 B 的速度似乎在走下坡路。一切条件都是对等的，因此，你可以假定团队 A 的工作效率在提升，而团队 B 的工作效率在下降。当然，仅靠数字表象去管理并不明智，我会对各自的工作状况做假设，而是去跟两个团队的成员谈话。这样一来，我可能发现：团队 A 已经采纳了以质量为导向的实践，比如持续集成和静态代码分析，而团队 B 没有。也就是说我应该帮助团队 B 采纳这些实践，并希望可以提升他们的工作效率。
为了计算团队的加速度，Ambler 建议使用下面的公式：
（迭代速度 X1 - 迭代速度 x2）/ 迭代速度 x2 = 团队加速度
其中迭代 x1 在时间上要早于迭代 x2。在这个例子中，Ambler 使用了两个团队，一个团队加速度为正，一个团队的加速度为负。
……团队 A 从迭代 1 到迭代 6 的加速度是（20-17）/17=0.176，而团队 B 的加速度是（45-51）/51=-0.118
Ambler 指出了这种方法的的一些优势和劣势：
优势：
- 易于计算。
- 成本低廉。
- 不易于敷衍了事。
- 很容易自动化。
- 为更有效的管理提供了机会。
- 要是调整团队大小，也很容易操作。
- 易于从金钱的角度衡量该方法。
劣势：
- 对于衡量工作效率来说，并不直接。
- 必须要测量感兴趣的指标。
- 管理可能很灵活。
- 现有的度量的方式可能被人质疑。
- 用词听起来过于科学化。
在他的 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 $
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论