风险投资家已认识到加班对Scrum的损害

“可持续的开发步调”实践认为团队应该努力工作，开发的步调要可以持续，并且能够一直维持下去。该实践还认为，如果团队工作过度，也许开发速度要快过可持续的速度，但是几周之后，团队的开发速度就会降低，而且大家会渐渐丧失工作热情。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