大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
用例之父称敏捷需要更加明智
作者 Shane Hastie 译者 李剑 发布于 2009年4月12日
在上周举行的Software Education SDC大会上，Ivar Jacobson——用例、UML和RUP的作者——说道，敏捷开发需要“明智”。
他提到，信息技术行业是比较容易追求时尚的，而且总想去发现银弹。他举出了下面的例子：
- 十五年前，大家全都在谈OO
- 十年前，就都变成了组件、UML、统一过程
- 五年前是RUP和CMMI
- 两年前是XP
- 今天是Scrum
这些都有好的地方——但无一是我们所需，我们需要的是更加明智的工作过。他说，“明智是敏捷的进化”。
- 敏捷意味着灵活和适应
- 敏捷提供了简单、轻量级的出发点
- 明智意味着知道什么时候超越敏捷
- 知道什么时候服从规则，什么时候打破规则
- 知道什么时候按老样子做事，什么时候做出革新
- 知道什么时候增长，什么时候退缩
按照Jacobson的话说，“明智就是敏捷++” 。他接着给出了一些明智（和不明智）实践和过程的例子，这些都是他在过往这些年里发现的。其中包括：
- 人（不明智）——把过程和工具看的比人更重要
- 人（明智） ——理解软件是人构造的，而不是过程和工具！
“有工具的蠢货依然是蠢货，但是是更危险的蠢货！” - 团队（不明智） ——把团队做职责分离（需求、分析、设计等），分成烟囱管一样的小组
- 团队（明智） ——跨功能的小型（一般是10个人，或者更少）自组织团队，拥有混合技能，可以承担工作。
“软件团队就像运动队，拥有一切所需的能力去赢得成功”
- 项目（不明智）——试着遵守瀑布流程
- 项目（明智）——先做一个“皮包骨的系统”起来，证明你已经排除了所有核心风险，然后再在需要的时候往这个皮包骨的系统上加肉。
“做远景思考，分步实施”
- 需求（不明智）——想着一开始就把所有需求都定义出来（软件开发中有一点是不变的，那就是需求总是会变）
- 需求（明智）——在轻量级的需求上做先期决策，在需要的时候再增加细节——需求是可以协商的，优先级是可以变化的。
“在设计项目时考虑到需求变化”
- 架构（不明智）——预先把所有设计都做好，没有比这更糟糕的架构了。
- 架构（明智） ——架构够用就好，架构必须来自于可以执行的代码。
“先把皮包骨的系统弄起来，一步步添肉”
- 测试（不明智）——把人分成两种，一种是开发，一种是测试。不明智的测试就是“软件世界中的清洁工”——给开发收拾残局。、
- 测试（明智） ——整个团队都为质量负责，测试也是一等公民。
“不管你做什么，在验证你确实做了想做的事情之前，这事情就没算做完”
- 文档（不明智） ——机械式的填写文档模板，只是因为一些过程规则是这样规定的。
- 文档（明智）——了解“自然规律：人们不读文档”。只在必须的时候才写文档。
“关注最根本的东西——给谈话占个位子——人们会自己找出剩余的部分”
- 过程（不明智） ——不断追逐最新时尚，要求你按照最新的规则手册把一切重写。
- 过程（明智） ——不要把孩子直接扔到浴缸里：
1. 先从现有的工作方式开始
2. 找出问题所在
3. 每次只改一个实践
“人们不读过程方面的书，所以还是只做最关键的部分，其他方面大家会自己做好的。”
明智的关键因素还是关注人，正如Jacobson所说，“这终归还是你的事”。
查看英文原文：Father of Use Cases Says Agile Needs to Get Smarter
译者 李剑 李剑──ThoughtWorks高级咨询师，在持续集成、重构等领域具有丰富的经验；多次为国内大型企业敏捷组织转型提供咨询和培训服务。
哈哈，换汤不换药
发表人
yongji zhang
发表于
人掌握方法，而不是方法掌握人
发表人
liao bruce
发表于
不是所有的人都意识到了这些
发表人
Wang Hui
发表于
-
敏捷就是一个框，什么都能往里装，可以从各个角度去阐述它，分享一下我的看法《敏捷迷雾背后的本质》
gurudk.javaeye.com/blog/366299 -
写的不错，其实每种方法都有自己的使用范围，都有优点和缺点，关键是自己缺什么，怎么用这些方法。
-
不过看起来越来越多的人已经认识到了,敏捷几乎就是银弹!
3 条回复
关注此讨论 回复