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

 

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

2014-03-19 19:28 2670人阅读 评论(14) 收藏 举报

本文章已收录于： 

 敏捷知识库

 分类：

【研发总结】（73） 

版权声明：本文为博主原创文章，未经博主允许不得转载。

 

目录(?)[+]

 

上篇文章，我们探讨了什么是敏捷开发，以及敏捷开发的方法学。在这篇文章中，我们将继续讨论敏捷开发中的问题——XP极限编程。

 

在讨论之前，先让我们来了解一下XP极限编程产生的背景，软件业所具有的共同的问题。

 

背景

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

了解了背景之后，那么就会想问，到底什么是极限编程呢？下面我们就做一个简单的介绍。

 

XP概述

 

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

 

核心价值观

• 沟通（Communication）

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

• 简单（Simplicity）

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

• 反馈（Feedback）

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

• 勇气（Courage）

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

 

12个实践原则

• 规划策略（Planning Game）

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

 

• 结对编程（Pair Programming）

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

 

     结对编程是让两个人共同设计和开发代码的实践。结对者是全职合作者，轮流执行键入和监视；这提供了持续的设计和代码评审。不是两个人做一个人的事情。 

• 测试（Testing）

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

• 重构（Refactoring）

     重构是XP的一个重要组成部分。所谓重构是指在不改变代码外在行为的前提下对代码做出的修改，以改进代码的内部结构。重构是一种有纪律的、经过训练的、有条不紊的代码整理方法，可以将整理过程中不小心引入错误的可能性降到最低。改进软件的设计，Refactoring帮助重新组织代码，重新清晰地体现结构和进一步改进设计。

• 简单设计（Simple Design）

     系统应设计得尽可能简单。

• 代码集体所有权（Collective Code Ownership）

     代码集体所有权强调的是整个团队，而非个人，即“我们”的代码，而不是“我”的代码。 团队中的任何人都可以改动任何一段代码，但改动后的代码必须通过所有相关的测试。

• 持续集成（Continuous Integration）

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

 

     测试先行是持续集成的一个重要前提。持续集成指不断地把完成的功能模块整合在一起。目的在于不断获得客户反馈以及尽早发现BUG。随时整合，越频繁越好；集成及测试过程的自动化程度越高越好。每次只有一个PAIR在整合，而且必须运行功能测试。

 

     需注意，持续集成需要良好的软件配置变更管理工具的有效支持。 

 

• 现场客户（On-site Customer）

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

• 小型发布（Small Release）

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

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

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

• 编码规范（Code Standards）

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

• 系统隐喻（System Metaphor）

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

 

开发过程

 

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

 

适用范围

 

XP适合规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和最小的 代价来满足用户未来的需求，XP在平衡短期和长期利益之间做了巧妙的选择。

 

结束语

 

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