|
自从2001年开始，“敏捷”一词在软件开发领域已经被赋予了一种新的意义。您真的明白敏捷一词的含义吗？这篇文章是由一名敏捷实践参与者所撰写。文章讨论了如今越来越重要的迭代和增量开发风格的基础方面，并用以文学评论的方式作了总结。 在 Princess Bride 这部电影中，Dread Pirate Roberts 正在攀爬 Vizzini 将要剪断的一条绳索。当 Roberts 并没有掉下来的 时候，Vizzini 说了一句"他没有掉下来？难以置信！" Inigo Montoya 回答道，"你经常使用的那个词，我并不认为他是你所认为的那个意思。" 当我和别人谈论敏捷一词的含义时，我的感觉和上面场景中 Montoya 的一样。我常常认为我们说的是同一件事。但是这不意味着我是正确的，他们是错误的。这只能说明敏捷一词的含义非常混乱。 软件行业中的人们有一个习惯，就是喜欢制造他们想要表达意思的词语，特别是在新技术领域。为了让这个新技术更易理解：我们的技术变化的太快，很多新的术语和简称几乎天天都会出现，我们很难跟上这个速度，因此我们试图对这些新术语产生麻痹的态度，并且希望我们更加的正确。 虽然敏捷一词已经出现很久了，但是仍然存在很多术语的滥用问题。 这个月，我将要公布一份关于敏捷前景的调查。我们首先要给这个术语做个定义。这并不是一件容易的事情。实际上，我并不确定能够胜任这项工作，不过我会努力的。首先，让我们从定义开始，来看看人们是如何曲解敏捷的意思。在我们达成定义的共识后，我会回顾一些有用的书籍和参考资料，他们能够为敏捷的前景指明方向。 最开始... 在2001年2月以前，"敏捷"一词意味着"标记快速的优雅的移动的能力"，或者是"拥有快速的机敏和适应能力的角色。" 从2001年开始，这个词对于软件开发人员来说拥有了更多的意义。由17个人组成的一组自称为无政府组织的团体出现了， 但他们实际上主要由软件开发领域的软件顾问和思想的领导人构成， 他们聚集在 Snowbird Utah 来定义敏捷的软件开发过程。虽然他们能在普通层面上对敏捷的理解达成一致，但是每一个与会者都有自己对于如何建立一个高质量软件的看法。 这种普通层面上的一致是在 Snowbird 举行的 Agile Manifesto 大会上面达成的。 我在之前已经讨论过这个宣言了，但是在这里我们仍然值得重复这四个条对于敏捷价值观的定义： 个体与交互 重于 过程和工具
这四个条对于敏捷价值观的定义看起来非常的简单明了。但是它引发的误解比任何一个词引发的误解都要多。这是为什么呢？我认为有三个原因。 首先，人们将 "敏捷" 一词理解为普通的用法。当我们谈到敏捷开发时，听众听到 "敏捷" 一词，正如我在介绍中提到的，会惯性的理解为我们在谈论一个很快速移动和变化的事物。当然，我们的软件项目变化是很快，但并不是所有的都是这种情况。如果在 Snowbird 大会上与会者没有事先定义描述软件开发过程的词汇，那么同样的问题也会发生。在当时，有很多人使用 轻量级 一词来将其和重量级过程区分，这些过程是由大型软件开发顾问公司强加给他们的。 其次，即使人们意识到敏捷一词的背后可能有其他含义，他们也会按照自己的想法来定义它。他们或许之前阅读过关于敏捷开发的书籍和文章，并尝试过使用这些方法来使他们的项目更加敏捷（根据他们自己的定义）。不幸的是，人们试图扭曲敏捷一词的含义，这些人中甚至包括一些专家和接触敏捷一段时间的人群。您所要做的就是参加一个敏捷讨论会，这样您就会明白我说的意思了。很多人都将敏捷概括为一种艺术："我看到它就会理解它，"或者是"它是一个非常个性化的定义。" 在去年的敏捷大会上，一些人说他们已经实现了"成熟的" 敏捷。当我问到他们这意味着什么的时候，他们的定义是，他们正在做单元测试和持续的集成。这些实践虽然可以用来支持四个值，但是它们本身并不是敏捷。 最后的理由来自于这些值的声明。很多人都会考虑这些值是如何规定的，但是许多人只是了解一下它们是怎样划分的。例如，"全面的文档"和"工作的软件"相对立吗？这些值好像暗示了这种可能，但是这两个方面是对立的，但是实际上并不存在合理的理由。因此我们拥有的四对值，每一个都被 Agile Manifesto 创造者放置在了和其他四个相对立的位置。我的目的并不是争论选择的正确性，而是简单的说明您只有在接受了成对值，并评价每一对中的第一个和第二个值。如果您决定了全面的文档化比单独和交互更加合适，那么我可以严肃的告诉您，您没有使用比较的方式来谈论 敏捷。这就是我们在谈论敏捷时容易产生混乱的第三个原因。我们很多人都不同意初始化配对。 一个科学的方法 接触一个学科的最好的方法，不管它是新的或者已经很好的制定的科目，我们都应该从定义开始，然后是严格的分析与质问，看它能引导我们做什么。让我们对敏捷这么做吧。 如果我们把 Agile Manifesto 作为资源文档，那么我们可以确定所有的组织或者项目都希望敏捷必须能够显示四个值中标识为第一位的特性（例如"客户协作"），要比标识为第二位的特性（"合约商议"）更能够评估它。Alistair Cockburn 曾经告诉我，敏捷是宇宙中16个可能存在的位置中的一个。他的意思是如果您考虑每一对值，您就拥有评估第一个和第二个值的选择。这是一个二择其一的问题。因为现在有四对值，所以有16种配置的可能性。我想这是理解敏捷的最简单，最清晰的方式。这就避免了我们试图区分敏捷的程度而产生的问题。使用 Cockburn 的描述，我们可以决定组织或者项目是否是敏捷的。如果组织具备这些评估数值，并按照执行方法应用它们，那么它就是敏捷的。如果不是则相反。 我们还可以从相反的观点来了解敏捷，这种思想是 Jeff Foxworthy 提出的。 5 如果您尽可能多或者超过使用单独交互这个值所规定的过程和工具，那么您也不是敏捷的。如果您评估的结果是完全文档化过多或者超过工作软件，那么您就不是敏捷的。如果您评估的结果是合约商议过多或者超过客户协作，那么您就不是敏捷的。如果您的评估的结果是计划过多或者超过相应变化，那么您就不是敏捷的。 上面的措辞中需要强调的是您不需要更多的评价非敏捷的特性。相对于敏捷来说，您最好尽量少的评价它们。如果您是一名项目的系统工程师，我猜想您的评估更多的是考虑到您的计划，而不是响应改变。您会涉及到硬件和软件问题，并且需要努力的将它们根据时间表整合起来。相对于硬件来说，改变软件更加的容易。 因此，如果我说我们不需要敏捷，那么我相信敏捷团体会严厉的抨击我。我们选择敏捷，是因为它对我们的项目和组织有重要的意义，而不是它本身有什么意义。当您和敏捷团体的成员对话时，他们都很明白这个道理并且在这一点上有共识。但是，像能够看到光，并想要分享它的福音传道者一样，他们强烈的热诚可能会压制您的想法。 您拥有确定的价值，并将这些价值转化为实践。宣言的作者为想要遵循敏捷的人提供了一系列原则。 6 如果您按照这些原则进行您的工作，那么您就是一个敏捷执行者。 文章的剩余部分将会介绍您使用敏捷和敏捷的一些定义。敏捷是按照 Agile Manifesto 大会上的定义，以及一系列相应的原则定义的。 哪里出了问题？ 我刚提到的定义非常简单。在组织和项目是否是敏捷这个问题上面，为什么还存在着这么多混乱和冲突的意见？部分的问题是由于原则的制定方式引起的，它为这些实践留出了解释和执行的空间。让我们看看一对问题。 我们的原则规定"根据个别的动机构建项目。为它们提供环境和所需的支持，并信任它们能够完成任务。"您如何执行这个实践？首先，您需要知道什么是一个个别的动机？一些人是出于简单的商业利润动机。另外一些人的动机来自于庞大的团队。一个团队的个别动机可能会干扰到另一个团队的动机。当您拥有一个组织事先挑选的人才时，您可能不需要适合您的项目小组定义的动机的个人。您还能继续敏捷么？ 另一个原则规定 "敏捷过程促进开发的维持。项目出资方、开发人员和用户应该可以长期的维持一种不变得步调。"很明显的，如果我们将标志杆设低，并少做工作，这也是我们能够长期维持的一种步调。还有一点也很明确，就是意图不一定就在原则之后。 我们可能单独的采用大部分原则，并将它歪曲为背离敏捷的精神。当完成整个工作时，它们确实会相互支持。但是仍然存在很多执行原则的空间。这为敏捷训练，顾问、方法学家和其他想要帮助组织成为敏捷和提供顾问的敏捷组织提供了有利的市场。它同时还促成很多组织采用新的实践，并声明他们已经根据方法学家的解释获得了敏捷。 获得一个敏捷的解释很容易。达到一个有效的解释程度却非常难。没有圣贤准确的告诉我们的项目或者组织是否是敏捷的。您必须要问的问题就是，这很重要吗？如果有效的生产出符合投资人所有需求的软件，那么您就非常的成功。您应该不断改进，但是您真的需要适应所以得需求吗？这是在您试图使用 CMM 和 CMMI、RUP 和其他方法学时会遇到的问题。个人和组织会"被鉴定"处于哪个层级，而不是简单的集中在最后的目标身上——软件的交付使用。方法学和实践意味着它们不是结束。 好的，如果它就是这么简单的话... 在2006年明尼阿波利斯举行的敏捷大会上出现了一个问题："如果敏捷这么简单的话，那为什么会有这么多的教科书教我们应该怎样去做？"当然这种说法有些开玩笑的意味，但是确实存在这样的问题。坐在学校的办公室里，我几乎有一整个书架的关于敏捷的书籍。至少有30本。另外我的家里还有10几本这样的书。关于敏捷的书籍太多了，为什么会有这么多种类的书呢？ 对于这个问题最简单的回答就是，书籍可以让那些顾问们更好的推销自己。书籍同样可以让那些理论学习者和从业者更好的扩展他们的视野。书籍可以在艺术级和实践级别上都给人以影响。不论何时当有新的观念被发现时，书籍，期刊论文和各种文章将会很自然地发布消息。那些具有很大影响力的观念一般会在讨论会上面形成。关于技术方面的话题是那些书刊所要报道的重点，因为，正如我在文章的开始所提到的，对于那些整天投身于 IT 行业——不断变更的项目，最终期限的到来，控制在预算之内，所有这些需要满足客户需求的事情——的人来说，随时关注能够帮助他们完成任务的最新方法，没有这些商品和帮助的指导是不可能的。 第二种解释就是，很多作者都在他们出版的书中声明自己有了关于某个热点话题的一种新方法。这就导致几乎每一本书都宣称自己介绍了一些作者关于价值和原则的新的有趣的想法。其中很多书重复的介绍了执行原则和价值的一种方法。比如一些自助书籍，它们声称只要按照他们的程序做，您就会成为敏捷的。如果您曾经尝试过不同的饮食习惯，娱乐节目，阅读改进程序等等，那么您应该很清楚的知道，有些事情对于一个人来说很成功，但是对于另一个人来说可能没有任何效果。同样的道理在敏捷方面的书籍上面也适用。一种方法在项目 A 上适用，但是到了项目 B 上可能会惨败。每一个项目和组织都要找到适合它们自己的那个敏捷，当然前提是您的项目和组织适合使用敏捷。 无处不在的敏捷 敏捷现在可以说无处不在。它不仅存在于软件开发领域。如果一个实践值得我们花时间和努力去学习和应用，那么它就是敏捷的。如果一个工具值得在我们的项目上学习和使用，那么它必须支持敏捷。这不仅是满足实际需要的问题，更是一个市场营销问题。敏捷就像一个新品牌的运动鞋，我们买来是想让它帮助我们的开发小组跳得更高，跑得更快。 有一天我在一个书店中挑选了一本关于 Ruby 程序设计的书籍。在这本书的封底上印着："Ruby 是一种敏捷的面向对象程序设计语言。"虽然他们没有将敏捷一词的字母 'a' 大写，但是我并不确定普通的读者是否能够意识到这个问题。Ruby 真的是 Agile Manifesto 上包含的价值观吗？这显然是一个荒谬的问题。但是我们现在谈论的是市场问题，逻辑上的问题并不是最重要的事情。使用 "敏捷" 一词去吸引客户的注意力，让您可以进入门槛。（我真希望有一天我们的顾客也能够变得聪明起来，他们可以提出正确的问题，并重视敏捷。） 我并不反对敏捷。但我也不是一个敏捷主义者。我希望被认为是一个实用主义者，我只使用那些可以帮我的东西，忽略那些对我没有用处的东西。有时候敏捷可以在工作上帮助我。但有时候我需要一些其他的帮助。 关于敏捷的书籍和方法学 在文章的后半部分我将简要的介绍一些关于敏捷的书籍，这些书籍我认为很重要。我会向您解释为什么说我给您提供的每一本书都很重要。我会站在很高的视角列出这些书籍——它们的内容主要都是关于敏捷的价值和原则。之后我会详细的列出方法学和实践的内容。 关于敏捷价值和原则的书籍 Agile Software Development：Cooperative Game，2ed.，Alistair Cockburn，Addison-Wesley Professional，2006，ISBN 0321482751。 作者是 Alistair Cockburn。这本书是从敏捷思想的原创者之一的视角，给了我们一个关于敏捷的最好的描述。文章写得非常清晰和均衡。Cockburn 描述了敏捷并把它放在了光谱值的其他位置。他老练的指出了 sweet spot 作为敏捷方法，以及为什么使用它以及您能从中获得的好处。 Cockburn 的处理方法并不是一种技术上的方法。他并没有涉及代码的编写以及更多的细节问题，而是给您了充足的材料让您理解敏捷。Cockburn 是由于他致力于人与人之间关系在软件开发领域的研究，并花费了大量的时间讨论了敏捷受人的影响等问题而被人所熟知。如果您对于敏捷软件开发一无所知，那么这本书非常的适合您。 Agile & Iterative Software Development A Manager's Guide，Craig Larman，Addison-Wesley，2004，ISBN 0131111558。 Craig Larman 是一名软件开发领域的大师，尤其在面向对象的实践领域。他精通不同的方法学，并且知道怎样以及何时需要使用它们。在这本书中，Larman 涉及到了迭代方法，Scrum、XP、RUP 和 Evo. Scrum 以及敏捷部分涉及的 XP，还有更多偏重于传统的（计划驱动的）迭代方法 RUP 和 Evo。Larman 比较和对比了不同的方法学，帮助读者评价它们之间的好坏，以及哪种类型的过程最适合特定类型的项目和组织。 方法学之间的对照出现在本书的后半部分。开始的六个章节是本卷书的精华所在。在这些章节中，Larman 以批判的眼光谈论了软件开发，敏捷度，迭代开发，并给读者提供了使用迭代开发和敏捷方法的证据。这些证据来自于研究，实践经历或者其他资源。Larman 在这本书中表现的非常的敬业。 Balancing Agility and Discipline A Guide for the Perplexed，Barry Boehm 和 Richard Turner，Addison-Wesley，2004，ISBN 0321186125。 这本书适合那些来自于大组织和项目的经理，或者在软件工程（不是软件开发）领域有很坚实知识背景的人员阅读。 7 Boehm 和 Turner 是拥有大型项目经验（其中大部分是国防部的项目）的理论家。他们通过介绍每一种方法学最适合应用的领域类型来切入主题—— sweet spots。Boehm 最为人所知的成就是项目评估中的 COCOMO 模型的开发，并且发表过很多有启发作用的软件工程领域的论文，其中包括介绍迭代开发的文章。 8 我最担心的关于这本书的问题，就是我不确定 Boehm 和 Turner 是否在我经常研究类型的项目中有工作经验。其中一人只写过不到 100K 行的代码。他们主要的研究方向是那些使用传统软件工程学方法的超大型项目。但是这并不妨碍您阅读这本书，因为它从一个不同于我所列出的其他书籍的视角，谈论了敏捷的应用。 关于敏捷方法学的书籍 Agile Software Development with Scrum，Ken Schwaber 和 Mike Beedle，Prentice Hall，2001，ISBN 0130676349。 Scrum 在过去的几年中获得了广泛的关注。它是项目管理的一种简单的方法，并且和软件开发有松弛连接关系。对于大部分情况来说，Scrum 由一些成熟的实践构成，但是执行起来非常严格。Scrum 的支持者声称它适用于所有规模的软件开发项目。这里没有任何我可以参考的技术实践来证明这个方法学。它们都是关于项目的管理。 这本书使用 Scrum 方法创造人 Schwaber 和 Beedle 的话描述了 Scrum 的方法学。使用 Scrum 非常愉快的一件事就是它的实践可以和大部分其他实践相结合。如果您想要了解敏捷项目如何处理项目管理方面的问题，那么这本书很适合您阅读。 Extreme Programming Explained：Embrace Change，2ed.，Kent Beck 和 Cynthia Andres，Addison-Wesley Professional，2004，ISBN 0321278658。 在这本书的第一版中，包含更多关于进行敏捷活动的效果。实际上，很多从业人员开始将 Extreme Programming (XP) 和敏捷放在同等重要的地位。对于软件开发人员来说，XP 这种方法学能够更多的吸引他们的注意力。Beck 以及她的助手 Andres 合著的第二版书中，描述了他在软件开发者之间使用最多的敏捷方法学的基础实践。我提到它是最多被使用的，因为只有很少的组织真正实际的将实践应用到他们的环境中，但是他们往往自称使用 XP。 这本书的第二版要比第一版厚了很多，其中添加了很多我认为有用处的内容。第二版中加入了很多关于基本 XP 方法学的策略和更改材料。如果您对于敏捷方法很陌生，那么我建议您最好先看第一版的书籍，对 XP 有一个大体的了解。 Extreme Programming Installed，Ron Jeffries，Ann Anderson 和 Chet Hendrickson，Addison-Wesley Professional，2000，ISBN 0201708426。 这是我推荐的众多与 XP 相关的书籍中的第二卷，它的出版方是 Addison-Wesley。这本书很值得我们去读，因为它描述了 XP 实践以及它是如何被最初众多的 XP 项目小组使用的。 9 这本书的可读性非常强，您会从中感觉到在项目中使用 XP 是一件非常愉快的事情。这本书所有介绍的 XP 实践应用程序，都不是我会选择从事的项目类型。这本书帮助我确定了有一些很好的实践我应该去学习。即使 XP 不断的在进化，但是这本书还是非常适合那些没有经验，从未进行过 XP 开发的小组人员去阅读。 关于实践细节的书籍 Test Driven Development：A Practical Guide，David Astels，Prentice Hall Ptr，2003，ISBN 0131016490。 我相信测试驱动的开发 (TDD) 是敏捷活动中最为重要的一种实践。它关心的重点是开发人员的质量以及责任的质量。它需要我们在开发的整个周期中都关注产品的质量，而忽略我们所使用的方法学。这是一本介绍 TDD 的好书。它使我领略到了简单的测试所带来的强大效果。 Pragmatic Unit Testing in Java with JUnit，Andrew Hunt 和 David Thomas，The Pragmatic Programmers，LLC，2003，ISBN 0974514012。 这本书介绍了大量的实践，补充了之前那本书关于如何真正执行 TDD 实践。Pragmatic Programmers 出版了一系列很好的书籍，它们针对软件开发人员讲解最新的技术。这本书是他们的早期作品之一，它是每一个想要很好的编写单元测试用例的 Java 程序员的必读书籍。它用 TDD 的替换掉了单元测试的内容，并给了读者所有需要编写，管理和自动操作单元测试的工具。 User Stories Applied，Mike Cohn，Addison-Wesley Professional，2004，ISBN 0321205685。 用户的经历往往是很多敏捷项目的需求规范的传达手段；虽然还存在很多其它方法，例如用例等。用户的经历只是功能性需求的一小部分，它被客户写在一张索引卡片上面。这仅仅是 XP 和其他敏捷方法中的一小部分。像编写用例，编写用户经历都是一种需要学习和实践的能力。Mike Cohn 为我们提供了我所见过的编写用户经历的最好的介绍。他的书偏重于用户经历，而 Alistair Cockburn 的书更偏重于用例。 10 如果您经常使用用例，但是还没有阅读过 Cockburn 的书，那么 Cohn 将会给您关于如何在您的项目中编写和应用用户经历的完整的教学指南。他为您提供了很多例子，并且他在真实项目中的经验也会给您提供很大的帮助。如果您是一个对用户经历有兴趣的分析员，那么这本书再适合您不过了。 Planning Extreme Programming，Kent Beck and Martin Fowler，Addison-Wesley Professional，2000，ISBN 0210710919。 XP 项目另一个关键实践就是 planning game。这是一系列非常简单的活动，它能帮助客户和小组人员决定在每一个迭代过程中应该做什么，如何评估效果，以及如何追踪结果，好让您更好的做评估。Beck 和 Fowler 描述实践的方法能够很好的吸引开发人员，经历和所有 XP 小组的成员。 其它相关书籍 虽然下面的两本书不属于上面所列书籍的种类，但是我认为这两本书都很有用处。我用下面的第二本书作为我一年两次的软件工程课程的教科书。 Agile Software Development Principles，Patterns，和 Practices，Robert C. Martin，Prentice Hall，2002，ISBN 0135974445。 这是开发人员的开发人员写的一本开发人员的书籍。Bob Martin 是一名高级开发人员，他在面向对象和敏捷原则领域有很深的造诣。在这本书中，Uncle Bob 给我们介绍了这两个概念，并且带我们了解面向对象设计原则，以及如何在敏捷项目中使用它们。这是每一个开发人员都应该了解的内容。 Extreme Software Engineering：A Hands-On Approach，Daniel H. Steinberg 和 Daniel W. Palmer，Prentice Hall，2003，ISBN 013047812。 这是一本小册的书籍，它公正的谈论了敏捷项目，尤其是 XP。它并不是教条的方法，这本书中介绍了敏捷既不是偶然出现的软件开发方法，也不是按照任何旧方式执行的方法。我认为这本书很适合我的学生去读，让我有更多的时间强调我认为重要的软件开发方面。这本书很适合您在周末去阅读它。 结论 敏捷无处不在。如果您忽视它，那么您会失去很多现今热门的技术话题。学习它，您将会在今后的工作中更加智慧的作出决定。同时您还可以理解很多其他的实践和方法学。如果您是某个层级技术的经理，那么学习它是您的职责，也是您赖以生存的必需品。 我强烈建议您开始阅读我上面所列的书籍，还有一些其它书籍，例如 Mary Poppendieck （瘦开发），Scott Ambler （数据库），Jim Highsmith （管理实践），以及其他直接投身于敏捷活动或者已经开发出，并且被敏捷小组和项目"运行良好"的原则和实践。我希望您能够通过学习获得一些对于您的团队，项目和组织有用的信息。毋庸置疑，您会发现很多可能误导您的书籍——并不是因为它们的内容是错误的，而只是它们不是您所需要的。成为一名见多识广的客户，会增加您在团队中的价值。 注释： 1我会使用大写字母来分辨这个词和普通词汇。这是敏捷团体的习惯用法。 2出自于 Merriam-Webster OnLine 字典（http://www.）。 3查看 “敏捷宣言的历史”（History: The Agile Manifesto）。 4 《敏捷软件开发宣言》（Manifesto for Agile Software Development）。 5 Jeff Foxworthy 是一名喜剧演员，他经常使用：“如果您……您就是一个乡下人” （美国南部的乡下劳动力，通常被当作笨蛋的原型）的句式来引人发笑。 6 “敏捷开发原则”（Principles behind the Agile Manifesto）。 7察看我在 2006 年 2 月发表的专栏文章，该文讲述了他们之间的区别。“教学软件开发与软件工程”。 8Barry Boehm，"A Spiral Model of Software Development and Enhancement"，ACM SIGSOFT Software Engineering Notes，August 1986。 9引起很多书关注的这个项目 :-) 这就是 Chrysler Comprehensive Compensation System，它开始于1995年。这是第一个将所有 XP 实践应用，记录和精炼到方法学中的项目，我们后来称其为 XP。 10 Writing Effective Use Cases，Alistair Cockburn，Addison-Wesley Professional，2000，ISBN 0201702258。如果您经常使用用例，那么建议您去阅读这本书。 |
|
|
