大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
应该奖励最好的Scrum团队吗？
作者 Mark Levison 译者 石永超 发布于 2010年9月2日
Rajesh Velliyatt想知道，建立一个“本季度最佳Scrum团队”的管理理念是好是坏。他担心奖励制度可能存在以下缺点：
- 制度是主观的（像任何其他类似的系统）
- 如果所有团队都做得很好（或者都很差），选择其中之一会降低其他团队的表现
- 可能对跨团队协作不利
- 证实“我们是最好的团队”开销太大（数据收集）（对Scrum master而言？）
- 对于不同的产品团队，没有可比性
除了Rajesh的观点，这份报告还认为这种竞争可能不是良性的。同时，他指出《Drive》的作者Dan Pink已经证明，尽管奖励制度对机械性任务有作用，但对于像软件开发这样的创造性活动没有任何帮助。Pink解释说，对于创造性任务，内在因素才是提高生产力的动力，而不是外部激励。Michael James把Dan Ariely的实验结果作为参考：“通过对9种任务的3项实验进行调查，我们发现，其中有8种任务的实验结果表明，更高的外部激励会导致更糟糕的表现。事实上，我们对这种效应的稳定性感到惊讶。”——Dan Ariely，Uri Gneezy, George Loewenstein和Nina Mazar(2005)，《大赌注和大误区》，5-011号工作文件，波士顿联邦储备银行。
Steve Janvrin询问他的Scrum团队是怎么想的：“假如有多个Scrum团队，而你们没有赢得奖励，你们会有何感受？”他们的回答是：“我们会对他们很恼火，不想跟他们合作。”
Paul Tiseo认为，不是所有团队都会去争取最佳团队奖的。他指出，单一奖励就像是在鸡蛋里挑骨头，挑出哪个团队做得最好。出于这种实际情况，Rajesh提出了一些办法：
1. 团队的速率趋势（假设：团队的故事点估算是一致的，可能会受到奖励机制的影响？）
2. Sprint的执行效果（燃尽图、提出的障碍，以及团队如何处理障碍）
3. 坚持完成标准的情况（数据可以从PO那里获取）
4. 团队对Scrum过程的投入/态度情况（数据可以从Scrum Master那里获得）
这份报告指出，所有这些方法，尤其是速率（更多详情，请参见《速率在敏捷项目中的误用》），都是可以耍花招的。一般而言，任何方法都会导致大家在工作中耍花招，因此我们必须考虑如果团队过多地做出这种事情会引发什么后果？
Jay Conne提出了市场驱动的替代方案：“让业务部门对团队是否想做他们的项目进行投标。这可以一举覆盖到许多方面。作为平衡因素，让团队去竞标项目。这将赢得互信。”
Bachan Anand具有在团队间进行“健康”竞争的经验。他发现，在短期内这会让团队变得非常不健康，团队开始孤立地工作，不与相同产品的其他团队一起协作。但Bachan的组织发现，有多个团队参与的辅导和指导活动会有助于提高协作状况。
查看英文原文：Should the Best Scrum Team Be Rewarded
译者 石永超 是Irdeto BSS软件工程师，CSM，敏捷爱好者，《User Stories Applied中文版》译者之一。
应该明确“本季度最佳Scrum团队”的目的到底是什么？
发表人
高 翌翔
发表于
Re: 应该明确“本季度最佳Scrum团队”的目的到底是什么？
发表人
yu fu
发表于
-
如果脱离做事的目的或意图，而凭空地讨论做一件事的好与坏，那么这么做只是“消遣”罢了！
当然评选“本季度最佳Scrum团队”的目的很明显，那就是通过奖励机制，提高团队的生产力，进而为企业创造更多的价值！
软件开发经常与建筑工程相比较（尽管这种比较是错误的），在建筑工地上经常可以见到写有“青年突击队”字样的旗帜或横幅，这种评比在建筑领域已经持续了五六十年（仅指国内，对国外的情况并不了解），而且并未出现 Rajesh Velliyatt 在文章开篇所担忧的那些问题。
为什么会这样？
后面 Dan Pink 给出了部分答案，即“奖励制度对机械性任务有作用”，我认为 Pink 的观点不准确，继续“青年突击队”的话题，尽管施工人员有图纸可依，但是“青年突击队”往往会创造一些高效的施工方法，又快又好地完成工程。可见，建筑施工并不仅仅是简单的机械性任务，同样需要施工人员的创造性活动参与其中。因此 Pink 的观点有失偏颇。
从上面的讨论中不难看出，“快”和“好”是“青年突击队”的两大特点：“快”即省时，时间就是金钱，无须多言；“好”即高质量的工程，在建筑中通过各种检测仪器及指标，可以判定工程质量的优劣，而评判标准几乎都是业界公认的客观的硬性指标！
暂且把“快”和“好”机械地平移到“本季度最佳Scrum团队”的评比中，“快”还是比较容易判定，但“好”就不那么容易辨别了！对比建筑工程就一目了然了，对于建筑工程优劣的评判有一套业界公认的客观的硬性指标与方法。但是对于“代码”质量的评判恰恰缺乏类似的指标与方法，尽管现在有一些，但并不完善。这将直接导致了“本季度最佳Scrum团队”评比的失败。
结论就是，在没有出现能被各个团队广泛认可的代码质量评判指标与方法出现以前，“本季度最佳Scrum团队”的结果将难以服众，由此将引发一系列的连锁反应，后果难以预料！
个人观点：要达到提高团队生产力的目的，如果团队间比较行不通，不妨试试团队自省的方式，即当每个团队完成项目后，分别对各自的开发过程进行经验总结，并将值得推广的经验公布出来，由其他团队进行投票及辩论，经过一段时间以后，将辩论整理成册，根据贡献程度，对各个团队给予相应的奖励，从而激发各个团队间的良性竞争！
团队自省方式中肯定存在许多问题和不足，有待在实践过程中来解决！ -
这个奖励的初衷是好的，可是现实中因为缺乏有效的评估标准，往往结局是发了还不如不发。
2 条回复
关注此讨论 回复