应用云平台的可用性——从新浪SAE看云平台设计
云计算平台的可用性，相比传统互联网服务而言，更加复杂和困难，也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台，以及对云计算的用户提出了建议。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
敏捷的核心：消除浪费，走向精益
作者 Jeff Xiong 发布于 2007年7月4日
首先考虑质量问题。一些软件企业为了降低成本而忽视质量，但质量低下的软件会造成返工的浪费，反而提高成本。相反，在日常工作中投入更多的精力来保证质量，反而能够为企业节约成本。ThoughtWorks中国公司技术总监Michael Robinson用软件工程的经典理论来分析这个问题：
任何一本软件工程教材都会告诉你：假设在分析阶段找到并解 决一个错误的成本为1，在设计阶段解决同一个错误的成本就变成10，在实现阶段就变成100，在维护阶段就变成1000。敏捷软件开发中的众多实践正是为 了避免低质量和返工的浪费。尽管它们一开始看起来似乎有些麻烦，但它们带来的收益是实实在在的。另一种常见的浪费则是“为将来准备的投资”。例如为了应付将来可能出现的需求变化而提前引入的灵活设计，如果需求没有发生变化，这些灵活设计就会成为浪费：不仅浪费了将它设计出来的成本，而且浪费了继续维护它的成本。制造业为了降低库存成本而创造出“Just In Time”的生产和决策方法，ThoughtWorks中国公司总经理郭晓认为这些方法同样适用于软件行业：
如何消除预测错误的浪费？避免预测错误的 根本办法就是推迟决策：决策下得越晚，就越不容易因为预测失准而造成浪费。当然也不能晚到错过了时机、耽误了工作才下决策，这就像丰田制造的Just In Time，决策也要Just In Time。过早的、含有太多预测成分的决策也会造成浪费，其危害丝毫不亚于过晚的决策。在最近的两篇Blog里，我谈到了一些从更深层次思考敏捷的心得。在我看来，敏捷的、精益的、实用主义的决策往往是符合中庸之道的：它们往往是各种因素、选择权衡之后的结果。敏捷方法极端重视提升客户价值，为了达到这个目标而采取的手段通常都不可能是极端的。
中庸之道常常有效的深层原因是边际效用递减律：对一个方面的东西重视到一定程度以后，再加入更多的重视，收到的边际效用递减；同样的重视度放到另一个方面上，能够收到更大的边际效用。让每一分投入收到最大的回报，尽可能地消除浪费，这是精益的追求。在另一篇Blog里我谈到了如何进行精益设计。设计方案的选择说到底应该是一次成本与收益的计算，而不是个人审美取向的衡量——当然，优秀的程序员能够把这种计算变成本能，我认为这就是“软件开发的艺术”所在。敏捷方法强调“简单设计”，同样是经过计算的结果。
在面对一个复杂并且灵活的设计时，首先要衡量的不是实现它的收益，而是“现在实现它”与“将来实现它”之间成本的差额。不论一个灵活的设计的收益和成本如何，只要这个差额非常小——等到未来实现它也没有什么额外的困难，就应该毫不犹豫地推迟决策，等到真正需要的时候再引入灵活的设计。感谢现代化的IDEs，很多时候我们讨论的这个成本差额确实非常小，这是敏捷设计通常取简单方案的原因所在。值得注意的是，随时进行这种成本与收益的计算并不是一件易如反掌的事。计算本身也有成本。这是最佳实践和工具支持存在的意义所在：你可以用较低的成本得到前人积累的知识。例如ThoughtWorks在介绍其项目管理工具Mingle时特别指出其中融汇了该公司多年从事敏捷软件开发的经验：
Mingle是一个敏捷项目管理工具。它为整个团队在软件交付过程中提供“一站”式服务，并通过有10年敏捷项目开发经验的ThoughtWorks公司提供的开发框架共享所有的项目成果。我们带来了敏捷开发方法，同时Mingle将会支持和推动这一切工作。畅通的信息渠道，清晰的成本/收益核算，全面消除浪费，这是精益制造的核心所在，也是敏捷软件开发的核心所在。
消除浪费的敏捷
发表人
Zheng Ye
发表于
PP就是一个消除浪费的很好例子
发表人
Lai Jason
发表于
核算
发表人
Guo Xiaogang
发表于
敏捷应当不仅仅是消除浪费
发表人
Jade Love
发表于
含糊器词,没有衡量的原则和标准
发表人
guan lei
发表于
-
程序员版：消除浪费的敏捷
-
呵呵，透明又要开始思考的黑子大爆发盛期了，赞！！
感谢 dreamhead 提到以程序员角度进行对敏捷的思考，我也来抛出一块小砖头吧（呵呵，别误会不是拍砖）——
其实，结对编程就是一个消除浪费的很好例子。有些人（包括我在一开始了解到 XP 的时候）就会觉得它的实践之一的 pair programming 简直就是浪费资源嘛，其实不然。甚至有人说，PP 就是资本家剥削榨取程序员更多剩余价值的最好方法——做过 PP 的人都会觉得结对过程中有人盯着，精力要非常集中，一场 PP 下来甚至有时候会精疲力尽。而实际的结果，看似是两个人在做一个人的事情，却要比两个人分别做交付的成果还要多。毕竟有人监工而且还可以一起 tackle 问题，要比一个人碰到问题的时候，四处找答案，最后可能影响工作效率的效果好多了。
另外，这样代码的质量也可以得到很大的提升。借用一下软件工程的经典原理之一：一个问题在它产生初期就被发现，修复它的成本要比在部署维护之后发现并修复花费的成本大成百甚至上千倍。而在有另外一双眼镜盯着你编码的时候，你肯定会不自觉地更加专注于编码，即便有了错误自己没有发现，也是有很大概率被你 pair 的人发现的，这样就在一定程度上保证了质量，一定程度上减少了维护出现麻烦的概率——其实这个质量原理也同样适用于看似浪费时间的 TDD -
www.infoq.com/cn/news/2007/07/Agile_Measurement
建议也同时看看这一篇。要精确计算成本收益本身的计算成本可能高得吓人，其实只需要定性的测量就足够作出选择了。其实用不着“优秀的程序员”，大家其实都有这种猪肉贵了就多吃菜的本能。要下功夫的是怎样把这种模糊的本能变成理性的分析吧。 -
在制造业，有两个相关的单词：lean 和 agile，代表的是截然不同的内涵。虽然在软件业目前使用的是agile，但本质上应当涵盖了这两个方面的含义。
lean的含义，Jeff所做的诠释非常精辟。agile，我认为更多地是为了真正实现最终用户导向制造的目的，即为满足市场需求变化提供最大之可能，而成本不是其首要考虑因素。
虽然lean和agile不是相互孤立的特性（就像敏捷开发的各个最佳实践不能孤立看待一样），但二者的侧重点还是有所差别的。 -
含糊器词,没有衡量的原则和标准,这个就是听起来很好,但是做的时候麻烦.这个方法听起来像银弹,我很想知道风险都那些,怎么处理?
5 条回复
关注此讨论 回复