敏捷建模 极限编程和统一过程的有效实践 (2008 年度畅销榜NO.2785 )

敏捷建模（AM）是一种基于实践的过程，它描述了怎样才能够成为一个高效的建模人员。本书研究了AM的价值观、原则和实践，描述了用来提高建模人员工作效率的技术，而且书中还重新思考了与软件开发有关的几个重要问题，例如，怎样编写文档、怎样组织建模会议和建模团队以及UML适用于什么地方等。此外，还详细研究了怎样在XP项目中有效地建模，并解释了怎样在采用Rational统一过程（RUP）或者企业统一过程（EUP）的项目中简化建模工作。本书既适用于想知道在XP项目中怎样建模以及在RUP项目中怎样简化建模工作的开发人员和建模人员，也适用于想了解“敏捷开发”的项目经理和过程专家。
在这本具有创新思想的书中，Scott w. Ambler谈到如何做到以下几点：
◆ 坚定不移地采用快速移动和敏捷软件开发方法来为XP项日建模
◆ 将建模规程简单化，将UP的工作流程简单化，而同时又不会失去这些规程所带来的真正益处
◆ 利用建模来探索问题的解决方案或使交流更容易
◆ 有效地应用UML，并将其延伸到其他方法学中，更好地满足你的开发需要
◆ 通过编写敏捷文档来减轻在项目中建立文档的负担
◆ 使用简单建模工具，如索引卡片和白板，并且知道何时
◆ 使用复杂的CASE工具
◆ 重新考虑有关工作区域、建模团队和建模会议等问题

