大师讲述如何使敏捷开发成为主流

转自 http://blog.vsharing.com/agiledo/

使敏捷成为主流

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

统一散乱的敏捷过程景象

敏捷开发是随着它的声望而增长的，敏捷过程的数量也是如此。这些包括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相关的观念反应了敏捷价值，一个公司在奖赏和提升它的员工时清楚地说明它所想要的赖于生成的价值是十分重要的。 4 为了使敏捷开发变成主流，我们需要更好地阐述必需的HR变更以及如何实现它们。

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

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

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