使敏捷成为主流：跨越断层

2010-08-26 作者：Per Kroll　来源：IBM

本文内容包括：

主流公司正在寻找安全的赌注
应对大规模公司转变
大规模以及合作开发问题
结论
注释
参考资料

本文来自于 Rational Edge：虽然敏捷开发的实践已经成功地运用了很多年，但是大多数软件开发公司仍没有采用这些技术。在本文中作者探究了其中的原因，描述了将推动敏捷在这个行业里朝着更能让人接受的方向发展的趋势。

尽管在过去的几年里众多软件项目的结果有所改善，但是 Standish Group 的 Chaos Report 告诉我们其中 72％的项目都失败了或者遇到了困难。 ¹ 进一步来说，所实现的特性中有 45％从来没用过，19％很少用到。最让人失望的是，许多能促进获得更多成功项目结果的软件开发实践很少被采用。这些实践中有很多都属于敏捷开发的范畴。

图 1. 绝大多数实现的特性从来没有或者很少被使用到。

敏捷开发已经被有效地使用了很多年，即使项目结果很有希望，敏捷开发的采用也主要限制在公司内部。最近，采用敏捷开发的行业已经开始增加，比如保险行业，电信和金融服务领域，但是为了使敏捷开发变成主流，还需要主要产业积极参与者的支持，散乱的敏捷景象需要被统一起来，敏捷的转变需要是逐步演进的而不是革命性的。我们需要对大规模敏捷转变提供良好的支持，包括大规模的知识改变，处理必要的 HR 政策，以及可扩展的敏捷工具构架。最后，我们需要处理大型公司所涉及的开发问题，包括大规模的开发项目，地域分布式开发以及遵从性。让我们看看那些有希望的工作在每个区域所发生的事件。

主流公司正在寻找安全的赌注

在 Crossing the Chasm 一文中， ² Geoffrey Moore 指出，对于一个产品来说，从“流血的边缘”，早期采用的技术，转变为有更广泛的市场接受度，需要吸引大批逐渐增加的消费者。主流组织将寻找他们认为安全的可能性，而不是进入未知领域去冒风险。他们将站在市场领导者一边而不是最火热的技术一边，他们会寻找持续的改进而不是激进的范式转换。

思考一下 Moore 的观察报告是如何与建立敏捷开发主流联系起来的：

主要产业积极参与者的支持

一个家庭手工行业的积极参与者已经进入了这个敏捷市场，包括一些服务公司，比如 Object Mentor，Mountain Goat Software，Net Objectives，Quadrus，以及Industrial Logic，还有一些产品公司，比如 Rally Software Development 和 VersionOne。这些公司大多数都只有不足一百的员工。直到现在，还是缺少主要服务公司和产品公司的出现。这就是我们所谈的转变。

例如，世界最大的系统集成商最近在敏捷开发商投入了经多的精力。IBM Global Business Services 刚刚运行了一个 Accelerated Solution Delivery Practice，聚焦于敏捷开发和敏捷转变，Capgemini 正在为敏捷开发投资一个加速的交付平台，甚至一些印度系统集成商也在这么做，比如Cognizant和ITC Infotech India正在朝敏捷开发发展。

绝大多数投资商都投资于敏捷工具和过程。IBM最近已经预言了下一代技术平台支持的JAZZ，此外，还有敏捷和协作开发。Microsoft最近为发布了MSF，一个敏捷过程。IBM、Telelogic、 Covansys,、Capgemini以及其它大大小小的15个公司正在合作开发Eclipse Process Framework (EPF)， ³ 一个以敏捷过程为主的开放源代码组织。

统一散乱的敏捷过程景象

敏捷开发是随着它的声望而增长的，敏捷过程的数量也是如此。这些包括XP、Scrum、OpenUP、AUP、DSDM、Lean Software Development、Adaptive Software Development、Rational Unified Process (RUP)、MSF、FDD、Crystal Clear、EssUP，以及Agile Modeling。

这些项目中有很多都仅仅覆盖了软件开发生命周期的某些方面。例如，Scrum只覆盖了项目和需求管理方面，还需要与其它过程集成来完成整个生命周期，比如XP和Agile Modeling。集成不同的过程非常困难而且耗费时间，主流公司都不愿意承担这些投资。

