大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
讨论：Scrum回顾会议怎么开最有效？
作者 金毅 发布于 2009年6月8日
Scrum中的回顾会议到底怎么召开更加有效？大家又遇到了什么样的问题？最近在Google敏捷中国邮件组中，网名克强的网友发了名为“Scrum中的回顾会议如何开？”的帖子，其中他提出了关于Scrum回顾会议的8个问题和大家进行讨论。这八个问题是：
- 领导要参加，怎么办？
- 会议达成的共识要不要以书面形式写下来？
- 以MSN形式开回顾会议，有没有人实践过？
- 是不是强制要求每个人都要发言？
- 有什么典型的议程没有？
- 时间长度上面，真的需要3小时吗？
- ScrumMaster在回顾会议时有没有特别不恰当的行为，应当避免的？
- 还有其它问题？
网友们对于“领导要参加，怎么办？”这一问题异议最多。有网友抱着无所谓的态度，只要领导有兴趣来，就由他们来。而网友Alsor Zhou对领导的参与表示了坚决反对：
拒绝，一定要拒绝，特别是跟团队有直接从属关系的。否则，很容易造成“绩效考评”。
部分网友则有着完全不同的看法，网名为Andy的网友这么认为：
我们欢迎领导（特别是负责研发的副总）参加，希望他可以通过这个机会了解我们下一步会如何改进，为什么要改进，同时也更有机会获得管理层的支持。
对于其他几个问题，网友们的看法却都是惊人的一致：大家都同意把会议共识记录下来；都觉得不能强制每个人发言，但需要引导让每个人来发言；都觉得议程主要谈做得好的和需要改进的地方；都认为会议1-2小时足够了，这样不容易跑题。
大家同时还指出，对于回顾会议需要有一种开放的讨论环境，不能有人太强势，而且会议的结论是整个团队做出的，而不是个人。于是领导的话题再次被提出，当Raymond谈到“有没有特别不恰当的行为，应当避免的” 的时候，他指出：
最后一个发言，否则下属会被影响 。
在Esther Derby和Diana Larsen的《敏捷回顾》一书中，作者也提到了关于邀请项目以外的人（包括领导）来参与回顾会议的问题。他们认为迭代中的回顾会议大部分应该集中在团队内部，而对于一个正式发布或者项目结束时候所做的回顾会议应该邀请些对项目有所付出的编外人员，其中可能包括项目管理层和客户。作者认为
发布一个产品所涉及的人比一个增量开发要多得多。适时地停下来，深入并且发散地想想你是怎么跟他们一起合作的。你可以选择有助于达到你回顾会议目的的人来参加。你要去寻找那些在项目中也扮演重要角色，同时愿意分享他们观点的人。
各位InfoQ的读者，你对这些问题又是怎么看的呢？欢迎加入讨论。
金毅 多年来服务于欧美软件外包行业从事管理工作，对软件工程、方法学等在外包业的运用和CMMI实施略有感悟。
领导应该尽量少参加迭代回顾会议
发表人
Zhang Charlie
发表于
以MSN形式开回顾会议，ScrumMaster不恰当的行为
发表人
Yao Scott
发表于
关注敏捷实践改进
发表人
Song Sam
发表于
-
对于“领导要参加，怎么办？”这类脱离具体 context 的笼统问题往往没有唯一的标准答案，it depends。
这是大多的公司（10 人，100 人，还是 1000 人？），什么类型的项目，重要性如何，哪一级别的领导（产品级，部门级，公司级？），参加的目的是什么，企业文化，合适的时机 ... 有很多的因素会影响答案。
Alsor 和 Andy 说的都有道理，因为他们面对的是不同的 context 和 constraints。
如果一定要找个标准答案，可以参考利弊原则，视情况而定。如果利大于弊，就可以参加，如果弊大于利，就不要参加。还可以参考太极敏捷的 Adding Value 原则，如果领导参加会议，不能带来额外的价值，那为什么要做呢？
我们常常看到，在一些等级分明的企业中，由于中高层领导参加基层会议，往往会导致意见失真，大家反而不敢说实话、暴露问题了，这其实与企业文化有关。那些具有先进文化的企业就不存在这种现象。
一般情况下，我赞成 Derby 和 Larsen 所说的，“迭代中的回顾会议大部分应该集中在团队内部，而对于一个正式发布或者项目结束时候所做的回顾会议应该邀请些对项目有所付出的 stakeholders，其中可能包括项目管理层和客户”。
迭代回顾会议，主要的目的是内部总结和改进，如果内部能够顺利解决，还有必要让公司副总参加吗？
回答此类问题需要辩证思维。
资深敏捷教练 张恂
www.zhangxun.com -
以MSN形式进行分布式的讨论，缺少统一的可视化平台，不利于组员之间的交流，同时ScrumMaster不能有效的引导每个人发言。效率低下导致浪费的产生。
ScrumMaster应当控制发言的时间，避免过早的下定论，影响成员个人想法的表述，应以引导大家发言为主。 -
敏捷回顾重点是关注在过去的一个迭代中哪些方面的实践不尽如人意，有什么更好的方法能够弥补。因此应该是团队成员为主，就算是stakeholder参加，也应该是列席。
3 条回复
关注此讨论 回复