捷方法学家Scott W. Ambler：敏捷最困难的地方是变通。在一个10人团队中实践敏捷，与在成百上千人团队中是很不一样的。不仅如此，影响延展性的因素还体现在其他方面。比如，人们如何在受管控环境下实践敏捷；又比如，如何在复杂领域里实践敏捷。
记者：能否介绍一下您目前所从事的工作以及关注的方向？
Scott： 我目前的主要工作是帮助企业理解敏捷。Disciplined Agile Delivery是我近期关注的一个方向，它主要讨论的是如何从项目启动开始，到产品成型，再到系统交付的整个软件生命周期里进行敏捷开发。其中涵盖的内容要比我们通常在主流敏捷社区中所见到的方法学还要多。像Scrum、XP 这些主流的敏捷技术都是相当不错的，但是它们并没有涉及软件开发全生命周期的方方面面。
如何启动项目、如何将功能特性加入产品、如何建模、如何解决数据库问题，这些内容在上述方法学里都没有提到，企业只能自己去找寻这些缺失部分的答案。Scrum有意将自己说成是一种过程框架，所以许多内容都没有提到，这是它的一种策略。
此外，我们在Disciplined Agile Delivery的基础上进行了扩展，称之为Agility at Scale，这也是我目前的另一项工作。它主要解决的是如何将敏捷技术运用于不同跨度的团队。因为，在一个10人的团队中实践敏捷，与在成百上千人的团队中是很不一样的。不仅如此，影响延展性的因素还体现在其他一些方面。比如，人们如何在受管控的环境下实践敏捷；又比如，如何在复杂领域里实践敏捷。一些讨论敏捷的书里讲的都是些非常简单的系统，而构建一个飞行控制系统与构建信息网站在复杂度上是不一样的。所有这些潜在因素，我们都需要考虑。
记者：根据开发者的反馈，敏捷方法在中国推广的时候会遇到一些困难，由于它导致原来项目管理模式的改变，以致公司的领导往往不愿意引进这样的开发模式。您对这一问题怎么看呢？
Scott： 在企业里推广敏捷很大程度上会触及到企业文化的变革，包括工作内容和性质的重新界定，人与人之间协作方式的改变，这其中直接受到影响的一类人就是项目经理。不过如果你注意到，和以前相比，这样做可以让开发人员更好地制订计划，评估工作量，那么这就是一件好事。开发人员是最适合完成这项工作的，因为我们都知道，具体实施者才是计划和评估的最佳人选。
所以如果你想获得更准确的信息，更可靠的计划和评估，那么这样做是再合适不过的。但这对于那些过去做这些工作的项目经理而言会是一个威胁。因此，在敏捷团队里，我们希望管理者所关注的是团队的领导职能和教练职能，而不是纠缠于技术问题。我觉得任何组织如果要想获得成功，变得更加高效，他们就需要寻求方法对管理人员重新进行培训，要求他们把精力放到更为重要的工作上去，对企业而言这将会是一个挑战。你会发现，任何一家在各自领域里处于领先地位的大型企业，都需要花上几年的时间才能完全变得敏捷。
实际上，这是人们在以后几年的职业生涯当中必须要跨越的一个坎儿，因为人总是希望自己变得更好，变得更有效率，所以总有机会可以让你有所改善。在一个行业里能够成为领头羊的企业只有一家，其他公司都只能在后面追着跑，所以它们需要不断改进，即便是领头羊也依然有改进的余地，这个道理很有意思，你总可以变得更好，意味着你总是在变化之中，总是在改进之中，这是一个长期的过程， 但是方向没错。
记者：很多时候我们提到敏捷都是在谈技术问题，对于业务人员和管理人员，如何向他们推广敏捷方法呢？
Scott： 我们会发现，很多敏捷技术都是针对技术人员的，并且在他们中间很流行。但是业务人员和管理人员并不关心技术，他们关心的是商业利益。当面对这一类人的时候，我时常会给他们列举敏捷所带来的一系列好处，比如，相比传统团队，敏捷团队更有可能交付高质量的代码，这是因为他们会做更多的测试和重构，工作起来更有纪律；敏捷团队更有可能交付客户想要的功能，这是因为他们与客户贴得更近，他们以增量迭代的方式工作，定期发布可用的软件，每隔几个星期就给客户展示新的功能，并从客户那里得到反馈。这些我觉得对业务人员而言是很有吸引力的，因为他们可以看到工作在有条不紊地进行着。
而在传统团队里，软件开发对业务人员是不透明的。人们会在项目初期花大量的时间去写需求文档，然后签下合同书，承诺日后要交付的东西，而用户事后又经常会改变想法。采用传统工作方式的IT项目时常会超支，业务人员会因此而感到沮丧。反观敏捷团队，由于人们可以看到项目实际的进展情况，所以能够更好的对项目进行把控。敏捷团队的交付速度通常会更快，效率也更高，因而成本投入也更划算。这些是我们能够从调查数据中看到的。
还有一些 学术研究成果也表明了敏捷的业务价值，David Rico在他最近写的一本书中就谈到了敏捷开发的经济效益。所以，技术人员如果要想说服管理层采纳敏捷，那就不要和他们讲测试驱动、敏捷建模、数据库重构，管理人员并不关心这些，他们关心的是如何投资，如何提供用户真正需要的功能，只要和他们谈这些，通常都能够获得管理层的支持。
记者：在您为不同公司和团队提供敏捷咨询的过程中，您认为最困难的地方在哪里？
Scott： 我们得承认，组织与组织之间是有差异的，即使遵循同样的原则，具体行事方式也还是会不同的。而且即使在一家公司里，每个项目的情况也不尽相同。比如在 IBM，DB2团队的情况就和WebSphere团队不同，它们和Jazz、Lotus Connections团队也都不同，因为它们做的产品不同，人员不同，地理分布不同，面对的客户也不同，因此每个团队采用敏捷的方式都不相同，关注点也不一样。这对你来说可能是一个挑战，因为当你在为这些团队提供支持，帮助他们实施敏捷时，你需要具备足够的智慧和灵活性，以便帮助团队采用不同的方法，在不同层面，以他们认为最合理的方式来实施敏捷。因此我认为，作为企业应该要意识到，一旦他们选择了敏捷，就需要懂得变通，没有唯一的标准答案，而且这是要花时间的。
记者：您觉得做什么样的产品或者应用，适合敏捷开发呢？
Scott： 我认为一个项目如果软件介入得越多，应用敏捷的机会也就越多，因为许多敏捷技术都是专门针对软件开发而设计的。每个领域都有其特殊之处，银行软件与航空软件当然不一样，它们有特定于各自领域的问题需要解决。但是我认为领域并不是问题，你可以将敏捷应用于银行业、制造业、零售业等许多领域。比如和传统软件方法相比，敏捷方法鼓励更多的测试，任何领域的应用都可以从中获益。
不论什么领域，这都是值得去做的，它给人们带来了改进的机会。实施敏捷的真正困难在于企业文化，你是否知道变通，是否希望改善，是否愿意改变，这才是真正的问题所在。我在全球许多地方拜访客户，帮助他们解决问题，我看到了许多领域都在应用敏捷，从医药到银行，从制造到零售。
我们还在系统工程领域规划实施敏捷，比如，我的一位同事Bruce Powell Douglas最近写了一本新书，叫做《Real-Time Agility》，讨论的是如何在极端技术环境下（如开发飞行器或空间卫星）变得敏捷，我想这是一个非常有意思的领域。
记者：您刚才谈到IBM有很多敏捷经验，IBM在敏捷开发方面，最近有哪些新的进展？能否谈谈敏捷开发在IBM内部项目开发中的应用情况？
Scott：IBM 内部的敏捷推广还在进行当中，实际进展情况非常不错。我们在全球范围内有38万名员工，要对如此庞大的一家企业实施改造是很有难度的。IBM还是一家跨国企业，在世界各地有许多分支机构，它们各自采用敏捷的方式不尽相同，这也在情理之中。
我们有内部的敏捷推广活动，对大家实施培训，提供指导，帮助人们理解变化本身，以及怎样变化。这些工作已经开展一段时间了。事实上，本周我来到这里，就是给中国开发中心的同事进行培训。我觉得这很有帮助，我在全球范围内做着这样的工作，效果很不错。
在今年和去年芝加哥的敏捷大会上，IBM负责软件过程改进的副总裁Sue McKinney和与会者分享了我们的一些推广经验，还有统计数据，通过数字我们看到了生产力在提升，质量也在提升，我们正在创造更多的人均收益，这正是我们想要的。当然一切还在进行当中，我们还有许多年的路要走。
记者：IBM除了内部实施敏捷，对外是否还提供敏捷服务呢？
Scott：我们也为客户提供咨询，其中一项服务叫做MCIF，其全称是能力度量改进框架（MeasuredCapability Improvement Framework），主要目的是为企业识别改进，并帮助实施。其中包含了两个方面：首先是评估，我们会有一些资深的咨询师和企业一起，帮助他们了解业务目标，识别挑战和困难，找到解决方法，并确定采用哪些敏捷实践。
MCIF不仅包含敏捷，还涵盖了传统方法。尽管MCIF里有相当一部分内容和敏捷有关，因为敏捷实践往往更加有效，但一些企业依然可以从其中的一些传统实践当中获得益处。我们也在帮助一部分企 业采用这样的实践，帮助它们改进，而不是一味地把它们都变得更加敏捷。
MCIF 的另一方面同样也很重要。单单做一下评估还是很简单的，问题是大多数评估实际上最终都并不成功，尽管每个人都声称自己是成功的。他们有非常像样的评估报告，很棒的改进方案和改进建议。于是所有人都被忽悠了，都认为：哦，是的，我们会实施这些改进。可是一个月下来，评估报告被束之高阁，那些很棒的建议都被人遗忘了，大家依然因循以前旧的工作习惯。为了避免这些情况，MCIF的第二部分就是要帮助人们实施改进。
敏捷中有一项实践被称为“回顾”，项目团队定期花上几个小时来回顾过去的成绩和存在的不足，以此来决定团队下一步应该如何改进。我们有一个产品叫Rational Self Check，是MCIF的一部分，它用来帮助企业跟踪这些改进。因为我们发现，在IBM内部，经常作回顾的团队，在提高生产力方面，要比不作回顾的团队表现更好。我们还发现，这些团队如果对改进做了跟踪，表现还会更好。我们将这些方法用于客户已经有很长一段时间了，同样也获得了很好的效果。
记者：据我所知，IBM Rational的Jazz/RTC最近很流行，您觉得它们有哪些特点，是否适合敏捷团队使用呢？
Scott： Jazz 对敏捷团队而言是一个非常值得关注的平台，当然它对传统团队也一样很有帮助。首先，它能够有效地改善团队协作，尤其是当团队成员不在一起工作的时候。敏捷 社区讨论更多的是在一起紧密工作的团队，大家都在一个办公室里自然好，但现实是，只有少数团队才属于这种情况。
人们有可能工作在不同隔间，不同办公室，不同楼层，不同大楼。这种情况下，许多主流敏捷技术就不那么好使了：在分布环境下，我们很难再把需求写到索引卡上。在白板上建模尽管很值得去做，但在分布环境下却难以施行。而Jazz帮助人们解决了这些问题。
其次，Jazz还帮助解决了工具的集成问题。尽管敏捷社区时常在讲“个体和交互胜过流程和工具”，可人们还是要在工具上花很多工夫。因为大家经常要用到一些开源产品，这些工具种类繁多，把它们集成起来需要花很大的代价。Rational Team Concert（RTC）内置了许多常用工具，比如，配置管理，持续集成，协作工具，以及需求管理工具。因此你不用再做额外的事情，只要下载安装，所有工具都已经很好地集成在一起了。
由于工具已经被事先集成和配置好了，所以当你在使用Jazz的时候，特别是其中的Team Concert、Requirements Composer以 及Quality Manager，这些工具会自动把你的行为记录到数据仓库，然后为团队生成出许多重要的数据指标，并以仪表盘的形式呈现出来。项目经理 可以通过仪表盘了解项目的进展状况，包括：系统构建的统计、缺陷走势、燃尽图等，所有这些都是自动生成的。
对开发人员来说这是一件好事，因为它可以省去手工完成这些工作所花的代价。一些在Scrum和XP中谈到的技术，比如燃尽图，如果手工去做工作量会很大，也很繁琐。我们可以把它自动化，并实时进行精确跟踪。假如我是项目经理，我会很欢迎像Jazz/RTC这样的工具，因为它们对于我实施项目管理很有帮助。
另一个和RTC有关的概念是协作应用生命周期管理（Collaborative Application Lifecycle Management，简称 C/ALM），它把一些很重要的工具真正整合到了一起，并鼓励人们彼此之间协作和交流，从而减少了不必要的手工操作，还有人与人之间在协作上的“内耗”， 使生产效率得到了提高，这一点是应该值得人们注意的。大家可以访问jazz.net网站，下载不同版本的RTC，RTC提供了最多可供10人规模团队使用 的免费版本。
关于jazz.net还有一个有意思的地方，那就是你可以看到Jazz团队自己的项目仪表盘，它是动态生成的，这个项目是完全开放的。如果你想知道 Eric Gamma今天正在干些什么，不妨登录到jazz.net上去看一看。看看你从仪表盘上能够得到的信息，然后再问问自己，如果手指轻轻一点就可 以得到所有这些和自己项目相关的数据，项目管理是不是会变得更容易一些呢？所以我想，对于许多企业来说，这是一个非常值得关注的平台，我也建议大家看一看 这个平台，考察一下它对你是否有价值。
记者：谈到工具我有一个疑问，很多人理解的敏捷，是不需要建模、工具、框架之类的东西的，对此您怎么看呢？
Scott： 大约在一年前我做了一项有关建模和文档的调查，想看看人们到底是怎么做的。结果在调查中我们发现，敏捷社区中大多数人都在做建模，并且和传统团队相比他们更倾向于建模，只不过大多数时候人们是在白板和纸上建模，这一点事实上让我感到很惊讶，它不是我原本所期望的结果。又比如，敏捷社区总是在说用户故事，这项技术很不错，可那也是模型。所以，在敏捷社区里有人说他们没有建模，这显然是个错误。
我曾经在全世界范围内拜访过一些团队，一些人站在白板面前说他们从来不做任何建模，可是白板上却明明画着数据模型。于是我问：这是不是你们画的。他们说：是的，哦，这就是模型。所以这种说法多少会让人觉得有点困惑。
一 些人也在使用工具，比如我们有客户在使用RSA（Rational Software Architect），这些客户通常所使用的都是些比较复杂的工具。在系统工程领域，使用基于软件的建模工具（如Rational Rhapsody Tool）是一件很常见的事，人们经常用这样的工具来生成软件。在调查中我们还发现,尽管传统团队相对而言更喜欢使用工具，但是他们更多的是用工具来写文档，而敏捷团队则更多的是用来写软件，这是工具真正的价值所在。我认为，敏捷实践者们使用工具的目的相比于传统团队而言更为务实。
所以，毫无疑问敏捷团队也做建模。在我做的一些敏捷调研中，我们从统计数据中发现，有85%的敏捷团队会为产品做架构建模，或者事先做需求建模，因为用户故事不是从石头缝里蹦出来的，它们一定有源头，所以人们需要通过需求建模来作为起步，这是一种思路。所以说敏捷团队不建模显然是个错误，他们同样也使用工具。没有工具又怎么构造软件呢？这显然是不合逻辑的。所以我觉得敏捷社区里的一部分人需要认真思考一下，想想他们实际上是怎么做的。
记者：最后，您怎么预测敏捷开发的未来走向呢？
Scott： 毫无疑问，敏捷正在不断地发展壮大。我在《Dr. Bob》杂志上开设了一个专栏，其中一项工作是每隔两个月在业内做一次调查，现在已经积累了好几年的数据。我调查了企业采用敏捷的比率，这个数字一直在增长。我们看到敏捷正在被广泛采用，越来越多的企业把敏捷应用到他们的项目当中。在IBM，有越来越多的客户向我们咨询敏捷，寻求帮助。
过去半年里，我们欣喜地收到了大量有关敏捷工具和咨询的需求。这些客户不止来自政府和银行，还有其他领域的，大家都在关注敏捷。在北美和欧洲地区，不少企业都已经体验过敏捷，他们觉得那是可行的。当你尝试过并且收到了成效以后，就会更加渴望继续使用它。这就是我们所看到的现状。很多人都见证了敏捷的可行性，他们相互交流和分享经验，企业无疑也看到了这样的现象，要想拒绝敏捷很困难。敏捷存在已经有若干年了，显而易见，现在有足够多的证据和案例可以证明它的成功。
作者：itwriter
来源：CSDN
粤公网安备 44010602010970