在一个关于超高生产力与电击疗法的演讲中， 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 指出：团队不应该浪费时间度量生产力、分析团队是否到达“超高生产力”状态，而是应该将焦点放在：
- 我们是不是正在交付有价值的、可工作的软件？是不是持续不断地、每个迭代都是这样？
- 我们现在是不是把精力都放在可持续的工作方式之上？我们能一直按照这个步调交付软件么？我们还能改进么？
- 我们有没有把精力浪费在对于直接交付价值没有贡献的事情上？我们应该怎么消除这些浪费？
综上，通过这些讨论，大部分人都认为：在敏捷开发中，相对于比较不同 sprint 之间的生产力数字以查看是否达到“超高生产力”状况，还有更重要的事情要做。而且，由于没有收集不同 sprint 之间生产力数字的标准计算方法，去比较这些数字也就不怎么靠谱了。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论