对超高生产力的度量是浪费时间吗？

作者 Vikas Hazrati 译者 郑柯 发布于 2009年6月3日

领域

过程 & 实践

主题

团队工作 ,

企业级敏捷 ,

敏捷技术 ,

敏捷

标签

最佳实践

在一个关于超高生产力与电击疗法的演讲中，Jeff Sutherland提到：超高生产力（Hyper-Productivity）至少应该达到丰田的绩效水准，也就是四倍于行业平均水平。他认为：正确进行敏捷开发的团队，应该可以在3个为期两周的迭代中体现出300%的进步。最近在Scrum Development group的讨论中，成员们争论有无可能准确度量多个sprint体现出来的生产力，以及这样做是否有益，还谈到是否有可能看出团队已经到达超高生产力状态。

Adam Sroka认为要想度量多个sprint体现出来的生产力或工作效率很困难，甚至不可能。很多时候，团队的生产力建立在故事点数基础之上，而这个数字在各个sprint之间是不断变化的。他觉得：

故事点数未必可以比较，即使它们看起来是随时间推移不断稳定下来的（比如在迭代1中的5个故事点数与迭代5中的5个故事点数就没有可比性。不过，迭代5中的5个故事点数与迭代6中的5个故事点数就比较接近）。因此，一个敏捷项目在过程中体现出来的生产力提升类似于没有实际证据的轶事 。我们见过这样的状况，也知道它确实存在，但我们找不到确定的方式来度量它。 。

Tobias Mayer同意Adam的意见，他也指出：

对“超高生产力”的度量纯属浪费时间——而且就跟卖“大力丸”差不多。对故事的估算不是一成不变的，团队交付软件的能力会随着时间推移提升，也会改变他们估算故事的结果。正如Adam指出的，对于同等复杂的故事，我们估算的准确度会越来越高。
我认为这样的“量化”会给Scrum造成伤害，正如最初的帖子指出的，如果你将底线设得足够低，所有的事情看起来像是达到了“超高生产力”。要是团队在第一个sprint中什么都没有完成呢？在此后的第二个sprint中完成的1个故事点数就像是增长了无数倍啊。真是荒谬透顶！

Joseph Little指出：尽管很多关于“超高生产力”的谈话都是白费口水，“超高生产力”本身还是有意义的。他建议：团队应该知道自己的速度，这样才能不断改进。他也同意：速度可能会随着迭代的推进而改变，所以在不同sprint中，大小相同的故事可能分配的点数不同。要解决这个问题，应该计算3个sprint下来的平均速度，而不是就拿一个sprint中的速度来说事儿。接下来应该要做的，就是让团队的开发速度翻番了，这就需要对开发流程进行大大小小的调整，移除遇到的障碍，多多益善。Joseph认为：

让我说得更明白点儿：软件开发这件事儿现在做得真不怎么样，要想让团队的工作效率翻番没那么困难。

Roy Morien补充道：要想精确度量个人或团队的生产力，难上加难。因此，团队应该把注意力放在交付有效的、可工作的软件之上，力图改善上个sprint中做事的方法，而不是去考虑如何度量生产力。

与他的观点相同，Adam Sroka指出：团队不应该浪费时间度量生产力、分析团队是否到达“超高生产力”状态，而是应该将焦点放在：

1. 我们是不是正在交付有价值的、可工作的软件？是不是持续不断地、每个迭代都是这样？
2. 我们现在是不是把精力都放在可持续的工作方式之上？我们能一直按照这个步调交付软件么？我们还能改进么？
3. 我们有没有把精力浪费在对于直接交付价值没有贡献的事情上？我们应该怎么消除这些浪费？

综上，通过这些讨论，大部分人都认为：在敏捷开发中，相对于比较不同sprint之间的生产力数字以查看是否达到“超高生产力”状况，还有更重要的事情要做。而且，由于没有收集不同sprint之间生产力数字的标准计算方法，去比较这些数字也就不怎么靠谱了。

查看英文原文：Is Measuring Hyper-Productivity a Waste of Time?

译者 郑柯 InfoQ中文站总编。做过开发，当过PM，干过销售，搞过市场，最终还是回到媒体。实用的理想主义者，相信：每天改变一点点，这个世界会更好。

1. 返回顶部

   关键问题在于如何将故事点标准化

   发表人 Wang chris

   如果采用FP的方式来分析故事点中隐含的工作量就可以进行比较了

   回复

• 更早的 >