Tapestry for Nonbelievers
I. Drobiazko和R. Zubairov合作撰写了一篇文章，详细介绍Apache Tapestry 版本5——一个面向组件web框架。文章向读者展示了创建组件方法，并谈到了Tapestry中的IoC以及Ajax的相关特性。
- Java,
新闻
可持续的开发速度意味着每周工作40小时吗？
作者 Vikas Hazrati译者 郑柯 发布于 2008年5月11日 下午9时29分
对于希望长久使用敏捷的团队来说，“以可持续的开发速度前进”是一个广为人知的XP实践。该实践建议团队应该努力工作，但是要以可持续的、能够维持下去的开发速度。它可以帮助人们保持新鲜感，这样就能更有创造力。
然而，在可持续的开发速度与每周工作的小时数之间，是否存在某些联系呢？
Henrik Jernevad在他的博客试图解释可持续的开发速度与每周工作的小时数之间可能存在的联系。Henrik认为，每个程序员基于其才能都有个“最大生产力值”。还存在一个所谓的“当前工作能力”，表示在不降低质量的情况下能够完成的最大工作量。“可持续的开发速度”必须依托于此二者的值。他提出如果可以将每周工作的小时数提升至比40更高的数值，那结果可能会让人大吃一惊。采取貌似安全的40小时工作制听起来像是浪费。
如果我们可以把开发速度提升，比如每周45而不是40个小时，那么在一年的时间里，我们就可以得到多于一个月的额外开发时间了！特别是对于像我目前工作的创业公司来说，每周只工作40个小时过于奢侈了。
那么额外交付一个月所能完成的业务价值是否值得再花费一个月的努力呢？
讨论在Scrum Development组上继续，人们对此理念展开辩论。很多成员提出，增加每周工作小时数不会线性提升生产效率。其他人补充认为，工作小时数并不等同于业务价值。当到达某个临界点后，团队会变得更具破坏性而不是更有生产力。Laurent Bossavit在讨论中这样说 ：要想在每个迭代中都产生同样的业务价值，那工作小时数肯定是会有很大差异的。
直觉告诉我，对于一个有可持续开发速度和良好流程的团队，如果去看它“创建业务价值”的数值，可以发现各个迭代之间差异很大。如果将这些数字以图形表示，你会得到一个幂函数曲线。你会看到：创建同等数值的业务价值，所需要的“开发小时数”差异巨大。
在IGDA上一篇类似的文章总结出了类似的发现：
在保持每周五天共约40小时工作时间的情况下，工人可以维持生产率。工作更长时间，生产率开始下降。在四天和两个月之间某个时间点上，从加班工作中得到的收益会被小时生产率下降所抵消。在某些极端情况下（当工人无法保证每晚至少7到8小时睡眠的状况下，一到两天之内），效率会直线下降。
Henrik试图用Google和Microsoft的例子来证明应每周工作多于40小时的观点。他说：
根据《财富》杂志，Google已经连续两年被评为“工作者最爱公司”！而且他们当然不会将自己每周的工作时间限制在40个小时。
Dan Rawsthorne提出“可持续的开发速度”不仅仅是由工作小时数决定的，它还与承诺和技术欠账相关。如果团队在工作时不会欠技术账，那他们就可以以固定的开发速度前进，而不必去考虑工作了多少个小时。George Dinwiddie进一步补充道，应该在回顾时与团队讨论可持续的开发速度。他引用了Alistair Cockburn的观点：应该忽略可持续的开发速度与工作小时数之间的关系。
以我的经验来看，在软件开发领域中，要想完成工作，增加工作时间是最没有成效的一种方式。就像H.L. Mencken所说的，这种选择是“简单、明确而且错误”的。Alistair Cockburn已经明确指出，人是一种非线性系统。期望在输入（更多工作时间）和输出（更快完成任务）之间有线性关系是错误的。
Joseph Little力图总结陈词，他说：维持可持续开发速度的重要因素，不是工作小时数，而是有创意的思考与以更少时间完成人物。他提到，可持续的开发速度需要很多因素，包括工作文化、技术欠账、激励因素等等。工作时间也许会产生一些影响，但这并不是最佳的切入点。
查看英文原文：Does Sustainable Pace mean a 40 hour week?
把握這個尺度很重要
发表人
sobizz sasumi
发表于
2008年5月13日 下午8时45分
1 条回复
回复