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