XP实践 (1) - XP必读篇

2008年9月26日

 

极限编程的一般思想

 

索引：

1.    应用领域

2.    开发流程图示

3.    开发原则

4.    设计原则

5.    编程原则

6.    团队成员角色

 

声明(ifanso@gmail.com)：

以下主要内容来自于中程在线对于XP开发的中文介绍，稍作几处修改

http://www.itisedu.com/phrase/200603291800375.html

 

 

正文：

 

Extreme Programming（XP，极限编程） 是一种轻量级的软件开发方法，它使用快速的反馈，大量而迅速的交流，经过保证的测试来最大限度的满足用户的需求。

 

1. 应用领域：

 

XP特别适用于需求经常改变的领域：客户可能对系统的功能并没有清晰的认识，或者系统的需求经常需要变动。XP也适用于风险比较高的项目，当开发人员面对一个新的领域或技术时，XP可以帮助减低风险。

 

XP适用于中小项目，人员在2-12人之间；特别地，在需求经常变化或风险比较高的项目中，少量而有效的XP开发人员效率要远远高于大量的开发人员。

 

2. XP的开发流程图示：

 

152.3.176.116

 

3. XP的开发原则

 

(1) 用户需求（user stories）

 

User stories描述用户所见的系统功能，但避免使用大量的文档，user stories由用户编写（不仅限于描述用户界面）。User stories使用用户的语言编写，不使用技术性的语言，每个user stories限于几句话。User stories用于在release plan会议上对开发时间进行评估，也用于产生功能测试（acceptance test），必须使用可以自动进行的功能测试保证软件的正确性。User stories与传统的用户需求的区别在于详细的程度，user stories并不会确定需求的每个细节，它只是用来简单的描述系统功能，供开发人员进行估计开发进度，在开发过程中，开发人员和用户会不断的交流以讨论细节问题。User story应该专注于功能，不应该过分注重用户界面等细节。一个user story在1-3周的时间完成，如果估计超过3周，说明user story太大了，需要细分。

 

(2) 产品计划（release plan）

 

Release plan用于规划开发周期。开发人员对每个user story估计开发时间（在不被打断，无其他工作情况下的开发时间，包括单元测试与功能测试），用户对user stories给出优先级。注意，release plan会议并不制订每个开发周期的详细计划。它的目的是使得用户、开发人员和管理者，在功能、资源、工期以及工程质量上达成一致。

 

(3) 阶段性产品（small release）

 

经常性地发布阶段性产品是XP的一个原则，每一个阶段性产品都必须实现部分功能的整合，尽快地提交给用户以获得反馈，并及时调整。团队在开发过程中收集数据，以便于对自己的开发速度进行评估。

 

(4) 迭代开发周期 (iteration)

 

迭代开发周期，即为每个阶段性产品的开发周期，约为1-3周。每个迭代开发的计划，应于上一个阶段性产品发布后，根据用户反馈而制定，以灵活地适应变化。要注重每个迭代周期的时间限制：当团队觉得不能按时完成时，宜重新评估，减少一些user stories。

 

(5) 迭代开发计划 (iteration plan)

 

在每个迭代开发周期开始的时候召开会议，从产品计划(release plan)中选择还没有实现的用户最迫切需要的user stories。上一个迭代开发中没有通过功能测试的功能也要在本次迭代中实现。User stories和失败的测试被分解成编程任务，使用技术语言编写，作为迭代开发计划的详细描述。程序员主动领取任务并估计完成时间，每个task应该在1-3天内完成，超过3天的task应该被细分。如果整个团队需要的时间多于或少于规定的iteration时间，则调整user stories。

 

(6) 站立会议

 

工作开始之前，开5-10分钟的站立会议。站立的目的是为了强迫节省时间。会议的目的是交流，提出存在的问题，但不要在会议上解决问题。开一个所有人员参加的短会比多个个别人员参加的会议要高效。在会议上提出的问题可以由少数人讨论解决，这个少数人参加的会议如果涉及到代码，可以在计算机前讨论。

 

(7) 人员流动

 

