| 词条 | 敏捷软件开发 |
| 释义 | 在这本书中，由享誉全球的软件开发专家和软件工程大师Robert C.Martin所著，他是敏捷开发的创始人之一。主要向读者展示如何解决软件开发人员、项目经理及软件项目领导们所面临的最棘手的问题。这本书是综合性、实用性的敏捷开发和极限编程方面的指南。 版权信息作 者：(美国)(AlistairCockburn)库克伯恩 出版社： 机械工业出版社 出版时间： 2008 ISBN: 9787111231660 开本： 16 定价: 52.00 元 又名: Agile Software Development: Principles, Patterns, and Practices 作者简介AlistairCockburn，国际知名软件项目管理方面的专家，用例技术，对象技术和敏捷方法大师，于2001年和2002年两次获得Jolt生产力奖。他是HumansandTechnology公司的资深顾问，负责帮助客户成功地进行面向对象项目。他在软硬件开发方面有20多年的项目管理经验，所涉及的领域有保险业，零售业，电子商务公司，并曾在大公司（如挪威中心银行和IBM）中任职。除本书外，他还著有《编写有效用例》（本书中文版已由机械工业出版社出版）、《OO项目求生法则》和《CrystalClear：小团队的敏捷开发方法》。 内容简介在这本书中，享誉全球的软件开发专家和软件工程大师Robert C.Martin将向您展示如何解决软件开发人员、项目经理及软件项目领导们所面临的最棘手的问题。这本综合性、实用性的敏捷开发和极限编程方面的指南，是由敏捷开发的创始人之一所撰写的。 ·讲述在预算和实践要求下，软件开发人员和项目经理如何使用敏捷开发完成项目； ·使用真实案例讲解如何用极限编程来设计、测试、重构和结对编程； ·包含了极具价值的可多次使用的C++和JAVA源代码； ·重点讲述了如何使用UML和设计模式解决面向客户系统的问题。 目录译者序 第2版前言 第1版前言 第0章不可知和不可说 0.1和解析体验相关的问题 0.1.1解析模式的冲突 0.1.2检测解析模式 0.1.3思考不准确的思想 0.2沟通的不可能性 0.2.1内部重新组织 0.2.2触及共享体验 0.2.3管理不完美的沟通 0.3聆听的三个层次 0.3.1三个层次和方法集 0.3.2三个层次与本书 0.3.3守-破-离 0.4那么，明天我做什么 第0A章不可知和不可说：演进 0A.1沟通和共享的体验 0A.2守-破-离 第1章创造和沟通的合作博弈 1.1软件和诗歌 1.2软件与博弈 1.2.1博弈的类型 1.2.2软件与攀岩 1.2.3创造和沟通的博弈 1.2.4软件与工程化 1.2.5软件与模型构建 1.3再论合作博弈 1.3.1程序员成为沟通专家 1.3.2更快地博弈 1.3.3标识物和道具 1.3.4减少回报 1.3.5对于首要目标的充分度 1.3.6对于积淀的充分度 1.3.7博弈中的博弈 1.3.8开放源码开发 1.4这对我意味着什么 第1A章创造和沟通的合作博弈：演进 1A.1沼泽游戏 1A.2合作中的竞争 1A.3其他领域的合作博弈 1A.4软件工程的重建 1A.4.1这一词汇从哪里来 1A.4.2我们从哪里走错了 1A.4.3重建软件工程 1A.4.4技艺 1A.4.5合作博弈 1A.4.6精益制造 1A.4.7重建后的软件工程 1A.4.8其他工程化中的协作 第2章个人 2.1人是古怪的 2.1.1寻找特征函数 2.1.2古怪性格的元素 2.1.3不可避免的多样性 2.1.4技术的作用 2.1.5相互冲突的共同点 2.2克服失败模式 2.2.1犯错误 2.2.2宁可失败也要选择保守 2.2.3创新而不研究 2.2.4不能始终如一的习惯动物 2.2.5使用纪律和容忍来应对 2.3以一些更好的方式工作 2.3.1具体化 2.3.2实物 2.3.3在某些东西的基础上进行修改 2.3.4观察和聆听 2.3.5支持专注和沟通 2.3.6工作分配要与个性相匹配 2.3.7天赋 2.3.8奖励要能保留乐趣 2.3.9组合奖励 2.3.10反馈 2.4利用成功模式 2.4.1善于四处寻找 2.4.2人们学习 2.4.3可塑性 2.4.4贡献和采取主动 2.4.5组合成功模式 2.4.6英雄也是普通人 2.5明天我该做什么 第2A章个人：演进 2A.1策略平衡 第3章团队的沟通与合作 3.1信息的对流 3.1.1延迟和机会损失成本 3.1.2尔格-秒 3.1.3渗透式沟通 3.1.4穿堂风 3.1.5信息辐射源 3.1.6热空气理论的应用 3.2跨越沟通的鸿沟 3.2.1沟通的形态 3.2.2去掉某些形态所产生的影响 3.2.3利用各种形态 3.2.4黏度与跨越空间的鸿沟 3.3团队就是集体 3.3.1友善和冲突 3.3.2工作时间的公民意识 3.3.3敌意的XP与友善的XP 3.3.4使用胜利来建立“团队” 3.3.5团队文化与亚文化 3.4团队就是生态系统 3.5我明天该做什么 第3A章团队：演进 3A.1一个修订后的办公室布局样本 第4章方法集 4.1一个交付软件的生态系统 4.2方法集中的概念 4.2.1结构术语 4.2.2范围 4.2.3概念术语 4.2.4发布一个方法集 4.3方法集的设计原则 4.3.1常见设计错误 4.3.2在方法集上成功的项目 4.3.3与作者的相关性 4.3.4七条原则 4.4细看XP 4.4.1XP简介 4.4.2剖析XP 4.4.3调整XP 4.5到底为什么使用方法集 4.5.1方法集解决什么问题 4.5.2如何评估一个方法集 4.6明天我应该做什么 第4A章方法集：演进 4A.1方法集与策略 4A.2组织级的方法集 4A.3过程就是循环 4A.4更简单地描述方法集 第5章敏捷与自适应 5.1轻但足够 5.1.1刚好足够 5.1.2对于编制文档的建议 5.2敏捷 5.2.1最佳击球点 5.2.2虚拟团队的麻烦 5.3变得自适应 5.3.1不厌其烦地进行反思 5.3.2方法集成长技术 5.3.3反思研讨会技术 5.4明天我该做什么 第5A章敏捷与自适应：演进 5A.1对于寓意的误解 5A.1.1迭代必须简短 5A.1.2敏捷团队必须驻扎在一起 5A.1.3敏捷团队不需要计划 5A.1.4架构已死；重构是你全部所需要的 5A.1.5我们不需要什么经理 5A.1.6敏捷开发在纪律上要求很低 5A.1.7敏捷只适合最优秀的开发人员 5A.1.8敏捷是既老又新的、失败的、没有尝试过的 5A.2敏捷方法集的演进 5A.2.1XP第2版 5A.2.2Scrum 5A.2.3实用主义和无名的 5A.2.4可预测、计划驱动和其他中心调整 5A.2.5约束理论 5A.2.6精益开发 5A.3新的方法集话题 5A.3.1敏捷项目管理 5A.3.2测试 5A.3.3用户体验设计 5A.3.4规划管控、Burn图和系统工程 5A.3.5用例和用户故事 5A.4经久不绝的问题 5A.4.1最佳击球点和下降 5A.4.2固定价格、固定范围的合同 5A.4.3敏捷、CMMI和ISO9001 5A.4.4何时停止建模 5A.4.5高科技/高接触的工具箱 5A.4.6敏捷的中心 5A.4.7你有多敏捷 5A.4.8引入敏捷 5A.5软件开发之外的敏捷 5A.5.1项目组合管理 5A.5.2客户关系 5A.5.3合同 5A.5.4将变更引入组织 5A.5.5程序员读哈佛商业周刊 5A.5.6建造房屋 5A.5.7机场建设 5A.5.8图书出版 5A.5.9会议组织和敏捷模型的限制 第6章Crystal方法集 6.1对Crystal家族塑形 6.1.1核心Crystal元素 6.2CrystalClear 6.2.1CrystalClear的简要描述 6.2.2CrystalClear的反思 6.3CrystalOrange 6.3.1CrystalOrange的简要描述 6.3.2CrystalOrange的反思 6.4CrystalOrangeWeb 6.4.1CrystalOrangeWeb的简要描述 6.4.2CrystalOrangeWeb的反思 6.5明天我该做什么 第6A章Crystal方法集：演进 6A.1Crystal基因代码 6A.1.1合作博弈的理念 6A.1.2方法集的重点 6A.1.3方法集设计原则 6A.1.4高度成功的项目的7个特性 6A.1.5技术与选择 6A.1.6样本方法集设计 6A.2CrystalClear 6A.3把CrystalClear扩展到Yellow 附录A敏捷软件开发宣言 附录Aa敏捷软件开发宣言和相互依赖声明 附录BNaur、Ehn、宫本武藏 附录BaNaur、Ehn、宫本武藏：演进 附录C后记 参考文献 …… ---------------------------------------------------- 敏捷软件开发又称敏捷开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。 词源敏捷一词来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。 极限编程。 价值观雪鸟会议共同起草了敏捷软件开发宣言。其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述： 人和交互重于过程和工具。可以工作的软件重于求全责备的文档。客户协作重于合同谈判。随时应对变化重于循规蹈矩。其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。 原则宣言中还包括以下原则： 对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。可以工作的软件是进度的主要度量标准。敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。对卓越技术与良好设计的不断追求将有助于提高敏捷性。简单--尽可能减少工作量的艺术至关重要。最好的架构、需求和设计都源自自我组织的团队。每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。 对比其他的方法敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。 适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化. 对比迭代方法相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。 对比瀑布式开发两者没有很多的共同点，瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。 瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。 相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。 有人可能在这样小规模的范围内的每次迭代中使用瀑布式方法，另外的人可能将选择各种工作并行进行，例如 敏捷方法的适用性在敏捷方法其独特之处以外，他和其他的方法也有很多共同之处，比如迭代开发，关注互动沟通，减少中介过程的无谓资源消耗。通常可以在以下方面衡量敏捷方法的适用性：从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；从组织结构的角度看，组织结构的文化、人员、沟通则决定了敏捷方法是否适用。跟这些相关联的关键成功因素有： 组织文化必须支持谈判人员彼此信任，人少但是精干，开发人员所作决定得到认可，环境设施满足成员间快速沟通之需，要最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，20、40人或者更少。大规模的敏捷软件开发尚处于积极研究的领域。 另外的问题是项目初期的大量假定或者快速收集需求可能导致项目走入误区，特别是客户对其自身需要毫无概念的情况下。与之类似，人之天性很容易造成某个人成为主导并将项目目标和设计引入错误方向的境况。开发者经常能把不恰当的方案授予客户，并且直到最后发现问题前都能获得客户认同。虽然理论上快速交互的过程可以限制这些错误的发生，但前提是有效的负反馈，否则错误会迅速膨胀。 方法列表目前列入敏捷方法的有： 软件开发节奏，Software Development Rhythms敏捷数据库技术，AD/Agile Database Techniques敏捷建模，AM/Agile Modeling自适应软件开发，ASD/Adaptive Software Development水晶方法，Crystal特性驱动开发，FDD/Feature Driven Development动态系统开发方法，DSDM/Dynamic Systems Development Method精益软件开发，Lean Software DevelopmentScrum测试驱动开发，TDD/Test-Driven DevelopmentXBreed极限编程，en:XP/en:Extreme Programming 外部链接敏捷联盟 (英语，Agile Alliance) |
| 随便看 |
百科全书收录4421916条中文百科知识，基本涵盖了大多数领域的百科知识，是一部内容开放、自由的电子版百科全书。