敏捷开发二——极限编程

背景：

• 软件越来越复杂
• 需求越来越多变
• 过程越来越规范

XP概述（eXtreme Programming）

是一种全新的，轻量级的，灵巧的软件开发方法。它强调程序设计团队与业务专家之间的紧密协作，面对面的沟通（比书面文档更有效），频繁交付新的版本，紧凑而自我组织的团队，能够更好地适应需求变化的代码编写和团队组织方式，更注重软件开发中的人的作用。

核心价值观

沟通

问题往往是由开发人员和设计人员，设计人员和客户之间沟通不畅造成的。XP认为项目之间的沟通是项目成功的关键，并把沟通看作是协调与合作的推动因素。项目相关人员进行充分，多渠道沟通很有必要。

简单

XP假定未来不能可靠预测，所以不应该过多考虑未来的问题而是应该集中力量解决燃眉之急。 在系统可运转的前提下，做最简洁的工作，坚定的专注于最小化解决方案；在开发中不断的优化设计，时刻保持代码简洁、无冗余。需求尽量的简单，设计尽量的简单，代码尽量的简单，文档尽量的简单。

反馈

尽快获得用户的反馈，并且越详细越好，使得开发人员能够保证自己的成果符合用户的需要。强调各种形式的反馈：小交付、短迭代、测试先行等。XP认为系统本身及其代码是报告系统开发进度和状态的可靠依据。系统开发状态的反馈可以作为一种确定系统开发进度和决定系统下一步开发方向的手段。

勇气

这是最重要的核心价值。因为XP强调要“拥抱变化”，因此对于用户的反馈，提倡积极面对现实和修改问题的勇气，如放弃已有代码，改进系统设计等；勇敢的重构；所有人拥有代码；敢于极限（把好的方法做到极致）。XP认为，软件开发中，人是最重要的一个方面。在一个软件产品的开发中，人的参与贯穿其整个生命周期，是人的勇气来排除困境，让团队把局部的最优抛之脑后，达到更重大的目标。

12个实践原则：

规划策略（planing game)：

以业务优先级和技术估计为基础，决定下一版本发布的范围：

结对编程：

结对编程是一种编程模式。两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起单元测试，一起整合测试(Integration Test)，一起写文档等。基本上所有的开发环节都一齐肩并肩地，平等地，互补地进行开发工作

测试：

测试驱动开发，是指在编码前，首先将测试写好，然后进行编码，直至所有测试都通过。即先测试，再编码，代码未动，测试先行。通常包括，Unit Test、Acceptance Test( Functional Test )、Nightly Test、Stress Test等

重构：

重构是不改变代码外在行为的前提下对代码做出修改，以改进代码的内部结构，重构是一种有纪律，经过训练的，有条不紊的代码整理方法。可以讲整理过程中不小心引入的错误降到最低。

简单设计：

系统尽可能的简单。

代码集体所有权：

强调整个团队，而非个人，即“我们的代码”。团队中任何一个人都可以改动代码，但是改动之后必须通过测试。

持续集成：

任何时候只有要一项任务完成，就集成新代码，构造系统并测试，持续集成是每日集成/每晚集成的极限形式。是XP的重要基础。

测试先行是持续集成的一个重要前提，持续集成是不断的把完整的功能模块整合在一起，目的在于不断的获得用户反馈以及今早发现bug，

现场客户：

客户是team成员，在开发现场和开发人员一起工作。

小型发布：

发布过程应该尽可能地自动化、规范化。不断地发布可用的系统可以告诉客户你在做正确的事情。客户使用发布的系统，可以保证频繁地反馈和交流。保证客户有足够的依据调控开发过程(增加、删除或改变User Story)。降低开发风险。随着开发的推进，发布越来越频繁。所有的发布都要经过功能测试。 

每周40 hour工作制

编码规范：

XP 强调通过指定严格的代码规范来进行沟通，尽可能减少不必要的文档。类型包括：格式、代码结构、命名约定、错误处理、注释等。

系统隐喻：

XP通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统。它通常包含了一些可以参照和比较的类和设计模式。XP不需要事先进行详细的架构设计。
开发过程：

用户代表提出用户故事，项目组据此进行讨论、提出隐喻，在此活动中有可能要进行系统结构的Spike。在隐喻和用户故事的基础上，根据用户设定的优先级制订交付计划，然后开始多个迭代过程，在迭代期内产生的新用户故事不在本迭代内解决，以保证开发不受干扰。经验收测试通过后交付使用。

适用范围：

适合规模小，进度紧，需求变化大，质量要求严的项目。