当我与人们讨论敏捷性的概念时，在上述场景中，我感觉像蒙托亚。 我想知道我们是否在谈论同一件事。 那并不意味着我是对的，他们是错的。 这仅表示混乱围绕着敏捷一词的当前用法。 1软件行业的人们习惯于使单词成为他们想要表达的意思，尤其是新的技术术语。 在某种程度上这是可以理解的：我们的技术变化如此之快，以至于几乎每天出现的新术语和首字母缩略词的数量很难跟上，而且我们的术语往往有些草率，希望我们更正确比错。
尽管敏捷已经存在了一段时间，但许多学者和实践者还是滥用该术语。
本月，我想对敏捷景观进行一次调查。 但是，为了开始，我们需要为该术语建立一个定义。 这不容易。 实际上，我不确定自己是否能胜任这项工作，但我会尽力而为。 让我们从第一个原则开始，然后看一下那些对敏捷有个人定义的人通常会如何扭曲它们。 在我们（希望）同意一个定义之后，我将回顾一些我认为对导航敏捷景观有用的书籍和参考。
一开始...
在2001年2月之前，“敏捷”一词的意思是“具有随时随地轻松移动的随时准备能力”或“具有快速机智和适应能力”。 2在2001年，这个词开始对软件开发人员来说意味着更具体的含义。 A组的17人谁自称为无政府主义者组织 ， 3但主要是软件顾问和思想领袖在软件开发，聚集在雪鸟，犹他州和定义敏捷软件开发。 尽管每个与会者对如何构建高质量的软件都有自己的想法，但敏捷是他们可以达成共识的共同基础。
雪鸟会议达成的共识是“敏捷宣言” 。 4我之前已经讨论过宣言，但是值得重复这里定义的四个值，因为它们为我们提供了理解敏捷的预期含义的基础（大写的“ A”）。 这些值被表述为相对于软件开发的一个方面的偏好：
- 在流程和工具上的个人和互动。
- 工作软件超过全面的文档。
- 通过合同谈判进行客户协作。
- 响应计划变更。
而已。 看起来很简单明了。 但是，它导致的误解和解释都比我想不到的任何单词都要多。 为什么？ 我可以想到三个原因。
首先，人们理解“敏捷”一词，因为它是常用的。 当我们谈到敏捷开发时，听众会听到“敏捷”，并且正如我在引言中提到的那样，应用他们自己的语义过滤器来相信我们所讲的是快速变化的事物，快速变化的事物和经常变化的事物。 当然，我们的许多软件项目的确会快速变化和快速移动，但并非全部。 当然，如果Snowbird参与者选择任何其他已经定义的词来描述他们的软件开发方法，也会发生相同的问题。 当时，许多咨询公司考虑将轻量级产品与他们认为的重量级过程区分开来，这是大型咨询公司强加给开发组织的。
其次，即使人们知道敏捷一词背后有不同的含义，他们也会想到自己的个人定义。 他们可能已经阅读了一些有关敏捷开发的文章或书籍，并尝试实施一些使他们的项目更加敏捷的实践（根据他们的定义）。 不幸的是，人们倾向于歪曲敏捷的预期含义，甚至包括一些参与敏捷运动一段时间的专家或人员。 您所要做的就是参加其中一个敏捷会议，您会明白我的意思的。 许多人得出这样的结论：敏捷就像艺术：“当我看到它时，我就知道它”，“这是一个非常个人化的定义”。 去年在敏捷2006年大会上，有人说他们已经实施了“成熟的”敏捷。 当我向他们询问这意味着什么时，他们的定义是他们在进行单元测试和持续集成。 这些实践可用于支持这四个价值观，但它们本身并不是敏捷。
最终原因来自值的声明。 如何表达价值观有很多想法，但是很多人看起来很有价值，并且质疑（正确地如此）它们所体现的二分法。 例如，“综合文档”是否与“工作软件”相反？ 这些价值观似乎暗示着，但这两个方面是相互对立的，但实际上，这没有逻辑上的依据。 因此，我们拥有四对价值观，每对价值观都与敏捷宣言创建者相对于其他四对价值观相对立。 我的目的不是要争论选择的正确性，而只是说除非您同意配对并选择在每对中的第二个值上重视第一个值，否则您不能考虑敏捷。 如果您认为综合文档比起个人和互动更合适，那么严格来讲，您没有词汇来比较地讨论敏捷性。 这是我们谈论敏捷性时产生困惑的第三个原因。 我们许多人不同意最初的配对。
科学的方法
处理任何新的或公认的主题的最佳方法之一是从定义开始，然后通过严格的分析和质疑，找出导致问题的原因。 让我们使用敏捷性来做到这一点。
如果我们将“敏捷宣言”视为源文档，则可以确定希望成为敏捷组织的任何组织或项目必须比四个名称中的每个特征更重视四个值（例如，“客户合作”）中第一个名称中的特征。 （例如，“合同谈判”）。 阿利斯泰尔·考克本（Alistair Cockburn）曾经告诉我，敏捷性在16个可能的位置中是一个位置。 他的意思是，如果考虑每对值，则可以选择第一个值对第二个值的取舍。 这是一个二进制决定。 由于其中有四个，因此有十六种可能的配置。 我认为这是思考敏捷性的最简单，最清晰的方法。 这避免了尝试区分敏捷度的问题。 使用Cockburn的描述，我们可以确定组织或项目是否敏捷。 如果组织拥有这些价值观，并将这些价值观应用于其运营方式，那么它就是敏捷的。 如果不是，那么它就不是敏捷的。
我们也可以从否定的角度对待敏捷，并向杰夫·福克斯沃西（Jeff Foxworthy）道歉。 5如果您重视流程和工具的使用， 甚至重视个人交互，那么您就不是敏捷的。 如果您对综合文档的重视程度不亚于可运行的软件，则您不是敏捷的。 如果您比客户协作更重视合同谈判，那么您就不会敏捷。 如果您对执行计划的重视程度远胜于对变更做出的响应，那么您就没有敏捷性。
上面措词的关键是要注意，您不必比非敏捷特性更重视非敏捷特性。 您只需要至少将它们视为与敏捷特性一样的价值即可。 如果您从事的是系统工程项目，那么我认为您将重视坚持计划以及对变更做出响应。 您正在处理硬件和软件，需要努力按照时间表将它们组合在一起。 虽然更改软件可能很容易，但是更改硬件通常很困难，即使不是不可能。
因此，在这里我要说一下-我将接受敏捷社区的热捧-敏捷不是好事。 敏捷并不是要自己争取的东西。 您只是选择要为此而努力，因为它对您的项目和组织有意义。 当您在敏捷社区中与许多人交谈时，您会发现他们理解并同意。 但是，就像看到光明并想分享光明的传道人一样，他们的力量如此之强，以至于他们对信仰的热忱使您不知所措。
说您拥有某些价值观，而将这些价值观付诸实践是一回事。 如果您想变得敏捷，该宣言的作者添加了一组要遵循的原则。 6如果您遵循工作方式中的原则，则表示您表现出敏捷行为。
现在，让我们就在本文的其余部分中将用于敏捷和敏捷的定义达成一致。 敏捷的定义是保持敏捷宣言中定义的价值，并遵循一系列附带的原则-不多也不少。
什么地方出了错？
我刚才说的定义很简单。 那么，对于组织或项目是否敏捷，为什么会有如此混乱和矛盾的看法？ 问题的一部分是，原则的陈述方式留给了很多实践解释和实践空间。 让我们看看其中的几个。
一项原则说：“围绕有上进心的人建立项目。为他们提供所需的环境和支持，并信任他们能够完成工作。” 您如何实施这种做法？ 首先，您应该问什么是有动力的人 ？ 有些人仅仅是出于经济利益的动机。 其他人则是成为一支优秀团队的一部分。 一个团队的积极进取的个人可能会对另一个团队造成破坏。 如果您的组织已经预先选择了人才库，那么您可能无法在项目团队中拥有符合您的动机定义的人员。 你还能敏捷吗？
另一个原则是：“敏捷过程可以促进可持续发展。发起者，开发者和用户应该能够无限期地保持恒定的步伐。” 显然，如果我们将门槛定得较低并且不花力气，那么我们可以无限期地保持这一步伐。 这显然也不是该原则背后的意图。
我们可以单独采用大多数原则，并以某种方式扭曲它们，以违背敏捷精神。 但是，当作为一个完整的工作主体时，它们确实会相互支持。 但是，仍然有很多实施原则的空间。 这为敏捷教练，顾问，方法论者和其他想要帮助组织成为敏捷并采用顾问敏捷风格的人带来了丰厚的市场。 这也导致许多组织采用新的做法，并声称他们根据方法学家的解释实现了敏捷性。
拥有敏捷的解释很简单。 在一个有效的解释到达可能会更加困难。 我们没有一个单一的预言家可以要求您获得有关您的项目或组织是否敏捷的明确答案。 您真正要问的问题是，这有关系吗？ 如果您正在有效地生产满足所有涉众需求的软件，那么您的状况就很好。 您应该一直在寻求改进，但是您真的必须贴上标签吗？ 在尝试遵循CMM和CMMI，RUP和其他方法时，这一直是一个问题。 人员和组织会陷入某种程度的“认证”，而不是专注于最终目标-即交付软件。 方法论和实践是手段，不是目的。
好，就这么简单...
在明尼阿波利斯举行的Agile2006大会上提出的一个问题是：“如果敏捷性如此简单，那么为什么有那么多书告诉我们该怎么做？” 有人用嘲讽的口吻说了这一点，但是这个问题有一个严重的意义。 我在学校的办公室里坐着一个书架，几乎完全用来摆放敏捷类书籍。 有三十多个。 我家里的书房里还有大约十二个书名。 好多话。 为什么有这么多关于敏捷的书？
简单的答案是，书籍是顾问推销自己的好方法。 这也是学者和从业人员表达他们对某个主题的看法的一种方式。 书籍会影响人们，它们会影响最新技术和实践。 每当发现新概念时，书籍，期刊论文和文章自然就会随之而来。 对于那些影响很大的概念，会议应运而生。 技术领域是思想和后续书籍的特别沃土，因为，正如我在本文开头所指出的那样，对于我们这个IT行业的人来说，这很困难-忙于项目，按时完成任务，保持预算，一直在努力让客户满意-在没有良好的自我指导的情况下，紧跟最新的方法来实现我们的目标。
第二个答案是，许多声称对热点话题采取新方法的作者似乎在出版他们的书方面很成功。 结果，每本书都试图提出一些关于作者对价值观和原则的解释的新颖有趣的东西。 他们中的许多人提出了一种导致实施原则和价值观的方式。 像许多自助书一样，他们声称如果遵循他们的计划，您将变得敏捷。 如果您曾经尝试过不同的饮食，放松计划，阅读改善计划等等，那么您就会知道，对一个人有用的方法对另一个人无效。 许多关于敏捷性的书也是如此。 一种方法可能对项目A有效，但对项目B却失败了。如果合适的话，每个项目和组织都需要找到自己的敏捷方法。
无处不在的敏捷
今天的敏捷无处不在。 它是围绕软件开发的以太。 如果一项实践值得花时间和精力来学习和应用，那么它必须敏捷。 如果值得在我们的项目中学习和使用工具，则它必须支持敏捷性。 这不仅仅是实际问题，更是营销问题。 敏捷就像我们要购买的新品牌运动鞋，以帮助我们的开发团队跳得更高，跑得更快。
前几天我在一家书店里，买了一本关于Ruby编程语言的书。 在封底开始：“ Ruby是一种敏捷的面向对象编程语言。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。关心。 Ruby是否真的接受敏捷宣言中提出的价值观？ 从逻辑上讲，这似乎是一个荒谬的问题。 但是我们现在正在谈论营销，逻辑可能不是最重要的事情。 使用“敏捷”一词来吸引客户的注意力，这可以让您立足。 （我希望有一天，我们将培养出更聪明的客户，他们会提出正确的问题并以敏捷为视角。）
我不反对敏捷。 我也不是某些所谓的敏捷专家。 我想以为我是一个实用主义者，我会使用那些对我有帮助的东西，而丢弃那些对我没有帮助的东西。 有时，敏捷性会起作用。 有时我需要一些不同的东西。 我认为这是一个不错的地方。
顶级敏捷书籍和方法论
我想用本文的其余部分简要介绍敏捷领域中我认为很重要的那些书。 我会告诉您为什么我认为每个人都很重要，以及它能为您提供什么。 我将从一个较高的角度介绍该列表，该列表主要涉及敏捷性，其价值和原则。 然后，我将进一步研究特定的方法和实践。
敏捷价值观和原则书籍
敏捷软件开发：合作游戏，第二版。 ，Alistair Cockburn，Addison-Wesley Professional，2006年，ISBN 0321482751。
Alistair Cockburn的写作很好。 从最初的敏捷推动者之一的角度来看，本书提供了对敏捷性的最佳描述之一。 文字清晰且相当平衡。 Cockburn描述了敏捷性，并把它放在价值范围内的其他地方。 他熟练地指出了敏捷方法的最佳位置 ，它们为什么起作用以及从中受益。
科克本的治疗不是技术性的。 他没有涉及编码问题和很多细节。 他为您提供了足够的知识来使他们了解敏捷。 Cockburn以专注于软件开发中的人际关系问题而闻名，并花费大量时间讨论敏捷性的人方面。 如果有人对敏捷软件开发一无所知，那么我会向他们推荐这本书。
敏捷与迭代软件开发经理指南 ，克雷格·拉曼（Craig Larman），Addison-Wesley，2004年，ISBN 0131111558。
Craig Larman是软件开发（尤其是面向对象）实践的高级老师。 他精通不同的方法，并且知道如何以及何时应用它们。 在本书中，Larman讨论了迭代方法，Scrum，XP，RUP和Evo。 Scrum和XP正处于敏捷领域，而RUP和Evo更处于传统（计划驱动）迭代阵营。 Larman比较并对比了不同的方法，以帮助读者评估其收益并确定最适合特定类型的项目和组织的过程类型。
本书的后半部分对方法进行了比较。 前六章是本卷的黄金。 在这些章节中，Larman着眼于软件开发，敏捷性，迭代开发，并为读者提供了使用迭代和敏捷方法的证据。 证据来自研究，经验和其他来源。 拉曼显然已经完成了功课。
平衡敏捷与纪律》，《困惑的指南》 ，Barry Boehm和Richard Turner，Addison-Wesley，2004年，ISBN 0321186125。
本书将吸引那些来自大型组织和项目或在软件工程（而非软件开发）方面具有扎实背景的经理。 7 Boehm和Turner是具有大型项目经验的学者，其中许多人在国防工业中。 最佳位置 -他们试图找出哪里能最好地利用各类型的方法的地方接近的话题。 Boehm以其COCOMO项目估算模型的开发而闻名，并撰写了许多软件工程方面的开创性论文，其中包括介绍迭代开发的论文。 8
我在这本书上遇到的主要问题是，我对Boehm或Turner曾经从事过我通常花费时间的那种项目缺乏信心。 也就是说，少于10万行代码的代码。 他们将研究重点放在传统软件工程已发挥作用的大型项目上。 但是，我认为阅读本书非常重要，因为与本书中的大多数其他书籍相比，本书确实从不同的角度介绍了敏捷性。
敏捷方法论书籍
Scrum的敏捷软件开发 ，Ken Schwaber和Mike Beedle，Prentice Hall，2001年，ISBN 0130676349。
在过去的几年中，Scrum受到了很多关注。 这是一种非常简单的项目管理方法，与软件开发之间存在松散的联系。 在大多数情况下，Scrum包含了一些不是新的但严格执行的实践。 支持Scrum的人声称成功将其应用于各种规模的软件开发项目。 方法论中没有实践可以考虑技术实践。 它们都是关于项目管理的。
本书以Scrum，Schwaber和Beedle的发明者的话描述了Scrum方法。 Scrum的优点之一是它的实践可以与大多数其他实践结合使用。 值得读这本书只是为了让您了解有关敏捷项目如何进行项目管理的一些知识。
极限编程说明：拥抱变化，第二版。 ，肯特·贝克（Kent Beck）和辛西娅·安德烈斯（Cynthia Andres），Addison-Wesley Professional，2004年，ISBN 0321278658。
这本书的第一版可能对发起敏捷运动产生更大的影响。 实际上，许多从业人员已经将极限编程（XP）与敏捷相提并论。 对于软件开发人员而言，XP是最能解决他们感兴趣的问题的方法。贝克在第二版中得到安德烈斯（Andres）的帮助，描述了他最习惯使用或被认为最常用的基本实践。使用-软件开发人员中的敏捷方法论。 我提到它被认为是使用最多的，因为很少有组织可以实际将所有实践应用于他们的情况，但是他们仍然声称使用XP。
本书的第二版比第一版更丰富，在我看来并不是非常有用。 后一版本增加了有关XP基本方法论的策略和修改的更多材料。 这是不幸的。 如果您可以获得第一版的副本并且是敏捷方法的新手，那么我建议您阅读一下以获取XP的味道。
已安装Extreme Programming ，Ron Jeffries，Ann Anderson和Chet Hendrickson，Addison-Wesley Professional，2000年，ISBN 0201708426。
这是Addison-Wesley出版的大量与XP相关的书籍中的第二卷。 值得一读，因为它描述了XP实践以及原始XP项目团队的成员如何使用它们。 9这本书非常易读，您将了解XP项目的工作情况。 这本书使我确信XP实践的100％应用不是我会选择从事的项目类型。 这也使我确信我需要学习一些非常好的实践。 即使XP已经发展，这也是一本很棒的书，可以让经验不足的团队在首次XP航行之前先进行阅读。
练习专用书籍
测试驱动开发：实用指南 ，David Astels，Prentice Hall Ptr，2003年，ISBN 0131016490。
我认为测试驱动开发（TDD）是敏捷运动中最重要的实践之一。 它强调质量以及开发人员对质量的责任。 无论您采用哪种方法，它都需要在整个开发周期中始终关注质量。 这本书是对TDD的出色介绍。 它是使我相信它具有除简单测试之外的强大功能的工具。
使用JUnit进行Java中的实用单元测试 ，Andrew Hunt和David Thomas，The Pragmatic Programmers，LLC，2003年，ISBN 0974514012。
这对上一本书进行了补充，提供了有关如何真正实现TDD的实践的非常实用的建议。 《实用程序员》出版了一系列精彩的书籍，这些书籍直接与软件开发人员讨论最新技术的话题。 这本书是他们较早的出版物之一，对于任何想擅长编写单元测试的Java程序员来说都是必读的。 它将单元测试放在TDD的上下文中，并为读者提供编写，管理和自动化出色的单元测试所需的所有工具。
用户故事已应用 ，迈克·科恩，Addison-Wesley专业版，2004年，ISBN 0321205685。
用户故事似乎是许多敏捷项目选择的需求规范工具。 尽管其他方法（如用例）也是可以接受的。 用户故事是客户可以在索引卡上描述的一小部分功能。 这适合XP和其他敏捷方法的非常小的迭代方法。 就像编写用例一样，编写用户故事是必须学习和实践的技能。 Mike Cohn提供了我所见过的有关编写用户故事的最佳介绍。 他的书用于讲述用户故事，而Alistair Cockburn的书则用于案例。 10如果您使用用例，但还没有阅读Cockburn的书，那么Cohn会为您提供有关如何编写项目并将其应用到项目中的完整课程。 他使用了很多示例，他在实际项目中的经验也很明显。 如果您是分析师，甚至可能对用户故事感兴趣，则应该阅读本书。
《规划极限编程》 ，肯特·贝克（Kent Beck）和马丁·福勒（Martin Fowler），Addison-Wesley Professional，2000年，ISBN 0210710919。
XP项目的另一个关键实践是计划游戏 。 这是一组相当简单的活动，可帮助客户和团队确定每次迭代的内容，如何估算工作量以及如何跟踪结果，以便您可以更好地进行估算。 Beck和Fowler在描述实践的过程中做得很好，使开发人员，经理和XP团队的所有其他成员都感兴趣。
杂
以下两本书并不完全符合上述类别，但我发现它们都非常有用，并经常参考它们。 我将第二本用作我每年两次的软件工程课程的教科书。
敏捷软件开发原理，模式和实践 ，Robert C. Martin，Prentice Hall，2002年，ISBN 0135974445。
这是由开发人员的开发人员编写的书。 鲍勃·马丁（Bob Martin）是一位高级开发人员，对面向对象和敏捷原则有深刻的理解。 在本书中，Bob叔叔将两者结合在一起，为开发人员介绍了面向对象的设计原则，并深入介绍了如何在敏捷项目中使用它们。 这应该在每个开发人员的库中。
极限软件工程：一种动手方法 ，Daniel H. Steinberg和Daniel W. Palmer，Prentice Hall，2003年，ISBN 013047812。
这是一本小书，它对敏捷项目有相当平衡的了解，并且偏爱XP。 它的方法不是教条主义，而是试图表明敏捷性不是软件开发的偶然方法，也不是以任何旧方式做事的借口。 我发现这本书可供我的学生阅读，并留给我很多时间来强调我认为重要的软件开发方面。 这是一个很好的周末阅读。
结论
敏捷无处不在。 忽略它，您将在当前的技术对话中迷路。 了解它，您将能够就它是否适合您做出明智的决定。 您还将能够了解许多其他新兴的实践和方法。 如果您是任何级别的技术经理，这都是您的责任，也是生存的需要。
我敦促您开始阅读上面列出的书籍，以及Mary Poppendieck（精益开发），Scott Ambler（数据库），Jim Highsmith（管理实践）等作家的其他书籍，以及其他直接做出过贡献的作家加入敏捷运动，或制定与敏捷团队和项目“良好配合”的原则和实践。 我希望像我一样，您会发现一些可以给您带来想法的人，以便与您的人员，项目和组织一起尝试。 毫无疑问，您会发现很多书需要辞退-不是因为它们是错误的，而是因为它们不适合您的需求。 成为知情的消费者，您将为组织增加价值。
翻译自: https://www.ibm.com/developerworks/rational/library/mar07/pollice/index.html
1200
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
