大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
文章
该内容已经被标记书签！
标记书签错误，请重试！
为什么有些公司敏捷实施不成功？
作者 Christopher Goldsbury 译者 刘洋 发布于 2010年1月20日
介绍
常听说有公司实施敏捷失败？本文研究探讨了那些经常被忽视，却导致敏捷实施失败的组织级原因，也讨论了为什么这些组织级原因并不是很容易能发现，并提出了一些处理此类组织障碍的潜在策略。本文的目标读者是负责预算的管理人员，尽管技术人员可能也会对此感兴趣。
相关厂商内容
敏捷的历史观
敏捷实践从哪里起源，因何而起源？这个问题将我们的注意力直接转向一些公司的大规模软件开发工作，这些公司要么开拓市场并以出售其软件作为主要收入来源， 要么将它们的定制软件视为其业务的主要竞争优势。我们将此类公司称为X。敏捷不是起源于从事固定报价软件开发工作的公司的IT部门的，而我们把这类公司成为Y。
为何这个问题重要？
答案在于X和Y公司是如何从财务角度看待开发工作的。在X公司，软件开发工作被视为一种投资，而且是为公司的未来所做出的首要投资。而在Y公司，开发工作 是小规模的，只是被看成是有时间界限的并需要去跟踪的一笔开销。X公司的经费是划拨给团队，Y公司的经费则是划拨给项目。请将最后这两句话再读一次。
在X公司，敏捷方法能成功；在Y公司，敏捷方法则将失败。
在固定报价软件开发中，软件开发工作是要在某个时间点结束的。为了获取项目经费，需要你预先定义范围，进行估算，分配资源，开发，测试，实施，然后将其交给支持部门。这是Y公司所采用的方法。
而在时间和材料（time and materials）决定经费的情况下，公司做出决定，有必要组建软件开发团队，因为未来会有很多需要开发得很好的项目。他们会在预算期内（1年，2年） 估算可以承受的开发团队大小，并据此分配资源，然后决定项目范围和安排进度。这是X公司所采用的方法。
发现区别了吗？在X公司，总是有软件在被开发。这一活动没有结束点，团队经费据此划拨。所以，在基于时间盒的迭代中，把任务放入backlog、按优先级排序、进行估算和评审才有意义的。
而在Y公司中，他们通常只为某个预算期的一些子集（例如3个月）的工作划拨经费。在此之后，就没有更多的钱或者公司不愿再拨出额外款项了。他们不希望维持 一个长期的开发团队，因为他们负担不起，再说也不会有足够的开发工作使团队一直有事可做。因此，就必须通过严格控制和强有力的项目管理来确保3个月后项目能交付。
从财务角度来看，敏捷是一种奢侈品。它假定你始终有一个软件开发团队，并且总有开发工作。它假定你的团队每年都能得到经费支持，并且你作为管理者，不必担 心需要按单个项目来划拨经费。作为敏捷管理者，你主要关注于日程安排、范围和团队能力。预算是每年或每两年才需要考虑的事情。你根据公司所面临的经济现状 向上或向下调整预算。成功的标准，则主要集中在一段时间内所交付的功能。
在Y公司，你可能被分配了5万美元，要在3个月内完成项目。制定预算和控制费用至关重要，它们决定项目成功与否。管理者会在资本周期的不同时段得到按照项 目划拨的经费。你可能按时交付了所有功能，但如果超过了预算，也不会被视为一个成功的项目。作为这家公司的一名经理，你需要关注项目管理三角形的方方面面。你的团队可能是临时性的，并由合同工组成。在这种情况下实施敏捷是个错误...甚至可以说是个低级错误。为什么呢？
估算
关键在于估算。
在敏捷软件团队中，只有当你开始工作的时候，你才对其进行估算。就Scrum来说，你仅仅估算下次迭代的工作。因此你怎么能知道产品需要多长时间完成呢？ 你不可能知道。而且，你确实不在乎这点。因为你将持续在每次迭代中交付功能。只要产品经理和QA说你有个足够好的产品，它就可以作为正式版本发布。你也许 有一个猜测值，但是直到团队对它进行估算….你真不知道它还需要多长时间。
在固定报价项目中….你的估算需要在最开始就进行。公司会问你需要多少经费来构建此应用程序，因为他们不想无休止地资助它。他们希望它能结束….最好是早 一点而不是迟一点。资金是有限的，而且你的项目，虽然可能是必需的，但不会被看作对公司的未来至关重要。它的投资回报率甚至可能为负数。如果你回复公司的 领导者说；“我不知道此产品需要多长时间完成...请为团队提供一年的经费，然后我们看看每次迭代后会它会是什么样子”，那你可就犯错了，其结果很可能是你被解雇了。
第二种情景中，如果我在取得经费并雇用团队成员后告诉他们：“我们将使用Scrum”。他们将会估算下次迭代的工作。他们会假定他们的估算被认真对待并且你会据此给予他们时间去完成工作，而不管他们的估算是否适合你初始的项目经费。这很公平的，只是不幸的是，你作为管理者将处于难受的位置，因为你需要提交 预算/日程变动，并且/或者要在初始估算被证明为不准确时削减项目范围。最终你无法管理项目还因此得出结论.......“敏捷这事儿行不通”。
这里的错误在于假定公司的领导者了解并且从上至下地致力于实施Scrum和敏捷原则。从他们要求你估算完成项目所需的经费这一细节，可以察觉出实情与假定大有出入。如果他们问的是，“在后面三年需要多少经费来维持一个软件开发团队？”那么我们就会明智地从敏捷观点出发着手处理了。
真正难题
因此，什么才是公司实施敏捷的真正难题？这可以概括成以下几点：
- 敏捷假定公司需要长期的软件开发工作而不是短期的项目。
- 敏捷经常被公司管理层假定为是一种对预算没有影响的开发流程。但事实并非如此。
- 开发团队假定领导者明白实施敏捷对于预算层面意味着什么。
我们不应低估这些问题的复杂性。开发人员和团队往往对预算毫无概念，所以他们不知道从财务角度是怎么解读敏捷开发的。对于这一点，在网络上很多关于敏捷的 文章中体现得很明显。同样，管理人员往往对开发和特定的敏捷实践一无所知。实施敏捷需要通过培训来减少这两个世界之间的冲突和误解。
所以，试图在一个固定报价项目中实施敏捷实践会有什么后果呢？本质上，这其实就是给瀑布项目批了层敏捷的“羊皮”。
故事点
敏捷团队经常使用故事点来衡量当前工作的复杂性。每次迭代中完成的点数确定了他们的速度（每次迭代点数），同时基于速度可以向管理层提供一个估算，用于表明某个给定的迭代能完成多少工作。
如果你来自像Y那样的从事固定报价项目的公司，你的第一个问题就是：“这怎样和时间联系起来？又如何计划成本和投资回报率？”事实是：不能。并且也不打算能。重申一下，敏捷学家假定你正在为一个软件开发团队而不是一个软件开发项目提供经费。
在X公司，你甚至可以用汉堡包或香烟作为参照，来估算每个迭代的工作。这没关系。你总会在某个时间点完成这个产品（根据要求增加/减少功能）。唯一真正的问题是：何时我们能称之为完成然后作为产品发布？团队经费并不取决于工作量的估算。
而在Y公司，项目经费直接与工作量的估算相关。至关重要的是，我们将其与时间紧密联系起来。因为我们的成本动因往往是以小时来计算的。故事点在这里毫无意义。
ScrumMaster vs 项目经理
“敏捷不需要项目经理。”你曾听到过这种说法吗？这种不经意的吓唬会使传统型项目经理提心吊胆。然而，这一说法是对的。如果你假定团队每年都能得到 经费，并且经费不受项目工作量影响，那么组织和管理开发工作就的重点将是技术指导、任务和风险管理。这种情况下根本不需要时间表和预算，ScrumMaster就足够了，他能更好地完成任务。
不过，如果你在像Y这样非敏捷的公司工作，那么传统的项目管理实践不仅有效，而且对于控制预算和工期偏差来说是必要的。这种情况下，就需要开发团队的领导去尽量节约公司的每一份宝贵资源，并且需要具备一个准CEO的技能。
在有经费支持的开发团队中，项目经理的角色的确被改变了。而固定报价项目开发团队则没有。
每日站立会议
因为种种原因，敏捷使用每日站立会议。这其中包括：激励团队成员、缓解风险、汇报工作、问责、建设团队等。即使在固定报价瀑布式的项目中，这也是个好主 意，没有理由不继续使用这一实践。但从事固定报价项目的团队必须意识到：你并不是在真正地实施敏捷开发，最后期限正在悄悄地逐步逼近。你还可能需要权衡时 间需要。每日站立会议应该很短。但当你只有三个月的经费时，即使每天15分钟也得累计并考虑在总开销之内。
迭代评审
有充分经费的敏捷软件团队会渐进式地回答何时能完成产品这个问题。在每次迭代（例如30天）结束后，他们都会进行功能评审，并评估产品发布的准备情况。同 样，这也是个能被用于固定报价项目的好主意，但需要去引导业务负责人理解：迭代评审是一种缓解风险和问责的方法，而不是对已完成产品的演示。
迭代规划
迭代规划的确假定你是在一个有经费支持的团队中使用敏捷。它需要确保你的成本已知，预算周期固定，并且团队做出的任何估算都不会严重破坏你的预算。在固定报价项目中使用迭代规划基本上肯定会导致混乱、预算差异、和/或功能丢失。
燃尽图
燃尽图展示了一个特定迭代中完成功能的进度。它们是对一段时间内团队业绩的衡量，但并不能用于阐释离项目完成还有多远。如果我们将所有燃尽图都总结在一 起.....它们可能能够说明这一点。但鉴于燃尽图通常被严格地用于衡量项目开发工作量，所以即使这点也并不是总能被做到。
在固定报价项目中，问题通常不是团队在一个时间段内完成多少功能，这真的不重要，重要的是在经费允许的时间段内所有的功能都必须完成。
因此，在固定报价项目中使用燃尽图和迭代会向团队和客户传递错误信号。
总结
首先，我建议不要试图在固定报价或基于项目划拨经费的情况下尝试实施敏捷。取而代之，作为经理，你应该评估你的公司是否能够支持敏捷实践以及一支人员配备 齐全的开发团队。如果能，那么你应该实施敏捷...它能运作良好；如果不能....那么你最好明智地坚持使用传统项目管理实践。
如果你确定你的公司有足够资源和工作负荷来支持软件开发工作，但没有使用敏捷，那么问题就涉及到如何使管理层相信敏捷对于开发工作是有意义的。戴顶变革管理和销售的帽子....你会需要它们的。
其次，项目经理和ScrumMaster不是一成不变的角色和头衔。在一家公司，项目经理/ScrumMaster可能要负责预算；在另一家，他们可能不负责。有时候，在一个传统组织结构的公司 中，他们可能有直接下属；而在另一家，组织结构可能更偏向于矩阵式，项目经理/ScrumMaster没有直接下属。我提到这些差异，是因为有关敏捷的文 章，就像所有的著作，都是从作者的观点出发的来阐述。往往一些在某些情况下能起作用的过程或技术会被拔高说成万能的过程或者技术.......然而实际情 况是该组织和角色都能很好地适应这个过程和技术。如果角色和组织发生了变化，它可能就不会再起作用了。在敏捷vs瀑布开发的博客圈中，这种背景信息经常缺失。
最后，有关敏捷的争论往往被比喻成一种哲学的战争。但是，从我的经验和角度来看，这种混乱很大程度上是误解的产物。很多时候，一个技术经理并未全面仔细考 虑实施敏捷的商业内涵。同样，业务人员则常将敏捷误解为与他们如何提供经费无关的“一些开发工作”。在我的职业生涯中，很幸运，这两类问题我都遇到过，并 且找到了解决之道。通过这些，我也才深刻地理解了有关预算的假定：这个导致敏捷实施失败却常常不被识别出来的原因。
查看英文原文：Why Agile Adoption Fails in Some Organizations。
译者简介：刘洋，上海交通大学计算机系硕士，目前在某外企任职项目经理，拥有多年Web开发及团队管理经验，致力于敏捷思想和实践在软件服务行业中的应用。
感谢金毅对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。
有些部分有点道理，结论不敢苟同
发表人
Jun Ran
发表于
太武断了吧
发表人
king win
发表于
为什么有些公司敏捷实施不成功？
发表人
huang zheng
发表于
视角很独特
发表人
Han Zheng
发表于
各得其所
发表人
Zeng Andrew
发表于
固定报价的项目可以用故事点来和时间联系起来
发表人
Keqiang Zhang
发表于
有些可以借鉴，但是不敢苟同
发表人
Wang nethibernate
发表于
适用才是硬道理啊
发表人
Chou Jacky
发表于
写的很好
发表人
王 瑜珩
发表于
个人觉得X公司类型的团队相对而言更适合点
发表人
weng crystal
发表于
应该如何去理解敏捷？
发表人
Chan Jackei
发表于
经费和投资回报对公司永远是第一位的。
发表人
Zhang Lovrane
发表于
划分太武断
发表人
Zhang Double
发表于
-
如果是5万美元3个月的项目，就不能分为4个迭代来实现么（每3周一个迭代）？这种项目，就真的不需要应对客户需求的变化么？
想想看敏捷开发宣言和原则吧，它们在这种项目就真的不适用么？
如果把敏捷狭隘地理解为“在项目团队中完整地实施SCRUM”，那么就可以得到作者的结论，然而敏捷并非只有SCRUM，也不一定非要完整一套照搬才叫敏捷，根据实际情况，从方法集中挑取自己适用的实践不是敏捷是什么？ -
恐怕多数的项目都属于Y类型的，合同约束了整个预算以及交付日期，难道敏捷在这样的项目上一定失败吗？不会那么绝对，关键还在于敏捷的实施过程吧
-
适合自己的就是好的，敏捷的核心因该就在次。
-
看了很多关于如果实施敏捷的文章，大多是技术层面的。从财务的角度看敏捷，确实让我有了新的认识。
-
的确，不用太绝对，各取其所是对的。
-
一般的，合同或内部任务是不会有需求的细节，但合同金额或预算是比较难改的。在这种情况下是可以用故事点的。
如果有所积累，有历史的速度，比如历史数据表明 6人团队4周平均烧掉80个故事点。如果没有积累，就先做一个迭代来看看。
可以得到每人月的故事点数。
先算 可以提供的人月数量 = 固定报价/（1+期望利润率）/平均人月成本
然后计算 可以完成的故事点数 = 可以提供的人月数量 * 每人月故事点数。
然后得到 计划的故事点数 num1 = 可以完成的故事点数 * 60% ~ 80%
以上务必悄悄的计算，不要汇报。
然后进行需求范围划定，经讨论 选择 A,B,C....等等功能进行开发，大块上肯定要符合合同或任务书，细节上要限制在计划的故事点数以内。
经分析，这些 需求范围的故事点数约是num1
然后 迭代，燃尽，拥抱变化.... -
我觉得说的有些太武断了。我觉得作者好像仅仅在强调一个团队完全实施Scrum的情况下可能会失败。但是所有的敏捷方法都是基于敏捷宣言的，所以我觉得在敏捷宣言的基础上可以有很多的修正。
况且，固定合同的项目从合同上来说可能就与敏捷有矛盾！但是我觉得不是没有调整的可能。我记得Infoq上以前有一个关于荷兰铁路的项目实践应该就是从传统->敏捷的，可以借鉴！ -
有部分内容深有同感。
我觉得在项目应该有不同的方式来管理不同类型的项目，不是所有的项目都硬可以用一种方式来管理。
我不相信有大同的社会。
不过每一种好的方式都值得借鉴，这点我一直坚持着。 -
项目的类型确实对敏捷实施有很大的影响影响，如果本身客户不敏捷、合同不敏捷，那么就算团队敏捷，也敏捷不起来，反而不如不敏捷。
-
个人觉得一个long-lived的团队在一些实践更具有持续改进的可操作性。 成员变化的团队在交互沟通的成本比较大，同时难以估计一个团队可能会有的capability.
-
应该如何去理解敏捷？当敏捷变成了成体系的方法论，变成了值得争议的理论时，它还是敏捷吗？
敏捷是否该更多得强调当初的那几条原则，然后更多的去关注结果是否达成？
敏捷是否应该更多的去讨论项目实践，讨论基于一个个实际项目上下文环境中的经验和体会？而避免过多理论的上升？
软件开发并非科学实验，开发过程自身具有不可重现性──无论是人、过程、技术、工作内容以及外部环境上，都是动态的因素，不可能找到完全相同的两个项目，也无法完全重现一个项目。在这种环境下，如何去评估项目经理的经验和敏捷方法哪个更重要？ -
无论是传统过程还是敏捷，所做努力的最终目的都是协调经费和投资回报。
如果说按团队来划分经费，公司就会不停的进行投入，这是不合理的（钱总是有限的，回报也肯定是有限的，公司会做出选择）；另一方面，即使是按照项目来划分，也是有可能实施敏捷的。 -
不是y公司就不做全局计划的，SCRUM也不是只关心当前的或下一个sprint的内容。
13 条回复
关注此讨论 回复