大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
文章
该内容已经被标记书签！
标记书签错误，请重试！
轻装上阵: 减少团队的启动时间
作者 Pat Kua 译者 韩锴 发布于 2007年12月4日
面对现实：团队的变化
在 过去的几年里，我和很多团队一起工作过，有的时间很长，有的则很短。我注意到在这些团队中，都面临一个相同的问题，即团队的成员总是在变化。通常，任何项目背后的变动都会引发这样的改变：比如员工生病或者度假，项目需求增加，出现新的项目或者仅仅是员工希望能改变当前的工作。然而像每日站立会议、结对编程等这样的敏捷实践，如果没有足够的上下文场景，就无法提供给新员工以足够有用的信息。这是因为敏捷实践并不能直接提供新团队成员的学习需要。因此我建议使用其他一些实践以便有效减少新成员的"启动时间"。
相关厂商内容
将排队论（Queuing theory）应用于团队中
在制造业中，从订货到交货这段时间基本上都会分为四部分，包括：
- 启动（Setup）——产品等待进入运作（Run）阶段的耗时。
- 运作（Run）——产品从待处理阶段进入处理阶段的耗时。有时会分为处理耗时和等待耗时两个部分。
- 移动（Move）——产品转移到下一个阶段的耗时。
- 等候（Queue）—— 产品进入下一个启动（Setup）阶段前的所有耗时。
由于从订货到交货这段时间的后两部分（移动和等候时间）不会影响一个独立的项目，因此我们的关注点通常都会落到前两部分上（启动和运作时间）。对于团队的新成员来说，启动时间指的就是他能融入团队并充分发挥自己能力所花费的时间。其中，团队需要吸收并培养新人，教会他们各种技巧，直到他们可以发挥自己最大的潜力为止。为这些事情所付出的所有时间和努力，构成了启动时间。运行时间则与成员在项目中工作的效率有关。
大多数过程都致力于促进团队的通力合作，帮助降低项目运营的开销。但是它们都忽略了一件事，减少新人用于熟悉环境所需的时间——比如，新成员多快可以加入到团队中，或者团队处理成员变更的能力有多强。
敏捷实践关注运行时间，而非启动时间
"学习"对于每一种敏捷方法论都是不可分割的一部分。其中大多数都关注于短期的反馈环、进行自我反省以及强调持续改进。
但是，每个新进入项目的人在进入项目一段时间后，对学习的需求会变得大相径庭。
对于新的团队成员来说，消化信息的过程通常会带来更多的问题。像在Scrum站立会议上说的“我昨天做了……”这种话，会触发新人更多的问题，比如“他 们在说什么，这与我所了解的又有什么联系呢？”结对编程的效果也会有变化，如果结对的那个新人对整个项目有个大致的了解，效果会好些；但如果只是面对一个 接一个的User Story，效果就会很差，毕竟此时窥一斑而难以见全豹。我曾经见到过，当面对大量琐碎的信息碎片，也没有一条明确的线索将它们串连到一起时，很多团队的新员工都会感到很沮丧。
新人需要学习的主要内容是关于项目的概貌（larger context）。他们要找到应该了解的知识，逐步理解领域相关的词汇表，并融入团队及其文化。项目越复杂，加入的人数越多，这个阶段就需要持续更长的时间。了解了项目的概况之后，就要学习一些更加深入的知识了。有了概况中包含的信息，其他信息就变得更容易被接受了。每日站立会议、结对编程、测试驱动开发等这些 敏捷实践，它们提供的所有信息只有放在一个更大的场景中才会真正有用。前述的这些敏捷实践并不会直接关注团队新成员的不同的学习需求。你应该怎么做？答案 是：应用其他特定的实践来减少新团队成员的“启动时间”。
利用“提携(onboarding)策略”减少使用时间
下面简要地列出了一些技术，在我的团队中，新员工们发现这些有助于帮助他们掌握必要的上下文场景，来理解其他敏捷实践提供的信息：
- 预备Email——在新员工加入前，给他们发一封Email，解释一下项目的背景，这样他们在正式工作前就可以先阅读一些资料，或者锻炼并学习与项目相关的技能和知识。
- 业务问题的大视野——开一个会，告诉新成员项目背后的价值以及驱动力。让他们一点点地熟悉领域相关的术语，并把他们的工作放在一个更大的上下文环境中。
- 具化架构——图表可以很好地用于将琐碎的概念放到更大的概念中。以此来将讨论聚焦在汇集知识和分析这些知识如何相互关联上面。
- 项目问题透明——坦诚地公布团队已知的需要改进的领域。要关注如何提高、并制定计划，而不是一味地看到问题有多糟糕。
- 细小的任务——将一件庞杂的工作划分为大量细小的任务，以便新的团队成员不需要很多麻烦就能理解项目团队成员正在做些什么。确保每项任务都能在相对独立的条件下完成。
- 互相学习——让角色相似的人们一同工作，来分享他们学到的新知识和任何可能对其他人有用的技巧。这类会议应该集中在技能的学习与共享上。
- 从学生到老师——尝试让新成员去帮助其他的团队成员。让新成员向其他的团队成员解释概念，这样既能巩固他们所学的知识，又能提高他们的思考方法。
- 尊重个人的差异——让学习的过程适合每个人。使用图表、文档、CRC卡或者任何事物，帮助他们更好地构建出项目的整体图景来。
- 放手一搏——给予每个成员以足够的空间，让他们在一个安全的环境里犯错。有些教训如果是自己学习的，印象将更加深刻。
团队成员在不同项目间轮换不再困难
敏捷实践强烈推崇“学习”，但是它们只关注减少“运行时间”，而非“启动时间”，因此对于团队的新成员来说，敏捷并不是非常有效。理解了新成员对学习的不同需求后，就可以使用一些特定的“提携策略”，直接解决问题。然后采用其他实践持续减少“启动时间”。
大多人在加入新公司时都会经历一些入职的程序。你在项目使用的那一套有多有效呢？
关于作者
Patrick Kua是ThoughtWorks公司的软件开发工程师、培训导师和教练。Patrick热情地为他所在的团队创造价值，对于那些尽情享受生活的人， Patrick也会热情对待。他相信，如果能把喜欢的事情和事业结合到一起，就会变得更好。在过去三年半的时间里，他指导、领导并参与了很多实践敏捷的团 队。
查看英文原文：A Leaner Start: Reducing Team Setup Times译者简介：韩锴，ThoughtWorks公司的咨询师，毕业于北京工业大学。主要关注领域为Java SE应用、Ruby语言、Eclipse插件开发以及敏捷开发方法实践，参与翻译了《Java并发编程实践》、《Ant in Action第二版》。参与InfoQ中文站内容建设，请邮件至china-editorial[at]infoq.com。
赞
发表人
Zaoldyeck Solomon
发表于
不错！
发表人
Lai Mead
发表于
Re: 不错！
发表人
zhang sj
发表于
3 条回复
关注此讨论 回复