BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Vikas Hazrati 关注 0 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2008年10月4日. 估计阅读时间: 3 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

得看sprint中间的工作能否不受干扰 by 徐 毅

"Scrum的工作节奏是很紧张的"这句话很关键啊,如果团队成员总是被干扰,很难进入一种什么flow的状态,那么sustainable恐怕就很难企及。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT