Extreme Programming

Extreme Programming（XP，极限编程） 是一种轻量级的软件开发方法，它使用快速的反馈，大量而迅速的交流，经过保证的测试来最大限度的满足用户的需求。XP强调用户满意，开发人员可以对需求的变化作出快速的反应。XP强调team work。项目管理者，用户，开发人员都处于同一个项目中，他们之间的关系不是对立的，而是互相协作的，具有共同的目标：提交正确的软件。XP强调4个因素：
交流(communication)，XP要求程序员之间以及和用户之间有大量而迅速的交流
简单（simplicity），XP要求设计和实现简单和干净
反馈（feedback）通过测试得到反馈，尽快提交软件并根据反馈修改
勇气（courage）。勇敢的面对需求和技术上的变化

XP特别适用于需求经常改变的领域，客户可能并系统的功能并没有清晰的认识，可能系统的需求经常需要变动。
XP也适用于风险比较高的项目，当开发人员面对一个新的领域或技术时，XP可以帮助减低风险
XP适用于小的项目（人员上），人员在2-12人之间，XP不适用于人员太多的项目，事实上，在需求经常变化或风险比较高的项目中，少量而有效的XP开发人员效率要远远高于大量的开发人员。

下面是XP的开发流程


XP的原则和实践：

1 Planning:

1)user stories。
User stories类似use case，描述用户所见的系统功能，但避免使用大量的文档，user stories由用户编写（不仅限于描述用户界面）。User stories使用用户的语言编写，不使用技术性的语言，每个user stories限于几句话。User stories用于在release plan会议上对开发时间进行评估，也用于产生验收测试（acceptance test），必须使用可以自动进行的验收测试保证软件的正确性。User stories与传统的用户需求的区别在于详细的程度，user stories并不会确定需求的每个细节，它只是用来简单的描述系统功能，供开发人员进行估计开发进度，

在开发过程中开发人员和用户会不断的交流以讨论细节问题。User story应该专注于功能，不应该过分注重用户界面等细节。一般一个user storiy在1-3周的时间完成，如果估计超过3周，说明user story太大了，需要细分。

2)release plan.
召开一个release plan会议，产生release plan。Release plan将用于指定每个iteration的计划。开发人员对每个user story估计开发时间（在不被打断，无其他工作情况下的开发时间，包括测试），用户对user stories给出优先级，release plan会议并不制订每个iteration的计划。Release plan要用户，开发人员和管理者都同意，在完成功能范围（scope），使用资源（resource）,时间（time）和质量(quality)上达成一致（一般质量是不能改变的）

3) small release
often and small release是XP的一个原则，每个release完成一些用户有意义的功能集合，尽快的提交给用户以获得反馈，及时调整，提交的越晚，调整越困难。
4）project velocity
团队在开发过程中要收集数据，以便于对自己的开发速度进行评估，用于以后的releazse plan

5)iteration
每个small release的周期称为iteration，每个iteration约为1-3周，在一个项目中保持每个iteration的时间相等，不要超前制定计划，每个iteration的计划在iteration的开始时制定。这样能够更灵活的应付变化。不要急于完成本次iteration没有包括的功能。要注重每个iteration的时间限制，当团队觉得不能按时完成iteration时，召开一次iteration plan会议，重新评估，减少一些user stories。

6）iteration plan
在每个iteration开始的时候召开会议，从release plan中选择还没有实现的用户最迫切需要的user stories。上一个iteration中没有通过验收测试的功能也要在这个iteration中实现。可以根据上一个iteration的实践调整团队速度。User stories和失败的测试被分解成programming task，task使用技术语言编写，作为iteration plan的详细描述。程序员主动领取task并估计完成时间，每个task应该在1-3天内完成，超过3天的task应该被细分。如果整个团队需要的时间多于或少于规定的iteration时间，调整user stories。

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

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

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

2 Designing

1) Simplicity
保持简单的设计，在完成同样的功能的情况下，选择简单的设计，不要急于设计没有计划的功能，应该认识到：keeping a design simple is hard work

2）system metaphor
使用统一的术语描述系统，在用户，管理者和开发人员之间使用统一的术语。这将使交流清晰。

3）CRC card
使用CRC(Class, Responsibilities, and Collaboration) card进行系统设计，鼓励更多的人参加设计。每个CRC卡片表示系统中一个对象，写上对象的名字，责任和每个责任需要交互的其他对象。可以模拟对象之间的交互。CRC卡片是易于理解的，但是是非正式的，如果需要正式的文档，要将卡片转换为相应的文档。

4) spike solution
使用spike solution减低风险，当遇到技术难题或设计问题时，使用简单的程序进行测试，找出问题，在不同的解决方法之间进行评估。在早期进行实验可以有效的降低风险。

5）never add function early
不要过早的设计没有计划的功能，在一个需求经常变化的环境中，过早的设计经常是没有用的。

6）refactoringwhenever and wherever
XP鼓励对设计和代码经常进行重构（Refactoring），目的是去除冗余，提高质量，保持设计简单。重构必须以完全测试为检验条件


3 Coding

1) customer is alaways available
用户是项目组的成员之一，用户的参加贯穿整个开发过程，用户与开发人员之间的交流是重要的

2) coding standard
使用统一的编码标准，这是保持代码整洁和共享代码的基础

3）coding unit test first
test first是XP的一个特点，在编写代码之前先编写单元测试代码，单元测试代码和代码由同一个程序员完成。先编写测试代码可以使程序员更好的理解需求，避免直接编码造成的理解偏差，对需求的不清晰，可以在编写测试代码时就发现。测试代码也是检验程序是否完成的标准。编码工作应该是以下工作的循环：
1 编写测试代码
2 运行测试程序，确认失败
3 编写实现这个测试程序要求功能的代码，不需要实现其他的功能，只需要实现刚刚满足测试程序的功能
4 运行测试程序，确认成功
实践证明，test first方式需要的编码实践少于先编码，后写测试代码

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

5）sequential integration
要保证源代码库的状态是可标识的，同一时间，只允许一个pair的程序进行整和和测试，这样可以缩小问题产生的范围。不同的pair可以在自己的机器上随时进行整和和测试.

6) integrate often
只要有可能就进行代码整合，周期可以在几个小时，最好不要超过一天。经常的整合可以避免错误的积累，可以增加可重用的代码。在一个pair认为适当的时候并通过了所有的unit test，就可以进行整合，整合后的代码必须通过测试。同一时间，只允许一个pair进行整合。(整合失败是不是要退回原有状态，供其他pair整合？？)

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

8）优化工作放在最后
先使系统能够正常工作，不要猜测系统的瓶颈，要实际测量

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




4Testing

1)所有的代码都有单元测试
单元测试是XP的基石，XP中的单元测试应该是可以自动进行的，所以可以很快的进行所有的单元测试，单元测试应该在编码之前创建。单元测试的代码和代码一起release，没有单元测试的代码不能够release。使用自动单元测试可以系统整合时节省大量的发现错误和改正的时间。单元测试越完善，节省的时间越多。对面向对象的编程来说，应该对每个类都有单元测试。完善的单元测试也是共同拥有代码的保证。单元测试也是可以经常重构的保证，每次重构后的代码都要重新进行测试
（这里的unit test好象不只限于测试某个模块的功能？？？，应该可以测试整合起来的整个系统，这样才能保证整合的正确性。）

2）代码在release前必须通过所有的单元测试

3) 发现bug后，首先增加测试
在实际运行中发现bug,首先增加acceptance test，然后增加unit test，在增加完测试后在查找和修改代码，增加的测试保证同样的错误不会再出现

4) acceptance test
acceptance test根据user stories在iteration plan会议上创建，它也应该可以自动运行以便可以经常运行。User stories是否完成是以是否通过acceptance test为检验标准。


XP中的角色：

1 customer 用户
在XP中，用户是项目组的一部分，用户负责编写use stories，确定优先级，和开发人员讨论需求，编写accept test，运行accept test，用户驱动iteration(release plan, iteration plan)

2 开发人员
与用户讨论user stories，估计开发时间，将user stories细化成programming task
编写unit test
编码
进行重构
整合及测试，保证100通过

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

4 tracker
跟踪release plan/iteration plan/acceptance test

5 coach
起顾问指导作用，mentor, monitor and help
A Coach is respected, but also respectful. They’re willing to talk, but also willing to listen. They let the team explore, but provide a guard-rail in case of danger.

监督进展，确保过程和规则，必要时改变过程，帮助解决问题，也可以参加pair programming。