级别： 初级 Scott Laningham, Podcast 编辑, IBM developerWorks
2007 年 4 月 10 日
更新 2008 年 7 月 28 日 IBM® 敏捷开发实践领导者 Scott Ambler 在这个 Podcast 里阐述了敏捷开发这种迭代和增量的开发方法，展示敏捷开发的业务实例，并且澄清对于敏捷开发过程的一些误解。
developerWorks：各位朋友大家好，您正在收听的是 developerWorks 访谈。在这里，我们同来自各个领域的技术专家和思想领袖，就技术从业人员感兴趣的话题进行对话。我是主持人 Scott Laningham。今天，我们有幸邀请到的嘉宾是 IBM Rational 敏捷开发的实践领导者 Scott Ambler。
Scott，欢迎您的到来。
Ambler：谢谢。
developerWorks：敏捷开发中的敏捷一词，暗示出这种开发处理过程良好的可适应性。我的这种推测是否正确呢？
Ambler：的确如此。当我们谈论敏捷的时候，通常涉及到以下这些关键问题。首先，它是一种增量的开发方法，所以不断进化是它的本性。它还具备高度的协作性，所以开发人员能够共同工作，您知道，这既包括开发人员之间的协作，也包括开发人员同利益攸关方之间的协作。所以说，它是一种非常好的工作方式。
我们所关注的是高质量的软件。所以，当您考虑敏捷的时候，您也必须考虑到质量的问题。我们以一种成本和时间有效的方法做到这一点。我想，最为重要的是，我们所关注的是如何让我们开发出来的软件满足出资方不断变化的需要。我们欢迎变化的发生。
developerWorks：为什么 IBM 要在此时谈论敏捷开发呢？它并不是一个新的概念，不是么？
Ambler：是的，这并不是一个新的概念。在 2001 年的时候它就已经被普及了。在那时，许多方法学家聚集在一起讨论软件处理过程。他们所取得的一些结论最终成为了敏捷宣言。此后，软件开发杂志（一本我曾经为其撰写过文章的杂志）通过一些特写文章使其在社区中基本上被普及。
那么为什么我们要进行敏捷开发呢？我认为它具有一些重大的商业利益。敏捷软件开发，当您正确应用它时，至少可以改善产品投放市场的时间，以及显著改善产品的质量。敏捷人员进行了比以往多得多的测试，我们重新分解我们的代码来确保它总是高质量的。所以其结果是，我们将完成比传统世界中的要好得多的工作。实际上，它还大大增加了满足出资方需要的机会。我们的出资方并不善于预先定义什么才是他们想要的东西。当他们看到一些东西时，他们会说：“这并不是我想要的，您知道，您需要给我另外的东西。”所以，通过欢迎变化、通过拥有那些允许我们轻易做出改变的工具，我们将更有能够建造出人们所真正想要的系统，并且在同时减少开销。我们做到了，由于我们将关注点放在人们真正想要的东西上面，而并不是去建造那些传统人员努力去做的但却是人们不想要的东西，所以我们能够大大提高软件开发的效率。
从 IBM 的观点来看，我想另一些原因在于商业利益并不是充分的，但是敏捷开发却迅速地在全球范围内被采纳。这里有一组调查资料可以显示这一点。敏捷开发真实存在在这里，我们的客户将要采用它，所以我们也必须采用它。坦白的说，传统的开发方法并没有很有效的工作。我们确实需要重新思考我们应当如何工作。我想这就是敏捷开发的内容：一群聪明人对常规方法的重新思考。
developerWorks：那么软件开发的现状如何呢？我推测这同充满动态氛围的网络环境下的变革速度有关，是这样么？
Ambler：是的，确实如此。正如我们常说的那句话：唯一不变的就是变化本身。但是，我们将发现不久以前的那些大型系统相当的直截了当……虽然它们很复杂，但是它们却是十分直截了当，所以它们不再适用。这些项目从而变得更短、更快和更加动态。您必须更加快速地满足市场的需要，人们的期望在增加，我们就必须满足它们。
developerWorks：您能够告诉我们敏捷开发的基本点是什么？它同传统的软件开发方法的区别在哪里？
Ambler：我认为，主要基本点之一就是无论何时我向人们描述敏捷开发的时候，他们总是会说“我已经从事那个许多年了”。这种情况出现在对象身上，也会出现在敏捷身上。所以，是的，您也许在过去一直都很聪明，但是您本来还是可以变得更加聪明的，我想这就是一部分情况吧。
那么，它的不同之处又在哪里呢？首先，它更加关注协作。编写文档并将其与他人分享，无疑是一种最烂的交流方式。所以我们努力避免这样做。最后的沟通方式是，一群人站在一块白板面前，一边谈论，一边绘制草图。现在，如果您的团队碰巧要被分散开，那么您知道，也许您们就必须打电话或者发送电子邮件或者进行视频会议了。但是，您可以将这些问题传播出去。我们的出资方积极地参与到项目之中。我们尊重我们的出资方，他们都是非常聪明的人。所以我们找到一种让他们能够积极参与到建模之中的工作方式。我们尽可能地使用综合性的建模技术以及简单的建模工具。
第二个主要区别在于，我们关注的是工作的软件。我认为这是至关重要的。衡量软件开发项目进展情况的唯一真正标准就是工作软件的交付。除此之外，其他指标都是虚的。所以，在传统的世界里，要求通过交付需求文档、体系结构文档、或者类似的东西来获得价值，但是我要说这样做的结果仅仅是撰写了一个文档。我不知道人们是否会阅读它。是的，它起到了回顾的作用，但是这并不意味着任何事情都可以长期的运转下去。我认为这是一个严重的挑战。所以，我们的做法是大量减少文档。我们仍然生产一些文档，但是数量上已经远远少于以往了。但是，我们更加关注工作软件的交付，因为人们能够理解这一点。他们付钱给我们，几个星期之后，我们就必须把一些东西展示给他们。这是一种十分健康的方式。
第三，敏捷开发人员更像是通用专家或者工匠。通用专家是指具有一种或者多种专门技术的人，您必须添加一些价值到团队之中，但是您拥有软件开发的一般知识——较好的情况是拥有所要工作领域的一般知识，较坏的情况也至少是拥有一般的知识。您希望学习，希望卷起挽起自己的袖子。好的，这是我的工作，那是您的工作。您知道，这是我们的工作，让我们一起完成它吧。所以，由通用专家所组成的团队，其结果是由于大家都具有很好的技能，因而很少发生人员之间的相互支持。在一个多年以来鼓励人们更加专门化的环境中，这是一个十分重大的挑战。所以您拥有用例建模专家、或者数据建模专家、或者测试专家。我们正在远离这一点，所以对于许多人来说将面临新的挑战。
最后，我认为主要的观察结论就是：敏捷开发是基于实践的，而不是基于理论的。而传统的开发技术是基于理论的。由于我们长期以来受其影响，所以许多人都已经忘记了这一点。有大量的证据可以证明这个理论是错误的。所以，敏捷开发就从那些在战壕中奋战的人们之中应运而生了。
developerWorks：所以，也许这把我们带入了反对者的逻辑之中。我知道在您所进行的陈述中，您是根据谎言阐述事实。也许我们也可以按照这一形式展开下面的谈话，从而您可以快速地驱散这些谎言。我们的第一个话题是，没有文档资料。请您对这种说法做出解释。
Ambler：是的，我们确实编写文档资料，但是我们将其视为一种必要条件。所以我们要求人们估计它的成本，并且将成本清楚的体现出来。所以您会惊讶的发现您会说：“您希望那些文档资料？非常好。生产这些文档资料将花费您辛苦挣来的五万美元。”当您说出这样的话时，下一个问题一定会是：“五万美元？您在开玩笑么？我能不能只花费一万美元？”于是，您们的谈判就从此开始了。或者他们说：“我真的不知道我需要付这么多钱。算了吧，我们不需要这些。”所以这确实是一种更聪明的做事方法。它促使您编写更加严密和简练的文档资料。
所以，敏捷人员所做的一件事就是为我们证明稳定的概念而非投机的概念。所以，我们并不事先编写大量的文档，这是由于这些信息是会发生变化的。所以，将它们记录在纸上并不是一项很好的投资。那样做有些疯狂。所以，我们促使人们思考并且判断他们为什么希望得到这些文档资料。这样做的结果之一就是，减少了我们的工作量。
developerWorks：有人指责敏捷开发是训练不足的，您如何评价这种说法？
Ambler：这种说法是完全错误的。在我看来，传统的开发才是训练不足的。在传统的世界里，有大量的论文和机构，但这些并不是训练。敏捷开发需要大量的训练来测试第一个开发或者完成足够的工作，然后向前推进并完成其他的工作，并且始终关注高价值的活动。是的，这种说法是错误的。
developerWorks：现在，有些人将迭代等同于无计划，您认为这种看法正确么？
Ambler：不，完全不是这样的。我们所做的是及时的计划。所以我们将进行一小部分的预先计划，这是由于您必须确定您的主要里程碑以及对其他团队的主要依赖关系。但是，我们只进行及时的计划。我们也是自我组织的团队。开发人员都是十分聪明的人，他们知道如何完成他们的工作，也知道如何组织他们的工作。他们不需要管理人员制定详细的 Gantt 图表，您知道，开发人员会忽略掉这些事情。他们在被允许的情况下完成正确的工作。
所以我们认识到真正的事实是，您知道，人们能够非常明确地指出如何完成他们自己的工作。从而，我们能够少做许多计划工作。实际上，我们已经为完成这项工作进行了充足的计划。事情就是这样的。
developerWorks：现在，下一个看起来只是跟着做，并不是可预言的。我的意思是说，您已经谈论了这是如何不可适用的。但是请您继续谈一谈另一个问题。
Ambler：是的。传统的开发是不可预言的。实际上，我想是这样的：我能够预言您更有可能延迟。您更有可能超出预算，并且更有可能生产出并不满足用户实际需要的产品。所以，如果那就是您的目标的话，那么就请您进行传统的工作吧。但是我能够预言的是，您知道，如果您真的进行敏捷开发的话，您将会编写出高质量的软件。您所进行的工作根据出资方的定义将把最好的 ROI 提供给他们。我能够预言的是，您将按照出资方设定的进度完成工作。所以说，这完全是可以预测的。
现在，我能够预言您将花费多少资金了么？不可以。我能够做的只是预言您的花销将是非常精打细算的。我能够精确预言您将建造的是什么么？不可以，但是我可以预言您将建造最有价值的产品。所以，我认为这才是我更加喜欢的可预言级别。我猜这同您看待问题的方式有关系。
但是，我认为由于这些详细的估计和进度表，这里存在大量错误的信心。有趣的是，许多人并不能够观察到这些估计很少能够变成现实、以及这些进度表很少能够长久有效这一事实。所以，我并不喜欢这样做。
developerWorks：那么关于没有测量的说法，您又是如何看的呢？
Ambler：这种说法并不恰当。平心而论，许多敏捷著作并没有关注小型的共处一地的团队。但是实际情况是，Eclipse 项目就是一个敏捷的项目，全世界有数百位开发人员工作于一个复杂的系统。并且他们一直以来都能够按期完成他们的阶段目标，您知道，它被认为是计算历史上最成功的项目之一。现在的情况我并不了解，但是我知道它确实很成功。但是，如果他们是最成功的，我将会让他们就此讨论一番。但是，他们确实完成了一项伟大的工作。这就是敏捷的若干例子之一。我们的网站 ibm.com 就是使用一个敏捷的处理过程被开发的，您知道，它可是一个相当大型的系统。
developerWorks：好的，您刚才说敏捷开发是一种时尚，您还说它现在正在快速地成为一种标准，是这样么？
Ambler：是的，这里有一些调查数据。一年前我为 Dobbs 博士进行了一次调查。我的调查也许是最悲观的一个，但是它显示在北美地区有 45% 的公司已经采用了一种或多种方法；65% 的公司已经采用了一种或多种敏捷技术。由此可见我们前进的方向是十分正确的。您知道，纵观今天的任何一个软件开发会议，很难找到一个没有人在讨论敏捷的软件开发的地方。
developerWorks：当涉及到合同谈判或者价格等此类问题时，会不会引入某些挑战呢？
Ambler：实际上，无论在何种情况下，价格谈判都是一个棘手的问题。我们需要承认这一点。但是，实际上是有固定的价格的。但是，在最后一天确定价格对于所涉及的每个人来说都不是一件好事情。这样做会增加您需要承担的风险。它会迫使您做一些根本无助于您的预先的工作，并且在事实上降低您的效率。所以说，这是一个坏消息。是的，敏捷人员可以同传统人员一起确定价格：我们能够做同样的事情，我们将会多做一些预先的工作……我们将向传统人员一样做一些事情。
主要的区别在于，我们将十分诚实的对待这件事情，并且我们会说出来，您知道么？这并不是一个好的数字，如果您坚持一个精确的数字的话，我们将会提高出价。这就是事实，并没有什么魔法。
developerWorks：将文化转变到这类事情上有多么困难？这是一种挑战么？
Ambler：是的，的确如此。这就像任何一个范例提升一样。您将会扰动现已存在的文化。您知道，这些年来我们一直将某些人视为专家。我们将要打破他们的小权威。事实上，一旦您向某些人所拥有的权利结构发起挑战，他们都不会希望变化的发生。人们总是不希望自然地改变。我想，我们将要改变他们所习惯的规则。但是，同时我认为，您必须认识到这是必然要发生的事情，无论您喜欢与否。我们必须要这样做。
developerWorks： 当然，好的，我们还是不要再它仍然处于发展的时候对其加以讨论吧，因为这实在是太困难了，不是么？
Ambler：是的，这很困难。我们必须要这样做，我们也必须帮助别人这样做。我们已经拥有了一些 IBM 工具，借助它们我们可以帮助人们学习敏捷开发的知识。但是，我强烈建议人们现在就开始阅读、开始思考、甚至回过身去观察究竟发生了什么。
这些我曾经在会议上多次强调，同时也是我给大家的建议，当然，您希望聆听演讲者在说什么，但是更加重要的是，您希望同坐在身边的人进行交流。您将会发现您们都将经受由于您们对同一问题存在认识上的细微差异所带来的痛苦。所有这些都是基于传统的软件开发所基于的错误理论。直到我们开始认识到并且观察到传统的工作方式是如此可怕，我们才会真的具有动机进行相应的改变。
developerWorks：当您谈论的时候，我感觉您将更多的信任放到了命令链条的开发人员身上。这并不是传统的自顶向下的组织看待事情的方法，是这样么？
Ambler：的确如此。您仍然能够进行管理，仍然能够观察事情。我认为管理一个敏捷的项目较之管理一个传统的项目更加容易，这是因为敏捷的项目很难隐藏。如果您必须每隔几个星期就交付软件，我就不可能在这种项目上做傻事。人们将注意到您并没有进行生产，并且他们会提出一些令人厌恶的问题。所以，我认为这正是价值所在。
developerWorks：所以说那种认为它只适合于那些高级开发者的想法是不正确的？
Ambler：是的，这种想法是完全错误的。真正的问题是在您的团队中会有许多新手。如同其他任何一个团队一样，您还将拥有一些中级的开发人员和一些高级的开发人员。我想，最主要的特征是，他们需要具有共同工作和学习的意愿。我想，这才是至关重要的。
developerWorks：下面这个问题看起来好像是包装好的。关于这一主题，IBM 正在进行哪些工作呢？
Ambler：我们正在进行大量的十分有意思的工作。现在，IBM Rational 很快将会开展一项敏捷活动，我们将在那里交流和沟通消息，那里会有许多好东西。我们已经拥有了 IBM developerWorks，那里也有一些好东西。Rational Edge、一些优秀的文章、Rational 统一过程等，我们拥有非常好的处理过程资产。
IBM 全球服务正在进行一些敏捷开发的努力。我们拥有一些团队，他们正在进行十分有意义的工作。因此，我们正在不断积累这些实践经验。IBM 研究院五月份将在加利福尼亚的 Alamedan 举办一次会议。如果可能的话，我强烈建议您参加这次会议。我是会议组委会的一员，我们正要发送论文的最终确认接收函。我们现在所面临的最大问题是，我们收到了大量的好的建议，但是我们无法全部采纳它们。所以说，这次会议将是一场非常有价值的会议。我们邀请到许多著名的行业专家出席，这十分令人兴奋。我于最近加入了 IBM，于是我遇到了一些十分聪明的人正在进行一些十分有意思的工作。
我们正在进行一些十分出色的开源项目，您知道，Eclipse 就是一个著名的例子。但是，我记不清具体的数字是多少了，然而 IBM 积极参与的开源项目大概有 300~400 个。所以，我们正在该社区中进行着最前沿的工作。并且我认为，我们需要对此进行更好的交流和沟通。
developerWorks：好的，在您今天的谈话中，我们收获了许多有意思和激动人心的内容。
Ambler：谢谢。
developerWorks：感谢您带领我们跟上敏捷开发的发展脚步。非常感谢您抽出时间接受我们的采访。
Ambler：我非常高兴能够来到这里，非常感谢。
developerWorks：我们今天的嘉宾是 IBM Rational 敏捷开发的实践领导者 Scott Ambler。如果希望得到 Scott 谈话的更多内容，请您访问 ibm.com/developerworks。只需在 developerWorks 的网站中键入“Agile development”，您就将得到大量的相关文章。
您还可以登录我的博客查看本节目的播出笔记，其中提供了相关的资源链接。您可以在 ibm.com/developerworks/podcast 上找到它，以及我们所进行的其他访谈的列表。今天的 developerWorks 访谈就到这里。我是 Scott Laningham，感谢您的收听。
参考资料 学习
获得产品和技术
讨论
关于作者  | | | Scott Laningham 是 developerWorks Podcast 的主持人，以前曾担任 developerWorks 时事通迅的编辑。在加入 IBM 之前，他是一名曾多次获奖的记者和 Public Radio International 新闻节目的主播，以及 American Communications Foundation 和 CBS Radio 的自由撰稿人。此外，他还是一名作曲家和音乐家。 |
对本文的评价
| 