不要使每个开发人员局限于一项工作，不要使某项工作依赖于一个开发人员，增加知识共享，减少信息孤岛，多进行交流和培训。当项目中的所有人对所有模块都了解并可以进行开发时是效率最高的。

 

(8) 随机应变

 

XP并不是一成不变的，当团队觉得需要修改的时候，可以根据自己的情况进行修改，任何修改都要经过整个团队的讨论和达成一致

 

4. XP的产品设计原则

 

(1) 简洁；

 

(2) 尽量避免术语，使用用户可以理解的比喻；

 

(3) 采用CRC card，鼓励多人参与同一个对象的设计；

 

(4) 杜绝过早的功能设计；

 

(5) 及时进行代码重构（Refactoring），提高质量和可读性，保持设计简单。重构的前提是，代码已经完全通过测试。

 

5. XP的编程原则

 

(1) 用户是项目组的重要组成

 

用户的参加贯穿整个开发过程，用户与开发人员之间的交流是重要的；

 

(2) 统一的编码标准

 

这是保持代码整洁和共享代码的基础，强调纪律，不鼓励个性发挥；

 

(3)测试第一

 

在编写某个对象的代码之前先编写单元测试代码，且由同一个程序员完成，是XP的一个特点。先编写测试代码可以使程序员更好的理解需求，避免直接编码造成的理解偏差。实践证明，它所需要的编程工作量要远少于“先编码，后写测试代码”的方式。测试代码也是检验程序是否完成的标准。编码工作应该是以下工作的循环：

 

a) 编写测试代码；b) 运行测试程序，确认失败；c) 编写且仅编写刚好可以实现这个测试程序所要求功能的代码；d) 运行测试程序，确认成功

 

(4) 结对编程

 

结对编程是XP的特色，它要求两个程序员在一台计算机上同时进行编程工作。共用鼠标和键盘，通常一个人进行战略上的思考，程序架构和函数，类之间的关系，一个人进行输入和战术上的思考，完成函数和类。两个人可以经常交换角色。结对编程需要一段时间学习和适应，实践证明，结对编程并不消耗更多的时间(人*小时)，但是代码的质量得到很大的提高。（注：避免将两个新手放在一个pair中）

 

(5) 串联整合

 

为了保证源代码库的状态是可标识的，同一时间，只允许一个pair的程序进行整和和测试，这样可以缩小问题产生的范围。只要有可能就进行代码整合，周期可以在几个小时，最好不要超过一天。经常的整合可以避免错误的积累，可以增加可重用的代码。在一个pair认为适当的时候并通过了所 有的单元测试，就可以进行整合，整合后的代码必须通过测试。同一时间，只允许一个pair进行整合。不同的pair可以在自己的机器上随时进行整合和测试。

 

(6) 共同拥有代码

 

鼓励每个人对项目中的任何人提 出新的想法，任何开发人员对项目中的任何代码都可以进行增加功能，改正错误和重构。没有代码或开发人员成为瓶颈。为了达到这个目标，任何的代码都必须有相应的测试代码，任何代码的修改必须100%通过测试。必须加强开发人员的交流和知识共享，必须 坚持统一编码标准。Pair programming可以经常交换伙伴。

 

(7) 优化工作放在最后

 

先使系统能够正常工作，不要猜测系统的瓶颈，要实际测量

 

(8) 拒绝加班

 

不要长时间的加班，大多数加班并不能挽回已有的延迟，连续超过两个星期的加班说明有问题存在。向一个已经延迟的项目填加人员也不是一个好的选择。

 

6. XP团队中的成员角色：

 

(1) 用户

 

在XP中，用户是项目组的一部分，用户负责编写use stories，确定优先级，和开发人员讨论需求，编写、运行功能测试，驱动每次迭代开发。

 

(2) 开发人员

 

与用户讨论user stories，估计开发时间，将user stories细化成编程任务；编写单元测试；编码；进行重构；整合及测试，保证100%通过

 

(3) 协调员

 

负责对外联系，组织团队，获取必要的资源，管理团队

 

(4) 监督

 

跟踪产品计划，迭代开发计划，以及功能测试状况

 

(5) 教练

 

起顾问指导作用，监督进展，确保过程和规则，必要时改变过程，帮助解决问题，也可以参加结对编程。