大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
技术访谈
该内容已经被标记书签！
标记书签错误，请重试！
Rachel Davies谈Generic Agile
受访人 Rachel Davies 采访人 Deborah Hartmann Preuss 发布于 2009年7月10日 长度 00:15:54
我在指导团队采用我称为Generic Agile的方式进行开发。许多我共事过的团队对Scrum或者XP感兴趣，而我试图在工作中拓展他们的眼界，让他们开始思考真正要解决的问题是什么，这个组织真正要做的事情是什么，以及采用的软件开发过程，我要让他们不再仅仅是盲从书本上的敏捷方法。
我并不是想发明Generic Agile这个词，通常我会根据情况采纳一些Scrum、XP或者DSDM的实践，但我可能会在实践中混合运用不同的方法。例如，很多XP团队在回顾过程中使用Scrum的burn-down charts，Scrum团队也常使用用户故事来描述product backlog和velocity中的条目——类似的方法混用的情况其实很常见。在我看来，试图像宇宙大爆炸一样，为了一个目标实施所有的事情并不能带来最好的效果。你希望人们在解决最重要的问题时，将尝试的步子放慢，通过反馈，通过观察他们正在做和将要进行的事情，逐步引入实践。允许团队探索和加入新鲜事物，并给出这样的建议：“我听说过另外一栋大厦的团队使用了索引卡片，我们可以用吗？”。不要说：“你们必须使用索引卡片，因为书上是这样写的”。要让大家勇于尝试，读一些敏捷方法以外的书，在用户组中结交朋友，不要老是讨论如何变得更敏捷，而要关注于我们目前遇到的问题是什么，应该如何解决它们，除了现在的方法之外还可以寻找和尝试哪些方法，我们要注意哪些东西，尝试些什么。我们可以在团队中进行一个小的尝试，给出评价并判断它是否可行。
我希望对于所有的敏捷实践来说，它们都是开放的、可用的，以及可以考虑将它们结合在一起的。唯一强制的是，敏捷的理念是频繁交付有价值的软件，一切都要以客户合作为中心。我不希望漠视了这些关键因素。许多团队都说“我们在实行Scrum”，事实上他们只进行Sprint planning和daily Scrum meetings，并没采用很多其它能够真正带来效率的Scrum实践。我希望他们能考虑混合实施XP之类的方法。我了解到许多团队最开始使用基本的Scrum, products back-logs和Sprint back-logs，然后转向更多的XP方法，如发布计划，用用户故事来描述back-logs上的条目，验收测试，自动化测试，他们已经在某种程度上混合使用了这些方法，并且可能仍然不采用Scrum中的某些实践。我注意到人们关注的不再是如何才能更敏捷，而是如何才能更有效的交付软件，这些不同的出发点取决于你所处的情况。例如，我可能会向一个存在软件质量问题的团队推荐XP实践，如采用测试驱动开发和持续集成。其他一些团队在软件质量方面没有问题，但是却无法和客户进行很好的沟通，他们可能需要使用用户故事，建立起与产品拥有者之间的联系，并进行规律性的演示，以便让产品拥有者参与到项目中来。我认为这其中有许多不同的出发点，而且终点也不是唯一的。你要做的是从解决对你最重要的问题开始，对实际的进展做出反馈，看看周围其他的敏捷实践，例如我今天所介绍的组合，将解决其他的问题。所以你一定要尝试去做，实验新的方法，做出反馈，然后再继续试验新主意。
Retrospective是一项很有用的技术，团队成员从中感觉到他们对开发过程具有掌控权，并去评估哪些主意可行，哪些不可行。这也是设计实验的好方法，你可以提议：“我听说持续集成是一个好主意，下一个sprint我们在白板上添加一个设置持续集成的故事，试试看效果如何。我们要尝试其它的方法么，或者这种方式是否对我们并不可行。”你会发现人们会观察其他团队在做什么，进而影响到团队的工作方式。有一个真实的例子，最近和我一起工作的团队有一块白板，用来展示所有任务。每个成员有一个圆形的脸孔图标，每天他们做什么工作，就把这个脸孔图案放在工作项目旁边，只要看这个白板就能知道大家每天都在干什么了。我注意到，楼下的一个团队也开始做类似的事情，但是把真人的照片换成了卡通图案的磁贴，他们在进行同样的实践，但也存在差异。没有人会说：“我认为你应该做那件事，我们的流程手册说你应该这样做”，相反地，他们会注意另外的团队在采用哪些有效的方法，并由此得出：“我们也可以那样做”。
我认为团队成员处在同一个环境下，看到彼此，相互间走动走动确实有帮助。其它好处还包括，有机会一起讨论如何在团队中实施Scrum，或者讨论如何实施测试驱动开发。所以，如果你有多个实施敏捷技术的团队，你希望他们能够分享已取得了效果的想法，这常常不属于retrospective的范围，而更像是对如何做事情的闲谈。我最近共事的组织都使用Scrum，但有多个不同的产品。我们组织了一次会议，分享各自如何进行product back-logs和Sprint back-logs，散会之后人们各自尝试新的办法。你可能会有这样的疑问：“为什么不去参加他们的stand-up meeting呢，看看他们是怎样做的，是否可以借鉴？”，从而获得与其他团队聊天的机会。另外一件值得介绍的有效方法是社区实践。当你向某个组织介绍Scrum时，通常会将原来的团队重新分组。之前所有的C++程序员、JavaScript程序员和数据库程序员是各自坐在一起的，你要将这些他们分散开，组成跨职能团队。如果他们过于分散，在结束活动的时候，数据库程序员没有得到分享最佳实践的机会，因此你需要通过纪律介绍这种scrum of scrums。当人们聚在一起分享心得：“这是我们最新打算要做的事情。”，一旦分成各个跨职能团队之后就需要进行这样的交流。
不完全是这样。我曾经遇到过自顶向下的改革，团队的领导说：“我们要采用敏捷开发”，他鼓励这个团队采用敏捷方法：“这就是我们要你采用的敏捷风格”。我发现团队内部会进行一些本地化的调整，敏捷将得到不同程度的实施，一些团队充满热情：“好啊，让我们来使用敏捷吧”，其他一些团队进展缓慢并希望这场运动能够快点过去。我曾在社区实践的话题中谈到过，我注意到这些人如果发现没有时间交谈，他们将会一起吃早餐，在跨职能团队组建之前就已经成型的团队，习惯于找一些机会来增加接触。不仅如此，他们还会谈论需要一起解决的问题，这是很有帮助的。少数组织中存在一种虚拟的团队，这种团队又叫做“orthogonal team”，团队成员拥有共同的兴趣，成员数量逐渐增加，以Scrum为例，我们最终用scrum of scrums来解决项目管理和处理问题，但是同时也会用scrum of scrums来规范纪律。所以，测试人员可能有专门的scrum of scrums，开发者也会有专门的scrum of scrums，这两种scrum of scrums进行的频率并不相同，也不一定和当前的Sprint或者当前发布一起进行，但它的作用在于解决我们面对的普遍问题。
这主要取决于组织的结构，采用矩阵式管理的团队会设定一个纪律长，有可能做到这一点，否则只能靠影响你的项目经理来做些事情了。收集证据或许能促成这件事情，我常常建议团队，如果认定问题存在，就要采取一些措施去补救。除非找到证据，否则他们不会去解决，而是往往推脱掉。他们可以说：“看，这就是我们在这件事上浪费的时间。这是所有的时间明细,它造成了浪费，我们可能需要些资金来缓解这个问题。”
当然。我想说，不论你的团队采用XP、Scrum，或者其它的敏捷方法，不要一味的照搬实践方法，要尝试花些时间看看周围，了解其它的敏捷方法，多去用户组，与其他人交流，了解他们团队正在做什么，去参加会议，听经验交流，了解其他人在做的有用的事情，并把它利用起来。如果你在一个多团队的组织中，组织一些讨论谈谈正在做的事情，以及如何执行以上说到的这些方法。
我认为可以。如果不进行社区实践会议，这些团队将无法推进他们的规则，他们将陷入到问题中，进展会越来越慢，事情往坏的方面发展，没有人对公共的平台和公共的技术负责，到最后大家都不会互相学习了。最后你得到了一群专家，对特定领域的规则了如指掌，但是他们从不交流知识，从这个方面说你也遭受了损失。
Generic Agile
发表人
LEE KAIFU
发表于
-
这个与我的观点是比较一致的。
实施敏捷，不一定非要完全教条式地照搬某种模式，甚至具体到每个细节每个做法。生搬硬套的敏捷未必能提升效率甚至适得其反。
Agile是一套相对普适的理念，未必非要局限于敏捷宣言的四条以及12原则。常常有人问题敏捷的精髓，然后就提出某个词来概括敏捷的精髓，并且强加别人接受这个所谓的精髓。敏捷的精髓在不同的侧面会有不同的理解，你认为对的，未必就是别人必须认为对的。
透过敏捷的理念可以生发出千万种的做法。推广、推行敏捷，重在理念及一套方法集，实施中接受敏捷的理念，选用已有的工具方法，结合自身实践，不断演化、改进，逐步形成一套量身定制的方法。Scrum可以作为一个框架，但非一成不变，适度的结合项目、团队具体实践，可以得到更佳的效果。
无论何时，敏捷是一套理念，思想上要接受这套理念。具体方法的实践应该服从于团队、项目的战略目标。
1 条回复
关注此讨论 回复