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

敏捷开发方法需要业务和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们在积极寻找项目管理方面的帮助，这恐怕并非巧合。据美国《CIO》杂志的最新调查显示，几乎四分之三的CIO读者表示对弄清楚如何改进项目管理方法“极有兴趣”或者“很有兴趣”。

显然，一个问题随之而来: 既然敏捷开发那么好，为什么还没有得到普遍采用呢？

敏捷开发的问题

软件开发的一套惯例深深地扎根于IT。就传统的瀑布方法而言，业务人员把需求告诉开发人员后，开发人员关起门来，按自己的思路开始编程。18个月的预定周期让人觉得时间多的是，虚度几个下午没什么。谁关心用户的真正需求？

Martin回忆: “许多IT人员以为，敏捷开发是昙花一现的东西。有些人就说‘我不会用它。’”他说，如今这些开发人员已被敏捷开发大潮甩在了身后。

弗雷斯特研究公司的应用软件开发高级分析师Carey Schwaber认为，反对敏捷方法的声音还会来自企业设计师、项目经理和质量保证人员。企业设计师担心: 敏捷开发方面没有足够的前期设计，结果会带来意大利面条式的代码（spaghetti code）。敏捷团队能自我管理，项目负责人的角色发生了显著变化: 从发号施令变成提供便利。又因为整个开发过程中都会进行质量保证测试，而不是开发结束后才进行，所以通常会遇到来自测试人员的阻力。

IT部门对敏捷开发仍然存在诸多误解。Eugene Nizker之前在一家金融服务公司当过CIO，目前担任顾问，他列举了最常见的误解: 以为敏捷团队不规划、不设计、不测试，敏捷就意味着没有文档。

另外，主管们觉得自己是敏捷开发工作的局外人，工作岗位岌岌可危。Scrum的开发者之一John Scumniotales说，这一切阻碍了人们接受敏捷开发。他说: “谈论用这种方式开发软件有什么价值，这很容易，但要是我把企业的命运都压在这个项目上，高级管理人员多少需要控制及了解这种开发方法。”他提到了需要专门针对敏捷开发的工具，譬如功能类似甘特图的工具，通过图表来显示项目进度。他说: “这是我们需要努力的方向。”

但考虑到瀑布方法接二连三地失败，CIO认为自己及所在公司有必要采用敏捷方法。五三银行的Dury说: “世界并非静止不变，再也不会等上18个月。”

案例调查: 让产品迅速上市

Dury没有抛弃所在银行的传统开发方法。他说，有些开发项目（如提供基本基础架构的项目或者庞大的SOA项目）根本“适应不了敏捷方法带来的那种急剧变化”。不过团队采用极限编程让他很是兴奋。

这家银行的零售产品线主管告诉Dury银行想销售一种新产品，这种名为Stock Power CD的投资工具可为存款单客户提供与股市表现挂钩的收益潜力。实际上，这家银行正在奋起直追。Dury说: “我们可能错失了这种产品的市场，但我们想进入这个市场。”因而，速度是关键。

开发团队使用极限编程方法，讨论了有望迅速满足业务需求、技术上又切实可行的解决方案。随后与零售银行业务部门进行了更深入的交流（主要是面对面交谈，很少有前期文档）。IT内部成立了两个开发团队: 投资顾问团队和存款单开发团队，它们与对方、消费者银行业务和零售业务部门通力合作。两个团队与最终销售Stock Power CD的银行附属公司和投资顾问紧密合作，满足法律和财务方面的要求。

极限编程涉及每天的碰头会、业务人员不断提供意见以及递归测试，让人觉得有一种紧迫感，要尽快为客户提供这项技术。首次交流后才过了四周，五三银行的几家附属公司就开始提供Stock Power CD产品。Dury强调: “推出一种新的存款产品通常需要大约90天到120天。这种产品还带来了其他许多存款。”他说，他无法想象再用别的方式来完成这个项目。除了让产品加快上市外，极限编程还促使IT人员与业务人员建立了更密切的工作关系，并且增强了业务人员对“我们有能力交付产品、满足预期值”的信心。

增强协作

正如Martin和Dury的故事那样，敏捷开发方法需要业务和IT人员之间不断交流。让业务和IT团队协调同步可以带来传统软件开发通常没有的亲密关系。Verizon Wireless公司负责美国中西北地区的CIO Ajay Waghray说: “业务人员与你在一条船上。要是情况不妙，他们会帮你一起抵达成功彼岸。”

没有采用敏捷方法的CIO说，改变与相关业务人员的关系会带来一些意料不到的结果。Waghray回忆，前不久与关键的业务和营销主管进行交流就采用了比较敏捷的方式。他说: “我告诉对方‘我不要任何需求。你要什么？尽管告诉我，我们可以谈谈。’主管们问道，自己要不要把需求写下来。我会说‘不要，别给我需求。’”他说，这种方式是人们不熟悉的。

