对于希望长久使用敏捷的团队来说，“以可持续的开发速度前进”是一个广为人知的 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力图总结陈词，他说：维持可持续开发速度的重要因素，不是工作小时数，而是有创意的思考与以更少时间完成人物。他提到，可持续的开发速度需要很多因素，包括工作文化、技术欠账、激励因素等等。工作时间也许会产生一些影响，但这并不是最佳的切入点。
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论