第一部分 敏捷建模简介\r\n第1章 绪论 3\r\n1.1 进入敏捷软件开发 5\r\n1.1.1 敏捷软件开发宣言 5\r\n1.1.2 敏捷软件开发的原则 6\r\n1.2 敏捷建模 7\r\n1.2.1 谁是敏捷建模人员 9\r\n1.2.2 敏捷建模概述 9\r\n1.2.3 什么是敏捷模型 10\r\n1.2.4 什么是（或不是）敏捷建模 12\r\n1.3 SWA在线案例研究 14\r\n1.4 本书概览 14\r\n第2章 敏捷建模的价值观 17\r\n2.1 交流 17\r\n2.2 简单 18\r\n2.3 反馈 19\r\n2.4 勇气 20\r\n2.5 谦虚 22\r\n2.6 老生常谈之后 22\r\n第3章 核心原则 25\r\n3.1 软件是你的首要目标 25\r\n3.2 支持后续工作是你的第二目标 26\r\n3.3 轻装前进 26\r\n3.4 主张简单 27\r\n3.5 包容变化 27\r\n3.6 递增的变化 28\r\n3.7 有目的地建模 28\r\n3.8 多种模型 29\r\n3.9 高质量的工作 31\r\n3.10 快速反馈 31\r\n3.11 最大化项目关系人的投资 33\r\n3.12 为什么需要核心原则 33\r\n第4章 补充原则 35\r\n4.1 内容比形式更重要 35\r\n4.2 每个人都可以向别人学习 37\r\n4.3 了解你的模型 37\r\n4.4 适应本地情况 38\r\n4.5 开放和诚实的交流 38\r\n4.6 相信直觉 38\r\n4.7 从这些原则中获益 39\r\n第5章 核心实践 41\r\n5.1 迭代和增量建模的实践 42\r\n5.1.1 使用合适的制品 42\r\n5.1.2 并行创建多个模型 43\r\n5.1.3 迭代到其他的制品中 45\r\n5.1.4 小增量建模 47\r\n5.2 有效团队协作的实践 47\r\n5.2.1 与他人一起建模 47\r\n5.2.2 项目关系人的积极参与 48\r\n5.2.3 集体所有 49\r\n5.2.4 公开展示模型 50\r\n5.3 简单性的实践 50\r\n5.3.1 创建简单的内容 50\r\n5.3.2 简单地描述模型 51\r\n5.3.3 使用最简单的工具 52\r\n5.4 验证工作的实践 52\r\n5.4.1 考虑可测试性 53\r\n5.4.2 用代码验证 53\r\n第6章 补充实践 55\r\n6.1 提高生产率的实践 55\r\n6.1.1 应用建模标准 55\r\n6.1.2 渐进地应用模式 57\r\n6.1.3 复用已有的制品 58\r\n6.2 敏捷文档的实践 58\r\n6.2.1 丢弃临时模型 58\r\n6.2.2 契约模型正式化 59\r\n6.2.3 在有危害时才更新模型 60\r\n6.3 有关动机的实践 62\r\n6.3.1 通过建模来理解 62\r\n6.3.2 通过建模来交流 63\r\n6.4 真正的好主意 64\r\n6.4.1 了解工具 64\r\n6.4.2 重构 64\r\n6.4.3 测试优先设计 64\r\n6.5 如何在项目中安排敏捷建模的\r\n实践 64\r\n第7章 从混乱到有序：AM的实践如何\r\n结合到一起 67\r\n7.1 核心实践 67\r\n7.1.1 与高效团队协作相关的实践 68\r\n7.1.2 与迭代和增量开发相关的实践 68\r\n7.1.3 促进简单性的实践 69\r\n7.1.4 验证工作的实践 69\r\n7.2 补充实践 69\r\n7.2.1 与文档相关的实践 69\r\n7.2.2 与动机相关的实践 70\r\n7.2.3 提高生产率的实践 70\r\n7.3 各类实践如何关联 70\r\n7.4 混乱而有序：Chaordic 71\r\n7.5 展望 72\r\n第二部分 实践中的敏捷建模\r\n第8章 交流 75\r\n8.1 怎样交流 75\r\n8.2 影响交流的因素 76\r\n8.3 交流与敏捷建模 78\r\n8.4 有效的交流 78\r\n第9章 培养敏捷文化 81\r\n9.1 消除有关建模的误解 81\r\n9.1.1 误解1：模型＝文档 81\r\n9.1.2 误解2：可以在一开头就把什么\r\n都想清楚 82\r\n9.1.3 误解3：建模意味着重量级软件\r\n过程 82\r\n9.1.4 误解4：必须“冻结”需求 82\r\n9.1.5 误解5：设计是“刻在石头里”的 82\r\n9.1.6 误解6：必须使用CASE工具 83\r\n9.1.7 误解7：建模是浪费时间 84\r\n9.1.8 误解8：世界绕着数据建模转 84\r\n9.1.9 误解9：开发人员都知道怎样\r\n建模 85\r\n9.2 从小处着眼 85\r\n9.3 放松一点要求 86\r\n9.4 坚决支持项目关系人的权利和义务 87\r\n9.5 重新考虑给项目关系人的报告 88\r\n第10章 使用可能的最简单的工具 91\r\n10.1 用简单工具敏捷建模 92\r\n10.1.1 简单工具的优点 92\r\n10.1.2 简单工具的缺点 93\r\n10.1.3 何时应该使用简单工具 93\r\n10.1.4 用技术支持简单工具 93\r\n10.2 模型的演化 95\r\n10.3 用CASE工具敏捷建模 99\r\n10.3.1 选择CASE工具 99\r\n10.3.2 克服关于CASE工具的误解 100\r\n10.3.3 生成源代码 101\r\n10.3.4 生成文档 102\r\n10.4 使用媒体 102\r\n10.5 在模型上使用工具的影响 103\r\n10.6 在实践中使用最简单的工具 103\r\n第11章 敏捷工作区域 105\r\n11.1 敏捷建模室 105\r\n11.2 有效的工作区域 107\r\n11.3 在实践中应用 108\r\n第12章 敏捷建模团队 111\r\n12.1 招募少量优秀的开发人员 111\r\n12.2 认识到在敏捷中没有“我” 114\r\n12.3 要求每个人积极参与 115\r\n12.4 团队一起建模 116\r\n12.5 在实践中应用 117\r\n第13章 敏捷建模会议 119\r\n13.1 建模会议持续时间 119\r\n13.2 建模会议的类型 120\r\n13.3 建模会议的参加者 122\r\n13.4 建模会议的正式程度 124\r\n13.5 在实践中应用 125\r\n第14章 敏捷资料 127\r\n14.1 人们为什么写文档 128\r\n14.2 模型什么时候成为永久文档 130\r\n14.2.1 与资料相关的考虑因素有哪些 132\r\n14.2.2 “轻装前进”是什么意思 134\r\n14.2.3 一份文档什么时候是敏捷的 136\r\n14.2.4 应该创建什么类型的文档 137\r\n14.2.5 何时应该更新文档 140\r\n14.2.6 有效的资料传递 141\r\n14.2.7 增加资料敏捷性的策略 141\r\n14.2.8 在实践中应用 144\r\n第15章 UML及其延伸 145\r\n15.1 UML并不充分 145\r\n15.2 UML过于复杂 147\r\n15.3 UML并非方法学也不是过程 147\r\n15.4 别再想着可执行UML\r\n（至少现在） 148\r\n15.5 在实践中应用UML 149\r\n第三部分 敏捷建模和极限编程（XP）\r\n第16章 澄清事实 153\r\n16.1 建模是XP的一部分 154\r\n16.2 文档是必需的 154\r\n16.3 XP和UML 156\r\n16.4 结论 157\r\n第17章 敏捷建模与极限编程 159\r\n17.1 AM和XP之间潜在的契合 159\r\n17.2 重构和AM 161\r\n17.3 测试优先开发和AM 161\r\n17.4 应该采取哪些AM实践 162\r\n第18章 贯穿XP生命周期的敏捷建模 163\r\n18.1 探索阶段 164\r\n18.2 计划阶段 164\r\n18.3 迭代到发布阶段 166\r\n18.4 产品化阶段 168\r\n18.5 维护阶段 169\r\n18.6 如何应用 169\r\n第19章 XP探索阶段的建模 171\r\n19.1 优先定义初始需求 171\r\n19.2 比喻. 架构和骨架 174\r\n19.3 为项目设定一个基础 176\r\n第20章 XP迭代中的建模：条目搜索 177\r\n20.1 任务 177\r\n20.2 物理数据库模式建模 178\r\n20.3 观察到的事实 181\r\n第21章 XP迭代中的建模：订单求和 183\r\n21.1 任务 183\r\n21.2 用需求建模来补救 184\r\n21.3 从外界专家那里寻求帮助 185\r\n21.4 简短的设计会议 186\r\n21.5 契约模型正式化 187\r\n21.6 将来有变化怎么办 188\r\n21.7 观察到的事实 189\r\n21.8 如何在实际工作中应用 189\r\n第四部分 敏捷建模和统一过程\r\n第22章 敏捷建模和统一过程 193\r\n22.1 在统一过程中如何建模 193\r\n22.2 AM与UP的契合到底有多好 194\r\n22.3 选择变得敏捷些 197\r\n第23章 贯穿统一过程生命周期的\r\n敏捷建模 199\r\n23.1 建模规程 199\r\n23.1.1 业务建模规程 200\r\n23.1.2 需求规程 201\r\n23.1.3 分析和设计规程 202\r\n23.1.4 基础设施管理规程 203\r\n23.2 非建模规程 204\r\n23.2.1 实现规程 204\r\n23.2.2 测试规程 205\r\n23.2.3 项目管理规程 205\r\n23.2.4 配置和变更管理规程 205\r\n23.2.5 环境规程 206\r\n23.2.6 部署规程 206\r\n23.2.7 运行和支持规程 206\r\n23.3 如何应用 207\r\n第24章 敏捷业务建模 209\r\n24.1 一个业务/基本用例模型 209\r\n24.2 一个简单的业务对象模型 211\r\n24.3 一份敏捷的补充业务规格说明书 212\r\n24.4 一个业务愿景 214\r\n24.5 如何在实践中应用 215\r\n第25章 敏捷需求 217\r\n25.1 上下文模型 217\r\n25.2 用例模型 220\r\n25.3 用例故事板 223\r\n25.4 补充规格说明书 226\r\n25.5 如何在实践中应用 227\r\n第26章 敏捷分析和设计 229\r\n26.1 在统一过程中重新考虑分析和设计\r\n模型 230\r\n26.2 架构建模 231\r\n26.3 创建用例实现 235\r\n26.4 是更新用例的时候了吗 238\r\n26.5 是使用CASE工具的时候了吗 241\r\n26.6 设计类建模 242\r\n26.7 数据建模 244\r\n26.8 包容变化 246\r\n26.9 如何在实践中应用 247\r\n第27章 敏捷基础设施管理 249\r\n27.1 基础设施模型 249\r\n27.2 基础设施建模 251\r\n27.2.1 自顶向下建模 252\r\n27.2.2 自底向上建模 252\r\n27.2.3 比较这两种方式 252\r\n27.3 设定建模标准和指导原则 253\r\n27.4 核心基础设施团队 254\r\n27.5 采用敏捷建模的核心架构团队 255\r\n27.6 如何在实践中应用 256\r\n第28章 在统一过程项目中采用敏捷\r\n建模 259\r\n第五部分 展望\r\n第29章 采用敏捷建模或者克服逆境 265\r\n29.1 估算契合程度 265\r\n29.1.1 认识到敏捷建模什么时候管用 266\r\n29.1.2 认识到敏捷建模什么时候\r\n不管用 267\r\n29.2 保持简单 268\r\n29.3 克服组织结构上的和文化上的挑战 268\r\n29.3.1 持怀疑态度的开发人员 269\r\n29.3.2 过分热心的过程警察 269\r\n29.3.3 有权力的催着要纸的人 270\r\n29.3.4 菜谱哲学 270\r\n29.3.5 不能接受批评 271\r\n29.3.6 由于害怕失去所有的人而导致\r\n过度的文档 271\r\n29.4 克服与项目有关的挑战 272\r\n29.4.1 分布式的开发 272\r\n29.4.2 移交给其他团队 273\r\n29.4.3 固定价格契约 274\r\n29.5 考虑完全采用AM之外的其他途径 274\r\n29.6 如何在实践中应用 275\r\n第30章 结论：决心成功 277\r\n30.1 对敏捷建模常见的误解 277\r\n30.2 什么时候是（或不是）在敏捷建模 278\r\n30.3 敏捷建模资源 279\r\n30.4 几个临别的想法 279\r\n附录A 建模技术 281\r\n词汇表 291\r\n参考文献 301

