`
zhouxing
  • 浏览: 207637 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论

敏捷的核心:消除浪费,走向精益(转载)

阅读更多

作者 Jeff Xiong 发布于 2007年7月4日 上午2时18分

社区
Agile
主题
企业级敏捷
敏捷的核心是什么?敏捷给软件企业(以及软件开发者个人)带来的好处究竟在哪里?这个问题有很多不同的答案。例如“重视个人和交流”,软件开发者喜欢这样的态度,这是毫无疑问的。例如“重视可工作的软件”,它的价值是显而易见的。但在这一切的背后,敏捷的核心是什么?时下流行的观点是:敏捷就是软件行业里的精益(lean)生产,它的核心是消除浪费。ThoughtWorks中国公司的高层在近日接受采访时明确指出了这一点。

首先考虑质量问题。一些软件企业为了降低成本而忽视质量,但质量低下的软件会造成返工的浪费,反而提高成本。相反,在日常工作中投入更多的精力来保证质量,反而能够为企业节约成本。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将会支持和推动这一切工作。
畅通的信息渠道,清晰的成本/收益核算,全面消除浪费,这是精益制造的核心所在,也是敏捷软件开发的核心所在。
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics