大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
XP与Scrum，只取其一，两者都取，还是全都抛弃？
作者 Amr Elssamadisy 译者 顾全 发布于 2009年11月7日
Scrum还是XP，哪个更好呢？是其中一个比另一个更适用，还是另有其他选择？
Tobias Mayer最近在其博客文章《不要用XP》中写到：
好多人坚持说：Scrum要是没有XP配合就行不通，跟他们反反复复的讨论让我开始有点厌烦了。如果理解了Scrum基础的价值观和原则再应用的话，Scrum是没有问题的。你实施Scrum的环境，决定了你需要应用的实践。教堂里的Scrum和软件业的Scrum会有一套不同的好做法，而他们与法律行业中的Scrum又都不一样。
因为Scrum在软件业中缺乏好的开发实践，XP的鼓吹者很快就对其进行责难。可是考虑到XP实施如此之慢，也可以争辩说（我也会这样干），实际上XP本身要对我们这一行业缺乏好的实践负责。
似乎Tobias所说的是，Scrum足以“拉出”（就精益开发而言）必要的技术实践，而无需使用全部XP实践。XP是个很大的负担，其采用者寥寥即是明证。
Steve Freeman以《就要用XP》来回应Tobias的博文：
作为一个偶尔鼓吹XP的人，我没有“因为Scrum在软件业中缺乏好的开发实践而对其进行责难”，我责难的是软件业。如果我们在行之有效的行业工作，就不会有方法论之争了，因为事物本来就会正常运转。现在这个行业也在乱搞Scrum，只从事它仪式化的部分。而另一方面，责难XP阻碍了好的实践，也够匪夷所思的。
XP是一个规模不大的运动，获得了一些关注。很多开发团队仍然被各种过于谨慎的各种条条框框所约束，有可能会求诸于胡乱省略式的开发，而且敏捷让人们看到避免类似状况的可能。它给了团队一套可靠而起作用的实践。当然XP没能掌管全世界，因为不是人人都适合它，在一定程度上它需要人们集中精力投入，还有技能上的要求，而这对很多团队并不合适。Kent Beck对XP第一版的演示是故意走了极端：其设计是要启发我们这些畏首畏尾的大众，拓展软件开发中可行之事的界限，以重构大家的探讨。
Steve接着说道，XP与当今出现的技艺（craftsmanship）运动颇有渊源：
Tobias写道，好的开发实践当时传播缓慢，但我会争辩说，没有XP的话，我们到现在还等着呢。测试驱动开发（TDD）仍然没有被广泛接受，而且在Kent写书之前，甚至最初的C3团队也没有全部采纳它。重构（Refactoring）有一小批学院派的追随者，但如果没有TDD实践的补充，它也不是那么安全。我怀疑大多数团队仍然禁止改变代码，除非是为了改动一项功能特性。结对编程仍然很难推广，这又跟TDD相关，因为它在TDD的上下文中要成功得多。我见多了那些Scrum团队，他们没有找到一套有条理、游系统的技术实践。要断言他们只是需要改善Scrum的实施，就不得不回答诸如Scrum如何被采行、自组织的局限等等问题。
上述和其他很多对话，促使Yves Hanoulle提出：也许敏捷社区正在经历“初起炉灶—暴风骤雨—照本宣科—大放光彩”循环的第二阶段：
看起来，我们的大量讨论都是在质疑我们所在的行业。
我感觉这一次的规模前所未有。也许我太年轻了；也许我现在更为投入，或是更有对错主见了；也许是这个总是紧密联系、充满推客和博客的世界让这些讨论如此地公开化。
这让我总是想起团队生命周期中的“暴风骤雨”阶段，或是Satir模型中的混沌期。所以从一个教练的角度看，这些讨论及其未来进展，都十分有趣。
在这些讨论中，很明显没有领导者。或者让我换种说法，没有人人都认可的领导者。
所以，我们社区内的这次争执，可能就是我们逐渐成熟的一个标志。本文作者从自己的经历中发现，任何事情在一定环境中都是合理的。有些成功团队从Scrum开始，另一些从XP开始，还有很多人使用这两种方式却都失败了。我们在敏捷社区里擅长的是，从试验中学习，同时从不忘记：所有这些实践和流程都只是通向结果的方法而已。
查看英文原文：XP or Scrum, Either, Both, or Neither?
Scrum怎么做？
发表人
杨 光
发表于
学习、理解、突破
发表人
Ye Lin
发表于
了解敏捷背后的价值观最重要
发表人
鲍 央舟
发表于
Re: 了解敏捷背后的价值观最重要
发表人
jiang rosen
发表于
如果你理解XP，那么你就会需要XP。
发表人
Lea Jean
发表于
5 条回复
关注此讨论 回复