如果你正在读这个前言, 那你很可能是想确定是不是应该买这本书, 我喜欢你的态度！为了帮助你做出这个决定, 我将很快地回答几个你最可能会问的重要问题. 什么是敏捷建模 敏捷建模（Agile Modeling, AM）是一种基于实践的过程, 它描述了怎样才能够成为一个高效的建模人员. 当前的建模方法经常被证明有“功能障碍”, 一个极端是根本就没有建模存在, 当软件被证明是没有经过很好思考的时候, 这经常会导致大量的返工, 另一个极端是生成过多的模型和文档, 这让开发工作慢得像蜗牛一样. AM帮你找到建模的最佳点, 在这一点上你既进行了足够的建模, 以保证有效地研究和记录系统, 但又没有过多地建模以致变成减慢项目进度的负担. 想要在软件开发上采用敏捷方法的项目团队能够并且也应该使用AM的技术, 特别是那些遵循极限编程（XP）. DSDM. SCRUM或FDD等敏捷过程的团队. 即使在没有采用纯敏捷方法的项目中, 也能用AM来改进而且能够经常简化建模工作. 这本书讲了什么 这本书一开始研究了AM的价值观. 原则和实践, 描述了用来提高建模人员工作效率的技术. 尽管可能害怕向别人承认, 但你很可能会发现, 自己实际上已经在遵循其中的一部分实践, 你也很可能会发现新的有效建模的方法. 这本书也重新思考了与软件开发有关的几个重要问题, 例如, 怎样写文档. 怎样组织建模会议和建模团队, 以及UML适用于什么地方等. 正如这本书的标题所表达的, 它详细研究了怎样在XP项目中有效地建模, 与你可能听到过的恰好相反, 建模是XP的一个重要组成部分. 这本书还解释了怎样在采用Rational统一过程（RUP）或者企业统一过程（RUP）的项目中简化建模工作. 这本书没讲什么 这本书没有告诉你怎样创建模型. 例如, 它没有描述写用户故事. 用例以及业务规则的步骤. 这本书也没有打算成为对UML. 数据建模或者以用法为中心的设计（usage-centered design）的介绍. 这本书着眼于更大的图景, 着眼于建模的过程, 而不是微小的细节. 这非常与XP描述了开发软件的过程, 但没有描述怎样实际去写程序非常类似. 而且, 这本书与你以前读过的任何关于软件建模的书都不同. 以前讲建模方法学的书一般是先描述几个建模制品, 例如, 用例. 顺序图. 类图等, 然后描述一个使用这些制品建模软件的方法. AM采取了一种完全不同的方式, 它描述了建模的技术, 但对于创建模型的类型并不坚持要求. AM只是建议你学习怎样使用种类广泛的建模制品, 并努力随着时间不断往你的知识工具箱里加入更多的东西. 在其他建模技术随着其下层技术的变化而消失的同时, 我相信你会发现AM的原则和实践能够经受住时间的考验, 因为它们是真正基础的东西. 我是谁 虽然住在加拿大多伦多北面, 但我却是位于丹佛市的Ronin International公司的高级顾问和总裁. 我从20世纪80年代中期开始就一直在开发软件, 从20世纪90年代初开始就一直在建造面向对象软件. 我积极地与客户合作创建用于关键任务的软件, 并且利用业余时间在书. 杂志和在线白皮书中写一些与自己经验有关的内容. 最近几年我一直致力于软件过程问题, 包括统一过程（UP）等指令性过程以及极限编程（XP）等敏捷过程, 帮助各种组织机构, 使他们在软件开发方法上变得更加有效. 我也喜欢在软件项目中扮演积极的角色, 身为高级开发人员或团队负责人, 只要可能我就会卷起袖子干活. 你是谁 你很可能是一个开发人员或建模人员, 很想要提高自己作为一个软件专业人员的效率. 你想知道在XP项目中怎样建模, 或者在RUP项目中怎样简化建模工作. 你甚至有可能是一个项目经理或者过程专家, 想要了解“敏捷开发这东西”到底是怎么回事.