大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
可持续的开发速度意味着每周工作40小时吗？
作者 Vikas Hazrati 译者 郑柯 发布于 2008年5月11日
对于希望长久使用敏捷的团队来说，“以可持续的开发速度前进”是一个广为人知的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?
译者 郑柯 InfoQ中文站总编。做过开发，当过PM，干过销售，搞过市场，最终还是回到媒体。实用的理想主义者，相信：每天改变一点点，这个世界会更好。
把握這個尺度很重要
发表人
sasumi sobizz
发表于
1 条回复
关注此讨论 回复