敏捷软件开发(原书第2版)

【内容简介】

本书提示了敏捷软件开发的真正内涵。全书以“软件是创造和沟通的合作博弈”为中心向读者展示一个看待软件开发的崭新视角。全书共13章，包括创造和沟通的合作博弈、个人、团队的沟通与合作、方法集、敏捷与自适应、以及Crystal方法集等内容。
　　本书适合软件开发人员、管理人员、架构师等技术人员参考。

【编辑推荐】

第17届Jolt大奖获奖作品，大师Cockburn讲授敏捷开发之道。
　　“这是一本激动人心的书。作者以其丰富的实践经验，为我们提供了一部融合敏捷方法的力作。”
　　　　　　　　　　　　　　　　　　　　——Tom Gilb，著名的软件工程和系统工程专家
本书是国际知名软件开发专家Alistair Cockburn通过采访项目开发组和总结自己20多年的开发和管理经验，撰写的一本介绍软件开发新思想——敏捷软件开发方法学的著作。
本书从更新软件开发就是“创造和沟通的合作博弈”这一强大的模型开始。在这些新观念之中，Cockburn引入了：利用竞争产生动力而不破坏合作，从精益制造中学习教训以及为了沟通而平衡战略。作者还解释了如何在业务和工程项目上而不仅仅是在软件开发上进行合作博弈。
作者系统地演示了敏捷模型，展示了敏捷模型的演进，并且回答了开发人员和项目经理最常提出的问题，其中包括：
·哪些地方适合敏捷开发？
·如何将敏捷观念与其他观念融合在一起？
·如何对敏捷观念进行扩展？
书中呈现了造成很多敏捷项目失败的至关重要的错误概念。例如，将项目管理策略编码到固定的过程中会导致低效率的战略决策和高成本的错误。此外，本书还深入讨论了关于敏捷方法和用户体验设计之间的有争议的关系。
Cockburn讨论了为团队建立敏捷方法学这一实践上的挑战，解释了如何对方法学进行调整并持续地再创造，以及如何管理不完全的沟通。
第2版主要增加了以下内容：
·敏捷与CMMI。
·自顶向下地介绍敏捷。
·重访“客户合同”。
·用“贴纸”来创建变更。
另外，Cockburn还更新了关于Crystal方法学的讨论，这种方法利用了“合作博弈”作为其核心的隐喻。
无论是敏捷开发新手，还是有经验的软件开发人员和项目管理人员，都会从本书中受益。

【作译者介绍】

【目录信息】

译者序
第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.1 XP简介
　　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.1 XP第2版
　　5A.2.2 Scrum
　　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.2 Crystal Clear
　　6.2.1 Crystal Clear的简要描述
　　6.2.2 Crystal Clear的反思
　6.3 Crystal Orange
　　6.3.1 Crystal Orange的简要描述
　　6.3.2 Crystal Orange的反思
　6.4 Crystal Orange Web
　　6.4.1 Crystal Orange Web的简要描述
　　6.4.2 Crystal Orange Web的反思
　6.5 明天我该做什么
第6A章 Crystal方法集：演进
　6A.1 Crystal基因代码
　　6A.1.1 合作博弈的理念
　　6A.1.2 方法集的重点
　　6A.1.3 方法集设计原则
　　6A.1.4 高度成功的项目的7个特性
　　6A.1.5 技术与选择
　　6A.1.6 样本方法集设计
　6A.2 Crystal Clear
　6A.3 把Crystal Clear扩展到Yellow
附录A 敏捷软件开发宣言
附录Aa 敏捷软件开发宣言和相互依赖声明
附录B Naur、Ehn、宫本武藏
附录Ba Naur、Ehn、宫本武藏：演进
附录C 后记
参考文献

<< 查看详细目录

【译者序】

作为《敏捷软件开发宣言》和《相互依赖声明》的合著者，Alistair Cockburn的这本书揭示了敏捷的真正内涵。.
“软件是创造和沟通的合作博弈”，这一隐喻向我们展示了一个看待软件开发的崭新视角，它告诉我们：软件开发的首要目标是交付有用、可工作的软件，次要目标是为下一轮博弈做好准备。因为“编程就是构建理论”，而“理论”中的大部分意会知识不能或很难用文档来传达，而要靠沟通来传达，所以提高信息沟通的效率就提高软件开发效率的最有效的方式。
人不是生产线上的智能机器，人的特点是：人在沟通、学习和解决问题方面都不同于智能机器。以管理生产设备的方式管理人，显然不能最大程度地发挥人的潜能。<.. << 查看译者序

【前言】

2001年，软件开发的敏捷模型给世界带来了一场风暴。一年中，全世界出现了很多关于敏捷的著作和会议。在5年中，它影响了每一件事，从项目管理和公司经理们如何编写与客户的合同，到军事采购的过程，甚至到大学的课程。.
是该看一下都发生了什么变化的时候了，看一下我们能从敏捷模型和（更具普遍意义的）合作博弈中学到什么。
在2001年2月写《敏捷软件开发的宣言》的时候，我已经深入到了编写一本关于“软件开发就是合作博弈”和“剪裁方法集以适合不同的项目”的书之中。这一宣言只不过是对我和其他人已经在做的事情的附和。
敏捷模型给世界带来了风暴。数以百计的开发人员在网上的签名板上签名（最.. << 查看前言

【免费试读】

第02章免费试读   第01章免费试读  
>>进入在线免费试读

【相关资源】

· 程序员的7种武器(正则表达式、编程语言、数据库、算法、软件调试、开发环境)
敏捷软件开发(原书第2版) -所有相关信息