“可持续的开发步调”实践认为团队应该努力工作，开发的步调要可以持续，并且能够一直维持下去。该实践还认为，如果团队工作过度，也许开发速度要快过可持续的速度，但是几周之后，团队的开发速度就会降低，而且大家会渐渐丧失工作热情。 Jeff Sutherland 最近给 OpenView Venture Partners 风险投资集团上了一次指导课程，对方展示给他的量化数据支持了他的观点。 Clinton Keith 在类似的研究中，也指出了长时间工作对于团队速度的影响。
Jeff 看到的是“麦克斯韦尔曲线”，其中描绘出如果团队投入超过 40 小时的工作时间，那么团队的开发速度就会下降。根据 OpenView Venture Partners 的说法，这些风投资本家们经常要人们每周工作超过 40 小时，希望开发效率可以翻倍；然而，使用了 Scrum 之后，情况有所不同。他们提到：
现在用了 Scrum 后，情况有所不同。为了开发效率翻番，我们反而要减少工作时间，当然不能超过每周 40 小时。Scrum 的工作节奏是很紧张的，在这种节奏下，你不可能再去加班而不降低工作效率。
Clinton Keith 在类似的研究中，也指出了长时间工作对于团队开发速度的影响。他提到，如果要求团队每周工作60 个小时，而不是通常的40 小时，头几周过后，团队的开发速度就会逐渐降低。不过，在加班的头几周，开发速度是要超过40 小时每周的；慢慢地，速度开始降低，直到最后，60 小时每周的开发速度反而不如40 小时每周。
其他类似的研究说明，如果团队的步调不稳定，工作效率最后一定会降低。
另一方面，Clinton 也着重提到人们对“可持续的步调”的阐述经常是有缺陷的。有些团队如果每周的工作量远远超过40 个小时，他们就会无法完全达成sprint 的目标。他认为，可持续的步调不应作为团队无法达成sprint 目标的理由。许下承诺之后，团队应该努力实现诺言，在sprint 过程中，还要经常注意寻找可以改进的细微之处，这可以让团队更有效利用时间。每个迭代作出1% 的改善，长此以往积累下来，将会产生极为显著的正面影响。
Clinton 提到，偶尔以超出可持续步调的速度工作并无大碍，然而这并不应成为日常实践。
如果是重大版本发布之前的最后一个 sprint，我们经常可以看到团队连续数周加班到深夜，而且周末也不休息。如果他们发现自己必须经常这么做，他们就得改善自己的估算了。
因此，只要小心使用，而不是随意滥用，“可持续的步调”的确可以提升团队的工作效率。
查看英文原文： Venture Capital Group Acknowledges Overtime Detrimental to Scrum
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论 1 条评论