敏捷开发促进技术与业务的协作.docVIP

敏捷开发促进技术与业务的协作 　　敏捷开发方法需要业务和IT人员之间不断交流。敏捷编程方法的基础是沟通。这种方法强调面对面的沟通，书面文档作为讨论要点。 　　基于对瀑布式开发方法的失望，越来越多的CIO开始关注并具体实践敏捷开发的方式，在开发过程中通过即时沟通，不断调整软件的设计和测试，以降低项目失败率。本期我们通过一组文章从基本概念到最佳实践对敏捷开发进行解读。 　　美国农场信贷服务公司（Farm Credit Services）听上去不像是一家会引来争议的组织。这家合作组织为美国中西部地区的6.6万余户农场主和牛场主提供贷款，以便他们有钱购买牛、猪、拖拉机和挖土机。该组织成立的目的主要是，向种养殖户提供110亿美元的经营资本和地皮融资。 　　但就是这样一家传统组织，恰恰采用了IT界争论最激烈的一种开发方法: 敏捷编程。 　　 　　敏捷开发的优点 　　 　　不同的人对敏捷编程有着不同的理解，不过所有敏捷开发方法的核心都具有以下原则: 业务 　　相关人员与独立的小型开发团队协调同步; 团队更多地依赖面对面交流，而不是前期需求和文档; 这种交流为软件设计和测试提供了不断调整的机会。 　　敏捷编程崭露头角还得益于IT行业的惨痛历史: 软件项目失败、成本超支，以及业务人员因而对传统的IT设计和开发方法，即瀑布方法（waterfall methodology）的不满意。按照瀑布方法，开发工作慢慢逐级通过一系列步骤，包括环境分析、设计、实施、测试、集成及维护。但由于诸多原因，并非谁都对敏捷编程有兴趣。据弗雷斯特研究公司的《2006年企业采用敏捷方法的状况》调查显示，实际上，只有17%的北美和欧洲企业在使用敏捷开发方法。 　　农场信贷服务公司之所以欢迎敏捷编程，是因为瀑布方法一直让这家公司很失望。农场信贷服务公司的CIO Dave Martin说: “我们拿来需求后开发应用软件，结果没人觉得满意。”有个项目是从基于大型机的客户应用处理系统迁移到名为PinPoint的基于Web的版本，需求居然超过了200页; 到2004年底，历时近三年才完工。在此期间，需求和业务需要一再变化，最初那个业务团队的成员大多已经离职。因而得到的错误百出的系统推出没过多久，就被搁置起来。 　　而这并不罕见。据敏捷联盟和Version One在2006年开展的《敏捷开发状况》调查显示: 调查对象称，只有29%的传统项目“有点成功”或者“非常成功”。反过来，调查对象称，获得这种成功的敏捷项目多达81%。 　　Standish Group以编撰软件项目失败方面的Chaos数据著称，它在2006年的研究报告中声称，成功的瀑布项目只有16%; 而成功的敏捷项目却达41%。Standish Group的主席Jim Johnson多年来一直在研究项目失败的问题，他说，许多公司就是抵制敏捷开发，这让他想不透。他说: “公司或者CIO不愿接受敏捷方法，好比他们不愿吃阿斯匹林治头痛。他们非但不吃阿斯匹林，还用头撞壁，嘴里还嘀咕为什么会痛。” 　　 　　走上敏捷之道 　　 　　两年前，Martin决定“改变现状”。得到两位应用软件开发主管的一番促动后，Martin的团队采用了Scrum: 迭代（Scrum中叫sprint）、日常会议、迭代评审及测试工作只用了两周的时间。他说: “我们提出的前提是，每两周就拿出可以交付的产品。” 　　农场信贷服务公司有六个开发团队，成员包括: 业务分析人员、项目领导人和首席开发人员各一名，两三名开发人员，数据库工程师，一到三名业务部门负责人代表以及一名质量保证工程师。开发团队编写项目开展过程中的“用户故事”，取代了许多需求，这些故事详细描述了业务功能的改进、技术、成功以及难题。Martin说: “用户故事是传达业务需要的主要机制。”农场信贷服务公司过去推出的每个瀑布项目平均有大约100个缺陷; 如今敏捷项目平均只有0到2个缺陷。 　　Martin说: “我们推出了五个关键产品，个个成效显著。我们的业务负责人每次都对最终结果欣喜若狂。” 　　 　　敏捷方法并非通用 　　 　　许多公司的CIO们说，他们已经抛弃了瀑布方法，或者正在逐步淘汰。美国五三银行CIO Raymond Dury采用了名为极限编程的敏捷方法外，他说: “我从不说‘18个月后我会向你交付一切软件’，早不兴这套了。” 　　但实际上，瀑布方法并没有销声匿迹。除了上面提到的弗雷斯特调查（只有17%使用敏捷方法）外，2006年3月针对《Software Development》杂志和《Dr. Dobb’s Journal》读者的调查发现，60%的调查对象根本没有使用任何敏捷方法。 　　如今CIO们在积极寻找项目管理方面的帮助，这恐怕并非巧合。据美