然而，EPF项目解决了这个过程集成的问题。EPF是一个为软件最佳实践提供设计，配置以及开发平台的开放源代码组织。这个项目在今年初期就已经开始，许多前端的敏捷过程已经或者都将会在EPF内部获得，包括OpenUP、XP、Scrum、DSDM，以及 Agile Modeling。

我们希望在EPF内部权衡所有这些敏捷方法，最后开发可重用的敏捷过程的组件，这些组件能够组合在一起开产生不同的敏捷过程，比如OpenUP，XP，以及 Scrum，或者产生你们自己的敏捷过程。公司应该能够增添或者修改过程组件，在内部使用它们，或者使它们能够免费使用或者出售。

逐步演进的还是革命性的？

敏捷开发经常以范式转换的方式出现——对很多公司来说是一个令人恐慌的建议。敏捷转换可以是一个持续的过程。您可以在每个季度转变额外的项目，并且每次您都可以进一步学习和改善您的转变过程。每次您还可以引进一些实践。比如，您可以以迭代和测试驱动开发开始，然后可以遵循成对编程和配置团队的原则。

有些敏捷实践，比如自我组织的团队，代表了真实的范式转换。允许团队成员影响结果的确定和让团队成员们真实地支配他们自己的工作和命运有很大的区别。当一个团队遇到难于抉择的问题时，团队成员向他们的经理求助，经理回答说,“我要出去喝杯咖啡，告诉我你们的决定。”这让人们对谁是决定者的理解有了根本的转变。这样能够将合作与动机引到一个新的水平，通常对生产力有根本的促进作用。

我们还需要清晰地说明敏捷转变对公司的因素产生了什么样的影响，需要承担什么义务。如果您没有做好重访的准备，比如，您怎样处理测试，您怎样激发并奖赏员工，您的IT公司与您的业务流程线是怎样联系起来的，以及您拥有什么样的工具框架，那么您就不会拥有全面的敏捷转变。

应对大规模公司转变

您可以通过一个熟练的敏捷教练，对适当的人进行填鸭式教育灌输信息，而转变这个十人工作的方法，但是转变一个几百人的公司同样需要一个可靠的框架。让我们看看一些需要处理的问题。

大规模的知识转变

由于Industrial Logic要完成一个在Kronos拥有600员工开发团队的敏捷信息转变的任务，它意识到仅仅依靠几次训练是不可能做到的。为了帮助转变关于XP的基本知识，这个团队构建了一个基于网络的训练课程，它允许这些训练专注于团队进行XP实际运用训练的高附加值的活动。EPF和IBM Rational Method Composer通过交付电子化的知识来对这个范式进行进一步研究，并且这个交付要以允许采用的公司和团队易于修改的方式来表示。这样促使了知识大规模的转变，同时允许这些知识被修改以适合单个项目的环境。从我们的经验可以知道，大规模的采用，需要用电子方式转移知识来补充传统的训练模式，无论是通过网站训练、过程指导、教学指南还是其它的方法。

改变HR政策

敏捷开发对传统的HR关系一直持有一些不同的观点，比如雇员的激励与报酬，职业路线以及职责。我们需要在执行必要的变化时，及早从HR部门和管理者那得到支持。

敏捷开发需要在一群视其他人为自己伙伴的人中建立紧密地合作关系，它可以联合团队的领导阶层来改变这个动态关系。通常，在较大的公司中，一个职位的晋升（比如从开发人员到构架师）意味着这是逃离编写代码这种地位低下工作的方法。但是这些公司需要专门的并且有经验的人充当他们团队中领导角色的导师，而不是挣得了适当的工资而坐到了一定的位置的监管者。

对合作的重视还改变了您怎样奖赏和衡量人的方式。衡量一个人不仅仅是评价个体生产力，您需要权衡个体为团队所带来的价值。最有价值的团队成员通常只有较低的个体生产力，因为他们花费了大量的时间来指导他们团队成员。

这些与HR相关的观念反应了敏捷价值，一个公司在奖赏和提升它的员工时清楚地说明它所想要的赖于生成的价值是十分重要的。 ⁴ 为了使敏捷开发变成主流，我们需要更好地阐述必需的HR变更以及如何实现它们。

提供一个可扩展的工具框架