Verizon Wireless的VZ Navigator产品在汽车转弯时，可以通过移动设备上的语音功能告诉用户开往哪里，它已成为这家公司最受欢迎的移动服务之一，这项产品就受到了敏捷方法的重大影响。Waghray的团队成员包括来自IT、销售、客户服务、市场营销、培训及人力资源等部门的相关方。团队的工作重点是，尽快开发出“最简单又完整的”解决方案，然后在此基础上开发更完善的解决方案。他说: “成功的原因在于，敏捷方法促进了相关方不断沟通及合作，因而不但开发了IT解决方案，还开发了培训文档和测试用例、确认及开发内外界面、促进与用户之间的沟通，以便为产品推出做好准备。”

对团队中的许多业务人员来说，结果令人震惊。他们告诉Waghray，结果这个项目从头至尾也就用了大约八周，原本需要三倍的时间才能完成。他这样评价敏捷方法:“它改变了企业文化和开发周期，我从其他项目得到的赞美从来没有比这个项目来得多。”

应对变化

由于敏捷团队本身就是迅速推动变革的独立小组，需要迅速做出关键的业务决策，因而曾经一成不变的项目管理法则发生了显著变化。因为瀑布项目通常需要18个月到24个月的开发时间，这次大大缩短至2周，每天的开发和每次的会话都至关重要。在Dury的IT部门，每天早晨先开团队碰头会，划分每个人当天负责完成的任务。

为敏捷小组的每个人设定新的预期目标: 配合、开放及协作是CIO的职责。农场信贷服务公司的Martin说: “现在要求彼此协作，你根本不能单枪匹马地工作。还要从新的角度了解工作，某些情况下，要了解工作以外的事情。”

不过，持抵制态度的团队成员极有可能发现自己会丢掉饭碗。敏捷专家Scott Ambler是IBM公司敏捷开发部门的业务主管，他猜想，许多开发人员、需求分析人员和数据及测试工作人员在担心: 敏捷开发会带来改变职业生涯的影响。

CIO的职责就是打消下属的焦虑，确保自己的团队致力于按时开发出具有成本效益的优质软件。Ambler说: “在敏捷开发社区，衡量软件开发项目进度的惟一标准就是交付实用软件。传统的开发社区却忽略了这点。”

为何众多CIO态度冷淡？

CIO和分析师被问及为什么那么多CIO对敏捷软件开发一直态度冷淡时，最常提到的一个字眼是怀疑。虽然他们对敏捷软件开发时有耳闻，也觉得不错，但2006年的《敏捷开发状况》调查显示，只有5%的调查对象提到CIO是敏捷开发方法的最初拥护者。奇怪的是，11%的调查对象提到总裁或者CEO在推动公司接受敏捷开发。

要是没有CIO作为后盾以及有影响力的相关业务人员给予支持，就得不到敏捷开发在软件开发及项目管理方面的时间和成本效益。弗雷斯特公司的Schwaber说: “要是公司里面没有副总裁或者CIO级别的主管在推动采用敏捷方法，就会遇到重重障碍。”在农场信贷服务公司，Martin推行敏捷方法的举动得到了CEO的注意及支持。他说，公司没有遇到障碍（除了跟上项目需求）。

敏捷方法甚至在公司的其他部门盛行起来。听说业务团队与IT部门一样每天也在召开站立会议后，Martin就知道这个举动是正确的。他说: “我们甚至使得业务部门问自己: ‘我们怎样才能更加敏捷？’”

Martin的敏捷开发之旅结局圆满。他从原先对敏捷开发一无所知的CIO，变成了敏捷开发的布道者，利用各种场合宣讲敏捷开发。他说: “我想不明白为何还要使用之前的瀑布方法。”（译自《CIO》）

链接

混合搭配效果更好

今年，新西兰梅西大学的三名研究人员着手研究敏捷开发是不是真的优于传统开发。而研究结果认为，前者确实优于后者，不过他们也发现，使用了不只一种敏捷开发方式的公司取得了更大的成功。

最有效的组合就是极限编程加上Scrum。他们撰文: “成功采用敏捷方法似乎未必就意味着选择某一种方法。事实上，考虑混合多种互补的方法可能更好。”

CIO、分析师和敏捷编程专家们建议: 从混合、定制的敏捷方法开始入手。Standish Group的主席Jim Johnson说: “我听到有人说，他们博采众长，形成了自己的敏捷方法。的确没必要迷信某一种方法，混合定制方法能够提高成功率、为利益相关方带来更好的产品和服务。”

美国最大的财产和房地产数据提供商First American CoreLogic公司的工程副总裁Scott Spencer在公司使用敏捷方法差不多已有三个年头。Spencer领导的12个开发团队分布在全球。这些团队都采用了Scrum，不过他同样进行了定制。他说: “我没听说过有谁纯粹用Scrum或者纯粹用极限编程进行开发，这很难。”譬如说，Scrum中没有什么项目经理概念。不过Spencer派一名员工担当类似项目经理的角色（名为Scrum管理者），该人与开发团队开展了更有效的合作。Spencer说: “必须让敏捷方法适应现有的组织需求。”