2007年08月22日 08:30:42
熊节：理解敏捷核心 做更成熟的开发者
|
【CSDN】很多人问我一个问题：究竟敏捷的核心是什么？在我看来，敏捷就是软件行业里的精益（lean）生产，它的核心是消除浪费。敏捷的众多实践可以大致分为两部分，一方面致力于持续改进质量，另一方面致力于创造团队内部和团队与其他涉众之间有效的交流环境。因为大量的经验表明，软件项目的浪费大部分由于两个原因：质量低下，交流不畅。敏捷的实践正是着眼于消除这两方面的浪费。 首先考虑质量问题。一些软件企业为了降低成本而忽视质量，但质量低下的软件会造成返工的浪费，反而提高成本。相反，在日常工作中投入更多的精力来保证质量，反而能够为企业节约成本。ThoughtWorks中国公司技术总监Michael Robinson曾用软件工程的经典理论来分析这个问题： 任何一本软件工程教材都会告诉你：假设在分析阶段找到并解决一个错误的成本为1，在设计阶段解决同一个错误的成本就变成10，在实现阶段就变成100，在维护阶段就变成1000。敏捷软件开发中的众多实践正是为了避免低质量和返工的浪费。尽管它们一开始看起来似乎有些麻烦，但它们带来的收益是实实在在的。 另一种常见的浪费则是“为将来准备的投资”。例如为了应付将来可能出现的需求变化而提前引入的灵活设计，如果需求没有发生变化，这些灵活设计就会成为浪费：不仅浪费了将它设计出来的成本，而且浪费了继续维护它的成本。制造业为了降低库存成本而创造出“Just In Time”的生产和决策方法，ThoughtWorks中国公司总经理郭晓认为这些方法同样适用于软件行业： 如何消除预测错误的浪费？避免预测错误的根本办法就是推迟决策：决策下得越晚，就越不容易因为预测失准而造成浪费。当然也不能晚到错过了时机、耽误了工作才下决策，这就像丰田制造的Just In Time，决策也要Just In Time。过早的、含有太多预测成分的决策也会造成浪费，其危害丝毫不亚于过晚的决策。 畅通的信息渠道，清晰的成本/收益核算，全面消除浪费，这是精益制造的核心所在，也是敏软件开发的核心所在。 说完敏捷的核心，不妨把话题延伸一下。有位记者问我：在我国的背景下应该如何理解敏捷？但我的看法是：敏捷无国界。中国的软件业越来越多地面临来自全球的竞争，就连中国的软件开发者也越来越多地面临来自印度、越南、马来西亚等地的开发者的竞争。大家都用同样的编程语言开发软件，遵循同样的市场规则做生意，在这样的情况下过于强调“中国特色”、“中国的情况”可能不会是特别有意义的想法。 如果说敏捷在国内的实施和推广并不理想，我认为原因只有一个：国内大部分企业的竞争压力还没有大到一定程度。这当然是好事，但压力迟早会来。实际上已经有很多软件企业和开发者意识到了这种压力，在刚刚结束的第二届“敏捷中国”软件技术大会上，很多企业和个人——尽管还没有开始真正实施敏捷——已经表现出了对敏捷的极大兴趣。这种“关注多、实施少”的现状在我看来不是“雷声大雨点小”，而是“山雨欲来风满楼”，是大家已经真切感受到了即将到来的竞争压力，在为提升自己的竞争力而做准备。同样的情况5年前在北美发生过，3年前在澳洲发生过，我相信——或者说已经看到——现在轮到了中国。 基于同样的道理，“敏捷并不适合中国”这种说法显然是站不住脚的，因为那就等于是在说“消除浪费并不适合中国”或者“提升竞争力并不适合中国”——显然这不是事实。照我理解，支撑这种说法的依据不外两方面：第一，很多中国企业目前还不需要如此高效地消除浪费；第二，很多中国企业不具备如此高效地消除浪费的能力。但正如我前面说过的，竞争的压力会让有效消除浪费的能力变得更加重要；而在那个时候如果一家企业仍然不具备这种能力，结果恐怕不容乐观。所以对于有远见的软件企业、对于有远见的软件开发者，这两条论据根本不足以支持“敏捷并不适合中国”的论点。 任何“中国特色”都架不住同一个事实：有效控制浪费等于赚钱；赚钱等于生存——即便是靠中国特色的关系获得订单，即便在竞标过程中玩遍手段，盈利仍然等于收入减去成本。为了控制浪费，泰勒在伯利恒钢铁集团采取的做法是在铲煤的工人背后架起高速摄影机，从每个动作的细节入手持续改进工作效率。而尽管软件行业一直在说“工程化”，但类似的对细节浪费的发现和控制在大部分团队中并没有落实。随着竞争的不断加剧，软件业的敏捷就像制造业的精益一样，无可阻挡，因为无法有效控制浪费的团队将被残酷的竞争淘汰。 从“消除浪费”这个出发点也不难看出，敏捷并不像很多人理解的那样，是技术人员的事情。我有个朋友在blog里提出一个观点：敏捷开发不仅仅是程序员喜欢的工作方式，而且是老板的最爱。他还分析了几个敏捷实践： 结对编程——最有效的相互监督机制 显然从这些实践中受益的不仅仅是程序员个体，而是整个团队、整个企业。通过消除浪费、提高工作率，开发者个人能够更有效地提升自身竞争力，同时为企业创造更大的价值，这是一场双赢的游戏。结对编程——最有效的内部培训机制 测试驱动开发——最有效的质量保证体系 User Story＋客户现场办公——最低成本的需求收集、分析机制 每日集成——有效降低集成、测试成本 对于开发者自身来说，“Be agile”常常意味着在技术选择中采取中庸之道，了解、使用多种技术，而不是偏执于自己喜爱的技术。深层的原因是边际效用递减律：对一个方面的东西重视到一定程度以后，再加入更多的重视，收到的边际效用递减；同样的重视度放到另一个方面上，能够收到更大的边际效用。让每一分投入收到最大的回报，尽可能地消除浪费，这是精益的追求。而技术偏执，例如“J2EE优于.NET”（或者相反的版本），容易让人忽视对边际效用的衡量而造成浪费——找不到投资回报率最高的解决方案。 成为一个更敏捷的软件开发者，很大程度上也意味着成为一个更成熟、更有责任感的软件开发者：着眼于创造价值，致力于消除浪费，而不是单凭兴趣来编写程序。敏捷的核心思想对于企业和开发者个人都是同样适用的。 本文作者熊节。 熊节是http://www.thoughtworks.com.cn公司的咨询师。目前正在从事Ruby on Rails的项目，并致力于敏捷方法与思想的推广。个人BLOG地址：http://gigix.thoughtworkers.org 2003年与侯捷先生合译了《重构：改善既有代码的设计（中文版）》 2004年翻译了《设计模式精解》 2004年翻译了《与熊共舞：软件项目风险管理》 2005年与刘天北合译《J2EE核心模式（原书第2版）》 2005年与JavaEye团队合译了《J2EE Development without EJB 中文版》(荣获2005年十大计算机好书之一） 2006年审校了《应用Rails 进行敏捷Web开发》（获得2006年Jolt Award 大奖） Tags：
敏捷
|
一共有 1 条评论