敏捷开发系列之旅 第二站（走近XP极限编程）

上篇文章，我们探讨了什么是敏捷开发，以及敏捷开发的方法学。在这篇文章中，我们将继续讨论敏捷开发中的问题——XP极限编程。
在讨论之前，先让我们来了解一下XP极限编程产生的背景，软件业所具有的共同的问题。

• 简单（Simplicity）

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

• 反馈（Feedback）

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

• 勇气（Courage）

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

• 现场客户（On-site Customer）

     客户是Team成员，在开发现场和开发人员一起工作。传统的客户任务一般是讲解需求，运行验收测试，接收发布的系统。

• 小型发布（Small Release）

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

• 每周40小时工作制（40-Hour Work）

    “不加班，不熬夜”。XP要求项目团队人员每周工作时间不能超过40小时，加班不得连续超过两周，否则反而会影响生产率。

• 编码规范（Code Standards）

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

• 系统隐喻（System Metaphor）

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

结束语

XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。XP的思想启发我们如何学习和对待快速变化、多样的开发技术。