软件工程导论---极限编程

极限编程

• 创始者是肯特·贝克（Kent Beck）、沃德·坎宁安（ Ward
Cunningham）和罗恩·杰弗里斯（Ron Jeffries），他们在
为克莱斯勒综合报酬系统（Chrysler Comprehensive
Compensation System )(C3) 的薪水册项目工作时提出了极
限编程方法。
• Kent Beck在1996年3月成为C3的项目负责人，开始对项目
的开发方法学进行改善。他写了一本关于这个改善后的方法
学的书，并且于1999年10月将之发行，这就是《解析极限编
程》。

• 极限编程将开发阶段的4个活动（分析、设计、编码和测试）
混合在一起，在全过程中采用迭代增量开发、反馈修正和反
复测试。

《极限编程解析》（2005第二版出版）阐述了如下的极致编程的哲学思想 ：

一种社会性的变化机制

一种开发模式

一种改进的方法

一种协调生产率和人性的尝试

一种软件开发方法

五个准则：

（改善）沟通

• 项目相关人员之间充分的多渠道的的沟通。

（寻求）简单

• 选择最简单的设计和实现来处理客户的需要。

（获得）反馈

• 来自系统的反馈：通过编写单元测试，程序员能够很直观的
得到经过修改后系统的状态。
• 来自客户的反馈：功能性测试是由客户还有测试人员来编写
的。这样的评审一般计划2、3个礼拜进行一次，这样客户可
以非常容易的了解、掌控开发的进度。
• 来自小组的反馈：当客户带着新需求来参加项目计划会议时，
小组可以直接对于实现新需求所需要的时间进行评估然后反
馈给客户。

（富有）勇气

• 面对压力作正确的判断并敢于付诸行动，如尽早地和经常交付功
能的承诺，敢于丢弃设计不良的代码等。

（互相）尊重（最新添加的价值）

• 尊重的价值在极限编程中，团队成员间的互相尊重体现在每
个人保证提交的任何改变不会导致编译无法通过、或者导致
现有的测试case失败、或者以其他方式导致工作延期。
• 团队成员对于他们工作的尊重体现在他们总是坚持追求高质
量，坚持通过重构的手段来为手头的工作找到最好的解决设
计方案。

十二条原则：

简单设计

• 为已定义的功能进行设计，而不是为潜在地未来可能
的功能进行设计。
• 最简单的设计将软件的一个可测试版本交付给用户。
• 创建最佳的可以实现功能的设计。

重构

• 重构是以不改变软件外部行为而改进其内部结构的方
式来修改软件系统的过程。为减少引入错误、减少冗
余、提高性能等目的，随时调整、优化系统的结构。

结对编程

• 所有的程式码都是由两
个人坐在一台电脑前一
起完成的。一个程式设
计师控制电脑并且主要
考虑编码细节。另外一
个人主要关注整体结构，
不断的对第一个程序设
计师写的程序进行评审。
结对编程的好处
 有助于提升代码设计质量；
 研究表明结对生产率比两个单人总和低 15%，
但缺陷数少 15%，考虑修改缺陷工作量和时间
都比初始编程大几倍，所以结对编程总体效率
更高（source: The Economist）；
 结对编程能够大幅促进团队能力提升和知识传
播。

代码集体所有

• 项目组中的每个人都可以在任何时候修改其他项目成员的代
码，这就是XP中所定义的代码共享。
• 强调所有的人都对代码负责。如果一个开发人员的代码有错
误，另外一个开发人员也可以进行BUG的修复。 提高了代
码的透明度，增进了团队的合作精神。一定要有严格的配置
管理。

持续集成

• XP实践者将每日集成作为最大
要求，选择每两个小时一次的
频繁编链。
• 冒烟测试

持续集成的好处

 大幅缩短反馈周期，实时反映产品真实质量状态；
 缺陷在引入的当天就被发现并解决,降低缺陷修改成
本；
 将集成工作分散在平时，通过每天生成可部署的软
件；，避免产品最终集成时爆发大量问题。

要点

坚持自动化是持续集成质量 保障；
 修复失败的构建是团队最高优先级的任务；
 开发人员须先在本地构建成功，才可提交代码到配
置库 ；
 持续集成的状态必须实时可视化显示给所有人；

每周工作40小时

• 程序员在疲劳时无法
保证最高效率。连续
两周加班是绝对不允
许的 。

现场客户

• 客户应该时刻在现场解决问题 。

测试驱动开发

• XP使用两种测试：单元测试和功
能测试。单元测试要求在写代码
之前就开发出相应功能的测试方
法，并且测试应当是自动化的。
代码一完成，它就被立即用有关
测试集加以测试，从而能立即得
到反馈。

策划游戏

• 每三周为一个循环，频繁地更新，按优先级划分任务与技术，
分配stories（一个story定义了一个特殊的功能需求并以一
种简单的方式记录在卡片上），所有的这些就是构成了XP中
的计划。通过结合使用优先级“故事”和技术估算，确定下
一版本的功能

小型发布

• 以小的增量版本经常向客户发布软件。每个版本应该尽可能
的小，而且包含最有商业价值的需求 。
1.4.4.5 极限编程

系统隐喻

• 通过提供类似系统全局的视图来指导系统的开发。
• 例：拼图时，尽管也能够痛苦的完成，但如果有了原图则拼
图非常轻松。原图就类似系统隐喻。

程序设计标准

• 程序员采用一致的编码标准。

误解

敏捷是拯救任何项目的银弹

– 敏捷方法只有运用得当才有效果

敏捷意味着 ad-hoc hacking ，不需要任何文档.

– 敏捷是有严格要求的，也是面向质量的
– 根据沟通的需要产生相应的文档

敏捷只是开发者的问题

– 基本的开发方法与传统相比有显著不同, 影响项目的各个方面: 合同,
角色, 定价模型, 项目管理等

采用敏捷方法的开发组/项目不需要制定计划

– 敏捷项目需要经常制定计划，但是不需要试图超前制定项目计划，通
常这也是不可能的

敏捷项目的范围可以随时改变

– 变更可以等到下一次迭代开始，当前正在进行中的迭代不能变更

只对小项目适用

– 在中型和大型的项目中一样取得了成功