一个关键的敏捷原则是，对个体和合作的关注要多于对工具的关注，也因此可能会造成这样的结果，许多敏捷导师对工具有敌对的态度。然而，工具框架能够为协作带来很大的便利，并且对制作敏捷主流也有很关键的作用。事实上，一些传统的工具可能对敏捷开发并没什么益处，还可能约束有意义的合作。但是还有一丝希望——一个正在被开发的下一代工具，主要关注于软件开发的协作方面。

VersionOne 和 Rally Software Development 已经运行了敏捷项目管理工具，为核心敏捷概念提供支持，比如速率、迭代计划、规模以及研究计划评估，以及可以在一两天或者更短的时间内将工作分解成很小的单元。IBM Rational 与 IBM Research 最近协作预演了科技代码命名的 Jazz，它超出了当前的敏捷项目管理的解决方案来包含敏捷开发支持，增加了敏捷概念，比如团队合作、透明开发、持续集成，以及测试驱动开发作为第一类市民。Jazz还是可定制的软件，能够被修改而支持不同的过程。

大规模以及合作开发问题

为了使它变成主流，敏捷需要处理面临大型公司的问题，比如对地域分布式开发的支持，大规模开发以及法规遵从性。当前的敏捷解决方案不能对这些问题清晰地阐述，所以这需要改变。

较大的团队和公司

许多敏捷过程对于很多较小的团队或者少数拥有高度熟练技术的开发者有明确的目标，但是为了处理大型团队需要提供更多的经验和指导。对较大团队的支持已经在对过程的开发中了，例如 XP、Scrum、OpenUP、RUP，以及Agile Modeling。 ⁵ 例如，IBM目前正在对RUP进行分解，使其被构建成一套的OpenUP的扩展。这将为领域增加导航，比如SOA、遵从性管理、地域分布式开发，以及对敏捷核心过程的打包应用开发。

地域分布式开发

对绝大多数较大的开发公司来说，地域分布式开发已经变成了生命周期中的一个麻烦问题。但是面对面的通信却是敏捷开发的一个核心原则。公司能够通过改进实践的组合补偿共享实际项目的空间， ⁶ 比如不同团队间对工作更有效的分配，以及改进的支持框架。Jazz技术提供了团队意识，允许团队清楚地看到谁在场以及他们在做什么。各种技术比如即时消息允许这个工作环境中的协作。Jazz源代码控制系统，使开发人员能够很容易地交换设置，并增强意识对坏掉的版本提供即时的反馈。目标是权衡技术来创建一个合作的团队，尽管团队成员可能相隔很远。

遵从性

遵从性意味着 说您所做的， 做您所说的，并且展示您所做的。这与敏捷开发是不一致的，而且有一些困难需要克服。

首先，这个敏捷团体需要克服对文件编制过程固有的恐惧感。敏捷团队应该不断地改进过程，从而确保它能够为他们服务，但是这种恐惧在您编制过程的时候变得更加难于改变。EPF和RUP通过将一个实践丰富的引用库，与这个团队是如何选择到他们特殊项目中工作的简洁描述分离来解决这个问题。我们没必要为了重大的变化而精心制作过程指导，相反，团队会为参考资料改变他们简短的过程描述和相关的指示。2007年，EPF将会增加Wiki技术使得这些变化更加容易，从而确保团队对他们过程的所有权。

其次，团队需要避免非生产性工作来“向你们展示应该这样做。”IBM Rational的经验告诉我们，自动操作允许必要的信息被保留，因此您不需要或者仅需要少量的额外工作就可以通过审计检查。

结论

敏捷对软件项目的成功率能产生重要的积极影响。为此，敏捷开发将克服许多困难，从而变成主流，但是我希望在2007年有巨大的进步。主要的SI和厂家都在投资敏捷开发，EPF能够使分散的敏捷过程前景统一化，敏捷转变很有可能成为一个过程逐渐呈现在我们面前，而不是“全有或者全无”的策略。专门为构建敏捷开发的工具也开始出现了。很多工作需要在遵从性、对大规模敏捷开发的支持，以及地域分布式开发的领域来完成，但是在这里我们看到了新兴的实践和支持框架，它们有助于发展敏捷开发主流。总之，我们对2007年充满希望，在这一年里敏捷开发将跨越断层成为主流开发组织。